[AFS3-std] Re: rxgk token expiry

[Jeffrey Hutzelman]

On Wed, 2012-10-31 at 18:51 -0700, Russ Allbery wrote:


> > 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.

I would certainly be opposed to assigning a session lifetime to an rxgk
token that extends beyond the life of the X.509 certificate used to
obtain it, just as I would for one that extends beyond the lifetime of a
Kerberos ticket.

Over the years, we've seen a variety of problems resulting from
credential translation services loosening restrictions rather than
tightening them.  Some of these have led to failure modes such as a
client being able to renew credentials indefinitely, or worse.

If you want an rxgk-authenticated _connection_ to be able to last longer
than the lifetime of the token used to authenticate it, that's one
thing.  In the case of AFS, even that concerns me -- the security model
that users and administrators depend on assumes that once you no longer
have valid tokens, you are no longer able to access the filesystem.
Yes, immediately.  The fact that you opened a sensitive document an hour
before you were fired should not grant you the ability to write to it an
hour after, even though your credentials have expired.



> 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.

Me too.  As Russ points out, the rxgk token is a derived credential, and
it is unacceptable for that credential to last longer than the one from
which it is derived.  I am opposed to allowing this behavior, even as an
option, because I expect people will use the option and even make it a
default because it is "easier", regardless (or ignorant) of the security
implications.  I've seen too many cases of well-meaning people on
mailing lists or in web forums recommending broken, insecure settings as
a "workaround" to some problem, while clearly not understanding what
they do.  While that's certainly not a universal argument for not having
flexibility, I also don't want to see rxgk in the same category of the
many applications that "use TLS" and gain from it only a false sense of
security.





> > 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.

Actually, to an extent, it is.  The SSH protocol limits the lifetime of
session keys to one hour or one gigabyte, whichever comes first (see
RFC4253 section 9).  Before these limits are reached, the session must
be rekeyd, and rekeying with an expired GSS-API context will fail,
causing the session to be terminated immediately.

Of course, it is possible to use GSS-API for user authentication in SSH
without using it for key exchange, in which case the context lifetime
has no effect on