[AFS3-std] Re: rxgk token expiry

[Russ Allbery]

Jeffrey Altman <jaltman@secure-endpoints.com> 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 (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>