[AFS3-std] Re: rxgk token expiry

[Jeffrey Hutzelman]

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>



> 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.

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.

-- Jeff