Subject: [Capwap] to rekey or not to rekey - that is the question...

From: "Scott G. Kelly" <[email-masked]>
Date: Wed, 15 Nov 2006 16:30:14 -0800 (GMT-08:00)

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.

Does anyone object to this?

--Scott

 *anyone who can get hold of active keys must have access to live memory; if they have this, they can also see the unprotected data as it goes by. If someone records for a long time, then they would be able to grab the keys and apply them without the added risk of detection they might face if they left memory probes attached the entire time. This is a minor added risk we face if we remove rekeying support, but if you are deploying in a high-risk scenario such as this, you can mitigate this threat by simply periodically terminating and re-establishing the secure association.

_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

Archives: http://lists.frascone.com/pipermail/capwap

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Sat, 18 Nov 2006 13:51:59 -0800

By all means.... out goes 3DES - and the complexity associated with DTLS
rekeying.

Thanks for your help on this, Scott.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems

> -----Original Message-----
> From: Scott G. Kelly [mailto:[email-masked]] 
> Sent: Wednesday, November 15, 2006 4:30 PM
> To: capwap
> Subject: [Capwap] to rekey or not to rekey - that is the question...
> 
> 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.
> 
>  *anyone who can get hold of active keys must have access to 
> live memory; if they have this, they can also see the 
> unprotected data as it goes by. If someone records for a long 
> time, then they would be able to grab the keys and apply them 
> without the added risk of detection they might face if they 
> left memory probes attached the entire time. This is a minor 
> added risk we face if we remove rekeying support, but if you 
> are deploying in a high-risk scenario such as this, you can 
> mitigate this threat by simply periodically terminating and 
> re-establishing the secure association.
>

---

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 22 Nov 2006 12:07:29 -0800

Issue 228 has been created.

Pat Calhoun

> From: Pat Calhoun (pacalhou) 
> Sent: Saturday, November 18, 2006 1:52 PM
> To: Scott G. Kelly; capwap
> Subject: Re: [Capwap] to rekey or not to rekey - that is the 
> question...
> 
> By all means.... out goes 3DES - and the complexity 
> associated with DTLS rekeying.
> 
> > 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.
> > 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 
> 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.
> > 
> >  *anyone who can get hold of active keys must have access to live 
> > memory; if they have this, they can also see the 
> unprotected data as 
> > it goes by. If someone records for a long time, then they would be 
> > able to grab the keys and apply them without the added risk of 
> > detection they might face if they left memory probes attached the 
> > entire time. This is a minor added risk we face if we 
> remove rekeying 
> > support, but if you are deploying in a high-risk scenario such as 
> > this, you can mitigate this threat by simply periodically 
> terminating 
> > and re-establishing the secure association.
> >