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