Capwap Mailing List: Issue 37: Key Rollover issue

[Pat Calhoun (pacalhou) (pcalhoun]

Sam,

This is a topic that has already been raised and closed. I am including
part of an e-mail exchange on the list where this was discussed. I can
also point you to
http://www.capwap.org/cgi-bin/roundup.old/CAPWAP/issue228, which is the
old tracker entry where more information can be found.

I would like to close this issue, as it is redundant, but want to make
sure you are ok with it first.

PatC



> At the CAPWAP meeting last week, Pat expressed concern about the 
> complexity introduced by the need for applications to manage their own

> rekeying for DTLS, and he asked if there was some alternative. If you 
> read the current draft text, you'll get a feel for just how complex 
> this is. You have to take into account all the edge cases, e.g. both 
> sides start rekeying at the same time, one side tries but the other 
> side never responds, etc, and then you also have to clearly specify 
> how to transition to the new keys once they are established - 
> synchronization is harder than you might guess.
>  It's a difficult operational problem, and we have years of experience

> with this in IPsec.
> 
> There are a few reasons we might want to periodically refresh 
> cryptographic keys, but how frequently depends on a number of factors.

> If there is high risk that someone will crack open the box and get 
> your active keys, then you might want to rekey frequently to minimize 
> the amount of data they can get access to. Other reasons people 
> frequently cite for rekeying:
> to minimize the data a cryptanalyst has to work with, or to prevent 
> leakage that may occur with block cipher algorithms.
> 
> If we ignore the risk of exposing lots of data to someone who gets 
> hold of active keys*, the primary practical reason we (in CAPWAP) 
> currently need to rekey is because we have specified support for 3DES 
> as one of our cryptographic algorithms. Since 3DES has a 64-bit block 
> size, by the birthday paradox we should expect to begin seeing 
> ciphertext collisions after about 2^32 blocks have been encrypted, and

> ciphertext collisions leak significant information about the 
> associated plaintext (if you want to know why, email me privately and 
> I'll explain).
> 
> As it turns out, on a busy gigabit network it doesn't take very long 
> to hit the birthday number if your block size is 64 bits. If the gigE 
> pipe was stuffed full of minimum-sized DTLS packets, it would take 
> around 59 minutes. If the pipe were instead stuffed full of 
> maximum-sized DTLS packets, it would only take around 5 minutes. Since

> in reality the actual maximum throughput would be something less than 
> 1 gigabit and we would not have it stuffed full all of the time, it 
> would usually take longer than this, but the point is that we expect 
> capwap sessions to be alive *far* longer than this - there is a real 
> risk here.
> 
> Okay, so going back to where we started, if we ignore the threat of 
> actively cracking live keys, we have to rekey only because we're 
> trying to support 3DES. Ciphers with a 128-bit block size (e.g. AES) 
> don't have the collision problem. For minimum sized packets using AES,

> we would expect it to take more than 519,428 *years* to start seeing 
> collisions, and for maximum-sized packets this only falls to just 
> under 80,000 years. Bottom line: if we don't support 3DES (or any 
> other ciphers with less than a 128-bit block size), we don't have this

> problem.
> 
> Charles and I discussed this, and then I checked with Russ Housley, 
> and none of us object to removing support for 3DES (and rekeying), and

> adding language expliaining that if in the future somone wants to 
> support a block cipher having a 64-bit block length, they will need to

> contemplate adding rekeying support at the same time.