[AFS3-std] Re: rxgk token expiry

[Benjamin Kaduk]

On Thu, 1 Nov 2012, Jeffrey Hutzelman wrote:

> On Wed, 2012-10-31 at 23:42 -0400, Benjamin Kaduk wrote:
>
>> 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.
>
> <hat role="chair">
> Oh, no.  The application-protocol-specific issues are very much in scope
> for this list, at least to the extent that the application protocol is
> AFS.  They are simply not in scope for this _document_.
> </hat>

Ah, okay.


>
>> 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.
>
> That's not quite strong enough; I think you should explicitly say the
> token SHOULD NOT expire later than the underlying credential.  In any
> case, this needs to be discussed somewhat in security considerations.

Mentioned in my previous mail.
Am I on the hook for drafting text to go in the security considerations 
section?

>
> It is important to realize that both GSS-API contexts and credentials
> can have expirations, and it is not entirely unreasonable for a context
> to have expiration longer than the credentials used to expire it.  IMHO
> it is necessary to point this out and to recommend that an rxgk token,
> as a derived credential, must take into account the lifetime of the
> underlying _credential_ and not just that of the context.
>
>
> Finally, it may be desirable to apply "connection" semantics to an Rx
> connection, such that an "expired" token may continue to be used to
> protect an already-established connection.  However, this must be
> optional at best, should not be enabled by default, and in any case may
> turn out to be too difficult to implement, given the stateless nature of
> Rx server connections.

It would be a nice feature to have connection semantics on connections, 
but I share the sentiment that it may be too difficult to implement.  We 
shall see.  I'm not sure I see the argument for "optional at best, not 
enabled by default", though.

-Ben