[AFS3-std] Re: Reviving draft-wilkinson-afs3-rxgk

[Benjamin Kaduk]

[Going through the old mail that snuck through and didn't get dealt 
with...]

On Mon, 29 Oct 2012, Andrew Deason wrote:

> On Thu, 25 Oct 2012 09:58:03 -0400 (EDT)
> Benjamin Kaduk <kaduk@MIT.EDU> wrote:
>
>> The next biggest issue I see is that in quite a number of places, we
>> specify that a random value (or nonce) should be used.  Sometimes we
>> specify a length, sometimes not, but we do a bad job of justifying
>> what a reasonable length is, or what level of randomness/entropic
>> quality is necessary.  (E.g., how long should the client and server
>> nonces that are used to generate K0 be?  Why are 20 octets enough for
>> the RX challenge/response?) I will do more research on this front, but
>> references and comments are welcome.
>
> This isn't my area, so I don't have anything concrete, but using about
> UUID-sized nonces seems pretty common. Whether that is using UUIDs or
> not, or securely or not, I haven't seen anything criticizing the length
> specifically. I don't see anything formally giving recommendations in
> this area, but rfc 2617 gives an example with a 17-byte nonce, though
> that was over 10 years ago. 20 bytes doesn't seem out of place.
>
> Some justification/guidance would be good, though, yes.

I added some SHOULD statements about the client/server nonce sizes for key 
negotiation, as well as a security considerations section with some 
reasoning behind those recommendations.

>> (3) Do we want to give upper bounds on the length of various opaques?
>> (Are there security considerations to allowing these objects to grow
>> to large sizes?)
>
> It can be a DoS depending on where in the protocol the opaque is (or at
> least makes such an attack easier).  Implementations can of course
> refuse huge payloads given to them, but with the current xdr decoder you
> would have to allocate space for the whole blob before you can look at
> it. That could be improved, but it helps to have a definite agreed-on
> upper bound, to ensure an implementation always bails out early before
> it tries to read and allocate e.g. gigabytes or terabytes of data. I
> think we should provide upper limits on these even if they're fairly
> large, especially if they're for an unauthenticated context.

I went through and put limits on most things (chosen arbitrarily).  Most 
notably is the absence of a limit on the RXGK_Data typedef -- since it 
will be easiest to make this be OpenAFS's rx_opaque type in practice, a 
limit for RXGK_Data should probably be coordinated with a limit there.

Of course, RXGK_Data is used all over the place to pass around tokens, 
encrypted blobs, and such, so it really should have a limit in some form.

-Ben