Re: [tsvwg] Updated draft LS to 3GPP regarding SCTP-AUTH and DTLS

["Black, David" <[e-mail]>]

Edits inline (need to view as HTML), mostly editorial cleanup.

Thanks, --David

From: tsvwg <[e-mail]> On Behalf Of Magnus Westerlund
Sent: Tuesday, November 29, 2022 4:40 AM
To: tsvwg IETF list
Cc: Michael Tuexen
Subject: [tsvwg] Updated draft LS to 3GPP regarding SCTP-AUTH and DTLS


[EXTERNAL EMAIL]
Hi,

I have now updated the draft text for the LS. So please review and provide any feedback.

/Magnus Westerlund


Subject: Security concerns with SCTP-AUTH and impact on progress of DTLS over SCTP
From: TSVWG
To Group: 3GPP RAN3, 3GPP SA3
To Contact: <[e-mail]<mailto:[e-mail]>>

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) was were found, as well as 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.
  *   Secondly,: 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 that 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 needs to have acceptable values acceptable to for 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, what although the impact of this may have is normally usually limited as because SCTP-AUTH prevents forging of those chunks that could have significant effects. However, it is uncertain what implementation-specific impacts on a specific implementation would be generated by replay of chunks out of its their original state context can result in. The SACK chunk replay can have significant effect after the TSN has wrapped as a replay can could (if timed correctly) move the cumulative ACK TSN forward for a sender and potentially result in that the receiver waiting for a missing a data chunk that it will never receive, it thus 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 currently acceptable 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 then 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 enough rekeying of SCTP-AUTH is performed occurring, 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 it depends on DTLS rekeying frequency determines whether if this that old DTLS record will be accepted as new user message. If a successfully replayed's data includes part of a DTLS record, then it is expected to fail 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 i.e., attacking the availability of the SCTP association.

We note that these attacks will require the attacker to have the capability of capturinge packets on the path between the endpoints, as well as sending packets with forged source addresses that reach the targeted endpoint, or alternatively also 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 the any SCTP-AUTH key has been 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 satisfactory mitigate 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 observation about replay potential 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 these, there will be additional delay before an updated DTLS over SCTP specification will be done. It's currently uncertain how long it this will take, but it will likely take until at least to the later part of 2023 before a complete solution can would be available.

References:
[1] https://datatracker.ietf.org/liaison/1744/ [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/liaison/1744/__;!!LpKI!ifnHIpwjFdIwpb8b_BCtibRre955cmxvDVnJAZgG9bf5mk0OIdGsVs9qMe9jfK8verHxj3_R8BRBeUAGTX-2MqECeRgy42Ht$>
[2] https://datatracker.ietf.org/doc/draft-ietf-tsvwg-dtls-over-sctp-bis/ [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/doc/draft-ietf-tsvwg-dtls-over-sctp-bis/__;!!LpKI!ifnHIpwjFdIwpb8b_BCtibRre955cmxvDVnJAZgG9bf5mk0OIdGsVs9qMe9jfK8verHxj3_R8BRBeUAGTX-2MqECecmPlCgp$>
[3] https://datatracker.ietf.org/meeting/115/materials/slides-115-tsvwg-sctp-auth-security-issues-00 [datatracker.ietf.org]<https://urldefense.com/v3/__https:/datatracker.ietf.org/meeting/115/materials/slides-115-tsvwg-sctp-auth-security-issues-00__;!!LpKI!ifnHIpwjFdIwpb8b_BCtibRre955cmxvDVnJAZgG9bf5mk0OIdGsVs9qMe9jfK8verHxj3_R8BRBeUAGTX-2MqECeXOGQ4h4$>