rxgk token expiry (was Re: [AFS3-std] Re: afs3-rxgk-updates for 03)

[Jeffrey Altman]

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



On Wednesday, October 31, 2012 8:15:07 PM, Benjamin Kaduk wrote:
> On Mon, 29 Oct 2012, Jeffrey Hutzelman wrote:
>
>> On Mon, 2012-10-29 at 16:57 -0500, Andrew Deason wrote:
>>
>>>> commit 13a2d01b722969da997f1878ad176991fb0ffabc
>>>> Author: Ben Kaduk <kaduk@mit.edu>
>>>> Date:   Wed Oct 24 23:26:49 2012 -0400
>>>>
>>>>     Clarify token expiry
>>>
>>> For krb5-based tokens, does this have any relevance for renewable
>>> tickets? That is, if our expiration time is in 10 hours, but we are
>>> renewable for 7 days, we want this field to specify the 'expiration
>>> time' in 7 days from now, not 10 hours, correct? Or does that just
>>> result in an entirely new connection because the token is effectively=

>>> entirely new? (I feel like this is obvious, but after reading this te=
xt
>>> for a while I tend to get confused easily... :)
>>
>> No, the token has to expire in 10 hours, when the ticket does.  The
>> renewable lifetime of a ticket only tells you for how long the KDC wil=
l
>> let you get a new ticket by presenting the old one to the TGS.
>
> I agree with jhutz; we must use the ticket that we have, not the
> ticket that we could have.
>
> -Ben

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=20
certificate lifetime
or whatever is applicable for OATH.   For rxkad the token is Kerberos=20
ticket
and I'm willing to accept that as a result the rxkad lifetime matches=20
the Kerberos
ticket lifetime.  However, an rxgk token is not a Kerberos ticket.  It=20
is explicitly
and intentionally independent.

I want the rxgk token lifetime to be specified by policy.   For=20
example, all rxgk
tokens in a particular environment may have a fixed lifetime.  For AFS=20
that might
be one hour from time of authentication.  For BOS that might be five=20
minutes.

Tying the AFS token lifetime to the remaining lifetime of the Kerberos=20
TGT has
proven to be a usability nightmare.  If there is one thing that end=20
user organizations
ask more than anything else it is "how can I request an afs token that=20
will always
provide a guaranteed minimum lifetime?"

If an organization wants the token lifetime to be tied to the Kerberos=20
ticket lifetime
that can be the administrators choice but it should not be a=20
requirement.  Certainly
not for a standard that is not Kerberos specific.

Jeffrey Altman



--------------enigB4DDBB82B47B410FF3504F7C
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)

iQEcBAEBAgAGBQJQkcTOAAoJENxm1CNJffh497sIANHK8zv/aAhzQ5esIAKn6W/h
sJfQRC7MIB/uvzbLfOt3IBg+wr9fjSdcsapAzB7iOF4NJ9h2WzErAEwB82TReBYf
gBJ6X+S7EP0KudTgKX9gE7JiHxPqLUGAHoXjM1LcRYuQu4KbPP3KaBWNsdBywjnq
zlLhRLM2YQxlqzKq0Dlc0ui4NfQ+AHl8OwBhHWnaUh9odcobYKmVYAVp5X2DCtxl
RwE4P21xTw5MEP37qpoA7IHOoUem672E0XLbrp5bARRwrQ0bmtmFMFvofwjbRJiN
oI1LYOB6Z2pBvGnzVwjQpu+XctNzPOlOcTcaNFIMzOPSI7ZnrEJRKNS7gcssuME=
=SibK
-----END PGP SIGNATURE-----

--------------enigB4DDBB82B47B410FF3504F7C--