| |
| |
| |
| |
| |
| |
| Internet Engineering Task Force (IETF) P. Eronen |
| Request for Comments: 5998 Independent |
| Updates: 5996 H. Tschofenig |
| Category: Standards Track Nokia Siemens Networks |
| ISSN: 2070-1721 Y. Sheffer |
| Independent |
| September 2010 |
| |
| |
| An Extension for EAP-Only Authentication in IKEv2 |
| |
| Abstract |
| |
| IKEv2 specifies that Extensible Authentication Protocol (EAP) |
| authentication must be used together with responder authentication |
| based on public key signatures. This is necessary with old EAP |
| methods that provide only unilateral authentication using, e.g., one- |
| time passwords or token cards. |
| |
| This document specifies how EAP methods that provide mutual |
| authentication and key agreement can be used to provide extensible |
| responder authentication for IKEv2 based on methods other than public |
| key signatures. |
| |
| Status of This Memo |
| |
| This is an Internet Standards Track document. |
| |
| This document is a product of the Internet Engineering Task Force |
| (IETF). It represents the consensus of the IETF community. It has |
| received public review and has been approved for publication by the |
| Internet Engineering Steering Group (IESG). Further information on |
| Internet Standards is available in Section 2 of RFC 5741. |
| |
| Information about the current status of this document, any errata, |
| and how to provide feedback on it may be obtained at |
| http://www.rfc-editor.org/info/rfc5998. |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Eronen, et al. Standards Track [Page 1] |
| |
| RFC 5998 Extension for EAP in IKEv2 September 2010 |
| |
| |
| Copyright Notice |
| |
| Copyright (c) 2010 IETF Trust and the persons identified as the |
| document authors. All rights reserved. |
| |
| This document is subject to BCP 78 and the IETF Trust's Legal |
| Provisions Relating to IETF Documents |
| (http://trustee.ietf.org/license-info) in effect on the date of |
| publication of this document. Please review these documents |
| carefully, as they describe your rights and restrictions with respect |
| to this document. Code Components extracted from this document must |
| include Simplified BSD License text as described in Section 4.e of |
| the Trust Legal Provisions and are provided without warranty as |
| described in the Simplified BSD License. |
| |
| This document may contain material from IETF Documents or IETF |
| Contributions published or made publicly available before November |
| 10, 2008. The person(s) controlling the copyright in some of this |
| material may not have granted the IETF Trust the right to allow |
| modifications of such material outside the IETF Standards Process. |
| Without obtaining an adequate license from the person(s) controlling |
| the copyright in such materials, this document may not be modified |
| outside the IETF Standards Process, and derivative works of it may |
| not be created outside the IETF Standards Process, except to format |
| it for publication as an RFC or to translate it into languages other |
| than English. |
| |
| 1. Introduction |
| |
| The Extensible Authentication Protocol (EAP), defined in [RFC3748], |
| is an authentication framework that supports multiple authentication |
| mechanisms. Today, EAP has been implemented at end hosts and routers |
| that connect via switched circuits or dial-up lines using PPP |
| [RFC1661], IEEE 802 wired switches [IEEE8021X], and IEEE 802.11 |
| wireless access points [IEEE80211i]. |
| |
| One of the advantages of the EAP architecture is its flexibility. |
| EAP is used to select a specific authentication mechanism, typically |
| after the authenticator requests more information in order to |
| determine the specific authentication method to be used. Rather than |
| requiring the authenticator (e.g., wireless LAN access point) to be |
| updated to support each new authentication method, EAP permits the |
| use of a backend authentication server that may implement some or all |
| authentication methods. |
| |
| |
| |
| |
| |
| |
| |
| Eronen, et al. Standards Track [Page 2] |
| |
| RFC 5998 Extension for EAP in IKEv2 September 2010 |
| |
| |
| IKEv2 ([RFC4306] and [RFC5996]) is a component of IPsec used for |
| performing mutual authentication and establishing and maintaining |
| Security Associations (SAs) for IPsec ESP and Authentication Header |
| (AH). In addition to supporting authentication using public key |
| signatures and shared secrets, IKEv2 also supports EAP |
| authentication. |
| |
| IKEv2 provides EAP authentication since it was recognized that public |
| key signatures and shared secrets are not flexible enough to meet the |
| requirements of many deployment scenarios. By using EAP, IKEv2 can |
| leverage existing authentication infrastructure and credential |
| databases, since EAP allows users to choose a method suitable for |
| existing credentials, and also makes separation of the IKEv2 |
| responder (VPN gateway) from the EAP authentication endpoint (backend |
| Authentication, Authorization, and Accounting (AAA) server) easier. |
| |
| Some older EAP methods are designed for unilateral authentication |
| only (that is, EAP peer to EAP server). These methods are used in |
| conjunction with IKEv2 public-key-based authentication of the |
| responder to the initiator. It is expected that this approach is |
| especially useful for "road warrior" VPN gateways that use, for |
| instance, one-time passwords or token cards to authenticate the |
| clients. |
| |
| However, most newer EAP methods, such as those typically used with |
| IEEE 802.11i wireless LANs, provide mutual authentication and key |
| agreement. Currently, IKEv2 specifies that these EAP methods must |
| also be used together with responder authentication based on public |
| key signatures. |
| |
| In order for the public key signature authentication of the gateway |
| to be effective, a deployment of Public Key Infrastructure (PKI) is |
| required, which has to include management of trust anchors on all |
| supplicants. In many environments, this is not realistic, and the |
| security of the gateway public key is the same as the security of a |
| self-signed certificate. Mutually authenticating EAP methods alone |
| can provide a sufficient level of security in many circumstances, and |
| in fact, in some deployments, IEEE 802.11i uses EAP without any PKI |
| for authenticating the Wireless Local Area Network (WLAN) access |
| points. |
| |
| This document specifies how EAP methods that offer mutual |
| authentication and key agreement can be used to provide responder |
| authentication in IKEv2 completely based on EAP. |
| |
| |
| |
| |
| |
| |
| |
| Eronen, et al. Standards Track [Page 3] |
| |
| RFC 5998 Extension for EAP in IKEv2 September 2010 |
| |
| |
| 1.1. Terminology |
| |
| All notation in this protocol extension is taken from [RFC4306]. |
| |
| Numbered messages refer to the IKEv2 message sequence when using EAP. |
| |
| Thus: |
| |
| o Message 1 is the request message of IKE_SA_INIT. |
| |
| o Message 2 is the response message of IKE_SA_INIT. |
| |
| o Message 3 is the first request of IKE_AUTH. |
| |
| o Message 4 is the first response of IKE_AUTH. |
| |
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", |
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this |
| document are to be interpreted as described in [RFC2119]. |
| |
| 2. Scenarios |
| |
| In this section, we describe two scenarios for extensible |
| authentication within IKEv2. These scenarios are intended to be |
| illustrative examples rather than specifying how things should be |
| done. |
| |
| Figure 1 shows a configuration where the EAP and the IKEv2 endpoints |
| are co-located. Authenticating the IKEv2 responder using both EAP |
| and public key signatures is redundant. Offering EAP-based |
| authentication has the advantage that multiple different |
| authentication and key exchange protocols are available with EAP with |
| different security properties (such as strong password-based |
| protocols, protocols offering user identity confidentiality, and many |
| more). |
| |
| +------+-----+ +------------+ |
| O | IKEv2 | | IKEv2 | |
| /|\ | Initiator |<---////////////////////--->| Responder | |
| / \ +------------+ IKEv2 +------------+ |
| User | EAP Peer | Exchange | EAP Server | |
| +------------+ +------------+ |
| |
| Figure 1: EAP and IKEv2 Endpoints Are Co-Located |
| |
| Figure 2 shows a typical corporate network access scenario. The |
| initiator (client) interacts with the responder (VPN gateway) in the |
| corporate network. The EAP exchange within IKE runs between the |
| |
| |
| |
| Eronen, et al. Standards Track [Page 4] |
| |
| RFC 5998 Extension for EAP in IKEv2 September 2010 |
| |
| |
| client and the home AAA server. As a result of a successful EAP |
| authentication protocol run, session keys are established and sent |
| from the AAA server to the VPN gateway, and then used to authenticate |
| the IKEv2 SA with AUTH payloads. |
| |
| The protocol used between the VPN gateway and AAA server could be, |
| for instance, Diameter [RFC4072] or RADIUS [RFC3579]. See Section 6 |
| for related security considerations. |
| |
| +-------------------------------+ |
| | Corporate network | |
| | | |
| +-----------+ +--------+ | |
| | IKEv2 | AAA | Home | | |
| IKEv2 +////----->+ Responder +<---------->+ AAA | | |
| Exchange / | (VPN GW) | (RADIUS/ | Server | | |
| / +-----------+ Diameter) +--------+ | |
| / | carrying EAP | |
| | | | |
| | +-------------------------------+ |
| v |
| +------+-----+ |
| o | IKEv2 | |
| /|\ | Initiator | |
| / \ | VPN client | |
| User +------------+ |
| |
| Figure 2: Corporate Network Access |
| |
| 3. Solution |
| |
| IKEv2 specifies that when the EAP method establishes a shared secret |
| key, that key is used by both the initiator and responder to generate |
| an AUTH payload (thus authenticating the IKEv2 SA set up by messages |
| 1 and 2). |
| |
| When used together with public key responder authentication, the |
| responder is, in effect, authenticated using two different methods: |
| the public key signature AUTH payload in message 4, and the EAP-based |
| AUTH payload later. |
| |
| If the initiator does not wish to use public-key-based responder |
| authentication, it includes an EAP_ONLY_AUTHENTICATION notification |
| payload (16417) in message 3. The Protocol ID and Security Parameter |
| Index (SPI) size fields are set to zero, and there is no additional |
| data associated with this notification. |
| |
| |
| |
| |
| |
| Eronen, et al. Standards Track [Page 5] |
| |
| RFC 5998 Extension for EAP in IKEv2 September 2010 |
| |
| |
| If the responder supports this notification and chooses to use it, it |
| omits the public-key-based AUTH payload and CERT payloads from |
| message 4. |
| |
| If the responder does not support the EAP_ONLY_AUTHENTICATION |
| notification or does not wish to use it, it ignores the notification |
| payload, and includes the AUTH payload in message 4. In this case, |
| the initiator MUST verify that payload and any associated |
| certificates, as per [RFC4306]. |
| |
| When receiving message 4, the initiator MUST verify that the proposed |
| EAP method is allowed by this specification, and MUST abort the |
| protocol immediately otherwise. |
| |
| Both the initiator and responder MUST verify that the EAP method |
| actually used provided mutual authentication and established a shared |
| secret key. The AUTH payloads sent after EAP Success MUST use the |
| EAP-generated key, and MUST NOT use SK_pi or SK_pr (see Section 2.15 |
| of [RFC5996]). |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Eronen, et al. Standards Track [Page 6] |
| |
| RFC 5998 Extension for EAP in IKEv2 September 2010 |
| |
| |
| An IKEv2 message exchange with this modification is shown below: |
| |
| Initiator Responder |
| ----------- ----------- |
| HDR, SAi1, KEi, Ni, |
| [N(NAT_DETECTION_SOURCE_IP), |
| N(NAT_DETECTION_DESTINATION_IP)] --> |
| |
| <-- HDR, SAr1, KEr, Nr, [CERTREQ], |
| [N(NAT_DETECTION_SOURCE_IP), |
| N(NAT_DETECTION_DESTINATION_IP)] |
| |
| HDR, SK { IDi, [IDr], SAi2, TSi, TSr, |
| N(EAP_ONLY_AUTHENTICATION), |
| [CP(CFG_REQUEST)] } --> |
| |
| <-- HDR, SK { IDr, EAP(Request) } |
| |
| HDR, SK { EAP(Response) } --> |
| |
| <-- HDR, SK { EAP(Request) } |
| |
| HDR, SK { EAP(Response) } --> |
| |
| <-- HDR, SK { EAP(Success) } |
| |
| HDR, SK { AUTH } --> |
| |
| <-- HDR, SK { AUTH, SAr2, TSi, TSr, |
| [CP(CFG_REPLY] } |
| |
| Note: all notation in the above protocol sequence and elsewhere in |
| this specification is as defined in [RFC4306], and see in particular |
| Sec. 1.2 of [RFC4306] for payload types. |
| |
| The NAT detection and Configuration payloads are shown for |
| informative purposes only; they do not change how EAP authentication |
| works. |
| |
| An IKE SA that was set up with this extension can be resumed using |
| the mechanism described in [RFC5723]. However, session resumption |
| does not change the authentication method. Therefore, during the |
| IKE_AUTH exchange of the resumed session, this extension MUST NOT be |
| sent by the initiator. |
| |
| |
| |
| |
| |
| |
| |
| Eronen, et al. Standards Track [Page 7] |
| |
| RFC 5998 Extension for EAP in IKEv2 September 2010 |
| |
| |
| 4. Safe EAP Methods |
| |
| EAP methods to be used with this extension MUST have the following |
| properties: |
| |
| 1. The method provides mutual authentication of the peers. |
| |
| 2. The method is key-generating. |
| |
| 3. The method is resistant to dictionary attacks. |
| |
| The authors believe that the following EAP methods are secure when |
| used with the current extension. The list is not inclusive, and |
| there are likely other safe methods that have not been listed here. |
| |
| +-------------------------------+-------------------+---------------+ |
| | Method Name | Allows Channel | Reference | |
| | | Binding? | | |
| +-------------------------------+-------------------+---------------+ |
| | EAP-SIM | No | [RFC4186] | |
| | EAP-AKA | Yes | [RFC4187] | |
| | EAP-AKA' | Yes | [RFC5448] | |
| | EAP-GPSK | Yes | [RFC5433] | |
| | EAP-pwd | No | [RFC5931] | |
| | EAP-EKE | Yes | [EMU-EAP-EKE] | |
| | EAP-PAX | Yes | [RFC4746] | |
| | EAP-SAKE | No | [RFC4763] | |
| | EAP-SRP | No | [EAP-SRP] | |
| | EAP-POTP (mutual | Yes | [RFC4793] | |
| | authentication variant) | | | |
| | EAP-TLS | No | [RFC5216] | |
| | EAP-FAST | No | [RFC4851] | |
| | EAP-TTLS | No | [RFC5281] | |
| +-------------------------------+-------------------+---------------+ |
| |
| The "Allows channel binding?" column denotes protocols where |
| protected identity information may be sent between the EAP endpoints. |
| This third, optional property of the method provides protection |
| against certain types of attacks (see Section 6.2 for an |
| explanation), and therefore in some scenarios, methods that allow for |
| channel binding are to be preferred. It is noted that at the time of |
| writing, even when such capabilities are provided, they are not fully |
| specified in an interoperable manner. In particular, no RFC |
| specifies what identities should be sent under the protection of the |
| channel binding mechanism, or what policy is to be used to correlate |
| identities at the different layers. |
| |
| |
| |
| |
| |
| Eronen, et al. Standards Track [Page 8] |
| |
| RFC 5998 Extension for EAP in IKEv2 September 2010 |
| |
| |
| 5. IANA Considerations |
| |
| This document defines a new IKEv2 Notification Payload type, |
| EAP_ONLY_AUTHENTICATION, described in Section 3. This payload has |
| been assigned the type number 16417 from the "Status Types" range. |
| |
| 6. Security Considerations |
| |
| Security considerations applicable to all EAP methods are discussed |
| in [RFC3748]. The EAP Key Management Framework [RFC5247] deals with |
| issues that arise when EAP is used as a part of a larger system. |
| |
| 6.1. Authentication of IKEv2 SA |
| |
| It is important to note that the IKEv2 SA is not authenticated by |
| just running an EAP conversation: the crucial step is the AUTH |
| payload based on the EAP-generated key. Thus, EAP methods that do |
| not provide mutual authentication or establish a shared secret key |
| MUST NOT be used with the modifications presented in this document. |
| |
| 6.2. Authentication with Separated IKEv2 Responder / EAP Server |
| |
| As described in Section 2, the EAP conversation can terminate either |
| at the IKEv2 responder or at a backend AAA server. |
| |
| If the EAP method is terminated at the IKEv2 responder, then no key |
| transport via the AAA infrastructure is required. Pre-shared secret |
| and public-key-based authentication offered by IKEv2 is then replaced |
| by a wider range of authentication and key exchange methods. |
| |
| However, typically EAP will be used with a backend AAA server. See |
| [RFC5247] for a more complete discussion of the related security |
| issues; here we provide only a short summary. |
| |
| When a backend server is used, there are actually two authentication |
| exchanges: the EAP method between the client and the AAA server, and |
| another authentication between the AAA server and IKEv2 gateway. The |
| AAA server authenticates the client using the selected EAP method, |
| and they establish a session key. The AAA server then sends this key |
| to the IKEv2 gateway over a connection authenticated using, e.g., |
| IPsec or Transport Layer Security (TLS). |
| |
| Some EAP methods do not have any concept of pass-through |
| authenticator (e.g., Network Access Server (NAS) or IKEv2 gateway) |
| identity, and these two authentications remain quite independent of |
| each other. That is, after the client has verified the AUTH payload |
| sent by the IKEv2 gateway, it knows that it is talking to SOME |
| gateway trusted by the home AAA server, but not which one. The |
| |
| |
| |
| Eronen, et al. Standards Track [Page 9] |
| |
| RFC 5998 Extension for EAP in IKEv2 September 2010 |
| |
| |
| situation is somewhat similar if a single cryptographic hardware |
| accelerator, containing a single private key, would be shared between |
| multiple IKEv2 gateways (perhaps in some kind of cluster |
| configuration). In particular, if one of the gateways is |
| compromised, it can impersonate any of the other gateways towards the |
| user (until the compromise is discovered and access rights revoked). |
| |
| In some environments it is not desirable to trust the IKEv2 gateways |
| this much (also known as the "Lying NAS Problem"). EAP methods that |
| provide what is called "connection binding" or "channel binding" |
| transport some identity or identities of the gateway (or WLAN access |
| point / NAS) inside the EAP method. Then the AAA server can check |
| that it is indeed sending the key to the gateway expected by the |
| client. A potential solution is described in [EAP-SERVICE], see also |
| [EMU-AAAPAY]. |
| |
| In some deployment configurations, AAA proxies may be present between |
| the IKEv2 gateway and the backend AAA server. These AAA proxies MUST |
| be trusted for secure operation, and therefore SHOULD be avoided when |
| possible; see Section 2.3.4 of [RFC4072] and Section 4.3.7 of |
| [RFC3579] for more discussion. |
| |
| 6.3. Protection of EAP Payloads |
| |
| Although the EAP payloads are encrypted and integrity protected with |
| SK_e/SK_a, this does not provide any protection against active |
| attackers. Until the AUTH payload has been received and verified, a |
| man-in-the-middle can change the KEi/KEr payloads and eavesdrop or |
| modify the EAP payloads. |
| |
| In IEEE 802.11i wireless LANs, the EAP payloads are neither encrypted |
| nor integrity protected (by the link layer), so EAP methods are |
| typically designed to take that into account. |
| |
| In particular, EAP methods that are vulnerable to dictionary attacks |
| when used in WLANs are still vulnerable (to active attackers) when |
| run inside IKEv2. |
| |
| The rules in Section 4 are designed to avoid this potential |
| vulnerability. |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Eronen, et al. Standards Track [Page 10] |
| |
| RFC 5998 Extension for EAP in IKEv2 September 2010 |
| |
| |
| 6.4. Identities and Authenticated Identities |
| |
| When using this protocol, each of the peers sends two identity |
| values: |
| |
| 1. An identity contained in the IKE ID payload. |
| |
| 2. An identity transferred within the specific EAP method's |
| messages. |
| |
| (IKEv2 omits the EAP Identity request/response pair, see Section 3.16 |
| of [RFC5996].) The first identity value can be used by the recipient |
| to route AAA messages and/or to select authentication and EAP types. |
| But it is only the second identity that is directly authenticated by |
| the EAP method. The reader is referred to Section 2.16 of [RFC5996] |
| regarding the need to base IPsec policy decisions on the |
| authenticated identity. In the context of the extension described |
| here, this guidance on IPsec policy applies both to the |
| authentication of the client by the gateway and vice versa. |
| |
| 6.5. User Identity Confidentiality |
| |
| IKEv2 provides confidentiality for the initiator identity against |
| passive eavesdroppers, but not against active attackers. The |
| initiator announces its identity first (in message 3), before the |
| responder has been authenticated. The usage of EAP in IKEv2 does not |
| change this situation, since the ID payload in message 3 is used |
| instead of the EAP Identity Request/Response exchange. This is |
| somewhat unfortunate since when EAP is used with public key |
| authentication of the responder, it would be possible to provide |
| active user identity confidentiality for the initiator. |
| |
| IKEv2 protects the responder's identity even against active attacks. |
| This property cannot be provided when using EAP. If public key |
| responder authentication is used in addition to EAP, the responder |
| reveals its identity before authenticating the initiator. If only |
| EAP is used (as proposed in this document), the situation depends on |
| the EAP method used (in some EAP methods, the server reveals its |
| identity first). |
| |
| Hence, if active user identity confidentiality for the responder is |
| required then EAP methods that offer this functionality have to be |
| used (see [RFC3748], Section 7.3). |
| |
| |
| |
| |
| |
| |
| |
| |
| Eronen, et al. Standards Track [Page 11] |
| |
| RFC 5998 Extension for EAP in IKEv2 September 2010 |
| |
| |
| 7. Acknowledgments |
| |
| This document borrows some text from [RFC3748], [RFC4306], and |
| [RFC4072]. We would also like to thank Hugo Krawczyk for interesting |
| discussions about this topic, Dan Harkins, and David Harrington for |
| their comments. |
| |
| 8. References |
| |
| 8.1. Normative References |
| |
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate |
| Requirement Levels", BCP 14, RFC 2119, March 1997. |
| |
| [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and |
| H. Levkowetz, "Extensible Authentication Protocol |
| (EAP)", RFC 3748, June 2004. |
| |
| [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", |
| RFC 4306, December 2005. |
| |
| [RFC5723] Sheffer, Y. and H. Tschofenig, "Internet Key Exchange |
| Protocol Version 2 (IKEv2) Session Resumption", |
| RFC 5723, January 2010. |
| |
| [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, |
| "Internet Key Exchange Protocol Version 2 (IKEv2)", |
| RFC 5996, September 2010. |
| |
| 8.2. Informative References |
| |
| [EAP-SERVICE] Arkko, J. and P. Eronen, "Authenticated Service |
| Information for the Extensible Authentication Protocol |
| (EAP)", Work in Progress, October 2005. |
| |
| [EAP-SRP] Carlson, J., Aboba, B., and H. Haverinen, "EAP SRP- |
| SHA1 Authentication Protocol", Work in Progress, |
| July 2001. |
| |
| [EMU-AAAPAY] Clancy, C., Lior, A., Zorn, G., and K. Hoeper, "EAP |
| Method Support for Transporting AAA Payloads", Work |
| in Progress, May 2010. |
| |
| [EMU-EAP-EKE] Sheffer, Y., Zorn, G., Tschofenig, H., and S. Fluhrer, |
| "An EAP Authentication Method Based on the EKE |
| Protocol", Work in Progress, August 2010. |
| |
| |
| |
| |
| |
| Eronen, et al. Standards Track [Page 12] |
| |
| RFC 5998 Extension for EAP in IKEv2 September 2010 |
| |
| |
| [IEEE80211i] Institute of Electrical and Electronics Engineers, |
| "IEEE Standard for Information technology - |
| Telecommunications and information exchange between |
| systems - Local and metropolitan area networks - |
| Specific requirements - Part 11: Wireless Medium |
| Access Control (MAC) and Physical Layer (PHY) |
| specifications: Amendment 6: Medium Access Control |
| (MAC) Security Enhancements", IEEE Standard 802.11i- |
| 2004, July 2004. |
| |
| [IEEE8021X] Institute of Electrical and Electronics Engineers, |
| "Local and Metropolitan Area Networks: Port-Based |
| Network Access Control", IEEE Standard 802.1X-2001, |
| 2001. |
| |
| [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", |
| STD 51, RFC 1661, July 1994. |
| |
| [RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote |
| Authentication Dial In User Service) Support For |
| Extensible Authentication Protocol (EAP)", RFC 3579, |
| September 2003. |
| |
| [RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter |
| Extensible Authentication Protocol (EAP) Application", |
| RFC 4072, August 2005. |
| |
| [RFC4186] Haverinen, H. and J. Salowey, "Extensible |
| Authentication Protocol Method for Global System for |
| Mobile Communications (GSM) Subscriber Identity |
| Modules (EAP-SIM)", RFC 4186, January 2006. |
| |
| [RFC4187] Arkko, J. and H. Haverinen, "Extensible Authentication |
| Protocol Method for 3rd Generation Authentication and |
| Key Agreement (EAP-AKA)", RFC 4187, January 2006. |
| |
| [RFC4746] Clancy, T. and W. Arbaugh, "Extensible Authentication |
| Protocol (EAP) Password Authenticated Exchange", |
| RFC 4746, November 2006. |
| |
| [RFC4763] Vanderveen, M. and H. Soliman, "Extensible |
| Authentication Protocol Method for Shared-secret |
| Authentication and Key Establishment (EAP-SAKE)", |
| RFC 4763, November 2006. |
| |
| [RFC4793] Nystroem, M., "The EAP Protected One-Time Password |
| Protocol (EAP-POTP)", RFC 4793, February 2007. |
| |
| |
| |
| |
| Eronen, et al. Standards Track [Page 13] |
| |
| RFC 5998 Extension for EAP in IKEv2 September 2010 |
| |
| |
| [RFC4851] Cam-Winget, N., McGrew, D., Salowey, J., and H. Zhou, |
| "The Flexible Authentication via Secure Tunneling |
| Extensible Authentication Protocol Method (EAP-FAST)", |
| RFC 4851, May 2007. |
| |
| [RFC5216] Simon, D., Aboba, B., and R. Hurst, "The EAP-TLS |
| Authentication Protocol", RFC 5216, March 2008. |
| |
| [RFC5247] Aboba, B., Simon, D., and P. Eronen, "Extensible |
| Authentication Protocol (EAP) Key Management |
| Framework", RFC 5247, August 2008. |
| |
| [RFC5281] Funk, P. and S. Blake-Wilson, "Extensible |
| Authentication Protocol Tunneled Transport Layer |
| Security Authenticated Protocol Version 0 (EAP- |
| TTLSv0)", RFC 5281, August 2008. |
| |
| [RFC5433] Clancy, T. and H. Tschofenig, "Extensible |
| Authentication Protocol - Generalized Pre-Shared Key |
| (EAP-GPSK) Method", RFC 5433, February 2009. |
| |
| [RFC5448] Arkko, J., Lehtovirta, V., and P. Eronen, "Improved |
| Extensible Authentication Protocol Method for 3rd |
| Generation Authentication and Key Agreement (EAP- |
| AKA')", RFC 5448, May 2009. |
| |
| [RFC5931] Harkins, D. and G. Zorn, "Extensible Authentication |
| Protocol (EAP) Authentication Using Only A Password", |
| RFC 5931, August 2010. |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Eronen, et al. Standards Track [Page 14] |
| |
| RFC 5998 Extension for EAP in IKEv2 September 2010 |
| |
| |
| Appendix A. Alternative Approaches |
| |
| In this section, we list alternatives that have been considered |
| during the work on this document. We concluded that the solution |
| presented in Section 3 seems to fit better into IKEv2. |
| |
| A.1. Ignore AUTH Payload at the Initiator |
| |
| With this approach, the initiator simply ignores the AUTH payload in |
| message 4 (but obviously must check the second AUTH payload later!). |
| The main advantage of this approach is that no protocol modifications |
| are required and no signature verification is required. A |
| significant disadvantage is that the EAP method to be used cannot be |
| selected to take this behavior into account. |
| |
| The initiator could signal to the responder (using a notification |
| payload) that it did not verify the first AUTH payload. |
| |
| A.2. Unauthenticated Public Keys in AUTH Payload (Message 4) |
| |
| Another solution approach suggests the use of unauthenticated public |
| keys in the public key signature AUTH payload (for message 4). |
| |
| That is, the initiator verifies the signature in the AUTH payload, |
| but does not verify that the public key indeed belongs to the |
| intended party (using certificates) -- since it doesn't have a PKI |
| that would allow this. This could be used with X.509 certificates |
| (the initiator ignores all other fields of the certificate except the |
| public key), or "Raw RSA Key" CERT payloads. |
| |
| This approach has the advantage that initiators that wish to perform |
| certificate-based responder authentication (in addition to EAP) may |
| do so, without requiring the responder to handle these cases |
| separately. A disadvantage here, again, is that the EAP method |
| selection cannot take into account the incomplete validation of the |
| responder's certificate. |
| |
| If using RSA, the overhead of signature verification is quite small, |
| compared to the g^xy calculation required by the Diffie-Hellman |
| exchange. |
| |
| A.3. Using EAP Derived Session Keys for IKEv2 |
| |
| It has been proposed that when using an EAP method that provides |
| mutual authentication and key agreement, the IKEv2 Diffie-Hellman |
| exchange could also be omitted. This would mean that the session |
| keys for IPsec SAs established later would rely only on EAP-provided |
| keys. |
| |
| |
| |
| Eronen, et al. Standards Track [Page 15] |
| |
| RFC 5998 Extension for EAP in IKEv2 September 2010 |
| |
| |
| It seems the only benefit of this approach is saving some computation |
| time (g^xy calculation). This approach requires designing a |
| completely new protocol (which would not resemble IKEv2 anymore); we |
| do not believe that it should be considered. Nevertheless, we |
| include it for completeness. |
| |
| Authors' Addresses |
| |
| Pasi Eronen |
| Independent |
| |
| EMail: pe@iki.fi |
| |
| |
| Hannes Tschofenig |
| Nokia Siemens Networks |
| Linnoitustie 6 |
| Espoo 02600 |
| Finland |
| |
| Phone: +358 (50) 4871445 |
| EMail: Hannes.Tschofenig@gmx.net |
| URI: http://www.tschofenig.priv.at |
| |
| |
| Yaron Sheffer |
| Independent |
| |
| EMail: yaronf.ietf@gmail.com |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| Eronen, et al. Standards Track [Page 16] |
| |
