Transport Layer Security (TLS) based Key Management of the Stream Control Transmission Protocol (SCTP) DTLS Chunk

Introduction The Stream Control Transmission Protocol (SCTP) 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. 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 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 "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.

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 when, and only when, they appear in all capitals, as shown here. In this document, || denotes concatenation of byte sequences.

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 .
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 simultaneous 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 .

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

Overview This section provides an informational overview of DTLS in SCTP. Normative procedures are specified in .

Architecture

Architecture + Key Exporter +-+-+ | | | | | | +---------------------+ | | | | | | | | | | | | | | | | +---------------------+ | | | | | | | +--+ Key Management + | | | | | | | | +----------+----------+ | | | | | | | | | | | | | | | | | ContentType | | | | | | | | | +----------+----------+ | | | | | | | +->| TLS Record | | | | | | | | | Protection Operator | | | | | | | | +----------+----------+ | | | | | | +----------------------------+ | | | | | ^ | | +-------+-------+ +-----------------+--------------+-+ ^ ^ | | | | PPID=4243 | PPID=4242 | +--+---------+--------------+ | keys PPID | | V V +--------------------------------------------------+-+ | +---------------------+ | | | SCTP | DTLS Chunk |<----+ | | | Protection Operator | | | +---------------------+ | +----------------------------------------------------+ ]]> As shown in , the Key Management Method is layered above SCTP alongside the Upper Layer Protocol (ULP), while the DTLS Chunk Protection Operator sits within SCTP and performs the actual protection of SCTP packets by encrypting and decrypting them and performing integrity verification. The Key Management Method instantiates a TLS 1.3 connection that is used solely for mutual authentication and key establishment; it never carries user data. The key managers drive this connection through the TLS user API (the client key manager acting as the TLS client, the server key manager as the TLS server, role determination is specified in ) and relay the resulting TLS records to each other as SCTP user messages, so that the TLS handshake is performed between the two endpoints. TLS records and key management control information travel over the same SCTP association as the ULP's data and are distinguished by the SCTP Payload Protocol Identifier (PPID): PPID 4242 for TLS records, PPID 4243 for control information, and the ULP's own PPID(s) for application data. This separation lets the receiver deliver each message to the TLS connection, to the key management logic, or to the ULP, as appropriate. The framing and control messages are specified in . When the TLS handshake completes, the key management function derives keying material from the TLS Exporter and creates the DTLS Key Contexts (DKCs) used by the DTLS Chunk Protection Operator to protect SCTP packets; the TLS connection is then closed. Key derivation and DKC installation are specified in .

Protocol Flow Summary The protocol operates in three phases:

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.
Rekeying: Either endpoint may trigger rekeying to derive fresh DKCs for the next epoch, providing forward secrecy and re-authentication. The client key manager always performs the TLS 1.3 handshake; when the server key manager needs to rekey it requests one via a Rekey Request. Old DKCs are removed after draining.
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.

TLS Configuration Requirements

TLS Version This document defines the usage of TLS 1.3 . Earlier versions of TLS MUST NOT be used. An endpoint MUST NOT use more than one TLS version during the lifetime of an SCTP association.

Cipher Suite Constraints Parameters not marked as "Y" in the "Recommended" column of TLS registries SHOULD NOT be supported. 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 ).

Authentication and Identity DTLS in SCTP MUST be mutually authenticated. It is RECOMMENDED to use certificate-based authentication. When certificates are used, the application is responsible for trust anchor management, 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 . 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. The authenticated peer identity MUST remain stable across every TLS connection established for the lifetime of the SCTP association, including the connections used for rekeying () and the connection established after an SCTP restart (). 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. This requirement is independent of the key management role: the Client and Server roles are re-derived from the SCTP handshake and MAY differ after an SCTP restart (), but an endpoint that changes role MUST still present the same authenticated identity.

Rekeying Considerations Implementations need to implement criteria for when to initiate rekeying. Implementations are RECOMMENDED to rekey at least every hour and every 100 GB of data, which matches what is specified for IPsec in . 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 session resumption (see ). The endpoints MUST limit the number of simultaneous TLS connections to one.

Session Resumption Support for TLS 1.3 session resumption is OPTIONAL. When supported, it provides the following benefits:

