RFC Errata


Errata Search

 
Source of RFC  
Summary Table Full Records

Found 1 record.

Status: Reported (1)

RFC 6083, "Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)", January 2011

Source of RFC: tsvwg (tsv)

Errata ID: 5744
Status: Reported
Type: Technical
Publication Format(s) : TEXT

Reported By: Sidhartha Pant
Date Reported: 2019-05-30

Section 4.8 says:

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.

It should say:

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.

Report New Errata