[AFS3-std] Re: afs3-rxgk-updates for 03

[Jeffrey Hutzelman]

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.


> > commit c23fc51c268fefc460b224a12b63cd9a9672b538
> > Author: Ben Kaduk <kaduk@mit.edu>
> > Date:   Wed Oct 24 23:21:29 2012 -0400
> > 
> >     Describe the GSSNegotiate errorcode field
> 
> I wasn't quite sure on what kind of errors are expected here. If they
> are what you wrote in this commit, then I think it makes sense to make
> this application-specific, and in rxgk-afs we specify a registry to
> specify values (or if we want to keep it implementation-private or
> something, that's an option, too).
> 
> But if this is intended to contain GSS error codes... aren't those
> standard? (and don't we need more than one 4-byte int for that?)

GSS-API major status codes are standardized at the abstract API layer as
integers, but without specific values.  The actual integer values used
depend on the language bindings; for C they are specified in RFC2744,
but for other programming languages the values might be different.

GSS-API minor status codes are not standardized; they are specific to
the mechanism and implementation.

So, you can't depend on doing anything programmatic with GSS-API status
codes you receive from a peer.  However, it turns out that in practice,
the status codes (or better yet, the set of status strings returned by
GSS_Display_status) can be very useful in troubleshooting.


> > commit 13a2d01b722969da997f1878ad176991fb0ffabc
> > Author: Ben Kaduk <kaduk@mit.edu>
> > Date:   Wed Oct 24 23:26:49 2012 -0400
> > 
> >     Clarify token expiry
> 
> For krb5-based tokens, does this have any relevance for renewable
> tickets? That is, if our expiration time is in 10 hours, but we are
> renewable for 7 days, we want this field to specify the 'expiration
> time' in 7 days from now, not 10 hours, correct? Or does that just
> result in an entirely new connection because the token is effectively
> entirely new? (I feel like this is obvious, but after reading this text
> for a while I tend to get confused easily... :)

No, the token has to expire in 10 hours, when the ticket does.  The
renewable lifetime of a ticket only tells you for how long the KDC will
let you get a new ticket by presenting the old one to the TGS.


> Also, should the combined token enctype really be set to the minimum of
> the input tokens? Does the order of enctypes based on integer value
> really mean anything? (should this maybe be "most preferable" enctype
> based on the input enctypes, or something?)

Yeah, I'm not sure what "minimum" means here.  However, note that the
combine-tokens operation is _not_ commutative; the order of the inputs
matters.  Since we will be generating a new key anyway, the right answer
is probably to have the client send a list of supported enctypes and
have the server issuing the combined token select a suitable one.

If that's too much of a change for people, then you could also simply
assert that the enctype used is that from a particular input token.  In
that case, it needs to be the token that, in the case of an AFS cache
manager combining tokens with a user, works out to be the token that
belongs to the CM (i.e. the one the user doesn't control).


-- Jeff