| Internet-Draft | DTLS for Key Management for DTLS Chunks | July 2025 |
| Tüxen, et al. | Expires 8 January 2026 | [Page] |
This document defines how Datagram Transport Layer Security (DTLS) 1.3 is used to establish keys for securing SCTP using the DTLS Chunk mechanism. It specifies how a DTLS handshake is used to establish the initial security context for an SCTP association and describes procedures for key updates and post-handshake authentication. The goal is to enable authenticated, and confidential communication over SCTP using the DTLS Chunk, leveraging standardized DTLS features for key management and rekeying.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 8 January 2026.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The Stream Control Transmission Protocol (SCTP) is a transport protocol designed to support message-oriented communication with features such as multi-streaming and multi-homing. In many deployments, particularly those telecommunication networks and WebRTC data channels, it is essential to provide confidentiality, integrity, and peer authentication for SCTP traffic.¶
[RFC6083] defines a mechanism for securing SCTP by encapsulating it over DTLS 1.0/1.2, establishing a secure channel between SCTP endpoints. However, with the introduction of DTLS 1.3 [RFC9147], the protocol underwent significant changes, including removal of renegotiation, a new key schedule, and support for post-handshake operations. Without additional description, RFC 6083 cannot be used with DTLS 1.3.¶
Additionally, [I-D.westerlund-tsvwg-sctp-dtls-chunk] defines a new method for secure and confidential transfer for SCTP packets but leaves key management to a separate specification.¶
This document complements [I-D.westerlund-tsvwg-sctp-dtls-chunk] by specifying how DTLS 1.3 is used to derive and manage the cryptographic keys required for use with the DTLS Chunk, addressing key management aspects not covered in that specification. Specifically, it describes:¶
How the DTLS 1.3 handshake establishes the initial security context between SCTP endpoints.¶
How keying material is derived and associated with the SCTP association.¶
How DTLS 1.3 features, such as key updates and post-handshake authentication, are leveraged to support long-lived secure sessions.¶
The goal of this specification is to modernize and extend the approach defined in RFC 6083, aligning it with the architectural and cryptographic changes introduced in DTLS 1.3, while enabling a cleaner and more efficient integration with native SCTP functionality.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document describes how Datagram Transport Layer Security (DTLS) 1.3 is used to establish keys for securing SCTP using the DTLS Chunk as defined in [I-D.westerlund-tsvwg-sctp-dtls-chunk]. This approach combines the performance and encryption flexibility of DTLS Chunks with the integrated key management capabilities of DTLS.¶
The key characteristics of the solution are as follows:¶
Application data is protected using DTLS Chunks.¶
The DTLS handshake is used to establish keying material, algorithms, and parameters for use with DTLS Chunks.¶
DTLS and relevant extensions are used to negotiate cryptographic algorithms and parameters, perform extended key updates, enable larger record sizes, and support post-handshake authentication.¶
All other DTLS record-layer content types are protected using standard DTLS record framing.¶
Application data (except the messages for post handshake authentication) is never transmitted in DTLS record-layer application_data records. Instead, application data is sent via SCTP DATA chunks which are protected by the DTLS Chunk Protection Operator. This operator encapsulates all SCTP chunks into a DTLS Chunk, applying appropriate protection.¶
The figure below illustrates the architecture, highlighting the role of the upper-layer protocol (ULP), which acts as the consumer of SCTP's transport services. The ULP may interface directly with the SCTP stack or operate through the DTLS 1.3 stack. This specification builds upon DTLS 1.3 by introducing additional extensions to support enhanced functionality, including post-handshake authentication as described in [RFC9261] and the extended key update mechanism defined in [I-D.ietf-tls-extended-key-update].¶
Following the initial SCTP association setup, a DTLS 1.3 handshake is performed to mutually authenticate the endpoints and to derive keying material for the DTLS Chunk Protection Operator. The TLS exporter, as defined in Section 7.5 of [RFC8446], is used to derive this keying material. It leverages the same cryptographic algorithms that were negotiated during the DTLS handshake for use with the DTLS Record Layer, thereby eliminating the need for separate algorithm negotiation for the DTLS Chunk. However, this approach requires that only algorithm suites compatible with both DTLS 1.3 and DTLS Chunks be configured and supported.¶
+---------------+ +-------------------------------+
| Upper | | Post Handshake |
| Layer | | Authentication |
| Protocol | +-------------------------------+
| (ULP) | +-------------------------------+
| | | DTLS 1.3 |
| | | +---------------------+ |
| | | +->+ Key Exporter +--+ |
| | | | +---------------------+ | |
| | | | | |
| | | | +---------------------+ | |
| | | +--+ Key Management + | |
| | | | +---------------------+ | |
| | | | +---+ +---+ +---+ | |
| | | | | H | | | | A | | |
| | | | | a | | | | p | | |
| | | | k | n | | A | | p | k | |
| | | | e | d | | l | | | e | |
| | | | y | s | | e | | D |... y | |
| | | | s | h | | r | | a | s | |
| | | | | a | | t | | t | | |
| | | | | k | | | | a | | |
| | | | | e | | | | | | |
| | | | +-+-+ +-+-+ +-+-+ | |
| | | | | | | ... | |
| | | | +-----+----+ | |
| | | | ContentType | | |
| | | | +----------+----------+ | |
| | | +->| DTLS Record | | |
| | | | Protection Operator | | |
+ | | +----------+----------+ | |
+-------+-------+ +-----------------------------+-+
^ ^ |
| | |
+--+----------------------+ | keys
PPID | |
V V
+-----------------------------------------------+-+
| +---------------------+ | |
| SCTP | DTLS Chunk |<---+ |
| | Protection Operator | |
| +---------------------+ |
+-------------------------------------------------+
The following figure shows when the key exporter is used to get key material from the DTLS connection. Then keys are derived from that and the diagram also shows when these keys are configured for the DTLS chunk and also when the SCTP stack is instructed to discard received SCTP packets, when they are unprotected.¶
Client Server
------ ------
Record 0
ClientHello -------->
(epoch=0)
Record 0
<-------- ServerHello
(epoch=0)
{EncryptedExtensions}
(epoch=2)
{Certificate}
(epoch=2)
{CertificateVerify}
(epoch=2)
{Finished}
(epoch=2)
Record 1
{Certificate} -------->
(epoch=2)
{CertificateVerify}
(epoch=2)
{Finished}
(epoch=2)
SET RECV KEYS
SET RECV KEYS
SET SEND KEYS
Record 1
<-------- [ACK]
(epoch=3)
ENFORCE PROTECTION
SET SEND KEYS
on sender dry event
or
on reception of
protected packet
ENFORCE PROTECTION
The key derivation takes into account which protection solution identifiers have been sent and received. This way the communication is protected against downgrade attacks against the SCTP handshake.¶
TBD: Take the message flow into account which was presented by Magnus.¶
TBD: Provide formulas for deriving the keys and improve the message sequence diagram.¶
For updating the keys used for the DTLS chunk, the key updated described in [RFC9147] MUST NOT be used, since it does not update the exporter keys. Therefore the extended key update as described in [I-D.ietf-tls-extended-key-update] MUST be used. When a receive key for epoc n + 1 is installed, the receive key for epoc n - 1 SHOULD be removed. Deriving the keys from the exported keys is done similar to the initial derivation.¶
TBD: Provide formulas for the key derivation and a message sequence diagram for the extended key update.¶
SCTP peers may require periodic re-authentication after the DTLS handshake has completed. This is needed, for example, to demonstrate continued possession of a private key. In such cases, peers MUST use the post-handshake authentication mechanism defined in [RFC9261].¶
The application-layer protocol running over DTLS MUST be used to transmit the Authenticator Request. Either the SCTP client or the SCTP server may initiate this request using the established DTLS connection.¶
Similarly, the application-layer protocol running over DTLS MUST be used to transmit the corresponding Authenticator message.¶
TBD: A description of the application-layer message format(s) that carry the Authenticator Request and Authenticator will be provided in a future revision. This includes a message sequence chart illustrating the communication.¶
This document does not require any actions from IANA.¶
TBD.¶
The authors wish to thank Claudio Porfiri and Magnus Westerlund for their invaluable comments.¶