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