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] +