On Fri, 2 Nov 2012, Jeffrey Hutzelman wrote:
Benjamin Kaduk <[email protected]> wrote:
True. My concern is basically about whether we can pass that other
information in a general-enough fashion to not paint ourselves into a
corner. Attempting to enumerate the "additional information" one gets
along with a token makes me wonder if the enumeration is complete, or
even
can be complete given the possibility of application-specific data.
Well, the token establishment mechanism certainly has a complete picture
of what you get with a token. The only ways in which this operation is
different are those in which we define it to be, by providing an
alternative. We've done that for the key with the PRF, and for
lifetimes with a rule for computing them. We're arguing about whether
Assuming you count expiration as a lifetime, sure.
or how to do so for enctypes and, I think, level.
I hope we are arguing about 'how'....
You don't get "application-specific" data, just what you need to use the
token. If an app wants more, it can use an app-specific operation.
Reviewing the output of GSSNegotiate() again, I think you are right. We
only define these particular pieces of information (enctype, level,
lifetime, bytelife, and expiration) to be server-provided information with
a token (well, and the mic and nonce needed for tamper-resistance and to
produce the key), so relegating other fields to an app-specific operation
should be okay.
-Ben
_______________________________________________
AFS3-standardization mailing list
[email protected]
http://lists.openafs.org/mailman/listinfo/afs3-standardization
