doc/protocol/draft-badra-tls-password-00.txt

   1
   2
   3
   4 Internet Engineering Task Force                                M. Badra
   5 INTERNET DRAFT                                         LIMOS Laboratory
   6 April 19, 2007                                    Expires: October 2007
   7
   8
   9           Password Ciphersuites for Transport Layer Security (TLS)
  10                       <draft-badra-tls-password-00.txt>
  11
  12
  13 Status
  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
  26    months and may be updated, replaced, or obsoleted by other documents
  27    at any 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 October 19, 2007.
  37
  38 Copyright Notice
  39
  40    Copyright (C) The IETF Trust (2007).
  41
  42 Abstract
  43
  44    This document specifies a set of new ciphersuites for the Transport
  45    Layer Security (TLS) protocol to support TLS client authentication
  46    based on passwords. These ciphersuites provide client credential
  47    protection.
  48
  49
  50
  51
  52
  53
  54
  55
  56 Badra                     Expires October 2007                 [Page 1]
  57  \f
  58 Internet-draft        Password Ciphersuites for TLS          April 2007
  59
  60
  61 1 Introduction
  62
  63    TLS defines several ciphersuites providing authentication, data
  64    protection and session key exchange between two communicating
  65    entities. TLS uses public key certificates [TLS], Kerberos [KERB] or
  66    preshared key [PSK] for authentication. This document describes how
  67    to use passwords, shared in advance among the communicating parties,
  68    to authenticate the TLS clients.
  69
  70 1.2 Requirements language and Terminologies
  71
  72    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  73    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  74    document are to be interpreted as described in [KEYWORDS].
  75
  76 2. Password Key Exchange Algorithm
  77
  78    This document specifies a set of ciphersuites for TLS to make use of
  79    existing password databases (e.g. AAA databases) to support client
  80    password-based authentication. These ciphersuites reuse existing key
  81    exchange algorithms as well as existing MAC, stream and bloc ciphers
  82    algorithms from [TLS] and [TLSCTR], [TLSECC], [TLSAES] and [TLSCAM].
  83    Their names include the text "PWD" to refer to the client
  84    authentication using passwords. An example is shown below.
  85
  86     CipherSuite                        Key Exchange   Cipher       Hash
  87
  88     TLS_PWD_RSA_WITH_AES_128_CBC_SHA   RSA            AES_128_CBC  SHA
  89
  90    Currently, a set of password authentication modes are available,
  91    such as One-time password, pin mode, Token. Some of these modes
  92    require multiple exchanges (round-trips) between the client and the
  93    server. This document treats currently password authentication modes
  94    which don't require more than one round-trip.
  95
  96 2.1. Extending the client key exchange message
  97
  98    TLS defines the client key exchange message, which is used to convey
  99    the premaster secret. This secret is usually set; either through a
 100    direct transmission of the RSA-encrypted secret, or by the
 101    transmission of Diffie-Hellman parameters which will allow each side
 102    to agree upon the same premaster secret. The structure of this
 103    message depends on which key exchange method has been selected. The
 104    actual TLS specifications define several methods using usually RSA,
 105    Diffie_Hellman or PSK algorithms.
 106
 107    This document extends the client key exchange message with three new
 108    key exchange methods as following. It is described as following:
 109
 110
 111
 112 Badra                     Expires October 2007                 [Page 2]
 113  \f
 114 Internet-draft        Password Ciphersuites for TLS          April 2007
 115
 116
 117
 118         struct {
 119             select (KeyExchangeAlgorithm) {
 120             /* cases rsa, DH [TLS], ec_diffie_hellman [TLSECC]) */
 121                case pwd_rsa: /* NEW */
 122                  EncryptedPreMasterSecret;
 123                  EncryptedPWD;
 124                case pwd_dh: /* NEW */
 125                  ClientDiffieHellmanPublic;
 126                  EncryptedPWD;
 127                case pwd_ec_diffie_hellman: /* NEW */
 128                  ClientECDiffieHellmanPublic;
 129                  EncryptedPWD;
 130              } exchange_keys;
 131         } ClientKeyExchange;
 132
 133 2.1.1. Cases pwd_rsa, pwd_dh and pwd_ec_diffie_hellman
 134
 135    If pwd_rsa is being used for key agreement, the client generates a
 136    48-byte random value (premaster secret), encrypts it using the
 137    server public key sent in the server key exchange message or in the
 138    server certificate. This is the same as in the RSA key exchange
 139    method. In the case of stream cipher encryption, the client
 140    generates a fresh random value and concatenates it to its username
 141    and password. Therefore, the client symmetrically encrypts the
 142    result using the client_write_key. The cipher algorithm is the same
 143    selected by the server in the ServerHello.cipher_suite. The result
 144    of the above operations called the EncryptedPWD, structured as
 145    follow. In the case of block cipher encryption, the client uses an
 146    explicit IV and adds padding value to force the length of the
 147    plaintext to be an integral multiple of the block cipher's block
 148    length, as it is described in section 6.2.3.2 of [TLS1.1].
 149
 150         struct {
 151            uint16 length;
 152            select (CipherSpec.cipher_type) {
 153              case stream:
 154                    stream-ciphered struct {
 155                       opaque fresh_random<16..2^16-1>;
 156                       opaque login<1..2^16-1>;
 157                       opaque password<1..2^16-1>;
 158                   };
 159              case block:
 160                    block-ciphered struct {
 161                       opaque IV[CipherSpec.block_length];
 162                       opaque login<1..2^16-1>;
 163                       opaque password<1..2^16-1>;
 164                       uint8 padding[EncryptedPWD.padding_length];
 165
 166
 167
 168 Badra                     Expires October 2007                 [Page 3]
 169  \f
 170 Internet-draft        Password Ciphersuites for TLS          April 2007
 171
 172
 173                       uint8 padding_length;
 174                   };
 175             } EncryptedPWD;
 176
 177    fresh_random
 178      A vector contains at least 16 bytes.
 179
 180    length
 181      The length (in bytes) of the EncryptedPWD structure.
 182
 183    padding
 184      Padding that is added to force the length of the EncryptedPWD
 185      structure to be an integral multiple of the block cipher's block
 186      length. The padding MAY be any length up to 255 bytes, as long as
 187      it results in the EncryptedPWD.length being an integral
 188      multiple of the block length. Lengths longer than necessary might
 189      be desirable to frustrate attacks on a protocol that are based on
 190      analysis of the lengths of exchanged messages. Each uint8 in the
 191      padding data vector MUST be filled with the padding length value.
 192      The receiver MUST check this padding and SHOULD use the
 193      bad_record_mac alert to indicate padding errors.
 194
 195    padding_length
 196      The padding length MUST be such that the total size of the
 197      EncryptedPWD structure is a multiple of the cipher's block
 198      length. Legal values range from zero to 255, inclusive. This
 199      length specifies the length of the padding field exclusive of the
 200      padding_length field itself.
 201
 202    Implementations of this document MUST ensure that all policies being
 203    applied on the PSK encoding (section 5 of [PSK]) are applied on the
 204    password encoding as well.
 205
 206    Editor note: is it more secure to don't send the password on the
 207    wire and instead of that, mix it with the premaster secret, and use
 208    the result as an input for the key derivation function to implicitly
 209    authenticate the client?
 210
 211    The client concatenates the EncryptedPreMasterSecret and the
 212    EncryptedPWD values before sending the result to the server through
 213    the client key exchange message.
 214
 215    Upon receipt of this message, the server decrypts the
 216    EncryptedPreMasterSecret using its private key and therefore
 217    computes the master_secret and derives the same client_write_key.
 218    Next, the server symmetrically decrypts the EncryptedPWD to retrieve
 219    the client username and the password in clear text. The server then
 220    checks its database for a match. If a match is found, the server
 221
 222
 223
 224 Badra                     Expires October 2007                 [Page 4]
 225  \f
 226 Internet-draft        Password Ciphersuites for TLS          April 2007
 227
 228
 229    sends its change cipher spec message and proceeds directly to
 230    finished message. If no match is found, the server MUST send a fatal
 231    alert, results in the immediate termination of the connection.
 232
 233    If the server does not recognize the login, it MAY respond with an
 234    "unknown_login" alert message. Alternatively, if the server wishes
 235    to hide the fact that the login was not known, it MAY continue the
 236    protocol as if the login existed but the key was incorrect: that is,
 237    respond with a "decrypt_error" alert.
 238
 239         Client                                               Server
 240         ------                                               ------
 241
 242         ClientHello             -------->
 243                                                         ServerHello
 244                                                        Certificate*
 245                                                  ServerKeyExchange*
 246                                 <--------           ServerHelloDone
 247         ClientKeyExchange
 248         ChangeCipherSpec
 249         Finished                -------->
 250                                                    ChangeCipherSpec
 251                                 <--------                  Finished
 252         Application Data                           Application Data
 253         Attribute Value Pairs                 Attribute Value Pairs
 254         Type Length Value       <=======>         Type Length Value
 255
 256    The pwd_dh case is similar to pwd_rsa, except that the
 257    EncryptedPreMasterSecret is replaced with the parameter
 258    ClientDiffieHellmanPublic.
 259
 260    The pwd_ec_diffie_hellman case is similar to pwd_rsa, except that
 261    the EncryptedPreMasterSecret is replaced with the parameter
 262    ClientECDiffieHellmanPublic.
 263
 264 3. Security Considerations
 265
 266    The security considerations described throughout [TLS], [DTLS], and
 267    [TLS1.1] apply here as well.
 268
 269 4. IANA Considerations
 270
 271    This section provides guidance to the IANA regarding registration of
 272    values related to the client based-password authentication.
 273
 274    Note: For implementation and deployment facilities, it is helpful to
 275    reserve a specific registry sub-range (minor, major) for identity
 276    protection ciphersuites.
 277
 278
 279
 280 Badra                     Expires October 2007                 [Page 5]
 281  \f
 282 Internet-draft        Password Ciphersuites for TLS          April 2007
 283
 284
 285
 286    CipherSuite TLS_PWD_ITH_RC4_128_MD5                  ={ 0xXX,0xXX };
 287    CipherSuite TLS PWD_RSA WITH_RC4_128_SHA             ={ 0xXX,0xXX };
 288    CipherSuite TLS_PWD_RSA_WITH_IDEA_CBC_SHA            ={ 0xXX,0xXX };
 289    CipherSuite TLS_PWD_RSA_WITH_DES_CBC_SHA             ={ 0xXX,0xXX };
 290    CipherSuite TLS_PWD_RSA_WITH_3DES_EDE_CBC_SHA        ={ 0xXX,0xXX };
 291    CipherSuite TLS_PWD_DH_DSS_WITH_DES_CBC_SHA          ={ 0xXX,0xXX };
 292    CipherSuite TLS_PWD_DH_DSS_WITH_3DES_EDE_CBC_SHA     ={ 0xXX,0xXX };
 293    CipherSuite TLS_PWD_DH_RSA_WITH_DES_CBC_SHA          ={ 0xXX,0xXX };
 294    CipherSuite TLS_PWD_DH_RSA_WITH_3DES_EDE_CBC_SHA     ={ 0xXX,0xXX };
 295    CipherSuite TLS_PWD_DHE_DSS_WITH_DES_CBC_SHA         ={ 0xXX,0xXX };
 296    CipherSuite TLS_PWD_DHE_DSS_WITH_3DES_EDE_CBC_SHA    ={ 0xXX,0xXX };
 297    CipherSuite TLS_PWD_DHE_RSA_WITH_DES_CBC_SHA         ={ 0xXX,0xXX };
 298    CipherSuite TLS_PWD_DHE_RSA_WITH_3DES_EDE_CBC_SHA    ={ 0xXX,0xXX };
 299    CipherSuite TLS_PWD_RSA_WITH_CAMELLIA_128_CBC_SHA    ={ 0xXX,0xXX };
 300    CipherSuite TLS_PWD_DH_DSS_WITH_CAMELLIA_128_CBC_SHA ={ 0xXX,0xXX };
 301    CipherSuite TLS_PWD_DH_RSA_WITH_CAMELLIA_128_CBC_SHA ={ 0xXX,0xXX };
 302    CipherSuite TLS_PWD_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA={ 0xXX,0xXX };
 303    CipherSuite TLS_PWD_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA={ 0xXX,0xXX };
 304    CipherSuite TLS_PWD_RSA_WITH_CAMELLIA_256_CBC_SHA    ={ 0xXX,0xXX };
 305    CipherSuite TLS_PWD_DH_DSS_WITH_CAMELLIA_256_CBC_SHA ={ 0xXX,0xXX };
 306    CipherSuite TLS_PWD_DH_RSA_WITH_CAMELLIA_256_CBC_SHA ={ 0xXX,0xXX };
 307    CipherSuite TLS_PWD_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA={ 0xXX,0xXX };
 308    CipherSuite TLS_PWD_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA={ 0xXX,0xXX };
 309    CipherSuite TLS_PWD_RSA_WITH_AES_128_CBC_SHA         ={ 0xXX,0xXX };
 310    CipherSuite TLS_PWD_DH_DSS_WITH_AES_128_CBC_SHA      ={ 0xXX,0xXX };
 311    CipherSuite TLS PWD_DH_RSA_WITH_AES_128_CBC_SHA      ={ 0xXX,0xXX };
 312    CipherSuite TLS_PWD_DHE_DSS_WITH_AES_128_CBC_SHA     ={ 0xXX,0xXX };
 313    CipherSuite TLS_PWD_DHE_RSA_WITH_AES_128_CBC_SHA     ={ 0xXX,0xXX };
 314    CipherSuite TLS_PWD_RSA_WITH_AES_256_CBC_SHA         ={ 0xXX,0xXX };
 315    CipherSuite TLS_PWD_DH_DSS_WITH_AES_256_CBC_SHA      ={ 0xXX,0xXX };
 316    CipherSuite TLS_PWD_DH_RSA_WITH_AES_256_CBC_SHA      ={ 0xXX,0xXX };
 317    CipherSuite TLS_PWD_DHE_DSS_WITH_AES_256_CBC_SHA     ={ 0xXX,0xXX };
 318    CipherSuite TLS_PWD_DHE_RSA_WITH_AES_256_CBC_SHA     ={ 0xXX,0xXX };
 319    CipherSuite TLS_PWD_ECDH_ECDSA_WITH_RC4_128_SHA      ={ 0xXX,0xXX };
 320    CipherSuite TLS_PWD_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA ={ 0xXX,0xXX };
 321    CipherSuite TLS_PWD_ECDH_ECDSA_WITH_AES_128_CBC_SHA  ={ 0xXX,0xXX };
 322    CipherSuite TLS_PWD_ECDH_ECDSA_WITH_AES_256_CBC_SHA  ={ 0xXX,0xXX };
 323    CipherSuite TLS_PWD_ECDHE_ECDSA_WITH_RC4_128_SHA     ={ 0xXX,0xXX };
 324    CipherSuite TLS_PWD_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA={ 0xXX,0xXX };
 325    CipherSuite TLS_PWD_ECDHE_ECDSA_WITH_AES_128_CBC_SHA ={ 0xXX,0xXX };
 326    CipherSuite TLS_PWD_ECDHE_ECDSA_WITH_AES_256_CBC_SHA ={ 0xXX,0xXX };
 327    CipherSuite TLS_PWD_ECDH_RSA_WITH_RC4_128_SHA        ={ 0xXX,0xXX };
 328    CipherSuite TLS_PWD_ECDH_RSA_WITH_3DES_EDE_CBC_SHA   ={ 0xXX,0xXX };
 329    CipherSuite TLS_PWD_ECDH_RSA_WITH_AES_128_CBC_SHA    ={ 0xXX,0xXX };
 330    CipherSuite TLS_PWD_ECDH_RSA_WITH_AES_256_CBC_SHA    ={ 0xXX,0xXX };
 331    CipherSuite TLS_PWD_ECDHE_RSA_WITH_RC4_128_SHA       ={ 0xXX,0xXX };
 332    CipherSuite TLS_PWD_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA  ={ 0xXX,0xXX };
 333
 334
 335
 336 Badra                     Expires October 2007                 [Page 6]
 337  \f
 338 Internet-draft        Password Ciphersuites for TLS          April 2007
 339
 340
 341    CipherSuite TLS_PWD_ECDHE_RSA_WITH_AES_128_CBC_SHA   ={ 0xXX,0xXX };
 342    CipherSuite TLS_PWD_ECDHE_RSA_WITH_AES_256_CBC_SHA   ={ 0xXX,0xXX };
 343
 344    This document also defines a new TLS alert message,
 345    unknown_login(TBD).
 346
 347 5. References
 348
 349 5.1. Normative References
 350
 351    [TLS]      Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
 352               RFC 2246, January 1999.
 353
 354    [TLS1.1]   Dierks, T. and E. Rescorla, "The TLS Protocol Version
 355               1.1", RFC 4346, April 2006.
 356
 357    [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
 358               Requirement Levels", RFC 2119, March 1997.
 359
 360    [PSK]      Eronen, P. (Ed.) and H. Tschofenig (Ed.), "Pre-Shared Key
 361               Ciphersuites for Transport Layer Security (TLS)",
 362               RFC 4279, December 2005.
 363
 364    [TLSCAM]   Moriai, S., Kato, A., Kanda M., "Addition of Camellia
 365               Cipher Suites to Transport Layer Security (TLS)",
 366               RFC 4132, July 2005.
 367
 368    [TLSAES]   Chown, P., "Advanced Encryption Standard (AES)
 369               Ciphersuites for Transport Layer Security (TLS)",
 370               RFC 3268, June 2002.
 371
 372    [TLSECC]   Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C.,
 373               Moeller, B., "Elliptic Curve Cryptography (ECC) Cipher
 374               Suites for Transport Layer Security (TLS)", RFC 4492, May
 375               2006
 376
 377    [TLSCTR]   Modadugu, N. and E. Rescorla, "AES Counter Mode Cipher
 378               Suites for TLS and DTLS", draft-ietf-tls-ctr-01.txt (work
 379               in progress), June 2006.
 380
 381 5.2. Informative References
 382
 383    [KERB]     Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
 384               Suites to Transport Layer Security (TLS)", RFC 2712,
 385               October 1999.
 386
 387
 388
 389
 390
 391
 392 Badra                     Expires October 2007                 [Page 7]
 393  \f
 394 Internet-draft        Password Ciphersuites for TLS          April 2007
 395
 396
 397 Author's Addresses
 398
 399    Mohamad Badra
 400    LIMOS Laboratory - UMR (6158), CNRS
 401    France             Email: badra@isima.fr
 402
 403 Full Copyright Statement
 404
 405    Copyright (C) The IETF Trust (2007).
 406
 407    This document is subject to the rights, licenses and restrictions
 408    contained in BCP 78, and except as set forth therein, the authors
 409    retain all their rights.
 410
 411    This document and the information contained herein are provided on
 412    an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
 413    REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
 414    IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
 415    WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
 416    WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
 417    ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
 418    FOR A PARTICULAR PURPOSE.
 419
 420 Intellectual Property
 421
 422    The IETF takes no position regarding the validity or scope of any
 423    Intellectual Property Rights or other rights that might be claimed
 424    to pertain to the implementation or use of the technology described
 425    in this document or the extent to which any license under such
 426    rights might or might not be available; nor does it represent that
 427    it has made any independent effort to identify any such rights.
 428    Information on the procedures with respect to rights in RFC
 429    documents can be found in BCP 78 and BCP 79.
 430
 431    Copies of IPR disclosures made to the IETF Secretariat and any
 432    assurances of licenses to be made available, or the result of an
 433    attempt made to obtain a general license or permission for the use
 434    of such proprietary rights by implementers or users of this
 435    specification can be obtained from the IETF on-line IPR repository
 436    at http://www.ietf.org/ipr.
 437
 438    The IETF invites any interested party to bring to its attention any
 439    copyrights, patents or patent applications, or other proprietary
 440    rights that may cover technology that may be required to implement
 441    this standard.  Please address the information to the IETF at ietf-
 442    ipr@ietf.org.
 443
 444 Acknowledgment
 445
 446
 447
 448 Badra                     Expires October 2007                 [Page 8]
 449  \f
 450 Internet-draft        Password Ciphersuites for TLS          April 2007
 451
 452
 453
 454    Funding for the RFC Editor function is provided by the IETF
 455    Administrative Support Activity (IASA).
 456
 457
 458
 459
 460
 461
 462
 463
 464
 465
 466
 467
 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 Badra                     Expires October 2007                 [Page 9]
 505  \f