[AFS3-std] Re: rxgk token expiry

[Jeffrey Hutzelman]

On Fri, 2012-11-02 at 16:34 -0400, 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.
> >
> > 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?

Well, if you're volunteering...

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


As has been pointed out, the notion of "connection" isn't really visible
to AFS users, and I think it's best if things that don't look and act
connection-oriented also don't have connection-like security semantics.
That said, this is really about AFS filesystem access, not Rx in
general, so it's probably OK to be connection-oriented by default as
long as applications can specify otherwise.

-- Jeff