RFC 3436

Transport Layer Security over Stream Control Transmission Protocol

📅 published December 2002, from ietf

RFC 3436: Transport Layer Security over Stream Control Transmission Protocol 🎀

okay so this RFC is from December 2002 and it's a Standards Track doc, which means it's an official Internet protocol standard, not just a suggestion 💅 The authors are A. Jungmaier (University of Essen), E. Rescorla (RTFM Inc.), and M. Tuexen (Siemens AG). The title block doesn't list anything it obsoletes or updates, so it's standing on its own 🦋

Status of This Memo 📜

okay so this bit says the doc is an Internet standards track protocol for the Internet community, and it's asking people to discuss it and suggest improvements 💬 for the current standardization state, check the "Internet Official Protocol Standards" (STD 1) list. And distribution is unlimited, so anyone can read it 🌸

Copyright (C) The Internet Society (2002). All Rights Reserved. 🔒

Abstract ✨

this doc is about using TLS (the Transport Layer Security protocol, RFC 2246) on top of SCTP (the Stream Control Transmission Protocol, RFC 2960 and RFC 3309) 🫶

the TLS user gets to enjoy SCTP features, like having multiple streams so one stream doesn't cause head of line blocking for everyone else, and multi-homing for network-level fault tolerance. it's giving reliability 💖

there's also talk about extending SCTP, especially dynamic reconfiguration of IP addresses 🧚

1. Introduction 💅

1.1. Overview 🌈

okay so the overview says this doc describes using TLS, as defined in [RFC2246], over SCTP, as defined in [RFC2960] and [RFC3309] 🍓

TLS is built to run on a byte-stream transport that gives you reliable, in-sequence delivery. right now, TLS mostly runs on TCP (defined in [RFC793]) 🦋

comparing TCP and SCTP, SCTP has extra features, and this doc shows how TLS should be used with SCTP so the TLS user can get some of those extras ✨

this doc defines two things:

  • how to use the multiple streams feature of SCTP. 🎀
  • how to handle the message-oriented nature of SCTP. 💌

the TLS user can also take advantage of SCTP multi-homing 🌸 and the dynamic reconfiguration of IP addresses (which is still being discussed) can be used with this solution too 🧚

ngl the best part: the method here doesn't change TLS or SCTP at all 😭 the only thing it needs is for SCTP implementations to support the optional feature of fragmentation of SCTP user messages 🔥

1.2. Terminology 📖

this doc uses these terms:

  • Association: an SCTP association. 🫧
  • Connection: a TLS connection. 🔗
  • Session: a TLS session. 💜
  • Stream: a unidirectional stream of an SCTP association. It's uniquely identified by a stream identifier. 🌊

1.3. Abbreviations 🔤

  • MTU: Maximum Transmission Unit
  • SCTP: Stream Control Transmission Protocol
  • TCP: Transmission Control Protocol
  • TLS: Transport Layer Security

2. Conventions 👑

okay the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be read as described in BCP 14, RFC 2119 [RFC2119] 🧐 that's the official key word lingo, so keep an eye on those caps!

3. SCTP Requirements 🌷

3.1. Number of Inbound and Outbound Streams 🌊

say there's an association between endpoints A and Z. it gives you n streams from A to Z and m streams from Z to A 🫧

two streams with the same stream identifier count as one bi-directional stream, so they're treated as a pair 💞

that means an SCTP association is basically a set of min(n,m) bi-directional streams plus (max(n,m) - min(n,m)) uni-directional streams. the math is giving organized 📐✨

3.2. Fragmentation of User Messages 🧩

so TLS doesn't have to know or handle the MTU itself, SCTP MUST provide fragmentation of user messages. it's an optional feature of [RFC2960], but here it's not optional 😤 SCTP is message-oriented, so it has to be able to send all TLS records as SCTP user messages. That means the supported maximum length of SCTP user messages MUST be at least 2^14 + 2048 + 5 = 18437 bytes, which is the maximum length of a TLSCiphertext, as defined in [RFC2246] 💀

please note that an SCTP implementation might need the partial delivery API to handle user messages this big 🙈

so SCTP does the fragmenting and reassembling of TLS records itself, which avoids IP fragmentation 🫶

4. TLS Requirements 🔐

4.1 Supported Ciphersuites 🎀

a TLS implementation for TLS over SCTP MUST support at least the ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA, as defined in [RFC3268] 🔑 this one's the baseline, no skipping it!

5. Connections and Bi-directional Streams 🦋

TLS uses a bi-directional stream by setting up a connection on it. so the number of connections in an association is capped by the number of bi-directional streams 📊

the TLS handshake protocol runs on each bi-directional stream separately 🧵 each handshake can be:

  • a full handshake, or
  • an abbreviated handshake that resumes a TLS session using a session id from another connection (on the same association or a different one).

once the handshake on a connection is done, that bi-directional stream can carry TLS-based user data 💌 also, the handshakes for different connections are independent, so they can be delayed until the stream actually gets used for user data 🌸

6. Usage of Bi-directional Streams 🌈

it's not required that every bi-directional stream carries TLS-based user data. if TLS isn't used on a stream, that's called SCTP-based user data transmission 🧃

6.1. SCTP-based User Data Transmission 🍭

if a bi-directional stream isn't used for TLS-based communication, there are no restrictions on the SCTP features it can use for SCTP-based user data transmission 🎉

6.2. TLS-based User Data Transmission 💜

usually the bi-directional stream is used for TLS-based user data transmission, and it SHOULD NOT be used for SCTP-based user data transmission 🙅‍♀️ the exception is for protocols with upgrade-to-TLS mechanisms, like HTTP upgrade [RFC2817] and SMTP over TLS [RFC3207] ✨

