[AFS3-std] Re: rxgk token expiry

[Jeffrey Altman]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig2B96B69EBBDA4710372E37BE
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 t=
he
>> 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 y=
ou
> derive from a Kerberos ticket is only valid for the expiration period o=
f
> 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 downstre=
am
> 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 a=
nd
> 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=20
from
Kerberos authentications.   The rxgk token is a derived form of GSS
security context.  Forcing termination of application specific=20
connections
because the authentication context has expired is impractical and has=20
been
demonstrated to result in data loss.

 From a usability perspective, on Microsoft Windows, it is practically=20
impossible
to force renewal of Kerberos tickets in order to obtain reasonable=20
lifetimes.
Windows completely ignores renewable ticket lifetimes.  The Kerberos=20
SSPI
pays no attention to Kerberos ticket lifetimes for any subsequent=20
Security Context
usage.  Once the Security Context is created for a service it is valid=20
until the client
chooses to obtain a new one.   As a result, Windows allows Kerberos=20
ticket
lifetimes to drop to under five minutes and there is no reasonable way=20
to force the
acquisition of a new Kerberos ticket with a longer lifetime.  Besides,=20
what
difference does it make when the password or other credentials have been
cached by the operating system and the entity being authenticated is=20
never
going to be asked to re-authenticate.

As I said previously, it is completely reasonable for an rxgk service=20
administrator
to decide that a given rxgk service should enforce a policy of Kerberos=20
ticket lifetime
equals rxgk token lifetime.  However, it should be equally possible for=20
a
rxgk service administrator to say that s/he wants the lifetime to be=20
Kerberos ticket
lifetime plus one hour to ensure that Microsoft's poor implementation=20
choices
do not result in file system access failures.   It should also be=20
possible to say
that the lifetime is a fixed period of time independent of the=20
authentication
lifetime.

rxgk is not a Kerberos specific security class.  When rxgk is used with=20
a
X.509 client certificate that has a one year lifetime, or is used with=20
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=20
going to be.

The way I view the distinction is between authentication and=20
authorization.
The authentication occurs at the point when the authentication=20
credential
is presented to the rxgk service.  At that point the rxgk service can=20
refuse
to issue the token or not.  Once the token has been issued, the entity=20
has
been authenticated to the cell.  From that point forward what are made
are authorization decisions not authentication decisions.  The validity=20
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.

Jeffrey Altman



--------------enig2B96B69EBBDA4710372E37BE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)

iQEcBAEBAgAGBQJQkdNAAAoJENxm1CNJffh4ZwAIAOMiv16QOX5X09QcDX0GAZ6k
GpwHZPlnimcPnzyvLr4bWhzqyoHP0eqDJnSJt7kXj9Agg5e89zseE73P/l9vlifz
TWymweroE578NMd+lziLuxuamjXlL9MoasWLVuDLoZCdsngCOTLJrUVnfedmYPEY
kH8rlioCqTuRC2BsnOFy+WLSOqgpZvyxkmgOV7Tss4fGKlY0t/c8J5IZSOcp5SMv
8OchP7EmBI+tmLoyTwfKj1hnfNKs8pkLoLdEZ8LWUyaDD21tWcvhH1pazINNKhw0
57K6se1auZe1Ndn1rUU6YH2tz/y364OCj4i9mLHliOCKTFe7seGIIgrZGxRjAdk=
=KfKr
-----END PGP SIGNATURE-----

--------------enig2B96B69EBBDA4710372E37BE--