draft-ietf-tsvwg-dtls-over-sctp-bis-02.txt   draft-ietf-tsvwg-dtls-over-sctp-bis-03.txt 
TSVWG M. Westerlund TSVWG M. Westerlund
Internet-Draft J. Preuß Mattsson Internet-Draft J. Preuß Mattsson
Obsoletes: 6083 (if approved) C. Porfiri Obsoletes: 6083 (if approved) C. Porfiri
Intended status: Standards Track Ericsson Intended status: Standards Track Ericsson
Expires: 28 April 2022 25 October 2021 Expires: 8 September 2022 7 March 2022
Datagram Transport Layer Security (DTLS) over Stream Control Datagram Transport Layer Security (DTLS) over Stream Control
Transmission Protocol (SCTP) Transmission Protocol (SCTP)
draft-ietf-tsvwg-dtls-over-sctp-bis-02 draft-ietf-tsvwg-dtls-over-sctp-bis-03
Abstract Abstract
This document describes the usage of the Datagram Transport Layer This document describes the usage of the Datagram Transport Layer
Security (DTLS) protocol to protect user messages sent over the Security (DTLS) protocol to protect user messages sent over the
Stream Control Transmission Protocol (SCTP). It is an improved Stream Control Transmission Protocol (SCTP). It is an improved
update of the existing rfc6083. update of the existing rfc6083.
DTLS over SCTP provides mutual authentication, confidentiality, DTLS over SCTP provides mutual authentication, confidentiality,
integrity protection, and replay protection for applications that use integrity protection, and replay protection for applications that use
skipping to change at page 1, line 40 skipping to change at page 1, line 40
user message size by defining a secure user message fragmentation so user message size by defining a secure user message fragmentation so
that multiple DTLS records can be used to protect a single user that multiple DTLS records can be used to protect a single user
message. It further updates the DTLS versions to use, as well as the message. It further updates the DTLS versions to use, as well as the
HMAC algorithms for SCTP-AUTH, and simplifies secure implementation HMAC algorithms for SCTP-AUTH, and simplifies secure implementation
by some stricter requirements on the establishment procedures. by some stricter requirements on the establishment procedures.
Discussion Venues Discussion Venues
This note is to be removed before publishing as an RFC. This note is to be removed before publishing as an RFC.
Discussion of this document takes place on the TSVWG Working Group
mailing list (tsvwg@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/tsvwg/.
Source for this draft and an issue tracker can be found at Source for this draft and an issue tracker can be found at
https://github.com/gloinul/draft-westerlund-tsvwg-dtls-over-sctp-bis. https://github.com/gloinul/draft-westerlund-tsvwg-dtls-over-sctp-bis.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 28 April 2022. This Internet-Draft will expire on 8 September 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1. Comparison with TLS for SCTP . . . . . . . . . . . . 5 1.1.1. Comparison with TLS for SCTP . . . . . . . . . . . . 5
1.1.2. Changes from RFC 6083 . . . . . . . . . . . . . . . . 5 1.1.2. Changes from RFC 6083 . . . . . . . . . . . . . . . . 5
1.2. DTLS Version . . . . . . . . . . . . . . . . . . . . . . 6 1.2. DTLS Version . . . . . . . . . . . . . . . . . . . . . . 6
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7 1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
1.4. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 7 1.4. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 7
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 8 3. DTLS Considerations . . . . . . . . . . . . . . . . . . . . . 8
3.1. Version of DTLS . . . . . . . . . . . . . . . . . . . . . 8 3.1. Version of DTLS . . . . . . . . . . . . . . . . . . . . . 8
3.2. Cipher Suites and Cryptographic Parameters . . . . . . . 8 3.2. Cipher Suites and Cryptographic Parameters . . . . . . . 8
3.3. Message Sizes . . . . . . . . . . . . . . . . . . . . . . 8 3.3. Message Sizes . . . . . . . . . . . . . . . . . . . . . . 8
3.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 9 3.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 9
3.5. Path MTU Discovery . . . . . . . . . . . . . . . . . . . 9 3.5. Path MTU Discovery . . . . . . . . . . . . . . . . . . . 10
3.6. Retransmission of Messages . . . . . . . . . . . . . . . 10 3.6. Retransmission of Messages . . . . . . . . . . . . . . . 10
4. SCTP Considerations . . . . . . . . . . . . . . . . . . . . . 10 4. SCTP Considerations . . . . . . . . . . . . . . . . . . . . . 10
4.1. Mapping of DTLS Records . . . . . . . . . . . . . . . . . 10 4.1. Mapping of DTLS Records . . . . . . . . . . . . . . . . . 10
4.2. DTLS Connection Handling . . . . . . . . . . . . . . . . 12 4.2. DTLS Connection Handling . . . . . . . . . . . . . . . . 12
4.3. Payload Protocol Identifier Usage . . . . . . . . . . . . 13 4.3. Payload Protocol Identifier Usage . . . . . . . . . . . . 13
4.4. Stream Usage . . . . . . . . . . . . . . . . . . . . . . 13 4.4. Stream Usage . . . . . . . . . . . . . . . . . . . . . . 13
4.5. Chunk Handling . . . . . . . . . . . . . . . . . . . . . 13 4.5. Chunk Handling . . . . . . . . . . . . . . . . . . . . . 14
4.6. SCTP-AUTH Hash Function . . . . . . . . . . . . . . . . . 14 4.6. SCTP-AUTH Hash Function . . . . . . . . . . . . . . . . . 15
4.7. Parallel DTLS connections . . . . . . . . . . . . . . . . 14 4.7. Parallel DTLS connections . . . . . . . . . . . . . . . . 15
4.8. Renegotiation and KeyUpdate . . . . . . . . . . . . . . . 16 4.8. Renegotiation and KeyUpdate . . . . . . . . . . . . . . . 17
4.8.1. DTLS 1.2 Considerations . . . . . . . . . . . . . . . 17 4.8.1. DTLS 1.2 Considerations . . . . . . . . . . . . . . . 18
4.8.2. DTLS 1.3 Considerations . . . . . . . . . . . . . . . 17 4.8.2. DTLS 1.3 Considerations . . . . . . . . . . . . . . . 18
4.9. DTLS Epochs . . . . . . . . . . . . . . . . . . . . . . . 17 4.9. DTLS Epochs . . . . . . . . . . . . . . . . . . . . . . . 18
4.9.1. DTLS 1.2 Considerations . . . . . . . . . . . . . . . 17 4.9.1. DTLS 1.2 Considerations . . . . . . . . . . . . . . . 18
4.9.2. DTLS 1.3 Considerations . . . . . . . . . . . . . . . 17 4.9.2. DTLS 1.3 Considerations . . . . . . . . . . . . . . . 18
4.10. Handling of Endpoint-Pair Shared Secrets . . . . . . . . 18 4.10. Handling of Endpoint-Pair Shared Secrets . . . . . . . . 19
4.10.1. DTLS 1.2 Considerations . . . . . . . . . . . . . . 18 4.10.1. DTLS 1.2 Considerations . . . . . . . . . . . . . . 19
4.10.2. DTLS 1.3 Considerations . . . . . . . . . . . . . . 18 4.10.2. DTLS 1.3 Considerations . . . . . . . . . . . . . . 19
4.11. Shutdown . . . . . . . . . . . . . . . . . . . . . . . . 19 4.11. Shutdown . . . . . . . . . . . . . . . . . . . . . . . . 20
5. DTLS over SCTP Service . . . . . . . . . . . . . . . . . . . 19 5. DTLS over SCTP Service . . . . . . . . . . . . . . . . . . . 21
5.1. Adaptation Layer Indication in INIT/INIT-ACK . . . . . . 19 5.1. Adaptation Layer Indication in INIT/INIT-ACK . . . . . . 21
5.2. DTLS over SCTP Initialization . . . . . . . . . . . . . . 19 5.2. DTLS over SCTP Initialization . . . . . . . . . . . . . . 21
5.3. Client Use Case . . . . . . . . . . . . . . . . . . . . . 20 5.3. Client Use Case . . . . . . . . . . . . . . . . . . . . . 22
5.4. Server Use Case . . . . . . . . . . . . . . . . . . . . . 20 5.4. Server Use Case . . . . . . . . . . . . . . . . . . . . . 22
5.5. RFC 6083 Fallback . . . . . . . . . . . . . . . . . . . . 20 5.5. RFC 6083 Fallback . . . . . . . . . . . . . . . . . . . . 23
6. Socket API Considerations . . . . . . . . . . . . . . . . . . 21 5.5.1. Client Fallback . . . . . . . . . . . . . . . . . . . 23
6.1. Socket Option to Get the HMAC Identifier being Sent 5.5.2. Server Fallback . . . . . . . . . . . . . . . . . . . 24
(SCTP_SEND_HMAC_IDENT) . . . . . . . . . . . . . . . . . 21 6. SCTP API Consideration . . . . . . . . . . . . . . . . . . . 24
6.2. Exposing the HMAC Identifiers being Received . . . . . . 22 7. Socket API Considerations . . . . . . . . . . . . . . . . . . 25
6.3. Socket Option to Expose HMAC Identifier Usage 7.1. Socket Option to Get the HMAC Identifier being Sent
(SCTP_EXPOSE_HMAC_IDENT_CHANGES) . . . . . . . . . . . . 23 (SCTP_SEND_HMAC_IDENT) . . . . . . . . . . . . . . . . . 25
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 7.2. Exposing the HMAC Identifiers being Received . . . . . . 26
7.1. TLS Exporter Label . . . . . . . . . . . . . . . . . . . 23 7.3. Socket Option to Expose HMAC Identifier Usage
7.2. SCTP Adaptation Layer Indication Code Point . . . . . . . 23 (SCTP_EXPOSE_HMAC_IDENT_CHANGES) . . . . . . . . . . . . 26
8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
8.1. Cryptographic Considerations . . . . . . . . . . . . . . 24 8.1. TLS Exporter Label . . . . . . . . . . . . . . . . . . . 27
8.2. Downgrade Attacks . . . . . . . . . . . . . . . . . . . . 26 8.2. SCTP Adaptation Layer Indication Code Point . . . . . . . 27
8.3. Authentication and Policy Decisions . . . . . . . . . . . 26 9. Security Considerations . . . . . . . . . . . . . . . . . . . 27
8.4. Privacy Considerations . . . . . . . . . . . . . . . . . 26 9.1. Cryptographic Considerations . . . . . . . . . . . . . . 28
8.5. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 27 9.2. Downgrade Attacks . . . . . . . . . . . . . . . . . . . . 30
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 27 9.3. Targeting DTLS Messages . . . . . . . . . . . . . . . . . 30
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 9.4. Authentication and Policy Decisions . . . . . . . . . . . 30
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 28 9.5. Resumption and Tickets . . . . . . . . . . . . . . . . . 31
11.1. Normative References . . . . . . . . . . . . . . . . . . 28 9.6. Privacy Considerations . . . . . . . . . . . . . . . . . 31
11.2. Informative References . . . . . . . . . . . . . . . . . 29 9.7. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 31
Appendix A. Motivation for Changes . . . . . . . . . . . . . . . 31 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
12.1. Normative References . . . . . . . . . . . . . . . . . . 32
12.2. Informative References . . . . . . . . . . . . . . . . . 34
Appendix A. Motivation for Changes . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 36
1. Introduction 1. Introduction
1.1. Overview 1.1. Overview
This document describes the usage of the Datagram Transport Layer This document describes the usage of the Datagram Transport Layer
Security (DTLS) protocol, as defined in DTLS 1.2 [RFC6347], and DTLS Security (DTLS) protocol, as defined in DTLS 1.2 [RFC6347], and DTLS
1.3 [I-D.ietf-tls-dtls13], over the Stream Control Transmission 1.3 [I-D.ietf-tls-dtls13], over the Stream Control Transmission
Protocol (SCTP), as defined in [RFC4960] with Authenticated Chunks Protocol (SCTP), as defined in [RFC4960] with Authenticated Chunks
for SCTP (SCTP-AUTH) [RFC4895]. for SCTP (SCTP-AUTH) [RFC4895].
This specification provides mutual authentication of endpoints, This specification provides mutual authentication of endpoints,
confidentiality, integrity protection, and replay protection of user confidentiality, integrity protection, and replay protection of user
messages for applications that use SCTP as their transport protocol. messages for applications that use SCTP as their transport protocol.
Thus, it allows client/server applications to communicate in a way Thus, it allows client/server applications to communicate in a way
that is designed to give communications privacy and to prevent that is designed to give communications privacy and to prevent
eavesdropping and detect tampering or message forgery. DTLS/SCTP eavesdropping and detect tampering or message forgery. DTLS/SCTP
uses DTLS for mutual authentication, key exchange with perfect uses DTLS for mutual authentication, key exchange with forward
forward secrecy for SCTP-AUTH, and confidentiality of user messages. secrecy for SCTP-AUTH, and confidentiality of user messages. DTLS/
DTLS/SCTP use SCTP and SCTP-AUTH for integrity protection and replay SCTP use SCTP and SCTP-AUTH for integrity protection and replay
protection of user messages. protection of user messages.
Applications using DTLS over SCTP can use almost all transport Applications using DTLS over SCTP can use almost all transport
features provided by SCTP and its extensions. DTLS/SCTP supports: features provided by SCTP and its extensions. DTLS/SCTP supports:
* preservation of message boundaries. * preservation of message boundaries.
* a large number of unidirectional and bidirectional streams. * a large number of unidirectional and bidirectional streams.
* ordered and unordered delivery of SCTP user messages. * ordered and unordered delivery of SCTP user messages.
* the partial reliability extension as defined in [RFC3758]. * the partial reliability extension as defined in [RFC3758].
* the dynamic address reconfiguration extension as defined in * the dynamic address reconfiguration extension as defined in
[RFC5061]. [RFC5061].
* User messages of a size up to 2^64-1. * User messages of any size.
The method described in this document requires that the SCTP The method described in this document requires that the SCTP
implementation supports the optional feature of fragmentation of SCTP implementation supports the optional feature of fragmentation of SCTP
user messages as defined in [RFC4960]. The implementation is user messages as defined in [RFC4960]. The implementation is
required to have an SCTP API (for example the one described in required to have an SCTP API (for example the one described in
[RFC6458]) that supports partial user message delivery and also [RFC6458]) that supports partial user message delivery and also
recommended that I-DATA chunks as defined in [RFC8260] is used to recommended that I-DATA chunks as defined in [RFC8260] is used to
efficiently implement and support larger user messages. efficiently implement and support larger user messages.
To simplify implementation and reduce the risk for security holes, To simplify implementation and reduce the risk for security holes,
skipping to change at page 5, line 35 skipping to change at page 5, line 35
The DTLS over SCTP solution defined in RFC 6083 had the following The DTLS over SCTP solution defined in RFC 6083 had the following
limitations: limitations:
* The maximum user message size is 2^14 (16384) bytes, which is a * The maximum user message size is 2^14 (16384) bytes, which is a
single DTLS record limit. single DTLS record limit.
* DTLS 1.0 has been deprecated for RFC 6083 requiring at least DTLS * DTLS 1.0 has been deprecated for RFC 6083 requiring at least DTLS
1.2 [RFC8996]. This creates additional limitation as discussed in 1.2 [RFC8996]. This creates additional limitation as discussed in
Section 1.2. Section 1.2.
This update that replaces RFC 6083 defines the following changes: * DTLS messages that don't contain protected user message data where
limited to only be sent on Stream 0 and requiring that stream to
be in-order delivery which could potentially impact applicaitons.
This specification defines the following changes compared with RFC
6083:
* Removes the limitations on user messages sizes by defining a * Removes the limitations on user messages sizes by defining a
secure fragmentation mechanism. secure fragmentation mechanism. It is optional to support message
sizes over 2^64-1 bytes.
* Enable DTLS key-change without draining * Enable DTLS key-change without requiring draining all inflight
user message from SCTP.
* Mandates that more modern DTLS version are required (DTLS 1.2 or * Mandates that more modern DTLS version are used (DTLS 1.2 or 1.3)
1.3)
* Mandates support of modern HMAC algorithm (SHA-256) in the SCTP * Mandates support of modern HMAC algorithm (SHA-256) in the SCTP
authentication extension [RFC4895]. authentication extension [RFC4895].
* Recommends support of [RFC8260] to enable interleaving of large * Recommends support of [RFC8260] to enable interleaving of large
SCTP user messages to avoid scheduling issues. SCTP user messages to avoid scheduling issues.
* Applies stricter requirements on always using DTLS for all user * Applies stricter requirements on always using DTLS for all user
messages in the SCTP association. messages in the SCTP association.
* Requires that SCTP-AUTH is applied to all SCTP Chunks that can be * Requires that SCTP-AUTH is applied to all SCTP Chunks that can be
authenticated. authenticated.
* Requires support of partial delivery of user messages. * Requires support of partial delivery of user messages.
1.2. DTLS Version 1.2. DTLS Version
* The number of renegotiations in DTLS 1.2 is limited to 65534
compared to unlimited in DTLS 1.0.
Using DTLS 1.2 instead of using DTLS 1.0 limits the lifetime of a Using DTLS 1.2 instead of using DTLS 1.0 limits the lifetime of a
DTLS connection and the data volume which can be transferred over a DTLS connection and the data volume which can be transferred over a
DTLS connection. This is caused by: DTLS connection. This is caused by:
* The number of renegotiations in DTLS 1.2 is limited to 65534 * The number of renegotiations in DTLS 1.2 is limited to 65534
compared to unlimited in DTLS 1.0. compared to unlimited in DTLS 1.0.
* While the AEAD limits in DTLS 1.3 does not formally apply to DTLS * While the AEAD limits in DTLS 1.3 does not formally apply to DTLS
1.2 the mathematical limits apply equally well to DTLS 1.2. 1.2 the mathematical limits apply equally well to DTLS 1.2.
skipping to change at page 6, line 39 skipping to change at page 6, line 42
* Strict AEAD significantly limits on how much many packets can be * Strict AEAD significantly limits on how much many packets can be
sent before rekeying. sent before rekeying.
Many applications using DTLS/SCTP are of semi-permanent nature and Many applications using DTLS/SCTP are of semi-permanent nature and
use SCTP associations with expected lifetimes of months or even use SCTP associations with expected lifetimes of months or even
years, and where there is a significant cost of bringing down the years, and where there is a significant cost of bringing down the
SCTP association in order to restart it. Such DTLS/SCTP usages that SCTP association in order to restart it. Such DTLS/SCTP usages that
need: need:
* Periodic re-authentication of both endpoints (not only the DTLS * Periodic re-authentication and transfer of revocation information
client). of both endpoints (not only the DTLS client).
* Periodic rerunning of Diffie-Hellman key-exchange to provide * Periodic rerunning of Diffie-Hellman key-exchange to provide
Perfect Forward Secrecy (PFS) to reduce the impact any key-reveal. forward secrecy and mitigate static key exfiltration attacks.
* Perform SCTP-AUTH re-keying. * Perform SCTP-AUTH rekeying.
At the time of publication DTLS 1.3 does not support any of these, At the time of publication DTLS 1.3 does not support any of these,
where DTLS 1.2 renegotiation functionality can provide this where DTLS 1.2 renegotiation functionality can provide this
functionality in the context of DTLS/SCTP. To address these functionality in the context of DTLS/SCTP. To address these
requirements from semi-permanent applications, this document use requirements from semi-permanent applications, this document use
several overlapping DTLS connections with either DTLS 1.2 or 1.3. several overlapping DTLS connections with either DTLS 1.2 or 1.3.
Having uniform procedures reduces the impact when upgrading from 1.2 Having uniform procedures reduces the impact when upgrading from 1.2
to 1.3 and avoids using the renegotiation mechanism which is disabled to 1.3 and avoids using the renegotiation mechanism which is disabled
by default in many DTLS implementations. by default in many DTLS implementations.
skipping to change at page 7, line 46 skipping to change at page 7, line 42
1.4. Abbreviations 1.4. Abbreviations
AEAD: Authenticated Encryption with Associated Data AEAD: Authenticated Encryption with Associated Data
DTLS: Datagram Transport Layer Security DTLS: Datagram Transport Layer Security
HMAC: Keyed-Hash Message Authentication Code HMAC: Keyed-Hash Message Authentication Code
MTU: Maximum Transmission Unit MTU: Maximum Transmission Unit
PFS: Perfect Forward Secrecy
PPID: Payload Protocol Identifier PPID: Payload Protocol Identifier
SCTP: Stream Control Transmission Protocol SCTP: Stream Control Transmission Protocol
SCTP-AUTH: Authenticated Chunks for SCTP SCTP-AUTH: Authenticated Chunks for SCTP
TCP: Transmission Control Protocol TCP: Transmission Control Protocol
TLS: Transport Layer Security TLS: Transport Layer Security
ULP: Upper Layer Protocol ULP: Upper Layer Protocol
2. Conventions 2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
skipping to change at page 8, line 32 skipping to change at page 8, line 28
This document defines the usage of either DTLS 1.3 This document defines the usage of either DTLS 1.3
[I-D.ietf-tls-dtls13], or DTLS 1.2 [RFC6347]. Earlier versions of [I-D.ietf-tls-dtls13], or DTLS 1.2 [RFC6347]. Earlier versions of
DTLS MUST NOT be used (see [RFC8996]). DTLS 1.3 is RECOMMENDED for DTLS MUST NOT be used (see [RFC8996]). DTLS 1.3 is RECOMMENDED for
security and performance reasons. It is expected that DTLS/SCTP as security and performance reasons. It is expected that DTLS/SCTP as
described in this document will work with future versions of DTLS. described in this document will work with future versions of DTLS.
3.2. Cipher Suites and Cryptographic Parameters 3.2. Cipher Suites and Cryptographic Parameters
For DTLS 1.2, the cipher suites forbidden by [RFC7540] MUST NOT be For DTLS 1.2, the cipher suites forbidden by [RFC7540] MUST NOT be
used. For all versions of DTLS, cryptographic parameters giving used. For all versions of DTLS, cryptographic parameters giving
confidentiality and Perfect Forward Secrecy (PFS) MUST be used. confidentiality and forward secrecy MUST be used.
3.3. Message Sizes 3.3. Message Sizes
DTLS/SCTP, automatically fragments and reassembles user messages. DTLS/SCTP, automatically fragments and reassembles user messages.
This specification defines how to fragment the user messages into This specification defines how to fragment the user messages into
DTLS records, where each DTLS record allows a maximum of 2^14 DTLS records, where each DTLS record allows a maximum of 2^14
protected bytes. Each DTLS record adds some overhead, thus using protected bytes. Each DTLS record adds some overhead, thus using
records of maximum possible size are recommended to minimize the records of maximum possible size are recommended to minimize the
transmitted overhead. DTLS 1.3 has much less overhead than DTLS 1.2 transmitted overhead. DTLS 1.3 has much less overhead than DTLS 1.2
per record. per record.
The sequence of DTLS records is then fragmented into DATA or I-DATA The sequence of DTLS records is then fragmented into DATA or I-DATA
Chunks to fit the path MTU by SCTP. The largest possible user Chunks to fit the path MTU by SCTP. These changes ensures that DTLS/
messages using the mechanism defined in this specification is 2^64-1 SCTP has the same capability as SCTP to support user messages of any
bytes. size. However, to simplify implementations it is OPTIONAL to support
user messages larger than 2^64-1 bytes. This is to allow
implementation to assume that 64-bit length fields and offset
pointers will be sufficient.
Another implementation dependent exception to the support of any user
message size is the SCTP-API defined in [RFC6458]. That API does not
allow changing the SCTP-AUTH key used to send a particular user
message. Thus, the user message size must be limited such that
completion of the user message can occur within a short time frame
from the establishment of the new DTLS connection (Section 4.7).
The security operations and reassembly process requires that the The security operations and reassembly process requires that the
protected user message, i.e., with DTLS record overhead, is buffered protected user message, i.e., with DTLS record overhead, is buffered
in the receiver. This buffer space will thus put a limit on the in the receiver. This buffer space will thus put a limit on the
largest size of plain text user message that can be transferred largest size of plain text user message that can be transferred
securely. However, by mandating the use of the partial delivery of securely. However, by mandating the use of the partial delivery of
user messages from SCTP and assuming that no two messages received on user messages from SCTP and assuming that no two messages received on
the same stream are interleaved (as it is the case when using the API the same stream are interleaved (as it is the case when using the API
defined in [RFC6458]) the required buffering prior to DTLS processing defined in [RFC6458]) the required buffering prior to DTLS processing
can be limited to a single DTLS record per used incoming stream. can be limited to a single DTLS record per used incoming stream.
skipping to change at page 9, line 47 skipping to change at page 10, line 9
DTLS optionally supports record replay detection. Such replay DTLS optionally supports record replay detection. Such replay
detection could result in the DTLS layer dropping valid messages detection could result in the DTLS layer dropping valid messages
received outside of the DTLS replay window. As DTLS/SCTP provides received outside of the DTLS replay window. As DTLS/SCTP provides
replay protection even without DTLS replay protection, the replay replay protection even without DTLS replay protection, the replay
detection of DTLS MUST NOT be used. detection of DTLS MUST NOT be used.
3.5. Path MTU Discovery 3.5. Path MTU Discovery
DTLS Path MTU Discovery MUST NOT be used. Since SCTP provides Path DTLS Path MTU Discovery MUST NOT be used. Since SCTP provides Path
MTU discovery and fragmentation/reassembly for user messages, and MTU discovery and fragmentation/reassembly for user messages, and
according to Section 3.3, DTLS can send maximum sized DTLS Records. specified in Section 3.3, DTLS can send maximum sized DTLS Records.
3.6. Retransmission of Messages 3.6. Retransmission of Messages
SCTP provides a reliable and in-sequence transport service for DTLS SCTP provides a reliable and in-sequence transport service for DTLS
messages that require it. See Section 4.4. Therefore, DTLS messages that require it. See Section 4.4. Therefore, DTLS
procedures for retransmissions MUST NOT be used. procedures for retransmissions MUST NOT be used.
4. SCTP Considerations 4. SCTP Considerations
4.1. Mapping of DTLS Records 4.1. Mapping of DTLS Records
The SCTP implementation MUST support fragmentation of user messages The SCTP implementation MUST support fragmentation of user messages
using DATA [RFC4960], and optionally I-DATA [RFC8260] chunks. using DATA [RFC4960], and optionally I-DATA [RFC8260] chunks.
DTLS/SCTP works as a shim layer between the user message API and DTLS/SCTP works as a shim layer between the user message API and
SCTP. The fragmentation works similar as the DTLS fragmentation of SCTP. On the sender side a user message is split into fragments m0,
handshake messages. On the sender side a user message fragmented m1, m2, each no larger than 2^14 = 16384 bytes.
into fragments m0, m1, m2, each no larger than 2^14 = 16384 bytes.
m0 | m1 | m2 | ... = user_message m0 | m1 | m2 | ... = user_message
The resulting fragments are protected with DTLS and the records are The resulting fragments are protected with DTLS and the records are
concatenated concatenated
user_message' = DTLS( m0 ) | DTLS( m1 ) | DTLS( m2 ) ... user_message' = DTLS( m0 ) | DTLS( m1 ) | DTLS( m2 ) ...
The new user_message', i.e., the protected user message, is the input The new user_message', i.e., the protected user message, is the input
to SCTP. to SCTP.
On the receiving side DTLS is used to decrypt the individual records. On the receiving side, the length field in each DTLS record can be
There are three failure cases an implementation needs to detect and used to determine the boundaries between DTLS records. DTLS can
then act on: decrypt individual records or a concatenated sequence of records.
The last DTLS record can be found by subtracting the length of
individual records from the length of user_message'. Whether to
decrypt individual records, sequences of records, or the whole
user_message' is left to the implementation. The output from the
DTLS decryption(s) is the fragments m0, m1, m2 ... The user_message
is reassembled from decrypted DTLS records as user_message = m0 |
m1 | m2 ... There are three failure cases an implementation needs to
detect and then act on:
1. Failure in decryption and integrity verification process of any 1. Failure in decryption and integrity verification process of any
DTLS record. Due to SCTP-AUTH preventing delivery of injected or DTLS record. Due to SCTP-AUTH preventing delivery of injected or
corrupt fragments of the protected user message this should only corrupt fragments of the protected user message this should only
occur in case of implementation errors or internal hardware occur in case of implementation errors or internal hardware
failures or the necessary security context has been prematurely failures or the necessary security context has been prematurely
discarded. discarded.
2. In case the SCTP layer indicates an end to a user message, e.g., 2. In case the SCTP layer indicates an end to a user message, e.g.,
when receiving a MSG_EOR in a recvmsg() call when using the API when receiving a MSG_EOR in a recvmsg() call when using the API
skipping to change at page 11, line 31 skipping to change at page 11, line 39
delivery and the ULP is capable of recovering from this failure. delivery and the ULP is capable of recovering from this failure.
Note that if the SCTP extension for Partial Reliability (PR-SCTP) Note that if the SCTP extension for Partial Reliability (PR-SCTP)
[RFC3758] is used for a user message, user message may be partially [RFC3758] is used for a user message, user message may be partially
delivered or abandoned. These failures are not a reason for delivered or abandoned. These failures are not a reason for
terminating the DTLS connection and SCTP association. terminating the DTLS connection and SCTP association.
The DTLS Connection ID MUST be negotiated The DTLS Connection ID MUST be negotiated
([I-D.ietf-tls-dtls-connection-id] or Section 9 of ([I-D.ietf-tls-dtls-connection-id] or Section 9 of
[I-D.ietf-tls-dtls13]). If DTLS 1.3 is used, the length field in the [I-D.ietf-tls-dtls13]). If DTLS 1.3 is used, the length field in the
record layer MUST be included. A 16-bit sequence number SHOULD be record layer MUST be included in all records. A 16-bit sequence
used rather than 8-bit to minimize issues with DTLS record sequence number SHOULD be used rather than 8-bit to minimize issues with DTLS
number wrapping. record sequence number wrapping.
The ULP may use multiple messages simultanous, and the progress and The ULP may use multiple messages simultanous, and the progress and
delivery of these messages are progressing indepentely, thus the delivery of these messages are progressing indepentely, thus the
recieving DTLS/SCTP implementation may not receive records in order recieving DTLS/SCTP implementation may not receive records in order
in case of packet loss. Assuming that the sender will send the DTLS in case of packet loss. Assuming that the sender will send the DTLS
records in order the DTLS records where created (which may not be records in order the DTLS records where created (which may not be
certain in some implementations), then there is a risk that DTLS certain in some implementations), then there is a risk that DTLS
sequence number have wrapped if the amount of data in flight is more sequence number have wrapped if the amount of data in flight is more
than the sequence number covers. Thus, for 8-bit sequence number than the sequence number covers. Thus, for 8-bit sequence number
space with 16384 bytes records the receiver window only needs to be space with 16384 bytes records the receiver window only needs to be
skipping to change at page 12, line 33 skipping to change at page 12, line 39
record, it would have to be forwarded to the zero-length CID using record, it would have to be forwarded to the zero-length CID using
DTLS Connection and decryption and validation must be tried. DTLS Connection and decryption and validation must be tried.
Resulting in higher resource utilization. Thus, it is RECOMMENDED to Resulting in higher resource utilization. Thus, it is RECOMMENDED to
not use the zero length CID values and instead use a single common not use the zero length CID values and instead use a single common
length for the CID values. A single byte should be sufficient, as length for the CID values. A single byte should be sufficient, as
reuse of old CIDs is possible as long as the implementation ensure reuse of old CIDs is possible as long as the implementation ensure
they are not used in near time to the previous usage. they are not used in near time to the previous usage.
4.2. DTLS Connection Handling 4.2. DTLS Connection Handling
A DTLS connection MUST be established at the beginning of the SCTP DTLS/SCTP is negotiated on SCTP level as an adaptation layer
association. All DTLS connections are terminated when the SCTP Section 5. After a succesful negotiation of the DTLS/SCTP during
association is terminated. A DTLS connection MUST NOT span multiple SCTP association establishment, a DTLS connection MUST be established
SCTP associations. prior to transmission of any ULP user messages. All DTLS connections
are terminated when the SCTP association is terminated. A DTLS
connection MUST NOT span multiple SCTP associations.
As it is required to establish the DTLS connection at the beginning As it is required to establish the DTLS connection at the beginning
of the SCTP association, either of the peers should never send any of the SCTP association, either of the peers should never send any
SCTP user messages that are not protected by DTLS. So, the case that SCTP user messages that are not protected by DTLS. So, the case that
an endpoint receives data that is not either DTLS messages on Stream an endpoint receives data that is not either DTLS messages or
0 or protected user messages in the form of a sequence of DTLS protected user messages in the form of a sequence of DTLS Records on
Records on any stream is a protocol violation. The receiver MAY any stream is a protocol violation. The receiver MAY terminate the
terminate the SCTP association due to this protocol violation. SCTP association due to this protocol violation. Implementations
that does not have a DTLS endpoint immediately ready on SCTP
handshake completion will have to ensure correct caching of the
messages until the DTLS endpoint is ready.
Whenever a mutual authentication, updated security parameters, rerun Whenever a mutual authentication, updated security parameters, rerun
of Diffie-Hellman key-exchange , or SCTP-AUTH rekeying is needed, a of Diffie-Hellman key-exchange , or SCTP-AUTH rekeying is needed, a
new DTLS connection is instead setup in parallel with the old new DTLS connection is instead setup in parallel with the old
connection (i.e., there may be up to two simultaneous DTLS connection (i.e., there may be up to two simultaneous DTLS
connections within one association). connections within one association).
4.3. Payload Protocol Identifier Usage 4.3. Payload Protocol Identifier Usage
SCTP Payload Protocol Identifiers are assigned by IANA. Application SCTP Payload Protocol Identifiers are assigned by IANA. Application
protocols using DTLS over SCTP SHOULD register and use a separate protocols using DTLS over SCTP SHOULD register and use a separate
Payload Protocol Identifier (PPID) and SHOULD NOT reuse the PPID that Payload Protocol Identifier (PPID) and SHOULD NOT reuse the PPID that
they registered for running directly over SCTP. they registered for running directly over SCTP.
Using the same PPID does not harm as long as the application can Using the same PPID does no harm as DTLS/SCTP requires all user
determine whether or not DTLS is used. However, for protocol mesages being DTLS protected and knows that DTLS is used. However,
analyzers, for example, it is much easier if a separate PPID is used. for protocol analyzers, for example, it is much easier if a separate
PPID is used and avoids different behavior from [RFC6083]. This
means, in particular, that there is no specific PPID for DTLS.
This means, in particular, that there is no specific PPID for DTLS. Messages that are exchanged between DTLS/SCTP peers not containing
ULP user messages shall use PPID=0 according to section 3.3.1 of
[RFC4960] as no application identifier can be specified by the upper
layer for this payload data.
4.4. Stream Usage 4.4. Stream Usage
DTLS records with a content type different from "application_data" DTLS 1.3 protects the actual content type of the DTLS record and have
(e.g., "handshake", "alert", ...) MUST be transported on stream 0 therefore omitted the non-protected content type field. Thus, it is
with unlimited reliability and with the ordered delivery feature. not possible to determine which content type the DTLS record has on
SCTP level. For DTLS 1.2 ULP user messages will be carried in DTLS
records with content type "application_data".
DTLS records of content type "application_data", which carries the DTLS Records carrying protected user message fragments MUST be sent
protected user messages MAY be sent in SCTP messages on any stream, in the by ULP indicated SCTP stream and user message. The ULP has no
including stream 0. On stream 0 the DTLS record containing the part limitations in using SCTP facilities for stream and user messages.
of protected message, as well as any DTLS messages that aren't record DTLS records of other types MAY be sent on any stream. It MAY also
protocol will be mixed, thus the additional head of line blocking can be sent in its own SCTP user message as well as interleaved with
occur. Therefore, applications are RECOMMENDED to send its protected other DTLS records carrying protected user messages. Thus, it is
user messages using multiple streams, and on other streams than allowed to insert between protected user message fragments DTLS
stream 0. records of other types as the DTLS receiver will process these and
not result in any user message data being inserted into the ULP's
user message. However, DTLS messages of other types than protected
user message MUST be sent reliable, so the DTLS record can only be
interleaved in case the ULP user message is sent as reliable.
DTLS is capable of handling reordering of the DTLS records. However,
depending on stream properties and which user message DTLS records of
other types are sent in may impact in which order and how quickly
they are possible to process. Using a stream with in-order delivery
will ensure that the DTLS Records are delivered in the order they are
sent in user messages. Thus, ensuring that if there are DTLS records
that need to be delivered in particular order it can be ensured.
Alternatively, if it is desired that a DTLS record is delvired as
early as possible avoiding in-order streams with queued messages and
considering stream priorities can result in faster delviery.
A simple solution avoiding any protocol issue are to send all DTLS
messages that are not protected user message fragments is to pick a
stream not used by the ULP, send the DTLS messages in their own user
messages with in order delivery. That mimics the RFC 6083 behavior
without impacting the ULP.
4.5. Chunk Handling 4.5. Chunk Handling
DATA chunks of SCTP MUST be sent in an authenticated way as described DATA chunks of SCTP MUST be sent in an authenticated way as described
in SCTP-AUTH [RFC4895]. All other chunks that can be authenticated, in SCTP-AUTH [RFC4895]. All other chunks that can be authenticated,
i.e., all chunk types that can be listed in the Chunk List Parameter i.e., all chunk types that can be listed in the Chunk List Parameter
[RFC4895], MUST also be sent in an authenticated way. This makes [RFC4895], MUST also be sent in an authenticated way. This makes
sure that an attacker cannot modify the stream in which a message is sure that an attacker cannot modify the stream in which a message is
sent or affect the ordered/unordered delivery of the message. sent or affect the ordered/unordered delivery of the message.
skipping to change at page 14, line 23 skipping to change at page 15, line 19
When using DTLS/SCTP, the SHA-256 Message Digest Algorithm MUST be When using DTLS/SCTP, the SHA-256 Message Digest Algorithm MUST be
supported in the SCTP-AUTH [RFC4895] implementation. SHA-1 MUST NOT supported in the SCTP-AUTH [RFC4895] implementation. SHA-1 MUST NOT
be used when using DTLS/SCTP. [RFC4895] requires support and be used when using DTLS/SCTP. [RFC4895] requires support and
inclusion of SHA-1 in the HMAC-ALGO parameter, thus, to meet both inclusion of SHA-1 in the HMAC-ALGO parameter, thus, to meet both
requirements the HMAC-ALGO parameter will include both SHA-256 and requirements the HMAC-ALGO parameter will include both SHA-256 and
SHA-1 with SHA-256 listed prior to SHA-1 to indicate the preference. SHA-1 with SHA-256 listed prior to SHA-1 to indicate the preference.
4.7. Parallel DTLS connections 4.7. Parallel DTLS connections
To enable SCTP-AUTH re-rekeying, periodic authentication of both To enable SCTP-AUTH rekeying, periodic authentication of both
endpoints, and force attackers to dynamic key extraction [RFC7624], endpoints, and force attackers to dynamic key extraction [RFC7624],
DTLS/SCTP per this specification defines the usage of parallel DTLS DTLS/SCTP per this specification defines the usage of parallel DTLS
connections over the same SCTP association. This solution ensures connections over the same SCTP association. This solution ensures
that there are no limitations to the lifetime of the SCTP association that there are no limitations to the lifetime of the SCTP association
due to DTLS, it also avoids dependency on version specific DTLS due to DTLS, it also avoids dependency on version specific DTLS
mechanisms such as renegotiation in DTLS 1.2, which is disabled by mechanisms such as renegotiation in DTLS 1.2, which is disabled by
default in many DTLS implementations, or post-handshake messages in default in many DTLS implementations, or post-handshake messages in
DTLS 1.3, which does not allow mutual endpoint re-authentication or DTLS 1.3, which does not allow periodic mutual endpoint re-
re-keying of SCTP-AUTH. Parallel DTLS connections enable opening a authentication or re-keying of SCTP-AUTH. Parallel DTLS connections
new DTLS connection performing a handshake, while the existing DTLS enable opening a new DTLS connection performing a handshake, while
connection is kept in place. On handshake completion switch to the the existing DTLS connection is kept in place. In DTLS 1.3 the
security context of the new DTLS connection and then ensure delivery handshake MAY be a full handshake or a resumption handshake and
of all the SCTP chunks using the old DTLS connections security resumption can be done while the original connection is still open.
context. When that has been achieved close the old DTLS connection In DTLS 1.2 the handshake MUST be a full handshake. On handshake
and discard the related security context. completion switch to the security context of the new DTLS connection
and then ensure delivery of all the SCTP chunks using the old DTLS
connections security context. When that has been achieved close the
old DTLS connection and discard the related security context.
As specified in Section 4.1 the usage of DTLS connection ID is As specified in Section 4.1 the usage of DTLS connection ID is
required to ensure that the receiver can correctly identify the DTLS required to ensure that the receiver can correctly identify the DTLS
connection and its security context when performing its de-protection connection and its security context when performing its de-protection
operations. There is also only a single SCTP-AUTH key exported per operations. There is also only a single SCTP-AUTH key exported per
DTLS connection ensuring that there is clear mapping between the DTLS DTLS connection ensuring that there is clear mapping between the DTLS
connection ID and the SCTP-AUTH security context for each key-id. connection ID and the SCTP-AUTH security context for each key-id.
Application writers should be aware that establishing a new DTLS Application writers should be aware that establishing a new DTLS
connections may result in changes of security parameters. See connections may result in changes of security parameters. See
Section 8 for security considerations regarding rekeying. Section 9 for security considerations regarding rekeying.
A DTLS/SCTP Endpoint MUST NOT have more than two DTLS connections A DTLS/SCTP Endpoint MUST NOT have more than two DTLS connections
open at the same time. Either of the endpoints MAY initiate a new open at the same time. Either of the endpoints MAY initiate a new
DTLS connection by performing a full DTLS handshake. As either DTLS connection by performing a full DTLS handshake. As either
endpoint can initiate a DTLS handshake on either side at the same endpoint can initiate a DTLS handshake on either side at the same
time, either endpoint may receive a DTLS ClientHello when it has sent time, either endpoint may receive a DTLS ClientHello when it has sent
its own ClientHello. In this case the ClientHello from the endpoint its own ClientHello. In this case the ClientHello from the endpoint
that had the DTLS Client role in the establishment of the existing that had the DTLS Client role in the establishment of the existing
DTLS connection shall be continued to be processed and the other DTLS connection shall be continued to be processed and the other
dropped. dropped.
When performing the DTLS handshake the endpoint MUST verify that the When performing the DTLS handshake the endpoint MUST verify that the
peer identifies using the same identity as in the previous DTLS peer identifies using the same identity as in the previous DTLS
connection. connection.
When the DTLS handshake has been completed, a new SCTP-AUTH key will When the DTLS handshake has been completed, a new SCTP-AUTH key will
be exported per Section 4.10 and the new DTLS connection MUST be used be exported per Section 4.10 and the new DTLS connection MUST be used
for the DTLS protection operation of any future protected SCTP for the DTLS protection operation of any future protected ULP user
message. The endpoint is RECOMMENDED to use the security context of message. The endpoint is RECOMMENDED to use the security context of
the new DTLS connection for any DTLS protection operation occurring the new DTLS connection for any DTLS protection operation occurring
after the completed handshake. The new SCTP-AUTH key SHALL be used after the completed handshake. The new SCTP-AUTH key SHALL be used
for any SCTP message being sent after the DTLS handshake has for any SCTP user message being sent after the DTLS handshake has
completed. There is a possibility to use the new SCTP-AUTH key for completed. There is a possibility to use the new SCTP-AUTH key for
any SCTP packets part of an SCTP message that was initiated but not any SCTP packets part of an SCTP user message that was initiated but
yet fully transmitted prior to the completion of the new DTLS not yet fully transmitted prior to the completion of the new DTLS
handshake, however the API defined in [RFC6458] is not supporting handshake, however the API defined in [RFC6458] is not supporting
this. switching the SCTP-AUTH key on the sender side. Any SCTP-AUTH
receiver implementation is expected to be able to select key on SCTP
packet basis.
The SCTP endpoint will indicate to its peer when the previous DTLS The DTLS/SCTP endpoint will indicate to its peer when the previous
connection and its context are no longer needed for receiving any DTLS connection and its context are no longer needed for receiving
more data from this endpoint. This is done by having DTLS to send a any more data from this endpoint. This is done by having DTLS to
DTLS close_notify alert. The endpoint MUST NOT send the close_notify send a DTLS close_notify alert. The endpoint MUST NOT send the
until the following two conditions are fulfilled: close_notify until the following two conditions are fulfilled:
1. All SCTP packets containing part of any DTLS record or message 1. All SCTP packets containing part of any DTLS record or message
protected using the security context of this DTLS connection have protected using the security context of this DTLS connection have
been acknowledged in a non-renegable way. been acknowledged in a non-renegable way.
2. All SCTP packets using the SCTP-AUTH key associated with the 2. All SCTP packets using the SCTP-AUTH key associated with the
security context of this DTLS connection have been acknowledged security context of this DTLS connection have been acknowledged
in a non-renegable way. in a non-renegable way.
There is a very basic way of determining the above conditions for an Note: For DTLS 1.2 receiving Close_notify will close the DTLS
implementation that enables using the new DTLS connection's security connection for further writes and requires the immediate generation
context for all future DTLS records protected and enabling the of a Close_notify. Thus, this forces the DTLS/SCTP to protect any
associated new SCTP-AUTH key at the same time and not use the old buffered data on DTLS/SCTP layer not yet protected to use the new
context for any future protection operations. Mark the time when the DTLS connection. In addition the DTLS/SCTP layer will have to buffer
first SCTP chunk has been sent that is part of the first (partial) the close_notify generated by the shuting down DTLS connection and
SCTP message send call that uses the new security context. That SCTP also not discard the SCTP-AUTH key until it has fulfilled the
chunk and thus all previous chunks using the older security context delivery of the data protected by the closing DTLS connection
must have been delivered to the peer before the Endpoint Failure security context.
Detection (See Section 8.1 of [RFC4960] would trigger and terminate
the SCTP association. Calculate the upper limit for this timeout SCTP implementations exposing APIs like [RFC6458] fulfilling these
period, which is dependent on two configurable parameters. The conditions requires draining the SCTP association of all outstanding
maximum endpoint failure timeout period is the product of the data after having completed all the user messages using the previous
'Association.Max.Retrans' and RTO.Max parameters. For the default SCTP-AUTH key identifier. Relying on the SCTP_SENDER_DRY_EVENT to
values per [RFC4960] that would be 10 attempts time with an RTO.Max = know when delivery has been accomplished. A richer API could also be
60 s, i.e., 10 minutes. used that allows user message level tracking of delivery, see
Section 6 for API considerations.
For SCTP implementations exposing APIs like [RFC6458] where it is not For SCTP implementations exposing APIs like [RFC6458] where it is not
possible to change the SCTP-AUTH key for a partial SCTP message possible to change the SCTP-AUTH key for a partial SCTP message
initiated before the change of security context will be forced to initiated before the change of security context will be forced to
track the SCTP messages and determine when all using the old security track the SCTP messages and determine when all using the old security
context has been transmitted. This maybe be impossible to do context has been transmitted. This maybe be impossible to do
completely reliable without tighter integration between the DTLS/SCTP completely reliable without tighter integration between the DTLS/SCTP
layer and the SCTP implementation. This type of implementations also layer and the SCTP implementation. This type of implementations also
has an implicit limitation in how large SCTP messages it can support. has an implicit limitation in how large SCTP messages it can support.
Each SCTP message needs have completed delivery and enabling closing Each SCTP message needs have completed delivery and enabling closing
of the previous DTLS connection prior to the need to create yet of the previous DTLS connection prior to the need to create yet
another DTLS connection. Thus, SCTP messages can't be larger than another DTLS connection. Thus, SCTP messages can't be larger than
that the transmission completes in less than the duration between the that the transmission completes in less than the duration between the
rekeying or re-authentications needed for this SCTP association. rekeying or re-authentications needed for this SCTP association.
When the DTLS/SCTP implementation are more tightly integrated with
the SCTP stack or have a fuller API that enable the DTLS/SCTP
implementation to know when the SCPT messages have been delivered it
will be able to close down the old DTLS connection in a timelier
fashion, thus supporting more frequent rekeying etc. if needed.
The consequences of sending a DTLS close_notify alert in the old DTLS The consequences of sending a DTLS close_notify alert in the old DTLS
connection prior to the receiver having received the data can result connection prior to the receiver having received the data can result
in failure case 1 described in Section 4.1, which likely result in in failure case 1 described in Section 4.1, which likely result in
SCTP association termination. SCTP association termination.
4.8. Renegotiation and KeyUpdate 4.8. Renegotiation and KeyUpdate
DTLS 1.2 renegotiation enables rekeying (with ephemeral Diffie- DTLS 1.2 renegotiation enables rekeying (with ephemeral Diffie-
Hellman) of DTLS as well as mutual reauthentication inside an DTLS Hellman) of DTLS as well as mutual reauthentication and transfer of
1.2 connection. Renegotiation has been removed from DTLS 1.3 and revocation information inside an DTLS 1.2 connection. Renegotiation
partly replaced with post-handshake messages such as KeyUpdate. The has been removed from DTLS 1.3 and partly replaced with post-
parallel DTLS connection solution was specified due to lack of handshake messages such as KeyUpdate. The parallel DTLS connection
necessary features with DTLS 1.3 considered needed for long lived solution was specified due to lack of necessary features with DTLS
SCTP associations, such as rekeying (with ephemeral Diffie-Hellman) 1.3 considered needed for long lived SCTP associations, such as
as well as mutual reauthentication. rekeying (with ephemeral Diffie-Hellman) as well as mutual
reauthentication.
This specification do not allow usage of DTLS 1.2 renegotiation to This specification do not allow usage of DTLS 1.2 renegotiation to
avoid race conditions and corner cases in the interaction between the avoid race conditions and corner cases in the interaction between the
parallel DTLS connection mechanism and the keying of SCTP-AUTH. In parallel DTLS connection mechanism and the keying of SCTP-AUTH. In
addtion renegotiation is also disabled in implementation, as well as addtion renegotiation is also disabled in implementation, as well as
dealing with the epoch change reliable have similar or worse dealing with the epoch change reliable have similar or worse
applicaiton impact. applicaiton impact.
This specification also recommends against using DTLS 1.3 KeyUpdate This specification also recommends against using DTLS 1.3 KeyUpdate
and instead rely on parallel DTLS connections. For DTLS 1.3 there and instead rely on parallel DTLS connections. For DTLS 1.3 there
skipping to change at page 18, line 16 skipping to change at page 19, line 16
SCTP-AUTH [RFC4895] is keyed using Endpoint-Pair Shared Secrets. In SCTP-AUTH [RFC4895] is keyed using Endpoint-Pair Shared Secrets. In
SCTP associations where DTLS is used, DTLS is used to establish these SCTP associations where DTLS is used, DTLS is used to establish these
secrets. The endpoints MUST NOT use another mechanism for secrets. The endpoints MUST NOT use another mechanism for
establishing shared secrets for SCTP-AUTH. The endpoint-pair shared establishing shared secrets for SCTP-AUTH. The endpoint-pair shared
secret for Shared Key Identifier 0 is empty and MUST be used when secret for Shared Key Identifier 0 is empty and MUST be used when
establishing the first DTLS connection. establishing the first DTLS connection.
The initial DTLS connection will be used to establish a new shared The initial DTLS connection will be used to establish a new shared
secret as specified per DTLS version below, and which MUST use shared secret as specified per DTLS version below, and which MUST use shared
key identifier 1. After sending the DTLS Finished message, the key identifier 1. After sending the DTLS Finished message for the
active SCTP-AUTH key MUST be switched to the new one. Once the initial DTLS connection, the active SCTP-AUTH key MUST be switched
initial Finished message from the peer has been processed by DTLS, from key identifier 0 to key identifier 1. Once the initial Finished
the SCTP-AUTH key with Shared Key Identifier 0 MUST be removed. message from the peer has been processed by DTLS, the SCTP-AUTH key
with Shared Key Identifier 0 MUST be removed.
When a subsequent DTLS connection is setup, a new a 64-byte shared When a subsequent DTLS connection is setup, a new a 64-byte shared
secret is derived using the TLS-Exporter. The shared secret secret is derived using the TLS-Exporter. The shared secret
identifiers form a sequence. If the previous shared secret used identifiers form a sequence. If the previous shared secret used
Shared Key Identifier n, the new one MUST use Shared Key Identifier Shared Key Identifier n, the new one MUST use Shared Key Identifier
n+1, unless n= 65535, in which case the new Shared Key Identifier is n+1, unless n= 65535, in which case the new Shared Key Identifier is
1. 1.
After sending the DTLS Finished message, the active SCTP-AUTH key After sending the DTLS Finished message, the active SCTP-AUTH key
MUST be switched to the new one. When the endpoint has both sent and MUST be switched to the new one. When the endpoint has both sent and
skipping to change at page 18, line 41 skipping to change at page 19, line 42
SHALL remove shared secret(s) related to old DTLS connection. SHALL remove shared secret(s) related to old DTLS connection.
4.10.1. DTLS 1.2 Considerations 4.10.1. DTLS 1.2 Considerations
Whenever a new DTLS connection is established, a 64-byte Whenever a new DTLS connection is established, a 64-byte
endpoint-pair shared secret is derived using the TLS-Exporter endpoint-pair shared secret is derived using the TLS-Exporter
described in {{RFC5705}}. described in {{RFC5705}}.
The 64-byte shared secret MUST be provided to the SCTP stack as soon The 64-byte shared secret MUST be provided to the SCTP stack as soon
as the computation is possible. The exporter MUST use the label as the computation is possible. The exporter MUST use the label
given in Section 7 and no context. given in Section 8 and no context.
4.10.2. DTLS 1.3 Considerations 4.10.2. DTLS 1.3 Considerations
When the exporter_secret can be computed, a 64-byte shared secret is When the exporter_secret can be computed, a 64-byte shared secret is
derived from it and provided as a new endpoint-pair shared secret by derived from it and provided as a new endpoint-pair shared secret by
using the TLS-Exporter described in [RFC8446]. using the TLS-Exporter described in [RFC8446].
The 64-byte shared secret MUST be provided to the SCTP stack as soon The 64-byte shared secret MUST be provided to the SCTP stack as soon
as the computation is possible. The exporter MUST use the label as the computation is possible. The exporter MUST use the label
given in Section Section 7 and no context. given in Section Section 8 and no context.
4.11. Shutdown 4.11. Shutdown
To prevent DTLS from discarding DTLS user messages while it is To prevent DTLS from discarding DTLS user messages while it is
shutting down, a CloseNotify message MUST only be sent after all shutting down, the below procedure has been defined. Its goal is to
outstanding SCTP user messages have been acknowledged by the SCTP avoid the need for APIs requiring per user message data level
peer in a non-revokable way. acknowledgments and utilizes existing SCTP protocol behavior to
ensure delivery of the protected user messages data.
Prior to processing a received CloseNotify, all other received SCTP Note, this proceudre currenlty only works for DTLS 1.3. For DTLS 1.2
user messages that are buffered in the SCTP layer MUST be read and users the remote endpoint will be closed for sending more data with
processed by DTLS. the reception of the close_notify in step 5, and step 6 will not be
possible and that data will be lost.
The interaction between peers and protocol stacks shall be as
follows:
1. Local instance of ULP asks for terminating the DTLS/SCTP
Association.
2. Local DTLS/SCTP acknowledge the request, from this time on no
new data from local instance of ULP will be accepted. In case a
DTLS connection handshake is ongoing this needs to be aborted
conclusively at this step to ensure that the necessary DTLS
message exchange happens prior to draining any outstanding data
in the SCTP association from this endpoint.
3. Local DTLS/SCTP finishes any protection operation on buffered
user messages and ensures that all protected user message data
has been successfully transferred to the remote ULP.
4. Local DTLS/SCTP sends DTLS Close_notify to remote instance of
DTLS/SCTP on each and all DTLS connections, keys and session
state are kept for processing packets received later on.
5. When receiving Close_notify on the last open DTLS connection,
remote DTLS/SCTP instance informs its ULP that remote shutdown
has been initiated. When two parallel DTLS connections are in
place it is important to await Close_notify alert on both to not
misstake a rekeying. No more ULP user message data to be sent
to peer can be accepted by DTLS/SCTP. In case this endpoint has
initiated and DTLS connection handshake this MUST be aborted as
the peer is unable to respond.
6. Remote DTLS/SCTP finishes any protection operation on buffered
user messages and ensures that all protected user message data
has been successfully transferred to the remote ULP.
7. Remote DTLS/SCTP sends Close_notify to Local DTLS/SCTP entity
for each and all DTLS connections.
8. When receiving Close_notify on the last open DTLS connection,
local DTLS/SCTP instance initiates the SCTP shutdown procedure
(section 9.2 of [RFC4960]).
9. Remote DTLS/SCTP replied to the SCTP shutdown procedure (section
9.2 of [RFC4960]).
10. Upon receiving the information that SCTP has closed the
Association, independently the local and remote DTLS/SCTP
entities destroy the DTLS connection.
The verification in step 3 and 6 that all user data message has been
successfully delivered to the remote ULP can be provided by the SCTP
stack that implements [RFC6458] by means of SCTP_SENDER_DRY event
(section 6.1.9 of [RFC6458]).
A successful SCTP shutdown will indicate successful delivery of all
data. However, in cases of communication failures and extensive
packet loss the SCTP shutdown procedure can time out and result in
SCTP association termination where its unknown if all data has been
delivered. The DTLS/SCTP should indicate to ULP successful
completion or failure to shutdown gracefully.
5. DTLS over SCTP Service 5. DTLS over SCTP Service
The adoption of DTLS over SCTP according to the current description The adoption of DTLS over SCTP according to the current specification
is meant to add to SCTP the option for transferring encrypted data. is meant to add to SCTP the option for transferring encrypted data.
When DTLS over SCTP is used, all data being transferred MUST be When DTLS over SCTP is used, all data being transferred MUST be
protected by chunk authentication and DTLS encrypted. Chunks that protected by chunk authentication and DTLS encrypted. Chunks that
need to be received in an authenticated way will be specified in the need to be received in an authenticated way will be specified in the
CHUNK list parameter according to [RFC4895]. Error handling for CHUNK list parameter according to [RFC4895]. Error handling for
authenticated chunks is according to [RFC4895]. authenticated chunks is according to [RFC4895].
5.1. Adaptation Layer Indication in INIT/INIT-ACK 5.1. Adaptation Layer Indication in INIT/INIT-ACK
At the initialization of the association, a sender of the INIT or At the initialization of the association, a sender of the INIT or
INIT ACK chunk that intends to use DTLS/SCTP as specified in this INIT ACK chunk that intends to use DTLS/SCTP as specified in this
specification MUST include an Adaptation Layer Indication Parameter specification MUST include an Adaptation Layer Indication Parameter
with the IANA assigned value TBD (Section 7.2) to inform its peer with the IANA assigned value TBD (Section 8.2) to inform its peer
that it is able to support DTLS over SCTP per this specification. that it is able to support DTLS over SCTP per this specification.
5.2. DTLS over SCTP Initialization 5.2. DTLS over SCTP Initialization
Initialization of DTLS/SCTP requires all the following options to be Initialization of DTLS/SCTP requires all the following options to be
part of the INIT/INIT-ACK handshake: part of the INIT/INIT-ACK handshake:
RANDOM: defined in [RFC4895] RANDOM: defined in [RFC4895]
CHUNKS: list of permitted chunks, defined in [RFC4895] CHUNKS: list of permitted chunks, defined in [RFC4895]
HMAC-ALGO: defined in [RFC4895] HMAC-ALGO: defined in [RFC4895]
ADAPTATION-LAYER-INDICATION: defined in [RFC5061] ADAPTATION-LAYER-INDICATION: defined in [RFC5061]
When all the above options are present, the Association will start When all the above options are present and having acceptable
with support of DTLS/SCTP. The set of options indicated are the parameters, the Association will start with support of DTLS/SCTP.
DTLS/SCTP Mandatory Options. No data transfer is permitted before The set of options indicated are the DTLS/SCTP Mandatory Options. No
DTLS handshake is complete. Chunk bundling is permitted according to data transfer is permitted before DTLS handshake is complete. Chunk
[RFC4960]. The DTLS handshake will enable authentication of both the bundling is permitted according to [RFC4960]. The DTLS handshake
peers and also have the declare their support message size. will enable authentication of both the peers.
The extension described in this document is given by the following The extension described in this document is given by the following
message exchange. message exchange.
--- INIT[RANDOM; CHUNKS; HMAC-ALGO; ADAPTATION-LAYER-IND] ---> --- INIT[RANDOM; CHUNKS; HMAC-ALGO; ADAPTATION-LAYER-IND] --->
<- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO; ADAPTATION-LAYER-IND] - <- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO; ADAPTATION-LAYER-IND] -
------------------------ COOKIE-ECHO ------------------------> ------------------------ COOKIE-ECHO ------------------------>
<------------------------ COOKIE-ACK ------------------------- <------------------------ COOKIE-ACK -------------------------
---------------- AUTH; DATA[DTLS Handshake] -----------------> ---------------- AUTH; DATA[DTLS Handshake] ----------------->
... ...
skipping to change at page 21, line 7 skipping to change at page 23, line 18
can fallback to follow the DTLS/SCTP behavior in RFC6083. It is can fallback to follow the DTLS/SCTP behavior in RFC6083. It is
recommended to define a setting that represents the policy to allow recommended to define a setting that represents the policy to allow
fallback or not. However, the possibility to use fallback is based fallback or not. However, the possibility to use fallback is based
on the ULP can operate using user messages that are no longer than on the ULP can operate using user messages that are no longer than
16384 bytes and where the security issues can be mitigated or 16384 bytes and where the security issues can be mitigated or
considered acceptable. Fallback is NOT RECOMMEND to be enabled as it considered acceptable. Fallback is NOT RECOMMEND to be enabled as it
enables downgrade attacks to weaker algorithms and versions of DTLS. enables downgrade attacks to weaker algorithms and versions of DTLS.
An SCTP endpoint that receives an INIT chunk or an INIT-ACK chunk An SCTP endpoint that receives an INIT chunk or an INIT-ACK chunk
that does not contain the SCTP-Adaptation-Indication parameter with that does not contain the SCTP-Adaptation-Indication parameter with
the DTLS/SCTP adaptation layer codepoint, see Section 7.2, may in the DTLS/SCTP adaptation layer codepoint, see Section 8.2, may in
certain cases potentially perform a fallback to RFC 6083 behavior. certain cases potentially perform a fallback to RFC 6083 behavior.
However, the fallback attempt should only be performed if policy says However, the fallback attempt should only be performed if policy says
that is acceptable. that is acceptable.
If fallback is allowed, it is possible that the client will send If fallback is allowed, it is possible that the client will send
plain text user messages prior to DTLS handshake as it is allowed per plain text user messages prior to DTLS handshake as it is allowed per
RFC 6083. So that needs to be part of the consideration for a policy RFC 6083. So that needs to be part of the consideration for a policy
allowing fallback. allowing fallback.
6. Socket API Considerations 5.5.1. Client Fallback
A DTLS/SCTP client supporting this specficiation encountering an
server not compatible with this specficiation MAY attempt RFC 6083
fallback per this procedure.
1. Fallback procedure, if enabled, is initiated when receiving an
SCTP INIT-ACK that does not contain the DTLS/SCTP Adaptation
Layer indication. If fallback is not enabled the SCTP handshake
is aborted.
2. The client checks that the SCTP INIT-ACK contained the necessary
chunks and parameters to establish SCTP-AUTH per RFC 6083 with
this endpoint. If not all necessary parameters or support
algorithms don't match the client MUST abort the handshake.
Otherwise it complets the SCTP handshake.
3. Client performs DTLS connection handshake per RFC 6083 over
established SCTP association. If succesfull authenticating the
targeted server the client has succesfull fallen back to use RFC
6083. If not terminate the SCTP association.
5.5.2. Server Fallback
A DTLS/SCTP Server that supports both this specification and RFC 6083
and where fallback has been enabled for the ULP can follow this
procedure.
1. When receving an SCTP INIT message without the DTLS/SCTP
adapation layer indicataion fallback procedure is initiated.
2. Verify that the SCTP INIT contains SCTP-AUTH parameters required
by RFC 6083 and compatible with this server. If that is not the
case abort the SCTP handshake.
3. Send an SCTP INIT ACK with the required SCTP-AUTH chunks and
parameters to the client.
4. Complete the SCTP Handshake. Await DTLS handshake per RFC 6083.
Plain text SCTP messages MAY be received.
5. Upon succesful completion of DTLS handshake succesfull fallback
to RFC 6083 have been accomplished.
6. SCTP API Consideration
DTLS/SCTP needs certain functionality on the API that the SCTP
implementation provide to the ULP to function optimally. A DTLS/SCTP
implementation will need to provide its own API to the ULP, while
itself using the SCTP API. This discussion is focused on the needed
functionality on the SCTP API.
The following functionality is needed:
* Controlling SCPT-AUTH negotiation so that SHA-256 algorithm is
inlcuded, and determine that SHA-1 is not selected when the
association is established.
* Determine when all SCTP packets that uses an SCTP-auth key or
contains DTLS records associated to a particular DTLS connection
has been acknowledge in a non-renegable manor.
* Determine when all SCTP packets have been acknowledge in a non-
renegable manor.
* Negotiate the adaptation layer indication that indicates DTLS/SCTP
and determine if it was agreed or not.
* Partial user messages transmission and reception.
7. Socket API Considerations
This section describes how the socket API defined in [RFC6458] is This section describes how the socket API defined in [RFC6458] is
extended to provide a way for the application to observe the HMAC extended to provide a way for the application to observe the HMAC
algorithms used for sending and receiving of AUTH chunks. algorithms used for sending and receiving of AUTH chunks.
Please note that this section is informational only. Please note that this section is informational only.
A socket API implementation based on [RFC6458] is, by means of the A socket API implementation based on [RFC6458] is, by means of the
existing SCTP_AUTHENTICATION_EVENT event, extended to provide the existing SCTP_AUTHENTICATION_EVENT event, extended to provide the
event notification whenever a new HMAC algorithm is used in a event notification whenever a new HMAC algorithm is used in a
skipping to change at page 21, line 41 skipping to change at page 25, line 29
the name SCTP_SEND_HMAC_IDENT and SCTP_EXPOSE_HMAC_IDENT_CHANGES are the name SCTP_SEND_HMAC_IDENT and SCTP_EXPOSE_HMAC_IDENT_CHANGES are
defined as described below. The first socket option is used to query defined as described below. The first socket option is used to query
the HMAC algorithm used for sending AUTH chunks. The second enables the HMAC algorithm used for sending AUTH chunks. The second enables
the monitoring of HMAC algorithms used in received AUTH chunks via the monitoring of HMAC algorithms used in received AUTH chunks via
the SCTP_AUTHENTICATION_EVENT event. the SCTP_AUTHENTICATION_EVENT event.
Support for the SCTP_SEND_HMAC_IDENT and Support for the SCTP_SEND_HMAC_IDENT and
SCTP_EXPOSE_HMAC_IDENT_CHANGES socket options also need to be added SCTP_EXPOSE_HMAC_IDENT_CHANGES socket options also need to be added
to the function sctp_opt_info(). to the function sctp_opt_info().
6.1. Socket Option to Get the HMAC Identifier being Sent 7.1. Socket Option to Get the HMAC Identifier being Sent
(SCTP_SEND_HMAC_IDENT) (SCTP_SEND_HMAC_IDENT)
During the SCTP association establishment a HMAC Identifier is During the SCTP association establishment a HMAC Identifier is
selected which is used by an SCTP endpoint when sending AUTH chunks. selected which is used by an SCTP endpoint when sending AUTH chunks.
An application can access the result of this selection by using this An application can access the result of this selection by using this
read-only socket option, which uses the level IPPROTO_SCTP and the read-only socket option, which uses the level IPPROTO_SCTP and the
name SCTP_SEND_HMAC_IDENT. name SCTP_SEND_HMAC_IDENT.
The following structure is used to access HMAC Identifier used for The following structure is used to access HMAC Identifier used for
sending AUTH chunks: sending AUTH chunks:
skipping to change at page 22, line 18 skipping to change at page 26, line 5
}; };
assoc_id: This parameter is ignored for one-to-one style sockets. assoc_id: This parameter is ignored for one-to-one style sockets.
For one-to-many style sockets, the application fills in an For one-to-many style sockets, the application fills in an
association identifier. It is an error to use association identifier. It is an error to use
SCTP_{FUTURE|CURRENT|ALL}_ASSOC in assoc_id. SCTP_{FUTURE|CURRENT|ALL}_ASSOC in assoc_id.
assoc_value: This parameter contains the HMAC Identifier used for assoc_value: This parameter contains the HMAC Identifier used for
sending AUTH chunks. sending AUTH chunks.
6.2. Exposing the HMAC Identifiers being Received 7.2. Exposing the HMAC Identifiers being Received
Section 6.1.8 of [RFC6458] defines the SCTP_AUTHENTICATION_EVENT Section 6.1.8 of [RFC6458] defines the SCTP_AUTHENTICATION_EVENT
event, which uses the following structure: event, which uses the following structure:
struct sctp_authkey_event { struct sctp_authkey_event {
uint16_t auth_type; uint16_t auth_type;
uint16_t auth_flags; uint16_t auth_flags;
uint32_t auth_length; uint32_t auth_length;
uint16_t auth_keynumber; uint16_t auth_keynumber;
uint32_t auth_indication; uint32_t auth_indication;
skipping to change at page 22, line 47 skipping to change at page 26, line 34
uint32_t auth_length; uint32_t auth_length;
uint16_t auth_identifier; /* formerly auth_keynumber */ uint16_t auth_identifier; /* formerly auth_keynumber */
uint32_t auth_indication; uint32_t auth_indication;
sctp_assoc_t auth_assoc_id; sctp_assoc_t auth_assoc_id;
}; };
by renaming auth_keynumber to auth_identifier. auth_identifier just by renaming auth_keynumber to auth_identifier. auth_identifier just
replaces auth_keynumber in the context of [RFC6458]. In addition to replaces auth_keynumber in the context of [RFC6458]. In addition to
that, the SCTP_AUTHENTICATION_EVENT event is extended to also that, the SCTP_AUTHENTICATION_EVENT event is extended to also
indicate when a new HMAC Identifier is received and such reporting is indicate when a new HMAC Identifier is received and such reporting is
explicitly enabled as described in Section 6.3. In this case explicitly enabled as described in Section 7.3. In this case
auth_indication is SCTP_AUTH_NEW_HMAC and the new HMAC identifier is auth_indication is SCTP_AUTH_NEW_HMAC and the new HMAC identifier is
reported in auth_identifier. reported in auth_identifier.
6.3. Socket Option to Expose HMAC Identifier Usage 7.3. Socket Option to Expose HMAC Identifier Usage
(SCTP_EXPOSE_HMAC_IDENT_CHANGES) (SCTP_EXPOSE_HMAC_IDENT_CHANGES)
This options allows the application to enable and disable the This options allows the application to enable and disable the
reception of SCTP_AUTHENTICATION_EVENT events when a new HMAC reception of SCTP_AUTHENTICATION_EVENT events when a new HMAC
Identifiers has been received in an AUTH chunk (see Section 6.2). Identifiers has been received in an AUTH chunk (see Section 7.2).
This read/write socket option uses the level IPPROTO_SCTP and the This read/write socket option uses the level IPPROTO_SCTP and the
name SCTP_EXPOSE_HMAC_IDENT_CHANGES. It is needed to provide name SCTP_EXPOSE_HMAC_IDENT_CHANGES. It is needed to provide
backwards compatibility and the default is that these events are not backwards compatibility and the default is that these events are not
reported. reported.
The following structure is used to enable or disable the reporting of The following structure is used to enable or disable the reporting of
newly received HMAC Identifiers in AUTH chunks: newly received HMAC Identifiers in AUTH chunks:
struct sctp_assoc_value { struct sctp_assoc_value {
sctp_assoc_t assoc_id; sctp_assoc_t assoc_id;
uint32_t assoc_value; uint32_t assoc_value;
}; };
assoc_id: This parameter is ignored for one-to-one style sockets. assoc_id: This parameter is ignored for one-to-one style sockets.
For one-to-many style sockets, the application may fill in an For one-to-many style sockets, the application may fill in an
association identifier or SCTP_{FUTURE|CURRENT|ALL}_ASSOC. association identifier or SCTP_{FUTURE|CURRENT|ALL}_ASSOC.
assoc_value: Newly received HMAC Identifiers are reported if, and assoc_value: Newly received HMAC Identifiers are reported if, and
only if, this parameter is non-zero. only if, this parameter is non-zero.
7. IANA Considerations 8. IANA Considerations
7.1. TLS Exporter Label 8.1. TLS Exporter Label
RFC 6083 defined a TLS Exporter Label registry as described in RFC 6083 defined a TLS Exporter Label registry as described in
[RFC5705]. IANA is requested to update the reference for the label [RFC5705]. IANA is requested to update the reference for the label
"EXPORTER_DTLS_OVER_SCTP" to this specification. "EXPORTER_DTLS_OVER_SCTP" to this specification.
7.2. SCTP Adaptation Layer Indication Code Point 8.2. SCTP Adaptation Layer Indication Code Point
[RFC5061] defined a IANA registry for Adaptation Code Points to be [RFC5061] defined a IANA registry for Adaptation Code Points to be
used in the Adaptation Layer Indication parameter. The registry was used in the Adaptation Layer Indication parameter. The registry was
at time of writing located: https://www.iana.org/assignments/sctp- at time of writing located: https://www.iana.org/assignments/sctp-
parameters/sctp-parameters.xhtml#sctp-parameters-27 IANA is requested parameters/sctp-parameters.xhtml#sctp-parameters-27 IANA is requested
to assign one Adaptation Code Point for DTLS/SCTP per the below to assign one Adaptation Code Point for DTLS/SCTP per the below
proposed entry in Table 1. proposed entry in Table 1.
+============================+=============+===========+ +============================+=============+===========+
| Code Point (32-bit number) | Description | Reference | | Code Point (32-bit number) | Description | Reference |
+============================+=============+===========+ +============================+=============+===========+
| 0x00000002 | DTLS/SCTP | [RFC-TBD] | | 0x00000002 | DTLS/SCTP | [RFC-TBD] |
+----------------------------+-------------+-----------+ +----------------------------+-------------+-----------+
Table 1: Adaptation Code Point Table 1: Adaptation Code Point
RFC-Editor Note: Please replace [RFC-TBD] with the RFC number given RFC-Editor Note: Please replace [RFC-TBD] with the RFC number given
to this specification. to this specification.
8. Security Considerations 9. Security Considerations
The security considerations given in [I-D.ietf-tls-dtls13], The security considerations given in [I-D.ietf-tls-dtls13],
[RFC4895], and [RFC4960] also apply to this document. [RFC4895], and [RFC4960] also apply to this document.
8.1. Cryptographic Considerations 9.1. Cryptographic Considerations
Over the years, there have been several serious attacks on earlier Over the years, there have been several serious attacks on earlier
versions of Transport Layer Security (TLS), including attacks on its versions of Transport Layer Security (TLS), including attacks on its
most commonly used ciphers and modes of operation. [RFC7457] most commonly used ciphers and modes of operation. [RFC7457]
summarizes the attacks that were known at the time of publishing and summarizes the attacks that were known at the time of publishing and
BCP 195 [RFC7525] [RFC8996] provide recommendations for improving the BCP 195 [RFC7525] [RFC8996] provide recommendations for improving the
security of deployed services that use TLS. security of deployed services that use TLS.
When DTLS/SCTP is used with DTLS 1.2 [RFC6347], DTLS 1.2 MUST be When DTLS/SCTP is used with DTLS 1.2 [RFC6347], DTLS 1.2 MUST be
configured to disable options known to provide insufficient security. configured to disable options known to provide insufficient security.
skipping to change at page 25, line 5 skipping to change at page 28, line 36
been reached. The AEAD limits equations are equally valid for DTLS been reached. The AEAD limits equations are equally valid for DTLS
1.2 and SHOULD be followed for DTLS/SCTP, but are not mandated by the 1.2 and SHOULD be followed for DTLS/SCTP, but are not mandated by the
DTLS 1.2 specification. DTLS 1.2 specification.
HMAC-SHA-256 as used in SCTP-AUTH has a very large tag length and HMAC-SHA-256 as used in SCTP-AUTH has a very large tag length and
very good integrity properties. The SCTP-AUTH key can be used longer very good integrity properties. The SCTP-AUTH key can be used longer
than the current algorithms in the TLS record layer. The SCTP-AUTH than the current algorithms in the TLS record layer. The SCTP-AUTH
key is rekeyed when a new DTLS connection is set up at which point a key is rekeyed when a new DTLS connection is set up at which point a
new SCTP-AUTH key is derived using the TLS-Exporter. new SCTP-AUTH key is derived using the TLS-Exporter.
(D)TLS 1.3 [RFC8446] discusses forward secrecy from EC(DHE),
KeyUpdate, and tickets/resumption. Forward secrecy limits the effect
of key leakage in one direction (compromise of a key at time T2 does
not compromise some key at time T1 where T1 < T2). Protection in the
other direction (compromise at time T1 does not compromise keys at
time T2) can be achieved by rerunning EC(DHE). If a long-term
authentication key has been compromised, a full handshake with
EC(DHE) gives protection against passive attackers. If the
resumption_master_secret has been compromised, a resumption handshake
with EC(DHE) gives protection against passive attackers and a full
handshake with EC(DHE) gives protection against active attackers. If
a traffic secret has been compromised, any handshake with EC(DHE)
gives protection against active attackers.
The document "Confidentiality in the Face of Pervasive Surveillance:
A Threat Model and Problem Statement" [RFC7624] defines key
exfiltration as the transmission of cryptographic keying material for
an encrypted communication from a collaborator, deliberately or
unwittingly, to an attacker. Using the terms in RFC 7624, forward
secrecy without rerunning EC(DHE) still allows an attacker to do
static key exfiltration. Rerunning EC(DHE) forces and attacker to
dynamic key exfiltration (or content exfiltration).
When using DTLS 1.3 [I-D.ietf-tls-dtls13], AEAD limits and forward
secrecy can be achieved by sending post-handshake KeyUpdate messages,
which triggers rekeying of DTLS. Such symmetric rekeying gives
significantly less protection against key leakage than re-running
Diffie-Hellman as explained above. After leakage of
application_traffic_secret_N, an attacker can passively eavesdrop on
all future data sent on the connection including data encrypted with
application_traffic_secret_N+1, application_traffic_secret_N+2, etc.
Note that KeyUpdate does not update the exporter_secret.
DTLS/SCTP is in many deployments replacing IPsec. For IPsec, NIST DTLS/SCTP is in many deployments replacing IPsec. For IPsec, NIST
(US), BSI (Germany), and ANSSI (France) recommends very frequent re- (US), BSI (Germany), and ANSSI (France) recommends very frequent re-
run of Diffie-Hellman to provide Perfect Forward Secrecy and force run of Diffie-Hellman to provide forward secrecy and force attackers
attackers to dynamic key extraction [RFC7624]. ANSSI writes "It is to dynamic key extraction [RFC7624]. ANSSI writes "It is recommended
recommended to force the periodic renewal of the keys, e.g., every to force the periodic renewal of the keys, e.g., every hour and every
hour and every 100 GB of data, in order to limit the impact of a key 100 GB of data, in order to limit the impact of a key compromise."
compromise." [ANSSI-DAT-NT-003]. [ANSSI-DAT-NT-003].
For many DTLS/SCTP deployments the SCTP association is expected to For many DTLS/SCTP deployments the SCTP association is expected to
have a very long lifetime of months or even years. For associations have a very long lifetime of months or even years. For associations
with such long lifetimes there is a need to frequently re- with such long lifetimes there is a need to frequently re-
authenticate both client and server. TLS Certificate lifetimes authenticate both client and server. TLS Certificate lifetimes
significantly shorter than a year are common which is shorter than significantly shorter than a year are common which is shorter than
many expected DTLS/SCTP associations. many expected DTLS/SCTP associations.
SCTP-AUTH re-rekeying, periodic authentication of both endpoints, and SCTP-AUTH re-rekeying, periodic authentication of both endpoints, and
frequent re-run of Diffie-Hellman to force attackers to dynamic key frequent re-run of Diffie-Hellman to force attackers to dynamic key
skipping to change at page 25, line 33 skipping to change at page 29, line 48
up new DTLS connections over the same SCTP association. up new DTLS connections over the same SCTP association.
Implementations SHOULD set up new connections frequently to force Implementations SHOULD set up new connections frequently to force
attackers to dynamic key extraction. Implementations MUST set up new attackers to dynamic key extraction. Implementations MUST set up new
connections before any of the certificates expire. It is RECOMMENDED connections before any of the certificates expire. It is RECOMMENDED
that all negotiated and exchanged parameters are the same except for that all negotiated and exchanged parameters are the same except for
the timestamps in the certificates. Clients and servers MUST NOT the timestamps in the certificates. Clients and servers MUST NOT
accept a change of identity during the setup of a new connections, accept a change of identity during the setup of a new connections,
but MAY accept negotiation of stronger algorithms and security but MAY accept negotiation of stronger algorithms and security
parameters, which might be motivated by new attacks. parameters, which might be motivated by new attacks.
When using DTLS 1.3 [I-D.ietf-tls-dtls13], AEAD limits and forward
secrecy can be achieved by sending post-handshake KeyUpdate messages,
which triggers rekeying of DTLS. Such symmetric rekeying gives
significantly less protection against key leakage than re-running
Diffie-Hellman. After leakage of application_traffic_secret_N, a
passive attacker can passively eavesdrop on all future application
data sent on the connection including application data encrypted with
application_traffic_secret_N+1, application_traffic_secret_N+2, etc.
Note that KeyUpdate does not update the exporter_secret.
Allowing new connections can enable denial-of-service attacks. The Allowing new connections can enable denial-of-service attacks. The
endpoints SHOULD limit the frequency of new connections. endpoints SHOULD limit the frequency of new connections.
When DTLS/SCTP is used with DTLS 1.2 [RFC6347], the TLS Session Hash When DTLS/SCTP is used with DTLS 1.2 [RFC6347], the TLS Session Hash
and Extended Master Secret Extension [RFC7627] MUST be used to and Extended Master Secret Extension [RFC7627] MUST be used to
prevent unknown key-share attacks where an attacker establishes the prevent unknown key-share attacks where an attacker establishes the
same key on several connections. DTLS 1.3 always prevents these same key on several connections. DTLS 1.3 always prevents these
kinds of attacks. The use of SCTP-AUTH then cryptographically binds kinds of attacks. The use of SCTP-AUTH then cryptographically binds
new connections to the old connection. This together with mandatory new connections to the old connection. This together with mandatory
mutual authentication (on the DTLS layer) and a requirement to not mutual authentication (on the DTLS layer) and a requirement to not
accept new identities mitigates MITM attacks that have plagued accept new identities mitigates MITM attacks that have plagued
renegotiation [TRISHAKE]. renegotiation [TRISHAKE].
8.2. Downgrade Attacks 9.2. Downgrade Attacks
A peer supporting DTLS/SCTP according to this specification, DTLS/ A peer supporting DTLS/SCTP according to this specification, DTLS/
SCTP according to [RFC6083] and/or SCTP without DTLS may be SCTP according to [RFC6083] and/or SCTP without DTLS may be
vulnerable to downgrade attacks where on on-path attacker interferes vulnerable to downgrade attacks where on on-path attacker interferes
with the protocol setup to lower or disable security. If possible, with the protocol setup to lower or disable security. If possible,
it is RECOMMENDED that the peers have a policy only allowing DTLS/ it is RECOMMENDED that the peers have a policy only allowing DTLS/
SCTP according to this specification. SCTP according to this specification.
8.3. Authentication and Policy Decisions 9.3. Targeting DTLS Messages
The DTLS handshake messages and other control messages, i.e. not
application data can easily be identified when using DTLS 1.2 as
their content type is not encrypted. With DTLS 1.3 there is no
unprotected content type. However, they will sent with an PPID of 0
if sent in their own SCTP user messages. Section 4.4 proposes a
basic behavior that will stil make it easily for anyone to detect the
DTLS messages that are not proteceted user messages.
9.4. Authentication and Policy Decisions
DTLS/SCTP MUST be mutually authenticated. Authentication is the DTLS/SCTP MUST be mutually authenticated. Authentication is the
process of establishing the identity of a user or system and process of establishing the identity of a user or system and
verifying that the identity is valid. DTLS only provides proof of verifying that the identity is valid. DTLS only provides proof of
possession of a key. DTLS/SCTP MUST perform identity authentication. possession of a key. DTLS/SCTP MUST perform identity authentication.
It is RECOMMENDED that DTLS/SCTP is used with certificate-based It is RECOMMENDED that DTLS/SCTP is used with certificate-based
authentication. When certificates are used the applicatication using authentication. When certificates are used the applicatication using
DTLS/SCTP is reposible for certificate policies, certificate chain DTLS/SCTP is reposible for certificate policies, certificate chain
validation, and identity authentication (HTTPS does for example match validation, and identity authentication (HTTPS does for example match
the hostname with a subjectAltName of type dNSName). The application the hostname with a subjectAltName of type dNSName). The application
using DTLS/SCTP MUST define what the identity is and how it is using DTLS/SCTP MUST define what the identity is and how it is
encoded and the client and server MUST use the same identity format. encoded and the client and server MUST use the same identity format.
Guidance on server certificate validation can be found in [RFC6125]. Guidance on server certificate validation can be found in [RFC6125].
All security decisions MUST be based on the peer's authenticated DTLS/SCTP enables periodic transfer of mutual revocation information
(OSCP stapling) every time a new parallel connection is set up. All
security decisions MUST be based on the peer's authenticated
identity, not on its transport layer identity. identity, not on its transport layer identity.
It is possible to authenticate DTLS endpoints based on IP addresses It is possible to authenticate DTLS endpoints based on IP addresses
in certificates. SCTP associations can use multiple IP addresses per in certificates. SCTP associations can use multiple IP addresses per
SCTP endpoint. Therefore, it is possible that DTLS records will be SCTP endpoint. Therefore, it is possible that DTLS records will be
sent from a different source IP address or to a different destination sent from a different source IP address or to a different destination
IP address than that originally authenticated. This is not a problem IP address than that originally authenticated. This is not a problem
provided that no security decisions are made based on the source or provided that no security decisions are made based on the source or
destination IP addresses. destination IP addresses.
8.4. Privacy Considerations 9.5. Resumption and Tickets
In DTLS 1.3 any number of tickets can be issued in a connection and
the tickets can be used for resumption as long as they are valid,
which is up to seven days. The nodes in a resumed connection have
the same roles (client or server) as in the connection where the
ticket was issued. In DTLS/SCTP, there are no significant
performance benefits with resumption and an implementation can chose
to never issue any tickets. If tickets and resumption are used it is
enough to issue a single ticket per connection.
9.6. Privacy Considerations
[RFC6973] suggests that the privacy considerations of IETF protocols [RFC6973] suggests that the privacy considerations of IETF protocols
be documented. be documented.
For each SCTP user message, the user also provides a stream For each SCTP user message, the user also provides a stream
identifier, a flag to indicate whether the message is sent ordered or identifier, a flag to indicate whether the message is sent ordered or
unordered, and a payload protocol identifier. Although DTLS/SCTP unordered, and a payload protocol identifier. Although DTLS/SCTP
provides privacy for the actual user message, the other three provides privacy for the actual user message, the other three
information fields are not confidentiality protected. They are sent information fields are not confidentiality protected. They are sent
as cleartext because they are part of the SCTP DATA chunk header. as cleartext because they are part of the SCTP DATA chunk header.
It is RECOMMENDED that DTLS/SCTP is used with certificate based It is RECOMMENDED that DTLS/SCTP is used with certificate based
authentication in DTLS 1.3 [I-D.ietf-tls-dtls13] to provide identity authentication in DTLS 1.3 [I-D.ietf-tls-dtls13] to provide identity
protection. DTLS/SCTP MUST be used with a key exchange method protection. DTLS/SCTP MUST be used with a key exchange method
providing Perfect Forward Secrecy. Perfect Forward Secrecy providing forward secrecy.
significantly limits the amount of data that can be compromised due
to key compromise.
8.5. Pervasive Monitoring 9.7. Pervasive Monitoring
As required by [RFC7258], work on IETF protocols needs to consider As required by [RFC7258], work on IETF protocols needs to consider
the effects of pervasive monitoring and mitigate them when possible. the effects of pervasive monitoring and mitigate them when possible.
Pervasive Monitoring is widespread surveillance of users. By Pervasive Monitoring is widespread surveillance of users. By
encrypting more information including user identities, DTLS 1.3 encrypting more information including user identities, DTLS 1.3
offers much better protection against pervasive monitoring. offers much better protection against pervasive monitoring.
Massive pervasive monitoring attacks relying on key exchange without Massive pervasive monitoring attacks relying on key exchange without
forward secrecy has been reported. By mandating perfect forward forward secrecy has been reported. By mandating forward secrecy,
secrecy, DTLS/SCTP effectively mitigate many forms of passive DTLS/SCTP effectively mitigate many forms of passive pervasive
pervasive monitoring and limits the amount of compromised data due to monitoring and limits the amount of compromised data due to key
key compromise. compromise.
An important mitigation of pervasive monitoring is to force attackers An important mitigation of pervasive monitoring is to force attackers
to do dynamic key exfiltration instead of static key exfiltration. to do dynamic key exfiltration instead of static key exfiltration.
Dynamic key exfiltration increases the risk of discovery for the Dynamic key exfiltration increases the risk of discovery for the
attacker [RFC7624]. DTLS/SCTP per this specification encourages attacker [RFC7624]. DTLS/SCTP per this specification encourages
implementations to frequently set up new DTLS connections over the implementations to frequently set up new DTLS connections with
same SCTP association to force attackers to do dynamic key (EC)DHE over the same SCTP association to force attackers to do
exfiltration. dynamic key exfiltration.
In addition to the privacy attacks discussed above, surveillance on a In addition to the privacy attacks discussed above, surveillance on a
large scale may enable tracking of a user over a wider geographical large scale may enable tracking of a user over a wider geographical
area and across different access networks. Using information from area and across different access networks. Using information from
DTLS/SCTP together with information gathered from other protocols DTLS/SCTP together with information gathered from other protocols
increase the risk of identifying individual users. increase the risk of identifying individual users.
9. Contributors 10. Contributors
Michael Tuexen contributed as co-author to the intitial versions this Michael Tuexen contributed as co-author to the intitial versions this
draft. Michael's contributions include: draft. Michael's contributions include:
* The use of the Adaptation Layer Indication. * The use of the Adaptation Layer Indication.
* Socket API extension * Socket API extension
* Many editorial improvements. * Many editorial improvements.
10. Acknowledgments 11. Acknowledgments
The authors of RFC 6083 which this document is based on are Michael The authors of RFC 6083 which this document is based on are Michael
Tuexen, Eric Rescorla, and Robin Seggelmann. Tuexen, Eric Rescorla, and Robin Seggelmann.
The RFC 6083 authors thanked Anna Brunstrom, Lars Eggert, Gorry The RFC 6083 authors thanked Anna Brunstrom, Lars Eggert, Gorry
Fairhurst, Ian Goldberg, Alfred Hoenes, Carsten Hohendorf, Stefan Fairhurst, Ian Goldberg, Alfred Hoenes, Carsten Hohendorf, Stefan
Lindskog, Daniel Mentz, and Sean Turner for their invaluable Lindskog, Daniel Mentz, and Sean Turner for their invaluable
comments. comments.
The authors of this document want to thank GitHub user vanrein for The authors of this document want to thank Daria Ivanova, Li Yan, and
their contribution. GitHub user vanrein for their contribution.
11. References 12. References
11.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P. [RFC3758] Stewart, R., Ramalho, M., Xie, Q., Tuexen, M., and P.
Conrad, "Stream Control Transmission Protocol (SCTP) Conrad, "Stream Control Transmission Protocol (SCTP)
Partial Reliability Extension", RFC 3758, Partial Reliability Extension", RFC 3758,
DOI 10.17487/RFC3758, May 2004, DOI 10.17487/RFC3758, May 2004,
skipping to change at page 29, line 52 skipping to change at page 34, line 27
dtls13-43, 30 April 2021, <https://www.ietf.org/internet- dtls13-43, 30 April 2021, <https://www.ietf.org/internet-
drafts/draft-ietf-tls-dtls13-43.txt>. drafts/draft-ietf-tls-dtls13-43.txt>.
[I-D.ietf-tls-dtls-connection-id] [I-D.ietf-tls-dtls-connection-id]
Rescorla, E., Tschofenig, H., Fossati, T., and A. Kraus, Rescorla, E., Tschofenig, H., Fossati, T., and A. Kraus,
"Connection Identifiers for DTLS 1.2", Work in Progress, "Connection Identifiers for DTLS 1.2", Work in Progress,
Internet-Draft, draft-ietf-tls-dtls-connection-id-13, 22 Internet-Draft, draft-ietf-tls-dtls-connection-id-13, 22
June 2021, <https://www.ietf.org/archive/id/draft-ietf- June 2021, <https://www.ietf.org/archive/id/draft-ietf-
tls-dtls-connection-id-13.txt>. tls-dtls-connection-id-13.txt>.
11.2. Informative References 12.2. Informative References
[RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport [RFC3436] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport
Layer Security over Stream Control Transmission Protocol", Layer Security over Stream Control Transmission Protocol",
RFC 3436, DOI 10.17487/RFC3436, December 2002, RFC 3436, DOI 10.17487/RFC3436, December 2002,
<https://www.rfc-editor.org/info/rfc3436>. <https://www.rfc-editor.org/info/rfc3436>.
[RFC3788] Loughney, J., Tuexen, M., Ed., and J. Pastor-Balbas, [RFC3788] Loughney, J., Tuexen, M., Ed., and J. Pastor-Balbas,
"Security Considerations for Signaling Transport (SIGTRAN) "Security Considerations for Signaling Transport (SIGTRAN)
Protocols", RFC 3788, DOI 10.17487/RFC3788, June 2004, Protocols", RFC 3788, DOI 10.17487/RFC3788, June 2004,
<https://www.rfc-editor.org/info/rfc3788>. <https://www.rfc-editor.org/info/rfc3788>.
skipping to change at page 31, line 25 skipping to change at page 35, line 48
[RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T., [RFC7624] Barnes, R., Schneier, B., Jennings, C., Hardie, T.,
Trammell, B., Huitema, C., and D. Borkmann, Trammell, B., Huitema, C., and D. Borkmann,
"Confidentiality in the Face of Pervasive Surveillance: A "Confidentiality in the Face of Pervasive Surveillance: A
Threat Model and Problem Statement", RFC 7624, Threat Model and Problem Statement", RFC 7624,
DOI 10.17487/RFC7624, August 2015, DOI 10.17487/RFC7624, August 2015,
<https://www.rfc-editor.org/info/rfc7624>. <https://www.rfc-editor.org/info/rfc7624>.
[ANSSI-DAT-NT-003] [ANSSI-DAT-NT-003]
Agence nationale de la sécurité des systèmes Agence nationale de la sécurité des systèmes
d'information, ., "Recommendations for securing networks d'information, "Recommendations for securing networks with
with IPsec", ANSSI Technical Report DAT-NT-003 , August IPsec", ANSSI Technical Report DAT-NT-003 , August 2015,
2015, <<https://www.ssi.gouv.fr/uploads/2015/09/ <<https://www.ssi.gouv.fr/uploads/2015/09/
NT_IPsec_EN.pdf>>. NT_IPsec_EN.pdf>>.
[TRISHAKE] Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti, [TRISHAKE] Bhargavan, K., Delignat-Lavaud, A., Fournet, C., Pironti,
A., and P. Strub, "["Triple Handshakes and Cookie A., and P. Strub, "Triple Handshakes and Cookie Cutters:
Cutters", "Breaking and Fixing Authentication over TLS"]", Breaking and Fixing Authentication over TLS", IEEE
IEEE Symposium on Security & Privacy , April 2016, Symposium on Security & Privacy , April 2016,
<<https://hal.inria.fr/hal-01102259/file/triple- <https://hal.inria.fr/hal-01102259/file/triple-handshakes-
handshakes-and-cookie-cutters-oakland14.pdf>>. and-cookie-cutters-oakland14.pdf>.
Appendix A. Motivation for Changes Appendix A. Motivation for Changes
This document proposes a number of changes to RFC 6083 that have This document proposes a number of changes to RFC 6083 that have
various different motivations: various different motivations:
Supporting Large User Messages: RFC 6083 allowed only user messages Supporting Large User Messages: RFC 6083 allowed only user messages
that could fit within a single DTLS record. 3GPP has run into this that could fit within a single DTLS record. 3GPP has run into this
limitation where they have at least four SCTP using protocols (F1, limitation where they have at least four SCTP using protocols (F1,
E1, Xn, NG-C) that can potentially generate messages over the size of E1, Xn, NG-C) that can potentially generate messages over the size of
16384 bytes. 16384 bytes.
New Versions: Almost 10 years has passed since RFC 6083 was written, New Versions: Almost 10 years has passed since RFC 6083 was written,
and significant evolution has happened in the area of DTLS and and significant evolution has happened in the area of DTLS and
security algorithms. Thus DTLS 1.3 is the newest version of DTLS and security algorithms. Thus DTLS 1.3 is the newest version of DTLS and
also the SHA-1 HMAC algorithm of RFC 4895 is getting towards the end also the SHA-1 HMAC algorithm of RFC 4895 is getting towards the end
of usefulness. Use of DTLS 1.3 with long lived associations require of usefulness. Use of DTLS 1.3 with long lived associations require
parallel DTLS connections. Thus, this document mandates usage of parallel DTLS connections. Thus, this document mandates usage of
relevant versions and algorithms. relevant versions and algorithms.
Allowing DTLS Messages on any stream: RFC6083 requires DTLS messages
that are not user message data to sent on stream 0 and that this
stream is used with in-order delivery. That can actually limit the
applications that can use DTLS/SCTP. In addition with DTLS 1.3
encrypting the actual message type it is anyway not available.
Therefore a more flexible rule set is used that relies on DTLS
handling reordering.
Clarifications: Some implementation experiences have been gained that Clarifications: Some implementation experiences have been gained that
motivates additional clarifications on the specification. motivates additional clarifications on the specification.
* Avoid unsecured messages prior to DTLS handshake have completed. * Avoid unsecured messages prior to DTLS handshake have completed.
* Make clear that all messages are encrypted after DTLS handshake. * Make clear that all messages are encrypted after DTLS handshake.
Authors' Addresses Authors' Addresses
Magnus Westerlund Magnus Westerlund
 End of changes. 85 change blocks. 
236 lines changed or deleted 473 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/