Network Working Group V. Cakulev Internet-Draft Alcatel Lucent Intended status: Informational I. Broustis Expires: February 21, 2013 AT&T Labs Research August 20, 2012 An EAP Authentication Method Based on Identity-Based Authenticated Key Exchange draft-cakulev-emu-eap-ibake-03.txt Abstract The Extensible Authentication Protocol (EAP) is an authentication framework which supports multiple authentication methods. This document defines an authentication method for EAP called EAP-IBAKE, which is based on the Identity-Based Authenticated Key Exchange (IBAKE) protocol. The IBAKE method provides mutual authentication through the use of identity-based encryption. In addition to mutual authentication this method also provides perfect forward and backwards secrecy. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 21, 2013. Copyright Notice Copyright (c) 2012 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 Cakulev & Broustis Expires February 21, 2013 [Page 1] Internet-Draft The EAP-IBAKE Method August 2012 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. Cakulev & Broustis Expires February 21, 2013 [Page 2] Internet-Draft The EAP-IBAKE Method August 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Requirements notation . . . . . . . . . . . . . . . . . . 5 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5 3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 6 3.1. Message Flows . . . . . . . . . . . . . . . . . . . . . . 6 4. Protocol Sequence . . . . . . . . . . . . . . . . . . . . . . 9 4.1. IBAKE-ID Exchange . . . . . . . . . . . . . . . . . . . . 9 4.2. EAP-Request/IBAKE-Challenge . . . . . . . . . . . . . . . 9 4.3. EAP-Response/IBAKE-Challenge . . . . . . . . . . . . . . . 10 4.4. EAP-Request/IBAKE-Confirm . . . . . . . . . . . . . . . . 10 4.5. EAP-Response/IBAKE-Confirm . . . . . . . . . . . . . . . . 11 4.6. MSK and EMSK . . . . . . . . . . . . . . . . . . . . . . . 11 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. EAP-IBAKE Header . . . . . . . . . . . . . . . . . . . . . 13 5.2. EAP-IBAKE Payloads . . . . . . . . . . . . . . . . . . . . 14 5.2.1. The IBAKE-ID Payload . . . . . . . . . . . . . . . . . 14 5.2.2. The IBAKE-Challenge Payload . . . . . . . . . . . . . 15 5.2.3. The IBAKE-Confirm Payload . . . . . . . . . . . . . . 16 5.2.4. The IBAKE-Failure Payload . . . . . . . . . . . . . . 17 5.2.5. Channel Binding Values . . . . . . . . . . . . . . . . 18 6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7.1. Elliptic Curve Registry . . . . . . . . . . . . . . . . . 21 7.2. Pseudo Random Function Registry . . . . . . . . . . . . . 21 7.3. Identity Type Registry . . . . . . . . . . . . . . . . . . 22 7.4. EAP-IBAKE Channel Binding Type Registry . . . . . . . . . 22 7.5. Exchange Registry . . . . . . . . . . . . . . . . . . . . 23 7.6. Failure-Code Registry . . . . . . . . . . . . . . . . . . 23 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 8.1. Identity Protection . . . . . . . . . . . . . . . . . . . 24 8.2. Mutual Authentication . . . . . . . . . . . . . . . . . . 24 8.3. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 24 8.4. Brute-Force and Dictionary Attacks . . . . . . . . . . . . 24 8.5. Protection, Replay Protection, and Confidentiality . . . . 25 8.6. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 25 8.7. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 26 8.8. Reflection Attacks . . . . . . . . . . . . . . . . . . . . 26 8.9. Negotiation Attacks . . . . . . . . . . . . . . . . . . . 27 9. Security Claims . . . . . . . . . . . . . . . . . . . . . . . 28 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 10.2. Informative References . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 Cakulev & Broustis Expires February 21, 2013 [Page 3] Internet-Draft The EAP-IBAKE Method August 2012 1. Introduction The Extensible Authentication Protocol (EAP) [RFC3748] provides a standard mechanism for unified support of different authentication methods. EAP has been defined for use with different lower-layer transport methods, such as Point-to-Point Protocol (PPP) [RFC1661], Protocol for Carrying Authentication for Network Access (PANA) [RFC5191], IEEE 802 wired networks [IEEE-802.1X], as well as wireless technologies such as IEEE 802.11 [IEEE-802.11] and IEEE 802.16 [IEEE-802.16]. This document defines a new authentication method for EAP called EAP-Identity Based Authenticated Key Exchange (EAP-IBAKE). IBAKE is a protocol for mutual authentication and key agreement between two or more endpoints. It is structured as a public-key based authentication mechanism, where each message is encrypted with the public key of the corresponding endpoint, as per the Identity Based Encryption (IBE) principles [RFC5091]. As a result of the IBAKE protocol successful execution, a shared symmetric key is generated by each endpoint, which can further be used for securing the communication between the endpoints. IBAKE may be applied in a plurality of deployment scenarios that require generation of a common symmetric key. Hence, IBAKE may be used e.g. for establishing end- to-end secure sessions between peers [RFC6267], or for mutually authenticating a peer with a server and deriving a common key. IBAKE offers multiple benefits in terms of facilitating a simplified public-key based mutual authentication and key agreement procedure, which does not depend on the existence of public key infrastructures and the incurred complexities thereof [RFC6267]. IBAKE achieves secure mutual authentication between the participants, escrow-free key agreement, as well as perfect forward and backwards secrecy [I-D.cakulev-ibake]. This document specifies IBAKE as a method for the Extensible Authentication Protocol (EAP) [RFC3748]. In the EAP setting that is considered in this document, IBAKE is executed between an EAP peer and an EAP server. While IBAKE may be used for mutual authentication and key agreement between more than two participants, such scenarios are outside the scope of this document. Cakulev & Broustis Expires February 21, 2013 [Page 4] Internet-Draft The EAP-IBAKE Method August 2012 2. Terminology 2.1. Requirements notation 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.2. Abbreviations IBE Identity Based Encryption IBAKE Identity Based Authenticated Key Exchange IDp Peer's Identity IDs Server's Identity K_PR Private Key K_PUB Public Key 2.3. Conventions o E is an elliptic curve over a finite field F o P is a point on E of large prime order o [x]P denotes point multiplication on an elliptic curve, i.e. adding a point P to itself total of x times o H1 is a known hash function that takes a string and assigns it to a point on the elliptic curve, i.e., H1(A) = QA on E, where A is usually based on the identity. o Encr(k, A) denotes that A is IBE-encrypted with the key k o s||t denotes concatenation of the strings s and t o K_PUBx denotes Public Key of x Cakulev & Broustis Expires February 21, 2013 [Page 5] Internet-Draft The EAP-IBAKE Method August 2012 3. Protocol Description EAP is a two-party protocol that takes place between an EAP peer and an EAP server (also know as authenticator). An EAP method defines the specific authentication protocol being used by EAP. This document defines IBAKE as the EAP method, i.e., it defines the messages sent between the EAP server and the EAP peer for the purposes of authentication and key derivation. The peer and the server are attempting to mutually authenticate each other and agree on a key using EAP-IBAKE. This specification assumes that the peer and the server trust a third party, the Key Generation Function (KGF). Rather than a single KGF, several different KGFs may be involved, e.g. one for the peer and one for the server. The peer and the server do not share any credentials prior to execution of EAP-IBAKE. This specification also assumes that the peer and the server have securely obtained their respective Private Keys from their respective KGFs prior to EAP-IBAKE message exchange. In addition, the peer and the server obtained or are able to obtain a set of publicly available parameters of each other's KGF. The procedures needed to obtain the private keys and public parameters are outside of scope of this specification. The details for these procedures can be found in [RFC5091] and [RFC5408]. 3.1. Message Flows A successful run of EAP-IBAKE consists of up to three message exchanges: an Identity exchange, a Challenge exchange and a Confirm exchange. This is shown in Figure 1. The peer and the server use the EAP-IBAKE Identity exchange to obtain each other's identities and to agree upon a ciphersuite to use in the subsequent exchanges. In the Challenge exchange the peer and the server exchange information to authenticate each other and also to generate a shared key. In the Confirm exchange the peer and the server complete the authentication by proving the knowledge of valid identity-based private keys. Cakulev & Broustis Expires February 21, 2013 [Page 6] Internet-Draft The EAP-IBAKE Method August 2012 +--------+ +--------+ | | EAP-Request/IBAKE-ID | | | EAP |<------------------------------------| EAP | | peer | | server | | (P) | EAP-Response/IBAKE-ID | (S) | | |------------------------------------>| | | | | | | | EAP-Request/IBAKE-Challenge| | | |<------------------------------------| | | | | | | | EAP-Response/IBAKE-Challenge | | | |------------------------------------>| | | | | | | | EAP-Request/IBAKE-Confirm | | | |<------------------------------------| | | | | | | | EAP-Response/IBAKE-Confirm | | | |------------------------------------>| | | | | | | | EAP-Success | | | |<------------------------------------| | +--------+ +--------+ Figure 1: Successful EAP-IBAKE Exchange The IBAKE exchange, also described in [I-D.cakulev-ibake] is a three- step exchange as follows: Peer Server ---- ------ Encr(K_PUBs, IDp || IDs || [Rp]P) -> <- Encr(K_PUBp, IDp || IDs || [Rp]P || [Rs]P) Encr(K_PUBs, IDp || IDs || [Rs]P) -> Where: o K_PUBp and K_PUBs are the public keys of peer and server, respectively. These public keys are derived from their corresponding identities as follows K_PUBp/s = H1(IDp/s). o Rp and Rs are random integers, chosen by Peer and Server, respectively. Cakulev & Broustis Expires February 21, 2013 [Page 7] Internet-Draft The EAP-IBAKE Method August 2012 The EAP-IBAKE method extends the basic IBAKE protocol such that the regular successful EAP-IBAKE exchange takes place as follows. Message Server Peer --------- -------- ------ ID/Request IDs, CryptoProposals -> ID/Response <- Encr(K_PUBs,IDp), CryptoProposal Challenge/Request Encr(K_PUBp, IDs || IDp || [Rs]P) -> Challenge/Response <- Encr(K_PUBp, IDs || IDp || [Rs]P || [Rp]P) Confirm/Request Encr(K_PUBp, IDs || IDp || [Rp]P), Auth_S -> Confirm/Response <- Auth_P As shown in the exchange above, the following information elements have been added to the original protocol: exchange of identity values for both protocol parties (IDs, IDp), negotiation of cryptographic protocols, signature fields to protect the integrity of the negotiated parameters (Auth_S, Auth_P), and the last message to complete the four-way handshake. Detailed protocol description is provided in the next section while message formats are provided in Section 5. Cakulev & Broustis Expires February 21, 2013 [Page 8] Internet-Draft The EAP-IBAKE Method August 2012 4. Protocol Sequence This section describes the sequence of messages for the ID, Challenge and Confirm exchanges, and lists the operations performed by the server and the peer. 4.1. IBAKE-ID Exchange Initially, the server issues EAP-Request/IBAKE-ID, including its identity (IDs) in the Identity payload and optionally ciphersuite proposals in the Proposal payload. Upon receiving the EAP-Request/ IBAKE-ID message the peer uses the received server's identity to generate the server's public key as follows K_PUBs = H1(IDs). The peer then encrypts its identity as follows Encr(K_PUBs, IDp), and includes it in the Identity payload of the EAP-Response/IBAKE-ID message. Finally, if the EAP-Request/IBAKE-ID contains Proposals payload, the Peer chooses most preferred proposal, and includes it in the Proposal payload of the EAP-Response/IBAKE-ID message. 4.2. EAP-Request/IBAKE-Challenge Upon receiving EAP-Response/IBAKE-ID message, the server SHALL first decrypt the message as specified in [RFC5091] and [RFC5408], and obtain the identity of the peer. The server then selects a random Rs and computes its Elliptic curve Diffie-Hellman value, [Rs]P. The server MUST use a fresh, random value for Rs on each run of the protocol. The server uses the identity of the peer obtained in IBAKE-ID exchange to generate the IBE public key of the peer as follows K_PUBp = H1(IDp). The server then computes the encrypted field (see Section 5.2.2) ECDHComponent_S = Encr(K_PUBp, IDs || IDp || [Rs]P). Cakulev & Broustis Expires February 21, 2013 [Page 9] Internet-Draft The EAP-IBAKE Method August 2012 Finally, the server sends EAP-Request/IBAKE-Challenge message to the peer. 4.3. EAP-Response/IBAKE-Challenge Upon receiving EAP-Request/IBAKE-Challenge message, the peer SHALL first decrypt the message as specified in [RFC5091] and [RFC5408], and obtain [Rs]P. The peer then selects a random Rp and computes its Elliptic curve Diffie-Hellman value, [Rp]P. The peer MUST use a fresh, random value for Rp on each run of the protocol. The peer then computes the encrypted field (see Section 5.2.2) ECDHComponent_P = Encr(K_PUBs, IDs || IDp || [Rs]P || [Rp]P). Finally, the peer sends EAP-Response/IBAKE-Challenge message to the server. At this point both the Server and Peer can generate the session key [Rs][Rp]P using exchanged Elliptic Curve Diffie-Hellman values. The session key as a point on an elliptic curve is then converted into the octet string as specified in [SEC1]. This octet string, K_Session, is then used to generate MSK, EMSK and keys used for protection of IBAKE-Confirm exchange. 4.4. EAP-Request/IBAKE-Confirm Upon receiving EAP-Response/IBAKE-Challenge message, the server SHALL first decrypt the message as specified in [RFC5091] and [RFC5408], and obtain [Rs]P and [Rp]P. The server MUST verify that the received [Rs]P is the same as the one sent in EAP-Request/IBAKE-Challenge message. If it is not the same, the server MUST abort the protocol with an "Authentication Failure" code. Upon successful verification of the received [Rs]P, the server computes the encrypted field ECDHComponent_S = Encr(K_PUBp, IDs || IDp || [Rp]P). The server then computes: Ka = prf(K_Session, "EAP-IBAKE Ka" || IDs || IDp) whose length is the preferred key length of the negotiated pseudo- random function (see Section 5.2). It then constructs: Cakulev & Broustis Expires February 21, 2013 [Page 10] Internet-Draft The EAP-IBAKE Method August 2012 Auth_S = prf(Ka, "EAP-IBAKE server" || EAP-Request/IBAKE-ID || EAP-Response/IBAKE-ID || EAP-Request/IBAKE-Challenge || EAP-Response/IBAKE-Challenge). The messages in Auth_S computation are included in full, starting with the EAP header, and including any possible future extensions. The server then constructs and sends EAP-Request/IBAKE-Confirm message to the peer. 4.5. EAP-Response/IBAKE-Confirm Upon receiving EAP-Request/IBAKE-Confirm message, the peer SHALL first decrypt the message as specified in [RFC5091] and [RFC5408], and obtain [Rp]P. The peer MUST verify that the received [Rp]P is the same as the one sent in EAP-Response/IBAKE-Challenge message. If it is not the same, the peer MUST abort the protocol with an "Authentication Failure" code. The peer also MUST verify the correctness of the Auth_S value, and MUST abort the protocol if incorrect, with an "Authentication Failure" code. Upon successful verification of the received [Rp]P and correctness of the Auth_S value, the peer computes Ka as described above, and constructs: Auth_P = prf(Ka, "EAP-IBAKE peer" || EAP-Request/IBAKE-ID || EAP-Response/IBAKE-ID || EAP-Request/IBAKE-Challenge || EAP-Response/IBAKE-Challenge). The peer sends verification message EAP-Response/IBAKE-Confirm to complete the four-way handshake, including AUTH_P value. Upon receiving the message, the server MUST verify the correctness of the Auth_P value, and MUST abort the protocol if incorrect, with an "Authentication Failure" code. 4.6. MSK and EMSK The authenticated key exchange of EAP-IBAKE generates a shared and authenticated key, K_Session. EAP-IBAKE must export two 512-bit keys, MSK and EMSK. Therefore, following the last message of the protocol, both sides compute and export the shared keys, each 512 bits in length: MSK || EMSK = prf(K_Session, "EAP-IBAKE Exported Keys" || IDs || IDp) Cakulev & Broustis Expires February 21, 2013 [Page 11] Internet-Draft The EAP-IBAKE Method August 2012 At this point, both protocol participants MUST discard all intermediate cryptographic values, including Rs and Rp. Similarly, both parties MUST immediately discard these values whenever the protocol terminates with a failure code or as a result of timeout. Cakulev & Broustis Expires February 21, 2013 [Page 12] Internet-Draft The EAP-IBAKE Method August 2012 5. Message Formats EAP-IBAKE defines new message types, with 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. All multi-octet strings MUST be laid out in network byte order. 5.1. EAP-IBAKE Header The EAP-IBAKE header consists of the standard EAP header (see Section 4 of [RFC3748]), followed by an EAP-IBAKE 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 |L|M| IBAKE-Exch| Total-Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: EAP-IBAKE 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 [TBD by IANA] for EAP-IBAKE version 1. L and M bits: The L bit (Length included) is set to indicate the presence of the two-octet Total-Length field, and MUST be set for the first fragment of a fragmented EAP-IBAKE message or set of messages. The M bit (more fragments) is set on all but the last fragment. The IBAKE-Exch (IBAKE Exchange) field identifies the type of EAP- IBAKE payload encapsulated in the Data field. This document defines the following values for the IBAKE-Exch field: o 0x00: Reserved o 0x01: IBAKE-ID exchange o 0x02: IBAKE-Challenge exchange Cakulev & Broustis Expires February 21, 2013 [Page 13] Internet-Draft The EAP-IBAKE Method August 2012 o 0x03: IBAKE-Confirm exchange o 0x04: IBAKE-Failure message Further values of this IBAKE-Exch field are available via IANA registration. Total-Length: The Total-Length field is two octets in length, and is present only if the L bit is set. This field provides the total length of the EAP-IBAKE message or set of messages that is being fragmented. 5.2. EAP-IBAKE Payloads EAP-IBAKE messages all contain the EAP-IBAKE header and information encoded in a single payload, which differs for each message. This section defines payloads for EAP-IBAKE messages. 5.2.1. The IBAKE-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: IBAKE-ID Payload The IBAKE-ID payload contains the following fields: o NumProposals: The NumProposals field contains the number of Proposal fields subsequently contained in the payload. If in the IBAKE-ID/Request the NumProposals field is set to zero (0) then it is out of scope of this specification how the server and the peer negotiate the elliptic curve and PRF used in the rest of EAP-IBAKE exchange. Otherwise, if in the IBAKE-ID/Request the NumProposals field is not set to zero (0), then in the IBAKE-ID/Response message the NumProposals field MUST be set to one (1). The offered proposals in the Request are listed in priority order, with the most preferable appearing first. The selected proposal in the Response MUST be fully identical with one of the offered proposals. Cakulev & Broustis Expires February 21, 2013 [Page 14] Internet-Draft The EAP-IBAKE Method August 2012 o Proposal: Each proposal consists of three fields, in this order: * Elliptic Curve Description: This field's value is taken from the IANA registry for Elliptic curves defined in Section 7.1. The length of this field is one octet. * PRF: This field's value is taken from the IANA registry for pseudo random functions defined in Section 7.2. The length of this field is one octet. * P: This field contains the 2-dimensional coordinates of the selected point P on the Elliptic Curve. The length of each coordinate in octets depends on the chosen Elliptic Curve. o Reserved: By default, this field MUST be sent as zero, and MUST be ignored by the recipient. o IDType: Denotes the Identity Type. This is taken from the IANA registry defined in Section 7.3. 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. o Identity: The meaning of the Identity field depends on the values of the Code and IDType fields. * IBAKE-ID/Request: server ID * IBAKE-ID/Response: peer ID The length of the Identity field MUST be computed from the Length field in the EAP header. This field, like all other fields in this specification, MUST be octet-aligned. 5.2.2. The IBAKE-Challenge Payload This payload allows both parties send their encrypted ephemeral keys. 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 in IBAKE-Challenge exchange unprotected, but is verified when it is signed by the Auth_S/Auth_P payloads of the IBAKE-Confirm exchange. Cakulev & Broustis Expires February 21, 2013 [Page 15] Internet-Draft The EAP-IBAKE Method August 2012 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ | ECDHComponent_S ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ECDHComponent_P ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ | CBValue (zero or more occurrences) ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Encrypted | fields Figure 4: IBAKE-Challenge Payload The IBAKE-Challenge payload contains the following fields: o ECDHComponent_S/ECDHComponent_P: This field contains Server's/ Peer's IBE-encrypted Elliptic Curve Diffie-Hellman value. The peer's Elliptic Curve Diffie-Hellman value DHComponent_P is included only in the response message (i.e. EAP-Response/ IBAKE-Challenge). ECDHComponent field contains the identities of the server and the peer, as exchanged in IBAKE-ID exchange. o 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 5.2.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. Note that as shown in Figure 4, Identity fields and ECDHComponent fields are IBE-Encrypted. 5.2.3. The IBAKE-Confirm Payload Using this payload, both parties complete the authentication by mutually authenticating each other and generating key material for the EAP consumer protocol. Cakulev & Broustis Expires February 21, 2013 [Page 16] Internet-Draft The EAP-IBAKE Method August 2012 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ | ECDHComponent_P ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ | Auth_S/Auth_P ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ~ ~ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Encrypted | fields Figure 5: IBAKE-Confirm Payload The IBAKE-Confirm payload contains the following fields: o ECDHComponent_P: This field contains the peer's IBE-encrypted Elliptic Curve Diffie-Hellman value. The peer's Elliptic Curve Diffie-Hellman value DHComponent_P is included only in the request message (i.e. EAP-Request/IBAKE-Confirm). ECDHComponent field contains the identities of the server and the peer, as exchanged in IBAKE-ID exchange. o Auth_S/Auth_P: This field contains a signature of the preceding messages, including the Identity and the negotiated fields. This prevents various possible attacks, such as algorithm-downgrade attacks. Auth_S is included only in the request message (i.e. EAP-Request/IBAKE-Confirm), while Auth_P is included only in the response message (i.e. EAP-Response/IBAKE-Confirm). 5.2.4. The IBAKE-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: IBAKE-Failure Payload The payload's size is always exactly 4 octets. The following Failure-Code values are defined: Cakulev & Broustis Expires February 21, 2013 [Page 17] Internet-Draft The EAP-IBAKE Method August 2012 +------------+----------------+-------------------------------------+ | 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 | Authentication | Failure in the cryptographic | | | Failure | computation. | | 0x00000004 | Authorization | While the cryptographic computation | | | Failure | is correct, the user is not | | | | authorized to connect. | | 0x00000005 | 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. When the peer encounters an error situation, it MUST send IBAKE- Failure. The server MUST reply with an EAP-Failure message to end the exchange. When the server encounters an error situation, it MUST send IBAKE- Failure. The peer MUST send back IBAKE-Failure message containing a "No Error" failure code. Then the server MUST send an EAP-Failure message to end the exchange. 5.2.5. Channel Binding Values This protocol allows higher level protocols that are using it to transmit 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 details on its use. EAP-IBAKE 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 IBAKE-Confirm exchange (specifically, it is integrity protected through the use of the Auth_S, Auth_P payloads). Consequently, it MUST NOT be relied upon in case an error occurs at the EAP-IBAKE level. An unknown Channel Binding Value SHOULD be ignored by the recipient. Cakulev & Broustis Expires February 21, 2013 [Page 18] Internet-Draft The EAP-IBAKE Method August 2012 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 specification. Each Channel Binding Value is encoded using a simple 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 7: Channel Binding Value o CBType: This is the Channel Binding Value's type. This document defines the value 0x0000 as reserved. Other values are available for IANA allocation. o Length: This field is the total length in octets of the structure, including the CBType and Length fields. Cakulev & Broustis Expires February 21, 2013 [Page 19] Internet-Draft The EAP-IBAKE Method August 2012 6. Fragmentation EAP [RFC3748] is a request-response protocol. The server sends requests and the peer responds to those requests. These request and response messages are assumed to be limited to at most 1020 bytes. Messages in EAP-IBAKE can be larger than 1020 bytes and therefore require support for fragmentation and reassembly. Since EAP is a simple ACK-NAK protocol, fragmentation support can be added as follows. In EAP, fragments that are lost or damaged in transit will be retransmitted, and sequencing information is provided by the Identifier field in EAP. EAP-IBAKE fragmentation support is provided through addition of a "flags" octet within the EAP-Response and EAP-Request packets, as well as a Total-Length field of four octets. Flags include the Length included (L) and More fragments (M) bits. The L flag is set to indicate the presence of the two-octet Total-Length field, and MUST be set for the first fragment of a fragmented EAP-IBAKE message or set of messages. The M flag is set on all but the last fragment. The Total-Length field is two octets, and provides the total length of the EAP-IBAKE message or set of messages that is being fragmented; this simplifies buffer allocation. When an EAP-IBAKE peer receives an EAP-Request packet with the M bit set, it MUST respond with an EAP-Response with EAP-Type=EAP-IBAKE and no data. This serves as a fragment ACK. The EAP server MUST wait until it receives the EAP-Response before sending another fragment. In order to prevent errors in processing of fragments, the EAP server MUST increment the Identifier field for each fragment contained within an EAP-Request, and the peer MUST include this Identifier value in the fragment ACK contained within the EAP-Response. Retransmitted fragments will contain the same Identifier value. Similarly, when the EAP server receives an EAP-Response with the M bit set, it MUST respond with an EAP-Request with EAP-Type=EAP-IBAKE and no data. This serves as a fragment ACK. The EAP peer MUST wait until it receives the EAP-Request before sending another fragment. In order to prevent errors in the processing of fragments, the EAP server MUST increment the Identifier value for each fragment ACK contained within an EAP-Request, and the peer MUST include this Identifier value in the subsequent fragment contained within an EAP- Response. Cakulev & Broustis Expires February 21, 2013 [Page 20] Internet-Draft The EAP-IBAKE Method August 2012 7. IANA Considerations IANA shall allocate the EAP method type TBD from the range 1-191, for "EAP-IBAKE Version 1". This document requests that IANA create the registries described in the following sub-sections. 7.1. Elliptic Curve Registry IANA is to create and maintain Elliptic Curve Registry. Registry consists of an ECC curve and its associated value. Values in the range 1-239 SHOULD be approved by the process of Specification Required, values in the range 240-254 are for Private Use, and the values 0 and 255 are Reserved according to [RFC5226]. The initial contents of the registry should be as follows [SEC2], [FIPS186-2]: Value ECC curve ------- ------------------------------------ 0 Reserved 1 ECPRGF192Random / P-192 / secp192r1 2 EC2NGF163Random / B-163 / sect163r2 3 EC2NGF163Koblitz / K-163 / sect163k1 4 EC2NGF163Random2 / none / sect163r1 5 ECPRGF224Random / P-224 / secp224r1 6 EC2NGF233Random / B-233 / sect233r1 7 EC2NGF233Koblitz / K-233 / sect233k1 8 ECPRGF256Random / P-256 / secp256r1 9 EC2NGF283Random / B-283 / sect283r1 10 EC2NGF283Koblitz / K-283 / sect283k1 11 ECPRGF384Random / P-384 / secp384r1 12 EC2NGF409Random / B-409 / sect409r1 13 EC2NGF409Koblitz / K-409 / sect409k1 14 ECPRGF521Random / P-521 / secp521r1 15 EC2NGF571Random / B-571 / sect571r1 16 EC2NGF571Koblitz / K-571 / sect571k1 17-239 Unassigned 240-254 Private Use 255 Reserved 7.2. Pseudo Random Function Registry This section defines an IANA registry for pseudo random function algorithms: Cakulev & Broustis Expires February 21, 2013 [Page 21] Internet-Draft The EAP-IBAKE Method August 2012 +-------------------+---------+-------------------------------------+ | 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 | +-------------------+---------+-------------------------------------+ 7.3. Identity Type Registry In addition, an identity type registry is defined: +-----------+---------+---------------------------------------------+ | 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". 7.4. EAP-IBAKE 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. Cakulev & Broustis Expires February 21, 2013 [Page 22] Internet-Draft The EAP-IBAKE Method August 2012 7.5. Exchange Registry This section defines an IANA registry for the EAP-IBAKE Exchange registry, an 8-bit long code. Initial values are defined in Section 5.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.6. 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 5.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. Cakulev & Broustis Expires February 21, 2013 [Page 23] Internet-Draft The EAP-IBAKE Method August 2012 8. Security Considerations This section discusses the claimed security properties of EAP-IBAKE as well as vulnerabilities and security recommendations. 8.1. Identity Protection EAP-IBAKE includes identity privacy support that protects the privacy of the subscriber identity against passive eavesdropping. Observe that in all the messages, the identity of the peer is sent in the encrypted part of the payload, therefore an attacker cannot discover user identities by snooping authentication traffic. 8.2. Mutual Authentication Payloads in the protocol exchange are encrypted using IBE. In particular, only the peer can decrypt the contents of the ECDHComponent_S payload sent by the server, and similarly only the server can decrypt the contents of the ECDHComponent_P and the encrypted part of the EAP-Response/IBAKE-ID payload sent by the peer. Moreover, upon receiving EAP-Response/IBAKE-Challenge, the server can verify the authenticity of the peer, since [Rs]P could have been sent in EAP-Response/IBAKE-Challenge only after decryption of the contents of EAP-Request/IBAKE-Challenge by the peer. Similarly, upon receiving EAP-Request/IBAKE-Confirm, the peer can verify the authenticity of the server, since [Rp]P could have been sent back in EAP-Request/IBAKE-Confirm only after correctly decrypting the contents of EAP-Response/IBAKE-Challenge and this is possible only by the server. In other words, the protocol provides mutual authentication based on Identity Based Encryption. 8.3. Key Derivation EAP-IBAKE supports key derivation with 512-bit effective key strength. The key hierarchy is specified in Section 4. The transient EAP key used to protect EAP-IBAKE packets (Ka), the Master Session Keys, and the Extended Master Session Keys are cryptographically separate. An attacker cannot derive any non- trivial information about any of these keys based on the other keys. 8.4. Brute-Force and Dictionary Attacks The effective strength of EAP-IBAKE values is 512 bits, and there are no known, computationally feasible brute-force attacks to date. Because IBAKE is not a password protocol (the private keys are not a passphrase, or derived from a passphrase), EAP-IBAKE is not vulnerable to dictionary attacks. Cakulev & Broustis Expires February 21, 2013 [Page 24] Internet-Draft The EAP-IBAKE Method August 2012 8.5. Protection, Replay Protection, and Confidentiality ECDHComponent and Auth payloads are used to provide integrity, replay, and confidentiality protection for EAP-IBAKE Requests and Responses. Integrity protection with Auth includes the EAP header. Integrity protection (Auth) is based on a keyed message authentication code. Confidentiality (ECDHComponent) is based on Identity Based Encryption. Because the session key is not available in the beginning of the EAP method, the Auth payload cannot be used for protecting EAP/IBAKE-ID and EAP/IBAKE-Challenge messages. However, the EAP/IBAKE-ID and EAP/ IBAKE-Challenge exchanges are integrity protected through the Auth payloads exchanged in the Confirm exchange. Confidentiality protection is applied only to a part of the protocol fields. Section 4 describes in detail which fields are confidentiality protected. Identity protection is discussed in Section 8.1. Because EAP-IBAKE is not a tunneling method, EAP-Request/ Notification, EAP-Response/Notification, EAP-Success, or EAP-Failure packets are not confidentiality protected, integrity protected, or replay protected. On physically insecure networks, this may enable an attacker to mount denial-of-service attacks by spoofing these packets. However, the peer will only accept EAP-Success after the peer successfully authenticates the server. Hence, the attacker cannot force the peer to believe that successful mutual authentication has occurred before the peer successfully authenticates the server, or after the peer fails to authenticate the server. An eavesdropper will see the EAP Notification, EAP-Success and EAP- Failure packets sent in the clear. With EAP-IBAKE, confidential information MUST NOT be transmitted in EAP Notification packets. 8.6. Trust Model It is assumed that the KGFs that are used for deriving IBE private keys are secure, not compromised, trusted, and will not engage in launching active attacks independently or in a collaborative environment. However, any malicious insider could potentially launch passive attacks (by decryption of one or more message exchanges offline). While it is in the best interest of administrators to prevent such threats, it is hard to eliminate this problem. Hence, it is assumed that such problems will persist, and hence the session key agreement protocols are designed to protect participants from passive adversaries. Cakulev & Broustis Expires February 21, 2013 [Page 25] Internet-Draft The EAP-IBAKE Method August 2012 The EAP peer and the EAP server need to trust their respective KGF entities. Such a KGF may be owned/operated by third parties; in such cases, the peer and the server need to maintain trust relationships with those third parties. Note here that in scenarios where the EAP peer and the EAP server are associated with the same KGF, while such a KGF is owned by the server owner (or operator), there is no implicit or explicit trust to third parties. In addition, it is assumed that the communication between participants and their respective KGFs is secure. Therefore, in any implementation of the protocols described in this document, administrators of any KGF have to ensure that communication with participants is secure and not compromised. 8.7. Forward Secrecy The MSK and EMSK are extracted from the session key, K_Session, which is derived from exchanged Elliptic Curve Diffie-Hellman values. The peer and the server choose random values with each run of the protocol. Hence, even if an attacker is able to somehow obtain the session key from an earlier run, the attacker will be unable to determine any future session keys, or the MSK or EMSK. In other words, EAP-IBAKE provides perfect forward secrecy. 8.8. Reflection Attacks The use of identities within the encrypted payload is intended to eliminate some basic reflection attacks. For instance, suppose that identities were not used as part of the encrypted payload, in EAP- Request/IBAKE-Challenge message. Furthermore, assume an adversary who has access to the conversation between the server and peer and can actively snoop into packets and drop/modify them before routing them to the destination. As an example, consider the case where the IP source address and destination address can be modified by the adversary. After the EAP-Request/IBAKE-Challenge message is sent by the server (to the peer), the adversary can take over and trap the packet. Next, the adversary can modify the IP source address to include the adversary's IP address, before routing it onto the responder. The peer will assume that the request for an IBAKE session came from the adversary, and will send EAP-Response/ IBAKE-Challenge, but encrypt it using the adversary's public key. The above message can be decrypted by the adversary (and only by the adversary). In particular, since the EAP-Request/IBAKE-Challenge message includes the challenge sent by the server to the peer, the adversary will now learn the challenge sent by the server. Following this, the adversary can carry on a conversation with the server "pretending" to be the peer. This attack is eliminated with EAP- IBAKE, since identities are used as part of the encrypted payload. Cakulev & Broustis Expires February 21, 2013 [Page 26] Internet-Draft The EAP-IBAKE Method August 2012 8.9. Negotiation Attacks EAP-IBAKE does not protect the EAP-Response/Nak packet. Given that EAP-IBAKE does not protect the EAP method negotiation, EAP method downgrading attacks may be possible. In addition, EAP-IBAKE does not support EAP-IBAKE protocol version negotiation. EAP-IBAKE supports ciphersuite negotiation through the use of Proposal payload during IBAKE-ID exchange. The ciphersuite proposal made by the server is not protected from tampering by an active attacker. However, the Proposal payload in EAP-Response/IBAKE-ID message containing the peers choice of ciphersuite is sent in the encrypted part of the message. Furthermore, 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. Cakulev & Broustis Expires February 21, 2013 [Page 27] Internet-Draft The EAP-IBAKE Method August 2012 9. Security Claims This section provides the security claims required by [RFC3748]. Authentication Mechanism: EAP-IBAKE is based on the IBAKE mechanism, which is an authentication and key agreement mechanism based on Identity Based Encryption. Ciphersuite negotiation: Yes Mutual authentication: Yes (Section 8.2) Integrity protection: Yes (Section 8.5) Replay protection: Yes (Section 8.5) Confidentiality: Yes, except method-specific failure indications (Section 8.5) Key derivation: Yes Key strength: EAP-IBAKE supports key derivation with 512-bit effective key strength. Description of key hierarchy: Please see Section 4. Dictionary attack protection: N/A (Section 8.4) Fast reconnect: No Cryptographic binding: Yes Session independence: Yes (Section 8.7) Fragmentation: Yes (Section 6) Channel binding: Yes Indication of vulnerabilities: Vulnerabilities are discussed in Section 8. Cakulev & Broustis Expires February 21, 2013 [Page 28] Internet-Draft The EAP-IBAKE Method August 2012 10. References 10.1. Normative References [FIPS186-2] NIST, "Digital Signature Standard", FIPS 186-2, 2000. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC5091] Boyen, X. and L. Martin, "Identity-Based Cryptography Standard (IBCS) #1: Supersingular Curve Implementations of the BF and BB1 Cryptosystems", RFC 5091, December 2007. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5408] Appenzeller, G., Martin, L., and M. Schertler, "Identity- Based Encryption Architecture and Supporting Data Structures", RFC 5408, January 2009. [SEC1] Standards for Efficient Cryptography Group, "Elliptic Curve Cryptography", September 2000. [SHA] Standards for Efficient Cryptography Group, "Secure Hash Standard", Federal Information Processing Standards Publication 180-2, August 2002, with Change Notice 1, February 2004. 10.2. Informative References [I-D.cakulev-ibake] Cakulev, V., Sundaram, G., and I. Broustis, "IBAKE: Identity-Based Authenticated Key Exchange", draft-cakulev-ibake-06 (work in progress), November 2011. [IEEE-802.11] "Information technology - Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific Requirements Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) Specifications", IEEE Standard 802.11-2007, 2007. [IEEE-802.16] Institute of Electrical and Electronics Engineers, "IEEE Cakulev & Broustis Expires February 21, 2013 [Page 29] Internet-Draft The EAP-IBAKE Method August 2012 Standard for Local and Metropolitan Area Networks: Part 16: Air Interface for Fixed and Mobile Broadband Wireless Access Systems: Amendment for Physical and Medium Access Control Layers for Combined Fixed and Mobile Operations in Licensed Bands", IEEE 802.16e, August 2005. [IEEE-802.1X] Institute of Electrical and Electronics Engineers, "Local and Metropolitan Area Networks: Port-Based Network Access Control", IEEE Standard 802.1X-2004, December 2004. [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", RFC 5191, May 2008. [RFC6267] Cakulev, V. and G. Sundaram, "MIKEY-IBAKE: Identity-Based Authenticated Key Exchange (IBAKE) Mode of Key Distribution in Multimedia Internet KEYing (MIKEY)", RFC 6267, June 2011. [SEC2] Standards for Efficient Cryptography Group, "SEC 2 - Recommended Elliptic Curve Domain Parameters", September 2000. Cakulev & Broustis Expires February 21, 2013 [Page 30] Internet-Draft The EAP-IBAKE Method August 2012 Authors' Addresses Violeta Cakulev Alcatel Lucent 600 Mountain Ave. 3D-517 Murray Hill, NJ 07974 US Phone: +1 908 582 3207 Email: violeta.cakulev@alcatel-lucent.com Ioannis Broustis AT&T Labs Research 180 Park Ave. Building 103, Room E243 Florham Park, NJ 07986 US Phone: +1 973 360 7131 Email: broustis@research.att.com Cakulev & Broustis Expires February 21, 2013 [Page 31]