It avoids re-sending the full certificate chain on subsequent TLS connections. This saves a significant amount of message size, especially with post-quantum cryptography (PQC) certificates, which can be significantly larger than certificates based on Elliptic Curve Cryptography.
It reduces processing, and thus energy consumption and latency.
It allows successive TLS connections to be chained, increasing security by forcing an adversary to break them in sequence .

Session resumption tickets are delivered using the standard TLS 1.3 mechanisms: the server MAY send tickets unsolicited , and the client MAY request them . To ensure the client has the opportunity to obtain a ticket before the TLS connection is torn down, the client key manager SHOULD initiate the closure of the TLS connection, and the server key manager SHOULD NOT close the TLS connection before the client has had the opportunity to obtain the tickets it requested.

Key Management Messages All key management messages MUST be sent as SCTP user messages using reliable in-order delivery on stream 0. There are two classes of these key management messages:

SCTP user messages containing TLS records.
SCTP user messages containing control information.

These two classes are identified by using a specific PPID each.

TLS Records One or more complete TLS records are sent as an SCTP user message. These user messages MUST use PPID 4242. Other SCTP user messages MUST NOT use this PPID.

Control Messages Control messages are sent as SCTP user messages, they MUST use PPID 4243 and contain a single byte identifying the type as shown in the following . Other user messages MUST NOT use this PPID.

Control Message Format

Ctrl Type: 8 bits: Identifies the control message type.

The following control message type is defined: Control Message Types

Ctrl Type	Name	Description
0x01	Read Key Installed	Notifies the peer that the read key is installed
0x02	Rekey Request	Requests the client key manager to initiate a rekeying TLS handshake

Read Key Installed The Read Key Installed control message (Ctrl Type = 0x01) is sent by a key manager to its peer key manager for indicating that it has set the read key material. This enables the peer receiving this message to set its write key. The message is also used during rekeying in the same way as in the initial handshake.

Rekey Request The Rekey Request control message (Ctrl Type = 0x02) is sent by the server key manager to the client key manager to request that the client key manager initiate a rekeying TLS handshake (see ). Because only the client key manager initiates a TLS handshake, the server key manager uses this message when it determines that rekeying is needed (per its own criteria in ). This division of roles allows an endpoint holding only the client role to implement a TLS client only, and an endpoint holding only the server role to implement a TLS server only. Upon receiving a Rekey Request, the client key manager initiates a rekeying TLS handshake as described in , unless a rekeying is already in progress, in which case the Rekey Request is ignored (see ).

Key Derivation

Role Determination Role determination and method selection follow the procedure defined in Section 5.1 of . 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.

Exporter Context DTLS Key Contexts are derived using the TLS Exporter as defined in Section 7.5 of . The exporter context is constructed as the concatenation of the following fields: Exporter Context

Field	Length	Value
Direction	1 byte	0x00 = Client to Server, 0x01 = Server to Client
Key role	1 byte	0x00 = primary, 0x01 = restart
Key type	1 byte	0x00 = Key, 0x01 = SN_KEY, 0x02 = IV
Client KM Param	variable	DTLS Key Management Parameter sent by the endpoint designated as Client
Server KM Param	variable	DTLS Key Management Parameter sent by the endpoint designated as Server

Each DTLS Key Management Parameter (Section 4.1 of ) is included as the sequence of bytes sent on the wire, including the parameter header and excluding padding. 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.

Exporter Labels A single TLS Exporter label is used to derive all keying material: The specific key material (direction, role, and type) is differentiated by the exporter context (). 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 endpoint with the Client role installs exports with Direction=Client to server as its write keys and Direction=Server to client as its read keys. The endpoint with Server role does the reverse. The length of exported material depends on the negotiated cipher suite.

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, together with its paired Restart DKC, uses the next consecutive epoch. After an SCTP restart, the epoch resets to 3. If SCTP Restart is supported the endpoint MUST generate a Restart DKC for each epoch where a Primary DKC is generated. The Restart DKC uses the same DTLS epoch as the Primary DKC generated alongside it; the two are distinguished not by epoch but by the restart indicator (the R bit in the DTLS chunk, see ) and by the Key role field of the exporter context (). 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.

Procedures

Initial Establishment

