Liaison statement
LS on DTLS for SCTP Progress Report
Additional information about IETF liaison relationships is available on the
IETF webpage
and the
Internet Architecture Board liaison webpage.
| State | Posted |
|---|---|
| Submitted Date | 2025-11-11 |
| From Group | tsvwg |
| From Contact | Charles Eckel <eckelcu@cisco.com> |
| To Groups | 3GPP-TSG-RAN-WG3, 3GPP-TSG-SA-WG3 |
| To Contacts | 3GPP Liaisons Coordinator <3GPPLiaison@etsi.org> Peter Schmitt <Peter.Schmitt@huawei.com> |
| Cc | Mike Bishop <mbishop@evequefou.be> Gorry Fairhurst <gorry@erg.abdn.ac.uk> Zaheduzzaman Sarker <zahed.sarker.ietf@gmail.com> Charles Eckel <eckelcu@cisco.com> Transport and Services Working Group Discussion List <tsvwg@ietf.org> Martin Duke <martin.h.duke@gmail.com> |
| Response Contact | Martin Duke <martin.h.duke@gmail.com> Zaheduzzaman Sarker <zahed.sarker.ietf@gmail.com> |
| Purpose | For information |
| Attachments | LS on DTLS for SCTP Progress Report |
| Liaisons referred by this one |
Reply LS on DTLS for SCTP
Reply LS on DTLS for SCTP next steps and request for input |
| Body |
1. Description IETF’s Transport Working Group (TSVWG) would like to inform 3GPP’s RAN3 and SA3 WGs about its progress on defining a DTLS based security solution for SCTP that has occurred since the previous exchange of liaison statements [1,2,3]. TSVWG has now adopted two new WG items to provide a technical solution to address the maximum message size issue with SCTP and DTLS as observed in [2]. The complete solution consists of two separate components. The first component, which is the core of the complete solution, is called the DTLS Chunk. This component specifies how an SCTP endpoint initiates the negotiation using SCTP parameters and protects its packets using DTLS records using key-contexts that have been provisioned using an API to the SCTP stack. This protects the content of each SCTP packet in its own DTLS record. This results in all application messages as well as SCTP control chunks being encrypted and authenticated. It also ensures that there is no limit on application message sizes as they are fragmented by the regular SCTP mechanism, thereby supporting unlimited message size. This component is defined in the TSVWG adopted internet draft “Stream Control Transmission Protocol (SCTP) DTLS Chunk” [4]. The draft also defines certain requirements on key-management to prevent down-grade attacks. The second component of the complete solution is a key-management specification that can provision the DTLS chunk (i.e., the first component) with keys. Such a key-management is defined as functionality on top of the SCTP association, using an API defined in the DTLS chunk [4] to provision keys to secure the communication. TSVWG has adopted an Internet draft defining such a key-management titled: “Using Datagram Transport Layer Security (DTLS) for Key Management for the Stream Control Transmission Protocol (SCTP) DTLS Chunk” [5]. This key-management is dependent on new TLS 1.3 [6] functionality - the extended key-update [7] being defined by the TLS WG. It will support long lived sessions through ephemeral rekeying ensuring forward secrecy and also supports SCTP Association restart. Splitting the solution into two components (i.e., the DTLS chunk and the key-management) allows for alternative key-management to be specified if desired to achieve certain properties. There exists an individual internet draft detailing an alternative key-management [8], which can be seen as a proof that this divided concept works. TSVWG aims to have the DTLS chunk, the first component, published as RFC before the end of 2026. The WG key-management specification [5], the second component, has dependency on the TLS extended key-update mechanism [7], hence work needs to be done in both TSVWG and TLS working groups. TSVWG would like to inform 3GPP RAN3, following their previous observations in [2], that this technical solution does not limit the maximum size of application protocol messages. TSVWG plans to inform 3GPP RAN3 and SA3 when each of the components have been requested to be published. TSVWG welcomes any feedback on its work items. 2. Upcoming Meeting IETF 125 14-20 March 2026, Shenzhen, China IETF 126 18-24 July 2026, Vienna, Austria 3. References [1] TSVWG LS to RAN3 and SA3: DTLS for SCTP next steps and request for input, https://datatracker.ietf.org/liaison/1851/ [2] R3-234497 - Reply LS on DTLS for SCTP next steps and request for input, https://datatracker.ietf.org/liaison/1858/ [3] S3-234160 - Reply LS on DTLS for SCTP, https://datatracker.ietf.org/liaison/1854/ [4] Stream Control Transmission Protocol (SCTP) DTLS Chunk, https://datatracker.ietf.org/doc/draft-ietf-tsvwg-sctp-dtls-chunk/ [5] Using Datagram Transport Layer Security (DTLS) for Key Management for the Stream Control Transmission Protocol (SCTP) DTLS Chunk, https://datatracker.ietf.org/doc/draft-ietf-tsvwg-dtls-chunk-key-management/ [6] The Transport Layer Security (TLS) Protocol Version 1.3, RFC 8446, Aug 2018, https://datatracker.ietf.org/doc/rfc8446/ [7] Extended Key Update for Transport Layer Security (TLS) 1.3, https://datatracker.ietf.org/doc/draft-ietf-tls-extended-key-update/ [8] Datagram Transport Layer Security (DTLS) based key-management of the Stream Control Transmission Protocol (SCTP) DTLS Chunk, https://datatracker.ietf.org/doc/draft-westerlund-tsvwg-sctp-dtls-handshake/ |