Jeffrey Altman <[email protected]> writes: > The battle was lost a long time ago. Heimdal, MIT and Microsoft all > disregard Kerberos ticket lifetimes for GSS security contexts derived > from Kerberos authentications. The rxgk token is a derived form of GSS > security context. Forcing termination of application specific > connections because the authentication context has expired is > impractical and has been demonstrated to result in data loss.
This is not the same thing: it's a *connection*. People have chosen to give those connections the property that they are only authenticated at the start of the connection, not continuously authenticated throughout the session. This is a security tradeoff, but it's a less significant one, because TCP connections are not portable. You cannot easily steal someone else's LDAP session, or IMAP session, when you compromise their tickets, which is what Kerberos's revocation-free mechanism is intended to protect against. The security damage is therefore limited to allowing the authenticated user to continue to use existing sessions after their ability to authenticate has been revoked or after a compromise of their credentials have been discovered, but not to initiate new connections. There is a significant difference between allowing a TCP connection that is already open to continue after the authentication data has expired and allowing the possessor of a derived credential to create a *new* network connection using those credentials, authenticating with that credential. And that's what separating the rxgk token lifetime from the Kerberos ticket lifetime would permit, so far as I understand how the protocol works. The rxgk token is not a session authenticator for a single network connection. It's a derived credential. The lack of proper Windows support for a common Kerberos need is unfortunate, and causes problems for practical deployment, I agree. But this is a pretty serious hole in the security model to introduce just because the Windows Kerberos API is deficient. > Besides, what difference does it make when the password or other > credentials have been cached by the operating system and the entity > being authenticated is never going to be asked to re-authenticate. It makes a difference because the way that Kerberos implements revocation is to change the user's password, at which point such reauthentication will fail. > rxgk is not a Kerberos specific security class. When rxgk is used with > a X.509 client certificate that has a one year lifetime, or is used with > OATH or OpenID or SRP all of which have no lifetimes, it must be > possible for the rxgk service administrator to specify what the lifetime > policy is going to be. I have no objections to that. But I am opposed to standardizing an rxgk mechanism that permits creating rxgk tokens that last longer than the Kerberos ticket expiration time. I think it significantly weakens the Kerberos security model to do so. > For example, the valid lifetime of an SSH connection is not determined > by the lifetime of the Kerberos ticket when GSS authentication is used. > The lifetime of the connection is determined by the policy enforced by > the SSH service. Since that's an ongoing TCP session, it's not analogous. Analogous would be issuing an ssh RSA key pair based on Kerberos credentials and allowing it to be used to authenticate new connections after the Kerberos credentials have expired. Or, in kx509, issuing an X.509 certificate from Kerberos credentials with a lifetime longer than the underlying Kerberos credentials. -- Russ Allbery ([email protected]) <http://www.eyrie.org/~eagle/> _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
