doc/protocol/rfc2712.txt

   1
   2
   3
   4
   5
   6
   7 Network Working Group                                      A. Medvinsky
   8 Request for Comments: 2712                                       Excite
   9 Category: Standards Track                                        M. Hur
  10                                                   CyberSafe Corporation
  11                                                            October 1999
  12
  13
  14   Addition of Kerberos Cipher Suites to Transport Layer Security (TLS)
  15
  16 Status of this Memo
  17
  18    This document specifies an Internet standards track protocol for the
  19    Internet community, and requests discussion and suggestions for
  20    improvements.  Please refer to the current edition of the "Internet
  21    Official Protocol Standards" (STD 1) for the standardization state
  22    and status of this protocol.  Distribution of this memo is unlimited.
  23
  24 Copyright Notice
  25
  26    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  27
  28 IESG Note:
  29
  30    The 40-bit ciphersuites defined in this memo are included only for
  31    the purpose of documenting the fact that those ciphersuite codes have
  32    already been assigned.  40-bit ciphersuites were designed to comply
  33    with US-centric, and now obsolete, export restrictions.  They were
  34    never secure, and nowadays are inadequate even for casual
  35    applications.  Implementation and use of the 40-bit ciphersuites
  36    defined in this document, and elsewhere, is strongly discouraged.
  37
  38 1. Abstract
  39
  40    This document proposes the addition of new cipher suites to the TLS
  41    protocol [1] to support Kerberos-based authentication.  Kerberos
  42    credentials are used to achieve mutual authentication and to
  43    establish a master secret which is subsequently used to secure
  44    client-server communication.
  45
  46 2. Introduction
  47
  48    Flexibility is one of the main strengths of the TLS protocol.
  49    Clients and servers can negotiate cipher suites to meet specific
  50    security and administrative policies.  However, to date,
  51    authentication in TLS is limited only to public key solutions.  As a
  52    result, TLS does not fully support organizations with heterogeneous
  53    security deployments that include authentication systems based on
  54    symmetric cryptography.  Kerberos, originally developed at MIT, is
  55
  56
  57
  58 Medvinsky & Hur             Standards Track                     [Page 1]
  59 \f
  60 RFC 2712       Addition of Kerberos Cipher Suites to TLS   October 1999
  61
  62
  63    based on an open standard [2] and is the most widely deployed
  64    symmetric key authentication system.  This document proposes a new
  65    option for negotiating Kerberos authentication within the TLS
  66    framework.  This achieves mutual authentication and the establishment
  67    of a master secret using Kerberos credentials.  The proposed changes
  68    are minimal and, in fact, no different from adding a new public key
  69    algorithm to the TLS framework.
  70
  71 3. Kerberos Authentication Option In TLS
  72
  73    This section describes the addition of the Kerberos authentication
  74    option to the TLS protocol.  Throughout this document, we refer to
  75    the basic SSL handshake shown in Figure 1.  For a review of the TLS
  76    handshake see [1].
  77
  78   CLIENT                                             SERVER
  79   ------                                             ------
  80  ClientHello
  81                     -------------------------------->
  82                                                      ServerHello
  83                                                      Certificate *
  84                                                      ServerKeyExchange*
  85                                                      CertificateRequest*
  86                                                      ServerHelloDone
  87                     <-------------------------------
  88  Certificate*
  89  ClientKeyExchange
  90  CertificateVerify*
  91  change cipher spec
  92  Finished
  93      |              -------------------------------->
  94      |                                               change cipher spec
  95      |                                               Finished
  96      |                                                   |
  97      |                                                   |
  98  Application Data   <------------------------------->Application Data
  99
 100  FIGURE 1: The TLS protocol.  All messages followed by a star are
 101            optional.  Note: This figure was taken from an IETF document
 102            [1].
 103
 104    The TLS security context is negotiated in the client and server hello
 105    messages.  For example: TLS_RSA_WITH_RC4_MD5 means the initial
 106    authentication will be done using the RSA public key algorithm, RC4
 107    will be used for the session key, and MACs will be based on the MD5
 108    algorithm.  Thus, to facilitate the Kerberos authentication option,
 109    we must start by defining new cipher suites including (but not
 110    limited to):
 111
 112
 113
 114 Medvinsky & Hur             Standards Track                     [Page 2]
 115 \f
 116 RFC 2712       Addition of Kerberos Cipher Suites to TLS   October 1999
 117
 118
 119  CipherSuite      TLS_KRB5_WITH_DES_CBC_SHA            = { 0x00,0x1E };
 120  CipherSuite      TLS_KRB5_WITH_3DES_EDE_CBC_SHA       = { 0x00,0x1F };
 121  CipherSuite      TLS_KRB5_WITH_RC4_128_SHA            = { 0x00,0x20 };
 122  CipherSuite      TLS_KRB5_WITH_IDEA_CBC_SHA           = { 0x00,0x21 };
 123  CipherSuite      TLS_KRB5_WITH_DES_CBC_MD5            = { 0x00,0x22 };
 124  CipherSuite      TLS_KRB5_WITH_3DES_EDE_CBC_MD5       = { 0x00,0x23 };
 125  CipherSuite      TLS_KRB5_WITH_RC4_128_MD5            = { 0x00,0x24 };
 126  CipherSuite      TLS_KRB5_WITH_IDEA_CBC_MD5           = { 0x00,0x25 };
 127
 128  CipherSuite      TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA  = { 0x00,0x26 };
 129  CipherSuite      TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA  = { 0x00,0x27 };
 130  CipherSuite      TLS_KRB5_EXPORT_WITH_RC4_40_SHA      = { 0x00,0x28 };
 131  CipherSuite      TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5  = { 0x00,0x29 };
 132  CipherSuite      TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5  = { 0x00,0x2A };
 133  CipherSuite      TLS_KRB5_EXPORT_WITH_RC4_40_MD5      = { 0x00,0x2B };
 134
 135    To establish a Kerberos-based security context, one or more of the
 136    above cipher suites must be specified in the client hello message.
 137    If the TLS server supports the Kerberos authentication option, the
 138    server hello message, sent to the client, will confirm the Kerberos
 139    cipher suite selected by the server.  The server's certificate, the
 140    client
 141
 142    CertificateRequest, and the ServerKeyExchange shown in Figure 1 will
 143    be omitted since authentication and the establishment of a master
 144    secret will be done using the client's Kerberos credentials for the
 145    TLS server.  The client's certificate will be omitted for the same
 146    reason.  Note that these messages are specified as optional in the
 147    TLS protocol; therefore, omitting them is permissible.
 148
 149    The Kerberos option must be added to the ClientKeyExchange message as
 150    shown in Figure 2.
 151
 152
 153
 154
 155
 156
 157
 158
 159
 160
 161
 162
 163
 164
 165
 166
 167
 168
 169
 170 Medvinsky & Hur             Standards Track                     [Page 3]
 171 \f
 172 RFC 2712       Addition of Kerberos Cipher Suites to TLS   October 1999
 173
 174
 175  struct
 176  {
 177      select (KeyExchangeAlgorithm)
 178      {
 179          case krb5:            KerberosWrapper;       /* new addition */
 180          case rsa:             EncryptedPreMasterSecret;
 181          case diffie_hellman:  ClientDiffieHellmanPublic;
 182      } Exchange_keys;
 183
 184  } ClientKeyExchange;
 185
 186  struct
 187  {
 188      opaque Ticket;
 189      opaque authenticator;            /* optional */
 190      opaque EncryptedPreMasterSecret; /* encrypted with the session key
 191                                          which is sealed in the ticket */
 192  } KerberosWrapper;                   /* new addition */
 193
 194          FIGURE 2: The Kerberos option in the ClientKeyExchange.
 195
 196    To use the Kerberos authentication option, the TLS client must obtain
 197    a service ticket for the TLS server.  In TLS, the ClientKeyExchange
 198    message is used to pass a random 48-byte pre-master secret to the
 199    server.
 200
 201    The client and server then use the pre-master secret to independently
 202    derive the master secret, which in turn is used for generating
 203    session keys and for MAC computations.  Thus, if the Kerberos option
 204    is selected, the pre-master secret structure is the same as that used
 205    in the RSA case; it is encrypted under the Kerberos session key and
 206    sent to the TLS server along with the Kerberos credentials (see
 207    Figure 2).  The ticket and authenticator are encoded per RFC 1510
 208    (ASN.1 encoding).  Once the ClientKeyExchange message is received,
 209    the server's secret key is used to unwrap the credentials and extract
 210    the pre-master secret.
 211
 212    Note that a Kerberos authenticator is not required, since the master
 213    secret derived by the client and server is seeded with a random value
 214    passed in the server hello message, thus foiling replay attacks.
 215    However, the authenticator may still prove useful for passing
 216    authorization information and is thus allotted an optional field (see
 217    Figure 2).
 218
 219    Lastly, the client and server exchange the finished messages to
 220    complete the handshake.  At this point we have achieved the
 221    following:
 222
 223
 224
 225
 226 Medvinsky & Hur             Standards Track                     [Page 4]
 227 \f
 228 RFC 2712       Addition of Kerberos Cipher Suites to TLS   October 1999
 229
 230
 231    1) A master secret, used to protect all subsequent communication, is
 232       securely established.
 233
 234    2) Mutual client-server authentication is achieved, since the TLS
 235       server proves knowledge of the master secret in the finished
 236       message.
 237
 238    Note that the Kerberos option fits in seamlessly, without adding any
 239    new messages.
 240
 241 4. Naming Conventions:
 242
 243    To obtain an appropriate service ticket, the TLS client must
 244    determine the principal name of the TLS server.  The Kerberos service
 245    naming convention is used for this purpose, as follows:
 246
 247      host/MachineName@Realm
 248       where:
 249         - The literal, "host", follows the Kerberos convention when not
 250           concerned about the protection domain on a particular machine.
 251         - "MachineName" is the particular instance of the service.
 252         - The Kerberos "Realm" is the domain name of the machine.
 253
 254 5. Summary
 255
 256    The proposed Kerberos authentication option is added in exactly the
 257    same manner as a new public key algorithm would be added to TLS.
 258    Furthermore, it establishes the master secret in exactly the same
 259    manner.
 260
 261 6. Security Considerations
 262
 263    Kerberos ciphersuites are subject to the same security considerations
 264    as the TLS protocol.  In addition, just as a public key
 265    implementation must take care to protect the private key (for example
 266    the PIN for a smartcard), a Kerberos implementation must take care to
 267    protect the long lived secret that is shared between the principal
 268    and the KDC.  In particular, a weak password may be subject to a
 269    dictionary attack.  In order to strengthen the initial authentication
 270    to a KDC, an implementor may choose to utilize secondary
 271    authentication via a token card, or one may utilize initial
 272    authentication to the KDC based on public key cryptography (commonly
 273    known as PKINIT - a product of the Common Authentication Technology
 274    working group of the IETF).
 275
 276
 277
 278
 279
 280
 281
 282 Medvinsky & Hur             Standards Track                     [Page 5]
 283 \f
 284 RFC 2712       Addition of Kerberos Cipher Suites to TLS   October 1999
 285
 286
 287 7. Acknowledgements
 288
 289    We would like to thank Clifford Neuman for his invaluable comments on
 290    earlier versions of this document.
 291
 292 8. References
 293
 294    [1] Dierks, T. and C. Allen, "The TLS Protocol, Version 1.0", RFC
 295        2246, January 1999.
 296
 297    [2] Kohl J. and C. Neuman, "The Kerberos Network Authentication
 298        Service (V5)", RFC 1510, September 1993.
 299
 300 9. Authors' Addresses
 301
 302    Ari Medvinsky
 303    Excite
 304    555 Broadway
 305    Redwood City, CA 94063
 306
 307    Phone: +1 650 569 2119
 308    EMail: amedvins@excitecorp.com
 309    http://www.excite.com
 310
 311
 312    Matthew Hur
 313    CyberSafe Corporation
 314    1605 NW Sammamish Road
 315    Issaquah WA 98027-5378
 316
 317    Phone: +1 425 391 6000
 318    EMail: matt.hur@cybersafe.com
 319    http://www.cybersafe.com
 320
 321
 322
 323
 324
 325
 326
 327
 328
 329
 330
 331
 332
 333
 334
 335
 336
 337
 338 Medvinsky & Hur             Standards Track                     [Page 6]
 339 \f
 340 RFC 2712       Addition of Kerberos Cipher Suites to TLS   October 1999
 341
 342
 343 10. Full Copyright Statement
 344
 345    Copyright (C) The Internet Society (1999).  All Rights Reserved.
 346
 347    This document and translations of it may be copied and furnished to
 348    others, and derivative works that comment on or otherwise explain it
 349    or assist in its implementation may be prepared, copied, published
 350    and distributed, in whole or in part, without restriction of any
 351    kind, provided that the above copyright notice and this paragraph are
 352    included on all such copies and derivative works.  However, this
 353    document itself may not be modified in any way, such as by removing
 354    the copyright notice or references to the Internet Society or other
 355    Internet organizations, except as needed for the purpose of
 356    developing Internet standards in which case the procedures for
 357    copyrights defined in the Internet Standards process must be
 358    followed, or as required to translate it into languages other than
 359    English.
 360
 361    The limited permissions granted above are perpetual and will not be
 362    revoked by the Internet Society or its successors or assigns.
 363
 364    This document and the information contained herein is provided on an
 365    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
 366    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
 367    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
 368    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
 369    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 370
 371 Acknowledgement
 372
 373    Funding for the RFC Editor function is currently provided by the
 374    Internet Society.
 375
 376
 377
 378
 379
 380
 381
 382
 383
 384
 385
 386
 387
 388
 389
 390
 391
 392
 393
 394 Medvinsky & Hur             Standards Track                     [Page 7]
 395 \f