doc/protocol/rfc4680.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                       S. Santesson
   8 Request for Comments: 4680                                     Microsoft
   9 Updates: 4346                                             September 2006
  10 Category: Standards Track
  11
  12
  13               TLS Handshake Message for Supplemental Data
  14
  15 Status of This Memo
  16
  17    This document specifies an Internet standards track protocol for the
  18    Internet community, and requests discussion and suggestions for
  19    improvements.  Please refer to the current edition of the "Internet
  20    Official Protocol Standards" (STD 1) for the standardization state
  21    and status of this protocol.  Distribution of this memo is unlimited.
  22
  23 Copyright Notice
  24
  25    Copyright (C) The Internet Society (2006).
  26
  27 Abstract
  28
  29    This specification defines a TLS handshake message for exchange of
  30    supplemental application data.  TLS hello message extensions are used
  31    to determine which supplemental data types are supported by both the
  32    TLS client and the TLS server.  Then, the supplemental data handshake
  33    message is used to exchange the data.  Other documents will define
  34    the syntax of these extensions and the syntax of the associated
  35    supplemental data types.
  36
  37
  38
  39
  40
  41
  42
  43
  44
  45
  46
  47
  48
  49
  50
  51
  52
  53
  54
  55
  56
  57
  58 Santesson                   Standards Track                     [Page 1]
  59 \f
  60 RFC 4680      TLS Handshake Message for Supplemental Data September 2006
  61
  62
  63 1.  Introduction
  64
  65    Recent standards activities have proposed different mechanisms for
  66    transmitting supplemental application data in the TLS handshake
  67    message.  For example, recent proposals transfer data that is not
  68    processed by the TLS protocol itself, but assist the TLS-protected
  69    application in the authentication and authorization decisions.  One
  70    proposal transfers user name hints for locating credentials, and
  71    another proposal transfers attribute certificates and Security
  72    Assertions Markup Language (SAML) assertions for authorization
  73    checks.
  74
  75    In order to avoid definition of multiple handshake messages, one for
  76    each new type of application-specific supplemental data, this
  77    specification defines a new handshake message type that bundles
  78    together all data objects that are to be delivered to the TLS-
  79    protected application and sends them in a single handshake message.
  80
  81 1.1.  Terminology
  82
  83    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  84    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  85    document are to be interpreted as described in RFC 2119 [N1].
  86
  87    The syntax for the supplemental_data handshake message is defined
  88    using the TLS Presentation Language, which is specified in Section 4
  89    of [N2].
  90
  91 2.  Supplemental Data Handshake Message
  92
  93    The new supplemental_data handshake message type is defined to
  94    accommodate communication of supplemental data objects as agreed
  95    during the exchange of extensions in the client and server hello
  96    messages.  See RFC 2246 (TLS 1.0) [N2] and RFC 4346 (TLS 1.1) [N3]
  97    for other handshake message types.
  98
  99    Information provided in a supplemental data object MUST be intended
 100    to be used exclusively by applications and protocols above the TLS
 101    protocol layer.  Any such data MUST NOT need to be processed by the
 102    TLS protocol.
 103
 104
 105
 106
 107
 108
 109
 110
 111
 112
 113
 114 Santesson                   Standards Track                     [Page 2]
 115 \f
 116 RFC 4680      TLS Handshake Message for Supplemental Data September 2006
 117
 118
 119       enum {
 120              supplemental_data(23), (255)
 121          } HandshakeType;
 122
 123       struct {
 124              HandshakeType msg_type;    /* handshake type */
 125              uint24 length;             /* octets in message */
 126              select (HandshakeType) {
 127                     case supplemental_data:   SupplementalData;
 128                } body;
 129           } Handshake;
 130
 131       struct {
 132             SupplementalDataEntry supp_data<1..2^24-1>;
 133          } SupplementalData;
 134
 135       struct {
 136             SupplementalDataType supp_data_type;
 137             uint16 supp_data_length;
 138             select(SupplementalDataType) { }
 139          } SupplementalDataEntry;
 140
 141       enum {
 142             (65535)
 143         } SupplementalDataType;
 144
 145    supp_data_length
 146       This field is the length (in bytes) of the data selected by
 147       SupplementalDataType.
 148
 149    The client MUST NOT send more than one SupplementalData handshake
 150    message, and the server MUST NOT send more than one SupplementalData
 151    handshake message.  Receiving more than one SupplementalData
 152    handshake message results in a fatal error, and the receiver MUST
 153    close the connection with a fatal unexpected_message alert.
 154
 155    If present, the SupplementalData handshake message MUST contain a
 156    non-empty SupplementalDataEntry structure carrying data associated
 157    with at least one defined SupplementalDataType.  An explicit
 158    agreement that governs presence of any supplemental data MUST be
 159    concluded between client and server for each SupplementalDataType
 160    using the TLS extensions [N4] in the client and server hello
 161    messages.  Receiving an unexpected SupplementalData handshake message
 162    results in a fatal error, and the receiver MUST close the connection
 163    with a fatal unexpected_message alert.
 164
 165
 166
 167
 168
 169
 170 Santesson                   Standards Track                     [Page 3]
 171 \f
 172 RFC 4680      TLS Handshake Message for Supplemental Data September 2006
 173
 174
 175    Other documents will define specific SupplementalDataTypes and their
 176    associated data syntax and processing.  These same specifications
 177    must also specify the client and server hello message extensions that
 178    are used to negotiate the support for the specified supplemental data
 179    type.  This document simply specifies the TLS Handshake Protocol
 180    message that will carry the supplemental data objects.
 181
 182    Different situations require the transfer of supplemental data from
 183    the client to the server, require the transfer of supplemental data
 184    from the server to the client, or both ways.  All three situations
 185    are fully supported.
 186
 187 3.  Message Flow
 188
 189    The SupplementalData handshake message, if exchanged, MUST be sent as
 190    the first handshake message as illustrated in Figure 1 below.
 191
 192      Client                                               Server
 193
 194      ClientHello (with extensions) -------->
 195
 196                                     ServerHello(with extensions)
 197                                                SupplementalData*
 198                                                     Certificate*
 199                                               ServerKeyExchange*
 200                                              CertificateRequest*
 201                                   <--------      ServerHelloDone
 202
 203      SupplementalData*
 204      Certificate*
 205      ClientKeyExchange
 206      CertificateVerify*
 207      [ChangeCipherSpec]
 208      Finished                     -------->
 209                                               [ChangeCipherSpec]
 210                                   <--------             Finished
 211      Application Data             <------->     Application Data
 212
 213        *  Indicates optional or situation-dependent messages.
 214
 215                Figure 1.  Message Flow with SupplementalData
 216
 217
 218
 219
 220
 221
 222
 223
 224
 225
 226 Santesson                   Standards Track                     [Page 4]
 227 \f
 228 RFC 4680      TLS Handshake Message for Supplemental Data September 2006
 229
 230
 231 4.  Security Considerations
 232
 233    Each SupplementalDataType included in the handshake message defined
 234    in this specification introduces its own unique set of security
 235    properties and related considerations.  Security considerations must
 236    therefore be defined in each document that defines a supplemental
 237    data type.
 238
 239    In some cases, the SupplementalData information may be sensitive.
 240    The double handshake technique can be used to provide protection for
 241    the SupplementalData information.  Figure 2 illustrates the double
 242    handshake, where the initial handshake does not include any
 243    extensions, but it does result in protected communications.  Then, a
 244    second handshake that includes the SupplementalData information is
 245    performed using the protected communications.  In Figure 2, the
 246    number on the right side indicates the amount of protection for the
 247    TLS message on that line.  A zero (0) indicates that there is no
 248    communication protection; a one (1) indicates that protection is
 249    provided by the first TLS session; and a two (2) indicates that
 250    protection is provided by both TLS sessions.
 251
 252    The placement of the SupplementalData message in the TLS Handshake
 253    results in the server providing its SupplementalData information
 254    before the client is authenticated.  In many situations, servers will
 255    not want to provide authorization information until the client is
 256    authenticated.  The double handshake illustrated in Figure 2 provides
 257    a technique to ensure that the parties are mutually authenticated
 258    before either party provides SupplementalData information.
 259
 260
 261
 262
 263
 264
 265
 266
 267
 268
 269
 270
 271
 272
 273
 274
 275
 276
 277
 278
 279
 280
 281
 282 Santesson                   Standards Track                     [Page 5]
 283 \f
 284 RFC 4680      TLS Handshake Message for Supplemental Data September 2006
 285
 286
 287    Client                                                   Server
 288
 289    ClientHello (no extensions) -------->                            |0
 290                                        ServerHello (no extensions)  |0
 291                                                       Certificate*  |0
 292                                                 ServerKeyExchange*  |0
 293                                                CertificateRequest*  |0
 294                                <--------           ServerHelloDone  |0
 295    Certificate*                                                     |0
 296    ClientKeyExchange                                                |0
 297    CertificateVerify*                                               |0
 298    [ChangeCipherSpec]                                               |0
 299    Finished                    -------->                            |1
 300                                                 [ChangeCipherSpec]  |0
 301                                <--------                  Finished  |1
 302    ClientHello (w/ extensions) -------->                            |1
 303                                        ServerHello (w/ extensions)  |1
 304                                                  SupplementalData*  |1
 305                                                       Certificate*  |1
 306                                                 ServerKeyExchange*  |1
 307                                                CertificateRequest*  |1
 308                                <--------           ServerHelloDone  |1
 309    SupplementalData*                                                |1
 310    Certificate*                                                     |1
 311    ClientKeyExchange                                                |1
 312    CertificateVerify*                                               |1
 313    [ChangeCipherSpec]                                               |1
 314    Finished                    -------->                            |2
 315                                                 [ChangeCipherSpec]  |1
 316                                <--------                  Finished  |2
 317    Application Data            <------->          Application Data  |2
 318
 319    *  Indicates optional or situation-dependent messages.
 320
 321          Figure 2.  Double Handshake to Protect Supplemental Data
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338 Santesson                   Standards Track                     [Page 6]
 339 \f
 340 RFC 4680      TLS Handshake Message for Supplemental Data September 2006
 341
 342
 343 5.  IANA Considerations
 344
 345    IANA has taken the following actions:
 346
 347    1) Created an entry, supplemental_data(23), in the existing registry
 348       for HandshakeType (defined in RFC 2246 [N2]).
 349
 350    2) Established a registry for TLS Supplemental Data Formats
 351       (SupplementalDataType).  Values in the inclusive range 0-16385
 352       (decimal) are assigned via RFC 2434 [N5] Standards Action.  Values
 353       from the inclusive range 16386-65279 (decimal) are assigned via
 354       RFC 2434 IETF Consensus.  Values from the inclusive range
 355       65280-65535 (decimal) are reserved for RFC 2434 Private Use.
 356
 357 6.  Normative References
 358
 359    [N1]   Bradner, S., "Key words for use in RFCs to Indicate
 360           Requirement Levels", BCP 14, RFC 2119, March 1997.
 361
 362    [N2]   Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
 363           2246, January 1999.
 364
 365    [N3]   Dierks, T. and E. Rescorla, "The Transport Layer Security
 366           (TLS) Protocol Version 1.1", RFC 4346, April 2006.
 367
 368    [N4]   Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and
 369           T. Wright, "Transport Layer Security (TLS) Extensions", RFC
 370           4366, April 2006.
 371
 372    [N5]   Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
 373           Considerations Section in RFCs", BCP 26, RFC 2434, October
 374           1998.
 375
 376 7.  Acknowledgements
 377
 378    The fundamental architectural idea for the supplemental data
 379    handshake message was provided by Russ Housley and Eric Rescorla.
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394 Santesson                   Standards Track                     [Page 7]
 395 \f
 396 RFC 4680      TLS Handshake Message for Supplemental Data September 2006
 397
 398
 399 Author's Address
 400
 401    Stefan Santesson
 402    Microsoft
 403    Finlandsgatan 30
 404    164 93 KISTA
 405    Sweden
 406
 407    EMail: stefans@microsoft.com
 408
 409
 410
 411
 412
 413
 414
 415
 416
 417
 418
 419
 420
 421
 422
 423
 424
 425
 426
 427
 428
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448
 449
 450 Santesson                   Standards Track                     [Page 8]
 451 \f
 452 RFC 4680      TLS Handshake Message for Supplemental Data September 2006
 453
 454
 455 Full Copyright Statement
 456
 457    Copyright (C) The Internet Society (2006).
 458
 459    This document is subject to the rights, licenses and restrictions
 460    contained in BCP 78, and except as set forth therein, the authors
 461    retain all their rights.
 462
 463    This document and the information contained herein are provided on an
 464    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 465    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 466    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 467    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 468    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 469    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 470
 471 Intellectual Property
 472
 473    The IETF takes no position regarding the validity or scope of any
 474    Intellectual Property Rights or other rights that might be claimed to
 475    pertain to the implementation or use of the technology described in
 476    this document or the extent to which any license under such rights
 477    might or might not be available; nor does it represent that it has
 478    made any independent effort to identify any such rights.  Information
 479    on the procedures with respect to rights in RFC documents can be
 480    found in BCP 78 and BCP 79.
 481
 482    Copies of IPR disclosures made to the IETF Secretariat and any
 483    assurances of licenses to be made available, or the result of an
 484    attempt made to obtain a general license or permission for the use of
 485    such proprietary rights by implementers or users of this
 486    specification can be obtained from the IETF on-line IPR repository at
 487    http://www.ietf.org/ipr.
 488
 489    The IETF invites any interested party to bring to its attention any
 490    copyrights, patents or patent applications, or other proprietary
 491    rights that may cover technology that may be required to implement
 492    this standard.  Please address the information to the IETF at
 493    ietf-ipr@ietf.org.
 494
 495 Acknowledgement
 496
 497    Funding for the RFC Editor function is provided by the IETF
 498    Administrative Support Activity (IASA).
 499
 500
 501
 502
 503
 504
 505
 506 Santesson                   Standards Track                     [Page 9]
 507 \f