[tsvwg] [Technical Errata Reported] RFC6083 (5744)

[RFC Errata System <[e-mail]>]

The following errata report has been submitted for RFC6083,
"Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata/eid5744

--------------------------------------
Type: Technical
Reported by: Sidhartha Pant <[e-mail]>

Section: 4.8

Original Text
-------------
4.8.  Handling of Endpoint-Pair Shared Secrets

   The endpoint-pair shared secret for Shared Key Identifier 0 is empty
   and MUST be used when establishing a DTLS connection.  Whenever the
   master key changes, a 64-byte shared secret is derived from every
   master secret and provided as a new endpoint-pair shared secret by
   using the exporter described in [RFC5705].  The exporter MUST use the
   label given in Section 5 and no context.  The new Shared Key
   Identifier MUST be the old Shared Key Identifier incremented by 1.
   If the old one is 65535, the new one MUST be 1.

   Before sending the Finished message, the active SCTP-AUTH key MUST be
   switched to the new one.

   Once the corresponding Finished message from the peer has been
   received, the old SCTP-AUTH key SHOULD be removed.

Corrected Text
--------------
4.8.  Handling of Endpoint-Pair Shared Secrets

   The endpoint-pair shared secret for Shared Key Identifier 0 is empty
   and MUST be used when establishing a DTLS connection.  Whenever the
   master key changes, a 64-byte shared secret is derived from every
   master secret and provided as a new endpoint-pair shared secret by
   using the exporter described in [RFC5705].  The exporter MUST use the
   label given in Section 5 and no context.  The new Shared Key
   Identifier MUST be the old Shared Key Identifier incremented by 1.
   If the old one is 65535, the new one MUST be 1.

   Before sending the Finished message, the active SCTP-AUTH key 
   SHOULD be switched to the new one.
   However if the ChangeCipherSpec and Finished messages are sent 
   back to back, there may be a case if Finished message is sent with
   the new key might get dropped by peer, if the new key is not 
   configured yet.
   Hence the sender MAY send the Finished message with Old Key which
   SHOULD be accepted by the peer. 

   Once the corresponding Finished message from the peer has been
   received, the old SCTP-AUTH key SHOULD be removed.

Notes
-----
If the time gap between the ChangeCipherSpec and Finished messages is very less than either the peer may wait to configure the new key received in ChangeCipherSpec and then validate the Finished messges with new key. Alternatively the Sender may choose to send the Finished message with Old key to peer which should still be configured at the peer. Once the peer recevies the Finished message it should accept with Old key. Subsequently the Old key Should be removed.
Hence during this switchover of Key , two keys can be used by both peer nodes.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party  
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6083 (draft-ietf-tsvwg-dtls-for-sctp-06)
--------------------------------------
Title               : Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)
Publication Date    : January 2011
Author(s)           : M. Tuexen, R. Seggelmann, E. Rescorla
Category            : PROPOSED STANDARD
Source              : Transport Area Working Group
Area                : Transport
Stream              : IETF
Verifying Party     : IESG