GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc8146

Internet Engineering Task Force (IETF) D. Harkins Request for Comments: 8146 HP Enterprise Updates: 5931 April 2017 Category: Informational ISSN: 2070-1721

      Adding Support for Salted Password Databases to EAP-pwd

Abstract

 EAP-pwd is an Extensible Authentication Protocol (EAP) method that
 utilizes a shared password for authentication using a technique that
 is resistant to dictionary attacks.  It includes support for raw keys
 and double hashing of a password in the style of Microsoft Challenge
 Handshake Authentication Protocol version 2 (MSCHAPv2), but it does
 not include support for salted passwords.  There are many existing
 databases of salted passwords, and it is desirable to allow their use
 with EAP-pwd.

Status of This Memo

 This document is not an Internet Standards Track specification; it is
 published for informational purposes.
 This document is a product of the Internet Engineering Task Force
 (IETF).  It represents the consensus of the IETF community.  It has
 received public review and has been approved for publication by the
 Internet Engineering Steering Group (IESG).  Not all documents
 approved by the IESG are a candidate for any level of Internet
 Standard; see Section 2 of RFC 7841.
 Information about the current status of this document, any errata,
 and how to provide feedback on it may be obtained at
 http://www.rfc-editor.org/info/rfc8146.

Harkins Informational [Page 1] RFC 8146 NaCled EAP-pwd April 2017

