idnits 2.17.1 draft-cakulev-emu-eap-ibake-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 20, 2012) is 4267 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Rs' is mentioned on line 357, but not defined == Missing Reference: 'Rp' is mentioned on line 357, but not defined == Missing Reference: 'RFC2104' is mentioned on line 818, but not defined == Missing Reference: 'RFC4282' is mentioned on line 834, but not defined ** Obsolete undefined reference: RFC 4282 (Obsoleted by RFC 7542) == Missing Reference: 'RFC4514' is mentioned on line 840, but not defined == Missing Reference: 'RFC5891' is mentioned on line 848, but not defined ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Cakulev 3 Internet-Draft Alcatel Lucent 4 Intended status: Informational I. Broustis 5 Expires: February 21, 2013 AT&T Labs Research 6 August 20, 2012 8 An EAP Authentication Method Based on Identity-Based Authenticated Key 9 Exchange 10 draft-cakulev-emu-eap-ibake-03.txt 12 Abstract 14 The Extensible Authentication Protocol (EAP) is an authentication 15 framework which supports multiple authentication methods. This 16 document defines an authentication method for EAP called EAP-IBAKE, 17 which is based on the Identity-Based Authenticated Key Exchange 18 (IBAKE) protocol. The IBAKE method provides mutual authentication 19 through the use of identity-based encryption. In addition to mutual 20 authentication this method also provides perfect forward and 21 backwards secrecy. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on February 21, 2013. 40 Copyright Notice 42 Copyright (c) 2012 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 2.1. Requirements notation . . . . . . . . . . . . . . . . . . 5 60 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 61 2.3. Conventions . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 6 63 3.1. Message Flows . . . . . . . . . . . . . . . . . . . . . . 6 64 4. Protocol Sequence . . . . . . . . . . . . . . . . . . . . . . 9 65 4.1. IBAKE-ID Exchange . . . . . . . . . . . . . . . . . . . . 9 66 4.2. EAP-Request/IBAKE-Challenge . . . . . . . . . . . . . . . 9 67 4.3. EAP-Response/IBAKE-Challenge . . . . . . . . . . . . . . . 10 68 4.4. EAP-Request/IBAKE-Confirm . . . . . . . . . . . . . . . . 10 69 4.5. EAP-Response/IBAKE-Confirm . . . . . . . . . . . . . . . . 11 70 4.6. MSK and EMSK . . . . . . . . . . . . . . . . . . . . . . . 11 71 5. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 13 72 5.1. EAP-IBAKE Header . . . . . . . . . . . . . . . . . . . . . 13 73 5.2. EAP-IBAKE Payloads . . . . . . . . . . . . . . . . . . . . 14 74 5.2.1. The IBAKE-ID Payload . . . . . . . . . . . . . . . . . 14 75 5.2.2. The IBAKE-Challenge Payload . . . . . . . . . . . . . 15 76 5.2.3. The IBAKE-Confirm Payload . . . . . . . . . . . . . . 16 77 5.2.4. The IBAKE-Failure Payload . . . . . . . . . . . . . . 17 78 5.2.5. Channel Binding Values . . . . . . . . . . . . . . . . 18 79 6. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . . 20 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 81 7.1. Elliptic Curve Registry . . . . . . . . . . . . . . . . . 21 82 7.2. Pseudo Random Function Registry . . . . . . . . . . . . . 21 83 7.3. Identity Type Registry . . . . . . . . . . . . . . . . . . 22 84 7.4. EAP-IBAKE Channel Binding Type Registry . . . . . . . . . 22 85 7.5. Exchange Registry . . . . . . . . . . . . . . . . . . . . 23 86 7.6. Failure-Code Registry . . . . . . . . . . . . . . . . . . 23 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 88 8.1. Identity Protection . . . . . . . . . . . . . . . . . . . 24 89 8.2. Mutual Authentication . . . . . . . . . . . . . . . . . . 24 90 8.3. Key Derivation . . . . . . . . . . . . . . . . . . . . . . 24 91 8.4. Brute-Force and Dictionary Attacks . . . . . . . . . . . . 24 92 8.5. Protection, Replay Protection, and Confidentiality . . . . 25 93 8.6. Trust Model . . . . . . . . . . . . . . . . . . . . . . . 25 94 8.7. Forward Secrecy . . . . . . . . . . . . . . . . . . . . . 26 95 8.8. Reflection Attacks . . . . . . . . . . . . . . . . . . . . 26 96 8.9. Negotiation Attacks . . . . . . . . . . . . . . . . . . . 27 97 9. Security Claims . . . . . . . . . . . . . . . . . . . . . . . 28 98 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 99 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 100 10.2. Informative References . . . . . . . . . . . . . . . . . . 29 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 31 103 1. Introduction 105 The Extensible Authentication Protocol (EAP) [RFC3748] provides a 106 standard mechanism for unified support of different authentication 107 methods. EAP has been defined for use with different lower-layer 108 transport methods, such as Point-to-Point Protocol (PPP) [RFC1661], 109 Protocol for Carrying Authentication for Network Access (PANA) 110 [RFC5191], IEEE 802 wired networks [IEEE-802.1X], as well as wireless 111 technologies such as IEEE 802.11 [IEEE-802.11] and IEEE 802.16 112 [IEEE-802.16]. This document defines a new authentication method for 113 EAP called EAP-Identity Based Authenticated Key Exchange (EAP-IBAKE). 115 IBAKE is a protocol for mutual authentication and key agreement 116 between two or more endpoints. It is structured as a public-key 117 based authentication mechanism, where each message is encrypted with 118 the public key of the corresponding endpoint, as per the Identity 119 Based Encryption (IBE) principles [RFC5091]. As a result of the 120 IBAKE protocol successful execution, a shared symmetric key is 121 generated by each endpoint, which can further be used for securing 122 the communication between the endpoints. IBAKE may be applied in a 123 plurality of deployment scenarios that require generation of a common 124 symmetric key. Hence, IBAKE may be used e.g. for establishing end- 125 to-end secure sessions between peers [RFC6267], or for mutually 126 authenticating a peer with a server and deriving a common key. IBAKE 127 offers multiple benefits in terms of facilitating a simplified 128 public-key based mutual authentication and key agreement procedure, 129 which does not depend on the existence of public key infrastructures 130 and the incurred complexities thereof [RFC6267]. IBAKE achieves 131 secure mutual authentication between the participants, escrow-free 132 key agreement, as well as perfect forward and backwards secrecy 133 [I-D.cakulev-ibake]. 135 This document specifies IBAKE as a method for the Extensible 136 Authentication Protocol (EAP) [RFC3748]. In the EAP setting that is 137 considered in this document, IBAKE is executed between an EAP peer 138 and an EAP server. While IBAKE may be used for mutual authentication 139 and key agreement between more than two participants, such scenarios 140 are outside the scope of this document. 142 2. Terminology 144 2.1. Requirements notation 146 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 147 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 148 document are to be interpreted as described in [RFC2119]. 150 2.2. Abbreviations 152 IBE Identity Based Encryption 154 IBAKE Identity Based Authenticated Key Exchange 156 IDp Peer's Identity 158 IDs Server's Identity 160 K_PR Private Key 162 K_PUB Public Key 164 2.3. Conventions 166 o E is an elliptic curve over a finite field F 168 o P is a point on E of large prime order 170 o [x]P denotes point multiplication on an elliptic curve, i.e. 171 adding a point P to itself total of x times 173 o H1 is a known hash function that takes a string and assigns it to 174 a point on the elliptic curve, i.e., H1(A) = QA on E, where A is 175 usually based on the identity. 177 o Encr(k, A) denotes that A is IBE-encrypted with the key k 179 o s||t denotes concatenation of the strings s and t 181 o K_PUBx denotes Public Key of x 183 3. Protocol Description 185 EAP is a two-party protocol that takes place between an EAP peer and 186 an EAP server (also know as authenticator). An EAP method defines 187 the specific authentication protocol being used by EAP. This 188 document defines IBAKE as the EAP method, i.e., it defines the 189 messages sent between the EAP server and the EAP peer for the 190 purposes of authentication and key derivation. 192 The peer and the server are attempting to mutually authenticate each 193 other and agree on a key using EAP-IBAKE. This specification assumes 194 that the peer and the server trust a third party, the Key Generation 195 Function (KGF). Rather than a single KGF, several different KGFs may 196 be involved, e.g. one for the peer and one for the server. The peer 197 and the server do not share any credentials prior to execution of 198 EAP-IBAKE. This specification also assumes that the peer and the 199 server have securely obtained their respective Private Keys from 200 their respective KGFs prior to EAP-IBAKE message exchange. In 201 addition, the peer and the server obtained or are able to obtain a 202 set of publicly available parameters of each other's KGF. The 203 procedures needed to obtain the private keys and public parameters 204 are outside of scope of this specification. The details for these 205 procedures can be found in [RFC5091] and [RFC5408]. 207 3.1. Message Flows 209 A successful run of EAP-IBAKE consists of up to three message 210 exchanges: an Identity exchange, a Challenge exchange and a Confirm 211 exchange. This is shown in Figure 1. 213 The peer and the server use the EAP-IBAKE Identity exchange to obtain 214 each other's identities and to agree upon a ciphersuite to use in the 215 subsequent exchanges. In the Challenge exchange the peer and the 216 server exchange information to authenticate each other and also to 217 generate a shared key. In the Confirm exchange the peer and the 218 server complete the authentication by proving the knowledge of valid 219 identity-based private keys. 221 +--------+ +--------+ 222 | | EAP-Request/IBAKE-ID | | 223 | EAP |<------------------------------------| EAP | 224 | peer | | server | 225 | (P) | EAP-Response/IBAKE-ID | (S) | 226 | |------------------------------------>| | 227 | | | | 228 | | EAP-Request/IBAKE-Challenge| | 229 | |<------------------------------------| | 230 | | | | 231 | | EAP-Response/IBAKE-Challenge | | 232 | |------------------------------------>| | 233 | | | | 234 | | EAP-Request/IBAKE-Confirm | | 235 | |<------------------------------------| | 236 | | | | 237 | | EAP-Response/IBAKE-Confirm | | 238 | |------------------------------------>| | 239 | | | | 240 | | EAP-Success | | 241 | |<------------------------------------| | 242 +--------+ +--------+ 244 Figure 1: Successful EAP-IBAKE Exchange 246 The IBAKE exchange, also described in [I-D.cakulev-ibake] is a three- 247 step exchange as follows: 249 Peer Server 250 ---- ------ 252 Encr(K_PUBs, IDp || IDs || [Rp]P) -> 254 <- Encr(K_PUBp, IDp || IDs || [Rp]P || [Rs]P) 256 Encr(K_PUBs, IDp || IDs || [Rs]P) -> 258 Where: 260 o K_PUBp and K_PUBs are the public keys of peer and server, 261 respectively. These public keys are derived from their 262 corresponding identities as follows K_PUBp/s = H1(IDp/s). 264 o Rp and Rs are random integers, chosen by Peer and Server, 265 respectively. 267 The EAP-IBAKE method extends the basic IBAKE protocol such that the 268 regular successful EAP-IBAKE exchange takes place as follows. 270 Message Server Peer 271 --------- -------- ------ 272 ID/Request IDs, CryptoProposals -> 274 ID/Response <- Encr(K_PUBs,IDp), CryptoProposal 276 Challenge/Request Encr(K_PUBp, IDs || IDp || [Rs]P) -> 278 Challenge/Response <- Encr(K_PUBp, IDs || IDp || [Rs]P || [Rp]P) 280 Confirm/Request Encr(K_PUBp, IDs || IDp || [Rp]P), Auth_S -> 282 Confirm/Response <- Auth_P 284 As shown in the exchange above, the following information elements 285 have been added to the original protocol: exchange of identity values 286 for both protocol parties (IDs, IDp), negotiation of cryptographic 287 protocols, signature fields to protect the integrity of the 288 negotiated parameters (Auth_S, Auth_P), and the last message to 289 complete the four-way handshake. 291 Detailed protocol description is provided in the next section while 292 message formats are provided in Section 5. 294 4. Protocol Sequence 296 This section describes the sequence of messages for the ID, Challenge 297 and Confirm exchanges, and lists the operations performed by the 298 server and the peer. 300 4.1. IBAKE-ID Exchange 302 Initially, the server issues EAP-Request/IBAKE-ID, including its 303 identity (IDs) in the Identity payload and optionally ciphersuite 304 proposals in the Proposal payload. Upon receiving the EAP-Request/ 305 IBAKE-ID message the peer uses the received server's identity to 306 generate the server's public key as follows 308 K_PUBs = H1(IDs). 310 The peer then encrypts its identity as follows 312 Encr(K_PUBs, IDp), 314 and includes it in the Identity payload of the EAP-Response/IBAKE-ID 315 message. 317 Finally, if the EAP-Request/IBAKE-ID contains Proposals payload, the 318 Peer chooses most preferred proposal, and includes it in the Proposal 319 payload of the EAP-Response/IBAKE-ID message. 321 4.2. EAP-Request/IBAKE-Challenge 323 Upon receiving EAP-Response/IBAKE-ID message, the server SHALL first 324 decrypt the message as specified in [RFC5091] and [RFC5408], and 325 obtain the identity of the peer. The server then selects a random Rs 326 and computes its Elliptic curve Diffie-Hellman value, [Rs]P. The 327 server MUST use a fresh, random value for Rs on each run of the 328 protocol. The server uses the identity of the peer obtained in 329 IBAKE-ID exchange to generate the IBE public key of the peer as 330 follows 332 K_PUBp = H1(IDp). 334 The server then computes the encrypted field (see Section 5.2.2) 336 ECDHComponent_S = Encr(K_PUBp, IDs || IDp || [Rs]P). 338 Finally, the server sends EAP-Request/IBAKE-Challenge message to the 339 peer. 341 4.3. EAP-Response/IBAKE-Challenge 343 Upon receiving EAP-Request/IBAKE-Challenge message, the peer SHALL 344 first decrypt the message as specified in [RFC5091] and [RFC5408], 345 and obtain [Rs]P. The peer then selects a random Rp and computes its 346 Elliptic curve Diffie-Hellman value, [Rp]P. The peer MUST use a 347 fresh, random value for Rp on each run of the protocol. 349 The peer then computes the encrypted field (see Section 5.2.2) 351 ECDHComponent_P = Encr(K_PUBs, IDs || IDp || [Rs]P || [Rp]P). 353 Finally, the peer sends EAP-Response/IBAKE-Challenge message to the 354 server. 356 At this point both the Server and Peer can generate the session key 357 [Rs][Rp]P using exchanged Elliptic Curve Diffie-Hellman values. The 358 session key as a point on an elliptic curve is then converted into 359 the octet string as specified in [SEC1]. This octet string, 360 K_Session, is then used to generate MSK, EMSK and keys used for 361 protection of IBAKE-Confirm exchange. 363 4.4. EAP-Request/IBAKE-Confirm 365 Upon receiving EAP-Response/IBAKE-Challenge message, the server SHALL 366 first decrypt the message as specified in [RFC5091] and [RFC5408], 367 and obtain [Rs]P and [Rp]P. The server MUST verify that the received 368 [Rs]P is the same as the one sent in EAP-Request/IBAKE-Challenge 369 message. If it is not the same, the server MUST abort the protocol 370 with an "Authentication Failure" code. Upon successful verification 371 of the received [Rs]P, the server computes the encrypted field 373 ECDHComponent_S = Encr(K_PUBp, IDs || IDp || [Rp]P). 375 The server then computes: 377 Ka = prf(K_Session, "EAP-IBAKE Ka" || IDs || IDp) 379 whose length is the preferred key length of the negotiated pseudo- 380 random function (see Section 5.2). It then constructs: 382 Auth_S = prf(Ka, "EAP-IBAKE server" || EAP-Request/IBAKE-ID || 383 EAP-Response/IBAKE-ID || EAP-Request/IBAKE-Challenge || 384 EAP-Response/IBAKE-Challenge). 386 The messages in Auth_S computation are included in full, starting 387 with the EAP header, and including any possible future extensions. 389 The server then constructs and sends EAP-Request/IBAKE-Confirm 390 message to the peer. 392 4.5. EAP-Response/IBAKE-Confirm 394 Upon receiving EAP-Request/IBAKE-Confirm message, the peer SHALL 395 first decrypt the message as specified in [RFC5091] and [RFC5408], 396 and obtain [Rp]P. The peer MUST verify that the received [Rp]P is the 397 same as the one sent in EAP-Response/IBAKE-Challenge message. If it 398 is not the same, the peer MUST abort the protocol with an 399 "Authentication Failure" code. The peer also MUST verify the 400 correctness of the Auth_S value, and MUST abort the protocol if 401 incorrect, with an "Authentication Failure" code. 403 Upon successful verification of the received [Rp]P and correctness of 404 the Auth_S value, the peer computes Ka as described above, and 405 constructs: 407 Auth_P = prf(Ka, "EAP-IBAKE peer" || EAP-Request/IBAKE-ID || 408 EAP-Response/IBAKE-ID || EAP-Request/IBAKE-Challenge || 409 EAP-Response/IBAKE-Challenge). 411 The peer sends verification message EAP-Response/IBAKE-Confirm to 412 complete the four-way handshake, including AUTH_P value. Upon 413 receiving the message, the server MUST verify the correctness of the 414 Auth_P value, and MUST abort the protocol if incorrect, with an 415 "Authentication Failure" code. 417 4.6. MSK and EMSK 419 The authenticated key exchange of EAP-IBAKE generates a shared and 420 authenticated key, K_Session. EAP-IBAKE must export two 512-bit 421 keys, MSK and EMSK. Therefore, following the last message of the 422 protocol, both sides compute and export the shared keys, each 512 423 bits in length: 425 MSK || EMSK = prf(K_Session, "EAP-IBAKE Exported Keys" || 426 IDs || IDp) 428 At this point, both protocol participants MUST discard all 429 intermediate cryptographic values, including Rs and Rp. Similarly, 430 both parties MUST immediately discard these values whenever the 431 protocol terminates with a failure code or as a result of timeout. 433 5. Message Formats 435 EAP-IBAKE defines new message types, with each message consisting of 436 a header followed by a payload. This section defines the header, 437 several payload formats, as well as the format of specific fields 438 within the payloads. 440 All multi-octet strings MUST be laid out in network byte order. 442 5.1. EAP-IBAKE Header 444 The EAP-IBAKE header consists of the standard EAP header (see Section 445 4 of [RFC3748]), followed by an EAP-IBAKE exchange type. The header 446 has the following structure: 448 0 1 2 3 449 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 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | Code | Identifier | Length | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 | Type |L|M| IBAKE-Exch| Total-Length | 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 | Data ~ 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 458 Figure 2: EAP-IBAKE Header 460 The Code, Identifier, Length, and Type fields are all part of the EAP 461 header as defined in [RFC3748]. The Type field in the EAP header is 462 [TBD by IANA] for EAP-IBAKE version 1. 464 L and M bits: The L bit (Length included) is set to indicate the 465 presence of the two-octet Total-Length field, and MUST be set for the 466 first fragment of a fragmented EAP-IBAKE message or set of messages. 467 The M bit (more fragments) is set on all but the last fragment. 469 The IBAKE-Exch (IBAKE Exchange) field identifies the type of EAP- 470 IBAKE payload encapsulated in the Data field. This document defines 471 the following values for the IBAKE-Exch field: 473 o 0x00: Reserved 475 o 0x01: IBAKE-ID exchange 477 o 0x02: IBAKE-Challenge exchange 478 o 0x03: IBAKE-Confirm exchange 480 o 0x04: IBAKE-Failure message 482 Further values of this IBAKE-Exch field are available via IANA 483 registration. 485 Total-Length: The Total-Length field is two octets in length, and is 486 present only if the L bit is set. This field provides the total 487 length of the EAP-IBAKE message or set of messages that is being 488 fragmented. 490 5.2. EAP-IBAKE Payloads 492 EAP-IBAKE messages all contain the EAP-IBAKE header and information 493 encoded in a single payload, which differs for each message. This 494 section defines payloads for EAP-IBAKE messages. 496 5.2.1. The IBAKE-ID Payload 498 0 1 2 3 499 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 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 | NumProposals | Reserved | Proposal ... 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 ... Proposal | IDType | Identity ... 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 Figure 3: IBAKE-ID Payload 508 The IBAKE-ID payload contains the following fields: 510 o NumProposals: The NumProposals field contains the number of 511 Proposal fields subsequently contained in the payload. If in the 512 IBAKE-ID/Request the NumProposals field is set to zero (0) then it 513 is out of scope of this specification how the server and the peer 514 negotiate the elliptic curve and PRF used in the rest of EAP-IBAKE 515 exchange. Otherwise, if in the IBAKE-ID/Request the NumProposals 516 field is not set to zero (0), then in the IBAKE-ID/Response 517 message the NumProposals field MUST be set to one (1). The 518 offered proposals in the Request are listed in priority order, 519 with the most preferable appearing first. The selected proposal 520 in the Response MUST be fully identical with one of the offered 521 proposals. 523 o Proposal: Each proposal consists of three fields, in this order: 525 * Elliptic Curve Description: This field's value is taken from 526 the IANA registry for Elliptic curves defined in Section 7.1. 527 The length of this field is one octet. 529 * PRF: This field's value is taken from the IANA registry for 530 pseudo random functions defined in Section 7.2. The length of 531 this field is one octet. 533 * P: This field contains the 2-dimensional coordinates of the 534 selected point P on the Elliptic Curve. The length of each 535 coordinate in octets depends on the chosen Elliptic Curve. 537 o Reserved: By default, this field MUST be sent as zero, and MUST be 538 ignored by the recipient. 540 o IDType: Denotes the Identity Type. This is taken from the IANA 541 registry defined in Section 7.3. The server and the peer MAY use 542 different identity types. All implementations MUST be able to 543 receive two identity types: ID_NAI and ID_FQDN. 545 o Identity: The meaning of the Identity field depends on the values 546 of the Code and IDType fields. 548 * IBAKE-ID/Request: server ID 550 * IBAKE-ID/Response: peer ID 552 The length of the Identity field MUST be computed from the Length 553 field in the EAP header. This field, like all other fields in 554 this specification, MUST be octet-aligned. 556 5.2.2. The IBAKE-Challenge Payload 558 This payload allows both parties send their encrypted ephemeral keys. 560 In addition, a small amount of data can be included by the server 561 and/or the peer, and used for channel binding. This data is sent in 562 IBAKE-Challenge exchange unprotected, but is verified when it is 563 signed by the Auth_S/Auth_P payloads of the IBAKE-Confirm exchange. 565 0 1 2 3 566 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 567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ 568 | ECDHComponent_S ~ | 569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 570 | ECDHComponent_P ~ | 571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ 572 | CBValue (zero or more occurrences) ~ | 573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 574 ~ ~ | 575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 576 | 577 Encrypted | 578 fields 580 Figure 4: IBAKE-Challenge Payload 582 The IBAKE-Challenge payload contains the following fields: 584 o ECDHComponent_S/ECDHComponent_P: This field contains Server's/ 585 Peer's IBE-encrypted Elliptic Curve Diffie-Hellman value. The 586 peer's Elliptic Curve Diffie-Hellman value DHComponent_P is 587 included only in the response message (i.e. EAP-Response/ 588 IBAKE-Challenge). ECDHComponent field contains the identities of 589 the server and the peer, as exchanged in IBAKE-ID exchange. 591 o CBValue: This structure MAY be included both in the request and in 592 the response, and MAY be repeated multiple times in a single 593 payload (see Section 5.2.5). Each structure contains its own 594 length. The field is neither encrypted nor integrity protected; 595 instead it is protected by the AUTH payloads in the Confirm 596 exchange. 598 Note that as shown in Figure 4, Identity fields and ECDHComponent 599 fields are IBE-Encrypted. 601 5.2.3. The IBAKE-Confirm Payload 603 Using this payload, both parties complete the authentication by 604 mutually authenticating each other and generating key material for 605 the EAP consumer protocol. 607 0 1 2 3 608 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 609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ 610 | ECDHComponent_P ~ | 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <---+ 612 | Auth_S/Auth_P ~ | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 614 ~ ~ | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 616 | 617 Encrypted | 618 fields 620 Figure 5: IBAKE-Confirm Payload 622 The IBAKE-Confirm payload contains the following fields: 624 o ECDHComponent_P: This field contains the peer's IBE-encrypted 625 Elliptic Curve Diffie-Hellman value. The peer's Elliptic Curve 626 Diffie-Hellman value DHComponent_P is included only in the request 627 message (i.e. EAP-Request/IBAKE-Confirm). ECDHComponent field 628 contains the identities of the server and the peer, as exchanged 629 in IBAKE-ID exchange. 631 o Auth_S/Auth_P: This field contains a signature of the preceding 632 messages, including the Identity and the negotiated fields. This 633 prevents various possible attacks, such as algorithm-downgrade 634 attacks. Auth_S is included only in the request message (i.e. 635 EAP-Request/IBAKE-Confirm), while Auth_P is included only in the 636 response message (i.e. EAP-Response/IBAKE-Confirm). 638 5.2.4. The IBAKE-Failure Payload 640 The EAP-EKE-Failure payload format is defined as follows: 642 0 1 2 3 643 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 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Failure-Code | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 648 Figure 6: IBAKE-Failure Payload 650 The payload's size is always exactly 4 octets. 652 The following Failure-Code values are defined: 654 +------------+----------------+-------------------------------------+ 655 | Value | Name | Meaning | 656 +------------+----------------+-------------------------------------+ 657 | 0x00000000 | Reserved | | 658 | 0x00000001 | No Error | This code is used for failure | 659 | | | acknowledgement, see below. | 660 | 0x00000002 | Protocol Error | A failure to parse or understand a | 661 | | | protocol message or one of its | 662 | | | payloads. | 663 | 0x00000003 | Authentication | Failure in the cryptographic | 664 | | Failure | computation. | 665 | 0x00000004 | Authorization | While the cryptographic computation | 666 | | Failure | is correct, the user is not | 667 | | | authorized to connect. | 668 | 0x00000005 | No Proposal | The peer is unwilling to select any | 669 | | Chosen | of the cryptographic proposals | 670 | | | offered by the server. | 671 +------------+----------------+-------------------------------------+ 673 Additional values of this field are available via IANA registration. 675 When the peer encounters an error situation, it MUST send IBAKE- 676 Failure. The server MUST reply with an EAP-Failure message to end 677 the exchange. 679 When the server encounters an error situation, it MUST send IBAKE- 680 Failure. The peer MUST send back IBAKE-Failure message containing a 681 "No Error" failure code. Then the server MUST send an EAP-Failure 682 message to end the exchange. 684 5.2.5. Channel Binding Values 686 This protocol allows higher level protocols that are using it to 687 transmit opaque information between the peer and the server. This 688 information is integrity protected but not encrypted, and MAY be used 689 to ensure that protocol participants are identical at different 690 protocol layers. See Section 7.15 of [RFC3748] for more details on 691 its use. 693 EAP-IBAKE neither validates nor makes any use of the transmitted 694 information. The information MUST NOT be used by the consumer 695 protocol until it is verified in the IBAKE-Confirm exchange 696 (specifically, it is integrity protected through the use of the 697 Auth_S, Auth_P payloads). Consequently, it MUST NOT be relied upon 698 in case an error occurs at the EAP-IBAKE level. 700 An unknown Channel Binding Value SHOULD be ignored by the recipient. 702 Some implementations may require certain values to be present, and 703 will abort the protocol if they are not. Such policy is out of scope 704 of the current specification. 706 Each Channel Binding Value is encoded using a simple TLV structure: 708 0 1 2 3 709 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 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | CBType | Length | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | Value ... 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 Figure 7: Channel Binding Value 718 o CBType: This is the Channel Binding Value's type. This document 719 defines the value 0x0000 as reserved. Other values are available 720 for IANA allocation. 722 o Length: This field is the total length in octets of the structure, 723 including the CBType and Length fields. 725 6. Fragmentation 727 EAP [RFC3748] is a request-response protocol. The server sends 728 requests and the peer responds to those requests. These request and 729 response messages are assumed to be limited to at most 1020 bytes. 730 Messages in EAP-IBAKE can be larger than 1020 bytes and therefore 731 require support for fragmentation and reassembly. 733 Since EAP is a simple ACK-NAK protocol, fragmentation support can be 734 added as follows. In EAP, fragments that are lost or damaged in 735 transit will be retransmitted, and sequencing information is provided 736 by the Identifier field in EAP. 738 EAP-IBAKE fragmentation support is provided through addition of a 739 "flags" octet within the EAP-Response and EAP-Request packets, as 740 well as a Total-Length field of four octets. Flags include the 741 Length included (L) and More fragments (M) bits. The L flag is set 742 to indicate the presence of the two-octet Total-Length field, and 743 MUST be set for the first fragment of a fragmented EAP-IBAKE message 744 or set of messages. The M flag is set on all but the last fragment. 745 The Total-Length field is two octets, and provides the total length 746 of the EAP-IBAKE message or set of messages that is being fragmented; 747 this simplifies buffer allocation. 749 When an EAP-IBAKE peer receives an EAP-Request packet with the M bit 750 set, it MUST respond with an EAP-Response with EAP-Type=EAP-IBAKE and 751 no data. This serves as a fragment ACK. The EAP server MUST wait 752 until it receives the EAP-Response before sending another fragment. 753 In order to prevent errors in processing of fragments, the EAP server 754 MUST increment the Identifier field for each fragment contained 755 within an EAP-Request, and the peer MUST include this Identifier 756 value in the fragment ACK contained within the EAP-Response. 757 Retransmitted fragments will contain the same Identifier value. 759 Similarly, when the EAP server receives an EAP-Response with the M 760 bit set, it MUST respond with an EAP-Request with EAP-Type=EAP-IBAKE 761 and no data. This serves as a fragment ACK. The EAP peer MUST wait 762 until it receives the EAP-Request before sending another fragment. 763 In order to prevent errors in the processing of fragments, the EAP 764 server MUST increment the Identifier value for each fragment ACK 765 contained within an EAP-Request, and the peer MUST include this 766 Identifier value in the subsequent fragment contained within an EAP- 767 Response. 769 7. IANA Considerations 771 IANA shall allocate the EAP method type TBD from the range 1-191, for 772 "EAP-IBAKE Version 1". 774 This document requests that IANA create the registries described in 775 the following sub-sections. 777 7.1. Elliptic Curve Registry 779 IANA is to create and maintain Elliptic Curve Registry. Registry 780 consists of an ECC curve and its associated value. Values in the 781 range 1-239 SHOULD be approved by the process of Specification 782 Required, values in the range 240-254 are for Private Use, and the 783 values 0 and 255 are Reserved according to [RFC5226]. The initial 784 contents of the registry should be as follows [SEC2], [FIPS186-2]: 786 Value ECC curve 787 ------- ------------------------------------ 788 0 Reserved 789 1 ECPRGF192Random / P-192 / secp192r1 790 2 EC2NGF163Random / B-163 / sect163r2 791 3 EC2NGF163Koblitz / K-163 / sect163k1 792 4 EC2NGF163Random2 / none / sect163r1 793 5 ECPRGF224Random / P-224 / secp224r1 794 6 EC2NGF233Random / B-233 / sect233r1 795 7 EC2NGF233Koblitz / K-233 / sect233k1 796 8 ECPRGF256Random / P-256 / secp256r1 797 9 EC2NGF283Random / B-283 / sect283r1 798 10 EC2NGF283Koblitz / K-283 / sect283k1 799 11 ECPRGF384Random / P-384 / secp384r1 800 12 EC2NGF409Random / B-409 / sect409r1 801 13 EC2NGF409Koblitz / K-409 / sect409k1 802 14 ECPRGF521Random / P-521 / secp521r1 803 15 EC2NGF571Random / B-571 / sect571r1 804 16 EC2NGF571Koblitz / K-571 / sect571k1 805 17-239 Unassigned 806 240-254 Private Use 807 255 Reserved 809 7.2. Pseudo Random Function Registry 811 This section defines an IANA registry for pseudo random function 812 algorithms: 814 +-------------------+---------+-------------------------------------+ 815 | Name | Value | Definition | 816 +-------------------+---------+-------------------------------------+ 817 | Reserved | 0 | | 818 | PRF_HMAC_SHA1 | 1 | HMAC SHA-1, as defined in [RFC2104] | 819 | PRF_HMAC_SHA2_256 | 2 | HMAC SHA-2-256 [SHA] | 820 | | 3-127 | Available for allocation via IANA | 821 | | 128-255 | Reserved for private use | 822 +-------------------+---------+-------------------------------------+ 824 7.3. Identity Type Registry 826 In addition, an identity type registry is defined: 828 +-----------+---------+---------------------------------------------+ 829 | Name | Value | Definition | 830 +-----------+---------+---------------------------------------------+ 831 | Reserved | 0 | | 832 | ID_OPAQUE | 1 | An opaque octet string | 833 | ID_NAI | 2 | A Network Access Identifier, as defined in | 834 | | | [RFC4282] | 835 | ID_IPv4 | 3 | An IPv4 address, in binary format | 836 | ID_IPv6 | 4 | An IPv6 address, in binary format | 837 | ID_FQDN | 5 | A fully qualified domain name, see note | 838 | | | below | 839 | ID_DN | 6 | An LDAP Distinguished Name formatted as a | 840 | | | string, as defined in [RFC4514] | 841 | | 7-127 | Available for allocation via IANA | 842 | | 128-255 | Reserved for private use | 843 +-----------+---------+---------------------------------------------+ 845 An example of an ID_FQDN is "example.com". The string MUST NOT 846 contain any terminators (e.g., NULL, CR, etc.). All characters in 847 the ID_FQDN are ASCII; for an "internationalized domain name", the 848 syntax is as defined in [RFC5891], for example "xn--tmonesimerkki- 849 bfbb.example.net". 851 7.4. EAP-IBAKE Channel Binding Type Registry 853 This section defines an IANA registry for the Channel Binding Type 854 registry, a 16-bit long code. The value 0x0000 has been defined as 855 Reserved. All other values up to and including 0xfeff are available 856 for allocation via IANA. The remaining values up to and including 857 0xffff are available for private use. 859 7.5. Exchange Registry 861 This section defines an IANA registry for the EAP-IBAKE Exchange 862 registry, an 8-bit long code. Initial values are defined in 863 Section 5.1. All values up to and including 0x7f are available for 864 allocation via IANA. The remaining values up to and including 0xff 865 are available for private use. 867 7.6. Failure-Code Registry 869 This section defines an IANA registry for the Failure-Code registry, 870 a 32-bit long code. Initial values are defined in Section 5.2.4. 871 All values up to and including 0xfeffffff are available for 872 allocation via IANA. The remaining values up to and including 873 0xffffffff are available for private use. 875 8. Security Considerations 877 This section discusses the claimed security properties of EAP-IBAKE 878 as well as vulnerabilities and security recommendations. 880 8.1. Identity Protection 882 EAP-IBAKE includes identity privacy support that protects the privacy 883 of the subscriber identity against passive eavesdropping. Observe 884 that in all the messages, the identity of the peer is sent in the 885 encrypted part of the payload, therefore an attacker cannot discover 886 user identities by snooping authentication traffic. 888 8.2. Mutual Authentication 890 Payloads in the protocol exchange are encrypted using IBE. In 891 particular, only the peer can decrypt the contents of the 892 ECDHComponent_S payload sent by the server, and similarly only the 893 server can decrypt the contents of the ECDHComponent_P and the 894 encrypted part of the EAP-Response/IBAKE-ID payload sent by the peer. 895 Moreover, upon receiving EAP-Response/IBAKE-Challenge, the server can 896 verify the authenticity of the peer, since [Rs]P could have been sent 897 in EAP-Response/IBAKE-Challenge only after decryption of the contents 898 of EAP-Request/IBAKE-Challenge by the peer. Similarly, upon 899 receiving EAP-Request/IBAKE-Confirm, the peer can verify the 900 authenticity of the server, since [Rp]P could have been sent back in 901 EAP-Request/IBAKE-Confirm only after correctly decrypting the 902 contents of EAP-Response/IBAKE-Challenge and this is possible only by 903 the server. In other words, the protocol provides mutual 904 authentication based on Identity Based Encryption. 906 8.3. Key Derivation 908 EAP-IBAKE supports key derivation with 512-bit effective key 909 strength. The key hierarchy is specified in Section 4. 911 The transient EAP key used to protect EAP-IBAKE packets (Ka), the 912 Master Session Keys, and the Extended Master Session Keys are 913 cryptographically separate. An attacker cannot derive any non- 914 trivial information about any of these keys based on the other keys. 916 8.4. Brute-Force and Dictionary Attacks 918 The effective strength of EAP-IBAKE values is 512 bits, and there are 919 no known, computationally feasible brute-force attacks to date. 920 Because IBAKE is not a password protocol (the private keys are not a 921 passphrase, or derived from a passphrase), EAP-IBAKE is not 922 vulnerable to dictionary attacks. 924 8.5. Protection, Replay Protection, and Confidentiality 926 ECDHComponent and Auth payloads are used to provide integrity, 927 replay, and confidentiality protection for EAP-IBAKE Requests and 928 Responses. Integrity protection with Auth includes the EAP header. 929 Integrity protection (Auth) is based on a keyed message 930 authentication code. Confidentiality (ECDHComponent) is based on 931 Identity Based Encryption. 933 Because the session key is not available in the beginning of the EAP 934 method, the Auth payload cannot be used for protecting EAP/IBAKE-ID 935 and EAP/IBAKE-Challenge messages. However, the EAP/IBAKE-ID and EAP/ 936 IBAKE-Challenge exchanges are integrity protected through the Auth 937 payloads exchanged in the Confirm exchange. 939 Confidentiality protection is applied only to a part of the protocol 940 fields. Section 4 describes in detail which fields are 941 confidentiality protected. Identity protection is discussed in 942 Section 8.1. 944 Because EAP-IBAKE is not a tunneling method, EAP-Request/ 945 Notification, EAP-Response/Notification, EAP-Success, or EAP-Failure 946 packets are not confidentiality protected, integrity protected, or 947 replay protected. On physically insecure networks, this may enable 948 an attacker to mount denial-of-service attacks by spoofing these 949 packets. However, the peer will only accept EAP-Success after the 950 peer successfully authenticates the server. Hence, the attacker 951 cannot force the peer to believe that successful mutual 952 authentication has occurred before the peer successfully 953 authenticates the server, or after the peer fails to authenticate the 954 server. 956 An eavesdropper will see the EAP Notification, EAP-Success and EAP- 957 Failure packets sent in the clear. With EAP-IBAKE, confidential 958 information MUST NOT be transmitted in EAP Notification packets. 960 8.6. Trust Model 962 It is assumed that the KGFs that are used for deriving IBE private 963 keys are secure, not compromised, trusted, and will not engage in 964 launching active attacks independently or in a collaborative 965 environment. However, any malicious insider could potentially launch 966 passive attacks (by decryption of one or more message exchanges 967 offline). While it is in the best interest of administrators to 968 prevent such threats, it is hard to eliminate this problem. Hence, 969 it is assumed that such problems will persist, and hence the session 970 key agreement protocols are designed to protect participants from 971 passive adversaries. 973 The EAP peer and the EAP server need to trust their respective KGF 974 entities. Such a KGF may be owned/operated by third parties; in such 975 cases, the peer and the server need to maintain trust relationships 976 with those third parties. Note here that in scenarios where the EAP 977 peer and the EAP server are associated with the same KGF, while such 978 a KGF is owned by the server owner (or operator), there is no 979 implicit or explicit trust to third parties. 981 In addition, it is assumed that the communication between 982 participants and their respective KGFs is secure. Therefore, in any 983 implementation of the protocols described in this document, 984 administrators of any KGF have to ensure that communication with 985 participants is secure and not compromised. 987 8.7. Forward Secrecy 989 The MSK and EMSK are extracted from the session key, K_Session, which 990 is derived from exchanged Elliptic Curve Diffie-Hellman values. The 991 peer and the server choose random values with each run of the 992 protocol. Hence, even if an attacker is able to somehow obtain the 993 session key from an earlier run, the attacker will be unable to 994 determine any future session keys, or the MSK or EMSK. In other 995 words, EAP-IBAKE provides perfect forward secrecy. 997 8.8. Reflection Attacks 999 The use of identities within the encrypted payload is intended to 1000 eliminate some basic reflection attacks. For instance, suppose that 1001 identities were not used as part of the encrypted payload, in EAP- 1002 Request/IBAKE-Challenge message. Furthermore, assume an adversary 1003 who has access to the conversation between the server and peer and 1004 can actively snoop into packets and drop/modify them before routing 1005 them to the destination. As an example, consider the case where the 1006 IP source address and destination address can be modified by the 1007 adversary. After the EAP-Request/IBAKE-Challenge message is sent by 1008 the server (to the peer), the adversary can take over and trap the 1009 packet. Next, the adversary can modify the IP source address to 1010 include the adversary's IP address, before routing it onto the 1011 responder. The peer will assume that the request for an IBAKE 1012 session came from the adversary, and will send EAP-Response/ 1013 IBAKE-Challenge, but encrypt it using the adversary's public key. 1014 The above message can be decrypted by the adversary (and only by the 1015 adversary). In particular, since the EAP-Request/IBAKE-Challenge 1016 message includes the challenge sent by the server to the peer, the 1017 adversary will now learn the challenge sent by the server. Following 1018 this, the adversary can carry on a conversation with the server 1019 "pretending" to be the peer. This attack is eliminated with EAP- 1020 IBAKE, since identities are used as part of the encrypted payload. 1022 8.9. Negotiation Attacks 1024 EAP-IBAKE does not protect the EAP-Response/Nak packet. Given that 1025 EAP-IBAKE does not protect the EAP method negotiation, EAP method 1026 downgrading attacks may be possible. In addition, EAP-IBAKE does not 1027 support EAP-IBAKE protocol version negotiation. 1029 EAP-IBAKE supports ciphersuite negotiation through the use of 1030 Proposal payload during IBAKE-ID exchange. The ciphersuite proposal 1031 made by the server is not protected from tampering by an active 1032 attacker. However, the Proposal payload in EAP-Response/IBAKE-ID 1033 message containing the peers choice of ciphersuite is sent in the 1034 encrypted part of the message. Furthermore, if a proposal was 1035 modified by an active attacker, it would result in a failure to 1036 confirm the message sent by the other party, since the proposal is 1037 bound by each side into its Confirm message, and the protocol would 1038 fail as a result. 1040 9. Security Claims 1042 This section provides the security claims required by [RFC3748]. 1044 Authentication Mechanism: EAP-IBAKE is based on the IBAKE mechanism, 1045 which is an authentication and key agreement mechanism based on 1046 Identity Based Encryption. 1048 Ciphersuite negotiation: Yes 1050 Mutual authentication: Yes (Section 8.2) 1052 Integrity protection: Yes (Section 8.5) 1054 Replay protection: Yes (Section 8.5) 1056 Confidentiality: Yes, except method-specific failure indications 1057 (Section 8.5) 1059 Key derivation: Yes 1061 Key strength: EAP-IBAKE supports key derivation with 512-bit 1062 effective key strength. 1064 Description of key hierarchy: Please see Section 4. 1066 Dictionary attack protection: N/A (Section 8.4) 1068 Fast reconnect: No 1070 Cryptographic binding: Yes 1072 Session independence: Yes (Section 8.7) 1074 Fragmentation: Yes (Section 6) 1076 Channel binding: Yes 1078 Indication of vulnerabilities: Vulnerabilities are discussed in 1079 Section 8. 1081 10. References 1083 10.1. Normative References 1085 [FIPS186-2] 1086 NIST, "Digital Signature Standard", FIPS 186-2, 2000. 1088 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1089 Levkowetz, "Extensible Authentication Protocol (EAP)", 1090 RFC 3748, June 2004. 1092 [RFC5091] Boyen, X. and L. Martin, "Identity-Based Cryptography 1093 Standard (IBCS) #1: Supersingular Curve Implementations of 1094 the BF and BB1 Cryptosystems", RFC 5091, December 2007. 1096 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1097 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1098 May 2008. 1100 [RFC5408] Appenzeller, G., Martin, L., and M. Schertler, "Identity- 1101 Based Encryption Architecture and Supporting Data 1102 Structures", RFC 5408, January 2009. 1104 [SEC1] Standards for Efficient Cryptography Group, "Elliptic 1105 Curve Cryptography", September 2000. 1107 [SHA] Standards for Efficient Cryptography Group, "Secure Hash 1108 Standard", Federal Information Processing Standards 1109 Publication 180-2, August 2002, with Change Notice 1, 1110 February 2004. 1112 10.2. Informative References 1114 [I-D.cakulev-ibake] 1115 Cakulev, V., Sundaram, G., and I. Broustis, "IBAKE: 1116 Identity-Based Authenticated Key Exchange", 1117 draft-cakulev-ibake-06 (work in progress), November 2011. 1119 [IEEE-802.11] 1120 "Information technology - Telecommunications and 1121 information exchange between systems - Local and 1122 metropolitan area networks - Specific Requirements Part 1123 11: Wireless LAN Medium Access Control (MAC) and Physical 1124 Layer (PHY) Specifications", IEEE Standard 802.11-2007, 1125 2007. 1127 [IEEE-802.16] 1128 Institute of Electrical and Electronics Engineers, "IEEE 1129 Standard for Local and Metropolitan Area Networks: Part 1130 16: Air Interface for Fixed and Mobile Broadband Wireless 1131 Access Systems: Amendment for Physical and Medium Access 1132 Control Layers for Combined Fixed and Mobile Operations in 1133 Licensed Bands", IEEE 802.16e, August 2005. 1135 [IEEE-802.1X] 1136 Institute of Electrical and Electronics Engineers, "Local 1137 and Metropolitan Area Networks: Port-Based Network Access 1138 Control", IEEE Standard 802.1X-2004, December 2004. 1140 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 1141 RFC 1661, July 1994. 1143 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1144 Requirement Levels", BCP 14, RFC 2119, March 1997. 1146 [RFC5191] Forsberg, D., Ohba, Y., Patil, B., Tschofenig, H., and A. 1147 Yegin, "Protocol for Carrying Authentication for Network 1148 Access (PANA)", RFC 5191, May 2008. 1150 [RFC6267] Cakulev, V. and G. Sundaram, "MIKEY-IBAKE: Identity-Based 1151 Authenticated Key Exchange (IBAKE) Mode of Key 1152 Distribution in Multimedia Internet KEYing (MIKEY)", 1153 RFC 6267, June 2011. 1155 [SEC2] Standards for Efficient Cryptography Group, "SEC 2 - 1156 Recommended Elliptic Curve Domain Parameters", 1157 September 2000. 1159 Authors' Addresses 1161 Violeta Cakulev 1162 Alcatel Lucent 1163 600 Mountain Ave. 1164 3D-517 1165 Murray Hill, NJ 07974 1166 US 1168 Phone: +1 908 582 3207 1169 Email: violeta.cakulev@alcatel-lucent.com 1171 Ioannis Broustis 1172 AT&T Labs Research 1173 180 Park Ave. 1174 Building 103, Room E243 1175 Florham Park, NJ 07986 1176 US 1178 Phone: +1 973 360 7131 1179 Email: broustis@research.att.com