Internet-Draft DTLS for Key Management for DTLS Chunks July 2025
Tüxen, et al. Expires 8 January 2026 [Page]
Workgroup:
Network Working Group
Internet-Draft:
draft-tuexen-tsvwg-dtls-chunk-key-management-00
Published:
Intended Status:
Standards Track
Expires:
Authors:
M. Tüxen
Münster Univ. of Appl. Sciences
H. Tschofenig
H-BRS
T. Reddy
Nokia

Using Datagram Transport Layer Security (DTLS) for Key Management for the Stream Control Transmission Protocol (SCTP) DTLS Chunk

Abstract

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.

Status of This Memo

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.

Table of Contents

1. Introduction

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:

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.

2. Conventions

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.

3. Architecture

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 (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 |      |
|                    +---------------------+      |
+-------------------------------------------------+
Figure 1: Architecture

4. Setting the Keys Initially

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
Figure 2: Usage of Key Exporter

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.

5. Updating the Keys

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.

6. Post-Handshake Authentication

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.

7. IANA Considerations

This document does not require any actions from IANA.

8. Security Considerations

TBD.

9. References

9.1. Normative References

[RFC2119]
Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <https://www.rfc-editor.org/info/rfc2119>.
[RFC6083]
Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)", RFC 6083, DOI 10.17487/RFC6083, , <https://www.rfc-editor.org/info/rfc6083>.
[RFC8174]
Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, , <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446]
Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, , <https://www.rfc-editor.org/info/rfc8446>.
[RFC9147]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, , <https://www.rfc-editor.org/info/rfc9147>.
[RFC9260]
Stewart, R., Tüxen, M., and K. Nielsen, "Stream Control Transmission Protocol", RFC 9260, DOI 10.17487/RFC9260, , <https://www.rfc-editor.org/info/rfc9260>.
[RFC9261]
Sullivan, N., "Exported Authenticators in TLS", RFC 9261, DOI 10.17487/RFC9261, , <https://www.rfc-editor.org/info/rfc9261>.
[I-D.westerlund-tsvwg-sctp-dtls-chunk]
Westerlund, M., Mattsson, J. P., and C. Porfiri, "Stream Control Transmission Protocol (SCTP) DTLS Chunk", Work in Progress, Internet-Draft, draft-westerlund-tsvwg-sctp-dtls-chunk-04, , <https://datatracker.ietf.org/doc/html/draft-westerlund-tsvwg-sctp-dtls-chunk-04>.
[I-D.ietf-tls-extended-key-update]
Tschofenig, H., Tüxen, M., Reddy, T., Fries, S., and Y. Rosomakho, "Extended Key Update for Transport Layer Security (TLS) 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-extended-key-update-05, , <https://datatracker.ietf.org/doc/html/draft-ietf-tls-extended-key-update-05>.

Acknowledgments

The authors wish to thank Claudio Porfiri and Magnus Westerlund for their invaluable comments.

Authors' Addresses

Michael Tüxen
Münster University of Applied Sciences
Stegerwaldstrasse 39
48565 Steinfurt
Germany
Hannes Tschofenig
University of Applied Sciences Bonn-Rhein-Sieg
Tirumaleswar Reddy
Nokia