doc/protocol/draft-badra-tls-password-ext-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 Extension for TLS Client Authentication
  10                     <draft-badra-tls-password-ext-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 new TLS extension and a new TLS message
  45    providing TLS client authentication using passwords. It provides
  46    client credential protection.
  47
  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    This document defines a new extension and a new TLS message to the
  64    TLS protocol to enable TLS client authentication using passwords. It
  65    provides client credential protection.
  66
  67 1.2 Requirements language and Terminologies
  68
  69    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  70    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  71    document are to be interpreted as described in [KEYWORDS].
  72
  73 2. Password Extension
  74
  75    In order to negotiate the use of client password-based
  76    authentication, clients MAY include an extension of type "password"
  77    in the extended client hello. The "extension_data" field of this
  78    extension SHALL be empty. The extension_type field is to be assigned
  79    by IANA.
  80
  81    For servers aware of the password extension but not wishing to use
  82    it, it will gracefully revert to an ordinary TLS handshake or stop
  83    the negotiation.
  84
  85    Servers that receive an extended hello containing a "password"
  86    extension MAY agree to authenticate the client using passwords by
  87    including an extension of type "password", with empty
  88    "extension_data", in the extended server hello. The
  89    CertificateRequest payload is omitted from the server response.
  90
  91    Clients return a response along with their credentials by sending a
  92    "EncryptedPassword" message immediately after the
  93    "ClientKeyExchange" message. The encrypted password message is sent
  94    symmetrically encrypted with the key client_write_key and the cipher
  95    algorithm selected by the server in the ServerHello.cipher_suite.
  96    The Certificate and CertificateVerify payloads are omitted from the
  97    client response.
  98
  99 2.1. Encrypted Password
 100
 101    When this message will be sent:
 102
 103    The client MUST send this message immediately after the client key
 104    exchange message.
 105
 106
 107
 108
 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    Structure of this message:
 119
 120         struct {
 121            uint16 length;
 122            select (CipherSpec.cipher_type) {
 123              case stream:
 124                    stream-ciphered struct {
 125                       opaque fresh_random<16..2^16-1>;
 126                       opaque login<1..2^16-1>;
 127                       opaque password<1..2^16-1>;
 128                   };
 129              case block:
 130                    block-ciphered struct {
 131                       opaque IV[CipherSpec.block_length];
 132                       opaque login<1..2^16-1>;
 133                       opaque password<1..2^16-1>;
 134                       uint8 padding[EncryptedPassword.padding_length];
 135                       uint8 padding_length;
 136                   };
 137             } EncryptedPassword;
 138
 139    fresh_random
 140      A vector contains at least 16 bytes.
 141
 142    length
 143      The length (in bytes) of the EncryptedPassword structure.
 144
 145    padding
 146      Padding that is added to force the length of the EncryptedPassword
 147      structure to be an integral multiple of the block cipher's block
 148      length. The padding MAY be any length up to 255 bytes, as long as
 149      it results in the EncryptedPassword.length being an integral
 150      multiple of the block length. Lengths longer than necessary might
 151      be desirable to frustrate attacks on a protocol that are based on
 152      analysis of the lengths of exchanged messages. Each uint8 in the
 153      padding data vector MUST be filled with the padding length value.
 154      The receiver MUST check this padding and SHOULD use the
 155      bad_record_mac alert to indicate padding errors.
 156
 157    padding_length
 158      The padding length MUST be such that the total size of the
 159      EncryptedPassword structure is a multiple of the cipher's block
 160      length. Legal values range from zero to 255, inclusive. This
 161      length specifies the length of the padding field exclusive of the
 162      padding_length field itself.
 163
 164
 165
 166
 167
 168 Badra                     Expires October 2007                 [Page 3]
 169  \f
 170 Internet-draft        Password Ciphersuites for TLS          April 2007
 171
 172
 173    BulkCipherAlgorithm.null (e.g. TLS_RSA_WITH_NULL_MD5 and
 174    RSA_WITH_NULL_SHA) MUST NOT be negotiated when password extension is
 175    deployed, as it provides no more protection than an unsecured
 176    connection.
 177
 178    Implementations of this document MUST ensure that all policies being
 179    applied on the PSK encoding (section 5 of [PSK]) are applied on the
 180    password encoding as well.
 181
 182    Editor note: is it more secure to don't send the password on the
 183    wire and instead of that, mix it with the premaster secret, and use
 184    the result as an input for the key derivation function to implicitly
 185    authenticate the client?
 186
 187    Upon receipt of this message, the server symmetrically decrypts the
 188    EncryptedPassword using the same key as the client to retrieve the
 189    username and the password in clear text. The server then checks its
 190    database for a match. If a match is found, the server sends its
 191    change cipher spec message and proceeds directly to finished
 192    message. If no match is found, the server MUST send a fatal alert,
 193    results in the immediate termination of the connection.
 194
 195    If the server does not recognize the login, it MAY respond with an
 196    "unknown_login" alert message. Alternatively, if the server wishes
 197    to hide the fact that the login was not known, it MAY continue the
 198    protocol as if the login existed but the key was incorrect: that is,
 199    respond with a "decrypt_error" alert.
 200
 201         Client                                               Server
 202         ------                                               ------
 203
 204         ClientHello             -------->
 205                                                         ServerHello
 206                                                        Certificate*
 207                                                  ServerKeyExchange*
 208                                 <--------           ServerHelloDone
 209         ClientKeyExchange
 210         EncryptedPassword
 211         ChangeCipherSpec
 212         Finished                -------->
 213                                                    ChangeCipherSpec
 214                                 <--------                  Finished
 215         Application Data                           Application Data
 216         Attribute Value Pairs                 Attribute Value Pairs
 217         Type Length Value       <=======>         Type Length Value
 218
 219 3. Security Considerations
 220
 221
 222
 223
 224 Badra                     Expires October 2007                 [Page 4]
 225  \f
 226 Internet-draft        Password Ciphersuites for TLS          April 2007
 227
 228
 229    The security considerations described throughout [TLS], [DTLS], and
 230    [TLS1.1] apply here as well.
 231
 232 4. IANA Considerations
 233
 234    This document defines a new TLS extension "password", assigned the
 235    value TBD from the TLS ExtensionType registry defined in [TLSEXT].
 236
 237    This document also defines a new TLS alert message,
 238    unknown_login(TBD).
 239
 240    This document defines a new handshake message, encrypted password,
 241    whose value is to be allocated from the TLS HandshakeType registry
 242    defined in [TLS].
 243
 244 5. References
 245
 246 5.1. Normative References
 247
 248    [TLS]      Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
 249               RFC 2246, January 1999.
 250
 251    [TLSExt]   Blake-Wilson, S., et. al., "Transport Layer Security TLS)
 252               Extensions", RFC 4346, April 2006.
 253
 254    [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
 255               Requirement Levels", RFC 2119, March 1997.
 256
 257    [PSK]      Eronen, P. (Ed.) and H. Tschofenig (Ed.), "Pre-Shared Key
 258               Ciphersuites for Transport Layer Security (TLS)",
 259               RFC 4279, December 2005.
 260
 261    [TLSCAM]   Moriai, S., Kato, A., Kanda M., "Addition of Camellia
 262               Cipher Suites to Transport Layer Security (TLS)",
 263               RFC 4132, July 2005.
 264
 265    [TLSAES]   Chown, P., "Advanced Encryption Standard (AES)
 266               Ciphersuites for Transport Layer Security (TLS)",
 267               RFC 3268, June 2002.
 268
 269    [TLSECC]   Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C.,
 270               Moeller, B., "Elliptic Curve Cryptography (ECC) Cipher
 271               Suites for Transport Layer Security (TLS)", RFC 4492, May
 272               2006
 273
 274    [TLSCTR]   Modadugu, N. and E. Rescorla, "AES Counter Mode Cipher
 275               Suites for TLS and DTLS", draft-ietf-tls-ctr-01.txt (work
 276               in progress), June 2006.
 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 5.2. Informative References
 287
 288    [KERB]     Medvinsky, A. and M. Hur, "Addition of Kerberos Cipher
 289               Suites to Transport Layer Security (TLS)", RFC 2712,
 290               October 1999.
 291
 292 Author's Addresses
 293
 294    Mohamad Badra
 295    LIMOS Laboratory - UMR (6158), CNRS
 296    France             Email: badra@isima.fr
 297
 298 Full Copyright Statement
 299
 300    Copyright (C) The IETF Trust (2007).
 301
 302    This document is subject to the rights, licenses and restrictions
 303    contained in BCP 78, and except as set forth therein, the authors
 304    retain all their rights.
 305
 306    This document and the information contained herein are provided on
 307    an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
 308    REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
 309    IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
 310    WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
 311    WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
 312    ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
 313    FOR A PARTICULAR PURPOSE.
 314
 315 Intellectual Property
 316
 317    The IETF takes no position regarding the validity or scope of any
 318    Intellectual Property Rights or other rights that might be claimed
 319    to pertain to the implementation or use of the technology described
 320    in this document or the extent to which any license under such
 321    rights might or might not be available; nor does it represent that
 322    it has made any independent effort to identify any such rights.
 323    Information on the procedures with respect to rights in RFC
 324    documents can be found in BCP 78 and BCP 79.
 325
 326    Copies of IPR disclosures made to the IETF Secretariat and any
 327    assurances of licenses to be made available, or the result of an
 328    attempt made to obtain a general license or permission for the use
 329    of such proprietary rights by implementers or users of this
 330    specification can be obtained from the IETF on-line IPR repository
 331    at http://www.ietf.org/ipr.
 332
 333
 334
 335
 336 Badra                     Expires October 2007                 [Page 6]
 337  \f
 338 Internet-draft        Password Ciphersuites for TLS          April 2007
 339
 340
 341    The IETF invites any interested party to bring to its attention any
 342    copyrights, patents or patent applications, or other proprietary
 343    rights that may cover technology that may be required to implement
 344    this standard.  Please address the information to the IETF at ietf-
 345    ipr@ietf.org.
 346
 347 Acknowledgment
 348
 349    Funding for the RFC Editor function is provided by the IETF
 350    Administrative Support Activity (IASA).
 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 Badra                     Expires October 2007                 [Page 7]
 393  \f