Capwap Mailing List: Re: Issue 37: Key Rollover issue

[Scott G. Kelly (s.kelly]

I think Sam was referring to certificate-related key pairs, not session keys.

-----Original Message-----
>From: "Pat Calhoun (pacalhou)" <pcalhoun [at] cisco.com>
>Sent: Dec 21, 2007 11:34 AM
>To: capwap [at] frascone.com
>Cc: Sam Hartman <hartmans-ietf [at] mit.edu>
>Subject: [Capwap] Issue 37: Key Rollover issue
>
>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.
>_________________________________________________________________
>To unsubscribe or modify your subscription options, please visit:
>http://lists.frascone.com/mailman/listinfo/capwap
>
>Archives: http://lists.frascone.com/pipermail/capwap