RFC 4680

RFC 4680: TLS Handshake Message for Supplemental Data 🎀

Okay bestie, here's the main info 💅 This is RFC 4680, written by S. Santesson of Microsoft and published in September 2006. It's on the Standards Track in the Network Working Group. It updates RFC 4346 (TLS 1.1) and doesn't say anything about obsoleting anything else. Now let's get into it ✨

Status of This Memo 📋

This doc is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 If you want the current standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited.

Copyright Notice 🌸

Copyright (C) The Internet Society (2006).

Abstract 🦋

So this spec defines a new TLS handshake message for swapping supplemental application data 💖 TLS hello message extensions decide which supplemental data types both the TLS client and the TLS server support. After that, the supplemental data handshake message is what actually carries the data. Other documents will define the syntax of those extensions and the syntax of the supplemental data types themselves 🧚

1. Introduction ✨

Okay so recent standards work has come up with different ways to send supplemental application data inside the TLS handshake message 👀 For example, some recent proposals send data that TLS itself doesn't process, but that helps the TLS-protected application make authentication and authorization decisions. One proposal sends user name hints for finding credentials, and another sends attribute certificates and Security Assertions Markup Language (SAML) assertions for authorization checks.

To avoid defining a separate handshake message for every new kind of application-specific supplemental data, this spec defines one new handshake message type. It bundles together all the data objects that are going to be delivered to the TLS-protected application and sends them all in one handshake message 🎀

1.1. Terminology 💅

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [N1].

The syntax for the supplemental_data handshake message is defined using the TLS Presentation Language, which is specified in Section 4 of [N2].

2. Supplemental Data Handshake Message 💖

The new supplemental_data handshake message type is made to carry supplemental data objects that were agreed on during the exchange of extensions in the client and server hello messages 🦋 For other handshake message types, see RFC 2246 (TLS 1.0) [N2] and RFC 4346 (TLS 1.1) [N3].

Information provided in a supplemental data object MUST be intended to be used exclusively by applications and protocols above the TLS protocol layer. Any such data MUST NOT need to be processed by the TLS protocol. 🙈

   enum {
          supplemental_data(23), (255)
      } HandshakeType;

   struct {
          HandshakeType msg_type;    /* handshake type */
          uint24 length;             /* octets in message */
          select (HandshakeType) {
                 case supplemental_data:   SupplementalData;
            } body;
       } Handshake;

   struct {
         SupplementalDataEntry supp_data<1..2^24-1>;
      } SupplementalData;

   struct {
         SupplementalDataType supp_data_type;
         uint16 supp_data_length;
         select(SupplementalDataType) { }
      } SupplementalDataEntry;

   enum {
         (65535)
     } SupplementalDataType;

• supp_data_length: This field is the length (in bytes) of the data selected by SupplementalDataType. 📏

The client MUST NOT send more than one SupplementalData handshake message, and the server MUST NOT send more than one SupplementalData handshake message. Receiving more than one SupplementalData handshake message results in a fatal error, and the receiver MUST close the connection with a fatal unexpected_message alert. 🚨

If present, the SupplementalData handshake message MUST contain a non-empty SupplementalDataEntry structure carrying data associated with at least one defined SupplementalDataType. An explicit agreement that governs presence of any supplemental data MUST be concluded between client and server for each SupplementalDataType using the TLS extensions [N4] in the client and server hello messages. Receiving an unexpected SupplementalData handshake message results in a fatal error, and the receiver MUST close the connection with a fatal unexpected_message alert. 💀

Other documents will define specific SupplementalDataTypes and their associated data syntax and processing. Those same specifications must also specify the client and server hello message extensions that are used to negotiate support for the specified supplemental data type. This document only specifies the TLS Handshake Protocol message that carries the supplemental data objects 🧚

Different situations need supplemental data to go from the client to the server, from the server to the client, or both ways. All three situations are fully supported 👑

3. Message Flow 🦋

The SupplementalData handshake message, if exchanged, MUST be sent as the first handshake message, as shown in Figure 1 below. 🎀

  Client                                               Server

  ClientHello (with extensions) -------->

                                 ServerHello(with extensions)
                                            SupplementalData*
                                                 Certificate*
                                           ServerKeyExchange*
                                          CertificateRequest*
                               <--------      ServerHelloDone

  SupplementalData*
  Certificate*
  ClientKeyExchange
  CertificateVerify*
  [ChangeCipherSpec]
  Finished                     -------->
                                           [ChangeCipherSpec]
                               <--------             Finished
  Application Data             <------->     Application Data

    *  Indicates optional or situation-dependent messages.

            Figure 1.  Message Flow with SupplementalData

Author's Address ✨

okay bestie, this is where you find the author! 🎀 Stefan Santesson is at Microsoft, and the mailing address is in Sweden 🌸

Stefan Santesson
Microsoft
Finlandsgatan 30
164 93 KISTA
Sweden

EMail: stefans@microsoft.com 💌

Full Copyright Statement 💅

Copyright (C) The Internet Society (2006). 💜

This document is covered by the rights, licenses and restrictions in BCP 78. Unless BCP 78 says otherwise, the authors keep all of their rights 🦋

The document and the info in it are given to you "AS IS", and that's the whole vibe. ngl, the contributor, the organization they represent or are sponsored by (if any), the Internet Society, and the Internet Engineering Task Force all disclaim every warranty, express or implied 🙈 That includes no promise that using the info won't infringe anyone's rights, and no implied warranties of merchantability or fitness for a particular purpose 💀

Intellectual Property 🔥

The IETF doesn't take a side on whether any intellectual property rights or other rights claimed around this tech are valid, how far they reach, or whether a license for them is even available. It also doesn't claim it went looking for those rights itself 🫶 If you want the rules on rights in RFC documents, check BCP 78 and BCP 79 📚

Copies of IPR disclosures sent to the IETF Secretariat are a thing, and so are assurances of licenses. You can also find the results of any attempt to get a general license or permission for implementers or users of this spec. All of it lives in the IETF online IPR repository at http://www.ietf.org/ipr ✨

The IETF also invites anyone to tell it about copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. Send that to the IETF at ietf-ipr@ietf.org 📬

Acknowledgement 🌈

Funding for the RFC Editor function comes from the IETF Administrative Support Activity (IASA) 💖