Transport Layer Security (TLS) based key-management of the Stream Control Transmission Protocol (SCTP) DTLS Chunk
draft-porfiri-tsvwg-sctp-dtls-handshake-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Magnus Westerlund , John Preuß Mattsson , Claudio Porfiri | ||
| Last updated | 2026-07-06 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-porfiri-tsvwg-sctp-dtls-handshake-01
TSVWG M. Westerlund
Internet-Draft J. Preuß Mattsson
Intended status: Standards Track C. Porfiri
Expires: 7 January 2027 Ericsson
6 July 2026
Transport Layer Security (TLS) based key-management of the Stream
Control Transmission Protocol (SCTP) DTLS Chunk
draft-porfiri-tsvwg-sctp-dtls-handshake-01
Abstract
This document defines how Transport Layer Security (TLS) 1.3 is used
as a key-management method for the SCTP DTLS Chunk mechanism. It
specifies how a TLS handshake establishes the initial security
context for an SCTP association and how subsequent TLS handshakes
provide key updates and re-authentication. The goal is to enable
authenticated and confidential communication over SCTP using the DTLS
Chunk, leveraging standardized TLS 1.3 features for key management
and rekeying.
About This Document
This note is to be removed before publishing as an RFC.
Status information for this document may be found at
https://datatracker.ietf.org/doc/draft-porfiri-tsvwg-sctp-dtls-
handshake/.
Discussion of this document takes place on the Transport Area Working
Group (tsvwg) Working Group mailing list (mailto:tsvwg@ietf.org),
which is archived at https://mailarchive.ietf.org/arch/browse/tsvwg/.
Subscribe at https://www.ietf.org/mailman/listinfo/tsvwg/.
Source for this draft and an issue tracker can be found at
https://github.com/teiclap/draft-porfiri-tsvwg-sctp-dtls-handshake.
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/.
Westerlund, et al. Expires 7 January 2027 [Page 1]
Internet-Draft TLS for DTLS in SCTP July 2026
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 7 January 2027.
Copyright Notice
Copyright (c) 2026 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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Architecture . . . . . . . . . . . . . . . . . . . . . . 5
2.2. Protocol Flow Summary . . . . . . . . . . . . . . . . . . 6
3. TLS Configuration Requirements . . . . . . . . . . . . . . . 7
3.1. TLS Version . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. Cipher Suite Constraints . . . . . . . . . . . . . . . . 7
3.3. Authentication and Identity . . . . . . . . . . . . . . . 7
3.4. Rekeying Policy . . . . . . . . . . . . . . . . . . . . . 8
4. TLS Message Transport . . . . . . . . . . . . . . . . . . . . 8
4.1. Control Messages . . . . . . . . . . . . . . . . . . . . 9
4.1.1. Protection Established . . . . . . . . . . . . . . . 9
5. Key Derivation . . . . . . . . . . . . . . . . . . . . . . . 10
5.1. Role Determination . . . . . . . . . . . . . . . . . . . 10
5.2. Exporter Context . . . . . . . . . . . . . . . . . . . . 10
5.3. Exporter Labels . . . . . . . . . . . . . . . . . . . . . 11
5.4. DKC Installation . . . . . . . . . . . . . . . . . . . . 11
6. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Initial Establishment . . . . . . . . . . . . . . . . . . 11
6.2. Rekeying . . . . . . . . . . . . . . . . . . . . . . . . 14
6.2.1. Triggering Criteria . . . . . . . . . . . . . . . . . 14
6.2.2. Procedure . . . . . . . . . . . . . . . . . . . . . . 14
Westerlund, et al. Expires 7 January 2027 [Page 2]
Internet-Draft TLS for DTLS in SCTP July 2026
6.2.3. Drain Timer Considerations . . . . . . . . . . . . . 15
6.2.4. Simultaneous Rekey Resolution . . . . . . . . . . . . 16
6.2.5. Key Transition State Machine . . . . . . . . . . . . 16
6.3. SCTP Association Restart . . . . . . . . . . . . . . . . 18
6.3.1. Prerequisites . . . . . . . . . . . . . . . . . . . . 18
6.3.2. Restart Procedure . . . . . . . . . . . . . . . . . . 18
7. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 21
8. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8.1. General . . . . . . . . . . . . . . . . . . . . . . . . . 21
8.2. Privacy Considerations . . . . . . . . . . . . . . . . . 22
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
9.1. DTLS Key Management Method Identifier . . . . . . . . . . 22
9.2. TLS Exporter Labels . . . . . . . . . . . . . . . . . . . 22
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 23
10.1. Normative References . . . . . . . . . . . . . . . . . . 23
10.2. Informative References . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
1. Introduction
The Stream Control Transmission Protocol (SCTP) [RFC9260] is a
transport protocol designed to support message-oriented communication
with features such as multiple streams for messages and multi-homing.
In many deployments, particularly telecommunication networks, it is
essential to provide confidentiality, integrity, and peer
authentication for SCTP traffic.
[I-D.ietf-tsvwg-sctp-dtls-chunk] defines a mechanism for securing
SCTP by encapsulating SCTP chunks within DTLS 1.3 records at the
chunk level. That specification defines the DTLS chunk format,
negotiation procedures, and an abstract API for key management, but
delegates the actual key management to external methods identified by
a DTLS Key Management Identifier.
This document defines one such method: it uses TLS 1.3 [RFC8446]
handshakes carried as SCTP user messages to perform mutual
authentication and derive keying material for the DTLS Chunk
Protection Operator. The combination of the SCTP DTLS Chunk and the
key-management defined in this document is referred to as "TLS for
DTLS in SCTP".
The key advantages of this approach are:
* It requires no extensions to TLS 1.3 to support long-lived
sessions.
* It is based on TLS 1.3 rather than DTLS 1.3, leveraging widely
available TLS implementations.
Westerlund, et al. Expires 7 January 2027 [Page 3]
Internet-Draft TLS for DTLS in SCTP July 2026
1.1. 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.
In this document, || denotes concatenation of byte sequences.
1.2. Terminology
This document uses the following terms:
Association: An SCTP association.
Client: The endpoint that has the key management client role. This
corresponds to the "client" role (C bit) in the DTLS Key
Management Parameter of [I-D.ietf-tsvwg-sctp-dtls-chunk].
Connection: A TLS 1.3 connection used for key management.
DTLS Key Context (DKC): The keying material (record payload key,
sequence number key, and IV) for both send and receive directions,
together with the replay window and last used sequence number.
Each DKC is identified by a tuple of (SCTP Association, restart
indicator, DTLS epoch).
Initiator: The endpoint initiating the SCTP association. In case of
simultanous open both SCTP endpoints may have started as
Initiator.
Primary DKC: A DTLS Key Context used to protect regular SCTP
association traffic.
Responder: The endpoint acting as server during SCTP association
establishment.
Restart DKC: A DTLS Key Context reserved exclusively for the SCTP
association restart procedure.
Server: The endpoint taking the key management server role. This
corresponds to the "server" role (S bit) in the DTLS Key
Management Parameter of [I-D.ietf-tsvwg-sctp-dtls-chunk].
Westerlund, et al. Expires 7 January 2027 [Page 4]
Internet-Draft TLS for DTLS in SCTP July 2026
1.3. Abbreviations
AEAD: Authenticated Encryption with Associated Data
DKC: DTLS Key Context
DTLS: Datagram Transport Layer Security
PPID: Payload Protocol Identifier
SCTP: Stream Control Transmission Protocol
TLS: Transport Layer Security
ULP: Upper Layer Protocol
2. Overview
This section provides an informational overview of TLS for DTLS in
SCTP. Normative procedures are specified in Section 6.
2.1. Architecture
Westerlund, et al. Expires 7 January 2027 [Page 5]
Internet-Draft TLS for DTLS in SCTP July 2026
+---------------+ +-------------------------------+
| ULP | | TLS 1.3 |
| | | +---------------------+ |
| | | +->+ Key Exporter +--+ |
| | | | +---------------------+ | |
| | | | | |
| | | | +---------------------+ | |
| | | +--+ Key Management + | |
| | | | +----------+----------+ | |
| | | | | | |
| | | | ContentType | | |
| | | | +----------+----------+ | |
| | | +->| TLS Record | | |
| | | | Protection Operator | | |
| | | +----------+----------+ | |
+-------+-------+ +-----------------------------+-+
^ ^ |
| | |
+--+-----------------------+ | keys
PPID | |
V V
+-----------------------------------------------+-+
| +---------------------+ | |
| SCTP | DTLS Chunk |<---+ |
| | Protection Operator | |
| +---------------------+ |
+-------------------------------------------------+
Figure 1: Architecture
Application data is never transmitted in TLS application_data
records. Instead, application data is sent via SCTP DATA chunks
protected by the DTLS Chunk Protection Operator. TLS 1.3 is used
solely for key management: performing handshakes, deriving keys via
the TLS Exporter, and then closing the TLS connection.
2.2. Protocol Flow Summary
The protocol operates in three phases:
1. *Initial Establishment:* After SCTP association setup (with DTLS
Key Management Parameter negotiation), a TLS 1.3 handshake
derives the initial Primary and Restart DKCs. Protection is then
enforced.
2. *Rekeying:* Either endpoint initiates a new TLS 1.3 handshake to
derive fresh DKCs for the next epoch, providing forward secrecy
and re-authentication. Old DKCs are removed after draining.
Westerlund, et al. Expires 7 January 2027 [Page 6]
Internet-Draft TLS for DTLS in SCTP July 2026
3. *SCTP Restart:* The pre-established Restart DKC protects the
COOKIE ECHO/COOKIE ACK exchange, followed by a new TLS handshake
to establish fresh Primary and Restart DKCs.
3. TLS Configuration Requirements
3.1. TLS Version
This document defines the usage of TLS 1.3 [RFC8446]. Earlier
versions of TLS MUST NOT be used. Only one version of TLS MUST be
used during the lifetime of an SCTP Association.
3.2. Cipher Suite Constraints
Parameters not marked as "Y" in the "Recommended" column of TLS
registries are NOT RECOMMENDED to support. Non-AEAD cipher suites or
cipher suites without confidentiality MUST NOT be supported. Cipher
suites and parameters that do not provide ephemeral key-exchange MUST
NOT be supported.
The cipher suites negotiated in the key-management TLS connection
MUST only include those supported by the DTLS Chunk Protection
Operator. The DTLS Chunk provides an API to query supported cipher
suites (see Section 7.3 of [I-D.ietf-tsvwg-sctp-dtls-chunk]).
3.3. Authentication and Identity
TLS for DTLS in SCTP MUST be mutually authenticated. It is
RECOMMENDED to use certificate-based authentication.
When certificates are used, the application is responsible for
certificate policies, certificate chain validation, and identity
authentication. The application defines what the identity is and how
it is encoded. Guidance on server certificate validation can be
found in [RFC9525].
All security decisions MUST be based on the peer's authenticated
identity, not on its transport layer identity. Since SCTP
associations can use multiple IP addresses per endpoint, DTLS records
may arrive from different source IP addresses than those originally
authenticated.
Clients and servers MUST NOT accept a change of identity during the
setup of a new TLS connection, but MAY accept negotiation of stronger
algorithms and security parameters.
Westerlund, et al. Expires 7 January 2027 [Page 7]
Internet-Draft TLS for DTLS in SCTP July 2026
3.4. Rekeying Policy
Implementations MUST have policies for how often to set up new TLS
connections with ephemeral key exchange. Implementations SHOULD
rekey at least every hour and every 100 GB of data, which is a common
policy for IPsec [ANSSI-DAT-NT-003].
Implementations MUST set up a new TLS connection using a full
handshake with new certificates before any last used certificates
expire.
The PSK key exchange mode psk_ke MUST NOT be used as it does not
provide ephemeral key exchange. TLS Key Update MUST NOT be used as
it doesn't provide a new ephemeral key for the key exporter.
TLS 1.3 tickets MAY be used for resumption. Resumption can be used
to chain the connections, increasing security by forcing an adversary
to break them in sequence [KTH-NCSA].
The endpoints MUST limit the number of simultaneous TLS connections
to one.
4. TLS Message Transport
TLS records and control messages for key-management are sent as SCTP
user messages using reliable in-order delivery on stream 0 with the
DTLS Key Management Messages PPID (4242)
[I-D.ietf-tsvwg-sctp-dtls-chunk].
Each SCTP user message uses the format defined in Figure 2.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T| Epoch | |
+-+-+-+-+-+-+-+-+ Payload |
| |
| +-------------------------------+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Key Management User Message Structure
T (Message Type): 1 bit Indicates the type of payload carried in
this user message. A value of 0 indicates that the payload
contains TLS records. A value of 1 indicates that the payload is
a control message (see Section 4.1).
Westerlund, et al. Expires 7 January 2027 [Page 8]
Internet-Draft TLS for DTLS in SCTP July 2026
Epoch: 7 bits The 7 lowest bits of the DTLS Key Context epoch that
this message corresponds to — i.e., the DKC that will be created
from this handshake, or that already exists. The receiver uses
this field to associate incoming data with the correct key-
management session.
Payload: variable length When T=0, one or more complete TLS records.
When T=1, a control message as defined in Section 4.1.
4.1. Control Messages
When the T bit is set to 1, the payload of the user message is a
control message with the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ctrl Type | Control Data (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Control Message Format
Ctrl Type: 8 bits Identifies the control message type.
Control Data: variable length Type-specific data. May be empty.
The following control message type is defined:
+===========+========================+==============================+
| Ctrl Type | Name | Description |
+===========+========================+==============================+
| 0x01 | Protection | Signals that DTLS chunk |
| | Established | protection has been enforced |
+-----------+------------------------+------------------------------+
Table 1: Control Message Types
4.1.1. Protection Established
The Protection Established control message (Ctrl Type = 0x01) is sent
by the Server to the Client after the Server has installed all keys
and enforced DTLS chunk protection. This message carries no Control
Data (the payload following the Ctrl Type byte is empty).
Upon receiving this message, the Client enforces DTLS chunk
protection and informs the ULP that the association is protected.
Westerlund, et al. Expires 7 January 2027 [Page 9]
Internet-Draft TLS for DTLS in SCTP July 2026
The message is also used during rekeying to confirm to the endpoint
with the client role in that procedure that the server has installed
all keys, and the client can install write keys.
5. Key Derivation
5.1. Role Determination
Role determination and method selection follow the procedure defined
in Section 5.1 of [I-D.ietf-tsvwg-sctp-dtls-chunk]. After the SCTP
association is established, the key-management function retrieves
from the SCTP stack's DTLS chunk API the assigned role (Client or
Server), the selected DTLS Key Management Method, and the downgrade
prevention data (both endpoints' DTLS Key Management Parameters) used
as input to key derivation.
5.2. Exporter Context
DTLS Key Contexts are derived using the TLS Exporter as defined in
Section 7.5 of [RFC8446]. The exporter context is constructed as the
concatenation of the following fields:
+===========+==========+======================================+
| Field | Length | Value |
+===========+==========+======================================+
| Direction | 1 byte | 0x00 = Client to Server, 0x01 = |
| | | Server to Client |
+-----------+----------+--------------------------------------+
| Key role | 1 byte | 0x00 = primary/traffic, 0x01 = |
| | | restart |
+-----------+----------+--------------------------------------+
| Key type | 1 byte | 0x00 = Key, 0x01 = SN_KEY, 0x02 = IV |
+-----------+----------+--------------------------------------+
| Client KM | variable | DTLS Key Management Parameter sent |
| Param | | by the endpoint designated as Client |
+-----------+----------+--------------------------------------+
| Server KM | variable | DTLS Key Management Parameter sent |
| Param | | by the endpoint designated as Server |
+-----------+----------+--------------------------------------+
Table 2
Each DTLS Key Management Parameter (Section 4.1 of
[I-D.ietf-tsvwg-sctp-dtls-chunk]) is included as the sequence of
bytes sent on the wire, including the parameter header and excluding
padding.
Westerlund, et al. Expires 7 January 2027 [Page 10]
Internet-Draft TLS for DTLS in SCTP July 2026
This construction ensures that any modification to the DTLS Key
Management Parameter during the SCTP handshake (a downgrade attack)
results in mismatched keys and association failure.
5.3. Exporter Labels
A single TLS Exporter label is used to derive all keying material:
EXPORTER_TLS_FOR_DTLS_IN_SCTP
The specific key material (direction, role, and type) is
differentiated by the exporter context (Section 5.2). Each
combination of Direction, Key role, and Key type values produces a
distinct export, yielding 12 values in total (2 directions × 2 roles
× 3 types).
The Client installs exports with Direction=Client to server as its
write keys and Direction=Server to client as its read keys. The
Responder does the reverse.
The length of exported material depends on the negotiated cipher
suite.
5.4. DKC Installation
Each successful TLS handshake produces one or two (if restart is
supported) DKCs:
* A Primary DKC for regular SCTP traffic.
* A Restart DKC for the SCTP restart procedure.
The first DKC established for any SCTP association MUST use DTLS
epoch 3. Each subsequent Primary DKC uses the next consecutive
epoch. After an SCTP restart, the epoch resets to 3.
If SCTP Restart is supported the endpoint MUST generate Restart DKC
for each epoch where a Primary DKC is generated. The Restart DKC
MUST be maintained in a well-defined state (initialized but never
used for regular traffic) so that both endpoints have a consistent
view of sequence numbers and replay window.
6. Procedures
6.1. Initial Establishment
Westerlund, et al. Expires 7 January 2027 [Page 11]
Internet-Draft TLS for DTLS in SCTP July 2026
Initiator Responder
| |
1. +------------------------[INIT]---------------------->|
|<---------------------[INIT-ACK]---------------------+
+--------------------[COOKIE ECHO]------------------->| 2.
3. |<--------------------[COOKIE ACK]--------------------+
| |
| Key Manager Client Key Manager Server |
| | | |
4. +--->| TLS START TLS START |<----+
| | | |
| +---------[DATA(TLS Client Hello)]-------->| 5. |
| | | |
| 7. |<-[DATA(TLS Server Hello ... Finished)]---+ 6. |
| 8. +--[DATA(TLS Certificate ... Finished)]--->| 9. |
| | | 10. |
|12. |<--[DATA(Protection Established)]---------+ 11. |
| | | |
| | -.
13. +------------[DTLS CHUNK(DATA(APP DATA))]------------>| | APP DATA
+<-----------[DTLS CHUNK(DATA(APP DATA))]-------------+ +---------
| ... | |
Figure 4: Initial Establishment
The diagram Figure 4 shows the case where SCTP Initiator ends up with
the Key Manager client role. The opposite case is identical but with
inverted roles among Key Managers. In the following procedure we use
Initiator and Responder referring to SCTP, Client and Server
referring to Keymanager role, and implicitly TLS roles.
The procedure is as follows:
1. The Initiator sends INIT containing the DTLS Key Management
Parameter (Section 4.1 of [I-D.ietf-tsvwg-sctp-dtls-chunk]) with
this method's identifier (see Section 9.1) in its preference-
ordered list.
2. The Responder enters ESTABLISHED state. It retrieves the agreed
DTLS Key Management Method and role from the SCTP stack (e.g.,
using the "Get Agreed DTLS Key Management Method and Role" API
defined in Section 7.2 of [I-D.ietf-tsvwg-sctp-dtls-chunk]) and
verifies that the selected method matches the one defined in
this document (see Section 9.1) and gets the assigned role as
key manager client or server (in the example depicted in
Figure 4 it is server).
Westerlund, et al. Expires 7 January 2027 [Page 12]
Internet-Draft TLS for DTLS in SCTP July 2026
3. The Initiator enters ESTABLISHED state. It performs the same
retrieval and verification as the Responder, confirming the
assigned role as key manager client or server (in the example
depicted in Figure 4 it is client).
4. The client key manager starts a TLS 1.3 handshake, limiting
offered cipher suites to those supported by the DTLS Chunk
Protection Operator, and sends TLS ClientHello per Section 4.
5. The server key manager receives the TLS ClientHello. If a
HelloRetryRequest is needed, an additional round-trip occurs
before proceeding.
6. The server key manager sends its TLS ServerHello through
Finished messages.
7. The client key manager receives the TLS ServerHello message,
exports all Primary and Restart DKC keys, and installs the
server to client key material as its read (receive) key.
8. The client key manager sends its TLS
Certificate/CertificateVerify/Finished.
9. The server key manager receives Certificate/CertificateVerify/
Finished, it exports both direction key material for both the
Primary and Restart DKCs, and installs both read (receive) keys
and as its write (send) keys.
10. The server key manager calls Require Protected SCTP Packets to
enforce DTLS chunk protection for all future packets and informs
the ULP that the association is protected.
11. The server key manager sends a Protection Established control
message (Section 4.1.1) to the client key manager.
12. The client key manager receives the Protection Established
control message, and installs the client key material as its
write (send) key, calls Require Protected SCTP Packets to
enforce DTLS chunk protection for all future packets, and
informs the ULP that the association is protected.
13. Application traffic can begin.
If the TLS handshake fails, the SCTP association MUST be aborted.
After key installation, the TLS connection SHOULD be closed promptly.
Westerlund, et al. Expires 7 January 2027 [Page 13]
Internet-Draft TLS for DTLS in SCTP July 2026
6.2. Rekeying
6.2.1. Triggering Criteria
Rekeying is triggered by implementation-configurable criteria,
including:
* Time elapsed since last peer authentication.
* Volume of data transferred since last forward-secrecy rekeying.
* Approaching the cipher suite's AEAD usage limits.
6.2.2. Procedure
Initiator Responder
| |
| (traffic continues using epoch N DKC) |
| |
| Client Key Manager Key Manager Server |
| | | |
| 1. +---------[DATA(TLS Client Hello)]------->| 2. |
| 4. |<-[DATA(TLS Server Hello ... Finished)]--+ 3. |
| 5. +--[DATA(TLS Certificate ... Finished)]-->| 6. |
| 8. |<--[DATA(Protection Established)]--------+ 7. |
| |
| (traffic transitions to epoch N+1 DKC) |
| |
| (after draining, remove epoch N DKC) |
| |
Figure 5: Rekeying Procedure
The diagram Figure 5 shows the case where SCTP Initiator is
initiating the rekeying. The opposite case where the Responder
initates rekeying is identical but inverts which key manager role
that executes the various steps between Client and Server temporarly
for this exchange only. The initially determined Key manager roles
are only used to handle the case both sides initiate a rekey
simultanously, see Section 6.2.4.
Either endpoint may initiate rekeying. The procedure is as follows:
1. The peer willing to rekey becomes the TLS client for this rekey
procedure. It sends a TLS ClientHello in a key management
message using epoch N+1. The key management messages are carried
inside DTLS chunks (the association is already protected).
Westerlund, et al. Expires 7 January 2027 [Page 14]
Internet-Draft TLS for DTLS in SCTP July 2026
2. The other peer becomes the TLS server for this rekey procedure.
It receives and processes the ClientHello for the key management
epoch N+1.
3. The server sends its TLS ServerHello through Finished messages to
the client.
4. The client receives the TLS ServerHello message, exports all
Primary and Restart DKC keys, and installs server to client key
material as its read (receive) key.
5. The client sends its TLS Certificate/CertificateVerify/Finished
encrypted with the old keys.
6. The server receives and process the TLS message, exports and
installs the client key material for both the Primary and Restart
DKCs as its read (receive) key and the server key material as
write (send) key. Then it starts the drain timer to remove the
old (epoch N) DKC. From now on the server uses new keys.
7. The server key manager sends a Protection Established control
message (Section 4.1.1) to the client key manager.
8. The client key manager receives the Protection Established
control message, exports the client Primary and Restart DKC keys,
and installs the client key material as its write (send) key, and
starts the drain timer to remove the old (epoch N) DKC. From now
on the client uses new keys.
The new DKCs use epoch N+1 (where N is the current epoch). Both old
(epoch N) and new (epoch N+1) DKCs coexist temporarily until the
drain timer expires (see Section 6.2.3).
All rekeying MUST use ephemeral key exchange. TLS Key Update MUST
NOT be used.
6.2.3. Drain Timer Considerations
The drain timer determines how long old (epoch N) DKCs are retained
after new (epoch N+1) DKCs have been activated. Its purpose is to
allow in-flight packets protected with the old keys to be received
and processed before those keys are removed.
The drain timer value depends on whether the delivery of the final
rekeying message has been confirmed:
Westerlund, et al. Expires 7 January 2027 [Page 15]
Internet-Draft TLS for DTLS in SCTP July 2026
* If delivery of the last rekeying message has been confirmed (e.g.,
through SCTP acknowledgment of the DATA chunk carrying the TLS
Finished), the old DKC MAY be removed after a short drain timer.
A value of 120 seconds (one Maximum Segment Lifetime) is
RECOMMENDED in this case.
* If delivery has not been confirmed, the drain timer MUST be set to
at least the SCTP association failure time (T_fail). This ensures
that if the final rekeying message is lost and requires
retransmission, the old DKC remains available for as long as SCTP
continues retransmission attempts. If the association fails
(i.e., SCTP declares the peer unreachable), the DKCs are removed
as part of association teardown.
The SCTP association failure time depends on the Retransmission
Timeout (RTO) and the maximum number of retransmissions
(Association.Max.Retrans, as defined in [RFC9260]). With the default
values from [RFC9260] (RTO.Initial = 1s, RTO.Max = 60s,
Association.Max.Retrans = 10), T_fail is approximately 303 seconds.
Implementations SHOULD set the drain timer to at least T_fail when
delivery of the final rekeying message has not been confirmed.
6.2.4. Simultaneous Rekey Resolution
As either endpoint can initiate a TLS handshake at the same time,
either endpoint may receive a TLS ClientHello when it has already
sent its own. In this case, the ClientHello from the endpoint with
the initial keymanager client role SHALL be processed, and the other
SHALL be dropped.
6.2.5. Key Transition State Machine
This specification allows up to 2 Primary DKCs to be active at the
same time. The following state machine governs the transition:
Westerlund, et al. Expires 7 January 2027 [Page 16]
Internet-Draft TLS for DTLS in SCTP July 2026
+---------+
| INIT | Association started
+----+----+ No TLS H/S yet
|
| 1. TLS initial H/S
| completed
|
| +------------------ Association Restart
| |
V V
+---------+
+--------->| YOUNG |
| +------->| +--------------------+
| | +----+----+ |
| | | | 3. Aging event
| | | 2. Client Hello | Send Client Hello
| | | from peer |
| | V V
| | +---------+ 4. Client H +---------+ 5. TLS H/S
| | | REMOTE | tie-break | LOCAL | Timeout
| | | AGED |<-------------+ AGED +-----+
| | +----+----+ +----+----+ |
| | | | |
| | | | |
| | 7. Finished | 6. Server Hello | |
| | | +-----+ |
| | | | |
| | V V V
| | +---------+ +---------+ +---------+
| | | REMOTE | | LOCAL | | ABORT |
| | | OLD | | OLD | | |
| | +-----+---+ +-----+---+ +---------+
| | 8. Flush | |
| +--------------+ |
| 9. Flush |
+----------------------------------+
Figure 6: State Diagram for Rekeying
INIT: Initial state. Only event 1 (TLS handshake completed)
transitions to YOUNG.
YOUNG: Only the Current DKC is populated. Event 2 (peer
ClientHello) transitions to REMOTE OLD; event 3 (aging)
transitions to LOCAL AGED.
LOCAL AGED: A supervision timer runs. Event 5 (timeout) causes the
Westerlund, et al. Expires 7 January 2027 [Page 17]
Internet-Draft TLS for DTLS in SCTP July 2026
key manager to check for local aging expire, in that case ABORT
otherwise return to YOUNG. Event 4 (peer ClientHello with tie-
break yielding server role) transitions to REMOTE OLD. Event 6
(ServerHello received) transitions to LOCAL OLD.
LOCAL AGED: TLS handshake happens in this state. Local keys are
installed. Event 7 (peer sends Certificate..Finished enable
transition to REMOTE_OLD)
REMOTE OLD: Both Old and Current DKCs exist. Old DKC is used for
sending until Protection Established control message is sent.
Event 8 (flush timer expires) transitions to YOUNG.
LOCAL OLD: Both Old and Current DKCs exist. Old DKC is used for
sending, until Protection Established control message is received.
Event 9 (flush timer expires) transitions to YOUNG.
In REMOTE OLD and LOCAL OLD, if a new ClientHello or Aging event
arrives, the flushing timer is cleared and behavior is as in YOUNG.
6.3. SCTP Association Restart
6.3.1. Prerequisites
For protected SCTP restart to succeed:
* Both endpoints MUST have a valid Restart DKC.
* The Restart DKC MUST be stored securely and persistently to
survive crash events (see Section 10.4 of
[I-D.ietf-tsvwg-sctp-dtls-chunk]).
* Both endpoints MUST have indicated restart support (R bit) in the
DTLS Key Management Parameter.
6.3.2. Restart Procedure
Westerlund, et al. Expires 7 January 2027 [Page 18]
Internet-Draft TLS for DTLS in SCTP July 2026
Initiator Responder
| |
1. | (install restart keys from storage) |
| | -.
2. +------------------------(INIT)--------------------->| | Plain
3. |<---------------------(INIT-ACK)--------------------+ +-------
| | -'
| | -.
4. +-------------[DTLS CHUNK(COOKIE ECHO)]------------->| | Protected
5. |<------------[DTLS CHUNK(COOKIE ACK)]---------------+ +----------
6. | | -'
7. | |
| (TLS handshake for new keys, steps 8-13) |
| |
15. |<----------[DATA(Protection Established)]-----------+ 14.
16. | |
17. +------------[DTLS CHUNK(DATA(APP DATA))]----------->| APP DATA
+<-----------[DTLS CHUNK(DATA(APP DATA))]------------+
| |
Figure 7: SCTP Restart Procedure
1. The restarting endpoint (Initiator) retrieves the restart key
material from persistent secure storage and installs the Restart
DKC for both send and receive directions.
2. The Initiator sends INIT (VTag=0). Include the DTLS Key
Management Parameter with the same method list but a new random
Tie Breaker.
3. The Responder (the not restarting endpoint) replies INIT-ACK in
plain text per [RFC9260]. Include the DTLS Key Management
Parameter with the same method list but a new random Tie
Breaker.
4. The Initiator sends COOKIE ECHO in a DTLS chunk protected with
the Restart DKC (R bit set).
5. The Responder replies COOKIE ACK in a DTLS chunk protected with
the Restart DKC (R bit set).
Westerlund, et al. Expires 7 January 2027 [Page 19]
Internet-Draft TLS for DTLS in SCTP July 2026
6. Both endpoints have a new established association. Each
endpoint immediately calls Require Protected SCTP Packets to
enforce DTLS chunk protection (using the Restart DKC), then
retrieves the agreed DTLS Key Management Method and role from
the SCTP stack (e.g., using the "Get Agreed DTLS Key Management
Method and Role" API defined in Section 7.2 of
[I-D.ietf-tsvwg-sctp-dtls-chunk]) and verifies that the selected
method matches the one defined in this document (see
Section 9.1) and that the assigned role is as expected.
7. The ULP MAY be informed that the association is protected at
this point. ULP traffic MAY begin immediately using the Restart
DKC.
8. The client key manager starts a TLS 1.3 handshake, limiting
offered cipher suites to those supported by the DTLS Chunk
Protection Operator, and sends TLS ClientHello per Section 4,
protected by the Restart DKC.
9. The server key manager receives the TLS ClientHello. If a
HelloRetryRequest is needed, an additional round-trip occurs
before proceeding.
10. The server key manager sends its TLS ServerHello through
Finished messages.
11. The client key manager receives the TLS ServerHello message,
exports all Primary DKC keys, and installs the server key
material as its read (receive) key for the Primary DKC.
12. The client key manager sends its TLS
Certificate/CertificateVerify/Finished.
13. The server key manager receives Certificate/CertificateVerify/
Finished, it exports the client and server key material for the
Primary DKC, and installs client key as its read (receive) key
and the server key as its write (send) key.
14. The server key manager sends a Protection Established control
message (Section 4.1.1) to the client key manager. The server
endpoint export and install the new Restart DKC key material
(both send and receive directions), remove the old Restart DKC,
and commit the new Restart DKC to persistent secure storage.
15. The client key manager receives the Protection Established
control message. Installs the primary client Key as its write
(send) key.
Westerlund, et al. Expires 7 January 2027 [Page 20]
Internet-Draft TLS for DTLS in SCTP July 2026
16. The client key manager export and install the new Restart DKC
key material (both send and receive directions), remove the old
Restart DKC, and commit the new Restart DKC to persistent secure
storage.
17. Application traffic uses to the new Primary DKC.
After restart, the new Primary DKC MUST use epoch 3 (the epoch
resets).
The Responder MUST NOT change the Restart DKC during the restart
procedure. After the new Restart DKC is installed, the old one is
removed.
It is RECOMMENDED to complete the TLS handshake and install new DKCs
as soon as possible after restart, to minimize the window during
which no Restart DKC is available for a subsequent restart.
Note: There MAY exist a short time gap after association
establishment where no Restart DKC is yet installed. If an SCTP
restart is initiated during that time, it will fail. However, this
is unlikely as the restarting endpoint sends INIT multiple times with
exponential back-off.
7. Error Handling
TLS has its own error reporting via TLS alert messages. When a TLS
handshake error occurs, the TLS alert is sent in an SCTP user message
(see Section 4) with the DTLS Key Management Messages PPID (4242).
If a TLS handshake fails during initial establishment, the SCTP
association MUST be aborted.
If a TLS handshake fails during rekeying, and the current DKC has not
yet reached its usage limits, the implementation SHOULD retry the
handshake. If retry is not possible or the current DKC is aged
beyond policy limits, the association MUST be aborted.
8. Security Considerations
8.1. General
The security considerations given in [RFC8446], [RFC9147], and
[RFC9260] also apply to this document. BCP 195 [RFC9325] [RFC8996]
provides recommendations and requirements for improving the security
of deployed services that use TLS. BCP 195 MUST be followed.
Westerlund, et al. Expires 7 January 2027 [Page 21]
Internet-Draft TLS for DTLS in SCTP July 2026
8.2. Privacy Considerations
Although TLS for DTLS in SCTP provides privacy for user messages and
almost all SCTP chunks, the SCTP common header, DTLS chunk header,
and DTLS record header are not confidentiality protected. An
attacker can correlate TLS connections over the same SCTP association
using the SCTP common header.
To provide identity protection, it is RECOMMENDED to use certificate-
based authentication in TLS 1.3 and to not reuse tickets. TLS 1.3
with external PSK authentication does not provide identity
protection.
By mandating ephemeral key exchange and cipher suites with
confidentiality, TLS for DTLS in SCTP effectively mitigates many
forms of passive pervasive monitoring. Frequent rekeying forces
attackers to perform dynamic key exfiltration and limits the amount
of compromised data due to key compromise.
9. IANA Considerations
9.1. DTLS Key Management Method Identifier
IANA is requested to assign one DTLS Key Management Method Identifier
in the "DTLS Key Management Method" registry defined by
[I-D.ietf-tsvwg-sctp-dtls-chunk] to identify the key-management
method defined in this document.
+============+============================+===========+=========+
| Identifier | Key Management Method Name | Reference | Contact |
+============+============================+===========+=========+
| 192 | TLS for DTLS in SCTP | RFC-TBD | Draft |
| | | | Authors |
+------------+----------------------------+-----------+---------+
Table 3: DTLS Key Management Method Identifier
9.2. TLS Exporter Labels
IANA is requested to register the following value in the TLS Exporter
Label Registry [RFC5705] with Reference RFC-TBD and empty Comment.
Westerlund, et al. Expires 7 January 2027 [Page 22]
Internet-Draft TLS for DTLS in SCTP July 2026
+===============================+=========+=============+
| Value | DTLS-OK | Recommended |
+===============================+=========+=============+
| EXPORTER_TLS_FOR_DTLS_IN_SCTP | Y | N |
+-------------------------------+---------+-------------+
Table 4: TLS Exporter Label
10. References
10.1. Normative References
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
<https://www.rfc-editor.org/info/rfc8996>.
[RFC9147] Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version
1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022,
<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,
June 2022, <https://www.rfc-editor.org/info/rfc9260>.
[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>.
[I-D.ietf-tsvwg-sctp-dtls-chunk]
Westerlund, M., Mattsson, J. P., Porfiri, C., and M.
Tüxen, "Stream Control Transmission Protocol (SCTP) DTLS
Chunk", Work in Progress, Internet-Draft, draft-ietf-
tsvwg-sctp-dtls-chunk-04, 6 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-
sctp-dtls-chunk-04>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
Westerlund, et al. Expires 7 January 2027 [Page 23]
Internet-Draft TLS for DTLS in SCTP July 2026
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
10.2. Informative References
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport
Layer Security (TLS)", RFC 5705, DOI 10.17487/RFC5705,
March 2010, <https://www.rfc-editor.org/info/rfc5705>.
[RFC9525] Saint-Andre, P. and R. Salz, "Service Identity in TLS",
RFC 9525, DOI 10.17487/RFC9525, November 2023,
<https://www.rfc-editor.org/info/rfc9525>.
[ANSSI-DAT-NT-003]
Agence nationale de la sécurité des systèmes
d'information, "Recommendations for securing networks with
IPsec", ANSSI Technical Report DAT-NT-003 , August 2015,
<<https://www.ssi.gouv.fr/uploads/2015/09/
NT_IPsec_EN.pdf>>.
[KTH-NCSA] Ekerå, M., "On factoring integers, and computing discrete
logarithms and orders, quantumly", KTH, School of
Electrical Engineering and Computer Science (EECS),
Computer Science, Theoretical Computer Science, TCS.
Swedish NCSA, Swedish Armed Forces. , October 2024,
<http://kth.diva-portal.org/smash/get/diva2:1902626/
FULLTEXT01.pdf>.
Authors' Addresses
Magnus Westerlund
Ericsson
Email: magnus.westerlund@ericsson.com
John Preuß Mattsson
Ericsson
Email: john.mattsson@ericsson.com
Claudio Porfiri
Ericsson
Email: claudio.porfiri@ericsson.com
Westerlund, et al. Expires 7 January 2027 [Page 24]