Initial Establishment | |<--------[INIT-ACK]--------------------------+ +---------[COOKIE ECHO]---------------------->| 2. 3. |<--------[COOKIE ACK]------------------------+ | | | TLS client KM server KM TLS | | | | | | | 4. | |<---+ SSL_connect() SSL_accept() +--->| | 5. | | | | | | | |<---+-----------------------------+--->| | 6. | | | | | | | | | | | | 7. | +--->| READ installed | | | | | +-----------[RKI]------------>| | | 8b. | | | |<---+ | 8a. | | | (wait for done + client RKI)| | | | | | (install R+W, enforce) | | | | | |<-----------[RKI]------------+ | | 9. | | | READ installed, enforce | | | | | | | | | | | -. 10. +---------[protected APP DATA]--------------->| | APP +<--------[protected APP DATA]----------------+ +--- | ... | | ]]> Legend: TLS = local TLS engine; client KM/server KM = client/server key manager; RKI = Read Key Installed control message; R+W = read and write keys. The diagram 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 key managers drive TLS solely through the TLS user API. The procedure is as follows:

The Initiator sends INIT containing the DTLS Key Management Parameter (Section 4.1 of ) with this method's identifier (see ) in its preference-ordered list.
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 ) and verifies that the selected method matches the one defined in this document (see ) and gets the assigned role as key manager client or server (in the example depicted in it is server).
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 it is client).
The client key manager starts a TLS 1.3 handshake, limiting offered cipher suites to those supported by the DTLS Chunk Protection Operator, and relays the resulting flight of TLS records to the server key manager per .
The server key manager starts a TLS 1.3 server and is ready to relay any received TLS records to the TLS server and to forward any TLS records produced by the TLS server to the client key manager per .
The TLS endpoints continue to exchange TLS messages to complete the TLS handshake.
The client key manager's TLS handshake completes. It exports all Primary and Restart DKC keys, installs the server to client key material as its read (receive) key, and sends a Read Key Installed control message () to the server key manager.
The server key manager proceeds only after both its own TLS handshake has completed (8a) and it has received the client key manager's Read Key Installed control message (8b). Once both conditions are met, it exports both direction key material for both the Primary and Restart DKCs, installs both the read (receive) key and the write (send) key, calls Require Protected SCTP Packets to enforce DTLS chunk protection for all future packets, informs the ULP that the association is protected, and sends a Read Key Installed control message () to the client key manager.
The client key manager receives the Read Key Installed control message, 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.
Protected application traffic can begin.

If the TLS handshake fails in step 6, it SHOULD be retried according to . After key installation, the TLS connection SHOULD be closed promptly following the procedure in .

Rekeying

Triggering Criteria Rekeying is triggered by implementation-configurable criteria, including:

Time elapsed since last peer authentication.
Volume of data transferred since last rekeying.
Approaching the cipher suite's AEAD usage limits.

Procedure The client key manager and the server key manager keep the same key management roles for the entire lifetime of the SCTP association: the client key manager is always the TLS client and the server key manager is always the TLS server, for the initial handshake and for every rekeying. Consequently, only the client key manager ever initiates a TLS handshake. This allows an endpoint holding only the client role to implement only a TLS client, and an endpoint holding only the server role to implement only a TLS server. Either endpoint may need to rekey. The need is acted upon as follows:

If the client key manager needs to rekey, it directly initiates a rekeying TLS handshake.
If the server key manager needs to rekey, it cannot initiate a TLS handshake itself. Instead it sends a Rekey Request control message () to the client key manager, which then initiates the rekeying TLS handshake.

Because the key management messages are carried on SCTP stream 0 with reliable, in-order delivery, the Rekey Request and all handshake messages are guaranteed to be delivered and are not lost; no key-management-level retransmission is required.

Rekeying Procedure | | 4. | | | | | | | |<---+-----------------------------+--->| | 5. | | | | | | 6. | +--->| READ (epoch N+1) | | | | | +---------[RKI]-------------->| | | 7b. | | | |<---+ | 7a. | | | (wait own done + cli RKI) | | | | | | (install R+W N+1, drain, | | | | | | TX->N+1) | | | | | |<--------[RKI]---------------+ | | 8. | | | READ N+1, drain, TX->N+1 | | | | | | | | | | (traffic transitions to epoch N+1 DKC) | | (after draining, remove epoch N DKC) | ]]> Legend: TLS = local TLS engine; client KM/server KM = client/server key manager; Rekey Req = Rekey Request control message; RKI = Read Key Installed control message; R+W = read and write keys; N, N+1 = old and new epoch; TX->N+1 = switch sending to the epoch N+1 DKC. The diagram in shows both triggers. Steps 1 and 2 (the Rekey Request) are present only when the server key manager is the one that needs to rekey; when the client key manager needs to rekey it starts directly at step 3. As in initial establishment, the key managers drive TLS solely through the TLS user API. The procedure is as follows:

