Skip to main content

Liaison statement
Updated LS to 3GPP regarding SCTP-AUTH and DTLS

Additional information about IETF liaison relationships is available on the IETF webpage and the Internet Architecture Board liaison webpage.
State Posted
Submitted Date 2022-12-19
From Group tsvwg
From Contact Gorry Fairhurst
To Group 3GPP
To Contacts Lionel Morand <lionel.morand@orange.com>
Susanna Kooistra <3GPPLiaison@etsi.org>
Cc Martin Duke <martin.h.duke@gmail.com>
Zaheduzzaman Sarker <Zaheduzzaman.Sarker@ericsson.com>
David Black <david.black@dell.com>
Transport Area Working Group Discussion List <tsvwg@ietf.org>
Gonzalo Camarillo <gonzalo.camarillo@ericsson.com>
Marten Seemann <martenseemann@gmail.com>
Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Response Contact Gorry Fairhurst <gorry@erg.abdn.ac.uk>
David Black <david.black@dell.com>
Marten Seemann <martenseemann@gmail.com>
Technical Contact magnus.westerlund@ericsson.com
Purpose For information
Attachments (None)
Liaisons referring to this one Reply LS on SCTP-AUTH and DTLS
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 SCTP combined with
SCTP-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]