Fixed in draft-ietf-capwap-protocol-specification-03.txt

Closing given no comments since 11/22/06

All,

As per the discussion in San Diego, and the e-mail sent by Scott, it appears 
that we have agreement to eliminate the complexity of DTLS rekey from the 
current CAPWAP draft. The following text describes the proposed changes (which 
is mostly removing text, other than a new section in the security 
considerations):


2.3.  CAPWAP State Machine Definition
[...]

            /-------------<----------------+--------------------\
            v                              |d                   |
         +------+  b+-----------+    +----------+               |
         | Idle |-->| Discovery |--->|  Sulking |               |
         +------+ a +-----------+ c  +----------+               |
          ^   |aa    ^ |e            /----------------------\   |
          |   V     f| v            k|                      |   |
       h +--------------+  +------------+ i +------------+j |   |
      /--|    Join      |->|  Configure |-->| Image Data |  |   |
      |  +--------------+ g+------------+   +------------+  |   |
      |   "c1,  ^  ^   ^        m|            ^    |l       |   |
      |   "c4   "  "   "         |    /-------/    |   /----/   |
      |   "     "  "   "         V    |s           v   V        |
      |   "     "  "   "   +------------+ o+------------+       |
      |   "     "  "   "   |    Run     |->|    Reset   |-------/
      |   "     "  "   "  n+------------+  +------------+   p
      |   "     "  "   "        "c2  ^       ^  c3"   ^
      \---"-----"--"---"--------"----"-------/    "   "     CAPWAP
   ~~~~~~~"~~~~~"~~"~~~"~~~~~~~~"~~~~"~~~~~~~~~~~~"~~~"~~~~~~~~~~~~
          "     "  "   "        "    "            "   "      DTLS
          v     "  "n2 \"""""\  "    "            v   "n6,n7
   /-->+------+ " W+------+  "  "    "      +------------+
   | /-| Idle | " C| Auth |--"~-"----"----->|  Shutdown  |-------\P
   | | +------+ "  +------+V "  "    " /--->|            |<----\ |
   | |X     Z|  "   ^  U|    "  " n4 " |    +------------+     | |
   | |       |  "   |   |    "  " n5," |                       | |
   | |       v  "n1 |Y  |  n3"  v  n8" |R                      | |
   | |      +--------+  |  +------------+                      | |
   | |      |  Init  |  \->|    Run     |                      | | <<= NOTE 
REMOVAL OF REKEY STATE
   | |      +--------+     |            |                      | |
   | |                     +------------+                      | |
   | \---------------------------------------------------------/ |
   \-------------------------------------------------------------/


                 Figure 3: CAPWAP Integrated State Machine

[...]

2.3.2.  CAPWAP to DTLS Commands
[...]
   o  c2: DTLSRehandshake is sent to the DTLS module to cause initiation
      of a rehandshake (DTLS rekey).

[...]

2.3.4.  DTLS State Transitions

[...]

REMOVE THE FOLLOWING TEXT:

   Run to Rekey (T)  This state transition occurs when a DTLS
      rehandshake is in progress; this is initiated when either (a) the
      DTLS state machine receives the DTLSRehandshake command from
      CAPWAP, or (b) a DTLS rehandshake message is received from the
      peer..

      WTP:  If CAPWAP issued a DTLSRehandshake command, initiate
         rehandshake with the peer; note that control traffic may
         continue to flow using existing secure association.  If the
         rehandshake is initiated by the peer, send a DTLSRehandshake
         notification to CAPWAP.

      AC:  If CAPWAP issued a DTLSRehandshake command, initiate
         rehandshake with the peer; note that control traffic may
         continue to flow using existing secure association.  If the
         rehandshake is initiated by the peer, send a DTLSRehandshake
         notification to CAPWAP.

   Rekey to Run (R)  This state transition indicates the successful
      completion of a DTLS rehandshake.

      WTP:  This state transition occurs when the WTP receives the DTLS
         Finished message from the AC, completing the DTLS re-handshake.

      AC:  This state transition occurs when the AC sends a DTLS
         Finished message to the WTP, completing the DTLS re-handshake.

   Rekey to Shutdown (Q)  This state transition indicates the failure of
      the DTLS rekey operation.

      WTP:  This state transition occurs when there is a failure in the
         rehandshake negotiation with the AC.

      AC:  This state transition occurs when there is a failure in the
         rehandshake negotiation with the WTP.
[...]

2.4.3.  DTLS Rehandshake Behavior

REMOVAL OF THIS WHOLE SECTION (and subsections 2.4.3.1, 2.4.3.2, 2.4.3.3 and 
2.4.3.4 )

[...]

2.4.4.1.  Authenticating with Certificates

REMOVAL OF THE FOLLOWING TWO LINES:

   o  TLS_RSA_WITH_AES_128_CBC_SHA

   o  TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA

[...]

2.4.4.2.  Authenticating with Preshared Keys

REMOVAL OF THE FOLLOWING TWO LINES:

   o  TLS_PSK_WITH_3DES_EDE_CBC_SHA

   o  TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA

[...]

12.4 DTLS Rekeying

The current DTLS protocol [9] does not define a rekeying mechanism. However, 
there are a few reasons we might want to periodically refresh cryptographic 
keys, but how frequently depends on a number of factors. People frequently 
cite a need for rekeying in order to minimize the data a cryptanalyst has to 
work with, or to prevent leakage that may occur with block cipher algorithms.

Support for a cryptographic algorithm that has a 64-bit block size suffers 
from the birthday paradox, where one can expect to begin seeing ciphertext 
collisions after about 2^32 blocks have been encrypted, and ciphertext 
collisions leak significant information about the associated plaintext. On a 
busy gigabit network it doesn't take very long to hit the birthday number if 
the 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. 

CAPWAP currently only supports ciphers with an 128-bit block size (e.g., AES), 
which do not have the collision problem.  For minimum sized packets using AES, 
it would take more than 519,428 *years* to start seeing collisions, and for 
maximum-sized packets this only falls to just under 80,000 years. Clearly, 
there is no need for periodic refreshing of the cryptographic keys in this 
case.

Should the CAPWAP protocol decide to make use of a cryptographic algorithm 
that supports 64-bit block sizes in the future, the protocol will need to 
define how a DTLS rekeying mechanism.

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:s.kelly@ix.netcom.com]
> 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.
> 
> 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.
>