On Wednesday, October 31, 2012 8:52:00 PM, Russ Allbery wrote: > Jeffrey Altman <[email protected]> writes: > >> I disagree. The valid lifetime of an rxgk token does not need to be the >> same as the Kerberos ticket lifetime or the X.509 client certificate >> lifetime or whatever is applicable for OATH. For rxkad the token is >> Kerberos ticket and I'm willing to accept that as a result the rxkad >> lifetime matches the Kerberos ticket lifetime. However, an rxgk token >> is not a Kerberos ticket. It is explicitly and intentionally >> independent. > > However, it derives its authentication identity from a Kerberos ticket, > and it is *inherent* in the Kerberos mechanism that the identity that you > derive from a Kerberos ticket is only valid for the expiration period of > that ticket. Beyond the expiration point of a ticket, that ticket says > nothing about the authenticated identity of the user. > > The authentication data therefore needs to be discarded by any downstream > consumer of Kerberos tickets. Not doing this significantly undermines the > Kerberos security model. The lack of revocation support in Kerberos is > made possible by limited-lifespan tickets, and ignoring that expiration > means introducing new security vulnerabilities. > > It's particularly important in security systems to not discard bounds and > restrictions when translating their results into another protocol. By > doing so, you discard invariants that you may be relying on for other > security guarantees, some of which can be quite subtle and tricky.
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. From a usability perspective, on Microsoft Windows, it is practically impossible to force renewal of Kerberos tickets in order to obtain reasonable lifetimes. Windows completely ignores renewable ticket lifetimes. The Kerberos SSPI pays no attention to Kerberos ticket lifetimes for any subsequent Security Context usage. Once the Security Context is created for a service it is valid until the client chooses to obtain a new one. As a result, Windows allows Kerberos ticket lifetimes to drop to under five minutes and there is no reasonable way to force the acquisition of a new Kerberos ticket with a longer lifetime. 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. As I said previously, it is completely reasonable for an rxgk service administrator to decide that a given rxgk service should enforce a policy of Kerberos ticket lifetime equals rxgk token lifetime. However, it should be equally possible for a rxgk service administrator to say that s/he wants the lifetime to be Kerberos ticket lifetime plus one hour to ensure that Microsoft's poor implementation choices do not result in file system access failures. It should also be possible to say that the lifetime is a fixed period of time independent of the authentication lifetime. 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. The way I view the distinction is between authentication and authorization. The authentication occurs at the point when the authentication credential is presented to the rxgk service. At that point the rxgk service can refuse to issue the token or not. Once the token has been issued, the entity has been authenticated to the cell. From that point forward what are made are authorization decisions not authentication decisions. The validity of the authorization information is application specific. 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. Jeffrey Altman
signature.asc
Description: OpenPGP digital signature
