[AFS3-std] Last Call: afs3-rxgk-04, afs3-rxgk-afs-02

[Jeffrey Hutzelman]

On Fri, 2013-04-26 at 13:03 -0400, Benjamin Kaduk wrote:

> Well, this document does not define a token format, so there remains work 
> for any application wishing to use rxgk.

Not necessarily.  rxgk-afs needs to define a token format, because its
tokens are expected to be shared across multiple servers (and services).
For a generic application, this is not the case, and the token format
can be implementation-dependent.  I had sort of assumed from the
beginning that the token format would be private to each rxgk
implementation, and applications don't need to get into it at all.



> > 6. Key Negotiation
> > ------------------
> >
> >>        const RXGK_MAXENCTYPES = 10;
> >
> > Limiting to a maximum of 10 encryption types seems somewhat low, given that this is a hard limit that can't be negotiated around. Each encryption type only takes 4 bytes on the wire, so there doesn't seem to be a resource-based limit here. Given the sprawling proliferation of Kerberos encryption types, I can see somebody, at some point, wanting to use more than 10 here.
> >
> >>        const RXGK_MAXLEVELS = 10;
> >
> > Whilst we only support 3 levels today, again a hard limit of 10 seems low.
> >
> > How about a limit of 255 for each of these?
> 
> I don't mind bumping these to 255; part of the justification for a 
> small-ish limit of 10 is that if the client really does have more options, 
> it can call the negotiation rpc multiple times, iterating through chunks 
> of its list.  We have error values for bad enctype and bad level which 
> would prevent that from becoming an N^2 problem.
> 
> >>       const RXGK_MAXMIC = 16384;
> >
> > By contrast, this seems large. The MIC is going to be the length of the 
> > chosen encryption type's checksum, plus a small amount of header 
> > material. For aes-256, that's a mere 28 octets (16 of CFX token, 12 of 
> > checksum). So, I think we could get away with something smaller here.
> 
> I note that you do not suggest a new value :)
> This is large, it is true.  On the other hand, the goal of putting a limit 
> here is to avoid excessive resource allocation by the rx peer without 
> getting in the way of normal operation ... on the scale of 2**31, it's not 
> very large at all.  Would you want to drop down to, say, 1024, or even 
> smaller?
> 
> >>       typedef opaque RXGK_Data<>;
> > [ ... ]
> >>           RXGK_Data token;
> >
> > Given we're limiting everything else, should we also put some kind of 
> > upper limit on the size of the token? We do need to consider, though, 
> > that a token may contain non-Kerberos identities, and X509 (in 
> > particular) identities can be very large.
> 
> There should probably be a limit of some sort.  It's unclear whether this 
> limit should be different from a hypothetical global default limit on the 
> size of an opaque type (per the thread Andrew started).  (My picture of 
> this is that openafs's rxgen would translate opaque<> into, say, 
> opaque<16k>, but that opaque<1m> given explicitly would still be allowed. 
> Numbers not guaranteed to bear resemblence to reality.)
> 
> If we were to explicitly limit the size of a token (or a generic 
> RXGK_Data, I suppose), what would such a limit be?  If we start talking 
> about X.509 identities, maybe 16k is too small?

Some care is called for here.  We've had issues in the past with limits
on token sizes, so we should try to avoid setting one that is too small.


I think perhaps the right thing here might be to say that the limit is
implementation-defined (or subject to local policy), but MUST NOT be
less than a certain value.



> >>  client_start  The client params structure detailed above.  This
> >>         should remain constant across the negotiation
> >
> > "should" or SHOULD, or even MUST?

"will".  Be descriptive, not prescriptive.


> > 12.3 Nonce Lengths
> > ------------------
> >
> >>  The client_nonce is important for using the MIC of the StartParams
> >>   structure as a defense against man-in-the-middle attacks,
> >
> > I'm not sure what this sentence is trying to say?
> 
> The hypthetical scenario here is where a client gets two tokens using the 
> same kerberos service ticket.  In my thought experiment, an active 
> attacker could change the startparams for the second request to the 
> server, and replace the 'mic' field in RXGK_ClientInfo with the value from 
> the first request.  Oops, but RXGK_ClientInfo is encrypted for 
> transmission, so things would break pretty fast.
> 
> Anyway, since client_nonce is sent in the clear, it is not adding secure 
> randomness.  It does make each request unique.

It allows servers to cache and reject replays, no?