If the server key manager needs to rekey, it sends a Rekey Request control message () to the client key manager. The server key manager does not start a TLS handshake.
The client key manager receives the Rekey Request. If it is not already rekeying, it proceeds to initiate a rekeying TLS handshake (step 3). If it is already rekeying, it ignores the Rekey Request (see ).
The client key manager starts a rekeying TLS handshake for epoch N+1 and relays the resulting flight of TLS records to the server key manager per .
The server key manager awaits the rekeying TLS handshake as a TLS server.
The TLS endpoints continue exchange TLS messages to complete the TLS handshake.
The client key manager's TLS handshake completes. It exports all Primary and Restart DKC keys for epoch N+1, installs the server to client key material as its read (receive) key, and sends a Read Key Installed control message () to the server key manager.
The server key manager proceeds only after both its own TLS handshake has completed (7a) and it has received the client key manager's Read Key Installed control message (7b). Once both conditions are met, it exports both direction key material for both the Primary and Restart DKCs for epoch N+1, installs both the read (receive) key and the write (send) key, starts the drain timer to remove the old (epoch N) DKC, and switches sending to the epoch N+1 DKC. The server key manager sends a Read Key Installed control message () to the client key manager.
The client key manager receives the Read Key Installed control message (), installs the client key material as its write (send) key, starts the drain timer to remove the old (epoch N) DKC, and switches sending to the epoch N+1 DKC.

If the TLS handshake fails in step 5, it SHOULD be retried according to . The new DKCs use epoch N+1 (where N is the current epoch when initiating rekeying). Both old (epoch N) and new (epoch N+1) DKCs coexist temporarily until the drain timer expires (see ). All rekeying MUST use ephemeral key exchange.

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. When the client KM receives the Read Key Installed control message in Step 8, installs the write key and starts the drain timer it do knows that the server endpoint already is sending using the new DKC. Thus it can set a short timer to allow any reordered or delayed packets has been drained before removing the old DKS. A value of 3 seconds are recommended. The server drain timer value depends on whether the delivery of the final rekeying message has been confirmed:

If delivery of the server's Read Key Installed control message has been confirmed (e.g., through SCTP acknowledgment of the DATA chunk carrying control message, the old DKC MAY be removed after a short drain timer. A value of 3 seconds is RECOMMENDED in this case to allow for reordered or delayed packets to arrive.
If delivery of the Read Key Installed control message sent by this endpoint has not been confirmed, the drain timer MUST be set to at least the SCTP association failure time (T_fail). This ensures first of all that the ULP traffic is not impacted by the drainage, and 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 ). With the default values from (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 Read Key Installed message has not been confirmed.

Concurrent Rekey Requests Because only the client key manager ever initiates a TLS handshake, two ClientHellos cannot cross and no tie-breaker is needed. The only concurrency to resolve is when the server key manager sends a Rekey Request while the client key manager has already initiated (or is about to initiate) a rekeying to epoch N+1. Since both the direct client trigger and the server's Rekey Request lead to the same outcome, a single client-initiated rekeying to epoch N+1, the client key manager treats an incoming Rekey Request as redundant and ignores it while a rekeying is already in progress. Similarly, if the server key manager needs to rekey while a client-initiated rekeying is already in progress, it does not send a Rekey Request, as the in-progress rekeying already satisfies the need.

SCTP Association Restart

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 ).
Both endpoints MUST have indicated restart support (R bit) in the DTLS Key Management Parameter.

Restart Procedure

