RFC Errata
RFC 6083, "Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)", January 2011
Note: This RFC has been updated by RFC 8996
Source of RFC: tsvwg (wit)
Errata ID: 5744
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Sidhartha Pant
Date Reported: 2019-05-30
Held for Document Update by: Martin Duke
Date Held: 2020-04-21
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.