doc/protocol/draft-badra-tls-password-ext-01.txt

   1 TLS Working Group                                         Mohamad Badra
   2 Internet Draft                                         LIMOS Laboratory
   3 Intended status: Standards Track                      February 24, 2008
   4 Expires: August 2008
   5
   6
   7
   8            Password Extension for the TLS Client Authentication
   9                     draft-badra-tls-password-ext-01.txt
  10
  11
  12 Status of this Memo
  13
  14    By submitting this Internet-Draft, each author represents that any
  15    applicable patent or other IPR claims of which he or she is aware
  16    have been or will be disclosed, and any of which he or she becomes
  17    aware will be disclosed, in accordance with Section 6 of BCP 79.
  18
  19    Internet-Drafts are working documents of the Internet Engineering
  20    Task Force (IETF), its areas, and its working groups.  Note that
  21    other groups may also distribute working documents as Internet-
  22    Drafts.
  23
  24    Internet-Drafts are draft documents valid for a maximum of six months
  25    and may be updated, replaced, or obsoleted by other documents at any
  26    time.  It is inappropriate to use Internet-Drafts as reference
  27    material or to cite them other than as "work in progress."
  28
  29    The list of current Internet-Drafts can be accessed at
  30    http://www.ietf.org/ietf/1id-abstracts.txt
  31
  32    The list of Internet-Draft Shadow Directories can be accessed at
  33    http://www.ietf.org/shadow.html
  34
  35    This Internet-Draft will expire on August 24, 2008.
  36
  37 Copyright Notice
  38
  39    Copyright (C) The IETF Trust (2008).
  40
  41 Abstract
  42
  43    This document specifies a new Transport Layer Security (TLS)
  44    extension and a new TLS message providing TLS client authentication
  45    using passwords.  It provides client credential protection.
  46
  47
  48
  49
  50
  51
  52 Badra                  Expires August 24, 2008                 [Page 1]
  53 \f
  54 Internet-Draft        Password Extension for TLS          February 2008
  55
  56
  57 Table of Contents
  58
  59
  60    1. Introduction...................................................3
  61       1.1. Conventions used in this document.........................3
  62    2. Password Extension.............................................3
  63       2.1. Encrypted Password........................................3
  64    3. Conformance Requirements.......................................6
  65       3.1. Requirements for Management Interfaces....................6
  66    4. Security Considerations........................................6
  67    5. IANA Considerations............................................6
  68    6. References.....................................................7
  69       6.1. Normative References......................................7
  70       6.2. Informative References....................................7
  71    Author's Addresses................................................7
  72    Intellectual Property Statement...................................7
  73    Disclaimer of Validity............................................8
  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 Badra                  Expires August 24, 2008                 [Page 2]
 107 \f
 108 Internet-Draft        Password Extension for TLS          February 2008
 109
 110
 111 1. Introduction
 112
 113    This document defines a new extension and a new TLS message to the
 114    Transport Layer Security (TLS) protocol to enable TLS client
 115    authentication using passwords.  It provides client credential
 116    protection.
 117
 118 1.1. Conventions used in this document
 119
 120    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 121    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 122    document are to be interpreted as described in [RFC2119].
 123
 124 2. Password Extension
 125
 126    In order to negotiate the use of client password-based
 127    authentication, clients MAY include an extension of type "password"
 128    in the extended client hello.  The "extension_data" field of this
 129    extension SHALL be empty.  The extension_type field is to be assigned
 130    by IANA.
 131
 132    For servers aware of the password extension but not wishing to use
 133    it, it will gracefully revert to an ordinary TLS handshake or stop
 134    the negotiation.
 135
 136    Servers that receive an extended hello containing a "password"
 137    extension MAY agree to authenticate the client using passwords by
 138    including an extension of type "password", with empty
 139    "extension_data", in the extended server hello.  The
 140    CertificateRequest payload is omitted from the server response.
 141
 142    Clients return a response along with their credentials by sending a
 143    "EncryptedPassword" message immediately after the "ClientKeyExchange"
 144    message.  The encrypted password message is sent symmetrically
 145    encrypted with the key client_write_key and the cipher algorithm
 146    selected by the server in the ServerHello.cipher_suite.
 147
 148    The Certificate and CertificateVerify payloads are omitted from the
 149    client response.
 150
 151 2.1. Encrypted Password
 152
 153    When this message will be sent:
 154
 155    The client MUST send this message immediately after the client key
 156    exchange message.
 157
 158
 159
 160 Badra                  Expires August 24, 2008                 [Page 3]
 161 \f
 162 Internet-Draft        Password Extension for TLS          February 2008
 163
 164
 165    Structure of this message:
 166
 167         struct {
 168               uint16 length;
 169               select (CipherSpec.cipher_type) {
 170                 case stream:
 171                       stream-ciphered struct {
 172                          opaque fresh_random<16..2^16-1>;
 173                          opaque username<1..2^16-1>;
 174                          opaque password<1..2^16-1>;
 175                      };
 176                 case block:
 177                       block-ciphered struct {
 178                          opaque IV[CipherSpec.block_length];
 179                          opaque username<1..2^16-1>;
 180                          opaque password<1..2^16-1>;
 181                          uint8 adding[EncryptedPassword.padding_length];
 182                          uint8 padding_length;
 183                      };
 184                } EncryptedPassword;
 185
 186    fresh_random
 187
 188    A vector contains at least 16 bytes random value.  It is RECOMMENDED
 189    that implementations provide functionality for generating this
 190    random, taking [RFC4086] into account.
 191
 192    length
 193
 194      The length (in bytes) of the EncryptedPassword structure.
 195
 196    padding
 197
 198      Padding that is added to force the length of the EncryptedPassword
 199      structure to be an integral multiple of the block cipher's block
 200      length.  The padding MAY be any length up to 255 bytes, as long as
 201      it results in the EncryptedPassword.length being an integral
 202      multiple of the block length.  Lengths longer than necessary might
 203      be desirable to frustrate attacks on a protocol that are based on
 204      analysis of the lengths of exchanged messages.  Each uint8 in the
 205      padding data vector MUST be filled with the padding length value.
 206      The receiver MUST check this padding and SHOULD use the
 207      bad_record_mac alert to indicate padding errors.
 208
 209
 210
 211
 212
 213
 214 Badra                  Expires August 24, 2008                 [Page 4]
 215 \f
 216 Internet-Draft        Password Extension for TLS          February 2008
 217
 218
 219    padding_length
 220
 221      The padding length MUST be such that the total size of the
 222      EncryptedPassword structure is a multiple of the cipher's block
 223      length.  Legal values range from zero to 255, inclusive.  This
 224      length specifies the length of the padding field exclusive of the
 225      padding_length field itself.
 226
 227    BulkCipherAlgorithm.null (e.g.  TLS_RSA_WITH_NULL_MD5 and
 228    RSA_WITH_NULL_SHA) MUST NOT be negotiated when password extension is
 229    deployed, as it provides no more protection than an unsecured
 230    connection.
 231
 232    Upon receipt of this message, the server symmetrically decrypts the
 233    EncryptedPassword using the same key as the client to retrieve the
 234    username and the password in clear text.
 235
 236    Next, the server will then check the authentication database to see
 237    if the received username/password and those stored in the database
 238    match.  If a match is found, the server sends its change cipher spec
 239    message and proceeds directly to finished message.  If no match is
 240    found, the server MUST send a fatal alert, results in the immediate
 241    termination of the connection.
 242
 243    This documents doesn't specify how exactly the server checks the
 244    username/password for a match.  However, the server MAY consider
 245    using of an AAA or RADIUS infrastructures.  In this case, the server
 246    calls into the local AAA client, which in turn contacts the AAA
 247    server.  The client's credentials (username and password) are
 248    validated at the AAA server, which in turn responds to the AAA client
 249    with an accept/reject message.
 250
 251         Client                                               Server
 252         ------                                               ------
 253         ExtendedClientHello     -------->
 254                                                 ExtendedServerHello
 255                                                         Certificate
 256                                                  ServerKeyExchange*
 257                                 <--------           ServerHelloDone
 258         ClientKeyExchange
 259         EncryptedPassword
 260         ChangeCipherSpec
 261         Finished                -------->
 262                                                    ChangeCipherSpec
 263                                 <--------                  Finished
 264
 265
 266
 267
 268 Badra                  Expires August 24, 2008                 [Page 5]
 269 \f
 270 Internet-Draft        Password Extension for TLS          February 2008
 271
 272
 273 3. Conformance Requirements
 274
 275    This document does not specify how the server stores the password and
 276    the username, or how exactly it verifies the password and the
 277    username it receives.  It is RECOMMENDED that before looking up the
 278    password, the server processes the username with a SASLprep profile
 279    [RFC4013] appropriate for the username in question.
 280
 281 3.1. Requirements for Management Interfaces
 282
 283    In the absence of an application profile specification specifying
 284    otherwise, a management interface for entering the password and/or
 285    the username MUST support the following:
 286
 287       o   Entering usernames consisting of up to 128 printable Unicode
 288           characters.
 289
 290       o   Entering passwords up to 64 octets in length as ASCII strings
 291           and in hexadecimal encoding.  The management interface MAY
 292           accept other encodings if the algorithm for translating the
 293           encoding to a binary string is specified.
 294
 295 4. Security Considerations
 296
 297    The security considerations described throughout [RFC4346] and
 298    [RFC4366] apply here as well.
 299
 300 5. IANA Considerations
 301
 302    This document defines a new TLS extension "password", assigned the
 303    value to be allocated from the TLS ExtensionType registry defined in
 304    [RFC4366].
 305
 306    This document defines a new handshake message, encrypted password,
 307    whose value is to be allocated from the TLS HandshakeType registry
 308    defined in [RFC4346].
 309
 310
 311
 312
 313
 314
 315
 316
 317
 318
 319
 320
 321
 322 Badra                  Expires August 24, 2008                 [Page 6]
 323 \f
 324 Internet-Draft        Password Extension for TLS          February 2008
 325
 326
 327 6. References
 328
 329 6.1. Normative References
 330
 331    [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
 332              Requirement Levels", BCP 14, RFC 2119, March 1997.
 333
 334    [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
 335              "Randomness Requirements for Security", BCP 106, RFC 4086,
 336              June 2005.
 337
 338    [RFC4346] Dierks, T. and E. Rescorla, "The Transport Layer Security
 339              (TLS) Protocol 1.1", RFC 4346, April 2006.
 340
 341    [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
 342              and T. Wright, "Transport Layer Security (TLS) Extensions",
 343              RFC 4366, April 2006.
 344
 345 6.2. Informative References
 346
 347    [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names
 348              and Passwords", RFC 4013, February 2005.
 349
 350
 351
 352 Author's Addresses
 353
 354    Mohamad Badra
 355    LIMOS Laboratory - UMR6158, CNRS
 356    France
 357
 358    Email: badra@isima.fr
 359
 360
 361 Intellectual Property Statement
 362
 363    The IETF takes no position regarding the validity or scope of any
 364    Intellectual Property Rights or other rights that might be claimed to
 365    pertain to the implementation or use of the technology described in
 366    this document or the extent to which any license under such rights
 367    might or might not be available; nor does it represent that it has
 368    made any independent effort to identify any such rights.  Information
 369    on the procedures with respect to rights in RFC documents can be
 370    found in BCP 78 and BCP 79.
 371
 372    Copies of IPR disclosures made to the IETF Secretariat and any
 373    assurances of licenses to be made available, or the result of an
 374
 375
 376 Badra                  Expires August 24, 2008                 [Page 7]
 377 \f
 378 Internet-Draft        Password Extension for TLS          February 2008
 379
 380
 381    attempt made to obtain a general license or permission for the use of
 382    such proprietary rights by implementers or users of this
 383    specification can be obtained from the IETF on-line IPR repository at
 384    http://www.ietf.org/ipr.
 385
 386    The IETF invites any interested party to bring to its attention any
 387    copyrights, patents or patent applications, or other proprietary
 388    rights that may cover technology that may be required to implement
 389    this standard.  Please address the information to the IETF at
 390    ietf-ipr@ietf.org.
 391
 392 Disclaimer of Validity
 393
 394    This document and the information contained herein are provided on an
 395    "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
 396    OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
 397    THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
 398    OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 399    THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
 400    WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
 401
 402 Copyright Statement
 403
 404    Copyright (C) The IETF Trust (2008).
 405
 406    This document is subject to the rights, licenses and restrictions
 407    contained in BCP 78, and except as set forth therein, the authors
 408    retain all their rights.
 409
 410 Acknowledgment
 411
 412    Funding for the RFC Editor function is currently provided by the
 413    Internet Society.
 414
 415
 416
 417
 418
 419
 420
 421
 422
 423
 424
 425
 426
 427
 428
 429
 430 Badra                  Expires August 24, 2008                 [Page 8]
 431 \f