rxgk token: encrypted blob or not (was Re: [AFS3-std] Re: afs3-rxgk-updates for 03)

[Benjamin Kaduk]

Sorry for the delayed response; I didn't do much on Monday due to Sandy, 
and we had the Kerberos Conference yesterday and today.

Administratively, I'm going to split the three items Jeff replied to into 
separate threads, as my response to the last one is getting pretty long.

On Mon, 29 Oct 2012, Jeffrey Hutzelman wrote:

> On Mon, 2012-10-29 at 16:57 -0500, Andrew Deason wrote:
>
>>> commit 051c46a6d806e0ce4eab737ff91dc14b34b77375
>>> Author: Ben Kaduk <kaduk@mit.edu>
>>> Date:   Wed Oct 24 17:43:10 2012 -0400
>>>
>>>     The token need not be an encrypted blob
>>
>> I think this text makes the rest of the document a little unclear if the
>> token is not an encrypted blob. I'm not sure if it's worth it to bother,
>> but a sentence or two could be added... something like:
>>
>> For the remainder of this document, we will assume that the token
>> contains an encrypted copy of the user identifier and session key, for
>> concision. Any section referring to token decryption or encryption is
>> still applicable to applications not encrypting data inside tokens. It
>> is assumed that such applications will conceptually "decrypt" a token by
>> looking up the token in a local token table, and will "encrypt" a token
>> by associating the token value with a token table entry in the server.
>
> So, I understand the point here to be that tokens are opaque to anyone
> other than the server(s) for which they are intended.  Thus, their
> internal structure is not specified, and while we certainly anticipate
> an implementation in which blobs are signed, encrypted state, they could
> be session identifiers or similar.  The important thing here is that it
> should be impossible, or at least really hard, for a client to gain
> access by making up a token instead of going through one of the provided
> token-granting mechanisms.  In particular, an _unencrypted_ copy of the
> user identifier and session key would not be OK.

That's my understanding as well (modulo a single service key being shared 
amongst multiple servers).  There are at least four other places in the 
document that refer to "decrypt"ing a token, or a token "containing" a key 
-- it seems like the rest of the document is assuming that the token will 
be an encrypted blob, even though we really only require that it is opaque 
to not-the-intended-server and the intended server can use it as needed. 
It seemed like a smaller change to just make explicit this assumption than 
to introduce clarification at all the other spots in the document where it 
comes up.  Andrew's text is fine with me (with the caveat that we would 
still not refer to the RXGK_SERVER_ENC_TOKEN key usage value if that text 
is used), but I'd also be fine with adding some bit about the 
specification being for the properties of the token, not the particular 
mechanism used (maybe there is a mechanism other than encryption or lookup 
table, who knows).

The important bits about "the token MUST NOT expose the session key on the 
wire", etc., are already in the next paragraph.

-Ben