The restarting endpoint (Initiator) retrieves the restart key material from persistent secure storage and installs the Restart DKC for both send and receive directions.
The Initiator sends INIT (VTag=0). Include the DTLS Key Management Parameter with the same method list and the same role and restart settings, but a new random Tie Breaker.
The Responder (the not restarting endpoint) replies INIT-ACK in plain text per . Include the DTLS Key Management Parameter with the same method list and the same role and restart settings, but a new random Tie Breaker.
The Initiator sends COOKIE ECHO in a DTLS chunk protected with the Restart DKC (R bit set).
The Responder replies COOKIE ACK in a DTLS chunk protected with the Restart DKC (R bit set).
Both endpoints have a restarted association, whose state is as described in Section 5.2.4.1 of , with two differences specific to this document: DTLS chunk protection is enforced using the Restart DKC (the COOKIE ECHO and COOKIE ACK were exchanged protected with it), and the DTLS Key Management Client and Server roles may differ from those of the previous instance of the association, since the new INIT handshake re-runs role determination. The authenticated peer identity, however, MUST remain the same as in the previous instance of the association (see ). The ULP MAY be informed that the association is restarted at this point. ULP traffic MAY begin immediately using the Restart DKC.
Steps 7 to 12 perform the TLS 1.3 handshake and key installation, and correspond one-to-one to steps 4 to 9 of the initial establishment procedure (). They differ only as follows:
- all key management messages are carried inside DTLS chunks protected with the Restart DKC;
- in addition to the Primary DKC, each endpoint exports, installs, and commits the new Restart DKC to persistent secure storage, removing the old one;
- at the key transition (steps 11 and 12), each endpoint switches the active DTLS key context from the Restart DKC to the new Primary DKC after the Read Key Installed exchange completes (the Read Key Installed messages themselves are protected with the Restart DKC), rather than enforcing protection for the first time; the ULP was already informed at step 6.

Protected application traffic uses the new Primary DKC.

After restart, the new Primary DKC is required to use epoch 3 (the epoch resets), see . 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.

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 ) with the TLS records for DTLS Chunk Key Management PPID (4242). If a TLS handshake fails during initial establishment and the implementation determines that it can address the cause of the error (for example, by retrying with different parameters, as long as doing so does not compromise security), it SHOULD retry the TLS handshake. Otherwise, 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 limits, the association MUST be aborted.

Security Considerations

General The security considerations given in , , and also apply to this document. BCP 195 provides recommendations and requirements for improving the security of deployed services that use TLS. BCP 195 MUST be followed.

Privacy Considerations Although 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, 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. It is RECOMMENDED that implementations of this key management method do not allow the ULP to exchange any data beyond the key management information following this specification until the peer is authenticated and the local endpoint and the remote endpoint have both installed read and write keys and enforced protection. This is to avoid any information leakage from the ULP to unintended parties.

IANA Considerations

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 to identify the key management method defined in this document. DTLS Key Management Method Identifier

Identifier	Key Management Method Name	Reference	Contact
192	TLS based Key Management for SCTP DTLS Chunk	RFC-TBD	Draft Authors

TLS Exporter Labels IANA is requested to register the following value in the TLS Exporter Label Registry with Reference RFC-TBD and empty Comment. TLS Exporter Label

Value	DTLS-OK	Recommended
EXPORTER_TLS_FOR_DTLS_IN_SCTP	Y	N

DTLS Chunk Key Management Control Message Types IANA is requested to create a new registry called "DTLS Chunk Key Management Control Message Types" in the Stream Control Transmission Protocol (SCTP) Parameters group. This registry governs the values of the Ctrl Type field of the control messages defined in . The registration policy for this registry is IETF Review as defined in . Each entry in the registry MUST contain the following fields:

Ctrl Type: an 8-bit unsigned integer value (0x00-0xFF).
Name: a short, human-readable name for the control message type.
Reference: a reference to the document defining the control message type.

The initial contents of the registry are shown in . The value 0x00 is reserved. DTLS Chunk Key Management Control Message Types

Ctrl Type	Name	Reference
0x00	Reserved	RFC-TBD
0x01	Read Key Installed	RFC-TBD
0x02	Rekey Request	RFC-TBD
0x03-0xFF	Unassigned

SCTP Payload Protocol Identifier In the Stream Control Transmission Protocol (SCTP) Parameters group's "Payload Protocol Identifiers" registry, IANA is requested to update the name and reference for the PPID 4242 as depicted in . Furthermore, IANA is requested to add an entry in the "Payload Protocol Identifiers" registry for the PPID 4243 as depicted in . Payload Protocol Identifier

ID Value	SCTP Payload Protocol Identifier	Reference
4242	TLS records for DTLS Chunk Key Management	RFC-To-Be
4243	Control Messages for DTLS Chunk Key Management	RFC-To-Be