[AFS3-std] Re: rxgk token expiry

[Benjamin Kaduk]

I will try to keep comments brief, this risks becoming a very long thread.

On Wed, 31 Oct 2012, Jeffrey Altman wrote:

> On Wednesday, October 31, 2012 8:52:00 PM, Russ Allbery wrote:
>> 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.
>
> 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.
>

The question of existing versus new connection, and of authentication 
versus authorization, are good things to think about in this class of 
situations.  A single token may be used for both creating new connections 
and supporting encryption of existing ones ... but RX connections do not 
necessarily map to exactly what a user may want to think of as a 
connection.  At the level of an rxgk document, I do not think that we 
should try very hard to specify all application behavior.

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

OS X renews kerberos tickets automatically.  MIT Kerberos for Windows will 
renew kerberos tickets automatically.  Red Hat's SSSD will renew kerberos 
tickets automatically.  I echo Russ; Microsoft Windows' behavior is 
unfortunate, but nor is it the only behavior around.

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

Per Russ' follow-up to this, we cannot realistically make any strong 
statement at the level of the rxgk specification document.  If we want to 
get into a more detailed discussion of these issues, it should probably 
belong on an application-specific list, e.g., openafs-devel.

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

Indeed.  But that original kerberos ticket cannot create a new SSH 
connection once it is expired, even as the existing SSH connection 
remains.

I think we can only make a weak statement in this document, and proposed 
as such in my commit:
        <t hangText="expiration">The time, expressed as an rxgkTime, at which
-       this token expires.</t>
+       this token expires. The expiration time MAY be set administratively
+       by the server, and SHOULD reflect the expiration time of the
+       underlying GSSAPI credential.</t>

The server application has freedom to lower, or increase, the expiry time 
of the underlying credential, but should take that underlying credential 
into account as appropriate for the application.

-Ben