TLS Handshake Message for Supplemental Data
RFC 4680

Document Type RFC - Proposed Standard (October 2006; No errata)
Updated by RFC 8996, RFC 8447
Updates RFC 4346
Was draft-santesson-tls-supp (individual in sec area)
Author Stefan Santesson 
Last updated 2015-10-14
Stream Internet Engineering Task Force (IETF)
Formats plain text html pdf htmlized (tools) htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 4680 (Proposed Standard)
Action Holders
Consensus Boilerplate Unknown
Telechat date
Responsible AD Russ Housley
Send notices to (None)
Network Working Group                                       S. Santesson
Request for Comments: 4680                                     Microsoft
Updates: 4346                                             September 2006
Category: Standards Track

              TLS Handshake Message for Supplemental Data

Status of This Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2006).


   This specification defines a TLS handshake message for exchange of
   supplemental application data.  TLS hello message extensions are used
   to determine which supplemental data types are supported by both the
   TLS client and the TLS server.  Then, the supplemental data handshake
   message is used to exchange the data.  Other documents will define
   the syntax of these extensions and the syntax of the associated
   supplemental data types.

Santesson                   Standards Track                     [Page 1]
RFC 4680      TLS Handshake Message for Supplemental Data September 2006

1.  Introduction

   Recent standards activities have proposed different mechanisms for
   transmitting supplemental application data in the TLS handshake
   message.  For example, recent proposals transfer data that is not
   processed by the TLS protocol itself, but assist the TLS-protected
   application in the authentication and authorization decisions.  One
   proposal transfers user name hints for locating credentials, and
   another proposal transfers attribute certificates and Security
   Assertions Markup Language (SAML) assertions for authorization

   In order to avoid definition of multiple handshake messages, one for
   each new type of application-specific supplemental data, this
   specification defines a new handshake message type that bundles
   together all data objects that are to be delivered to the TLS-
   protected application and sends them in a single handshake message.

1.1.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   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 defined to
   accommodate communication of supplemental data objects as agreed
   during the exchange of extensions in the client and server hello
   messages.  See RFC 2246 (TLS 1.0) [N2] and RFC 4346 (TLS 1.1) [N3]
   for other handshake message types.

   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.

Santesson                   Standards Track                     [Page 2]
RFC 4680      TLS Handshake Message for Supplemental Data September 2006

      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 {
        } SupplementalDataType;

      This field is the length (in bytes) of the data selected by

   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
Show full document text