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 _______________________________________________ AFS3-standardization mailing list [email protected] http://lists.openafs.org/mailman/listinfo/afs3-standardization
