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