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

   1
   2
   3 NETWORK WORKING GROUP                                             L. Zhu
   4 Internet-Draft                                     Microsoft Corporation
   5 Updates: 4279 (if approved)                                 July 9, 2007
   6 Intended status: Standards Track
   7 Expires: January 10, 2008
   8
   9
  10      Flexible Key Agreement for Transport Layer Security (FKA-TLS)
  11                      draft-santesson-tls-gssapi-02
  12
  13 Status of this Memo
  14
  15    By submitting this Internet-Draft, each author represents that any
  16    applicable patent or other IPR claims of which he or she is aware
  17    have been or will be disclosed, and any of which he or she becomes
  18    aware will be disclosed, in accordance with Section 6 of BCP 79.
  19
  20    Internet-Drafts are working documents of the Internet Engineering
  21    Task Force (IETF), its areas, and its working groups.  Note that
  22    other groups may also distribute working documents as Internet-
  23    Drafts.
  24
  25    Internet-Drafts are draft documents valid for a maximum of six months
  26    and may be updated, replaced, or obsoleted by other documents at any
  27    time.  It is inappropriate to use Internet-Drafts as reference
  28    material or to cite them other than as "work in progress."
  29
  30    The list of current Internet-Drafts can be accessed at
  31    http://www.ietf.org/ietf/1id-abstracts.txt.
  32
  33    The list of Internet-Draft Shadow Directories can be accessed at
  34    http://www.ietf.org/shadow.html.
  35
  36    This Internet-Draft will expire on January 10, 2008.
  37
  38 Copyright Notice
  39
  40    Copyright (C) The IETF Trust (2007).
  41
  42 Abstract
  43
  44    This document defines extensions to RFC 4279 to enable dynamic key
  45    sharing in distributed environments.  By using these extensions, the
  46    client and the server can use off-shelf libraries to exchange tokens
  47    and establish a shared secret, based on a Generic Security Service
  48    Application Program Interface (GSS-API) mechanism such as Kerberos as
  49    defined in RFC 4121, and then proceed according to RFC 4279 to
  50    complete the authentication and provide data protection.
  51
  52
  53
  54 Zhu                     Expires January 10, 2008                [Page 1]
  55 \f
  56 Internet-Draft                   FKA-TLS                       July 2007
  57
  58
  59 Table of Contents
  60
  61    1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
  62    2.  Conventions Used in This Document . . . . . . . . . . . . . . . 3
  63    3.  Protocol Definition . . . . . . . . . . . . . . . . . . . . . . 3
  64    4.  Choosing GSS-API Mechanisms . . . . . . . . . . . . . . . . . . 6
  65    5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
  66    6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 7
  67    7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
  68    8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 7
  69      8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 7
  70      8.2.  Informative References  . . . . . . . . . . . . . . . . . . 8
  71    Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 8
  72    Intellectual Property and Copyright Statements  . . . . . . . . . . 9
  73
  74
  75
  76
  77
  78
  79
  80
  81
  82
  83
  84
  85
  86
  87
  88
  89
  90
  91
  92
  93
  94
  95
  96
  97
  98
  99
 100
 101
 102
 103
 104
 105
 106
 107
 108
 109
 110 Zhu                     Expires January 10, 2008                [Page 2]
 111 \f
 112 Internet-Draft                   FKA-TLS                       July 2007
 113
 114
 115 1.  Introduction
 116
 117    [RFC4279] defines Transport Layer Security (TLS) based on pre-shared
 118    keys (PSK).  This assumes a pair-wise key sharing scheme that is less
 119    scalable and more costly to manage in comparison with a trusted third
 120    party scheme such as Kerberos [RFC4120].  In addition, off-shelf GSS-
 121    API libraries that allow dynamic key sharing are not currently
 122    accessible to TLS applications.  For example, Kerberos [RFC4121] is a
 123    GSS-API mechanism that can establish a shared key between a client
 124    and a server based on either asymmetric keys [RFC4556] or symmetric
 125    keys [RFC4120].
 126
 127    This document extends [RFC4279] to allow the client and the server
 128    establish a shared key on demand by using off-shelf GSS-API
 129    libraries, and then proceed according to RFC 4279.  This is a modular
 130    approach to leverage Kerberos alike trust infrastructures in securing
 131    TLS connections.
 132
 133
 134 2.  Conventions Used in This Document
 135
 136    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 137    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 138    document are to be interpreted as described in [RFC2119].
 139
 140
 141 3.  Protocol Definition
 142
 143    The GSS-API TLS extension is defined according to [RFC3546].  The
 144    extension data carries GSS-API token within the TLS hello messages.
 145
 146      enum {
 147          GSS-API(TBD), (65535)
 148      } ExtensionType;
 149
 150    Initially the client calls GSS_Init_sec_context() [RFC2743] to
 151    establish a security context, it MUST set the mutual_req_flag and
 152    identify the server by targ_name so that mutual authentication is
 153    performed in the course of context establishment.  If the mutual
 154    authentication is not available when the context is established
 155    successfully, the GSS-API security context MUST be discarded.  The
 156    extension_data from the client contains the output token of
 157    GSS_Init_sec_context().  If a GSS-API context cannot be established,
 158    the GSS-API TLS extension MUST NOT be included in the client hello
 159    message and it is a matter of local policy on the client whether to
 160    continue or reject the TLS authentication as if the GSS-API TLS
 161    extension is not supported.
 162
 163
 164
 165
 166 Zhu                     Expires January 10, 2008                [Page 3]
 167 \f
 168 Internet-Draft                   FKA-TLS                       July 2007
 169
 170
 171    Upon receipt of the GSS-API TLS extension from the client, and if the
 172    server supports the GSS-API TLS extension, the server calls
 173    GSS_Accept_sec_context() with the client GSS-API output token in the
 174    client's extension data as the input token.  If
 175    GSS_Accept_sec_context() returns a token successfully, the server
 176    responds with a GSS-API TLS extension and places the output token in
 177    the extension_data.  If GSS_Accept_sec_context() fails, it is a
 178    matter of local policy on the server whether to continue or reject
 179    the TLS authentication as if the GSS-API TLS extension is not
 180    supported.
 181
 182    The server MUST NOT include a GSS-API TLS extension in the hello
 183    message if the cipher_suite in the ServerHello message is not a PSK
 184    ciphersuite [RFC4279].
 185
 186    If the server expects at least one more token to be accepted from the
 187    client in order to establish the security context, the additional
 188    GSS-API tokens are carried in a new handshake message called the
 189    token-transfer message.
 190
 191           enum {
 192              token_transfer(TBD), (255)
 193          } HandshakeType;
 194
 195          struct {
 196              HandshakeType msg_type;    /* handshake type */
 197              uint24 length;             /* bytes in message */
 198              select (HandshakeType) {
 199                  case token_transfer: /* NEW */
 200                        TokenTranfer;
 201              } body;
 202          } Handshake;
 203
 204           enum {
 205              gss-api-token(1), (255)
 206          } TokenTransferType;
 207
 208          struct {
 209                TokenTransferType token_type; /* token type */
 210                opaque token<0..2^16-1>;
 211          } TokenTranfer;
 212
 213    The TokenTranfer structure is filled out as follows:
 214
 215    o  The token_type is gss-api-token.
 216
 217
 218
 219
 220
 221
 222 Zhu                     Expires January 10, 2008                [Page 4]
 223 \f
 224 Internet-Draft                   FKA-TLS                       July 2007
 225
 226
 227    o  The token field contains the GSS-API context establishment tokens
 228       from the client and the server.
 229
 230    The client calls GSS_Init_sec_context() with the token in the
 231    TokenTranfer stucture from the server as the input token, and then
 232    places the output token, if any, into the TokenTranfer message and
 233    sends the handshake message to the server.  The server calls
 234    GSS_Accept_sec_context() with the token in the TokenTranfer structure
 235    from the client as the input token, and then places the output token,
 236    if any, into the TokenTranfer message and sends the handshake message
 237    to the client.  This loop repeats until either the context fails to
 238    establish or the context is established successfully.  To prevent an
 239    infinite loop, both the client and the server MUST have a policy to
 240    limit the maximum number of GSS-API context establishment calls for a
 241    given session.  The recommended value is 5.  If the GSS-API context
 242    fails to establish, it is a matter of local policy whether to
 243    continue or reject the TLS authentication as if the GSS-API TLS
 244    extension is not supported.
 245
 246    When the last GSS-API context establishment token is sent by the
 247    client or when the GSS-API context fails to establish on the client
 248    side and the local policy allows the TLS authentication to proceed as
 249    if the TLS GSS-API extension is not supported, the client sends an
 250    empty TokenTransfer handshake message.
 251
 252    If the GSS-API context fails to establish and local policy allows the
 253    TLS authentication continue as if the GSS-API TLS extension is not
 254    supported, the server MAY send another ServerHello message in order
 255    to choose a different cipher suite.  The client then MUST expect the
 256    second ServerHello message from the server before the session is
 257    established.  The second ServerHello message MUST differ from the
 258    first ServerHello message in the cipher_suite field and only in that
 259    field.
 260
 261    If the client and the server establish a security context
 262    successfully, both the client and the server call GSS_Pseudo_random()
 263    [RFC4401] to compute a sufficiently long shared secret with the same
 264    value based on the negotiated ciphersuite, and then proceed according
 265    to [RFC4279] using this shared secret value as the "PSK".  Both
 266    psk_identity and psk_identity_hint are empty in the handshake
 267    messages when the shared key is established using a GSS-API mechanism
 268    as described in this document.
 269
 270    The following text art summaries the protocol message flow.
 271
 272
 273
 274
 275
 276
 277
 278 Zhu                     Expires January 10, 2008                [Page 5]
 279 \f
 280 Internet-Draft                   FKA-TLS                       July 2007
 281
 282
 283        Client                                               Server
 284
 285        ClientHello                  -------->
 286                                                        ServerHello
 287                                    <--------        TokenTransfer*
 288                                       .
 289                                       .
 290                                       .
 291        TokenTransfer*               -------->
 292
 293                                                       ServerHello*
 294                                                       Certificate*
 295                                                 ServerKeyExchange*
 296                                                CertificateRequest*
 297                                    <--------       ServerHelloDone
 298        Certificate*
 299        ClientKeyExchange
 300        CertificateVerify*
 301        [ChangeCipherSpec]
 302        Finished                     -------->
 303                                                 [ChangeCipherSpec]
 304                                    <--------              Finished
 305        Application Data            <-------->     Application Data
 306
 307           Fig. 1. Message flow for a full handshake
 308
 309        * Indicates optional or situation-dependent messages that are
 310          not always sent.
 311
 312    There could be multiple TokenTransfer handshake messages, and the
 313    last TokenTranster message, if present, is always sent from the
 314    client to the server and it can carry an empty token.
 315
 316
 317 4.  Choosing GSS-API Mechanisms
 318
 319    If more than one GSS-API mechanism is shared between the client and
 320    the server, it is RECOMMENDED to deploy a pseudo GSS-API mechanism
 321    such as [RFC4178] to choose a mutually preferred GSS-API mechanism.
 322
 323    If the Kerberos client does not have access to the KDC but the server
 324    does, [IAKERB] can be chosen to tunnel the Kerberos authentication
 325    exchange within the TLS handshake messages.
 326
 327
 328 5.  Security Considerations
 329
 330    When Kerberos as defined in [RFC4120] is used to establish the share
 331
 332
 333
 334 Zhu                     Expires January 10, 2008                [Page 6]
 335 \f
 336 Internet-Draft                   FKA-TLS                       July 2007
 337
 338
 339    key, it is vulnerable to offline dictionary attacks.  The threat is
 340    mitigated by deploying kerberos FAST [KRB-FAST].
 341
 342
 343 6.  Acknowledgements
 344
 345    Stefan Santesson, Ari Medvinsky and Jeffery Altman helped editing the
 346    earlier revisions of this document.
 347
 348
 349 7.  IANA Considerations
 350
 351    A new handshake message token_transfer is defined according to
 352    [RFC4346] and a new TLS extension called the GSS-API extension is
 353    defined according to [RFC3546].  The registry need to be updated to
 354    include these new types.
 355
 356    This document defines the type of the transfer tokens in Section 3, a
 357    registry need to be setup and the allocation policy is "Specification
 358    Required".
 359
 360
 361 8.  References
 362
 363 8.1.  Normative References
 364
 365    [IAKERB]   Zhu, L., "Initial and Pass Through Authentication Using
 366               Kerberos V5 and the GSS-API", draft-zhu-ws-kerb-03.txt
 367               (work in progress), 2007.
 368
 369    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
 370               Requirement Levels", BCP 14, RFC 2119, March 1997.
 371
 372    [RFC2743]  Linn, J., "Generic Security Service Application Program
 373               Interface Version 2, Update 1", RFC 2743, January 2000.
 374
 375    [RFC3546]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
 376               and T. Wright, "Transport Layer Security (TLS)
 377               Extensions", RFC 3546, June 2003.
 378
 379    [RFC4178]  Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The
 380               Simple and Protected Generic Security Service Application
 381               Program Interface (GSS-API) Negotiation Mechanism",
 382               RFC 4178, October 2005.
 383
 384    [RFC4279]  Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites
 385               for Transport Layer Security (TLS)", RFC 4279,
 386               December 2005.
 387
 388
 389
 390 Zhu                     Expires January 10, 2008                [Page 7]
 391 \f
 392 Internet-Draft                   FKA-TLS                       July 2007
 393
 394
 395    [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
 396               (TLS) Protocol Version 1.1", RFC 4346, April 2006.
 397
 398    [RFC4401]  Williams, N., "A Pseudo-Random Function (PRF) API
 399               Extension for the Generic Security Service Application
 400               Program Interface (GSS-API)", RFC 4401, February 2006.
 401
 402 8.2.  Informative References
 403
 404    [KRB-FAST]
 405               Zhu, L. and S. Hartman, "A Generalized Framework for
 406               Kerberos Pre-Authentication",
 407               draft-ietf-krb-wg-preauth-framework-06.txt (work in
 408               progress), 2007.
 409
 410    [RFC4120]  Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The
 411               Kerberos Network Authentication Service (V5)", RFC 4120,
 412               July 2005.
 413
 414    [RFC4121]  Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos
 415               Version 5 Generic Security Service Application Program
 416               Interface (GSS-API) Mechanism: Version 2", RFC 4121,
 417               July 2005.
 418
 419    [RFC4556]  Zhu, L. and B. Tung, "Public Key Cryptography for Initial
 420               Authentication in Kerberos (PKINIT)", RFC 4556, June 2006.
 421
 422
 423 Author's Address
 424
 425    Larry Zhu
 426    Microsoft Corporation
 427    One Microsoft Way
 428    Redmond, WA  98052
 429    US
 430
 431    Email: lzhu@microsoft.com
 432
 433
 434
 435
 436
 437
 438
 439
 440
 441
 442
 443
 444
 445
 446 Zhu                     Expires January 10, 2008                [Page 8]
 447 \f
 448 Internet-Draft                   FKA-TLS                       July 2007
 449
 450
 451 Full Copyright Statement
 452
 453    Copyright (C) The IETF Trust (2007).
 454
 455    This document is subject to the rights, licenses and restrictions
 456    contained in BCP 78, and except as set forth therein, the authors
 457    retain all their rights.
 458
 459    This document and the information contained herein are provided on an
 460    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 461    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 462    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 463    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 464    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 465    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 466
 467
 468 Intellectual Property
 469
 470    The IETF takes no position regarding the validity or scope of any
 471    Intellectual Property Rights or other rights that might be claimed to
 472    pertain to the implementation or use of the technology described in
 473    this document or the extent to which any license under such rights
 474    might or might not be available; nor does it represent that it has
 475    made any independent effort to identify any such rights.  Information
 476    on the procedures with respect to rights in RFC documents can be
 477    found in BCP 78 and BCP 79.
 478
 479    Copies of IPR disclosures made to the IETF Secretariat and any
 480    assurances of licenses to be made available, or the result of an
 481    attempt made to obtain a general license or permission for the use of
 482    such proprietary rights by implementers or users of this
 483    specification can be obtained from the IETF on-line IPR repository at
 484    http://www.ietf.org/ipr.
 485
 486    The IETF invites any interested party to bring to its attention any
 487    copyrights, patents or patent applications, or other proprietary
 488    rights that may cover technology that may be required to implement
 489    this standard.  Please address the information to the IETF at
 490    ietf-ipr@ietf.org.
 491
 492
 493 Acknowledgment
 494
 495    Funding for the RFC Editor function is provided by the IETF
 496    Administrative Support Activity (IASA).
 497
 498
 499
 500
 501
 502 Zhu                     Expires January 10, 2008                [Page 9]
 503 \f
 504