Subject: [Capwap] lwapp-dtls: state machine question 7

From: Scott G Kelly <[email-masked]>
Date: Mon, 13 Feb 2006 06:55:27 -0800

>  Run to DTLS-Rekey (x): This state is used to initiate a new DTLS
>    handshake.  Either the WTP or AC may initiate the state transition.
>    It is important to note that this might more accurately be termed a
>    "meta-state", as the DTLS re-handshake is transparent to the LWAPP
>    protocol, and may even be interpersed with other LWAPP control
>    messages.
> 
>       WTP: The WTP enters this state when either (1) a rekey is
>       required, or (2) the AC initiates a DTLS handshake.
> 
>       AC: The AC enters this state when either (1) a rekey is required,
>       or (2) the WTP initiates a DTLS handshake.
> [NCW] Please elaborate on the rekey protocol used in DTLS as it is not
 > explicitly described in the draft-rescorla-dtls-05.txt draft.  Also,
 > there are security implications in key synchronization and other LWAPP
 > traffic during this key exchange as this draft is allowing it to happen
 >“interspersed”  in LWAPP.  I am assuming that by the use of the epoch,
 > the system may define a replay window by which more than one key can
 >be live to allow for the rekeys to work.  However, security considerations
 > must be described to better analyze the security implications for this
 > application.

DTLS uses the standard tls rehandshake - to avoid confusion, we should 
use that term (rather than rekey) going forward. This is fully described 
in the TLS 1.0 RFC. Regarding your other comments, Eric summed this up 
pretty well in an email to me:

The rekey protocol is of course just TLS rehandshaking, so
the reference shold be to HelloRequest and the sending of a new
ClientHello during an existing connection. There's no concern
about multiple keys co-existing at once. As Nancy says, that's
what the epoch is for.

How about:

      "DTLS data may continue to flow while a new handshake is
      being performed. Because packets may be reordered, records
      encrypted under the new cipher suite may be received before
      one side receives the ChangeCipherSpec from the other side.
      The epoch value in the DTLS record header allows the data
      from the two associations/cryptographic states to be
      distinguished. Implementations SHOULD retain the state
      for the old association until it is likely that all old
      records have been received or dropped, e.g., for the
      maximum packet lifetime. If the state is dropped too early,
      the only effect will be that some data is lost, which is
      a condition that systems running over unreliable protocols
      need to consider in any case.

      Because the new handshake is performed over the existing
      DTLS association, both sides can be confident that the
      handshake was properly initiated and was not tampered
      with. All data is protected under either the old or new
      keys--and these can be distinguished by both the epoch and
      the MAC verification. Thus, there is no period during which
      data is unprotected."

-----------------
Comments?

Scott

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

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