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

[Andrew Deason]

On Thu, 25 Oct 2012 09:58:03 -0400 (EDT)
Benjamin Kaduk <kaduk@MIT.EDU> wrote:

> Probably the biggest issue which is unaddressed is that of key
> rollover.  We use the 16-bit "checksum" field of the RX header to
> store the key number, and section 8.2 ("Rekeying") currently specifies
> that when that value would overflow, the connection must be
> terminated.  Andrew Deason asked (April 2012) whether this is
> necessary, given that we could roll over the 16-bit field and still be
> confident about what key is in use.  "We can be off by one or two, but
> we cannot be thousands off." Hmm, Simon replied to that with some
> estimates of how much data can be safely passed through a single AES
> key, and seemed to think that rollover would be okay to add.  I don't
> see any other replies to that issue, so maybe it is less large than it
> first seemed, and we should just add the rollover provision.

My impression of this is that there's no downside to allowing it to
rollover, so regardless of how likely it is for exhaustion to be an
issue... I mean, just allow for rollover and the issue is definitely
done.

> 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.

> (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.

-- 
Andrew Deason
adeason@sinenomine.net