EAP Internet Draft H. Tschofenig D. Kroeselberg Siemens Corporate Technology Document: draft-tschofenig-eap-ikev2-01.txt Expires: December 2003 June 2003 EAP IKEv2 Method (EAP-IKEv2) Status of this Memo This document is an Internet-Draft and is subject to all provisions of Section 10 of RFC2026. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Abstract EAP-IKEv2 is an EAP method which reuses the cryptography and the payloads of IKEv2, creating a flexible EAP method that supports both symmetric and asymmetric authentication. Furthermore protection of legacy authentication mechanisms is supported. This EAP method offers the security benefits of IKEv2 without the goal of establishing IPsec security associations. Tschofenig, Kroselberg Expires - December 2003 [Page 1] EAP IKEv2 June 2003 Table of Contents 1. Introduction..................................................2 2. Terminology...................................................3 3. Protocol overview.............................................3 4. Identities used in EAP-IKEv2..................................6 5. Packet Format.................................................8 6. Key derivation................................................9 7. Security Considerations.......................................9 8. Open Issues..................................................10 9. References...................................................10 Acknowledgments.................................................11 Author's Addresses..............................................11 Full Copyright Statement........................................12 1. Introduction IKEv2 [2] is a protocol which consists of two exchanges: (1) an authentication and key exchange protocol which establishes an IKE-SA. (2) messages and payloads which focus on the negotiation of parameters in order to establish IPsec security associations (i.e. Child-SAs). These payloads contain algorithm parameters and traffic selector fields. In addition to the above-mentioned parts IKEv2 also includes some payloads and messages which allow configuration parameters to be exchanged primarily for remote access scenarios. The EAP-IKEv2 method defined by this document uses the IKEv2 payloads and messages used for the initial IKEv2 exchange which establishes an IKE-SA. IKEv2 provides an improvement over IKEv1 [5] as described in Appendix A of [2]. Important for this document are the reduced number of initial exchanges, support of legacy authentication, decreased latency of the initial exchange, optional Denial-of- Service (DoS) protection capability and some other fixes (e.g. hash problem). IKEv2 is a cryptographically sound protocol that has received a considerable amount of expert review and that benefits from a long practical experience with IKE. The goal of EAP-IKEv2 is to inherit these properties within an efficient, secure EAP method. In addition, IKEv2 provides authentication and key exchange capabilities which allow an entity to use symmetric as well as asymmetric authentication in addition to legacy authentication Tschofenig, Kroselberg Expires - December 2003 [Page 2] EAP IKEv2 June 2003 support within a single protocol. Such flexibility is considered important for an EAP method and is provided by EAP-IKEv2. [6] provides a good tutorial for IKEv2 design decisions. EAP-IKEv2 therefore provides a) a well-known IKEv2 symmetric/asymmetric authentication and b) a new EAP tunneling method. 2. Terminology This document does not introduce new terms other than those defined in [1] or in [2]. The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [10]. 3. Protocol overview This section provides some overview over EAP-IKEv2 message exchanges. Note that some payloads are omitted (such as SAi2 and SAr2 ) which are mandatory for IKEv2 but are not required in EAP- IKEv2 since they are used to establish an IPsec SA. IKEv2 uses the same protocol message exchanges for both symmetric and asymmetric authentication. The difference lies only in the computation of the AUTH payload. See Section 2.15 of [2] for more information about the details of the AUTH payload computation. It is even possible to combine symmetric (e.g. from the client to the server) with asymmetric authentication (e.g. from the server to the client) in a single protocol exchange. Additionally, for symmetric authentication no CERT and CERTREQ payloads are required. Figure 1 depicts such a protocol exchange. Message exchanges are reused from [2], and are adapted. Since this document does not describe frameworks or particular architectures the message exchange takes place between two parties - between the Initiator (I) and the Responder (R). In context of EAP the Initiator is often called Authenticating Peer whereas the Responder is referred as Authenticator. The first message flow shows EAP-IKEv2 without the optional DoS protection exchanges. The DoS protection mechanism prevents the responder from allocating state and performing heavy cryptographic operations based on the first incoming message. The core EAP-IKEv2 exchange (message (4) - (7)) consists of four messages (two round Tschofenig, Kroselberg Expires - December 2003 [Page 3] EAP IKEv2 June 2003 trips)_only. The first two messages constitute the standard EAP identity exchange and are not mandatory if the EAP server is known. 1) I <-- R: EAP-Request/Identity 2) I --> R: EAP-Response/Identity(Id) 3) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(Start) 4) I --> R: EAP-Response/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni) 5) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2( HDR(A,B), SAr1, KEr, Nr, [CERTREQ]) 6) I --> R: EAP-Response/EAP-Type=EAP-IKEv2( HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,], AUTH}) 7) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2( HDR(A,B), SK {IDr, [CERT,] AUTH}) 8) I --> R: EAP-Response/EAP-Type=EAP-IKEv2(Finish) 9) I <-- R: EAP-Success Figure 1: EAP-IKEv2 message flow The subsequent message flow shows EAP-IKEv2 with DoS protection enabled. The IKEv2 DoS protection mechanism uses cookies and keeps the responder stateless when it receives the first IKEv2 message. As a consequence of DoS protection an additional round trip (message (5) and (6)) is required. 1) I <-- R: EAP-Request/Identity 2) I --> R: EAP-Response/Identity(Id) 3) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(Start) 4) I --> R: EAP-Response/EAP-Type=EAP-IKEv2(HDR(A,0), SAi1, KEi, Ni) 5) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2( HDR(A,0), N(COOKIE-REQUIRED), N(COOKIE)) 6) I --> R: EAP-Response/EAP-Type=EAP-IKEv2( HDR(A,0), N(COOKIE), SAi1, KEi, Ni) 7) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2( Tschofenig, Kroselberg Expires - December 2003 [Page 4] EAP IKEv2 June 2003 HDR(A,B), SAr1, KEr, Nr, [CERTREQ]) 8) I --> R: EAP-Response/EAP-Type=EAP-IKEv2( HDR(A,B), SK {IDi, [CERT,] [CERTREQ,] [IDr,], AUTH}) 9) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2( HDR(A,B), SK {IDr, [CERT,] AUTH}) 10) I --> R: EAP-Response/EAP-Type=EAP-IKEv2(Finish) 11) I <-- R: EAP-Success Figure 2: EAP-IKEv2 with Cookies The Secure Legacy Authentication (SLA) EAP message exchange shown in Figure 3 is taken from Section 2.16 of [2] and adapted. It provides an example of a successful inner EAP exchange using the EAP-SIM Authentication method [8], which is secured by the IKE-SA. Implementations MUST ensure that infinite recursions of EAP and EAP- IKEv2 exchanges are not allowed. (TBD: some limit necessary) I <-- R: EAP-Request/Identity I --> R: EAP-Response/Identity(Id) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(Start) I --> R: EAP-Response/EAP-Type=EAP-IKEv2( HDR, SAi1, KEi, Ni) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2( HDR, SAr1, KEr, Nr, [CERTREQ]) I --> R: EAP-Response/EAP-Type=EAP-IKEv2( HDR, SK {IDi, [CERTREQ,] [IDr,]}) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(HDR, SK {EAP(EAP- Request/SIM/Start(AT_VERSION_LIST)),[AUTH]}) I --> R: EAP-Response/EAP-Type=EAP-IKEv2(HDR, SK {EAP(EAP- Response/SIM/Start(AT_NONCE_MT, AT_SELECTED_VERSION)), [AUTH]}) I <-- R: EAP-Request/EAP-Type=EAP-IKEv2(HDR, SK {EAP(EAP- Request/SIM/Challenge(AT_RAND, AT_MAC)), [AUTH]}) I --> R: EAP-Response/EAP-Type=EAP-IKEv2( HDR, SK {EAP(EAP-Response/SIM/Challenge(AT_MAC) ), [AUTH]}) Tschofenig, Kroselberg Expires - December 2003 [Page 5] EAP IKEv2 June 2003 I <-- R: EAP-Success Figure 3: EAP-IKEv2 SLA with EAP-SIM Authentication Please note that the message flow in Figure 3 does not include an EAP-Request/Identity and the corresponding EAP-Response/Identity message inside the EAP-IKEv2 tunnel. Although it would be possible to perform such an exchange IKEv2 suggests using the IDi payload for this purpose. As a consequence the initiators identity is not protected against active attacks. Since the goal of this EAP method is not to establish an IPsec SA some payloads used in IKEv2 are omitted. In particularly the following messages and payloads are not required: - Traffic Selectors - IPsec SA negotiation payloads (e.g. CREATE_CHILD_SA exchange or SAx2 payloads) - ECN Notification - Port handling - NAT traversal Rekeying of IKE-SAs might be required but requires further study. Some of these messages and payloads are optional in IKEv2. In general it does not make sense to directly negotiate IPsec SAs with EAP-IKEv2, as such SAs were unlikely to be used between the EAP endpoints. IKEv2 also provides functionality for the initiator to request address information from the responder as described in Section 2.19 of [2]. Using this functionality it is possible for an end host to securely request address configuration information from the local network. 4. Identities used in EAP-IKEv2 A number of identities are used in IKEv2 and particularly when EAP is used. This section describes their function within the different exchanges. Note that EAP-IKEv2 does not introduce more identities than any other tunneling approach. Figure 4 shows which identities are used during the individual phases of the protocol. +-------+ +-------------+ +---------+ +--------+ |Client | |Front-End | |Local AAA| |Home AAA| | | |Authenticator| |Server | |Server | +-------+ +-------------+ +---------+ +--------+ Tschofenig, Kroselberg Expires - December 2003 [Page 6] EAP IKEv2 June 2003 EAP/Identity-Request <--------------------- (a) EAP/Identity-Response ----------------------------------> Tunnel-Establishment (b) (Identities of IKEv2 are used) Server (Network) Authentication <---------------------------------- ... ----------------------------------> +---------------------------------+ | Secure Tunnel | +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~+ | Secure Legacy Authentication | | protected with the IKE-SA | (c) | (Identities of the tunneled | | EAP method are used) | | Client Authentication | |---------------------------------+----------------> |<--------------------------------+----------------- +---------------------------------+ Figure 4: Identities used in EAP-IKEv2 a) The first part of the (outer) EAP message exchange provides information about the identities of the EAP endpoints. This message exchange mainly is an identity request/response. This exchange is optional if the EAP server is known already or can be learned by other means. b) The identities used within EAP-IKEv2 for both the initiator and the responder. The initiator identity is often associated with a user identity such as a fully-qualified RFC 822 email address. The identity of the responder might be a FQDN. The identity is of importance for authorization. For secure legacy authentication an EAP message exchange is protected with the established IKE-SA as shown in Figure 3. This exchange again adds EAP identities. c) This inner EAP message exchange serves the purpose of client authentication. The two identities used thereby are the EAP identity (i.e. a NAI) and possibly a separate identity for the selected EAP method. Tschofenig, Kroselberg Expires - December 2003 [Page 7] EAP IKEv2 June 2003 The large number of identities is required due to nesting of authentication methods and due to overloaded function of the identity for routing (i.e. authentication end point indication). Hence with this additional (nested) EAP exchange the end point of the EAP-IKEv2 exchange might not be the same as the end point of the inner EAP exchange which is protected by the IKE-SA (which in this case is not protected by the IKE-SA any more between the EAP-IKEv2 endpoint and the endpoint of the inner EAP exchange, but might be protected by other means that are not considered in this document). 5. Packet Format The IKEv2 payloads, which are defined in [2], are embedded into the Data field of the standard EAP Request/Response packets. The Code, Identifier, Length and Type field is described in [1]. The Type-Data field carries a one byte Flags field following the IKEv2 payloads. Each IKEv2 payload starts with a header field HDR (see [2]). The packet format is shown in Figure 5: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Code | Identifier | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Flags | Message Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message Length | Data ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Packet Format No additional packet formats other than those defined in [2] are required for this EAP method. The Flags field is required to indicate Start and Finish messages which are required due to the asymmetric nature of IKEv2 and the Request/Response message handling of EAP. Currently four bits of the eight bit flags field are defined. The remaining bits are set to zero. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |S F L M 0 0 0 0| +-+-+-+-+-+-+-+-+ Tschofenig, Kroselberg Expires - December 2003 [Page 8] EAP IKEv2 June 2003 S = EAP-IKEv2 start message F = EAP-IKEv2 finish message L = Length included M = More fragments EAP-IKEv2 messages which have neither the S nor the F flag set contain regular IKEv2 message payloads inside the Data field. With regard to fragmentation we follow the suggestions and descriptions given in Section 2.8 of [9]: The L indicates that a length field is present and the M flag indicates fragments. The L flag MUST be set for the first fragment and the M flag MUST be set on all fragments expect for the last one. Each fragment sent must subsequently be acknowledged. The Message Length field is four octets long and present only if the L bit is set. This field provides the total message length that is being fragmented. The EAP Type for this EAP method is . 6. Key derivation The EAP-IKEv2 method described in this document generates sessions keys. These session keys are used to establish an IKE-SA which provides protection of other payloads. To export a session key as part of the EAP keying framework [7] it is required to derive another session key for usage with EAP (sometimes referred as Pre- Master-Secret). It is good cryptographic security practice to use different keys for different "applications". Hence we suggest to reuse the key derivation function suggested in Section 2.17 of [2] to export the KEYMAT (as a Pre-Master-Secret) for further key derivation. The key derivation function defined is KEYMAT = prf+(SK_d, Ni | Nr), where Ni and Nr are the Nonces from the IKE_SA_INIT exchange. 7. Security Considerations The security of the proposed EAP method is intentionally based on IKEv2 [2]. Man-in-the-middle attacks discovered in the context of tunneled authentication protocols (see [3] and [4]) are applicable to IKEv2 if legacy authentication with EAP [1] is used. To counter this threat IKEv2 provides a compound authentication by including the EAP provided session key inside the AUTH payload. Further security considerations will be provided with future versions of this document. An example of the security issues which are pending at the moment is active user identity confidentiality Tschofenig, Kroselberg Expires - December 2003 [Page 9] EAP IKEv2 June 2003 for the initiator (particularly for tunneling of EAP packets protected by the IKE-SA). 8. Open Issues The following issues are still under consideration: - Session resumption TLS provides the capability of resuming a session. This offers primarily performance improvement for a new authentication and key exchange protocol run. It is for further study whether the concept of session resumption (i.e. a fast re-authentication procedure) is a useful context for EAP methods and for the AAA environment in particular. If it turns out to be useful then one possible approach is to reuse the dead peer detection informational exchange, which is able to provide fast re-authentication based on the established IKE- SA. This exchange is cheap in terms of processing complexity and provides both end points the capability to perform authentication based on an available IKE-SA. - Reducing the number of messages The message flows given in this document finish with an EAP-Success message. In some cases it might be possible to skip these messages. Furthermore it is possible to omit the first exchange if the identity can be learned by other means. - Fragmentation Fragments sent must subsequently be acknowledged. Typically an empty EAP packet is used. This, however, adds a vulnerability to the protocol. - EAP-IKEv2 Finish Message It might be advisable to protect the EAP-IKEv2 finish message since a key is already available. - Rekeying As mentioned in Section 3 it might be useful to keep rekeying functionality of IKEv2. 9. References [1] L. Blunk and J. Vollbrecht: "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998. Tschofenig, Kroselberg Expires - December 2003 [Page 10] EAP IKEv2 June 2003 [2] C. Kaufman: "Internet Key Exchange (IKEv2) Protocol", internet draft, Internet Engineering Task Force, 2003. Work in progress. [3] N. Asokan, V. Niemi, and K. Nyberg: "Man-in-the-middle in tunnelled authentication", In the Proceedings of the 11th International Workshop on Security Protocols, Cambridge, UK, April 2003. To be published in the Springer-Verlag LNCS series. [4] J. Puthenkulam, V. Lortz, A. Palekar, D. Simon, and B. Aboba, "The compound authentication binding problem," internet draft, Internet Engineering Task Force, 2003. Work in progress. [5] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [6] R. Perlman: "Understanding IKEv2: Tutorial, and rationale for decisions", internet draft, Internet Engineering Task Force, 2003. Work in progress. [7] B. Aboba and D. Simon: "EAP Keying Framework", internet draft, Internet Engineering Task Force, 2003. Work in progress. [8] H. Haverinen, J. Salowey: "EAP SIM Authentication", internet draft, Internet Engineering Task Force, 2003. Work in progress. [9] A. Palekar, D. Simon, G. Zorn and S. Josefsson: "Protected EAP Protocol (PEAP)", internet draft, Internet Engineering Task Force, March 2003. Work in progress. [10] S. Bradner: "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Internet Engineering Task Force, March 1997. Acknowledgments We would like to thank Jari Arkko and Paoulo Pagliusi for their comments to the initial version of this draft. Additionally we would like to thank members of the PANA design team (namely D. Forsberg, Y. Ohba and A. Yegin) for their comments and input to this draft. Author's Addresses Hannes Tschofenig Siemens AG Otto-Hahn-Ring 6 81739 Munich Germany Tschofenig, Kroselberg Expires - December 2003 [Page 11] EAP IKEv2 June 2003 EMail: Hannes.Tschofenig@siemens.com Dirk Kroeselberg Siemens AG Otto-Hahn-Ring 6 81739 Munich Germany EMail: Dirk.Kroeselberg@siemens.com Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Tschofenig, Kroselberg Expires - December 2003 [Page 12]