diff options
Diffstat (limited to 'doc/rfc/rfc6124.txt')
| -rw-r--r-- | doc/rfc/rfc6124.txt | 1851 |
1 files changed, 1851 insertions, 0 deletions
diff --git a/doc/rfc/rfc6124.txt b/doc/rfc/rfc6124.txt new file mode 100644 index 0000000..baba624 --- /dev/null +++ b/doc/rfc/rfc6124.txt @@ -0,0 +1,1851 @@ + + + + + + +Internet Engineering Task Force (IETF) Y. Sheffer +Request for Comments: 6124 Independent +Category: Informational G. Zorn +ISSN: 2070-1721 Network Zen + H. Tschofenig + Nokia Siemens Networks + S. Fluhrer + Cisco + February 2011 + + + An EAP Authentication Method Based on + the Encrypted Key Exchange (EKE) Protocol + +Abstract + + The Extensible Authentication Protocol (EAP) describes a framework + that allows the use of multiple authentication mechanisms. This + document defines an authentication mechanism for EAP called EAP-EKE, + based on the Encrypted Key Exchange (EKE) protocol. This method + provides mutual authentication through the use of a short, easy to + remember password. Compared with other common authentication + methods, EAP-EKE is not susceptible to dictionary attacks. Neither + does it require the availability of public-key certificates. + +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 5741. + + 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/rfc6124. + + + + + + + + + + + +Sheffer, et al. Informational [Page 1] + +RFC 6124 The EAP-EKE Method February 2011 + + +Copyright Notice + + Copyright (c) 2011 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. + + This document may contain material from IETF Documents or IETF + Contributions published or made publicly available before November + 10, 2008. The person(s) controlling the copyright in some of this + material may not have granted the IETF Trust the right to allow + modifications of such material outside the IETF Standards Process. + Without obtaining an adequate license from the person(s) controlling + the copyright in such materials, this document may not be modified + outside the IETF Standards Process, and derivative works of it may + not be created outside the IETF Standards Process, except to format + it for publication as an RFC or to translate it into languages other + than English. + + + + + + + + + + + + + + + + + + + + + + + + + +Sheffer, et al. Informational [Page 2] + +RFC 6124 The EAP-EKE Method February 2011 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 3.1. Message Flows . . . . . . . . . . . . . . . . . . . . . . 4 + 4. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 7 + 4.1. EAP-EKE Header . . . . . . . . . . . . . . . . . . . . . . 7 + 4.2. EAP-EKE Payloads . . . . . . . . . . . . . . . . . . . . . 8 + 4.2.1. The EAP-EKE-ID Payload . . . . . . . . . . . . . . . . 8 + 4.2.2. The EAP-EKE-Commit Payload . . . . . . . . . . . . . . 10 + 4.2.3. The EAP-EKE-Confirm Payload . . . . . . . . . . . . . 11 + 4.2.4. The EAP-EKE-Failure Payload . . . . . . . . . . . . . 12 + 4.3. Protected Fields . . . . . . . . . . . . . . . . . . . . . 13 + 4.4. Encrypted Fields . . . . . . . . . . . . . . . . . . . . . 14 + 4.5. Channel Binding Values . . . . . . . . . . . . . . . . . . 14 + 5. Protocol Sequence . . . . . . . . . . . . . . . . . . . . . . 15 + 5.1. EAP-EKE-Commit/Request . . . . . . . . . . . . . . . . . . 15 + 5.2. EAP-EKE-Commit/Response . . . . . . . . . . . . . . . . . 17 + 5.3. EAP-EKE-Confirm/Request . . . . . . . . . . . . . . . . . 18 + 5.4. EAP-EKE-Confirm/Response . . . . . . . . . . . . . . . . . 18 + 5.5. MSK and EMSK . . . . . . . . . . . . . . . . . . . . . . . 19 + 6. Cryptographic Details . . . . . . . . . . . . . . . . . . . . 19 + 6.1. Generating Keying Material . . . . . . . . . . . . . . . . 19 + 6.2. Diffie-Hellman Groups . . . . . . . . . . . . . . . . . . 20 + 6.3. Mandatory Algorithms . . . . . . . . . . . . . . . . . . . 20 + 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 + 8.1. Cryptographic Analysis . . . . . . . . . . . . . . . . . . 27 + 8.2. Diffie-Hellman Group Considerations . . . . . . . . . . . 28 + 8.3. Resistance to Active Attacks . . . . . . . . . . . . . . . 28 + 8.4. Identity Protection, Anonymity, and Pseudonymity . . . . . 28 + 8.5. Password Processing and Long-Term Storage . . . . . . . . 29 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29 + 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 + 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 + 10.2. Informative References . . . . . . . . . . . . . . . . . . 31 + +1. Introduction + + The predominant access method for the Internet today is that of a + human using a username and password to authenticate to a computer + enforcing access control. Proof of knowledge of the password + authenticates the human to the computer. + + Typically, these passwords are not stored on a user's computer for + security reasons and must be entered each time the human desires + network access. Therefore, the passwords must be ones that can be + + + +Sheffer, et al. Informational [Page 3] + +RFC 6124 The EAP-EKE Method February 2011 + + + repeatedly entered by a human with a low probability of error. They + will likely not possess high entropy and it may be assumed that an + adversary with access to a dictionary will have the ability to guess + a user's password. It is therefore desirable to have a robust + authentication method that is secure even when used with a weak + password in the presence of a strong adversary. + + EAP-EKE is an EAP method [RFC3748] that addresses the problem of + password-based authenticated key exchange, using a possibly weak + password for authentication and to derive an authenticated and + cryptographically strong shared secret. This problem was first + described by Bellovin and Merritt in [BM92] and [BM93]. + Subsequently, a number of other solution approaches have been + proposed, for example [JAB96], [LUC97], [BMP00], and others. + + This proposal is based on the original Encrypted Key Exchange (EKE) + proposal, as described in [BM92]. Some of the variants of the + original EKE have been attacked, see e.g., [PA97], and improvements + have been proposed. None of these subsequent improvements have been + incorporated into the current protocol. However, we have used only + the subset of [BM92] (namely the variant described in Section 3.1 of + that paper) that has withstood the test of time and is believed + secure as of this writing. + +2. Terminology + + This document uses Encr(Ke, ...) to denote encrypted information, and + Prot(Ke, Ki, ...) to denote encrypted and integrity protected + information. + + 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]. + +3. Protocol + + EAP is a two-party protocol spoken between an EAP peer and an EAP + server (also known as "authenticator"). An EAP method defines the + specific authentication protocol being used by EAP. This memo + defines a particular method and therefore defines the messages sent + between the EAP server and the EAP peer for the purpose of + authentication and key derivation. + +3.1. Message Flows + + A successful run of EAP-EKE consists of three message exchanges: an + Identity exchange, a Commit exchange, and a Confirm exchange. This + is shown in Figure 1. + + + +Sheffer, et al. Informational [Page 4] + +RFC 6124 The EAP-EKE Method February 2011 + + + The peer and server use the EAP-EKE Identity exchange to learn each + other's identities and to agree upon a ciphersuite to use in the + subsequent exchanges. In the Commit exchange, the peer and server + exchange information to generate a shared key and also to bind each + other to a particular guess of the password. In the Confirm + exchange, the peer and server prove liveness and knowledge of the + password by generating and verifying verification data (note that the + second message of the Commit exchange already plays an essential part + in this liveness proof). + + +--------+ +--------+ + | | EAP-EKE-ID/Request | | + | EAP |<------------------------------------| EAP | + | peer | | server | + | (P) | EAP-EKE-ID/Response | (S) | + | |------------------------------------>| | + | | | | + | | EAP-EKE-Commit/Request | | + | |<------------------------------------| | + | | | | + | | EAP-EKE-Commit/Response | | + | |------------------------------------>| | + | | | | + | | EAP-EKE-Confirm/Request | | + | |<------------------------------------| | + | | | | + | | EAP-EKE-Confirm/Response | | + | |------------------------------------>| | + | | | | + | | EAP-Success | | + | |<------------------------------------| | + +--------+ +--------+ + + Figure 1: A Successful EAP-EKE Exchange + + Schematically, the original exchange as described in [BM92] (and with + the roles reversed) is: + + Server Peer + ------ ---- + + Encr(Password, y_s) -> + + <- Encr(Password, y_p), Encr(SharedSecret, Nonce_P) + + Encr(SharedSecret, Nonce_S | Nonce_P) -> + + <- Encr(SharedSecret, Nonce_S) + + + +Sheffer, et al. Informational [Page 5] + +RFC 6124 The EAP-EKE Method February 2011 + + + Where: + + o Password is a typically short string, shared between the server + and the peer. In other words, the same password is used to + authenticate the server to the peer, and vice versa. + + o y_s and y_p are the server's and the peer's, respectively, + ephemeral public key, i.e., y_s = g ^ x_s (mod p) and + y_p = g ^ x_p (mod p). + + o Nonce_S, Nonce_P are random strings generated by the server and + the peer as cryptographic challenges. + + o SharedSecret is the secret created by the Diffie-Hellman + algorithm, namely SharedSecret = g^(x_s * x_p) (mod p). This + value is calculated by the server as: SharedSecret = y_p ^ x_s + (mod p), and by the peer as: SharedSecret = y_s ^ x_p (mod p). + + The current protocol extends the basic cryptographic protocol, and + the regular successful exchange becomes: + + Message Server Peer + --------- -------- ------ + ID/Request ID_S, CryptoProposals -> + + ID/Response <- ID_P, CryptoSelection + + Commit/Request Encr(Password, y_s) -> + + Commit/Response <- Encr(Password, y_p), Prot(Ke, Ki, Nonce_P) + + Confirm/Request Prot(Ke, Ki, Nonce_S | Nonce_P), Auth_S -> + + Confirm/Response <- Prot(Ke, Ki, Nonce_S), Auth_P + + + Where, in addition to the above terminology: + + o Encr means encryption only, and Prot is encryption with integrity + protection. + + o Ke is an encryption key, and Ki is an integrity-protection key. + + Section 5 explains the various cryptographic values and how they are + derived. + + + + + + +Sheffer, et al. Informational [Page 6] + +RFC 6124 The EAP-EKE Method February 2011 + + + As shown in the exchange above, the following information elements + have been added to the original protocol: identity values for both + protocol parties (ID_S, ID_P), negotiation of cryptographic + protocols, and signature fields to protect the integrity of the + negotiated parameters (Auth_S, Auth_P). In addition, the shared + secret is not used directly. In this initial exposition, a few + details were omitted for clarity. Section 5 should be considered as + authoritative regarding message and field details. + +4. Message Formats + + EAP-EKE defines a small number of message types, each message + consisting of a header followed by a payload. This section defines + the header, several payload formats, as well as the format of + specific fields within the payloads. + + As usual, all multi-octet strings MUST be laid out in network byte + order. + +4.1. EAP-EKE Header + + The EAP-EKE header consists of the standard EAP header (see Section 4 + of [RFC3748]), followed by an EAP-EKE exchange type. The header has + the following structure: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Code | Identifier | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | EKE-Exch | Data ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 2: EAP-EKE Header + + The Code, Identifier, Length, and Type fields are all part of the EAP + header as defined in [RFC3748]. The Type field in the EAP header is + 53 for EAP-EKE Version 1. + + The EKE-Exch (EKE Exchange) field identifies the type of EAP-EKE + payload encapsulated in the Data field. This document defines the + following values for the EKE-Exch field: + + o 0x00: Reserved + + o 0x01: EAP-EKE-ID exchange + + o 0x02: EAP-EKE-Commit exchange + + + +Sheffer, et al. Informational [Page 7] + +RFC 6124 The EAP-EKE Method February 2011 + + + o 0x03: EAP-EKE-Confirm exchange + + o 0x04: EAP-EKE-Failure message + + Further values of this EKE-Exch field are available via IANA + registration (Section 7.7). + +4.2. EAP-EKE Payloads + + EAP-EKE messages all contain the EAP-EKE header and information + encoded in a single payload, which differs for the different + exchanges. + +4.2.1. The EAP-EKE-ID Payload + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | NumProposals | Reserved | Proposal ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ... Proposal | IDType | Identity ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 3: EAP-EKE-ID Payload + + The EAP-EKE-ID payload contains the following fields: + + NumProposals: + + The NumProposals field contains the number of Proposal fields + subsequently contained in the payload. In the EAP-EKE-ID/Request + message, the NumProposals field MUST NOT be set to zero (0), and + in the EAP-EKE-ID/Response message, the NumProposals field MUST be + set to one (1). The offered proposals in the Request are listed + contiguously in priority order, most preferable first. The + selected proposal in the Response MUST be fully identical with one + of the offered proposals. + + Reserved: + + This field MUST be sent as zero, and MUST be ignored by the + recipient. + + + + + + + + + +Sheffer, et al. Informational [Page 8] + +RFC 6124 The EAP-EKE Method February 2011 + + + Proposal: + + Each proposal consists of four one-octet fields, in this order: + + Group Description: + + This field's value is taken from the IANA registry for Diffie- + Hellman groups defined in Section 7.1. + + Encryption: + + This field's value is taken from the IANA registry for + encryption algorithms defined in Section 7.2. + + PRF: + + This field's value is taken from the IANA registry for pseudo- + random functions defined in Section 7.3. + + MAC: + + This field's value is taken from the IANA registry for keyed + message digest algorithms defined in Section 7.4. + + IDType: + + Denotes the Identity Type. This is taken from the IANA registry + defined in Section 7.5. The server and the peer MAY use different + identity types. All implementations MUST be able to receive two + identity types: ID_NAI and ID_FQDN. + + Identity: + + The meaning of the Identity field depends on the values of the + Code and IDType fields. + + * EAP-EKE-ID/Request: server ID + + * EAP-EKE-ID/Response: peer ID + + The length of the Identity field is computed from the Length field + in the EAP header. Specifically, its length is + + eap_header_length - 9 - 4 * number_of_proposals. + + This field, like all other fields in this specification, MUST be + octet-aligned. + + + + +Sheffer, et al. Informational [Page 9] + +RFC 6124 The EAP-EKE Method February 2011 + + +4.2.2. The EAP-EKE-Commit Payload + + This payload allows both parties to send their encrypted ephemeral + public key, with the peer also including a Challenge. + + In addition, a small amount of data can be included by the server + and/or the peer, and used for channel binding. This data is sent + here unprotected, but is verified later, when it is signed by the + Auth_S/Auth_P payloads of the EAP-EKE-Confirm exchange. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | DHComponent_S/DHComponent_P ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | PNonce_P ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | CBValue (zero or more occurrences) ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 4: EAP-EKE-Commit Payload + + DHComponent_S/DHComponent_P: + + This field contains the password-encrypted Diffie-Hellman public + key, which is generated as described in Section 5.1. Its size is + determined by the group and the encryption algorithm. + + PNonce_P: + + This field only appears in the response, and contains the + encrypted and integrity-protected challenge value sent by the + peer. The field's size is determined by the encryption and MAC + algorithms being used, since this protocol mandates a fixed nonce + size for a given choice of algorithms. See Section 5.2. + + + + + + + + + + +Sheffer, et al. Informational [Page 10] + +RFC 6124 The EAP-EKE Method February 2011 + + + CBValue: + + This structure MAY be included both in the request and in the + response, and MAY be repeated multiple times in a single payload. + See Section 4.5. Each structure contains its own length. The + field is neither encrypted nor integrity protected, instead it is + protected by the AUTH payloads in the Confirm exchange. + +4.2.3. The EAP-EKE-Confirm Payload + + Using this payload, both parties complete the authentication by + generating a shared temporary key, authenticating the entire + protocol, and generating key material for the EAP consumer protocol. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | PNonce_PS/PNonce_S ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Auth_S/Auth_P ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 5: EAP-EKE-Confirm Payload + + PNonce_PS/PNonce_S: + + This field ("protected nonce") contains the encrypted and + integrity-protected response to the other party's challenge; see + Sections 5.3 and 5.4. Similarly to the PNonce_P field, this + field's size is determined by the encryption and MAC algorithms. + + Auth_S/Auth_P: + + This field signs the preceding messages, including the Identity + and the negotiated fields. This prevents various possible + attacks, such as algorithm downgrade attacks. See Section 5.3 and + Section 5.4. The size is determined by the pseudo-random function + negotiated. + + + + + + + + + +Sheffer, et al. Informational [Page 11] + +RFC 6124 The EAP-EKE Method February 2011 + + +4.2.4. The EAP-EKE-Failure Payload + + The EAP-EKE-Failure payload format is defined as follows: + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Failure-Code | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 6: EAP-EKE-Failure Payload + + The payload's size is always exactly 4 octets. + + The following Failure-Code values are defined: + + +------------+----------------+-------------------------------------+ + | Value | Name | Meaning | + +------------+----------------+-------------------------------------+ + | 0x00000000 | Reserved | | + | 0x00000001 | No Error | This code is used for failure | + | | | acknowledgement, see below. | + | 0x00000002 | Protocol Error | A failure to parse or understand a | + | | | protocol message or one of its | + | | | payloads. | + | 0x00000003 | Password Not | A password could not be located for | + | | Found | the identity presented by the other | + | | | protocol party, making | + | | | authentication impossible. | + | 0x00000004 | Authentication | Failure in the cryptographic | + | | Failure | computation, most likely caused by | + | | | an incorrect password or an | + | | | inappropriate identity type. | + | 0x00000005 | Authorization | While the password being used is | + | | Failure | correct, the user is not authorized | + | | | to connect. | + | 0x00000006 | No Proposal | The peer is unwilling to select any | + | | Chosen | of the cryptographic proposals | + | | | offered by the server. | + +------------+----------------+-------------------------------------+ + + Additional values of this field are available via IANA registration, + see Section 7.8. + + When the peer encounters an error situation, it MUST respond with + EAP-EKE-Failure. The server MUST reply with an EAP-Failure message + to end the exchange. + + + + + +Sheffer, et al. Informational [Page 12] + +RFC 6124 The EAP-EKE Method February 2011 + + + When the server encounters an error situation, it MUST respond with + EAP-EKE-Failure. The peer MUST send back an EAP-EKE-Failure message + containing a "No Error" failure code. Then the server MUST send an + EAP-Failure message to end the exchange. + + Implementation of the "Password Not Found" code is not mandatory. + For security reasons, implementations MAY choose to return + "Authentication Failure" also in cases where the password cannot be + located. + +4.3. Protected Fields + + Several fields are encrypted and integrity-protected. They are + denoted Prot(...). Their general structure is as follows: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Initialization Vector (IV) (optional) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Encrypted Data ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ | Random Padding | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Integrity Check Value (ICV) | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 7: Protected Field Structure + + The protected field is a concatenation of three octet strings: + + o An optional IV, required when the encryption algorithm/mode + necessitates it, e.g., for CBC encryption. The content and size + of this field are determined by the selected encryption algorithm. + In the case of CBC encryption, this field is a random octet string + having the same size as the algorithm's block size. + + o The original data, followed if necessary by random padding. This + padding has the minimal length (possibly zero) required to + complete the length of the encrypted data to the encryption + algorithm's block size. The original data and the padding are + encrypted together. + + + + + + + +Sheffer, et al. Informational [Page 13] + +RFC 6124 The EAP-EKE Method February 2011 + + + o ICV, a Message Authentication Code (MAC) cryptographic checksum of + the encrypted data, including the padding. The checksum is + computed over the encrypted, rather than the plaintext, data. Its + length is determined by the MAC algorithm negotiated. + + We note that because of the requirement for an explicit ICV, this + specification does not support authenticated encryption algorithms. + Such algorithms may be added by a future extension. + +4.4. Encrypted Fields + + Two fields are encrypted but are not integrity protected. They are + denoted Encr(...). Their format is identical to a protected field + (Section 4.3), except that the Integrity Check Value is omitted. + +4.5. Channel Binding Values + + This protocol allows higher-level protocols to transmit limited + opaque information between the peer and the server. This information + is integrity protected but not encrypted, and may be used to ensure + that protocol participants are identical at different protocol + layers. See Section 7.15 of [RFC3748] for more information on the + rationale behind this facility. + + EAP-EKE neither validates nor makes any use of the transmitted + information. The information MUST NOT be used by the consumer + protocol until it is verified in the EAP-EKE-Confirm exchange + (specifically, until it is integrity protected by the Auth_S, Auth_P + payloads). Consequently, it MUST NOT be relied upon in case an error + occurs at the EAP-EKE level. + + An unknown Channel Binding Value SHOULD be ignored by the recipient. + + Some implementations may require certain values to be present, and + will abort the protocol if they are not. Such policy is out of scope + of the current protocol. + + + + + + + + + + + + + + + +Sheffer, et al. Informational [Page 14] + +RFC 6124 The EAP-EKE Method February 2011 + + + Each Channel Binding Value is encoded using a TLV structure: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | CBType | Length | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Value ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 8: Channel Binding Value + + CBType: + + This is the Channel Binding Value's type. This document defines + the value 0x0000 as reserved. Other values are available for IANA + allocation, see Section 7.6. + + Length: + + This field is the total length in octets of the structure, + including the CBType and Length fields. + + This facility should be used with care, since EAP-EKE does not + provide for message fragmentation. EAP-EKE is not a tunneled method + and should not be used as a generic transport; specifically, + implementors should refrain from using the Channel Binding facility + to transmit posture information, in the sense of [RFC5209]. + +5. Protocol Sequence + + This section describes the sequence of messages for the Commit and + Confirm exchanges, and lists the cryptographic operations performed + by the server and the peer. + +5.1. EAP-EKE-Commit/Request + + The server computes: + + y_s = g ^ x_s (mod p), + + where x_s is a randomly chosen number in the range 2 .. p-1. The + randomly chosen number is the ephemeral private key, and the + calculated value is the corresponding ephemeral public key. The + server and the peer MUST both use a fresh, random value for x_s and + the corresponding x_p on each run of the protocol. + + + + + +Sheffer, et al. Informational [Page 15] + +RFC 6124 The EAP-EKE Method February 2011 + + + The server computes and transmits the encrypted field (Section 4.4) + + temp = prf(0+, password) + + key = prf+(temp, ID_S | ID_P) + + DHComponent_S = Encr(key, y_s). + + See Section 6.1 for the prf+ notation. The first argument to "prf" + is a string of zero octets whose length is the output size of the + base hash algorithm, e.g., 20 octets for HMAC-SHA1; the result is of + the same length. The first output octets of prf+ are used as the + encryption key for the negotiated encryption algorithm, according to + that algorithm's key length. + + Since the PRF function is required to be an application of the HMAC + operator to a hash function, the above construction implements HKDF + as defined in [RFC5869]. + + When using block ciphers, it may be necessary to pad y_s on the + right, to fit the encryption algorithm's block size. In such cases, + random padding MUST be used, and this randomness is critical to the + security of the protocol. Randomness recommendations can be found in + [RFC4086]; also see [NIST.800-90.2007] for additional recommendations + on cryptographic-level randomness. When decrypting this field, the + real length of y_s is determined according to the negotiated Diffie- + Hellman group. + + If the password needs to be stored on the server, it is RECOMMENDED + to store a randomized password value as a password-equivalent, rather + than the cleartext password. We note that implementations may choose + the output of either of the two steps of the password derivation. + Using the output of the second step, where the password is salted by + the identity values, is more secure; however, it may create an + operational issue if identities are likely to change. See also + Section 8.5. + + This protocol supports internationalized, non-ASCII passwords. The + input password string SHOULD be processed according to the rules of + the [RFC4013] profile of [RFC3454]. A password SHOULD be considered + a "stored string" per [RFC3454], and unassigned code points are + therefore prohibited. The output is the binary representation of the + processed UTF-8 [RFC3629] character string. Prohibited output and + unassigned code points encountered in SASLprep preprocessing SHOULD + cause a preprocessing failure and the output SHOULD NOT be used. + + + + + + +Sheffer, et al. Informational [Page 16] + +RFC 6124 The EAP-EKE Method February 2011 + + +5.2. EAP-EKE-Commit/Response + + The peer computes: + + y_p = g ^ x_p (mod p) + + Then computes: + + temp = prf(0+, password) + + key = prf+(temp, ID_S | ID_P) + + DHComponent_P = Encr(key, y_p) + + formatted as an encrypted field (Section 4.4). + + Both sides calculate + + SharedSecret = prf(0+, g ^ (x_s * x_p) (mod p)) + + The first argument to "prf" is a string of zero octets whose length + is the output size of the base hash algorithm, e.g., 20 octets for + HMAC-SHA1; the result is of the same length. This extra application + of the pseudo-random function is the "extraction step" of [RFC5869]. + Note that the peer needs to compute the SharedSecret value before + sending out its response. + + The encryption and integrity protection keys are computed: + + Ke | Ki = prf+(SharedSecret, "EAP-EKE Keys" | ID_S | ID_P) + + And the peer generates the Protected Nonce: + + PNonce_P = Prot(Ke, Ki, Nonce_P), + + where Nonce_P is a randomly generated binary string. The length of + Nonce_P MUST be the maximum of 16 octets, and half the key size of + the negotiated prf (rounded up to the next octet if necessary). The + peer constructs this value as a protected field (Section 4.3), + encrypted using Ke and integrity protected using Ki with the + negotiated encryption and MAC algorithm. + + The peer now sends a message that contains the two generated fields. + + The server MUST verify the correct integrity protection of the + received nonce, and MUST abort the protocol if it is incorrect, with + an "Authentication Failure" code. + + + + +Sheffer, et al. Informational [Page 17] + +RFC 6124 The EAP-EKE Method February 2011 + + +5.3. EAP-EKE-Confirm/Request + + The server constructs: + + PNonce_PS = Prot(Ke, Ki, Nonce_P | Nonce_S), + + as a protected field, where Nonce_S is a randomly generated string, + of the same size as Nonce_P. + + It computes: + + Ka = prf+(SharedSecret, "EAP-EKE Ka" | ID_S | ID_P | Nonce_P | + Nonce_S) + + whose length is the preferred key length of the negotiated prf (see + Section 5.2). It then constructs: + + Auth_S = prf(Ka, "EAP-EKE server" | EAP-EKE-ID/Request | EAP-EKE- + ID/Response | EAP-EKE-Commit/Request | EAP-EKE-Commit/Response). + + The messages are included in full, starting with the EAP header, and + including any possible future extensions. + + This construction of the Auth_S (and Auth_P) value implies that any + future extensions MUST NOT be added to the EAP-EKE-Confirm/Request or + EAP-EKE-Confirm/Response messages themselves, unless these extensions + are integrity-protected in some other manner. + + The server now sends a message that contains the two fields. + + The peer MUST verify the correct integrity protection of the received + nonces and the correctness of the Auth_S value, and MUST abort the + protocol if either is incorrect, with an "Authentication Failure" + code. + +5.4. EAP-EKE-Confirm/Response + + The peer computes Ka, and generates: + + PNonce_S = Prot(Ke, Ki, Nonce_S) + + as a protected field. It then computes: + + Auth_P = prf(Ka, "EAP-EKE peer" | EAP-EKE-ID/Request | EAP-EKE-ID/ + Response | EAP-EKE-Commit/Request | EAP-EKE-Commit/Response) + + The peer sends a message that contains the two fields. + + + + +Sheffer, et al. Informational [Page 18] + +RFC 6124 The EAP-EKE Method February 2011 + + + The server MUST verify the correct integrity protection of the + received nonce and the correctness of the Auth_P value, and MUST + abort the protocol if either is incorrect, with an "Authentication + Failure" code. + +5.5. MSK and EMSK + + Following the last message of the protocol, both sides compute and + export the shared keys, each 64 bytes in length: + + MSK | EMSK = prf+(SharedSecret, "EAP-EKE Exported Keys" | ID_S | + ID_P | Nonce_P | Nonce_S) + + When the RADIUS attributes specified in [RFC2548] are used to + transport keying material, then the first 32 bytes of the MSK + correspond to MS-MPPE-RECV-KEY and the second 32 bytes to MS-MPPE- + SEND-KEY. In this case, only 64 bytes of keying material (the MSK) + are used. + + At this point, both protocol participants MUST discard all + intermediate cryptographic values, including x_p, x_s, y_p, y_s, Ke, + Ki, Ka, and SharedSecret. Similarly, both parties MUST immediately + discard these values whenever the protocol terminates with a failure + code or as a result of timeout. + +6. Cryptographic Details + +6.1. Generating Keying Material + + Keying material is derived as the output of the negotiated pseudo- + random function (prf) algorithm. Since the amount of keying material + needed may be greater than the size of the output of the prf + algorithm, we will use the prf iteratively. We denote by "prf+" the + function that outputs a pseudo-random stream based on the inputs to a + prf as follows (where "|" indicates concatenation): + + prf+ (K, S) = T1 | T2 | T3 | T4 | ... + + where: + + T1 = prf(K, S | 0x01) + + T2 = prf(K, T1 | S | 0x02) + + T3 = prf(K, T2 | S | 0x03) + + T4 = prf(K, T3 | S | 0x04) + + + + +Sheffer, et al. Informational [Page 19] + +RFC 6124 The EAP-EKE Method February 2011 + + + continuing as needed to compute all required keys. The keys are + taken from the output string without regard to boundaries (e.g., if + the required keys are a 256-bit Advanced Encryption Standard (AES) + key and a 160-bit HMAC key, and the prf function generates 160 bits, + the AES key will come from T1 and the beginning of T2, while the HMAC + key will come from the rest of T2 and the beginning of T3). + + The constant concatenated to the end of each string feeding the prf + is a single octet. In this document, prf+ is not defined beyond 255 + times the size of the prf output. + +6.2. Diffie-Hellman Groups + + Many of the commonly used Diffie-Hellman groups are inappropriate for + use in EKE. Most of these groups use a generator that is not a + primitive element of the group. As a result, an attacker running a + dictionary attack would be able to learn at least 1 bit of + information for each decrypted password guess. + + Any MODP Diffie-Hellman group defined for use in this protocol MUST + have the following properties to ensure that it does not leak a + usable amount of information about the password: + + 1. The generator is a primitive element of the group. + + 2. The most significant 64 bits of the prime number are 1. + + 3. The group's order p is a "safe prime", i.e., (p-1)/2 is also + prime. + + The last requirement is related to the strength of the Diffie-Hellman + algorithm, rather than the password encryption. It also makes it + easy to verify that the generator is primitive. + + Suitable groups are defined in Section 7.1. + +6.3. Mandatory Algorithms + + To facilitate interoperability, the following algorithms are + mandatory to implement: + + o ENCR_AES128_CBC (encryption algorithm) + + o PRF_HMAC_SHA1 (pseudo-random function) + + o MAC_HMAC_SHA1 (keyed message digest) + + o DHGROUP_EKE_14 (DH-group) + + + +Sheffer, et al. Informational [Page 20] + +RFC 6124 The EAP-EKE Method February 2011 + + +7. IANA Considerations + + IANA has allocated the EAP method type 53 from the range 1-191, for + "EAP-EKE Version 1". + + Per this document, IANA created the registries described in the + following sub-sections. Values (other than private-use ones) can be + added to these registries per Specification Required [RFC5226], with + two exceptions: the Exchange and Failure Code registries can only be + extended per RFC Required [RFC5226]. + +7.1. Diffie-Hellman Group Registry + + This section defines an IANA registry for Diffie-Hellman groups. + + This table defines the initial contents of this registry. The Value + column is used when negotiating the group. Additional groups may be + defined through IANA allocation. Any future specification that + defines a non-MODP group MUST specify its use within EAP-EKE and MUST + demonstrate the group's security in this context. + + +-----------------+---------+---------------------------------------+ + | Name | Value | Description | + +-----------------+---------+---------------------------------------+ + | Reserved | 0 | | + | DHGROUP_EKE_2 | 1 | The prime number of the 1024-bit | + | | | Group 2 [RFC5996], with the generator | + | | | 5 (decimal) | + | DHGROUP_EKE_5 | 2 | The prime number of the 1536-bit | + | | | Group 5 [RFC3526], g=31 | + | DHGROUP_EKE_14 | 3 | The prime number of the 2048-bit | + | | | Group 14 [RFC3526], g=11 | + | DHGROUP_EKE_15 | 4 | The prime number of the 3072-bit | + | | | Group 15 [RFC3526], g=5 | + | DHGROUP_EKE_16 | 5 | The prime number of the 4096-bit | + | | | Group 16 [RFC3526], g=5 | + | Available for | 6-127 | | + | allocation via | | | + | IANA | | | + | Reserved for | 128-255 | | + | Private Use | | | + +-----------------+---------+---------------------------------------+ + + + + + + + + + +Sheffer, et al. Informational [Page 21] + +RFC 6124 The EAP-EKE Method February 2011 + + +7.2. Encryption Algorithm Registry + + This section defines an IANA registry for encryption algorithms: + + +-----------------+---------+-----------------------------------+ + | Name | Value | Definition | + +-----------------+---------+-----------------------------------+ + | Reserved | 0 | | + | ENCR_AES128_CBC | 1 | AES with a 128-bit key, CBC mode | + | | 2-127 | Available for allocation via IANA | + | | 128-255 | Reserved for Private Use | + +-----------------+---------+-----------------------------------+ + +7.3. Pseudo-Random Function Registry + + This section defines an IANA registry for pseudo-random function + algorithms: + + +-------------------+---------+-------------------------------------+ + | Name | Value | Definition | + +-------------------+---------+-------------------------------------+ + | Reserved | 0 | | + | PRF_HMAC_SHA1 | 1 | HMAC SHA-1, as defined in [RFC2104] | + | PRF_HMAC_SHA2_256 | 2 | HMAC SHA-2-256 [SHA] | + | | 3-127 | Available for allocation via IANA | + | | 128-255 | Reserved for Private Use | + +-------------------+---------+-------------------------------------+ + + A pseudo-random function takes two parameters K and S (the key and + input string respectively), and, to be usable in this protocol, must + be defined for all lengths of K between 0 and 65,535 bits + (inclusive). + + Any future pseudo-random function MUST be based on the HMAC + construct, since the security of HKDF is only known for such + functions. + + + + + + + + + + + + + + + +Sheffer, et al. Informational [Page 22] + +RFC 6124 The EAP-EKE Method February 2011 + + +7.4. Keyed Message Digest (MAC) Registry + + This section defines an IANA registry for keyed message digest + algorithms: + + +-------------------+---------+--------------+----------------------+ + | Name | Value | Key Length | Definition | + | | | (Octets) | | + +-------------------+---------+--------------+----------------------+ + | Reserved | 0 | | | + | MAC_HMAC_SHA1 | 1 | 20 | HMAC SHA-1, as | + | | | | defined in [RFC2104] | + | MAC_HMAC_SHA2_256 | 2 | 32 | HMAC SHA-2-256 | + | Reserved | 3-127 | | Available for | + | | | | allocation via IANA | + | Reserved | 128-255 | | Reserved for Private | + | | | | Use | + +-------------------+---------+--------------+----------------------+ + +7.5. Identity Type Registry + + This section defines an IANA registry for identity types: + + +-----------+---------+---------------------------------------------+ + | Name | Value | Definition | + +-----------+---------+---------------------------------------------+ + | Reserved | 0 | | + | ID_OPAQUE | 1 | An opaque octet string | + | ID_NAI | 2 | A Network Access Identifier, as defined in | + | | | [RFC4282] | + | ID_IPv4 | 3 | An IPv4 address, in binary format | + | ID_IPv6 | 4 | An IPv6 address, in binary format | + | ID_FQDN | 5 | A fully qualified domain name, see note | + | | | below | + | ID_DN | 6 | An LDAP Distinguished Name formatted as a | + | | | string, as defined in [RFC4514] | + | | 7-127 | Available for allocation via IANA | + | | 128-255 | Reserved for Private Use | + +-----------+---------+---------------------------------------------+ + + An example of an ID_FQDN is "example.com". The string MUST NOT + contain any terminators (e.g., NULL, CR, etc.). All characters in + the ID_FQDN are ASCII; for an internationalized domain name, the + syntax is as defined in [RFC5891], for example + "xn--tmonesimerkki-bfbb.example.net". + + + + + + +Sheffer, et al. Informational [Page 23] + +RFC 6124 The EAP-EKE Method February 2011 + + +7.6. EAP-EKE Channel Binding Type Registry + + This section defines an IANA registry for the Channel Binding Type + registry, a 16-bit long code. The value 0x0000 has been defined as + Reserved. All other values up to and including 0xfeff are available + for allocation via IANA. The remaining values up to and including + 0xffff are available for Private Use. + +7.7. Exchange Registry + + This section defines an IANA registry for the EAP-EKE Exchange + registry, an 8-bit long code. Initial values are defined in + Section 4.1. All values up to and including 0x7f are available for + allocation via IANA. The remaining values up to and including 0xff + are available for private use. + +7.8. Failure-Code Registry + + This section defines an IANA registry for the Failure-Code registry, + a 32-bit long code. Initial values are defined in Section 4.2.4. + All values up to and including 0xfeffffff are available for + allocation via IANA. The remaining values up to and including + 0xffffffff are available for private use. + +8. Security Considerations + + Any protocol that claims to solve the problem of password- + authenticated key exchange must be resistant to active, passive, and + dictionary attack and have the quality of forward secrecy. These + characteristics are discussed further in the following paragraphs. + + Resistance to Passive Attack: A passive attacker is one that merely + relays messages back and forth between the peer and server, + faithfully, and without modification. The contents of the + messages are available for inspection, but that is all. To + achieve resistance to passive attack, such an attacker must not be + able to obtain any information about the password or anything + about the resulting shared secret from watching repeated runs of + the protocol. Even if a passive attacker is able to learn the + password, she will not be able to determine any information about + the resulting secret shared by the peer and server. + + Resistance to Active Attack: An active attacker is able to modify, + add, delete, and replay messages sent between protocol + participants. For this protocol to be resistant to active attack, + the attacker must not be able to obtain any information about the + password or the shared secret by using any of its capabilities. + In addition, the attacker must not be able to fool a protocol + + + +Sheffer, et al. Informational [Page 24] + +RFC 6124 The EAP-EKE Method February 2011 + + + participant into thinking that the protocol completed + successfully. It is always possible for an active attacker to + deny delivery of a message critical in completing the exchange. + This is no different than dropping all messages and is not an + attack against the protocol. + + Resistance to Dictionary Attack: For this protocol to be resistant + to dictionary attack, any advantage an adversary can gain must be + directly related to the number of interactions she makes with an + honest protocol participant and not through computation. The + adversary will not be able to obtain any information about the + password except whether a single guess from a single protocol run + is correct or incorrect. + + Forward Secrecy: Compromise of the password must not provide any + information about the secrets generated by earlier runs of the + protocol. + + [RFC3748] requires that documents describing new EAP methods clearly + articulate the security properties of the method. In addition, for + use with wireless LANs, [RFC4017] mandates and recommends several of + these. The claims are: + + 1. Mechanism: password. + + 2. Claims: + + * Mutual authentication: the peer and server both authenticate + each other by proving possession of a shared password. This + is REQUIRED by [RFC4017]. + + * Forward secrecy: compromise of the password does not reveal + the secret keys (MSK and EMSK) from earlier runs of the + protocol. + + * Replay protection: an attacker is unable to replay messages + from a previous exchange either to learn the password or a key + derived by the exchange. Similarly, the attacker is unable to + induce either the peer or server to believe the exchange has + successfully completed when it hasn't. + + * Key derivation: a shared secret is derived by performing a + group operation in a finite cyclic group (e.g., + exponentiation) using secret data contributed by both the peer + and server. An MSK and EMSK are derived from that shared + secret. This is REQUIRED by [RFC4017]. + + + + + +Sheffer, et al. Informational [Page 25] + +RFC 6124 The EAP-EKE Method February 2011 + + + * Dictionary attack resistance: an attacker can only make one + password guess per active attack, and the protocol is designed + so that the attacker does not gain any confirmation of her + guess by observing the decrypted y_s or y_p value (see below). + The advantage she can gain is through interaction not through + computation. This is REQUIRED by [RFC4017]. + + * Session independence: this protocol is resistant to active and + passive attacks and does not enable compromise of subsequent + or prior MSKs or EMSKs from either passive or active attacks. + + * Denial-of-service resistance: it is possible for an attacker + to cause a server to allocate state and consume CPU. Such an + attack is gated, though, by the requirement that the attacker + first obtain connectivity through a lower-layer protocol + (e.g., 802.11 authentication followed by 802.11 association, + or 802.3 "link-up") and respond to two EAP messages: the + EAP-ID/Request and the EAP-EKE-ID/Request. + + * Man-in-the-Middle Attack resistance: this exchange is + resistant to active attack, which is a requirement for + launching a man-in-the-middle attack. This is REQUIRED by + [RFC4017]. + + * Shared state equivalence: upon completion of EAP-EKE, the peer + and server both agree on the MSK and EMSK values. The peer + has authenticated the server based on the Server_ID and the + server has authenticated the peer based on the Peer_ID. This + is due to the fact that Peer_ID, Server_ID, and the generated + shared secret are all combined to make the authentication + element that must be shared between the peer and server for + the exchange to complete. This is REQUIRED by [RFC4017]. + + * Fragmentation: this protocol does not define a technique for + fragmentation and reassembly. + + * Resistance to "Denning-Sacco" attack: learning keys + distributed from an earlier run of the protocol, such as the + MSK or EMSK, will not help an adversary learn the password. + + 3. Key strength: the strength of the resulting key depends on the + finite cyclic group chosen. Sufficient key strength is REQUIRED + by [RFC4017]. Clearly, "sufficient" strength varies over time, + depending on computation power assumed to be available to + potential attackers. + + + + + + +Sheffer, et al. Informational [Page 26] + +RFC 6124 The EAP-EKE Method February 2011 + + + 4. Key hierarchy: MSKs and EMSKs are derived from the secret values + generated during the protocol run, using a negotiated pseudo- + random function. + + 5. Vulnerabilities (note that none of these are REQUIRED by + [RFC4017]): + + * Protected ciphersuite negotiation: the ciphersuite proposal + made by the server is not protected from tampering by an + active attacker. However, if a proposal was modified by an + active attacker, it would result in a failure to confirm the + message sent by the other party, since the proposal is bound + by each side into its Confirm message, and the protocol would + fail as a result. Note that this assumes that none of the + proposed ciphersuites enables an attacker to perform real-time + cryptanalysis. + + * Confidentiality: none of the messages sent in this protocol + are encrypted, though many of the protocol fields are. + + * Integrity protection: protocol messages are not directly + integrity protected; however, the ID and Commit exchanges are + integrity protected through the Auth payloads exchanged in the + Confirm exchange. + + * Channel binding: this protocol enables the exchange of + integrity-protected channel information that can be compared + with values communicated via out-of-band mechanisms. + + * Fast reconnect: this protocol does not provide a fast + reconnect capability. + + * Cryptographic binding: this protocol is not a tunneled EAP + method and therefore has no cryptographic information to bind. + + * Identity protection: the EAP-EKE-ID exchange is not protected. + An attacker will see the server's identity in the EAP-EKE-ID/ + Request and see the peer's identity in EAP-EKE-ID/Response. + See also Section 8.4. + +8.1. Cryptographic Analysis + + When analyzing the Commit exchange, it should be noted that the base + security assumptions are different from "normal" cryptology. + Normally, we assume that the key has strong security properties, and + that the data may have few or none. Here, we assume that the key has + weak security properties (the attacker may have a list of possible + keys), and hence we need to ensure that the data has strong + + + +Sheffer, et al. Informational [Page 27] + +RFC 6124 The EAP-EKE Method February 2011 + + + properties (indistinguishable from random). This difference may mean + that conventional wisdom in cryptology might not apply in this case. + This also imposes severe constraints on the protocol, e.g., the + mandatory use of random padding and the need to define specific + finite groups. + +8.2. Diffie-Hellman Group Considerations + + It is fundamental to the dictionary attack resistance that the + Diffie-Hellman public values y_s and y_p are indistinguishable from a + random string. If this condition is not met, then a passive attacker + can do trial-decryption of the encrypted DHComponent_P or + DHComponent_S values based on a password guess, and if they decrypt + to a value that is not a valid public value, they know that the + password guess was incorrect. + + For MODP groups, Section 6.2 gives conditions on the group to make + sure that this criterion is met. For other groups (for example, + Elliptic Curve groups), some other means of ensuring this must be + employed. The standard way of expressing Elliptic Curve public + values does not meet this criterion, as a valid Elliptic Curve X + coordinate can be distinguished from a random string with probability + of approximately 0.5. + + A future document might introduce a group representation, and/or a + slight modification of the password encryption scheme, so that + Elliptic Curve groups can be accommodated. [BR02] presents several + alternative solutions for this problem. + +8.3. Resistance to Active Attacks + + An attacker, impersonating either the peer or the server, can always + try to enumerate all possible passwords, for example by using a + dictionary. To counter this likely attack vector, both peer and + server MUST implement rate-limiting mechanisms. We note that locking + out the other party after a small number of tries would create a + trivial denial-of-service opportunity. + +8.4. Identity Protection, Anonymity, and Pseudonymity + + By default, the EAP-EKE-ID exchange is unprotected, and an + eavesdropper can observe both parties' identities. A future + extension of this protocol may support anonymity, e.g., by allowing + the server to send a temporary identity to the peer at the end of the + exchange, so that the peer can use that identity in subsequent + exchanges. + + + + + +Sheffer, et al. Informational [Page 28] + +RFC 6124 The EAP-EKE Method February 2011 + + + EAP-EKE differs in this respect from tunneled methods, which + typically provide unconditional identity protection to the peer by + encrypting the identity exchange, but reveal information in the + server certificate. It is possible to use EAP-EKE as the inner + method in a tunneled EAP method in order to achieve this level of + identity protection. + +8.5. Password Processing and Long-Term Storage + + This document recommends that a password-equivalent (a hash of the + password) be stored instead of the cleartext password. While this + solution provides a measure of security, there are also tradeoffs + related to algorithm agility: + + o Each stored password must identify the hash function that was used + to compute the stored value. + + o Complex deployments and migration scenarios might necessitate + multiple stored passwords, one per each algorithm. + + o Changing the algorithm can require, in some cases, that the users + manually change their passwords. + + The reader is referred to Section 10 of [RFC3629] for security + considerations related to the parsing and processing of UTF-8 + strings. + +9. Acknowledgements + + Much of this document was unashamedly picked from [RFC5931] and + [EAP-SRP], and we would like to acknowledge the authors of these + documents: Dan Harkins, Glen Zorn, James Carlson, Bernard Aboba, and + Henry Haverinen. We would like to thank David Jacobson, Steve + Bellovin, Russ Housley, Brian Weis, Dan Harkins, and Alexey Melnikov + for their useful comments. Lidar Herooty and Idan Ofrat implemented + this protocol and helped us improve it by asking the right questions, + and we would like to thank them both. + +10. References + +10.1. Normative References + + [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: + Keyed-Hashing for Message Authentication", + RFC 2104, February 1997. + + + + + + +Sheffer, et al. Informational [Page 29] + +RFC 6124 The EAP-EKE Method February 2011 + + + [RFC2119] Bradner, S., "Key words for use in RFCs to + Indicate Requirement Levels", BCP 14, RFC 2119, + March 1997. + + [RFC2548] Zorn, G., "Microsoft Vendor-specific RADIUS + Attributes", RFC 2548, March 1999. + + [RFC3454] Hoffman, P. and M. Blanchet, "Preparation of + Internationalized Strings ("stringprep")", + RFC 3454, December 2002. + + [RFC3526] Kivinen, T. and M. Kojo, "More Modular + Exponential (MODP) Diffie-Hellman groups for + Internet Key Exchange (IKE)", RFC 3526, May 2003. + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of + ISO 10646", STD 63, RFC 3629, November 2003. + + [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, + J., and H. Levkowetz, "Extensible Authentication + Protocol (EAP)", RFC 3748, June 2004. + + [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for + User Names and Passwords", RFC 4013, + February 2005. + + [RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, + "The Network Access Identifier", RFC 4282, + December 2005. + + [RFC4514] Zeilenga, K., "Lightweight Directory Access + Protocol (LDAP): String Representation of + Distinguished Names", RFC 4514, June 2006. + + [RFC5891] Klensin, J., "Internationalized Domain Names in + Applications (IDNA): Protocol", RFC 5891, + August 2010. + + [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, + "Internet Key Exchange Protocol Version 2 + (IKEv2)", RFC 5996, September 2010. + + [SHA] National Institute of Standards and Technology, + U.S. Department of Commerce, "Secure Hash + Standard", NIST FIPS 180-3, October 2008. + + + + + + +Sheffer, et al. Informational [Page 30] + +RFC 6124 The EAP-EKE Method February 2011 + + +10.2. Informative References + + [BM92] Bellovin, S. and M. Merritt, "Encrypted Key + Exchange: Password-Based Protocols Secure Against + Dictionary Attacks", Proc. IEEE Symp. on Research + in Security and Privacy , May 1992. + + [BM93] Bellovin, S. and M. Merritt, "Augmented Encrypted + Key Exchange: A Password-Based Protocol Secure + against Dictionary Attacks and Password File + Compromise", Proc. 1st ACM Conference on Computer + and Communication Security , 1993. + + [BMP00] Boyko, V., MacKenzie, P., and S. Patel, "Provably + Secure Password Authenticated Key Exchange Using + Diffie-Hellman", Advances in Cryptology, + EUROCRYPT 2000 , 2000. + + [BR02] Black, J. and P. Rogaway, "Ciphers with Arbitrary + Finite Domains", Proc. of the RSA Cryptographer's + Track (RSA CT '02), LNCS 2271 , 2002. + + [EAP-SRP] Carlson, J., Aboba, B., and H. Haverinen, "EAP + SRP-SHA1 Authentication Protocol", Work + in Progress, July 2001. + + [JAB96] Jablon, D., "Strong Password-Only Authenticated + Key Exchange", ACM Computer Communications + Review Volume 1, Issue 5, October 1996. + + [LUC97] Lucks, S., "Open Key Exchange: How to Defeat + Dictionary Attacks Without Encrypting Public + Keys", Proc. of the Security Protocols + Workshop LNCS 1361, 1997. + + [NIST.800-90.2007] National Institute of Standards and Technology, + "Recommendation for Random Number Generation + Using Deterministic Random Bit Generators + (Revised)", NIST SP 800-90, March 2007. + + [PA97] Patel, S., "Number Theoretic Attacks On Secure + Password Schemes", Proceedings of the 1997 IEEE + Symposium on Security and Privacy , 1997. + + [RFC4017] Stanley, D., Walker, J., and B. Aboba, + "Extensible Authentication Protocol (EAP) Method + Requirements for Wireless LANs", RFC 4017, + March 2005. + + + +Sheffer, et al. Informational [Page 31] + +RFC 6124 The EAP-EKE Method February 2011 + + + [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, + RFC 4086, June 2005. + + [RFC5209] Sangster, P., Khosravi, H., Mani, M., Narayan, + K., and J. Tardo, "Network Endpoint Assessment + (NEA): Overview and Requirements", RFC 5209, + June 2008. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for + Writing an IANA Considerations Section in RFCs", + BCP 26, RFC 5226, May 2008. + + [RFC5869] Krawczyk, H. and P. Eronen, "HMAC-based Extract- + and-Expand Key Derivation Function (HKDF)", + RFC 5869, May 2010. + + [RFC5931] Harkins, D. and G. Zorn, "Extensible + Authentication Protocol (EAP) Authentication + Using Only a Password", RFC 5931, August 2010. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Sheffer, et al. Informational [Page 32] + +RFC 6124 The EAP-EKE Method February 2011 + + +Authors' Addresses + + Yaron Sheffer + Independent + + EMail: yaronf.ietf@gmail.com + + + Glen Zorn + Network Zen + 227/358 Thanon Sanphawut + Bang Na, Bangkok 10260 + Thailand + + Phone: +66 (0) 87-040-4617 + EMail: gwz@net-zen.net + + + Hannes Tschofenig + Nokia Siemens Networks + Linnoitustie 6 + Espoo 02600 + Finland + + Phone: +358 (50) 4871445 + EMail: Hannes.Tschofenig@gmx.net + URI: http://www.tschofenig.priv.at + + + Scott Fluhrer + Cisco Systems. + 1414 Massachusetts Ave. + Boxborough, MA 01719 + USA + + EMail: sfluhrer@cisco.com + + + + + + + + + + + + + + + +Sheffer, et al. Informational [Page 33] + |