idnits 2.17.1 draft-ietf-ipsecme-eap-mutual-05.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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 25, 2010) is 5044 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CERTREQ' is mentioned on line 256, but not defined == Missing Reference: 'IDr' is mentioned on line 260, but not defined ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) == Outdated reference: A later version (-09) exists of draft-sheffer-emu-eap-eke-07 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Eronen 3 Internet-Draft Nokia 4 Intended status: Standards Track H. Tschofenig 5 Expires: December 27, 2010 Nokia Siemens Networks 6 Y. Sheffer 7 Independent 8 June 25, 2010 10 An Extension for EAP-Only Authentication in IKEv2 11 draft-ietf-ipsecme-eap-mutual-05.txt 13 Abstract 15 IKEv2 specifies that EAP authentication must be used together with 16 public key signature based responder authentication. This is 17 necessary with old EAP methods that provide only unilateral 18 authentication using, e.g., one-time passwords or token cards. 20 This document specifies how EAP methods that provide mutual 21 authentication and key agreement can be used to provide extensible 22 responder authentication for IKEv2 based on methods other than public 23 key signatures. 25 Note to RFC Editor: this document updates 26 draft-ietf-ipsecme-ikev2bis, and therefore depends on that document. 27 Please add "Updates: RFCxxxx" to the title page, where "xxxx" is the 28 RFC number assigned to IKEv2-bis. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on December 27, 2010. 47 Copyright Notice 48 Copyright (c) 2010 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 1. Introduction 75 The Extensible Authentication Protocol (EAP), defined in [RFC4072], 76 is an authentication framework which supports multiple authentication 77 mechanisms. Today, EAP has been implemented at end hosts and routers 78 that connect via switched circuits or dial-up lines using PPP 79 [RFC1661], IEEE 802 wired switches [IEEE8021X], and IEEE 802.11 80 wireless access points [IEEE80211i]. 82 One of the advantages of the EAP architecture is its flexibility. 83 EAP is used to select a specific authentication mechanism, typically 84 after the authenticator requests more information in order to 85 determine the specific authentication method to be used. Rather than 86 requiring the authenticator (e.g., wireless LAN access point) to be 87 updated to support each new authentication method, EAP permits the 88 use of a backend authentication server which may implement some or 89 all authentication methods. 91 IKEv2 ([RFC4306] and [I-D.ietf-ipsecme-ikev2bis]) is a component of 92 IPsec used for performing mutual authentication and establishing and 93 maintaining security associations for IPsec ESP and AH. In addition 94 to supporting authentication using public key signatures and shared 95 secrets, IKEv2 also supports EAP authentication. 97 IKEv2 provides EAP authentication since it was recognized that public 98 key signatures and shared secrets are not flexible enough to meet the 99 requirements of many deployment scenarios. By using EAP, IKEv2 can 100 leverage existing authentication infrastructure and credential 101 databases, since EAP allows users to choose a method suitable for 102 existing credentials, and also makes separation of the IKEv2 103 responder (VPN gateway) from the EAP authentication endpoint (backend 104 AAA server) easier. 106 Some older EAP methods are designed for unilateral authentication 107 only (that is, EAP peer to EAP server). These methods are used in 108 conjunction with IKEv2 public key based authentication of the 109 responder to the initiator. It is expected that this approach is 110 especially useful for "road warrior" VPN gateways that use, for 111 instance, one-time passwords or token cards to authenticate the 112 clients. 114 However, most newer EAP methods, such as those typically used with 115 IEEE 802.11i wireless LANs, provide mutual authentication and key 116 agreement. Currently, IKEv2 specifies that these EAP methods must 117 also be used together with public key signature based responder 118 authentication. 120 In order for the public key signature authentication of the gateway 121 to be effective, a deployment of PKI is required, which has to 122 include management of trust anchors on all supplicants. In many 123 environments, this is not realistic, and the security of the gateway 124 public key is the same as the security of a self-signed certificate. 125 Mutually authenticating EAP methods alone can provide a sufficient 126 level of security in many circumstances, and in fact in some 127 deployments, IEEE 802.11i uses EAP without any PKI for authenticating 128 the WLAN access points. 130 This document specifies how EAP methods that offer mutual 131 authentication and key agreement can be used to provide responder 132 authentication in IKEv2 completely based on EAP. 134 1.1. Terminology 136 All notation in this protocol extension is taken from [RFC4306]. 138 Numbered messages refer to the IKEv2 message sequence when using EAP. 139 Thus: 141 o Message 1 is the request message of IKE_SA_INIT. 143 o Message 2 is the response message of IKE_SA_INIT. 145 o Message 3 is the first request of IKE_AUTH. 147 o Message 4 is the first response of IKE_AUTH. 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in [RFC2119]. 153 2. Scenarios 155 In this section we describe two scenarios for extensible 156 authentication within IKEv2. These scenarios are intended to be 157 illustrative examples rather than specifying how things should be 158 done. 160 Figure 1 shows a configuration where the EAP and the IKEv2 endpoints 161 are co-located. Authenticating the IKEv2 responder using both EAP 162 and public key signatures is redundant. Offering EAP based 163 authentication has the advantage that multiple different 164 authentication and key exchange protocols are available with EAP with 165 different security properties (such as strong password based 166 protocols, protocols offering user identity confidentiality and many 167 more). 169 +------+-----+ +------------+ 170 O | IKEv2 | | IKEv2 | 171 /|\ | Initiator |<---////////////////////--->| Responder | 172 / \ +------------+ IKEv2 +------------+ 173 User | EAP Peer | Exchange | EAP Server | 174 +------------+ +------------+ 176 Figure 1: EAP and IKEv2 endpoints are co-located 178 Figure 2 shows a typical corporate network access scenario. The 179 initiator (client) interacts with the responder (VPN gateway) in the 180 corporate network. The EAP exchange within IKE runs between the 181 client and the home AAA server. As a result of a successful EAP 182 authentication protocol run, session keys are established and sent 183 from the AAA server to the VPN gateway, and then used to authenticate 184 the IKEv2 SA with AUTH payloads. 186 The protocol used between the VPN gateway and AAA server could be, 187 for instance, Diameter [RFC4072] or RADIUS [RFC3579]. See Section 6 188 for related security considerations. 190 +-------------------------------+ 191 | Corporate network | 192 | | 193 +-----------+ +--------+ | 194 | IKEv2 | AAA | Home | | 195 IKEv2 +////----->+ Responder +<---------->+ AAA | | 196 Exchange / | (VPN GW) | (RADIUS/ | Server | | 197 / +-----------+ Diameter) +--------+ | 198 / | carrying EAP | 199 | | | 200 | +-------------------------------+ 201 v 202 +------+-----+ 203 o | IKEv2 | 204 /|\ | Initiator | 205 / \ | VPN client | 206 User +------------+ 208 Figure 2: Corporate Network Access 210 3. Solution 212 IKEv2 specifies that when the EAP method establishes a shared secret 213 key, that key is used by both the initiator and responder to generate 214 an AUTH payload (thus authenticating the IKEv2 SA set up by messages 215 1 and 2). 217 When used together with public key responder authentication, the 218 responder is in effect authenticated using two different methods: the 219 public key signature AUTH payload in message 4, and the EAP-based 220 AUTH payload later. 222 If the initiator does not wish to use public key based responder 223 authentication, it includes an EAP_ONLY_AUTHENTICATION notification 224 payload (type TBD-BY-IANA) in message 3. The Protocol ID and SPI 225 size fields are set to zero, and there is no additional data 226 associated with this notification. 228 If the responder supports this notification and chooses to use it, it 229 omits the public key based AUTH payload and CERT payloads from 230 message 4. 232 If the responder does not support the EAP_ONLY_AUTHENTICATION 233 notification or does not wish to use it, it ignores the notification 234 payload, and includes the AUTH payload in message 4. In this case 235 the initiator MUST verify that payload and any associated 236 certificates, as per [RFC4306]. 238 When receiving message 4, the initiator MUST verify that the proposed 239 EAP method is allowed by this specification, and MUST abort the 240 protocol immediately otherwise. 242 Both the initiator and responder MUST verify that the EAP method 243 actually used provided mutual authentication and established a shared 244 secret key. The AUTH payloads sent after EAP Success MUST use the 245 EAP-generated key, and MUST NOT use SK_pi or SK_pr (see Sec. 2.15 of 246 [I-D.ietf-ipsecme-ikev2bis]). 248 An IKEv2 message exchange with this modification is shown below: 250 Initiator Responder 251 ----------- ----------- 252 HDR, SAi1, KEi, Ni, 253 [N(NAT_DETECTION_SOURCE_IP), 254 N(NAT_DETECTION_DESTINATION_IP)] --> 256 <-- HDR, SAr1, KEr, Nr, [CERTREQ], 257 [N(NAT_DETECTION_SOURCE_IP), 258 N(NAT_DETECTION_DESTINATION_IP)] 260 HDR, SK { IDi, [IDr], SAi2, TSi, TSr, 261 N(EAP_ONLY_AUTHENTICATION), 262 [CP(CFG_REQUEST)] } --> 264 <-- HDR, SK { IDr, EAP(Request) } 266 HDR, SK { EAP(Response) } --> 268 <-- HDR, SK { EAP(Request) } 270 HDR, SK { EAP(Response) } --> 272 <-- HDR, SK { EAP(Success) } 274 HDR, SK { AUTH } --> 276 <-- HDR, SK { AUTH, SAr2, TSi, TSr, 277 [CP(CFG_REPLY] } 279 Note: all notation in the above protocol sequence and elsewhere in 280 this specification is as defined in [RFC4306], and see in particular 281 Sec. 1.2 of [RFC4306] for payload types. 283 The NAT detection and Configuration payloads are shown for 284 informative purposes only; they do not change how EAP authentication 285 works. 287 An IKE SA that was set up with this extension can be resumed using 288 the mechanism described in [RFC5723]. However session resumption 289 does not change the authentication method. Therefore during the 290 IKE_AUTH exchange of the resumed session, this extension MUST NOT be 291 sent by the initiator. 293 4. Safe EAP Methods 295 EAP methods to be used with this extension MUST have the following 296 properties: 298 1. The method provides mutual authentication of the peers. 300 2. The method is key-generating. 302 3. The method is resistant to dictionary attack. 304 The authors believe that the following EAP methods are secure when 305 used with the current extension. The list is not inclusive, and 306 there are likely other safe methods which have not been listed here. 308 +---------------------+--------------+------------------------------+ 309 | Method Name | Allows | Reference | 310 | | Channel | | 311 | | Binding? | | 312 +---------------------+--------------+------------------------------+ 313 | EAP-SIM | No | [RFC4186] | 314 | EAP-AKA | Yes | [RFC4187] | 315 | EAP-AKA' | Yes | [RFC5448] | 316 | EAP-GPSK | Yes | [RFC5433] | 317 | EAP-pwd | No | [I-D.harkins-emu-eap-pwd] | 318 | EAP-EKE | Yes | [I-D.sheffer-emu-eap-eke] | 319 | EAP-PAX | Yes | [RFC4746] | 320 | EAP-SAKE | No | [RFC4763] | 321 | EAP-SRP | No | [I-D.ietf-pppext-eap-srp-03] | 322 | EAP-POTP (mutual | Yes | [RFC4793] | 323 | authentication | | | 324 | variant) | | | 325 | EAP-TLS | No | [RFC5216] | 326 | EAP-FAST | No | [RFC4851] | 327 | EAP-TTLS | No | [RFC5281] | 328 +---------------------+--------------+------------------------------+ 330 The "Allows channel binding?" column denotes protocols where 331 protected identity information may be sent between the EAP endpoints. 332 This third, optional property of the method provides protection 333 against certain types of attacks (see Section 6.2 for an 334 explanation), and therefore in some scenarios, methods that allow for 335 channel binding are to be preferred. It is noted that at the time of 336 writing, even when such capabilities are provided, they are not fully 337 specified in an interoperable manner. In particular, no RFC 338 specifies what identities should be sent under the protection of the 339 channel binding mechanism, or what policy is to be used to correlate 340 identities at the different layers. 342 5. IANA considerations 344 This document defines a new IKEv2 Notification Payload type, 345 EAP_ONLY_AUTHENTICATION, described in Section 3. This payload must 346 be assigned a new type number from the "status types" range. 348 6. Security Considerations 350 Security considerations applicable to all EAP methods are discussed 351 in [RFC3748]. The EAP Key Management Framework [RFC5247] deals with 352 issues that arise when EAP is used as a part of a larger system. 354 6.1. Authentication of IKEv2 SA 356 It is important to note that the IKEv2 SA is not authenticated by 357 just running an EAP conversation: the crucial step is the AUTH 358 payload based on the EAP-generated key. Thus, EAP methods that do 359 not provide mutual authentication or establish a shared secret key 360 MUST NOT be used with the modifications presented in this document. 362 6.2. Authentication with separated IKEv2 responder/EAP server 364 As described in Section 2, the EAP conversation can terminate either 365 at the IKEv2 responder or at a backend AAA server. 367 If the EAP method is terminated at the IKEv2 responder then no key 368 transport via the AAA infrastructure is required. Pre-shared secret 369 and public key based authentication offered by IKEv2 is then replaced 370 by a wider range of authentication and key exchange methods. 372 However, typically EAP will be used with a backend AAA server. See 373 [RFC5247] for a more complete discussion of the related security 374 issues; here we provide only a short summary. 376 When a backend server is used, there are actually two authentication 377 exchanges: the EAP method between the client and the AAA server, and 378 another authentication between the AAA server and IKEv2 gateway. The 379 AAA server authenticates the client using the selected EAP method, 380 and they establish a session key. The AAA server then sends this key 381 to the IKEv2 gateway over a connection authenticated using, e.g., 382 IPsec or TLS. 384 Some EAP methods do not have any concept of pass-through 385 authenticator (e.g., NAS or IKEv2 gateway) identity, and these two 386 authentications remain quite independent of each other. That is, 387 after the client has verified the AUTH payload sent by the IKEv2 388 gateway, it knows that it is talking to SOME gateway trusted by the 389 home AAA server, but not which one. The situation is somewhat 390 similar if a single cryptographic hardware accelerator, containing a 391 single private key, would be shared between multiple IKEv2 gateways 392 (perhaps in some kind of cluster configuration). In particular, if 393 one of the gateways is compromised, it can impersonate any of the 394 other gateways towards the user (until the compromise is discovered 395 and access rights revoked). 397 In some environments it is not desirable to trust the IKEv2 gateways 398 this much (also known as the "Lying NAS Problem"). EAP methods that 399 provide what is called "connection binding" or "channel binding" 400 transport some identity or identities of the gateway (or WLAN access 401 point/NAS) inside the EAP method. Then the AAA server can check that 402 it is indeed sending the key to the gateway expected by the client. 403 A potential solution is described in 404 [I-D.arkko-eap-service-identity-auth], and see also 405 [I-D.clancy-emu-aaapay]. 407 In some deployment configurations, AAA proxies may be present between 408 the IKEv2 gateway and the backend AAA server. These AAA proxies MUST 409 be trusted for secure operation, and therefore SHOULD be avoided when 410 possible; see Sec. 2.3.4 of [RFC4072] Sec. 4.3.7 of [RFC3579] for 411 more discussion. 413 6.3. Protection of EAP payloads 415 Although the EAP payloads are encrypted and integrity protected with 416 SK_e/SK_a, this does not provide any protection against active 417 attackers. Until the AUTH payload has been received and verified, a 418 man-in-the-middle can change the KEi/KEr payloads and eavesdrop or 419 modify the EAP payloads. 421 In IEEE 802.11i wireless LANs, the EAP payloads are neither encrypted 422 nor integrity protected (by the link layer), so EAP methods are 423 typically designed to take that into account. 425 In particular, EAP methods that are vulnerable to dictionary attacks 426 when used in WLANs are still vulnerable (to active attackers) when 427 run inside IKEv2. 429 The rules in Section 4 are designed to avoid this potential 430 vulnerability. 432 6.4. Identities and Authenticated Identities 434 When using this protocol, each of the peers sends two identity 435 values: 437 1. An identity contained in the IKE ID payload. 439 2. An identity transferred within the specific EAP method's 440 messages. 442 (IKEv2 omits the EAP Identity request/response pair, see Sec. 3.16 of 443 [I-D.ietf-ipsecme-ikev2bis].) The first identity value can be used 444 by the recipient to route AAA messages and/or to select 445 authentication and EAP types. But it is only the second identity 446 that is directly authenticated by the EAP method. The reader is 447 referred to Sec. 2.16 of [I-D.ietf-ipsecme-ikev2bis] regarding the 448 need to base IPsec policy decisions on the authenticated identity. 449 In the context of the extension described here, this guidance on 450 IPsec policy applies both to the authentication of the client by the 451 gateway and vice versa. 453 6.5. User identity confidentiality 455 IKEv2 provides confidentiality for the initiator identity against 456 passive eavesdroppers, but not against active attackers. The 457 initiator announces its identity first (in message 3), before the 458 responder has been authenticated. The usage of EAP in IKEv2 does not 459 change this situation, since the ID payload in message 3 is used 460 instead of the EAP Identity Request/Response exchange. This is 461 somewhat unfortunate since when EAP is used with public key 462 authentication of the responder, it would be possible to provide 463 active user identity confidentiality for the initiator. 465 IKEv2 protects the responder's identity even against active attacks. 466 This property cannot be provided when using EAP. If public key 467 responder authentication is used in addition to EAP, the responder 468 reveals its identity before authenticating the initiator. If only 469 EAP is used (as proposed in this document), the situation depends on 470 the EAP method used (in some EAP methods, the server reveals its 471 identity first). 473 Hence, if active user identity confidentiality for the responder is 474 required then EAP methods that offer this functionality have to be 475 used (see [RFC3748], Section 7.3). 477 7. Acknowledgments 479 This document borrows some text from [RFC3748], [RFC4306], and 480 [RFC4072]. We would also like to thank Hugo Krawczyk for interesting 481 discussions about this topic, Dan Harkins and David Harrington for 482 their comments. 484 8. References 486 8.1. Normative References 488 [I-D.ietf-ipsecme-ikev2bis] 489 Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 490 "Internet Key Exchange Protocol: IKEv2", 491 draft-ietf-ipsecme-ikev2bis-11 (work in progress), 492 May 2010. 494 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 495 Requirement Levels", BCP 14, RFC 2119, March 1997. 497 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 498 Levkowetz, "Extensible Authentication Protocol (EAP)", 499 RFC 3748, June 2004. 501 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 502 Authentication Protocol (EAP) Application", RFC 4072, 503 August 2005. 505 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 506 RFC 4306, December 2005. 508 [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange 509 Protocol Version 2 (IKEv2) Session Resumption", RFC 5723, 510 January 2010. 512 8.2. Informative References 514 [I-D.arkko-eap-service-identity-auth] 515 Arkko, J. and P. Eronen, "Authenticated Service 516 Information for the Extensible Authentication Protocol 517 (EAP)", draft-arkko-eap-service-identity-auth-04 (work in 518 progress), October 2005. 520 [I-D.clancy-emu-aaapay] 521 Clancy, C., Lior, A., Zorn, G., and K. Hoeper, "EAP Method 522 Support for Transporting AAA Payloads", 523 draft-clancy-emu-aaapay-04 (work in progress), May 2010. 525 [I-D.harkins-emu-eap-pwd] 526 Harkins, D. and G. Zorn, "EAP Authentication Using Only A 527 Password", draft-harkins-emu-eap-pwd-14 (work in 528 progress), April 2010. 530 [I-D.ietf-pppext-eap-srp-03] 531 Carlson, J., Aboba, B., and H. Haverinen, "EAP SRP-SHA1 532 Authentication Protocol", draft-ietf-pppext-eap-srp-03 533 (work in progress), July 2001. 535 [I-D.sheffer-emu-eap-eke] 536 Sheffer, Y., Zorn, G., Tschofenig, H., and S. Fluhrer, "An 537 EAP Authentication Method Based on the EKE Protocol", 538 draft-sheffer-emu-eap-eke-07 (work in progress), 539 June 2010. 541 [IEEE80211i] 542 Institute of Electrical and Electronics Engineers, "IEEE 543 Standard for Information technology - Telecommunications 544 and information exchange between systems - Local and 545 metropolitan area networks - Specific requirements - Part 546 11: Wireless Medium Access Control (MAC) and Physical 547 Layer (PHY) specifications: Amendment 6: Medium Access 548 Control (MAC) Security Enhancements", IEEE 549 Standard 802.11i-2004, July 2004. 551 [IEEE8021X] 552 Institute of Electrical and Electronics Engineers, "Local 553 and Metropolitan Area Networks: Port-Based Network Access 554 Control", IEEE Standard 802.1X-2001, 2001. 556 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 557 RFC 1661, July 1994. 559 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 560 Dial In User Service) Support For Extensible 561 Authentication Protocol (EAP)", RFC 3579, September 2003. 563 [RFC4186] Haverinen, H. and J. Salowey, "Extensible Authentication 564 Protocol Method for Global System for Mobile 565 Communications (GSM) Subscriber Identity Modules (EAP- 566 SIM)", RFC 4186, January 2006. 568 [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication 569 Protocol Method for 3rd Generation Authentication and Key 570 Agreement (EAP-AKA)", RFC 4187, January 2006. 572 [RFC4746] Clancy, T. and W. Arbaugh, "Extensible Authentication 573 Protocol (EAP) Password Authenticated Exchange", RFC 4746, 574 November 2006. 576 [RFC4763] Vanderveen, M. and H. Soliman, "Extensible Authentication 577 Protocol Method for Shared-secret Authentication and Key 578 Establishment (EAP-SAKE)", RFC 4763, November 2006. 580 [RFC4793] Nystroem, M., "The EAP Protected One-Time Password 581 Protocol (EAP-POTP)", RFC 4793, February 2007. 583 [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, "The 584 Flexible Authentication via Secure Tunneling Extensible 585 Authentication Protocol Method (EAP-FAST)", RFC 4851, 586 May 2007. 588 [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS 589 Authentication Protocol", RFC 5216, March 2008. 591 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 592 Authentication Protocol (EAP) Key Management Framework", 593 RFC 5247, August 2008. 595 [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible Authentication 596 Protocol Tunneled Transport Layer Security Authenticated 597 Protocol Version 0 (EAP-TTLSv0)", RFC 5281, August 2008. 599 [RFC5433] Clancy, T. and H. Tschofenig, "Extensible Authentication 600 Protocol - Generalized Pre-Shared Key (EAP-GPSK) Method", 601 RFC 5433, February 2009. 603 [RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved 604 Extensible Authentication Protocol Method for 3rd 605 Generation Authentication and Key Agreement (EAP-AKA')", 606 RFC 5448, May 2009. 608 Appendix A. Change Log 610 Note to RFC Editor: please remove this section prior to publication. 612 A.1. -05 614 Implemented IESG review comments from David Harrington and Adrian 615 Farrel. In particular, this document updates 616 [I-D.ietf-ipsecme-ikev2bis]. Added a paragraph on interaction with 617 IKE session resumption. 619 A.2. -04 621 Anti-nit. 623 A.3. -03 625 Implemented IETF LC comments from Dan Harkins and Tero Kivinen. 627 A.4. -02 629 Implemented several WGLC comments. EAP methods are required to be 630 resistant to dictionary attacks to be used here. 632 A.5. -01 634 List of proposed EAP methods is now informative, not normative. 636 A.6. draft-ietf-ipsecme-mutual-auth-00 638 Initial WG draft, based on draft-eronen-ipsec-ikev2-eap-auth-07, with 639 the following changes: if the responder does not support this 640 mechanism, the initiator reverts to normal RFC 4306 behavior; the 641 initiator must abort immediately if it doesn't like the proposed EAP 642 method; allowed EAP methods are explicitly listed. 644 Appendix B. Alternative Approaches 646 In this section we list alternatives which have been considered 647 during the work on this document. We concluded that the solution 648 presented in Section 3 seems to fit better into IKEv2. 650 B.1. Ignore AUTH payload at the initiator 652 With this approach, the initiator simply ignores the AUTH payload in 653 message 4 (but obviously must check the second AUTH payload later!). 654 The main advantage of this approach is that no protocol modifications 655 are required and no signature verification is required. A 656 significant disadvantage is that the EAP method to be used cannot be 657 selected to take this behavior into account. 659 The initiator could signal to the responder (using a notification 660 payload) that it did not verify the first AUTH payload. 662 B.2. Unauthenticated public keys in AUTH payload (message 4) 664 Another solution approach suggests the use of unauthenticated public 665 keys in the public key signature AUTH payload (for message 4). 667 That is, the initiator verifies the signature in the AUTH payload, 668 but does not verify that the public key indeed belongs to the 669 intended party (using certificates)--since it doesn't have a PKI that 670 would allow this. This could be used with X.509 certificates (the 671 initiator ignores all other fields of the certificate except the 672 public key), or "Raw RSA Key" CERT payloads. 674 This approach has the advantage that initiators that wish to perform 675 certificate-based responder authentication (in addition to EAP) may 676 do so, without requiring the responder to handle these cases 677 separately. A disadvantage here, again, is that the EAP method 678 selection cannot take into account the incomplete validation of the 679 responder's certificate. 681 If using RSA, the overhead of signature verification is quite small, 682 compared to the g^xy calculation required by the Diffie-Hellman 683 exchange. 685 B.3. Using EAP derived session keys for IKEv2 687 It has been proposed that when using an EAP method that provides 688 mutual authentication and key agreement, the IKEv2 Diffie-Hellman 689 exchange could also be omitted. This would mean that the session 690 keys for IPsec SAs established later would rely only on EAP-provided 691 keys. 693 It seems the only benefit of this approach is saving some computation 694 time (g^xy calculation). This approach requires designing a 695 completely new protocol (which would not resemble IKEv2 anymore) we 696 do not believe that it should be considered. Nevertheless, we 697 include it for completeness. 699 Authors' Addresses 701 Pasi Eronen 702 Nokia Research Center 703 P.O. Box 407 704 FIN-00045 Nokia Group 705 Finland 707 Email: pasi.eronen@nokia.com 709 Hannes Tschofenig 710 Nokia Siemens Networks 711 Linnoitustie 6 712 Espoo 02600 713 Finland 715 Phone: +358 (50) 4871445 716 Email: Hannes.Tschofenig@gmx.net 717 URI: http://www.tschofenig.priv.at 719 Yaron Sheffer 720 Independent 722 Email: yaronf.ietf@gmail.com