rxgk CombineTokens and enctypes (was Re: [AFS3-std] Re: afs3-rxgk-updates for 03)

[Benjamin Kaduk]

On Fri, 2 Nov 2012, Jeffrey Hutzelman wrote:

> Benjamin Kaduk <kaduk@mit.edu> 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