Subject: [Capwap] Proposed resolution for issue 228

From: "Pat Calhoun (pacalhou)" <[email-masked]>
Date: Wed, 22 Nov 2006 17:33:09 -0800

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.

Pat Calhoun
CTO, Wireless Networking Business Unit
Cisco Systems
_________________________________________________________________
To unsubscribe or modify your subscription options, please visit:
http://lists.frascone.com/mailman/listinfo/capwap

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