doc/protocol/draft-santesson-tls-supp-02.txt

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