include RFC 5998

2 files changed, 899 insertions, 729 deletions

diff --git a/doc/standards/draft-eronen-ipsec-ikev2-eap-auth-05.txt b/doc/standards/draft-eronen-ipsec-ikev2-eap-auth-05.txt
deleted file mode 100644
index f5fd3cc0c..000000000
--- a/doc/standards/draft-eronen-ipsec-ikev2-eap-auth-05.txt
+++ /dev/null
@@ -1,729 +0,0 @@
-
-
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-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]
-
-
diff --git a/doc/standards/rfc5998.txt b/doc/standards/rfc5998.txt
new file mode 100644
index 000000000..9ebe32918
--- /dev/null
+++ b/doc/standards/rfc5998.txt
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+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]
+