You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is silly. We should stop having to care if the authenticator gets too big. The server already remembers a key for every session by virtue of subscribing.
One potential nuisance with it is that it may make the session lifetime problem worse. Right now a session from an expired ticket can still receive messages but you can't send new ones (or even shut it down...). We should certainly allow ZCancelSubscription because that's just dumb. New subscriptions and sending new messages is less clear. It will make Roost's life much much easier, but it'd be even harder to revoke those things.
But short of better Kerberos primitives, maybe that's not a bad thing. Perhaps zephyr should just give up on being able to revoke at the Kerberos level and instead, say, let you send a "BOOT" message to the zephyrds to boot all sessions on your principal or all which match some hostname or IP or whatever.
The text was updated successfully, but these errors were encountered:
Maybe we could let you even query all your live sessions and stuff. Of course, all this depends on IS&T deploying zephyrd changes, but I bet that's more likely than them deploying KDC changes.
This is silly. We should stop having to care if the authenticator gets too big. The server already remembers a key for every session by virtue of subscribing.
Karl's branch here is probably a good place to start:
https://github.com/zephyr-im/zephyr/tree/dev/kcr/red-right-hand
One potential nuisance with it is that it may make the session lifetime problem worse. Right now a session from an expired ticket can still receive messages but you can't send new ones (or even shut it down...). We should certainly allow ZCancelSubscription because that's just dumb. New subscriptions and sending new messages is less clear. It will make Roost's life much much easier, but it'd be even harder to revoke those things.
But short of better Kerberos primitives, maybe that's not a bad thing. Perhaps zephyr should just give up on being able to revoke at the Kerberos level and instead, say, let you send a "BOOT" message to the zephyrds to boot all sessions on your principal or all which match some hostname or IP or whatever.
The text was updated successfully, but these errors were encountered: