[AFS3-std] Re: rxgk token expiry

[Russ Allbery]

Jeffrey Altman <jaltman@secure-endpoints.com> 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.

> I want the rxgk token lifetime to be specified by policy.  For example,
> all rxgk tokens in a particular environment may have a fixed lifetime.
> For AFS that might be one hour from time of authentication.  For BOS
> that might be five minutes.

An rxgk lifetime that's less than the Kerberos ticket lifetime is, of
course, fine.  Longer isn't.

> Tying the AFS token lifetime to the remaining lifetime of the Kerberos
> TGT has proven to be a usability nightmare.  If there is one thing that
> end user organizations ask more than anything else it is "how can I
> request an afs token that will always provide a guaranteed minimum
> lifetime?"

There are solutions to that problem in Kerberos (k5start -H, krenew, kcm,
NIM), and that's the proper place to solve them, not in other applications
that reuse Kerberos tickets.  At the time that you make that request, you
check the remaining lifespan in the Kerberos ticket.  If it's
insufficient, you try to renew it.  If it's still insufficient, you force
the user to reauthenticate.  Then you end up with the required token
(assuming that your Kerberos and AFS configurations are consistent).

> If an organization wants the token lifetime to be tied to the Kerberos
> ticket lifetime that can be the administrators choice but it should not
> be a requirement.  Certainly not for a standard that is not Kerberos
> specific.

I completely disagree.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>