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 <[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.
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
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
