+++ /dev/null
-
-
-
-Network Working Group P. Eronen
-Internet-Draft Nokia
-Expires: December 28, 2006 H. Tschofenig
- Siemens
- June 26, 2006
-
-
- Extension for EAP Authentication in IKEv2
- draft-eronen-ipsec-ikev2-eap-auth-05.txt
-
-Status of this Memo
-
- By submitting this Internet-Draft, each author represents that any
- applicable patent or other IPR claims of which he or she is aware
- have been or will be disclosed, and any of which he or she becomes
- aware will be disclosed, in accordance with Section 6 of BCP 79.
-
- Internet-Drafts are working documents of the Internet Engineering
- Task Force (IETF), its areas, and its working groups. Note that
- other groups may also distribute working documents as Internet-
- Drafts.
-
- Internet-Drafts are draft documents valid for a maximum of six months
- and may be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet-Drafts as reference
- material or to cite them other than as "work in progress."
-
- The list of current Internet-Drafts can be accessed at
- http://www.ietf.org/ietf/1id-abstracts.txt.
-
- The list of Internet-Draft Shadow Directories can be accessed at
- http://www.ietf.org/shadow.html.
-
- This Internet-Draft will expire on December 28, 2006.
-
-Copyright Notice
-
- Copyright (C) The Internet Society (2006).
-
-Abstract
-
- IKEv2 specifies that EAP authentication must be used together with
- public key signature based responder authentication. 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
-
-
-
-Eronen & Tschofenig Expires December 28, 2006 [Page 1]
-\f
-Internet-Draft Extension for EAP in IKEv2 June 2006
-
-
- responder authentication for IKEv2 based on other methods than public
- key signatures.
-
-
-1. Introduction
-
- The Extensible Authentication Protocol (EAP), defined in [4], is an
- authentication framework which 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 [13],
- IEEE 802 wired switches [9], and IEEE 802.11 wireless access points
- [11].
-
- 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 which may implement some or
- all authentication methods.
-
- IKEv2 [3] is a component of IPsec used for performing mutual
- authentication and establishing and maintaining security associations
- for IPsec ESP and 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
- 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 also these EAP methods
-
-
-
-Eronen & Tschofenig Expires December 28, 2006 [Page 2]
-\f
-Internet-Draft Extension for EAP in IKEv2 June 2006
-
-
- must be used together with public key signature based responder
- authentication.
-
- In some environments, requiring the deployment of PKI for just this
- purpose can be counterproductive. Deploying new infrastructure can
- be expensive, and it may weaken security by creating new
- vulnerabilities. Mutually authenticating EAP methods alone can
- provide a sufficient level of security in many circumstances, and
- indeed, IEEE 802.11i uses EAP without any PKI for authenticating the
- 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.
-
-1.1. Terminology
-
- 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 [2].
-
-
-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). As an example it is possible to use GSS-API support within
- EAP [6] to support Kerberos based authentication which effectively
- replaces the need for KINK [14].
-
- +------+-----+ +------------+
- O | IKEv2 | | IKEv2 |
- /|\ | Initiator |<---////////////////////--->| Responder |
- / \ +------------+ IKEv2 +------------+
- User | EAP Peer | Exchange | EAP Server |
- +------------+ +------------+
-
- Figure 1: EAP and IKEv2 endpoints are co-located
-
-
-
-Eronen & Tschofenig Expires December 28, 2006 [Page 3]
-\f
-Internet-Draft Extension for EAP in IKEv2 June 2006
-
-
- 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
- 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 [4] or RADIUS [5]. See Section 5 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 (type TBD-BY-IANA) in message 3. The SPI size field is set
-
-
-
-Eronen & Tschofenig Expires December 28, 2006 [Page 4]
-\f
-Internet-Draft Extension for EAP in IKEv2 June 2006
-
-
- to zero, and there is no additional data associated with this
- notification.
-
- If the responder supports this notification, 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, it ignores the notification payload, and includes the
- AUTH payload in message 4. In this case the initiator can, based on
- its local policy, choose to either ignore the AUTH payload, or verify
- it and any associated certificates as usual.
-
- 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.
-
- 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] }
-
-
-
-Eronen & Tschofenig Expires December 28, 2006 [Page 5]
-\f
-Internet-Draft Extension for EAP in IKEv2 June 2006
-
-
- The NAT detection and Configuration payloads are shown for
- informative purposes only; they do not change how EAP authentication
- works.
-
-
-4. IANA considerations
-
- This document defines a new IKEv2 Notification Payload type,
- EAP_ONLY_AUTHENTICATION, described in Section 3. This payload must
- be assigned a new type number from the "status types" range.
-
- This document does not define any new namespaces to be managed by
- IANA.
-
-
-5. Security Considerations
-
- Security considerations applicable to all EAP methods are discussed
- in [1]. The EAP Key Management Framework [7] deals with issues that
- arise when EAP is used as a part of a larger system.
-
-5.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.
-
-5.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 terminates 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
- [7] 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
-
-
-
-Eronen & Tschofenig Expires December 28, 2006 [Page 6]
-\f
-Internet-Draft Extension for EAP in IKEv2 June 2006
-
-
- to the IKEv2 gateway over a connection authenticated using, e.g.,
- IPsec or TLS.
-
- Some EAP methods do not have any concept of pass-through
- authenticator (e.g., 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 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 [16].
-
- 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 [4] and [7] for more discussion.
-
-5.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 WLANs, 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.
-
-5.4. User identity confidentiality
-
- IKEv2 provides confidentiality for the initiator identity against
-
-
-
-Eronen & Tschofenig Expires December 28, 2006 [Page 7]
-\f
-Internet-Draft Extension for EAP in IKEv2 June 2006
-
-
- 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 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 initiator is
- required then EAP methods that offer this functionality have to be
- used (see [1], Section 7.3).
-
-
-6. Acknowledgments
-
- This document borrows some text from [1], [3], and [4]. We would
- also like to thank Hugo Krawczyk for interesting discussions about
- this topic.
-
-
-7. References
-
-7.1. Normative References
-
- [1] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
- Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748,
- June 2004.
-
- [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
- Levels", RFC 2119, March 1997.
-
- [3] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306,
- December 2005.
-
- [4] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
- Authentication Protocol (EAP) Application", RFC 4072,
- August 2005.
-
-
-
-
-
-Eronen & Tschofenig Expires December 28, 2006 [Page 8]
-\f
-Internet-Draft Extension for EAP in IKEv2 June 2006
-
-
-7.2. Informative References
-
- [5] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial
- In User Service) Support For Extensible Authentication Protocol
- (EAP)", RFC 3579, September 2003.
-
- [6] Aboba, B. and D. Simon, "EAP GSS Authentication Protocol",
- draft-aboba-pppext-eapgss-12 (work in progress), April 2002.
-
- [7] Aboba, B., "Extensible Authentication Protocol (EAP) Key
- Management Framework", draft-ietf-eap-keying-13 (work in
- progress), May 2006.
-
- [8] Forsberg, D., "Protocol for Carrying Authentication for Network
- Access (PANA)", draft-ietf-pana-pana-11 (work in progress),
- March 2006.
-
- [9] Institute of Electrical and Electronics Engineers, "Local and
- Metropolitan Area Networks: Port-Based Network Access Control",
- IEEE Standard 802.1X-2001, 2001.
-
- [10] Institute of Electrical and Electronics Engineers, "Information
- technology - Telecommunications and information exchange
- between systems - Local and metropolitan area networks -
- Specific Requirements Part 11: Wireless LAN Medium Access
- Control (MAC) and Physical Layer (PHY) Specifications", IEEE
- Standard 802.11-1999, 1999.
-
- [11] 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.
-
- [12] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote
- Authentication Dial In User Service (RADIUS)", RFC 2865,
- June 2000.
-
- [13] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
- RFC 1661, July 1994.
-
- [14] Sakane, S., Kamada, K., Thomas, M., and J. Vilhuber,
- "Kerberized Internet Negotiation of Keys (KINK)", RFC 4430,
- March 2006.
-
- [15] Tschofenig, H., "EAP IKEv2 Method",
-
-
-
-Eronen & Tschofenig Expires December 28, 2006 [Page 9]
-\f
-Internet-Draft Extension for EAP in IKEv2 June 2006
-
-
- draft-tschofenig-eap-ikev2-11 (work in progress), June 2006.
-
- [16] Arkko, J. and P. Eronen, "Authenticated Service Information for
- the Extensible Authentication Protocol (EAP)",
- draft-arkko-eap-service-identity-auth-04 (work in progress),
- October 2005.
-
-
-Appendix A. Alternative Approaches
-
- In this section we list alternatives which have been considered
- during the work on this document. Finally, 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.
-
- The initiator could signal the responder (using a NOTIFY payload)
- that it did not verify the first AUTH payload.
-
-A.2. Unauthenticated PKs in AUTH payload (message 4)
-
- The first 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.
-
- If using RSA, the overhead of signature verification is quite small
- (compared to g^xy calculation).
-
-A.3. Use EAP derived session keys for IKEv2
-
- It has been proposed that when using an EAP methods that provides
- mutual authentication and key agreement, the IKEv2 Diffie-Hellman
-
-
-
-Eronen & Tschofenig Expires December 28, 2006 [Page 10]
-\f
-Internet-Draft Extension for EAP in IKEv2 June 2006
-
-
- exchange could also be omitted. This would mean that the sessions
- keys for IPsec SAs established later would rely only on EAP-provided
- keys.
-
- 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Tschofenig Expires December 28, 2006 [Page 11]
-\f
-Internet-Draft Extension for EAP in IKEv2 June 2006
-
-
-Authors' Addresses
-
- Pasi Eronen
- Nokia Research Center
- P.O. Box 407
- FIN-00045 Nokia Group
- Finland
-
- Email: pasi.eronen@nokia.com
-
-
- Hannes Tschofenig
- Siemens
- Otto-Hahn-Ring 6
- Munich, Bayern 81739
- Germany
-
- Email: Hannes.Tschofenig@siemens.com
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Eronen & Tschofenig Expires December 28, 2006 [Page 12]
-\f
-Internet-Draft Extension for EAP in IKEv2 June 2006
-
-
-Intellectual Property Statement
-
- The IETF takes no position regarding the validity or scope of any
- Intellectual Property Rights or other rights that might be claimed to
- pertain to the implementation or use of the technology described in
- this document or the extent to which any license under such rights
- might or might not be available; nor does it represent that it has
- made any independent effort to identify any such rights. Information
- on the procedures with respect to rights in RFC documents can be
- found in BCP 78 and BCP 79.
-
- Copies of IPR disclosures made to the IETF Secretariat and any
- assurances of licenses to be made available, or the result of an
- attempt made to obtain a general license or permission for the use of
- such proprietary rights by implementers or users of this
- specification can be obtained from the IETF on-line IPR repository at
- http://www.ietf.org/ipr.
-
- The IETF invites any interested party to bring to its attention any
- copyrights, patents or patent applications, or other proprietary
- rights that may cover technology that may be required to implement
- this standard. Please address the information to the IETF at
- ietf-ipr@ietf.org.
-
-
-Disclaimer of Validity
-
- This document and the information contained herein are provided on an
- "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
- OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
- ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
- INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
- INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
- WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-Copyright Statement
-
- Copyright (C) The Internet Society (2006). This document is subject
- to the rights, licenses and restrictions contained in BCP 78, and
- except as set forth therein, the authors retain all their rights.
-
-
-Acknowledgment
-
- Funding for the RFC Editor function is currently provided by the
- Internet Society.
-
-
-
-
-Eronen & Tschofenig Expires December 28, 2006 [Page 13]
-\f
-
--- /dev/null
+
+
+
+
+
+
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
+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]
+\f
projects / thirdparty / strongswan.git / commitdiff
