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

[Gorry Fairhurst <[e-mail]>]

I haven't see any further updates to the revised LS text. Unless the 
Chairs hear more by noon on Wednesday 7th Dec, we'll plan to ask to move 
this version forward.

Best wishes,
Gorry, Marten, and David
tsvwg co-chairs.

  On 29/11/2022 09:39, Magnus Westerlund wrote:
>
> 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 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 found, as well as 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
>     could result in that HMAC-SHA-1 and HMAC-SHA-2 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 needs to have acceptable 
> values for the receiver. For other chunk types with sequence number 
> similar risk exist if their sequence number are wrapped. However, that 
> is fairly unlikely due to these chunk types low frequency of usage. 
> Chunk types without sequence numbers can be replayed at any time, what 
> impact this may have is normally limited as SCTP-AUTH prevents forging 
> of those that could have significant effect. However, it is uncertain 
> what impact on a specific implementation replay of chunks out of its 
> original state context can result in. The SACK chunk replay can have 
> significant effect after the TSN has wrapped as a replay can if timed 
> correctly move the cumulative ACK TSN forward for a sender and 
> potentially result in that the receiver missing a data chunk 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 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 frequent enough rekeying of SCTP-AUTH is occurring, DATA
>     chunk 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 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 if this old DTLS record
>     will be accepted as new user message. If a successful replay’s
>     data include part of a DTLS record, then it is expected to fail
>     the DTLS integrity check 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, i.e., attacking
>     the availability of the SCTP association.
>
> We note that these attacks will require the attacker to have the 
> capability of capture packets on the path between the endpoints, as 
> well as send packets with forged source address that reach the 
> targeted endpoint, alternatively also 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 
> SCTP-AUTH key has been replaced and discard before 2^32 TSN values 
> have been used since the first SCTP packet protected by this key. Note 
> that this does not appear to satisfactory mitigate 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 replay properties of 
> SCTP-AUTH.
>
> We wanted to inform SA3 of these security issues and 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 these, there will be additional delay 
> before an update DTLS over SCTP specification will be done. It’s 
> currently uncertain how long it will take, but it will likely take at 
> least to the later part of 2023 before a complete solution can be 
> available.
>
> References:
>
> [1] https://datatracker.ietf.org/liaison/1744/
>
> [2] https://datatracker.ietf.org/doc/draft-ietf-tsvwg-dtls-over-sctp-bis/
>
> [3] 
> https://datatracker.ietf.org/meeting/115/materials/slides-115-tsvwg-sctp-auth-security-issues-00
>