Transport Layer Security over Stream Control Transmission Protocol
updated by
- rfc-8996 — Deprecating TLS 1.0 and TLS 1.1
Extracted elements (19)
Both full and abbreviated (session-resumption) handshakes are allowed per stream. Abbreviated handshakes reduce computational complexity when many connections are needed, while parallel full handshakes are preferable in high-latency networks. The spec permits both to accommodate diverse deployment conditions.
Handshakes on different bi-directional streams are independent and can be delayed until the stream is actually needed, allowing a large number of streams to be requested without consuming resources at association start-up for streams not immediately used.
SCTP is given responsibility for fragmenting and reassembling TLS records to avoid IP-level fragmentation, eliminating the need for TLS to be aware of the MTU. This leverages SCTP's existing fragmentation capability.
The method requires no changes to TLS or SCTP; it only requires that SCTP implementations support the optional fragmentation of SCTP user messages. This keeps both protocol stacks unchanged.
Protocols containing upgrade-to-TLS mechanisms, such as HTTP upgrade (RFC 2817) and SMTP over TLS (RFC 3207), are an explicit exception to the rule against mixing TLS and SCTP-based data on the same bi-directional stream.
SCTP implementations may need to support the partial delivery API to handle user messages of the maximum required size (18437 bytes) for transporting TLS records.
A bi-directional stream being used for TLS-based user data transmission SHOULD NOT also be used for SCTP-based (unprotected) user data transmission, with the exception of upgrade-to-TLS protocols such as HTTP upgrade and SMTP over TLS.
A TLS implementation for TLS over SCTP MUST support at least the ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA as defined in RFC 3268.
SCTP MUST provide fragmentation of user messages (an optional feature of RFC 2960) so that TLS records can be transmitted without TLS needing to know or handle the MTU.
The supported maximum length of SCTP user messages MUST be at least 18437 bytes (2^14 + 2048 + 5), which is the maximum length of a TLSCiphertext as defined in RFC 2246.
The 'unordered delivery' feature of SCTP MUST NOT be used on streams used for TLS-based user data transmission, because TLS requires the underlying transport to deliver TLS records in strict sequence.
TLS records delivered to SCTP for transmission MUST NOT have limited lifetimes, again because TLS requires strict in-sequence delivery.
A bi-directional stream is defined as a pair of SCTP streams sharing the same stream identifier (one in each direction). An SCTP association provides min(n,m) bi-directional streams and (max(n,m)-min(n,m)) uni-directional streams.
Bi-directional streams not used for TLS-based communication may be used for SCTP-based user data transmission without any restrictions on SCTP features.
Each per-stream TLS handshake may be either a full handshake or an abbreviated handshake that resumes a TLS session (by session ID) from any connection on the same or another SCTP association.
Each TLS connection is established over exactly one bi-directional SCTP stream, and the TLS handshake protocol is run independently on each such stream. The number of TLS connections per association is thus bounded by the number of bi-directional streams.
Uni-directional SCTP streams cannot be used for TLS-based user data transmission, but may be used freely for unprotected SCTP-based communication.
TLS endpoints may be authenticated based on IP addresses in certificates, but SCTP associations can use multiple addresses per endpoint, so TLS records may arrive from a different IP address than the originally authenticated one. No security decisions should be made based on transport-layer (IP) identity; all decisions must be based on the peer's authenticated identity from the TLS certificate.
Using TLS over SCTP introduces no new security issues beyond those already discussed in RFC 2246 (TLS) and RFC 2960 (SCTP).