TLS requires the underlying transport to deliver TLS records in strict sequence. so the 'unordered delivery' feature of SCTP MUST NOT be used on streams that carry TLS-based user data 🚫 for the same reason, TLS records handed to SCTP for transmission MUST NOT have limited lifetimes ⏳

7. Usage of Uni-directional Streams 🌷

uni-directional streams can't be used for TLS-based user data transmission 😔 but they can be used without any restrictions for SCTP-based communication 🫧

8. Examples 🧚

in these examples, we're looking at an association with two bi-directional streams 👯‍♀️

8.1. Two Bi-directional Streams with Full Handshake 🤝

right after the association is set up, the client sends two ClientHello messages, on bi-directional streams 0 and 1 🌟 once a full handshake finishes on each stream, TLS-based user data can flow on that stream. it's totally possible for stream 0 to be done with its handshake and already sending data while stream 1's handshake isn't finished yet, or the other way around 🔄

8.2. Two Bi-directional Streams with an Abbreviated Handshake ⚡

after the association is set up, the client starts a full handshake on bi-directional stream 0. the server gives back a session identifier that allows session resumption 🪪 once that full handshake is done, the client starts an abbreviated handshake on bi-directional stream 1, using the session identifier from stream 0. while that's happening, user data can go on stream 0 but not on stream 1 🙈 after the abbreviated handshake finishes on stream 1, user data can go on both streams 🎊

whether to use abbreviated handshakes during TLS connection setup over an SCTP association depends on a few things:

  • the complexity and duration of the initial handshake processing (which also depends on how many connections there are), and
  • the network performance (round-trip times and bandwidth).

abbreviated handshakes can seriously cut down the computational complexity of the handshake, which is great if that's your limiting resource 💪 if you need to set up a lot of connections, using TLS session resumption might be a big help 🌈 but an abbreviated handshake can only happen after a full handshake is complete, so there's a catch 😅 on networks with big round-trip times, it can be better to run several full handshakes in parallel 🛫 so both options are allowed, and you pick what fits your situation 💖

8.3. Two Bi-directional Streams with a Delayed Abbreviated Handshake ⏰

this one's like the last example, except that after the full handshake on stream 0 finishes, the abbreviated handshake on stream 1 doesn't start right away 🐢 stream 0 can carry user data already. the abbreviated handshake on stream 1 only starts once the user wants to send data on stream 1 too 🫶

this lets the TLS user ask for lots of bi-directional streams without having to provide all those resources at association start-up, as long as not every stream gets used right away 🧠

8.4. Two Bi-directional Streams without Full Handshakes 🫧

this example is like the second and third ones, but an abbreviated handshake is used for both bi-directional streams 🔁 that needs a valid session identifier from connections handled by another association 🪄

9. Security Considerations 🚨

⚠️ okay this section is serious business, so read it carefully!

using TLS on top of SCTP doesn't add any new security issues beyond the ones already discussed in [RFC2246] and [RFC2960] 🔐

it's possible to authenticate TLS endpoints based on IP addresses in certificates. but unlike TCP, SCTP associations can use multiple addresses per SCTP endpoint 🌐 so TLS records might be sent from a different IP address than the one that was originally authenticated. that's fine as long as no security decisions are made based on that IP address 🙏 this is a special case of a general rule: all decisions should be based on the peer's authenticated identity, not on its transport layer identity 💅🔥

10. Acknowledgements 💌

the authors would like to thank P. Calhoun, J. Wood, and many others for their invaluable comments and suggestions 🫶💖

11. References 📚

nothing is listed under this heading in the original text, so there are no references to carry over 🦋

11.1. Normative References ✨

okay so first up are the normative refs, the stuff you actually have to have read to get the spec 💅

  • [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 🔑 the one that tells you what all those capital words mean
  • [RFC2246] Diercks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. 🔐 TLS 1.0, the OG
  • [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxon, "Stream Control Transmission Protocol", RFC 2960, October 2000. 🌊 SCTP, the whole reason we're here
  • [RFC3268] Chown, P., "Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)", RFC 3268, June 2002. 🧁 AES ciphersuites for TLS
  • [RFC3309] Stone, J., Stewart, R., Otis, D., "Stream Control Transmission Protocol (SCTP) Checksum Change", RFC 3309, September 2002. 🧮 the checksum glow-up for SCTP

11.2. Informative References 🧠

these ones are the extra reading. good to know, not strictly required, but I'm obsessed with them anyway 🫶

  • [RFC793] Postel, J. (ed.), "Transmission Control Protocol", STD 7, RFC 793, September 1981. 🦕 TCP, the legend
  • [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 📜 how the standards process itself works
  • [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, May 2000. 🌐 upgrading to TLS inside HTTP/1.1
  • [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over TLS", RFC 3207, February 2002. 📧 secure SMTP over TLS, iykyk

12. Authors' Addresses 🎀

these are the people who wrote it, and yes, they're giving real main character energy ✨

Andreas Jungmaier
University of Essen
Networking Technology Group at the IEM
Ellernstrasse 29
D-45326 Essen
Germany

Phone: +49 201 1837667
EMail: ajung@exp-math.uni-essen.de


Eric Rescorla
RTFM, Inc.
2064 Edgewood Drive
Palo Alto, CA 94303
USA

Phone: +1 650-320-8549
EMail: ekr@rtfm.com


Michael Tuexen
Siemens AG
D-81359 Munich
Germany

Phone: +49 89 722 47210
EMail: Michael.Tuexen@siemens.com

Copyright (C) The Internet Society (2002). All Rights Reserved.

okay, legal stuff, but it's actually important so I'm keeping it as close to the original as I can 🙈

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 🫶

Funding for the RFC Editor function is currently provided by the Internet Society. 💖

📦 where this page comes from