Re: why is SA lifetime kilobyte limit disabled in racoon?

[Steven Bellovin <smb%cs.columbia.edu@localhost>]

On May 23, 2011, at 1:17 54PM, Matthias Drochner wrote:

> 
> smb%cs.columbia.edu@localhost said:
>> In other words, a simple counter suffices.  Appendix B of the NIST
>> standard (Special Publication 800-38A) says the same thing.
> 
> OK, thanks... So we'd need to extend the framework to be able to
> choose a per-SA IV generation mechanism, and a place to store
> its per-SA context... I'll try to get something coordinated
> with the other BSDs. Someone alreading reading this???
> 
> A concern would be whether a simple counter leaks
> too much meta information for the paranoid.

Sure.

> At least it
> would be a help to fingerprint the OS or estimate uptime.

Depends on how you pick the starting point.

> (One can ask why, if a simple counter is good enough,
> the authors of the specification didn't just make a
> requirement of this. Then at least the fingerprinting
> concern wouldn't arise.)

They didn't require it because that's overspecifying things --
they want to allow the paranoid to do things differently.  The
cryptographic security property required is non-repetition
during the life of the key; any scheme that achieves that is
acceptable.  What you actually use will depend on other threat
model issues, ones that are outside of the scope of the standard.
It specifically says that a counter or an LFSR are acceptable;
the former is particularly important to say in the standard because
there are other contexts -- for example, CBC IVs -- where counters
are not acceptable.

But you've given another reason why they don't specify it: having
one counter per system, rather than one per SA, is perfectly acceptable
if you rekey at the right time.  What is the right time?  Well, far
longer than the life of the system or (most likely) our civilization....
The counter wraps -- and requires rekeying -- after 2^64 packets.  Let's
assume UDP in transport mode, which has a header size of 64 bits, and
hence would require one AES-CTR operation.  We also have to add 16 bits,
for the padding length and next protocol. (More likely, it's 128,  given 
padding, etc., but let's be really generous.)  We thus have to rekey after
no more than 2^64*80 bits.  At 10G bps, that's 147,573,952,589, or about
4700 years.  Divide that by the number of 10G bps interfaces on your
box...  (A better reason to have one counter per SA is to avoid lock
contention, I suspect, but that's also an implementation issue.)

> Or would it be a good idea to obfuscate the counter,
> eg using some random bits and a 64-bit block cipher?
> 
That's a lot more code or silicon.



                --Steve Bellovin, https://www.cs.columbia.edu/~smb