Copyright Notice

 Copyright (c) 2017 IETF Trust and the persons identified as the
 document authors.  All rights reserved.
 This document is subject to BCP 78 and the IETF Trust's Legal
 Provisions Relating to IETF Documents
 (http://trustee.ietf.org/license-info) in effect on the date of
 publication of this document.  Please review these documents
 carefully, as they describe your rights and restrictions with respect
 to this document.  Code Components extracted from this document must
 include Simplified BSD License text as described in Section 4.e of
 the Trust Legal Provisions and are provided without warranty as
 described in the Simplified BSD License.

Table of Contents

 1. Introduction ....................................................3
    1.1. Background .................................................3
    1.2. Keyword Definition .........................................3
 2. Salted Passwords in EAP-pwd .....................................3
    2.1. Password Preprocessing .....................................3
    2.2. The Salting of a Password ..................................5
    2.3. Using UNIX crypt ...........................................5
    2.4. Using scrypt ...............................................6
    2.5. Using PBKDF2 ...............................................6
    2.6. Protocol Modifications .....................................7
    2.7. Payload Modifications ......................................8
 3. IANA Considerations .............................................8
 4. Security Considerations .........................................9
 5. References ......................................................9
    5.1. Normative References .......................................9
    5.2. Informative References ....................................10
 Acknowledgements ..................................................11
 Author's Address ..................................................11

Harkins Informational [Page 2] RFC 8146 NaCled EAP-pwd April 2017

1. Introduction

1.1. Background

 Databases of stored passwords present an attractive target for attack
 -- get access to the database, learn the passwords.  To confound such
 attacks, a random "salt" was hashed with the password and the
 resulting digest stored, along with the salt, instead of the raw
 password.  This has the effect of randomizing the password; even if
 two, distinct users have chosen the same password, the stored, and
 salted, password will be different.  It also requires an adversary
 who has compromised the security of the stored database to launch a
 dictionary attack per entry to recover passwords.
 Dictionary attacks, especially using custom hardware, represent real-
 world attacks and merely salting a password is insufficient to
 protect a password database.  To address these attacks, a sequential
 memory hard function, such as described in [RFC7914], is used.
 While salting a password database is not sufficient to deal with many
 real-world attacks, the historic popularity of password salting means
 there are a large number of such databases deployed, and EAP-pwd
 needs to be able to support them.  In addition, EAP-pwd needs to be
 able to support databases using more modern sequential memory hard
 functions for protection.
 EAP-pwd imposes an additional security requirement on a database of
 salted passwords that otherwise would not exist, see Section 4.

1.2. Keyword Definition

 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
 document are to be interpreted as described in [RFC2119].

2. Salted Passwords in EAP-pwd

2.1. Password Preprocessing

 EAP-pwd is based on the "dragonfly" Password-Authenticated Key
 Exchange (PAKE) -- see [RFC7664].  This is a balanced PAKE and
 requires that each party to the protocol obtain an identical
 representation of a processed password (see Section 4).  Therefore,
 salting of a password is treated as an additional password
 preprocessing technique of EAP-pwd.  The salt and digest to use are
 conveyed to the peer by the server, and the password is processed
 prior to fixing the password element (see Section 2.8.3 of
 [RFC5931]).

Harkins Informational [Page 3] RFC 8146 NaCled EAP-pwd April 2017

 This memo defines eight (8) new password preprocessing techniques for
 EAP-pwd:
 o  0x03: a random salt with SHA-1
 o  0x04: a random salt with SHA-256
 o  0x05: a random salt with SHA-512
 o  0x06: UNIX crypt()
 o  0x07: scrypt
 o  0x08: PBKDF2 with SHA-256
 o  0x09: PBKDF2 with SHA-512
 o  0x0A: SASLprep then a random salt with SHA-1
 o  0x0B: SASLprep then a random salt with SHA-256
 o  0x0C: SASLprep then a random salt with SHA-512
 o  0x0D: SASLprep then UNIX crypt()
 o  0x0E: OpaqueString then scrypt
 o  0x0F: OpaqueString then PBKDF2 with SHA-256
 o  0x10: OpaqueString then PBKDF2 with SHA-512
 When passing salt, the size of the salt SHOULD be at least as long as
 the message digest of the hash algorithm used.  There is no guarantee
 that deployed salted databases have followed this rule, and in the
 interest of interoperability, an EAP peer SHOULD NOT abort an EAP-pwd
 exchange if the length of the salt conveyed during the exchange is
 less than the message digest of the indicated hash algorithm.
 UNIX crypt() ([CRY]), scrypt ([RFC7914]), and PBKDF2 ([RFC8018])
 impose additional formatting requirements on the passed salt.  See
 below.
 Plain salting techniques using [SHS] are included for support of
 existing databases. scrypt and PBKDF2 techniques are RECOMMENDED for
 new password database deployments.
 SASLprep has been deprecated, but databases treated with SASLprep
 exist; it is necessary to provide code points for them.  When using

Harkins Informational [Page 4] RFC 8146 NaCled EAP-pwd April 2017

 SASLprep, a password SHALL be considered a "stored string" per
 [RFC3454]; therefore, unassigned code points are prohibited.  The
 output of SASLprep SHALL be the binary representation of the
 processed UTF-8 character string.  Prohibited output and unassigned
 code points encountered in SASLprep preprocessing SHALL cause a
 failure of preprocessing, and the output SHALL NOT be used with EAP-
 pwd.
 When performing one of the preprocessing techniques (0x0E-0x10), the
 password SHALL be a UTF-8 string and SHALL be preprocessed by
 applying the Preparation and Enforcement steps of the OpaqueString
 profile in [RFC7613] to the password.  The output of OpaqueString,
 also a UTF-8 string, becomes the EAP-pwd password and SHALL be hashed
 with the indicated algorithm.
 There is a large number of deployed password databases that use
 salting and hashing in the style of [RFC7616], but these deployments
 require a nonce contribution by the client (as well as the server),
 and EAP-pwd does not have the capability to provide that information.

2.2. The Salting of a Password

 For both parties to derive the same salted password, there needs to
 be a canonical method of salting a password.  When using EAP-pwd, a
 password SHALL be salted by hashing the password followed by the salt
 using the designated hash function:
    salted-password = Hash(password | salt)
 The server stores the salted-password, and the salt, in its database
 and the client derives the salted password on the fly.

2.3. Using UNIX crypt

 Different algorithms are supported with the UNIX crypt() function.
 The particular algorithm used is indicated by prepending an encoding
 of "setting" to the passed salt.  The specific algorithm used is
 opaque to EAP-pwd as the entire salt, including the encoded
 "setting", is passed as an opaque string for interpretation by
 crypt().  The salted password used for EAP-pwd SHALL be the output of
 crypt():
    salted-password = crypt(password, salt)
 The server stores the salted-password, and the encoded algorithm plus
 salt, in its database and the client derives the salted-password on-
 the-fly.

Harkins Informational [Page 5] RFC 8146 NaCled EAP-pwd April 2017

 If the server indicates a crypt() algorithm that is unsupported by
 the client, the exchange fails and the client MUST terminate the
 connection.

2.4. Using scrypt

 The scrypt function takes several parameters:
 o  N, the cost parameter
 o  r, the block size
 o  p, the parallelization parameter
 o  dkLen, the length of the output
 These parameters are encoded into the "salt" field of the modified
 EAP-pwd message.  Parameters r and dkLen SHALL be 16-bit integers in
 network order.  The other parameters SHALL each be 32-bit integers in
 network order.  The "salt" field that gets transmitted in EAP-pwd
 SHALL therefore be:
    N || r || p || dkLen || salt
 where || represents concatenation.
 The value of N represents the exponent taken to the power of two in
 order to determine the CPU/Memory cost of scrypt -- i.e., the value
 is 2^N.  Per [RFC7914], the resulting CPU/Memory cost value SHALL be
 less than 2^(128 * r / 8), and the value p SHALL be less than or
 equal to ((2^32 - 1) * 32) / (128 * r).
 Note: EAP-pwd uses the salted password directly as the authentication
 credential and will hash it with a counter in order to obtain a
 secret element in a finite field.  Therefore, it makes little sense
 to use dkLen greater than the length of the digest produced by the
 underlying hash function, but the capability is provided to do so
 anyway.

2.5. Using PBKDF2

 The PBKDF2 function requires two parameters:
 o  c, the iteration count
 o  dkLen, the length of the output

Harkins Informational [Page 6] RFC 8146 NaCled EAP-pwd April 2017

 These parameters are encoded into the "salt" field of the modified
 EAP-pwd message.  The parameters SHALL be 16-bit integers in network
 order.  The "salt" field that gets transmitted in EAP-pwd SHALL
 therefore be:
    c || dkLen || salt
 where || represents concatenation.
 Note: EAP-pwd uses the salted password directly as the authentication
 credential and will hash it with a counter in order to obtain a
 secret element in a finite field.  Therefore, it makes little sense
 to use a dkLen greater than the length of the digest produced by the
 underlying hash function, but the capability is provided to do so
 anyway.

2.6. Protocol Modifications

 Like all EAP methods, EAP-pwd is server initiated, and the initial
 identity supplied by the client is not useful for authentication
 purposes.  Because of this, the server is required to indicate its
 intentions, including the password preprocessing it wishes to use,
 before it knows the true identity of the client.  This prevents the
 server from supporting multiple salt digests simultaneously in a
 single password database.  To support multiple salt digests
 simultaneously, it is necessary to maintain multiple password
 databases and use the routable portion of the client identity to
 select one when initiating EAP-pwd.
 The server uses the EAP-pwd-ID/Request to indicate the password
 preprocessing technique.  The client indicates its acceptance of the
 password preprocessing technique and identifies itself in the EAP-
 pwd-ID/Response.  If the client does not accept any of the offered
 preprocessing techniques, it SHALL terminate the exchange.  Upon
 receipt of the EAP-pwd-ID/Response, the server knows the identity of
 the client and can look up the client's salted password and the salt
 from the database.  The server adds the length of the salt and the
 salt itself to the EAP-pwd-Commit/Request message (see Section 2.7).
 The server can fix the password element (Section 2.8.3 of [RFC5931])
 as soon as the salted password has been looked up in the database.
 The client, though, is required to wait until receipt of the server's
 EAP-pwd-Commit/Request before it begins fixing the password element.

Harkins Informational [Page 7] RFC 8146 NaCled EAP-pwd April 2017

2.7. Payload Modifications

 When a salted password preprocessing technique is agreed upon during
 the EAP-pwd-ID exchange, the EAP-pwd-Commit payload is modified to
 include the salt and salt length (see Figure 1).  The server passes
 the salt and salt length in the EAP-pwd-Commit/Request; the client's
 EAP-pwd-Commit/Response is unchanged, and it MUST NOT echo the salt
 length and salt in its EAP-pwd-Commit/Response.
     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |   Salt-len    |                                               |
    +-+-+-+-+-+-+-+-+                                               ~
    ~                            Salt             +-+-+-+-+-+-+-+-+-+
    |                                             |                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                 ~
    |                                                               |
    ~                           Element                             ~
    |                                                               |
    ~                               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               |                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               ~
    |                                                               |
    ~                            Scalar             +-+-+-+-+-+-+-+-+
    |                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                Figure 1: Salted EAP-pwd-Commit/Request
 The "salt-len" SHALL be non-zero, and it indicates the length, in
 octets, of the salt that follows.  The "Salt" SHALL be a binary
 string.  The "Element" and "Scalar" are encoded according to
 Section 3.3 of [RFC5931].
 Note: when a non-salted password preprocessing method is used, for
 example, any of the methods from [RFC5931], the EAP-pwd-Commit
 payload MUST NOT be modified to include the salt and salt length.

3. IANA Considerations

 IANA has allocated fourteen (14) values from the "password
 preprocessing method registry" established by [RFC5931].

Harkins Informational [Page 8] RFC 8146 NaCled EAP-pwd April 2017

4. Security Considerations

 EAP-pwd requires each side to produce an identical representation of
 the (processed) password before the password element can be fixed.
 This symmetry undercuts one of the benefits to salting a password
 database because the salted password from a compromised database can
 be used directly to impersonate the EAP-pwd client -- since the
 plaintext password need not be recovered, no dictionary attack is
 needed.  While the immediate effect of such a compromise would be
 compromise of the server, the per-user salt would still prevent the
 adversary from recovering the password, barring a successful
 dictionary attack, to use for other purposes.
 Salted password databases used with EAP-pwd MUST be afforded the same
 level of protection as databases of plaintext passwords.
 Hashing a password with a salt increases the work factor for an
 attacker to obtain the cleartext password, but dedicated hardware
 makes this increased work factor increasingly negligible in real-
 world scenarios.  Cleartext password databases SHOULD be protected
 with a scheme that uses a sequential memory hard function such as
 [RFC7914].
 EAP-pwd sends the salt in the clear.  If EAP-pwd is not tunneled in
 another, encrypting, EAP method, an adversary that can observe
 traffic from server to authenticator or from authenticator to client
 would learn the salt used for a particular user.  While knowledge of
 a salt by an adversary may be of a somewhat dubious nature (pre-image
 resistance of the hash function used will protect the client's
 password and, as noted above, the database of salted passwords must
 still be protected from disclosure), it does represent potential
 additional meta-data in the hands of a untrusted third party.

5. References

5.1. Normative References

 [CRY]      Linux Programmer's Manual, "CRYPT(3)", August 2015,
            <http://man7.org/linux/man-pages/man3/crypt.3.html>.
 [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
            Requirement Levels", BCP 14, RFC 2119,
            DOI 10.17487/RFC2119, March 1997,
            <http://www.rfc-editor.org/info/rfc2119>.

Harkins Informational [Page 9] RFC 8146 NaCled EAP-pwd April 2017

 [RFC3454]  Hoffman, P. and M. Blanchet, "Preparation of
            Internationalized Strings ("stringprep")", RFC 3454,
            DOI 10.17487/RFC3454, December 2002,
            <http://www.rfc-editor.org/info/rfc3454>.
 [RFC5931]  Harkins, D. and G. Zorn, "Extensible Authentication
            Protocol (EAP) Authentication Using Only a Password",
            RFC 5931, DOI 10.17487/RFC5931, August 2010,
            <http://www.rfc-editor.org/info/rfc5931>.
 [RFC7613]  Saint-Andre, P. and A. Melnikov, "Preparation,
            Enforcement, and Comparison of Internationalized Strings
            Representing Usernames and Passwords", RFC 7613,
            DOI 10.17487/RFC7613, August 2015,
            <http://www.rfc-editor.org/info/rfc7613>.
 [RFC7914]  Percival, C. and S. Josefsson, "The scrypt Password-Based
            Key Derivation Function", RFC 7914, DOI 10.17487/RFC7914,
            August 2016, <http://www.rfc-editor.org/info/rfc7914>.
 [RFC8018]  Moriarty, K., Ed., Kaliski, B., and A. Rusch, "PKCS #5:
            Password-Based Cryptography Specification Version 2.1",
            RFC 8018, DOI 10.17487/RFC8018, January 2017,
            <http://www.rfc-editor.org/info/rfc8018>.
 [SHS]      National Institute of Standards and Technology, "Secure
            Hash Standard (SHS)", FIPS PUB 180-4,
            DOI 10.6028/NIST.FIPS.180-4, August 2015,
            <http://csrc.nist.gov/publications/fips/fips180-4/
            fips-180-4.pdf>.

5.2. Informative References

 [RFC7616]  Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
            Digest Access Authentication", RFC 7616,
            DOI 10.17487/RFC7616, September 2015,
            <http://www.rfc-editor.org/info/rfc7616>.
 [RFC7664]  Harkins, D., Ed., "Dragonfly Key Exchange", RFC 7664,
            DOI 10.17487/RFC7664, November 2015,
            <http://www.rfc-editor.org/info/rfc7664>.

Harkins Informational [Page 10] RFC 8146 NaCled EAP-pwd April 2017

Acknowledgements

 Thanks to Stefan Winter and the eduroam project for its continued
 interest in using EAP-pwd.  Thanks to Simon Josefsson for his advice
 on support for scrypt and PBKDF2.

Author's Address

 Dan Harkins
 HP Enterprise
 3333 Scott Boulevard
 Santa Clara, CA  95054
 United States of America
 Email: dharkins@arubanetworks.com

Harkins Informational [Page 11]

/data/webs/external/dokuwiki/data/pages/rfc/rfc8146.txt · Last modified: 2017/04/21 23:57 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki