idnits 2.17.1 draft-eronen-ipsec-ikev2-eap-auth-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, 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 (October 20, 2009) is 5301 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 234, but not defined == Missing Reference: 'IDr' is mentioned on line 238, but not defined == Unused Reference: 'IEEE80211' is defined on line 418, but no explicit reference was found in the text == Unused Reference: 'RFC2865' is defined on line 437, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). 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 Expires: April 23, 2010 H. Tschofenig 5 Nokia Siemens Networks 6 Y. Sheffer 7 Check Point 8 October 20, 2009 10 An Extension for EAP-Only Authentication in IKEv2 11 draft-eronen-ipsec-ikev2-eap-auth-07.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. This document may contain material 17 from IETF Documents or IETF Contributions published or made publicly 18 available before November 10, 2008. The person(s) controlling the 19 copyright in some of this material may not have granted the IETF 20 Trust the right to allow modifications of such material outside the 21 IETF Standards Process. Without obtaining an adequate license from 22 the person(s) controlling the copyright in such materials, this 23 document may not be modified outside the IETF Standards Process, and 24 derivative works of it may not be created outside the IETF Standards 25 Process, except to format it for publication as an RFC or to 26 translate it into languages other than English. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 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 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on April 23, 2010. 46 Copyright Notice 48 Copyright (c) 2009 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 in effect on the date of 53 publication of this document (http://trustee.ietf.org/license-info). 54 Please review these documents carefully, as they describe your rights 55 and restrictions with respect to this document. 57 Abstract 59 IKEv2 specifies that EAP authentication must be used together with 60 public key signature based responder authentication. This is 61 necessary with old EAP methods that provide only unilateral 62 authentication using, e.g., one-time passwords or token cards. 64 This document specifies how EAP methods that provide mutual 65 authentication and key agreement can be used to provide extensible 66 responder authentication for IKEv2 based on methods other than public 67 key signatures. 69 1. Introduction 71 The Extensible Authentication Protocol (EAP), defined in [RFC4072], 72 is an authentication framework which supports multiple authentication 73 mechanisms. Today, EAP has been implemented at end hosts and routers 74 that connect via switched circuits or dial-up lines using PPP 75 [RFC1661], IEEE 802 wired switches [IEEE8021X], and IEEE 802.11 76 wireless access points [IEEE80211i]. 78 One of the advantages of the EAP architecture is its flexibility. 79 EAP is used to select a specific authentication mechanism, typically 80 after the authenticator requests more information in order to 81 determine the specific authentication method to be used. Rather than 82 requiring the authenticator (e.g., wireless LAN access point) to be 83 updated to support each new authentication method, EAP permits the 84 use of a backend authentication server which may implement some or 85 all authentication methods. 87 IKEv2 [RFC4306] is a component of IPsec used for performing mutual 88 authentication and establishing and maintaining security associations 89 for IPsec ESP and AH. In addition to supporting authentication using 90 public key signatures and shared secrets, IKEv2 also supports EAP 91 authentication. 93 IKEv2 provides EAP authentication since it was recognized that public 94 key signatures and shared secrets are not flexible enough to meet the 95 requirements of many deployment scenarios. By using EAP, IKEv2 can 96 leverage existing authentication infrastructure and credential 97 databases, since EAP allows users to choose a method suitable for 98 existing credentials, and also makes separation of the IKEv2 99 responder (VPN gateway) from the EAP authentication endpoint (backend 100 AAA server) easier. 102 Some older EAP methods are designed for unilateral authentication 103 only (that is, EAP peer to EAP server). These methods are used in 104 conjunction with IKEv2 public key based authentication of the 105 responder to the initiator. It is expected that this approach is 106 especially useful for "road warrior" VPN gateways that use, for 107 instance, one-time passwords or token cards to authenticate the 108 clients. 110 However, most newer EAP methods, such as those typically used with 111 IEEE 802.11i wireless LANs, provide mutual authentication and key 112 agreement. Currently, IKEv2 specifies that these EAP methods must 113 also be used together with public key signature based responder 114 authentication. 116 In some environments, requiring the deployment of PKI for just this 117 purpose can be counterproductive. Deploying new infrastructure can 118 be expensive, and it may weaken security by creating new 119 vulnerabilities. Mutually authenticating EAP methods alone can 120 provide a sufficient level of security in many circumstances, and 121 indeed, IEEE 802.11i uses EAP without any PKI for authenticating the 122 WLAN access points. 124 This document specifies how EAP methods that offer mutual 125 authentication and key agreement can be used to provide responder 126 authentication in IKEv2 completely based on EAP. 128 1.1. Terminology 130 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 131 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 132 document are to be interpreted as described in [RFC2119]. 134 2. Scenarios 136 In this section we describe two scenarios for extensible 137 authentication within IKEv2. These scenarios are intended to be 138 illustrative examples rather than specifying how things should be 139 done. 141 Figure 1 shows a configuration where the EAP and the IKEv2 endpoints 142 are co-located. Authenticating the IKEv2 responder using both EAP 143 and public key signatures is redundant. Offering EAP based 144 authentication has the advantage that multiple different 145 authentication and key exchange protocols are available with EAP with 146 different security properties (such as strong password based 147 protocols, protocols offering user identity confidentiality and many 148 more). As an example it is possible to use GSS-API support within 149 EAP [I-D.aboba-pppext-eapgss] to support Kerberos based 150 authentication which effectively replaces the need for KINK 151 [RFC4430]. 153 +------+-----+ +------------+ 154 O | IKEv2 | | IKEv2 | 155 /|\ | Initiator |<---////////////////////--->| Responder | 156 / \ +------------+ IKEv2 +------------+ 157 User | EAP Peer | Exchange | EAP Server | 158 +------------+ +------------+ 160 Figure 1: EAP and IKEv2 endpoints are co-located 162 Figure 2 shows a typical corporate network access scenario. The 163 initiator (client) interacts with the responder (VPN gateway) in the 164 corporate network. The EAP exchange within IKE runs between the 165 client and the home AAA server. As a result of a successful EAP 166 authentication protocol run, session keys are established and sent 167 from the AAA server to the VPN gateway, and then used to authenticate 168 the IKEv2 SA with AUTH payloads. 170 The protocol used between the VPN gateway and AAA server could be, 171 for instance, Diameter [RFC4072] or RADIUS [RFC3579]. See Section 5 172 for related security considerations. 174 +-------------------------------+ 175 | Corporate network | 176 | | 177 +-----------+ +--------+ | 178 | IKEv2 | AAA | Home | | 179 IKEv2 +////----->+ Responder +<---------->+ AAA | | 180 Exchange / | (VPN GW) | (RADIUS/ | Server | | 181 / +-----------+ Diameter) +--------+ | 182 / | carrying EAP | 183 | | | 184 | +-------------------------------+ 185 v 186 +------+-----+ 187 o | IKEv2 | 188 /|\ | Initiator | 189 / \ | VPN client | 190 User +------------+ 192 Figure 2: Corporate Network Access 194 3. Solution 196 IKEv2 specifies that when the EAP method establishes a shared secret 197 key, that key is used by both the initiator and responder to generate 198 an AUTH payload (thus authenticating the IKEv2 SA set up by messages 199 1 and 2). 201 When used together with public key responder authentication, the 202 responder is in effect authenticated using two different methods: the 203 public key signature AUTH payload in message 4, and the EAP-based 204 AUTH payload later. 206 If the initiator does not wish to use public key based responder 207 authentication, it includes an EAP_ONLY_AUTHENTICATION notification 208 payload (type TBD-BY-IANA) in message 3. The SPI size field is set 209 to zero, and there is no additional data associated with this 210 notification. 212 If the responder supports this notification, it omits the public key 213 based AUTH payload and CERT payloads from message 4. 215 If the responder does not support the EAP_ONLY_AUTHENTICATION 216 notification, it ignores the notification payload, and includes the 217 AUTH payload in message 4. In this case the initiator can, based on 218 its local policy, choose to either ignore the AUTH payload, or verify 219 it and any associated certificates as usual. 221 Both the initiator and responder MUST verify that the EAP method 222 actually used provided mutual authentication and established a shared 223 secret key. The AUTH payloads sent after EAP Success MUST use the 224 EAP-generated key, and MUST NOT use SK_pi or SK_pr. 226 An IKEv2 message exchange with this modification is shown below: 228 Initiator Responder 229 ----------- ----------- 230 HDR, SAi1, KEi, Ni, 231 [N(NAT_DETECTION_SOURCE_IP), 232 N(NAT_DETECTION_DESTINATION_IP)] --> 234 <-- HDR, SAr1, KEr, Nr, [CERTREQ], 235 [N(NAT_DETECTION_SOURCE_IP), 236 N(NAT_DETECTION_DESTINATION_IP)] 238 HDR, SK { IDi, [IDr], SAi2, TSi, TSr, 239 N(EAP_ONLY_AUTHENTICATION), 240 [CP(CFG_REQUEST)] } --> 242 <-- HDR, SK { IDr, EAP(Request) } 244 HDR, SK { EAP(Response) } --> 246 <-- HDR, SK { EAP(Request) } 248 HDR, SK { EAP(Response) } --> 250 <-- HDR, SK { EAP(Success) } 252 HDR, SK { AUTH } --> 254 <-- HDR, SK { AUTH, SAr2, TSi, TSr, 255 [CP(CFG_REPLY] } 257 The NAT detection and Configuration payloads are shown for 258 informative purposes only; they do not change how EAP authentication 259 works. 261 4. IANA considerations 263 This document defines a new IKEv2 Notification Payload type, 264 EAP_ONLY_AUTHENTICATION, described in Section 3. This payload must 265 be assigned a new type number from the "status types" range. 267 This document does not define any new namespaces to be managed by 268 IANA. 270 5. Security Considerations 272 Security considerations applicable to all EAP methods are discussed 273 in [RFC3748]. The EAP Key Management Framework [RFC5247] deals with 274 issues that arise when EAP is used as a part of a larger system. 276 5.1. Authentication of IKEv2 SA 278 It is important to note that the IKEv2 SA is not authenticated by 279 just running an EAP conversation: the crucial step is the AUTH 280 payload based on the EAP-generated key. Thus, EAP methods that do 281 not provide mutual authentication or establish a shared secret key 282 MUST NOT be used with the modifications presented in this document. 284 5.2. Authentication with separated IKEv2 responder/EAP server 286 As described in Section 2, the EAP conversation can terminate either 287 at the IKEv2 responder or at a backend AAA server. 289 If the EAP method is terminated at the IKEv2 responder then no key 290 transport via the AAA infrastructure is required. Pre-shared secret 291 and public key based authentication offered by IKEv2 is then replaced 292 by a wider range of authentication and key exchange methods. 294 However, typically EAP will be used with a backend AAA server. See 295 [RFC5247] for a more complete discussion of the related security 296 issues; here we provide only a short summary. 298 When a backend server is used, there are actually two authentication 299 exchanges: the EAP method between the client and the AAA server, and 300 another authentication between the AAA server and IKEv2 gateway. The 301 AAA server authenticates the client using the selected EAP method, 302 and they establish a session key. The AAA server then sends this key 303 to the IKEv2 gateway over a connection authenticated using, e.g., 304 IPsec or TLS. 306 Some EAP methods do not have any concept of pass-through 307 authenticator (e.g., NAS or IKEv2 gateway) identity, and these two 308 authentications remain quite independent of each other. That is, 309 after the client has verified the AUTH payload sent by the IKEv2 310 gateway, it knows that it is talking to SOME gateway trusted by the 311 home AAA server, but not which one. The situation is somewhat 312 similar if a single cryptographic hardware accelerator, containing a 313 single private key, would be shared between multiple IKEv2 gateways 314 (perhaps in some kind of cluster configuration). In particular, if 315 one of the gateways is compromised, it can impersonate any of the 316 other gateways towards the user (until the compromise is discovered 317 and access rights revoked). 319 In some environments it is not desirable to trust the IKEv2 gateways 320 this much (also known as the "Lying NAS Problem"). EAP methods that 321 provide what is called "connection binding" or "channel binding" 322 transport some identity or identities of the gateway (or WLAN access 323 point/NAS) inside the EAP method. Then the AAA server can check that 324 it is indeed sending the key to the gateway expected by the client. 325 A potential solution is described in 326 [I-D.arkko-eap-service-identity-auth]. 328 In some deployment configurations, AAA proxies may be present between 329 the IKEv2 gateway and the backend AAA server. These AAA proxies MUST 330 be trusted for secure operation, and therefore SHOULD be avoided when 331 possible; see [RFC4072] and [RFC5247] for more discussion. 333 5.3. Protection of EAP payloads 335 Although the EAP payloads are encrypted and integrity protected with 336 SK_e/SK_a, this does not provide any protection against active 337 attackers. Until the AUTH payload has been received and verified, a 338 man-in-the-middle can change the KEi/KEr payloads and eavesdrop or 339 modify the EAP payloads. 341 In IEEE 802.11i wireless LANs, the EAP payloads are neither encrypted 342 nor integrity protected (by the link layer), so EAP methods are 343 typically designed to take that into account. 345 In particular, EAP methods that are vulnerable to dictionary attacks 346 when used in WLANs are still vulnerable (to active attackers) when 347 run inside IKEv2. 349 5.4. User identity confidentiality 351 IKEv2 provides confidentiality for the initiator identity against 352 passive eavesdroppers, but not against active attackers. The 353 initiator announces its identity first (in message #3), before the 354 responder has been authenticated. The usage of EAP in IKEv2 does not 355 change this situation, since the ID payload in message #3 is used 356 instead of the EAP Identity Request/Response exchange. This is 357 somewhat unfortunate since when EAP is used with public key 358 authentication of the responder, it would be possible to provide 359 active user identity confidentiality for the initiator. 361 IKEv2 protects the responder's identity even against active attacks. 363 This property cannot be provided when using EAP. If public key 364 responder authentication is used in addition to EAP, the responder 365 reveals its identity before authenticating the initiator. If only 366 EAP is used (as proposed in this document), the situation depends on 367 the EAP method used (in some EAP methods, the server reveals its 368 identity first). 370 Hence, if active user identity confidentiality for the initiator is 371 required then EAP methods that offer this functionality have to be 372 used (see [RFC3748], Section 7.3). 374 6. Acknowledgments 376 This document borrows some text from [RFC3748], [RFC4306], and 377 [RFC4072]. We would also like to thank Hugo Krawczyk for interesting 378 discussions about this topic. 380 7. References 382 7.1. Normative References 384 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 385 Levkowetz, "Extensible Authentication Protocol (EAP)", 386 RFC 3748, June 2004. 388 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 389 Requirement Levels", RFC 2119, March 1997. 391 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 392 RFC 4306, December 2005. 394 [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 395 Authentication Protocol (EAP) Application", RFC 4072, 396 August 2005. 398 7.2. Informative References 400 [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication 401 Dial In User Service) Support For Extensible 402 Authentication Protocol (EAP)", RFC 3579, September 2003. 404 [I-D.aboba-pppext-eapgss] 405 Aboba, B. and D. Simon, "EAP GSS Authentication Protocol", 406 draft-aboba-pppext-eapgss-12 (work in progress), 407 April 2002. 409 [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible 410 Authentication Protocol (EAP) Key Management Framework", 411 RFC 5247, August 2008. 413 [IEEE8021X] 414 Institute of Electrical and Electronics Engineers, "Local 415 and Metropolitan Area Networks: Port-Based Network Access 416 Control", IEEE Standard 802.1X-2001, 2001. 418 [IEEE80211] 419 Institute of Electrical and Electronics Engineers, 420 "Information technology - Telecommunications and 421 information exchange between systems - Local and 422 metropolitan area networks - Specific Requirements Part 423 11: Wireless LAN Medium Access Control (MAC) and Physical 424 Layer (PHY) Specifications", IEEE Standard 802.11-1999, 425 1999. 427 [IEEE80211i] 428 Institute of Electrical and Electronics Engineers, "IEEE 429 Standard for Information technology - Telecommunications 430 and information exchange between systems - Local and 431 metropolitan area networks - Specific requirements - Part 432 11: Wireless Medium Access Control (MAC) and Physical 433 Layer (PHY) specifications: Amendment 6: Medium Access 434 Control (MAC) Security Enhancements", IEEE 435 Standard 802.11i-2004, July 2004. 437 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 438 "Remote Authentication Dial In User Service (RADIUS)", 439 RFC 2865, June 2000. 441 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 442 RFC 1661, July 1994. 444 [RFC4430] Sakane, S., Kamada, K., Thomas, M., and J. Vilhuber, 445 "Kerberized Internet Negotiation of Keys (KINK)", 446 RFC 4430, March 2006. 448 [I-D.arkko-eap-service-identity-auth] 449 Arkko, J. and P. Eronen, "Authenticated Service 450 Information for the Extensible Authentication Protocol 451 (EAP)", draft-arkko-eap-service-identity-auth-04 (work in 452 progress), October 2005. 454 Appendix A. Alternative Approaches 456 In this section we list alternatives which have been considered 457 during the work on this document. We concluded that the solution 458 presented in Section 3 seems to fit better into IKEv2. 460 A.1. Ignore AUTH payload at the initiator 462 With this approach, the initiator simply ignores the AUTH payload in 463 message #4 (but obviously must check the second AUTH payload later!). 464 The main advantage of this approach is that no protocol modifications 465 are required and no signature verification is required. 467 The initiator could signal to the responder (using a notification 468 payload) that it did not verify the first AUTH payload. 470 A.2. Unauthenticated public keys in AUTH payload (message 4) 472 Another solution approach suggests the use of unauthenticated public 473 keys in the public key signature AUTH payload (for message 4). 475 That is, the initiator verifies the signature in the AUTH payload, 476 but does not verify that the public key indeed belongs to the 477 intended party (using certificates)--since it doesn't have a PKI that 478 would allow this. This could be used with X.509 certificates (the 479 initiator ignores all other fields of the certificate except the 480 public key), or "Raw RSA Key" CERT payloads. 482 This approach has the advantage that initiators that wish to perform 483 certificate-based responder authentication (in addition to EAP) may 484 do so, without requiring the responder to handle these cases 485 separately. 487 If using RSA, the overhead of signature verification is quite small, 488 compared to g^xy calculation. 490 A.3. Using EAP derived session keys for IKEv2 492 It has been proposed that when using an EAP method that provides 493 mutual authentication and key agreement, the IKEv2 Diffie-Hellman 494 exchange could also be omitted. This would mean that the session 495 keys for IPsec SAs established later would rely only on EAP-provided 496 keys. 498 It seems the only benefit of this approach is saving some computation 499 time (g^xy calculation). This approach requires designing a 500 completely new protocol (which would not resemble IKEv2 anymore) we 501 do not believe that it should be considered. Nevertheless, we 502 include it for completeness. 504 Authors' Addresses 506 Pasi Eronen 507 Nokia Research Center 508 P.O. Box 407 509 FIN-00045 Nokia Group 510 Finland 512 Email: pasi.eronen@nokia.com 514 Hannes Tschofenig 515 Nokia Siemens Networks 516 Linnoitustie 6 517 Espoo 02600 518 Finland 520 Phone: +358 (50) 4871445 521 Email: Hannes.Tschofenig@gmx.net 522 URI: http://www.tschofenig.priv.at 524 Yaron Sheffer 525 Check Point Software Technologies Ltd. 526 5 Hasolelim St. 527 Tel Aviv 67897 528 Israel 530 Email: yaronf@checkpoint.com