draft-ietf-tsvwg-dtls-over-sctp-bis-00.txt   draft-ietf-tsvwg-dtls-over-sctp-bis-01.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: 11 November 2021 M. Tüxen Expires: 13 January 2022 M. Tüxen
Münster Univ. of Appl. Sciences Münster Univ. of Appl. Sciences
10 May 2021 12 July 2021
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-00 draft-ietf-tsvwg-dtls-over-sctp-bis-01
Abstract Abstract
This document describes a proposed update for the usage of the This document describes a proposed update for the usage of the
Datagram Transport Layer Security (DTLS) protocol to protect user Datagram Transport Layer Security (DTLS) protocol to protect user
messages sent over the Stream Control Transmission Protocol (SCTP). messages sent over the Stream Control Transmission Protocol (SCTP).
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
SCTP as their transport protocol and allows client/server SCTP as their transport protocol and allows client/server
applications to communicate in a way that is designed to give applications to communicate in a way that is designed to give
communications privacy and to prevent eavesdropping and detect communications privacy and to prevent eavesdropping and detect
tampering or message forgery. tampering or message forgery.
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. This document intends features provided by SCTP and its extensions. This document intends
to obsolete RFC 6083 and removes the 16 kB limitation on user message to obsolete RFC 6083 and removes the 16 kB limitation on user message
size by defining a secure user message fragmentation so that multiple size by defining a secure user message fragmentation so that multiple
DTLS records can be used to protect a single user message. It DTLS records can be used to protect a single user message. It
further updates the DTLS versions to use, as well as the HMAC further updates the DTLS versions to use, as well as the HMAC
algorithms for SCTP-AUTH, and simplifies the implementation by some algorithms for SCTP-AUTH, and simplifies secure implementation by
stricter requirements on the establishment procedures. 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 Discussion of this document takes place on the TSVWG Working Group
mailing list (tsvwg@ietf.org), which is archived at mailing list (tsvwg@ietf.org), which is archived at
https://mailarchive.ietf.org/arch/browse/tsvwg/. 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
skipping to change at line 62 skipping to change at line 62
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 11 November 2021. This Internet-Draft will expire on 13 January 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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
skipping to change at line 84 skipping to change at line 84
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as 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 Simplified BSD License.
Table of Contents Table of Contents
1. Introduction 1. Introduction
1.1. Overview 1.1. Overview
1.1.1. Comparison with TLS for SCTP 1.1.1. Comparison with TLS for SCTP
1.1.2. Changes from RFC 6083 1.1.2. Changes from RFC 6083
1.2. Terminology 1.2. DTLS Version
1.3. Abbreviations 1.3. Terminology
1.4. Abbreviations
2. Conventions 2. Conventions
3. DTLS Considerations 3. DTLS Considerations
3.1. Version of DTLS 3.1. Version of DTLS
3.2. Cipher Suites 3.2. Cipher Suites and Cryptographic Parameters
3.3. Message Sizes 3.3. Message Sizes
3.4. Replay Protection 3.4. Replay Protection
3.5. Path MTU Discovery 3.5. Path MTU Discovery
3.6. Retransmission of Messages 3.6. Retransmission of Messages
4. SCTP Considerations 4. SCTP Considerations
4.1. Mapping of DTLS Records 4.1. Mapping of DTLS Records
4.2. DTLS Connection Handling 4.2. DTLS Connection Handling
4.3. Payload Protocol Identifier Usage 4.3. Payload Protocol Identifier Usage
4.4. Stream Usage 4.4. Stream Usage
4.5. Chunk Handling 4.5. Chunk Handling
4.6. SCTP-AUTH Hash Function 4.6. SCTP-AUTH Hash Function
4.7. Renegotiation 4.7. Renegotiation
4.7.1. DTLS 1.2 Considerations
4.7.2. DTLS 1.3 Considerations
4.8. DTLS Epochs 4.8. DTLS Epochs
4.8.1. DTLS 1.2 Considerations
4.8.2. DTLS 1.3 Considerations
4.9. Handling of Endpoint-Pair Shared Secrets 4.9. Handling of Endpoint-Pair Shared Secrets
4.9.1. DTLS 1.2 Considerations
4.9.2. DTLS 1.3 Considerations
4.10. Shutdown 4.10. Shutdown
5. DTLS over SCTP Service 5. DTLS over SCTP Service
5.1. Adaptation Layer Indication in INIT/INIT-ACK 5.1. Adaptation Layer Indication in INIT/INIT-ACK
5.2. DTLS/SCTP "dtls_over_sctp_maximum_message_size" Extension 5.2. DTLS over SCTP Initialization
5.3. DTLS over SCTP Initialization 5.3. Client Use Case
5.4. Client Use Case 5.4. Server Use Case
5.5. Server Use Case 5.5. RFC 6083 Fallback
5.6. RFC 6083 Fallback 6. Socket API Considerations
6. IANA Considerations 6.1. Socket Option to Get the HMAC Identifier being Sent
6.1. TLS Exporter Label (SCTP_SEND_HMAC_IDENT)
6.2. DTLS "dtls_over_sctp_buffer_size_limit" Extension 6.2. Exposing the HMAC Identifiers being Received
6.3. SCTP Parameter 6.3. Socket Option to Expose HMAC Identifier Usage
7. Security Considerations (SCTP_EXPOSE_HMAC_IDENT_CHANGES)
7.1. Cryptographic Considerations 7. IANA Considerations
7.2. Downgrade Attacks 7.1. TLS Exporter Label
7.3. DTLS/SCTP Message Sizes 7.2. SCTP Adaptation Layer Indication Code Point
7.4. Authentication and Policy Decisions 8. Security Considerations
7.5. Privacy Considerations 8.1. Cryptographic Considerations
7.6. Pervasive Monitoring 8.2. Downgrade Attacks
8. Acknowledgments 8.3. Authentication and Policy Decisions
9. References 8.4. Privacy Considerations
9.1. Normative References 8.5. Pervasive Monitoring
9.2. Informative References 9. Acknowledgments
10. References
10.1. Normative References
10.2. Informative References
Appendix A. Motivation for Changes Appendix A. Motivation for Changes
Authors' Addresses Authors' Addresses
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 [I-D.ietf-tls-dtls13], over Security (DTLS) protocol, as defined in DTLS 1.2 [RFC6347], and DTLS
the Stream Control Transmission Protocol (SCTP), as defined in 1.3 [I-D.ietf-tls-dtls13], over the Stream Control Transmission
[RFC4960] with Authenticated Chunks for SCTP (SCTP-AUTH) [RFC4895]. Protocol (SCTP), as defined in [RFC4960] with Authenticated Chunks
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 perfect
forward secrecy for SCTP-AUTH, and confidentiality of user messages. forward secrecy for SCTP-AUTH, and confidentiality of user messages.
DTLS/SCTP use SCTP and SCTP-AUTH for integrity protection and replay DTLS/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:
skipping to change at line 168 skipping to change at line 179
* 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].
* large user messages. * large user messages.
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]. To efficiently implement and user messages as defined in [RFC4960]. The implementation is also
support larger user messages it is also recommended that I-DATA required to have an SCTP API (for example the one described in
chunks as defined in [RFC8260] as well as an SCTP API that supports [RFC6458]) that supports partial user message delivery and also
partial user message delivery as discussed in [RFC6458]. recommended that I-DATA chunks as defined in [RFC8260] is used to
efficiently implement and support larger user messages.
To simplify implementation and reduce the risk for security holes,
limitations have been defined such that STARTTLS as specified in
[RFC3788] is no longer supported.
1.1.1. Comparison with TLS for SCTP 1.1.1. Comparison with TLS for SCTP
TLS, from which DTLS was derived, is designed to run on top of a TLS, from which DTLS was derived, is designed to run on top of a
byte-stream-oriented transport protocol providing a reliable, in- byte-stream-oriented transport protocol providing a reliable, in-
sequence delivery. TLS over SCTP as described in [RFC3436] has some sequence delivery. TLS over SCTP as described in [RFC3436] has some
serious limitations: serious limitations:
* It does not support the unordered delivery of SCTP user messages. * It does not support the unordered delivery of SCTP user messages.
skipping to change at line 199 skipping to change at line 215
if a large number of streams is used. if a large number of streams is used.
1.1.2. Changes from RFC 6083 1.1.2. Changes from RFC 6083
The DTLS over SCTP solution defined in RFC 6083 had the following The DTLS over SCTP solution defined in RFC 6083 had the following
limitation: limitation:
* The maximum user message size is 2^14 bytes, which is a single * The maximum user message size is 2^14 bytes, which is a single
DTLS record limit. DTLS record limit.
This update that replaces RFC6083 defines the following changes: This update that replaces RFC 6083 defines the following changes:
* 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.
* Defines a DTLS extension for the endpoints to declare the user
message size supported to be received.
* Mandates that more modern DTLS version are required (DTLS 1.2 or * Mandates that more modern DTLS version are required (DTLS 1.2 or
1.3) 1.3)
* Mandates use of modern HMAC algorithm (SHA-256) in the SCTP * Mandates use 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.
* Recommends support of partial message delivery API, see [RFC6458]
if larger usage messages are intended to be used.
* 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.
1.2. Terminology * Requires support of partial delivery of user messages.
Mandating DTLS 1.2 or DTLS 1.3 instead to using DTLS 1.0 limits the
lifetime of a DTLS connection and the data volume which can be
transferred over a DTLS connection. This is cause by:
* The number of renegotiations in DTLS 1.2 is limited to 65534
compared to unlimited in DTLS 1.0.
* The number of KeyUpdates in DTLS 1.3 is limited to 65532 and
renegotiations are not supported.
1.2. DTLS Version
DTLS/SCTP as defined by this document can use either DTLS 1.2
[RFC6347] or DTLS 1.3 [I-D.ietf-tls-dtls13]. Some crucial difference
between the DTLS versions make it necessary for a user of DTLS/SCTP
to make an informed choice of the DTLS version to use based on their
application's requirements. In general, DTLS 1.3 is to preferred
being a newer protocol that addresses known vulnerabilities and only
defines strong algorithms without known major weaknesses at the time
of publication.
However, some applications using DTLS/SCTP are of semi-permanent
nature and use SCTP associations with lifetimes that are more than a
few hours, and where there is a significant cost of bringing down the
SCTP association in order to restart it. For such DTLS/SCTP usages
that need either of:
* Periodic re-authentication of both endpoints (not only the DTLS
client).
* Periodic rerunning of Diffie-Hellman key-exchange to provide
Perfect Forward Secrecy (PFS) to reduce the impact any key-reveal.
* Perform SCTP-AUTH re-keying.
At the time of publication DTLS 1.3 does not support any of these,
where DTLS 1.2 renegotiation functionality can provide this
functionality in the context of DTLS/SCTP. The application will have
to analyze its needs and requirements on the above and based on this
select the DTLS version to use.
To address known vulnerabilities in DTLS 1.2 this document describes
and mandates implementation constraints on ciphers, protocol options
and how to use the DTLS renegotiation mechanism.
In the rest of the document, unless the version of DTLS is
specifically called out the text applies to both versions of DTLS.
1.3. Terminology
This document uses the following terms: This document uses the following terms:
Association: An SCTP association. Association: An SCTP association.
Stream: A unidirectional stream of an SCTP association. It is Stream: A unidirectional stream of an SCTP association. It is
uniquely identified by a stream identifier. uniquely identified by a stream identifier.
1.3. Abbreviations 1.4. Abbreviations
DTLS: Datagram Transport Layer Security DTLS: Datagram Transport Layer Security
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
TCP: Transmission Control Protocol TCP: Transmission Control Protocol
TLS: Transport Layer Security TLS: Transport Layer Security
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.
3. DTLS Considerations 3. DTLS Considerations
3.1. Version of DTLS 3.1. Version of DTLS
This document is based on DTLS 1.3 [I-D.ietf-tls-dtls13], but works This document defines the usage of either DTLS 1.3
also for DTLS 1.2 [RFC6347]. Earlier versions of DTLS MUST NOT be [I-D.ietf-tls-dtls13], or DTLS 1.2 [RFC6347]. Earlier versions of
used. It is expected that DTLS/SCTP as described in this document DTLS MUST NOT be used (see [RFC8996]). It is expected that DTLS/SCTP
will work with future versions of DTLS. as described in this document will work with future versions of DTLS.
3.2. Cipher Suites 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. Cipher suites without encryption MUST NOT be used. used. For all versions of DTLS, cryptographic parameters giving
confidentiality and Perfect Forward Secrecy (PFS) 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 1.3 record allows a maximum of 2^14 DTLS records, where each DTLS 1.3 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
overhead. transmitted overhead.
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. The largest possible user
messages using the mechanism defined in this specification is 2^64-1 messages using the mechanism defined in this specification is 2^64-1
bytes. bytes.
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. securely. However, by mandating the use of the partial delivery of
user messages from SCTP and assuming that no two messages received on
A receiver that doesn't support partial delivery of user messages the same stream are interleaved (as it is the case when using the API
from SCTP [RFC6458] will advertise its largest supported protected defined in [RFC6458]) the required buffering prior to DTLS processing
message using SCTP's mechanism for Advertised Receiver Window Credit can be limited to a single DTLS record per used incoming stream.
(a_rwnd) as specified in Section 3.3.2 of [RFC4960]. Note that the This enables the DTLS/SCTP implementation to provide the Upper Layer
a_rwnd value is across all user messages being delivered. Protocol (ULP) with each DTLS record's content when it has been
decrypted and its integrity been verified enabling partial user
For a receiver supporting partial delivery of user messages a_rwnd message delivery to the ULP. Implementations can trade-off buffer
will not limit the maximum size of the DTLS protected user message memory requirements in the DTLS layer with transport overhead by
because the receiver can move parts of the DTLS protected user using smaller DTLS records.
message from the SCTP receiver buffer into a buffer for DTLS
processing. When each complete DTLS record have been received from
SCTP, it can be processed and the plain text fragment can, in its
turn, be partially delivered to the user application.
Thus, the limit of the largest user message is dependent on buffering
allocated for DTLS processing as well as the DTLS/SCTP API to the
application. To ensure that the sender have some understanding of
the maximum receiver size a TLS extension
"dtls_over_sctp_maximum_message_size" Section 5.2 is used to signal
the endpoints receiver capability when it comes to user message size.
All implementors of this specification MUST support user messages of
at least 16383 bytes. Where 16383 bytes is the supported message
size in RFC 6083. By requiring this message size in this document,
we ensure compatibility with existing usage of RFC 6083, not
requiring the upper layer protocol to implement additional features
or requirements.
Due to SCTP's capability to transmit concurrent user messages the
total memory consumption in the receiver is not bounded. In cases
where one or more user messages are affected by packet loss, the DATA
chunks may require more data in the receiver's buffer.
The necessary buffering space for a single user message of
dtls_over_sctp_maximum_message_size (MMS) is dependent on the
implementation.
When no partial data delivery is supported, the message size is
limited by the a_rwnd as this is the largest protected user message
that can be received and then processed by DTLS and where the plain
text user message is expected to be no more than the signalled MMS.
With partial processing it is possible to have a receiver
implementation that is bound to use no more buffer space than MMS
(for the plaintext) plus one maximum size DTLS record. The later
assumes that one can realign the start of the buffer after each DTLS
record has been consumed. A more realistic implementation is two
maximum DTLS record sizes.
If an implementation supports partial delivery in both the SCTP API The DTLS/SCTP implementation is expected to behave very similar to
and the ULP API, and also partial processing in the DTLS/SCTP just SCTP when it comes to handling of user messages and dealing with
implementation, then the buffering space in the DTLS/SCTP layer ought large user messages and their reassembly and processing. Making it
to be no more than two DTLS records. In which case the MMS to set is the ULP responsible for handling any resource contention related to
dependent on the ULP and the endpoints capabilities. large user messages.
3.4. Replay Protection 3.4. Replay Protection
SCTP-AUTH [RFC4895] does not have explicit replay protection. SCTP-AUTH [RFC4895] does not have explicit replay protection.
However, the combination of SCTP-AUTH's protection of DATA or I-DATA However, the combination of SCTP-AUTH's protection of DATA or I-DATA
chunks and SCTP user message handling will prevent third party chunks and SCTP user message handling will prevent third party
attempts to inject or replay SCTP packets resulting in impact on the attempts to inject or replay SCTP packets resulting in impact on the
received protected user message. In fact this document's solution is received protected user message. In fact, this document's solution
dependent on SCTP-AUTH and SCTP to prevent reordering of the DTLS is dependent on SCTP-AUTH and SCTP to prevent reordering,
records within each protected user message. duplication, and removal of the DTLS records within each protected
user message. This includes detection of changes to what DTLS
records start and end the SCTP user message, and removal of DTLS
records before an increment to the epoch. Without SCTP-AUTH, these
would all have required explicit handling.
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 own DTLS Path MTU Discovery MUST NOT be used. Since SCTP provides Path
Path MTU discovery and fragmentation/reassembly for user messages, MTU discovery and fragmentation/reassembly for user messages, and
and according to Section 3.3, DTLS can send maximum sized DTLS according to Section 3.3, DTLS can send maximum sized DTLS Records.
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
skipping to change at line 394 skipping to change at line 423
into fragments m0, m1, m2, each no larger than 2^14 - 1 = 16383 into fragments m0, m1, m2, each no larger than 2^14 - 1 = 16383
bytes. 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 records. If a DTLS On the receiving side DTLS is used to decrypt the individual records.
decryption fails, the DTLS connection and the SCTP association are There are three failure cases an implementation needs to detect and
terminated. Due to SCTP-AUTH preventing delivery of corrupt then act on:
fragments of the protected user message this should only occur in
case of implementation errors or internal hardware failures. 1. Failure in decryption and integrity verification process of any
DTLS record. Due to SCTP-AUTH preventing delivery of injected or
corrupt fragments of the protected user message this should only
occur in case of implementation errors or internal hardware
failures.
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
described in [RFC6458], and the last buffered DTLS record length
field does not match, i.e., the DTLS record is incomplete.
3. Unable to perform the decryption processes due to lack of
resources, such as memory, and have to abandon the user message
fragment. This specification is defined such that the needed
resources for the DTLS/SCTP operations are bounded for a given
number of concurrent transmitted SCTP streams or unordered user
messages.
The above failure cases all result in the receiver failing to
recreate the full user message. This is a failure of the transport
service that is not possible to recover from in the DTLS/SCTP layer
and the sender could believe the complete message have been
delivered. This error MUST NOT be ignored, as SCTP lacks any
facility to declare a failure on a specific stream or user message,
the DTLS connection and the SCTP association SHOULD be terminated. A
valid exception to the termination of the SCTP association is if the
receiver is capable of notifying the ULP about the failure in
delivery and the ULP is capable of recovering from this failure.
Note that if the SCTP extension for Partial Reliability (PR-SCTP)
[RFC3758] is used for a user message, user message may be partially
delivered or abandoned. These failures are not a reason for
terminating the DTLS connection and SCTP association.
The DTLS Connection ID SHOULD NOT be negotiated (Section 9 of The DTLS Connection ID SHOULD NOT be negotiated (Section 9 of
[I-D.ietf-tls-dtls13]). If DTLS 1.3 is used, the length field MUST [I-D.ietf-tls-dtls13]). If DTLS 1.3 is used, the length field MUST
NOT be omitted and a 16 bit sequence number SHOULD be used. be included and a 16-bit sequence number SHOULD be used.
4.2. DTLS Connection Handling 4.2. DTLS Connection Handling
The DTLS connection MUST be established at the beginning of the SCTP The DTLS connection MUST be established at the beginning of the SCTP
association and be terminated when the SCTP association is association and be terminated when the SCTP association is
terminated, (i.e. there's only one DTLS connection within one terminated, (i.e., there's only one DTLS connection within one
association). A DTLS connection MUST NOT span multiple SCTP association). A DTLS connection MUST NOT span multiple SCTP
associations. 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 Strea 0 an endpoint receives data that is not either DTLS messages on Stream
or protecetd user messages in the form of a sequence of DTLS Records 0 or protected user messages in the form of a sequence of DTLS
on any stream is a protocol violation. The receiver MAY terminate Records on any stream is a protocol violation. The receiver MAY
the SCTP association due to this protocol violation. terminate the SCTP association due to this protocol violation.
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 not harm as long as the application can
determine whether or not DTLS is used. However, for protocol determine whether or not DTLS is used. However, for protocol
skipping to change at line 444 skipping to change at line 505
This means, in particular, that there is no specific PPID for DTLS. This means, in particular, that there is no specific PPID for DTLS.
4.4. Stream Usage 4.4. Stream Usage
All DTLS Handshake, Alert, or ChangeCipherSpec (DTLS 1.2 only) All DTLS Handshake, Alert, or ChangeCipherSpec (DTLS 1.2 only)
messages MUST be transported on stream 0 with unlimited reliability messages MUST be transported on stream 0 with unlimited reliability
and with the ordered delivery feature. and with the ordered delivery feature.
DTLS messages of the record protocol, which carries the protected DTLS messages of the record protocol, which carries the protected
user messages, SHOULD use multiple streams other than stream 0; they user messages, SHOULD use multiple streams other than stream 0; they
MAY use stream 0 as long as the ordered message semantics is MAY use stream 0. On stream 0 protected user messages as well as any
acceptable. On stream 0 protected user messages as well as any DTLS DTLS messages that aren't record protocol will be mixed, thus the
messages that isn't record protocol will be mixed, thus the
additional head of line blocking can occur. additional head of line blocking can occur.
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 [RFC4895]. All other chunks that can be authenticated, i.e. all in [RFC4895]. All other chunks that can be authenticated, i.e., all
chunk types that can be listed in the Chunk List Parameter [RFC4895], chunk types that can be listed in the Chunk List Parameter [RFC4895],
MUST also be sent in an authenticated way. This makes sure that an MUST also be sent in an authenticated way. This makes sure that an
attacker cannot modify the stream in which a message is sent or attacker cannot modify the stream in which a message is sent or
affect the ordered/unordered delivery of the message. affect the ordered/unordered delivery of the message.
If PR-SCTP as defined in [RFC3758] is used, FORWARD-TSN chunks MUST If PR-SCTP as defined in [RFC3758] is used, FORWARD-TSN chunks MUST
also be sent in an authenticated way as described in [RFC4895]. This also be sent in an authenticated way as described in [RFC4895]. This
makes sure that it is not possible for an attacker to drop messages makes sure that it is not possible for an attacker to drop messages
and use forged FORWARD-TSN, SACK, and/or SHUTDOWN chunks to hide this and use forged FORWARD-TSN, SACK, and/or SHUTDOWN chunks to hide this
dropping. dropping.
I-DATA chunk type as defined in [RFC8260] is RECOMMENDED to be I-DATA chunk type as defined in [RFC8260] is RECOMMENDED to be
supported to avoid some of the down sides that large user messages supported to avoid some of the down sides that large user messages
have on blocking transmission of later arriving high priority user have on blocking transmission of later arriving high priority user
messages. However, the support is not mandated and negotiated messages. However, the support is not mandated and negotiated
independently from DTLS/SCTP. If I-DATA chunks are used then they independently from DTLS/SCTP. If I-DATA chunks are used, then they
MUST be sent in an authenticated way as described in [RFC4895]. MUST be sent in an authenticated way as described in [RFC4895].
4.6. SCTP-AUTH Hash Function 4.6. SCTP-AUTH Hash Function
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 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. Renegotiation 4.7. Renegotiation
Renegotiation enables rekeying and reauthentication inside an DTLS DTLS 1.2 renegotiation enables rekeying (with ephemeral Diffie-
1.2 connection. It is up to the upper layer to use/allow it or not. Hellman) of both DTLS and SCTP-AUTH as well as mutual
Application writers should be aware that allowing renegotiations may reauthentication inside an DTLS 1.2 connection. It is up to the
result in changes of security parameters. Renegotiation has been upper layer to use/allow it or not. Application writers should be
removed from DTLS 1.3 and partly replaced with Post-Handshake aware that allowing renegotiations may result in changes of security
messages such as KeyUpdate. See Section 7 for security parameters. Renegotiation has been removed from DTLS 1.3 and partly
considerations regarding rekeying. replaced with post-handshake messages such as KeyUpdate. See
Section 8 for security considerations regarding rekeying.
4.7.1. DTLS 1.2 Considerations
Before sending during renegotiation a ClientHello message or
ServerHello message, the DTLS endpoint MUST ensure that all DTLS
messages using the previous epoch have been acknowledged by the SCTP
peer in a non-revokable way.
Prior to processing a received ClientHello message or ServerHello
message, all other received SCTP user messages that are buffered in
the SCTP layer and can be delivered to the DTLS layer MUST be read
and processed by DTLS.
4.7.2. DTLS 1.3 Considerations
Before sending a KeyUpdate message, the DTLS endpoint MUST ensure
that all DTLS messages have been acknowledged by the SCTP peer in a
non-revokable way. After sending the KeyUpdate message, it stops
sending DTLS messages until the corresponding Ack message has been
processed.
Prior to processing a received KeyUpdate message, all other received
SCTP user messages that are buffered in the SCTP layer and can be
delivered to the DTLS layer MUST be read and processed by DTLS.
4.8. DTLS Epochs 4.8. DTLS Epochs
In general, DTLS implementations SHOULD discard records from earlier In general, DTLS implementations SHOULD discard records from earlier
epochs, as described in Section 4.2.1 of [I-D.ietf-tls-dtls13]. To epochs. However, in the context of a reliable communication this is
avoid discarding messages, the processing guidelines in Section 4.2.1 not appropriate.
of DTLS 1.3 [I-D.ietf-tls-dtls13] or Section 4.1 or DTLS 1.2
[RFC6347] should be followed. 4.8.1. DTLS 1.2 Considerations
The procedures of Section 4.1 of [RFC6347] MUST NOT be followed.
Instead, when currently using epoch n, for n > 1, DTLS packets from
epoch n - 1 and n MUST be processed.
4.8.2. DTLS 1.3 Considerations
The procedures of Section 4.2.1 of [I-D.ietf-tls-dtls13] are
irrelevant. When receiving DTLS packets using epoch n, no DTLS
packets from earlier epochs are received.
4.9. Handling of Endpoint-Pair Shared Secrets 4.9. Handling of Endpoint-Pair Shared Secrets
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. establishing shared secrets for SCTP-AUTH. The endpoint-pair shared
secret for Shared Key Identifier 0 is empty and MUST be used when
establishing a DTLS connection.
The endpoint-pair shared secret for Shared Key Identifier 0 is empty 4.9.1. DTLS 1.2 Considerations
and MUST be used when establishing a DTLS connection. In DTLS 1.2,
whenever the main secret changes, a 64-byte shared secret is derived
from every main secret and provided as a new endpoint-pair shared
secret by using the TLS-Exporter. In DTLS 1.3, the exporter_secret
never change. For DTLS 1.3, the exporter is described in [RFC8446].
For DTLS 1.2, the exporter is described in [RFC5705]. The exporter
MUST use the label given in Section Section 6 and no context. The
new Shared Key Identifier MUST be the old Shared Key Identifier
incremented by 1. If the old one is 65535, the new one MUST be 1.
Before sending the DTLS Finished message, the active SCTP-AUTH key Whenever the master secret changes, a 64-byte shared secret is
derived from every master secret and provided as a new endpoint-pair
shared secret by using the TLS-Exporter described in [RFC5705]. 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 given
in Section Section 7 and no context. The new Shared Key Identifier
MUST be the old Shared Key Identifier incremented by 1.
After sending the DTLS Finished message, the active SCTP-AUTH key
MUST be switched to the new one. MUST be switched to the new one.
Once the corresponding Finished message from the peer has been Once the initial Finished message from the peer has been processed by
received, the old SCTP-AUTH key SHOULD be removed. DTLS, the SCTP-AUTH key with Shared Key Identifier 0 MUST be removed.
Once the Finished message using DTLS epoch n with n > 2 has been
processed by DTLS, the SCTP-AUTH key with Shared Key Identifier n - 2
MUST be removed.
4.9.2. DTLS 1.3 Considerations
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
using the TLS-Exporter described in [RFC8446]. 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 given in
Section Section 7 and no context. This shared secret MUST use Shared
Key Identifier 1.
After sending the DTLS Finished message, the active SCTP-AUTH key
MUST be switched to use Shared Key Identifier 1.
Once the Finished message from the peer has been processed by DTLS,
the SCTP-AUTH key with Shared Key Identifier 0 MUST be removed.
4.10. Shutdown 4.10. 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, a CloseNotify message MUST only be sent after all
outstanding SCTP user messages have been acknowledged by the SCTP outstanding SCTP user messages have been acknowledged by the SCTP
peer and MUST NOT be revoked by the SCTP peer. peer in a non-revokable way.
Prior to processing a received CloseNotify, all other received SCTP Prior to processing a received CloseNotify, all other received SCTP
user messages that are buffered in the SCTP layer MUST be read and user messages that are buffered in the SCTP layer MUST be read and
processed by DTLS. processed by DTLS.
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 description
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 to inform its peer that it is able with the IANA assigned value TBD (Section 7.2) to inform its peer
to support DTLS over SCTP per this specification. that it is able to support DTLS over SCTP per this specification.
5.2. DTLS/SCTP "dtls_over_sctp_maximum_message_size" Extension
The endpoint's DTLS/SCTP maximum message size is declared in the
"dtls_over_sctp_maximum_message_size" TLS extension. The
ExtensionData of the extension is MessageSizeLimit:
uint64 MessageSizeLimit;
The value of MessageSizeLimit is the maximum plaintext user message
size in octets that the endpoint is willing to receive. When the
"dtls_over_sctp_maximum_message_size" extension is negotiated, an
endpoint MUST NOT send a user message larger than the
MessageSizeLimit value it receives from its peer.
This value is the length of the user message before DTLS
fragmentation and protection. The value does not account for the
expansion due to record protection, record padding, or the DTLS
header.
The "dtls_over_sctp_maximum_message_size" MUST be used to negotiate
maximum message size for DTLS/SCTP. A DTLS/SCTP endpoint MUST treat
the omission of "dtls_over_sctp_maximum_message_size" as a fatal
error unless supporting RFC 6083 fallback Section 5.6, and it SHOULD
generate an "illegal_parameter" alert. Endpoints MUST NOT send a
"dtls_over_sctp_maximum_message_size" extension with a value smaller
than 16383. An endpoint MUST treat receipt of a smaller value as a
fatal error and generate an "illegal_parameter" alert.
The "dtls_over_sctp_maximum_message_size" MUST NOT be send in TLS or
in DTLS versions earlier than 1.2. In DTLS 1.3, the server sends the
"dtls_over_sctp_maximum_message_size" extension in the
EncryptedExtensions message.
During resumption, the maximum message size is renegotiated.
5.3. 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]
skipping to change at line 618 skipping to change at line 698
--- 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] ----------------->
... ...
... ...
<--------------- AUTH; DATA[DTLS Handshake] ------------------ <--------------- AUTH; DATA[DTLS Handshake] ------------------
5.4. Client Use Case 5.3. Client Use Case
When a SCTP Client initiates an Association with DTLS/SCTP Mandatory When a client initiates an SCTP Association with DTLS protection,
Options, it can receive an INIT-ACK also containing DTLS/SCTP i.e., the SCTP INIT containing DTSL/SCTP Mandatory Options, it can
Mandatory Options, in that case the Association will proceed as receive an INIT-ACK also containing DTLS/SCTP Mandatory Options, in
specified in the previous Section 5.3 section. If the peer replies that case the Association will proceed as specified in the previous
with an INIT-ACK not containing all DTLS/SCTP Mandatory Options, the Section 5.2 section. If the peer replies with an INIT-ACK not
Client can decide to keep on working with RFC 6083 fallback, plain containing all DTLS/SCTP Mandatory Options, the client SHOULD reply
data only, or to ABORT the association. with an SCTP ABORT.
5.5. Server Use Case 5.4. Server Use Case
If a SCTP Server supports DTLS/SCTP, when receiving an INIT chunk If a SCTP Server supports DTLS/SCTP, i.e., per this specification,
with all DTLS/SCTP Mandatory Options it must reply with INIT-ACK also when receiving an INIT chunk with all DTLS/SCTP Mandatory Options it
containing the all DTLS/SCTP Mandatory Options, then it must follow will reply with an INIT-ACK also containing all the DTLS/SCTP
the sequence for DTLS initialization Section 5.3 and the related Mandatory Options, following the sequence for DTLS initialization
traffic case. If a SCTP Server supports DTLS, when receiving an INIT Section 5.2 and the related traffic case. If a SCTP Server that
chunk with not all DTLS/SCTP Mandatory Options, it can decide to supports DTLS and configured to use it, receives an INIT chunk
continue by creating an Association with RFC 6083 fallback, plain without all DTLS/SCTP Mandatory Options, it SHOULD reply with an SCTP
data only or to ABORT it. ABORT.
5.6. RFC 6083 Fallback 5.5. RFC 6083 Fallback
This section discusses how an endpoint supporting this specification This section discusses how an endpoint supporting this specification
can fallback to follow the DTLS/SCTP behavior in RFC 6083. 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
16383 bytes and where the security issues can be mitigated or 16383 bytes and where the security issues can be mitigated or
considerd acceptable. Fallback is NOT RECOMMEND to be enabled as it considered acceptable. Fallback is NOT RECOMMEND to be enabled as it
enables downgrade to weaker algorithms and versions of DTLS. enables downgrade to weaker algorithms and versions of DTLS.
A SCTP client that receives an INIT-ACK that is not compliant An SCTP endpoint that receives an INIT chunk or an INIT-ACK chunk
according this specification may in certain cases potentially perform that does not contain the SCTP-Adaptation-Indication parameter with
an fallback to RFC 6083 behavior. The first case is when the SCTP the DTLS/SCTP adaptation layer codepoint, see Section 7.2, may in
client receives an INIT-ACK doesn't contain the SCTP-Adaptation- certain cases potentially perform a fallback to RFC 6083 behavior.
Indication parameter with the DTLS/SCTP adaptation layer codepoint However, the fallback attempt should only be performed if policy says
but do include the SCTP-AUTH parameters on a server that are expected that is acceptable.
to provide services using DTLS. The second case is when the INIT-ACK
do contain the SCTP-Adaptation-Indication parameter with the correct
code point, however the HMAC-ALGO or the Chunks parameters values are
such that do not fullfil the requirement of this specification but do
meet the requirements of RFC 6083. In either of these cases the
client could attempt DTLS per RFC 6083 as fallback. However, the
fallback attempt should only be performed if policy says that is
acceptable.
If fallback is allowed it is possible that the client will send plain If fallback is allowed, it is possible that the client will send
text user messages prior to DTLS handshake as it is allowed per RFC plain text user messages prior to DTLS handshake as it is allowed per
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. When performing the the DTLS handshake, the allowing fallback.
server is required accepting that lack of the TLS extension
"dtls_over_sctp_maximum_message_size" and can't treat it as fatal
error. In case the "dtls_over_sctp_maximum_message_size" TLS
extension is present in the handshake the server SHALL continue the
handshake including the extension with its value also, and from that
point follow this specification. In case the TLS option is missing
RFC 6083 applies.
6. IANA Considerations 6. Socket API Considerations
6.1. TLS Exporter Label This section describes how the socket API defined in [RFC6458] is
extended to provide a way for the application to observe the HMAC
algorithms used for sending and receiving of AUTH chunks.
Please note that this section is informational only.
A socket API implementation based on [RFC6458] is, by means of the
existing SCTP_AUTHENTICATION_EVENT event, extended to provide the
event notification whenever a new HMAC algorithm is used in a
received AUTH chunk.
Furthermore, two new socket options for the level IPPROTO_SCTP and
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
the HMAC algorithm used for sending AUTH chunks. The second enables
the monitoring of HMAC algorithms used in received AUTH chunks via
the SCTP_AUTHENTICATION_EVENT event.
Support for the SCTP_SEND_HMAC_IDENT and
SCTP_EXPOSE_HMAC_IDENT_CHANGES socket options also needs to be added
to the function sctp_opt_info().
6.1. Socket Option to Get the HMAC Identifier being Sent
(SCTP_SEND_HMAC_IDENT)
During the SCTP association establishment a HMAC Identifier is
selected which is used by an SCTP endpoint when sending AUTH chunks.
An application can access the result of this selection by using this
read-only socket option, which uses the level IPPROTO_SCTP and the
name SCTP_SEND_HMAC_IDENT.
The following structure is used to access HMAC Identifier used for
sending AUTH chunks:
struct sctp_assoc_value {
sctp_assoc_t assoc_id;
uint32_t assoc_value;
};
assoc_id: This parameter is ignored for one-to-one style sockets.
For one-to-many style sockets, the application fills in an
association identifier. It is an error to use
SCTP_{FUTURE|CURRENT|ALL}_ASSOC in assoc_id.
assoc_value: This parameter contains the HMAC Identifier used for
sending AUTH chunks.
6.2. Exposing the HMAC Identifiers being Received
Section 6.1.8 of [RFC6458] defines the SCTP_AUTHENTICATION_EVENT
event, which uses the following structure:
struct sctp_authkey_event {
uint16_t auth_type;
uint16_t auth_flags;
uint32_t auth_length;
uint16_t auth_keynumber;
uint32_t auth_indication;
sctp_assoc_t auth_assoc_id;
};
This document updates this structure to
struct sctp_authkey_event {
uint16_t auth_type;
uint16_t auth_flags;
uint32_t auth_length;
uint16_t auth_identifier; /* formerly auth_keynumber */
uint32_t auth_indication;
sctp_assoc_t auth_assoc_id;
};
by renaming auth_keynumber to auth_identifier. auth_identifier just
replaces auth_keynumber in the context of [RFC6458]. In addition to
that, the SCTP_AUTHENTICATION_EVENT event is extended to also
indicate when a new HMAC Identifier is received and such reporting is
explicitly enabled as described in Section 6.3. In this case
auth_indication is SCTP_AUTH_NEW_HMAC and the new HMAC identifier is
reported in auth_identifier.
6.3. Socket Option to Expose HMAC Identifier Usage
(SCTP_EXPOSE_HMAC_IDENT_CHANGES)
This options allows the application to enable and disable the
reception of SCTP_AUTHENTICATION_EVENT events when a new HMAC
Identifiers has been received in an AUTH chunk (see Section 6.2).
This read/write socket option uses the level IPPROTO_SCTP and the
name SCTP_EXPOSE_HMAC_IDENT_CHANGES. It is needed to provide
backwards compatibility and the default is that these events are not
reported.
The following structure is used to enable or disable the reporting of
newly received HMAC Identifiers in AUTH chunks:
struct sctp_assoc_value {
sctp_assoc_t assoc_id;
uint32_t assoc_value;
};
assoc_id: This parameter is ignored for one-to-one style sockets.
For one-to-many style sockets, the application may fill in an
association identifier or SCTP_{FUTURE|CURRENT|ALL}_ASSOC.
assoc_value: Newly received HMAC Identifiers are reported if, and
only if, this parameter is non-zero.
7. IANA Considerations
7.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.
6.2. DTLS "dtls_over_sctp_buffer_size_limit" Extension 7.2. SCTP Adaptation Layer Indication Code Point
This document registers the "dtls_over_sctp_maximum_message_size" [RFC5061] defined a IANA registry for Adaptation Code Points to be
extension in the TLS "ExtensionType Values" registry established in used in the Adaptation Layer Indication parameter. The registry was
[RFC5246]. The "dtls_over_sctp_maximum_message_size" extension has at time of writing located: https://www.iana.org/assignments/sctp-
been assigned a code point of TBD. This entry [[will be|is]] marked parameters/sctp-parameters.xhtml#sctp-parameters-27 IANA is requested
as recommended ([RFC8447] and marked as "Encrypted" in (D)TLS 1.3 to assign one Adaptation Code Point for DTLS/SCTP per the below
[I-D.ietf-tls-dtls13]. The IANA registry [RFC8447] [[will proposed entry in Table 1.
list|lists]] this extension as "Recommended" (i.e., "Y") and
indicates that it may appear in the ClientHello (CH) or
EncryptedExtensions (EE) messages in (D)TLS 1.3
[I-D.ietf-tls-dtls13].
6.3. SCTP Parameter +============================+=============+===========+
| Code Point (32-bit number) | Description | Reference |
+============================+=============+===========+
| 0x00000002 | DTLS/SCTP | [RFC-TBD] |
+----------------------------+-------------+-----------+
IANA is requested to assign a Adaptation Code Point for DTLS/SCTP. Table 1: Adaptation Code Point
7. Security Considerations RFC-Editor Note: Please replace [RFC-TBD] with the RFC number given
to this specification.
8. 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.
7.1. Cryptographic Considerations 8.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] provides recommendations for improving the security BCP 195 [RFC7525] provides recommendations for improving the security
of deployed services that use TLS. 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.
HTTP/2 [RFC7540] gives good minimum requirements based on the attacks HTTP/2 [RFC7540] gives good minimum requirements based on the attacks
that where publicly known in 2015. DTLS 1.3 [I-D.ietf-tls-dtls13] that where publicly known in 2015. DTLS 1.3 [I-D.ietf-tls-dtls13]
only define strong algorithms without major weaknesses at the time of only define strong algorithms without major weaknesses at the time of
publication. Many of the TLS registries have a "Recommended" column. publication. Many of the TLS registries have a "Recommended" column.
Parameters not marked as "Y" are NOT RECOMMENDED to support. Parameters not marked as "Y" are NOT RECOMMENDED to support.
DTLS 1.3 requires rekeying before algorithm specific AEAD limits have DTLS 1.3 requires rekeying before algorithm specific AEAD limits have
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. HMAC-SHA-256 as used in SCTP-AUTH has a very DTLS 1.2 specification.
large tag length and very good integrity properties. The SCTP-AUTH
key can be used until the DTLS handshake is re-run at which point a HMAC-SHA-256 as used in SCTP-AUTH has a very large tag length and
new SCTP-AUTH key is derived using the TLS-Exporter. very good integrity properties. The SCTP-AUTH key can be used until
the DTLS handshake is re-run at which point a new SCTP-AUTH key is
derived using the TLS-Exporter. As discussed below DTLS 1.3 does not
currently support renegotiation and lacks the capability of updating
the SCTP-AUTH key.
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. ANSSI run of Diffie-Hellman to provide Perfect Forward Secrecy. ANSSI
writes "It is recommended to force the periodic renewal of the keys, writes "It is recommended to force the periodic renewal of the keys,
e.g. every hour and every 100 GB of data, in order to limit the e.g., every hour and every 100 GB of data, in order to limit the
impact of a key compromise." [ANSSI-DAT-NT-003]. impact of a key compromise." [ANSSI-DAT-NT-003].
For many DTLS/SCTP deployments the DTLS connections are expected to For many DTLS/SCTP deployments the DTLS connections are expected to
have very long lifetimes of months or even years. For connections have very long lifetimes of months or even years. For connections
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. authenticate both client and server.
When using DTLS 1.2 [RFC6347], AEAD limits, frequant re- When using DTLS 1.2 [RFC6347], AEAD limits, frequent re-
authentication and frequent re-run of Diffie-Hellman can be achieved authentication and frequent re-run of Diffie-Hellman can be achieved
with frequent renegotiation, see TLS 1.2 [RFC5246]. When with frequent renegotiation, see TLS 1.2 [RFC5246]. When
renegotiation is used both clients and servers MUST use the renegotiation is used both clients and servers MUST use the
renegotiation_info extension [RFC5746] and MUST follow the renegotiation_info extension [RFC5746] and MUST follow the
renegotiation guidelines in BCP 195 [RFC7525]. renegotiation guidelines in BCP 195 [RFC7525]. In particular, both
clients and servers MUST NOT accept a change of identity during
renegotiation.
In DTLS 1.3 renegotiation has been removed from DTLS 1.3 and partly In DTLS 1.3 renegotiation has been removed from DTLS 1.3 and partly
replaced with Post-Handshake KeyUpdate. When using DTLS 1.3 replaced with Post-Handshake KeyUpdate. When using DTLS 1.3
[I-D.ietf-tls-dtls13], AEAD limits and frequent rekeying can be [I-D.ietf-tls-dtls13], AEAD limits and frequent rekeying can be
achieved by sending frequent Post-Handshake KeyUpdate messages. achieved by sending frequent post-handshake KeyUpdate messages.
Symmetric rekeying gives less protection against key leakage than re- Symmetric rekeying gives less protection against key leakage than re-
running Diffie-Hellman. After leakage of running Diffie-Hellman. After leakage of
application_traffic_secret_N, a passive attacker can passively application_traffic_secret_N, a passive attacker can passively
eavesdrop on all future application data sent on the connection eavesdrop on all future application data sent on the connection
including application data encrypted with including application data encrypted with
application_traffic_secret_N+1, application_traffic_secret_N+2, etc. application_traffic_secret_N+1, application_traffic_secret_N+2, etc.
The is no way to do Post-Handshake server authentication or Ephemeral The is no way to do post-handshake server authentication or Ephemeral
Diffie-Hellman inside a DTLS 1.3 connection. Note that KeyUpdate Diffie-Hellman inside a DTLS 1.3 connection. Note that KeyUpdate
does not update the exporter_secret. does not update the exporter_secret.
7.2. Downgrade Attacks For upper layer protocols where frequent re-run of Diffie-Hellman,
rekeying of SCTP-AUTH, and server reauthentication is required and
creating a new SCTP connection with DTLS 1.3 to replace the current
is not a viable option it is RECOMMENDED to use DTLS 1.2.
8.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.
7.3. DTLS/SCTP Message Sizes 8.3. Authentication and Policy Decisions
The DTLS/SCTP maximum message size extension enables secure negation
of a message sizes that fit in the DTLS/SCTP buffer, which improves
security and availability. Very small plain text user fragment sizes
might generate additional work for senders and receivers, limiting
throughput and increasing exposure to denial of service.
The maximum message size extension does not protect against peer
nodes intending to negatively affect the peer node through flooding
attacks. The attacking node can both send larger messages than the
expressed capability as well as initiating a large number of
concurrent user message transmissions that never are concluded. For
the target of the attack it is more straight forward to determine
that a peer is ignoring the node's stated limitation.
7.4. Authentication and Policy Decisions
DTLS/SCTP MUST be mutually authenticated. It is RECOMMENDED that DTLS/SCTP MUST be mutually authenticated. It is RECOMMENDED that
DTLS/SCTP is used with certificate based authentication. All DTLS/SCTP is used with certificate-based authentication. All
security decisions MUST be based on the peer's authenticated 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.
7.5. Privacy Considerations 8.4. 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 clear text, 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 Perfect Forward Secrecy. Perfect Forward Secrecy
significantly limits the amount of data that can be compromised due significantly limits the amount of data that can be compromised due
to key compromise. to key compromise.
7.6. Pervasive Monitoring 8.5. 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 perfect forward
secrecy, DTLS/SCTP effectively mitigate many forms of passive secrecy, DTLS/SCTP effectively mitigate many forms of passive
pervasive monitoring and limits the amount of compromised data due to pervasive monitoring and limits the amount of compromised data due to
key compromise. key compromise.
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
increases the risk of identifying individual users. increase the risk of identifying individual users.
8. Acknowledgments 9. 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.
9. References The authors of this document want to thank GitHub user vanrein for
their contribution.
9.1. Normative References 10. References
10.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 line 916 skipping to change at line 1090
[RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann, [RFC8260] Stewart, R., Tuexen, M., Loreto, S., and R. Seggelmann,
"Stream Schedulers and User Message Interleaving for the "Stream Schedulers and User Message Interleaving for the
Stream Control Transmission Protocol", RFC 8260, Stream Control Transmission Protocol", RFC 8260,
DOI 10.17487/RFC8260, November 2017, DOI 10.17487/RFC8260, November 2017,
<https://www.rfc-editor.org/info/rfc8260>. <https://www.rfc-editor.org/info/rfc8260>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[RFC8447] Salowey, J. and S. Turner, "IANA Registry Updates for TLS [RFC8996] Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
and DTLS", RFC 8447, DOI 10.17487/RFC8447, August 2018, 1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
<https://www.rfc-editor.org/info/rfc8447>. <https://www.rfc-editor.org/info/rfc8996>.
[I-D.ietf-tls-dtls13] [I-D.ietf-tls-dtls13]
Rescorla, E., Tschofenig, H., and N. Modadugu, "The Rescorla, E., Tschofenig, H., and N. Modadugu, "The
Datagram Transport Layer Security (DTLS) Protocol Version Datagram Transport Layer Security (DTLS) Protocol Version
1.3", Work in Progress, Internet-Draft, draft-ietf-tls- 1.3", Work in Progress, Internet-Draft, draft-ietf-tls-
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>.
9.2. Informative References 10.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,
"Security Considerations for Signaling Transport (SIGTRAN)
Protocols", RFC 3788, DOI 10.17487/RFC3788, June 2004,
<https://www.rfc-editor.org/info/rfc3788>.
[RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M. [RFC5061] Stewart, R., Xie, Q., Tuexen, M., Maruyama, S., and M.
Kozuka, "Stream Control Transmission Protocol (SCTP) Kozuka, "Stream Control Transmission Protocol (SCTP)
Dynamic Address Reconfiguration", RFC 5061, Dynamic Address Reconfiguration", RFC 5061,
DOI 10.17487/RFC5061, September 2007, DOI 10.17487/RFC5061, September 2007,
<https://www.rfc-editor.org/info/rfc5061>. <https://www.rfc-editor.org/info/rfc5061>.
[RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram [RFC6083] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram
Transport Layer Security (DTLS) for Stream Control Transport Layer Security (DTLS) for Stream Control
Transmission Protocol (SCTP)", RFC 6083, Transmission Protocol (SCTP)", RFC 6083,
DOI 10.17487/RFC6083, January 2011, DOI 10.17487/RFC6083, January 2011,
skipping to change at line 977 skipping to change at line 1156
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
2015, <https://www.rfc-editor.org/info/rfc7525>. 2015, <https://www.rfc-editor.org/info/rfc7525>.
[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 IPsec", ANSSI Technical Report DAT-NT-003 , August with 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>>.
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. Thus, this document mandates usage of relevant of usefulness. Thus, this document mandates usage of relevant
versions and algorithms. versions and algorithms.
Clarifications: Some implementation experiences has 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
Ericsson Ericsson
 End of changes. 86 change blocks. 
303 lines changed or deleted 482 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/