[AFS3-std] Re: rxgk token expiry

[Benjamin Kaduk]

On Thu, 1 Nov 2012, Simon Wilkinson wrote:

>
> On 1 Nov 2012, at 03:42, Benjamin Kaduk wrote:
>> 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.
>
> I'm happy with the intent behind this, although I wonder if the wording

Okay.  Does jaltman have objections to the intent behind it?

> leaves the possibility that the server could set no expiration time at 
> all, which we obviously want to avoid.
>

Hmm, a fair point.
In summary (hopefully I did not miss something while reviewing the 
thread), we may want to add one or more of the following constraints to 
the above sentiment:
(1) the server MUST set some expiration time
(2) the server SHOULD NOT set an expiration time after the expiration time 
of the underlying credential

(2) seems to be the more controversial of the two, but I would like it to 
be present.  This sentiment seems to parallel the snippet Russ quoted from 
RFC 6717, which has "it is RECOMMENDED that the lifetime of an issued 
certificate not exceed the lifetime of the predecessor Kerberos ticket 
unless the implications with respect to local policy and supporting 
infrastructure are clearly understood and allow it."; we can certainly use 
a parallel wording if necessary to acheive consensus from this group.

-Ben