doc/protocol/draft-santesson-tls-gssapi-01.txt

   1
   2
   3
   4
   5 INTERNET-DRAFT                                  S. Santesson (Microsoft)
   6 Intended Category: Standards Track              A. Medvinsky (Microsoft)
   7 Expires June 2007                           J. Altman (Secure Endpoints)
   8                                                            December 2006
   9
  10     Generic Security Service Application Program Interface (GSS-API)
  11               Extension for Transport Layer Security (TLS)
  12                   <draft-santesson-tls-gssapi-01.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 as "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 Abstract
  39
  40    This document defines protocol extensions to the Transport Layer
  41    Security (TLS) protocol for user authentication and key negotiation
  42    based on the Generic Security Service Application Program Interface
  43    (GSS-API).
  44
  45    Full flexibility for negotiation of GSS-API mechanisms is provided,
  46    allowing use of arbitrary GSS-API mechanisms provided that they
  47    support the GSS-API PRF.
  48
  49    This document supersedes RFC 2712 [ref] as the mechanism to support
  50    Kerberos based authentication and key establishment for a TLS
  51    session.
  52
  53
  54
  55
  56 Santesson, et. all                                              [Page 1]
  57 \f
  58 INTERNET DRAFT            DNS SRV RR otherName             November 2006
  59
  60
  61 Table of Contents
  62
  63    1  Introduction ................................................    n
  64    2  GSS-API TLS extension .......................................    n
  65    3  GSS-API Handshake message ...................................    n
  66    4  Cipher Suites ...............................................    n
  67    4  Message Flow  ...............................................    n
  68    5  Key Derivation ..............................................    n
  69    6  Security Considerations .....................................    n
  70    7  IANA Considerations .........................................    n
  71    8  References ..................................................    n
  72    Appendix A (if needed)  ........................................    n
  73    Authors' Addresses .............................................    n
  74    Full Copyright Statement .......................................    n
  75    Intellectual Property ..........................................    n
  76
  77 1.  Introduction
  78
  79    This document defines protocol extensions to the Transport Layer
  80    Security (TLS) [N5] protocol for user authentication and key
  81    negotiation based on the Generic Security Service Application Program
  82    Interface (GSS-API).  The extensions to TLS include a new
  83    ExtensionType "gss_api" (section 2), a new HandshakeType "gss_token"
  84    (section 3), a new KeyExchangeAlgorithm "gss_prf" (section 5), and
  85    new "TLS_GSS" cipher suites (section 4).
  86
  87    Full flexibility for negotiation of GSS-API mechanisms is provided,
  88    allowing use of arbitrary GSS-API mechanisms provided that they
  89    support the GSS-API PRF.
  90
  91    This document supersedes RFC 2712 [ref] as the mechanism to support
  92    Kerberos based authentication and key establishment for a TLS
  93    session.
  94
  95 1.1  Terminology
  96
  97    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  98    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  99    document are to be interpreted as described in RFC 2119 [N1].
 100
 101    The syntax for the supplemental_data handshake message is defined
 102    using the TLS Presentation Language, which is specified in Section 4
 103    of [N4].
 104
 105
 106
 107
 108
 109
 110
 111
 112 Santesson, et. all                                              [Page 2]
 113 \f
 114 INTERNET DRAFT            DNS SRV RR otherName             November 2006
 115
 116
 117 2.  GSS-API TLS extension
 118
 119    This section defines a new TLS extension that conveys a list of GSS
 120    mechanism OIDS in ClientHello and ServerHello messages.  The client
 121    uses this extension to transmit a list of supported GSS mechanisms to
 122    the server.  If the server chooses one of the GSS mechanisms, it
 123    returns the selected OID to the client.  The client includes this
 124    extension in the ClientHello only if one or more GSS based
 125    ciphersuites (defined in section X) are included in the list of
 126    supported cipher suites.  Similarly, the server includes this
 127    extension in the ServerHello message only if it selected one of the
 128    GSS cipher suites.
 129
 130
 131        enum {
 132             gss_api(n), (65535)
 133        } ExtensionType;
 134
 135    The "extension_data" field of this extension SHALL contain
 136    "GssOIDList" where:
 137
 138       struct{
 139            GssOID  gss_oid_list<0..2^24-1>  // list of supported OIDs
 140       }GssOIDList;
 141
 142       unit16 GssOID<2..254>;
 143
 144    GssOID contains a sequence of integers of an OBJECT IDENTIFIER (OID)
 145    [ref] where the first integer in the sequence specifies the top node
 146    of the OID.
 147
 148    Each OID specifies a specific GSS token exchange scheme.
 149
 150
 151 3.  GSS-API Handshake Message
 152
 153    This section defines a new handshake message to carry GSS tokens.
 154    The message is used to send GSS tokens from TLS client to TLS server
 155    and vice versa.
 156
 157       enum {
 158            gss_token (nn), (255)
 159       } HandshakeType;
 160
 161       struct {
 162                   HandshakeType msg_type;    /* handshake type */
 163                    uint24 length;            /* octets in message */
 164                    select (HandshakeType) {
 165
 166
 167
 168 Santesson, et. all                                              [Page 3]
 169 \f
 170 INTERNET DRAFT            DNS SRV RR otherName             November 2006
 171
 172
 173                           case gss_token:   GssToken;
 174                      } body;
 175       } Handshake;
 176
 177       Struct {
 178           opaque  GssPayload<1..2^16-1>;
 179           opaque  GssStatus[1]
 180       } GssToken;
 181
 182
 183    The GssStatus contains a status byte for the GssPayload:
 184
 185       GssStatus GSS_NORMAL            = { 0x00 };
 186       GssStatus GSS_LAST_PAYLOAD      = { 0x01 };
 187       GssStatus GSS_ERROR             = { 0x02 };
 188
 189
 190    GSS_NORMAL is set for all GssPayload that does not match the
 191    conditions for any other status bytes.
 192
 193    GSS_LAST_PAYLOAD is set for the last GssPayload in the exchange of
 194    GSS-API payloads and signals that the exchange was successfully
 195    concluded.
 196
 197    GSS_ERROR is set if an error state was reached in the exchange of GSS
 198    tokens. Receiving a GssToken with this status set results in a fatal
 199    error, and the receiver MUST close the connection with a
 200    handshake_failure alert.  Immediately following the transmission of a
 201    GssToken with this status set, the sender MUST close the connection
 202    with a handshake_failure alert.
 203
 204
 205 4. Cipher suites
 206
 207    This document defines the following new cipher suites
 208
 209    CipherSuite TLS_GSS_API_WITH_RC4_128_SHA         = { 0xnn,0x00 };
 210    CipherSuite TLS_GSS_API_WITH_AES_128_CBC_SHA     = { 0xnn,0x01 };
 211    CipherSuite TLS_GSS_API_WITH_AES_256_CBC_SHA     = { 0xnn,0x02 };
 212
 213
 214
 215 5. Key Derivation
 216
 217    After successful completion of the gss_token messages, the client and
 218    server each obtain 46 bytes of key random data using the GSS-API PRF.
 219    This data is the TLS pre-master secret.
 220
 221
 222
 223
 224 Santesson, et. all                                              [Page 4]
 225 \f
 226 INTERNET DRAFT            DNS SRV RR otherName             November 2006
 227
 228
 229    If the GSS-API PRF fails, the connection MUST be closed with a
 230    handshake_failure alert.
 231
 232
 233 6. Message flow
 234
 235    Client                                               Server
 236
 237    ClientHello
 238     /* with GSS-API extension */ ----->
 239
 240                                                    ServerHello
 241                                   /* with GSS-API extension */
 242                                   <--------    ServerHelloDone
 243
 244          <-----  gss_token Handskake messages ----->
 245           /* multiple iterations with GssPayload */
 246
 247    ClientKeyExchange [ChangeCipherSpec] Finished
 248    -------->
 249                                             [ChangeCipherSpec]
 250                                 <--------             Finished
 251    Application Data             <------->     Application Data
 252
 253
 254    If the client is sending the GSSToken message with the
 255    GSS_LAST_PAYLOAD flag set then the third leg of the protocol would
 256    look like this:
 257
 258    GSSToken ClientKeyExchange [ChangeCipherSpec] Finished
 259
 260    However, for a GSS scheme where the server is sending the last GSS
 261    token to the client (and the client has no more GSS tokens to send
 262    then the third leg of the protocol will be just:
 263
 264    ClientKeyExchange [ChangeCipherSpec] Finished
 265
 266
 267 7  IANA Considerations
 268
 269    IANA needs to take the following actions:
 270
 271    1) Create an entry, gss_api (TBD), in the existing registry for
 272    ExtensionType (defined in RFC 4366 [N7]).
 273
 274    2) Create an entry, gss_token (TBD), in the existing registry for
 275    HandshakeType (defined in RFC 2246 [N7]).
 276
 277
 278
 279
 280 Santesson, et. all                                              [Page 5]
 281 \f
 282 INTERNET DRAFT            DNS SRV RR otherName             November 2006
 283
 284
 285    Cipher suite IANA actions TBD
 286
 287 8 References
 288
 289    Normative references:
 290
 291    [N1]      S. Bradner, "Key words for use in RFCs to Indicate
 292              Requirement Levels", BCP 14, RFC 2119, March 1997.
 293
 294    [N2]      Linn, J., "Generic Security Service Application Program
 295              Interface Version 2, Update 1", RFC 2743, January 2000.
 296
 297    [N3]      N. Williams, "A Pseudo-Random Function (PRF) API Extension
 298              for theGeneric Security Service Application Program
 299              Interface (GSS-API)",RFC 4401, February 2006.
 300
 301    [N4]      Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
 302              2246, January 1999.
 303
 304    [N5]      Dierks, T. and E. Rescorla, "The Transport Layer Security
 305              (TLS) Protocol Version 1.1", RFC 4346, April 2006.
 306
 307    [N6]      Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
 308              and T. Wright, "Transport Layer Security (TLS) Extensions",
 309              RFC 4366, April 2006.
 310
 311    [N7]      Narten, T. and H. Alvestrand, "Guidelines for Writing an
 312              IANA Considerations Section in RFCs", BCP 26, RFC 2434,
 313              October 1998.
 314
 315
 316
 317
 318
 319
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336 Santesson, et. all                                              [Page 6]
 337 \f
 338 INTERNET DRAFT            DNS SRV RR otherName             November 2006
 339
 340
 341 Appendix A.
 342
 343    Appednix text
 344
 345
 346
 347
 348
 349
 350
 351
 352
 353
 354
 355
 356
 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, et. all                                              [Page 7]
 393 \f
 394 INTERNET DRAFT            DNS SRV RR otherName             November 2006
 395
 396
 397 Authors' Addresses
 398
 399
 400    Stefan Santesson
 401
 402    Microsoft
 403    Tuborg Boulevard 12
 404    2900 Hellerup
 405    Denmark
 406
 407    EMail: stefans@microsoft.com
 408
 409
 410    Ari Medvinsky
 411
 412    Microsoft
 413    One Microsoft Way
 414    Redmond, WA 98052-6399
 415    USA
 416
 417    Email: arimed(at)microsoft.com
 418
 419
 420    Jeffrey E. Altman
 421
 422    Secure Endpoints Inc.
 423    255 West 94th Street
 424    New York NY 10025
 425    USA
 426
 427    EMail:jaltman@columbia.edu
 428
 429
 430
 431
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446
 447
 448 Santesson, et. all                                              [Page 8]
 449 \f
 450 INTERNET DRAFT            DNS SRV RR otherName             November 2006
 451
 452
 453 Full Copyright Statement
 454
 455    Copyright (C) The Internet Society (2006).
 456
 457    This document is subject to the rights, licenses and restrictions
 458    contained in BCP 78, and except as set forth therein, the authors
 459    retain all their rights.
 460
 461    This document and the information contained herein are provided on an
 462    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 463    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
 464    ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
 465    INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
 466    INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 467    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 468
 469 Intellectual Property
 470
 471    The IETF takes no position regarding the validity or scope of any
 472    Intellectual Property Rights or other rights that might be claimed to
 473    pertain to the implementation or use of the technology described in
 474    this document or the extent to which any license under such rights
 475    might or might not be available; nor does it represent that it has
 476    made any independent effort to identify any such rights. Information
 477    on the procedures with respect to rights in RFC documents can be
 478    found in BCP 78 and BCP 79.
 479
 480    Copies of IPR disclosures made to the IETF Secretariat and any
 481    assurances of licenses to be made available, or the result of an
 482    attempt made to obtain a general license or permission for the use of
 483    such proprietary rights by implementers or users of this
 484    specification can be obtained from the IETF on-line IPR repository at
 485    http://www.ietf.org/ipr.
 486
 487    The IETF invites any interested party to bring to its attention any
 488    copyrights, patents or patent applications, or other proprietary
 489    rights that may cover technology that may be required to implement
 490    this standard.  Please address the information to the IETF at ietf-
 491    ipr@ietf.org."
 492
 493
 494 Expires June 2007
 495
 496
 497
 498
 499
 500
 501
 502
 503
 504 Santesson, et. all                                              [Page 9]