Network Working Group A. Kukec Internet-Draft University of Zagreb Expires: August 19, 2007 February 15, 2007 Additions to IKEv2 tutorial and Rationale for Decisions draft-kukec-ikev2-tutorial-additions-00.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 August 19, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Kukec Expires August 19, 2007 [Page 1] Internet-Draft Additions to IKEv2 tutorial February 2007 Abstract This document contains additions to the R. Perlman's draft Understanding IKEv2: Tutorial, and rationale for decisions. Its purpose is to request for comments and to incorporate it into draft-ietf-ipsec-ikev2-tutorial-01. This document describes some of controversial issues discussed on the IPsec mailing list and described in various IETF documents that were written after the publication of draft-ietf-ipsec-ikev2-tutorial-01. Its additional purpose is to explain some of IKEv2 protocol parts that were not described in draft-ietf-ipsec-ikev2-tutorial-01. It follows the original R. Perlman draft's concept to be both a tutorial for understanding IKEv2 and a summary of IKEv2 issues. Table of Contents 1. IKEv2 with old and/or new IPsec architecture . . . . . . . . . 3 1.1. SA bundles in IKEv2 . . . . . . . . . . . . . . . . . . . 3 2. Alice (initiator) and Alice (original initiator) . . . . . . . 6 2.1. Alice and Bob . . . . . . . . . . . . . . . . . . . . . . 6 3. IKEv2 and PAD database . . . . . . . . . . . . . . . . . . . . 7 4. Identity types for Alice and Bob . . . . . . . . . . . . . . . 10 4.1. Secure SPD lookup . . . . . . . . . . . . . . . . . . . . 11 5. RSA authentication . . . . . . . . . . . . . . . . . . . . . . 12 6. Different authentication methods for Alice and Bob . . . . . . 14 7. Alice's EAP authentication without Bob's RSA authentication . 15 8. NAT traversal and UDP/TCP checksums . . . . . . . . . . . . . 17 9. Alice's requests for internal address with DHCP and RADIUS . . 19 10. Rekeying and reauthentication . . . . . . . . . . . . . . . . 20 10.1. REKEY_SA and DELETE payloads in the same time . . . . . . 20 10.2. Bob's repeated authentication . . . . . . . . . . . . . . 21 11. Security Considerations . . . . . . . . . . . . . . . . . . . 23 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 13.1. Normative References . . . . . . . . . . . . . . . . . . . 25 13.2. Informative References . . . . . . . . . . . . . . . . . . 25 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 27 Intellectual Property and Copyright Statements . . . . . . . . . . 28 Kukec Expires August 19, 2007 [Page 2] Internet-Draft Additions to IKEv2 tutorial February 2007 1. IKEv2 with old and/or new IPsec architecture There are two currently used versions of the IPsec architecture: o the old IPsec architecture described in [RFC2401], o the new IPsec architecture described in [RFC4301]. Nowadays all common kernels have implementation of the IPsec stack based on the old IPsec architecture. Therefore IKEv2 is often used in combination with that old architecture. In spite of the fact that is possible to implement IKEv2 "on the top" of it, that is the standard violation - IKEv1 is compliant only with the old IPsec architecture and IKEv2 is compliant only with the new one. There are some important features that IKEv2 can achieve only if it is used in combination with the new IPsec architecture. Some examples of differences between two IPsec architectures and impact on IKEv2 are: o The old IPsec architecture supports SA bundles (protection of the SA with the AH and ESP protocol in the same time). The new IPsec architecture only simulates nested SAs through the forwarding table and appropriate Security Policies for each security protocol (AH or ESP). IKEv2 does not support IKEv1-style combined SAs. o The new IPsec architecture introduces IP address ranges in traffic selectors, while the old IPsec architecture supports only IP networks. IKEv2 requires address ranges which can not be implemented in combination with the old IPsec architecture. o The old IPsec architecture does not inform IKEv2 about the data in the initial packet that triggered the whole IPsec communication (PF_KEY SADB_ACQUIRE). Therefore, the PFP flag (Populate From Packet) feature can not be implemented in IKEv2 when IKEv2 is used in combination with the old IPsec architecture. 1.1. SA bundles in IKEv2 The nested SAs processing in IKEv2 depends on the version of the IPsec architecture: o the old IPsec architecture and IKEv1 support combined SAs, o the new IPsec architecture and IKEv2 only simulate nested SAs through the forwarding table and appropriate Security Policies. It is important to point out that even in old IPsec architecture, the term combined SAs is related only to CHILD SAs. IKE SA protects only IKE traffic, it is duplex and logical association (it does not really Kukec Expires August 19, 2007 [Page 3] Internet-Draft Additions to IKEv2 tutorial February 2007 exist in the OS kernel). Combined SAs in IKEv1 (for example AH+ESP bundle) are SA pair that is protected both with the AH and the ESP protocol in the same time. Only one Security Policy is enough to describe combined SAs. [ TSi = (any proto, Alice); TSr = (any proto, Bob); transform = AH + ESP ] The Security Policy in the row above contains Alice's traffic selectors, Bob's traffic selectors and the transform for SA pair. It says: all Alice's traffic for Bob protect both with AH and ESP in the same time. Combined SAs always originate from only one Security Policy. In IKEv2, for the AH+ESP protection each packet traverses through the IPsec boundary two times as a consequent of two Security Policies: 1. [ TSi = (any proto, Alice); TSr = (any proto, Bob); transform = ESP ] 2. [ TSi = (ESP, Alice); TSr = (ESP, Bob); transform = AH ] First Security Policy causes the ESP protection of each Alice's packet for Bob, while second Security Policy causes AH protection of each Alice's ESP protected packet for Bob. The IKEv2 payload structure described in [RFC4306] still supports combined SAs from the old IPsec architecture, in spite of the fact that IKEv2 must be explicitly based on the new architecture. The reason why IKEv2 still supports the IKEv1 style combined SAs is in the IKEv2 SA payload structure: SA payload contains one or more proposals. Each proposal contains one or more protocols (AH protocol or ESP protocol). The protocol ID (for AH or ESP) is located in the proposal payload which is allowed by the IKEv2 specification to appear multiple times in each IKEv2 INIT message and not in the SA payload which is unique and only one for each initial IKE exchange. The compliance of the IKEv2 with the new IPsec architecture (in which one SA pair must be protected with exactly one security protocol) could be achieved with either of these two solutions: o to move the protocol ID (for AH or ESP) from the proposal payload to the SA payload. Then, it would be only one protocol ID for one SA payload), o to change the SA payload to contain only one proposal payload. However, it is allowed to use multiple proposal payloads in IKEv2, Kukec Expires August 19, 2007 [Page 4] Internet-Draft Additions to IKEv2 tutorial February 2007 but only if all of them have the same protocol ID. One such instance is when one wants to provide to following policy: [allow AES and ESN] or [3DES and NO ESN] and forbid [AES and NO ESN]. When receiving such multiple proposals, the receiver can return an error if it concludes that all of the proposals do not contain the same protocol ID. Obviously, the first solution (to move the protocol ID from the proposal payload to the SA payload) would be a better solution. The major cause why the IKEv2 spec still supports SA bundles is that IKEv2 was already in the RFC queue when the new IPsec architecture (rfc4301) was revised not to support SA bundles and it was too late to revise it. (References: [IPSEC] " Is AH + ESP required or needed in IKEv2 ", August 2005.) Kukec Expires August 19, 2007 [Page 5] Internet-Draft Additions to IKEv2 tutorial February 2007 2. Alice (initiator) and Alice (original initiator) There is a difference between Alice (initiator) and Alice (original initiator)[RFC4718]. The initiator is the peer that has initiated the whole IKEv2 initial exchange. The initiator of the IKE_SA_INIT exchange is also the initiator in the IKE_AUTH exchange, but he does not have to be the initiator of the CREATE_CHILD_SA exchange. Therefore the initiator of the whole IKE SA exchange is sometimes called the original initiator and the peer who initiated the current CHILD SA is called only initiator. The described difference between the initiator and the original initiator can be explained additionally on the example of rekeying and reauthentication: o only the original initiator can initiate reauthentication (the process that includes complete new initial IKE SA INIT and IKE AUTH exchanges followed with the CREATE CHILD SA exchange), o the initiator can only initiate rekeying (the process of the cryptographic material recalculation that includes only the CREATE CHILD SA exchange). 2.1. Alice and Bob IKEv2's architecture is the peer-to-peer architecture. However, Alice and Bob are not always fully equal peers. There are a few exceptions usually related to the road warrior scenario (Endpoint to Security Gateway tunnel scenario): o Only the original initiator can send the configuration request payload (CFG_REQUEST) to get the configuration data from the original responder (server). The original responder can only initiate rekeying. o Only the original initiator can use extended authentication (EAP)[eapikev2], while the original responder acts as a server. o Only the original initiator can be behind a NAT. The problem is simply that the initiator can not start communication with the responder if he does not have a public IP address. There are no problems with NAT detection mechanism - it can detect for both initiator and / or responder if someone has rewritten their address. Kukec Expires August 19, 2007 [Page 6] Internet-Draft Additions to IKEv2 tutorial February 2007 3. IKEv2 and PAD database IPsec architecture contains three databases: o the SAD database with Security Associations, o the SPD database with Security Policies, o the PAD (Peer Authorization Database) database that represents link between IKEv2 and the SPD database. SAD and SPD databases exist in common OS kernels while the PAD database is pseudo-database whose functionality is described in the IPsec architecture specification. The PAD database is divided into two parts: the authentication part and the authorization part. The authentication part imposes exactly which authentication material has to be used when verifying the peer's authenticity and which authentication method peer uses. The authorization part makes a check if a peer with a specific identity is valid to create the designated CHILD SA. That identity does not have to be necessarily from the IKEv2 ID payload; it can be, for example, from the certificate or it can be internal EAP authenticated identity. The example of the PAD entry[padslides] is shown in the Table 1: The example of the PAD entry is: +----------------------------------+-----------------------------+ | Authentication data | Authorization data | +----------------------------------+-----------------------------+ | Peer ID: my_domain | SA Constraints: *@my_domain | | | | | Auth Data: CA cert for my_domain | | | | | | Revocation Info: http://my_crl | | +----------------------------------+-----------------------------+ Table 1 The authentication part of the PAD entry contains: o the peer's ID. Identity types are equivalent to types of IKEv2 ID payloads), o the authentication data. Shared secret, end-entity certificate or certification authority certificate), Kukec Expires August 19, 2007 [Page 7] Internet-Draft Additions to IKEv2 tutorial February 2007 o the information about the revocation material. OCSP server and his public key or a pointer to the Certificate Revocation List in case of a public key authentication based on X509 certificates. The authorization part of the PAD entry contains: o addresses or symbolic names (IDs) that a peer is allowed to use when establishing designated CHILD SAs. The PAD entry will also usually contain the flag that determines whether the SPD lookup will be based on the address (stored in the TS payload of the CREATE_CHILD_SA message) or on the symbolic name (exchanged in the IKE AUTH message, either in the ID payload, the certificate or somewhere else). The link between IKEv2 and the SPD database contains three steps: 1. The authentication: After the receipt of Bob's identity and his authentication material, Alice verifies his authentication material against authentication data from the PAD entry that matches Bob's identity. 2. The authorization: In case of the successful verification of Bob's credentials, Alice checks in the PAD entry if Bob is allowed to create designated CHILD SAs. This process is called the SA constraining. 3. The SPD lookup: After the authentication in the first step and the authorization in the second step, Alice finally performs the Security Policy lookup for Bob. Such SPD lookup based on the appropriate PAD entry and on the appropriately selected identity that matches the identity from peer's credential is called the secure SPD lookup[pki4ipsec]. The authentication part of the PAD database allows avoiding heuristic during the process of validation of the received authentication data. One could imagine the following scenario with IKEv2 daemon without the appropriate PAD entry: Alice possesses two certificates: CERT1 issued by the corporation T1 and CERT2 issued by the corporation T2. Bob is a gateway and behind him is a VPN containing both the T1's network and T2's network. Bob has certification authority certificates for both corporations (CA_CERT1 and CA_CERT2). If CERT1 expires and CERT2 does not expire, in spite of the fact that Alice should not be able to "contact" the corporation T1, she will authenticate herself successfully - Bob will succesfully verify her CERT2 against CA_CERT2. Alice can then communicate both with T1 and T2, and not only with T2. In such scenario (without the PAD database) Bob will try to validate the received Alice's certificate Kukec Expires August 19, 2007 [Page 8] Internet-Draft Additions to IKEv2 tutorial February 2007 against each CA certificate that he has. With the appropriate PAD entry, Bob knows exactly against which CA certificates he has to validate Alice's certificate. The authorization part of the PAD database enables flexibility in choosing the policies by using both symbolic names (identities, either IKEv2 ID's or certificate identities) as well as addresses. The [pki4ipsec] describes the IKEv2 ID profile that ensures the secure SPD lookup based on that identity. It describes how to perform the check if an identity from the PAD entry matches the corresponding identity found in the received certificate. Each IKEv2 implementation must be able to perform such check, although there must be possibility to configure the implementation not to do so due to interoperability reasons. Additionally, the PAD database could store an additional information, for example whether to perform the matching between the received ID payload and corresponding PKIX attributes from the certificate. Kukec Expires August 19, 2007 [Page 9] Internet-Draft Additions to IKEv2 tutorial February 2007 4. Identity types for Alice and Bob The ID payload in IKEv2 contains an identity that peers insert in each IKE AUTH message. It is used: o For the authentication purposes, in the process of the AUTH payload calculation and in the process of searching the peer's PAD entry that contains information about peer's authentication material, o For the symbolic SPD lookup. That is the process of selecting specific Security Policy based on identity. (Non-symbolic SPD lookup is process of selecting specific Security Polity based on IP addresses, o For the certificate lookup (optionally). The IKEv2 ID payload does not have to match the data from the insecure outer IP header. For the example the road warrior client can use his private IP address as ID and the certificate based on that private IP address as his credential to authenticate himself even when he is not in his private network. The only requirement is that none of our other peers does not have that same ID. The decision which identity type to use depends on the specific scenario. However looking from the security aspect, there is no special advantage of any of them. For example the advantage of ID_RFC822_ADDR (e-mail address), ID_FQDN (domain name) and ID_KEY_ID (vendor specific information) types is that they make it easier to name a great number of peers with dynamic IP addresses. In the case of a small number of clients with static IP addresses it is convenient to use the ID_IPv4(6)_ADDR. Usually, ID_DER_ASN1 type that matches the certificate Subject field (DN) will not be used in case of the pre-shared key authentication and ID_KEY_ID will not be used in the case of the public key based authentication. There are two types of ID_DER_ASN1 identites: ID_DER_ASN1_DN and ID_DER_ASN1_GN. ID_DER_ASN1_DN is equal to the X.501 Distinguished Name (for example, CN=MyName, O=MyOrganization, C=MyCountry), while ID_DER_ASN1_GN is equal to X.509 General Name. With ID_DER_ASN1_GN one could specify almost everything of any use on the Internet (e-mail address, URL, X.400, postal address, phone fax, pet's name, etc). However ID_DER_ASN1_GN is not allowed in IKEv2. If Alice wants to identify herself with e-mail address, instead of generating ID_DER_ASN1_GN identity type, she has to use SubjectAltName fields from the certificate. Those SubjectAltName fields match IKEv2 identity types: Kukec Expires August 19, 2007 [Page 10] Internet-Draft Additions to IKEv2 tutorial February 2007 Certificate SubjectAltName iPAddress matches IKEv2 ID_IPv4(6)_ADDR, Certificate SubjectAltName dNSName matches IKEv2 ID_FQDN, Certificate SubjectAltName rfc822Name matches IKEv2 ID_RFC822_ADDR, Entire certificate Subject field matches the ID_DER_ASN1_DN IKEv2 identity type. 4.1. Secure SPD lookup For the PKI scenario (RSA authentication based on X509 certificates) [pki4ipsec] describes how to perform secure symbolic SPD and certificate lookups. The secure symbolic SPD lookup is based on the matching of contents of the SPD entry with the ID payload. For the certificate lookup, [pki4ipsec] suggests that one should check if the ID payload from the IKEv2 message matches the data from peer's certificate. It suggests that the ID payload should be populated with the corresponding PKIX certificate attribute. Although the properly populated ID payload can be used for the secure certificate lookup, such matching of the ID payload and corresponding certificate field narrows the number of appropriate identity types. For example, one should not use SubjectAltName of type IPaddress in the certificate because the usage of the ID_IPv4(6)_ADDR in IKEv2 ID payload is not recommended in the situations where a peer has dynamic IP address or is behind the NAT. Another reason to have an identity different from the certificate's identity is flexibility. For example in the multi-homed environments ID payload from each of the network interfaces will contain different identity, yet all of them will usually use the same given certificate to prove identity. The solution for the interoperability problems that could be consequent of required identities' matching can be achieved by the appropriate PAD entries that contain additional information that informs a remote peer whether to match or not. (References: [IPSEC] " Identities types IP address ", January 2005. [IPSEC] " ID and subject/subject-alt in certificate ", April 2005. ". ) Kukec Expires August 19, 2007 [Page 11] Internet-Draft Additions to IKEv2 tutorial February 2007 5. RSA authentication Besides the pre-shared key authentication, the RSA authentication is the most often used authentication method in IKEv2. There are different types of the RSA authentication based on different kinds of credentials: Raw RSA keys, DNS Signed Key, PGP Certificate, Kerberos Token, X509 Certificate - Signature, Hash and URL of X509 Certificate, etc. All of the previously mentioned credentials can be exchanged either through out-of-band means or in the CERTREQ/CERT payloads. The CERTREQ payload provides an information to peer about the trusted certification authorities. Alice creates the CERTREQ payload based on all CA certificates that she has. After the receipt of such CERTREQ payload Bob searches if some of his certificates have been provided by the certification authority listed in the received CERTREQ payload. He responses with the CERT payload that contains only certificates selected based on the CA hashes in the received CERTREQ payload. Alice can either ignore received CERT payload or proceed with the validation of received certificates. If she has the locally stored Bob's certificate, either exchanged with some out-of- band means or stored in the previous authentication process, she ignores all of received CERT payloads and validates Bob's locally stored certificate. However if Alice does not have Bob's certificate stored locally, she validates received certificates against CA certificates and the revocation material from Bob's PAD entry. While the CERTREQ payload consists always of the Certificate Encoding and of the concatenated list of SHA-1 hashes of the certification authorities (CAs), the CERT payload structure depends on the Certificate Encoding. In case of the X509 Certificate - Signature, the CERT payload contains the X509 certificate, while in case of the Hash and URL of X509 Certificate contains the SHA-1 hash of X509 certificate followed by the URL that resolves into DER encoded X509 certificate. Unfortunately at the moment the X509 certificate does not have an attribute to store URL in it. However if Alice uses the Hash and URL certificates, she sends to Bob both the Hash and URL CERTREQ payload and the HTTP_CERT_LOOKUP_SUPPORTED notification. This notification serves as an information to Bob that Alice is able to receive and validate Hash and URL certificates. After the receipt of the Hash and URL CERT payload, Alice downloads the certificate from URL extracted from the CERT payload. She compares if the SHA-1 hash of the dowloaded certificate matches the SHA-1 hash in the CERT payload and proceeds with the certificate validation. The Hash and URL CERT payload is used to shorten the CERT payload which is of essential meaning due to the optimal bandwith usage and the prevention of the IP fragmentation (some NATs/firewalls might block IP fragments, IP fragments are potential security vulnerability, Kukec Expires August 19, 2007 [Page 12] Internet-Draft Additions to IKEv2 tutorial February 2007 etc). The use of Hash and URL certificates is important for multiple CERT payloads exchange. In most cases, both Alice and Bob will have only one X509 certificate but there are scenarios in which they will exchange multiple certificates, either as o the certificate chain or o the certificate bundle. The certificate chain consists of the end-entity certificate followed by the intermediate CA certificates and the root certificate. The certificate bundle is the ASN.1 sequence of certificates, which are either end-entity certificates or the certificate chain. The example of the certificate bundle is the X509 Certificate - Signature stored in one CERT payload and X.509 Certificate - Attribute in another, where the X.509 Certificate - Attribute is exchanged to obtain an additional authorization information. Another example of the certificate bundle exchange are X509 certificates with the same public key but different Subject fields and/or SubjectAltName extensions. The exchange of a such certificate bundle can be relevant for the successful authentication to a peer which is configured to check the matching of the received identity from the IKEv2 ID payload with the corresponding PKIX attribute from the X509 certificate (Subject or SubjectAltName). In case of exchanging multiple certificates, the AUTH payload is always signed with public key from the first CERT payload. The main advantage of the RSA authentication (compared to the PSK authentication) is that it relies on the popular principles of a cryptographic material exchange. For example X509 Certificate - Signature and URL of X509 Certificate use the Public Key Infrastructure (PKI). The importance of the RSA authentication lays in fact that it is the only authentication method that the responder can use in the roadwarrior IKEv2 scenario in which the roadwarrior client (Alice) uses extended authentication (EAP)[eapikev2]. In spite of newer EAP authentication methods that are mutual, Bob must authenticate himself to the initiator with the RSA based authentication. However, there are some methods that suggest, for example, using EAP methods with channel binding support instead of Bob's authentication[exteapikev2]. (References: [IPSEC] " certificate encoding type in ikev2 ", July 2004.) Kukec Expires August 19, 2007 [Page 13] Internet-Draft Additions to IKEv2 tutorial February 2007 6. Different authentication methods for Alice and Bob In most cases both Alice and Bob will use the same authentication method (either PSK or RSA authentication). However IKEv2 permits that Alice, for example, uses the certificate based authentication and Bob uses the shared secret. Obviously in such cases Bob needs to trust at least one certification authority to be able to validate Alice's certificate and Alice needs to have Bob's shared secret. In such scenarios the name shared secret is rather misleading because Bob does not use the same secret as Alice as his credentital (Bob uses the certificate as a credential). Therefore for the PSK authentication is just important that both Alice and Bob have matched the same secret with Bob's identity, while for the RSA authentication is important that Bob has appropriate PAD entry for Alice in his PAD database with the information about CA certificates and the revocation material. The question that arise up before the IKE AUTH exchange is which authentication method the peer will use? This issue is the consequent of the fact that we can not select appropriate (peer's) PAD entry with the information about the peer's authentication material sooner then we receive the IKE AUTH message with peer's ID payload. In the moment of sending the CERTREQ payload there is no possibility to find out which authentication method our peer will use. Therefore it is convenient to send the CERTREQ payload by default, even if peer (Bob in our case) itself does not use the RSA authentication. This way Alice is not limited which authentication method to use. An implementation that does not send the CERTREQ payload by default could cause interoperability problems in case of the authentication with the peer that sends the CERT payload only after the previously received CERTREQ payload. The purpose of the CERTREQ is strictly informational and the event of the CERTREQ payload ignoring is not an error. Bob can either ignore the CERTREQ payload and use the authentication method different than the RSA authentication or he can use the RSA authentication and answer with the CERT payload. (References: [IPSEC] " certificate payloads/requests in IKEv2 ", September 2005.) Kukec Expires August 19, 2007 [Page 14] Internet-Draft Additions to IKEv2 tutorial February 2007 7. Alice's EAP authentication without Bob's RSA authentication In the EAP scenario, where Alice uses EAP authentication, IKEv2 requires that Bob uses the RSA authentication. That was perfectly reasonable from the security perspective when EAP methods were one- sided. Newer EAP authentication methods that are mutual [exteapikev2] brought out the idea of the EAP usage without the Bob's RSA authentication which means the omitting of the AUTH payload from message 4. Initiator Responder ----------- ----------- 1. HDR, SAi1, KEi, Ni --> <-- 2. HDR, SAr1, KEr, Nr, [CERTREQ] 3. HDR, SK {IDi, [CERTREQ,] [IDr,] SAi2, TSi, TSr} --> <-- 4. HDR, SK {IDr, [CERT,] AUTH, EAP } 5. HDR, SK {EAP} --> <-- 6. HDR, SK {EAP (success)} 7. HDR, SK {AUTH} --> <-- 8.HDR, SK {AUTH, SAr2, TSi, TSr} Mutual EAP authentication methods imply producing the shared key (MSK value) that is used for AUTH payload calculation (message 7 and 8) over the Diffie-Hellman values (message 1 and 2). However even when using mutual EAP methods with shared keys but without Bob's signature in message 4, there is a possibility for a MITM attack such as described in [eapmitm]. Non-IKEv2 attacker can perform such reverse MITM attack by stealing IKEv2 exchanges and moving them to an un- tunneled non-IKEv2 context. In such scenarios attacker does not fail when checking the MSK value due to the fact that he completely impersonates Bob (an IKEv2 responder). Additionally authentication of the DH values is done after the EAP success message which makes the keys for encryption of the EAP messages meaningless (attacker can easily establish them with Alice). Therefore IKEv2 requires mutual EAP authentication methods that generate shared key in conjunction with the public key to produce Kukec Expires August 19, 2007 [Page 15] Internet-Draft Additions to IKEv2 tutorial February 2007 Bob's signature to sign the AUTH payload in the message 4. On the other hand, [exteapikev2] suggests EAP authentication without the requirement for Bob's RSA authentication. [exteapikev2] requests an eap method with mutual authentication and key generation in addition to the channel binding support instead of Bob's public key signature. It arguments proposal for omitting Bob's public key authentication with explanation that the use of PKI for this purpose can be even counterproductive. The deployment of the additional infrastructure such as PKI may be expensive and may cause new vulnerabilities. (References: [IPSEC] " Clarification of EAP authentication in IKEv2? ", Dec 2003. ) Kukec Expires August 19, 2007 [Page 16] Internet-Draft Additions to IKEv2 tutorial February 2007 8. NAT traversal and UDP/TCP checksums The impact of the NAT traversal on the process of fixing the UDP/TCP checksums depends on the selected IPsec mode. From NAT-T perspective, there are three cases: o the tunnel mode, o the UDP encapsulation of the ESP packets, o the transport mode. In the tunnel mode NAT box changes only the outer IP header but not the inner one. Because only the inner IP header is under the integrity protection, the combination of the tunnel mode with the NAT traversal does not introduce checksum problems. Similarly, in the UDP-encapsulation the inner IP header stays as it is and the outer UDP header is not encrypted; therefore NAT box can easily fix checksums. The problem is the transport mode through a NAT-T because there is only one IP header that is both changed by the NAT box and is protected by the integrity algorithm. The combination of the NAT with the transport mode raised some questions: o Whether to support the transport mode through a NAT-T or not, o How to fix the UDP/TCP checksums in such scenario. There were some arguments that one does not need the transport mode at all, while everything can be done with the ESP tunnel mode. That is just partly true, because there are two main differences between the tunnel and the transport mode: o the overhead caused by the additional header in the tunnel mode, o the difference with the selector checking. While the first can be solved with the appropriate compression, the second one still remains. Therefore it has been decided to keep the ESP transport mode with one additional fact to be remembered - NAT-T is not the mandatory mechanism in the IKEv2. The question on how to fix UDP/TCP checksums was the consequent of the dropping out the NAT-OA payload in IKEv2 (NAT-OA exists only in IKEv1). NAT-OA payload was used in IKEv1 to transport the original IP address (i.e. the address that Alice sent in her packet). When Bob received such packet, he could use that address to adjust the transport checksum after decrypting received packet. Contrary to the IKEv1 NAT-OA principle, in IKEv2 only the hash of the original IP Kukec Expires August 19, 2007 [Page 17] Internet-Draft Additions to IKEv2 tutorial February 2007 address is transported and it is used only for the NAT discovery. Initially people were suggesting three different ways of fixing the transport checksums in IKEv2: o the incremental recomputing based on the IP address received in the IP header, o the recomputing based on the original IP address. The incremental recomputing principle uses the data from the received IP header to fix the cheksum. But, if there is NAT box between Alice and Bob, Bob will not receive the IP header with Alice's address but rather with the source address of the NAT box. That automatically means that the combination of NAT-t and the transport mode could be used only if peers would know the IP address of the NAT box. In the scenario where Bob is NATed, in case of the incremental recomputing, he would have to know the address of the NAT box. For example if Alice sends packet to NATed Bob, she calculates the checksum as function of her address and Bob's NAT box address. Therefore Bob would need to know the address of NAT box (which he does not know) to fix the checksum. Even the tunnel mode in case of the incremental recomputing is not the perfect solution, while there are some security issues. In the tunnel mode Bob can recompute checksum based on the IP address from the received inner IP header because NAT box does not change it. However, one could think that this is secure principle because the inner IP header is integrity protected. This thought is unfortunately not correct because in such a way one looses the possibility of discovering errors based on the original address. One can only detect if bits have been changed before entering the ESP tunnel (during the encryption) and not somewhere on the path between Alice and Bob. Therefore IKEv2 has adopted the second solution, the recomputing based on the original IP address that Alice puts in one of the existing IKEv2 payloads - traffic selector payload. After the receipt of the message, Bob performs the only correct process of fixing the checksum: new_CSUM = CSUM + original_address from the TS payload - new_address. (References: [IPSEC] " Another NAT Traversal question ", March 2003.) Kukec Expires August 19, 2007 [Page 18] Internet-Draft Additions to IKEv2 tutorial February 2007 9. Alice's requests for internal address with DHCP and RADIUS If Alice is, for example, the end-node somewhere on the Internet and wants to create a tunnel to a protected network behind a gateway called Bob, she needs to acquire an IP address that belongs to the protected network. IKEv2 calls Alice IPsec Remote Access Client (IRAC) and Bob IPsec Remote Access Server (IRAS). In IKEv1 this part of the IKE protocol was called the MODECFG. IKEv2 has inherited MODECFG almost unchanged, but with different name - Configuration Payloads. Alice needs to allocate address before creating the IKE SAs and CHILD SAs, which means, in the IKE AUTH exchange. She messages Bob with the request for the address and other configuration parameters in the form of the Configuration Payload named CFG_REQUEST. Such request is inserted in the IKE_AUTH request message. Alice can send the request wither with zero-valued attributes or with non-zero attributes. Non- zero attributes Bob interprets as suggested values. Alice can also request the same attribute multiple times by repeating it multiple times in the Configuration Payload. For example, this will happen if she wants to allocate more than one IP address. After the receipt of CFG_REQUEST, Bob achieves requested data from DHCP, RADIUS or LDAP server or any other locally configured pool of data. After receipt of the CFG_REQUEST Bob starts acting as, for example, DHCP client or RADIUS client. When Bob acts as DHCP client, he transforms CFG_REQUEST to DHCPDISCOVER and does a LAN broadcast[RFC2131][dhcpslides]. After the receipt of DHCPOFFER (which represents offered configuration parameters from DHCP server), Bob sends DHCPREQUEST. Finally with DHCPACK message he gets the address and all other configuration data for Alice. Then he forms CFG_REPLY and inserts it in the Configuration Payload before the SA and TS payloads in the IKE AUTH request. In case of the RADIUS client/server communication[RFC2865][dhcpslides], the initial exchange is more complicated due to the fact that it requires a password. The consequent is that Alice needs to perform the extended authentication (EAP) and she needs to insert the Configuration Payload in the first IKE AUTH message. After the receipt of the IKEv2 message 5 that contains the EAP payload, Bob uses the EAP password to perform the RADIUS Access-Request and waits for the RADIUS server to respond with the Access-Response. Access-Response will contain attributes that Bob transforms into Configuration Payload parameters. Bob sends to Alice CFG_REPLY in message 6. Optionally Bob can send Accounting- Request (START) to RADIUS server before message 6 and Accounting- Response (STOP) upon deletion of the IKE SAs and CHILD SAs. Kukec Expires August 19, 2007 [Page 19] Internet-Draft Additions to IKEv2 tutorial February 2007 10. Rekeying and reauthentication IKE SAs and CHILD SAs are allowed to be used only for a limited amount of time. That time is called hardlimit time (authlimit time) in case of IKE SA and softlimit time in case of CHILD SA[RFC4301]. When hardlimit time expires, IKE SA has to be reauthenticated; and when the softlimit time expires, CHILD SA has to be rekeyed. The reauthentication includes always the rekeying and, as a consequent, the hardlimit time has to be shorter than the softlimit time. In order to support light implementations, IKEv2 declares rekeying of the CHILD SAs as an optional mechanism. The rekeying is the process of the new CHILD SA creation followed by the process of deletion of the old CHILD SA. The new CHILD SA belongs to the same IKE SA to which the replaced CHILD SA belonged. The rekeying is achieved with the CREATE_CHILD_SA exchange that contains the REKEY_SA notification. This is contrary to the CREATE_CHILD_SA exchange during the first authentication, which does not contain the REKEY_SA notification. Algorithms proposed in the SA payload of CREATE_CHILD_SA exchange during the reauthentication might not be the same as those in the current SA. This should not be treated as error due to the fact that it is a matter of local policy. The reauthentication is actually the rekeying of the IKE SA; that is the process which starts with the creation of the new, equivalent IKE SA. After the creation of the new IKE SA is finished, the implementation performs rekeying - the creation of the new equivalent CHILD SAs within the new IKE SA. Finally at the end of the reauthentication, implementation uses the old IKE SA (for the last time) to send the DELETE payload to delete itself. Therefore the reauthentication is achieved through completly new initial handshake - IKE INIT exchange and IKE AUTH exchange. Both Alice and Bob are allowed to initiate both the rekeying and the reauthentication. This can lead to the scenarios of a dropping-out- from-synchronization such as simultaneous CHILD_SA close, simultaneous IKE_SA close, simultaneous CHILD_SA rekeying, simultaneous IKE_SA rekeying, parallel closing and rekeying a CHILD_SA, rekeying of the CHILD_SA or IKE_SA soon after its creation that are described in [RFC4718]. 10.1. REKEY_SA and DELETE payloads in the same time Some people argued that there is no need for both the REKEY_SA notification and the exchange of DELETE payloads in the rekeying SAs process. Instead, one could either: Kukec Expires August 19, 2007 [Page 20] Internet-Draft Additions to IKEv2 tutorial February 2007 o replace the existing SA without exchanging DELETE payloads, o or create a parallel SA without the REKEY_SA notification and delete the old one afterwards. In first scenario the problem is the possible lost of some traffic if the decision of not using the old SA immediately after the rekeying is not supported by both Alice and Bob. Although, there were also two things that people pointed out against the second scenario (and in favour of not omitting the REKEY_SA): o REKEY_SA notification contains the SA identifier and is base for avoiding IKEv1-heuristic way of searching for SAs that have to be rekeyed, o REKEY_SA notification allows making statistics over SAs that could provide the optimization of rekeying. Additionally, REKEY_SA notification could be interpreted as an early warning about incoming packets from the new rekeyed SA. However, the DELETE payload also contains the SA identifier - the SPI of Alice's incoming designated SA. So, the only actual reason for REKEY_SA notification lies mainly in the possibility for making statistics. Finally, the only allowed principle currentlu in IKEv2 is rekeying with both the REKEY_SA notification and the DELETE payload. (References: [IPSEC] " REKEY_SA Notify clarification wanted ", July 2005.) 10.2. Bob's repeated authentication Reauthentication in IKEv2 is performed by the repeating of the initial handshake (first four messages) and therefore presents the problem in situations where Bob can not initiate the reauthentication. For example, if Alice is original initiator, only Alice's authentication can be extended and she is the only one that can initiate the reauthentication. The solution for the repeated authentication problem is described in [RFC4478]. [RFC4478] introduces the AUTH_LIFETIME notification which Bob sends in the IKE AUTH response or in the INFORMATIONAL message to Alice. The AUTH_LIFETIME notification contains information about the time period during which Alice has to repeat the authentication. If she does not repeat authentication in the demanded period, Bob sends the Delete notification and deletes the current IKE SA. Kukec Expires August 19, 2007 [Page 21] Internet-Draft Additions to IKEv2 tutorial February 2007 In the case of the EAP reauthentication, one must notice that the identity authenticated by the EAP method may not be equal to the initial identity from the IKEv2 IDi payload. The example is EAP Fast reconnect which Alice can choose to decrease the number of EAP round trips by the reusing of the existing EAP-IKEv2 security context. The described EAP-IKEv2 reauthentication can be performed only if Alice and Bob have already been mutually authenticated. In such reauthentication, Alice uses special Fast reconnect EAP identifier (FRID) to tell Bob that she wants to use the EAP Fast reconnect. FRID will be different than the identity from the IKEv2 IDi payload which was authenticated in the previous exchange. Therefore, one should not perform the symbolic policy lookup based on that old IKEv2 IDi identity. The EAP authenticated identity is always used for access control decisions while the initial response identity from the IKEv2 IDi payload is used for AAA routing purposes and selecting which EAP method to use[RFC3748]. Therefore, the symbolic policy lookup (SPD lookup based on identities prescribed in the PAD database) should always be based on the EAP authenticated identity to ensure the successful policy lookup that follows after each reauthentication. This situation where policy is not selected based on the identity from the ID payload of the IKEv2 message is normally allowed by the protocol and it is not new in the protocol. It is similar to the situation when SPD entry is selected based on some value from the certificate instead of identity from the ID payload. (References: [IPSEC] " Reauthentication in IKEv2 ", October 2004. ) Kukec Expires August 19, 2007 [Page 22] Internet-Draft Additions to IKEv2 tutorial February 2007 11. Security Considerations None. Kukec Expires August 19, 2007 [Page 23] Internet-Draft Additions to IKEv2 tutorial February 2007 12. Acknowledgements I am grateful for the Radia Perlman's permission to work on additions to her draft Understanding IKEv2: Tutorial and Rationale for decisions[ikev2tutorial]. Also, it has been a great experience to be able to work on IKEv2 project for ZEMRIS on Faculty of electrical engineering and computing, University of Zagreb. Kukec Expires August 19, 2007 [Page 24] Internet-Draft Additions to IKEv2 tutorial February 2007 13. References 13.1. Normative References [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4306, December 2005. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC4478] Nir, J. and P. Hoffman, "Repeated Authentication in Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [eapikev2] Tschofenig, H., Kroeselberg, D., Pashalidis, A., Ohba, J., and F. Bersani, "EAP IKEv2 Method", October 2006. [exteapikev2] Eronen, P. and H. Tschofenig, "Extension for EAP Authentication in IKEv2", October 2006. [ikev2tutorial] Perlman, R., "Understanding IKEv2: Tutorial, and rationale for decisions", March 2003. [padslides] Kent, S., "PAD slides for pki4ipsec", November 1998. [pki4ipsec] Korver, B., "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX", September 2006. 13.2. Informative References [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. [RFC2865] Rigney, C., Rubens, A., Simpson, W., and S. Willens, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000. [RFC3748] Aboba, B., Blunk, J., Vollbrecht, J., Carlson, J., and H. Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 4306, June 2004. Kukec Expires August 19, 2007 [Page 25] Internet-Draft Additions to IKEv2 tutorial February 2007 [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and Implementation Guidelines", RFC 4306, December 2005. [dhcpslides] Dukes, D. and G. Lebovitz, "IKEv2 Configuration Payload Integration", March 2003. [eapmitm] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle in Tunneled Authentication Protocols", October 2006. Kukec Expires August 19, 2007 [Page 26] Internet-Draft Additions to IKEv2 tutorial February 2007 Author's Address Ana Kukec University of Zagreb Unska 3 Zagreb 10000 Croatia Email: ana.kukec@fer.hr Kukec Expires August 19, 2007 [Page 27] Internet-Draft Additions to IKEv2 tutorial February 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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. 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, THE IETF TRUST 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. Intellectual Property 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Kukec Expires August 19, 2007 [Page 28]