[tsvwg] New Liaison Statement, "Updated LS to 3GPP regarding SCTP-AUTH and DTLS"

[Liaison Statement Management Tool <[e-mail]>]

Title: Updated LS to 3GPP regarding SCTP-AUTH and DTLS
Submission Date: 2022-12-19
URL of the IETF Web page: https://datatracker.ietf.org/liaison/1806/

From: Gorry Fairhurst <[e-mail]>
To: Lionel Morand <[e-mail]>,Susanna Kooistra <[e-mail]>
Cc: Martin Duke <[e-mail]>,Zaheduzzaman Sarker <[e-mail]>,David Black <[e-mail]>,Transport Area Working Group Discussion List <[e-mail]>,Gonzalo Camarillo <[e-mail]>,Marten Seemann <[e-mail]>,Gorry Fairhurst <[e-mail]>
Response Contacts: Gorry Fairhurst <[e-mail]>,David Black <[e-mail]>,Marten Seemann <[e-mail]>
Technical Contacts: [e-mail]
Purpose: For information

Body: The IETF Transport Area Working Group (TSVWG) has been working on an updated specification for DTLS over SCTP (RFC6083) that removes the user message size limitation as previously acknowledged in the earlier liaison statement [1] to 3GPP RAN3. As part of this work security issues with SCTP-AUTH (RFC 4895) were found, along with a better understanding of the actual security properties provided by SCTP-AUTH. These impact DTLS over SCTP, because both RFC 6083 and the current working draft [2] for an updated solution rely on SCTP-AUTH. The security issues identified in SCTP-AUTH can be summarized as:

• First: packets from host A can be reflected by an attacker back to host A to make it believe that these packets are coming from its SCTP peer (B). Thus, reflection of DATA chunk can be accomplished if the SCTP transport sequence number (TSN) and Stream Sequence Number (SSN) can be matched to an acceptable range in host A. • Second: its current key provisioning can result in the same key being used for multiple authentication algorithms. This situation can theoretically be created by an attacker capable of rewriting the INIT or INIT-ACK AUTH chunk to change the preference order, and could result in HMAC-SHA-1 and HMAC-SHA-2 being used with the same key.

A better understanding of the replay protection that SCPT combined with SCPT-AUTH provides and its interaction with DTLS over SCTP has also been realized. SCTP-AUTH does not provide better replay protection than what SCTP itself provides unless additional measures are taken. This means that replay of DATA chunks may be possible after 2^32 DATA chunks have been sent and the TSN has wrapped. To be accepted by the endpoint the TSN and SSN would need to have values acceptable to the receiver. For other chunk types with sequence numbers, similar risks exist if their sequence numbers are wrapped. However, that is fairly unlikely due to these chunk types having a low frequency of usage. Chunk types without sequence numbers can be replayed at any time, although the impact of this is usually limited because SCTP-AUTH prevents forging of those chunks that could have significant effects. However, it is uncertain what implementation-specific impacts would be generated by replay of chunks out of their original state context. The SACK chunk replay can have significant effect after the TSN has wrapped as a replay could (if timed correctly) move the cumulative ACK TSN forward for a sender and potentially result in the receiver waiting for a missing a data chunk that it will never receive, dead locking the SCTP association. The resulting impact on DTLS over SCTP is the following:

1. Reflection of a DATA chunk that matches the currently acceptable TSN and SSN can result in delivery of the data in the DATA chunk to DTLS over SCTP. This data will be either a complete DTLS record or be inserted as part of a DTLS record. This injection is expected to be detected by DTLS integrity protection as DTLS keying is directional, resulting in the whole DTLS record being discarded. Such a failure is expected to result in an SCTP association termination as it represents a non-recoverable transport protocol failure.
2. Unless sufficiently frequent rekeying of SCTP-AUTH is performed, DATA chunks sent from A to B (and/or from B to A) can be replayed to B (or A) after at least 2^32 DATA chunks have been sent. The same constraint on matching the currently acceptable TSN and SSN applies for a successful replay. If the data in the DATA chunk is a complete DTLS record, then DTLS rekeying frequency determines whether that old DTLS record will be accepted as new user message. If successfully replayed data includes part of a DTLS record, then the DTLS integrity check is expected to fail and thus result in SCTP association termination.
3. Reflection or replay of SCTP control chunks could result in termination or dead lock of the SCTP association, thereby attacking the availability of the SCTP association.

We note that these attacks require the attacker to have the capability of capturing packets on the path between the endpoints, as well as sending packets with forged source addresses that reach the targeted endpoint, or alternatively to send packets from an on-path location. For more details on these security issues, please review the presentation to the TSVWG [3]. An identified mitigation that protects against the replay of DATA and SACK chunks is to ensure that any SCTP-AUTH key is replaced and discarded before 2^32 TSN values have been used since the first SCTP packet protected by this key. Note that this mitigation does not appear to be effective against the reflection attack.

TSVWG is willing to start working on addressing these security issues in SCTP-AUTH immediately. However, it is unclear how long it will take to finalize a resolution that addresses these issues. DTLS over SCTP [2] will also have to be updated to address the resulting replay resistance properties of SCTP-AUTH.

We wanted to inform SA3 of these security issues and the potential for replay as they impact the security properties of the usage of RFC 6083 that is already defined in “Security architecture and procedures for 5G system” 3GPP TS 33.501 Rel 16 and forward. We want to inform RAN3 that, due to the discovery of the security issues and the need to address them, there will be additional delay before an updated DTLS over SCTP specification will be done. It’s currently uncertain how long this will take, but it will likely take until at least to the later part of 2023 before a complete solution would be available.

References:
[1] https://datatracker.ietf.org/liaison/1744/ [datatracker.ietf.org]
[2] https://datatracker.ietf.org/doc/draft-ietf-tsvwg-dtls-over-sctp-bis/ [datatracker.ietf.org]
[3] https://datatracker.ietf.org/meeting/115/materials/slides-115-tsvwg-sctp-auth-security-issues-00 [datatracker.ietf.org]
Attachments:

No document has been attached