INTERNET-DRAFT Keith Welter Intended Status: Experimental IBM Expires: April 1,2011 September 28, 2010 Reauthentication Extension for IKEv2 draft-welter-ipsecme-ikev2-reauth-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html Copyright and License 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. Keith Welter Expires April 1, 2011 [Page 1] INTERNET DRAFT Reauthentication Extension for IKEv2September 28, 2010 Abstract This document extends the Internet Key Exchange (IKEv2) Protocol document [IKEv2]. IKEv2 reauthentication does not scale well when an IKE SA has multiple Child SAs because each Child SA of the IKE SA to be reauthenticated must be renegotiated. In addition, reauthentication is susceptible to the same kinds of exchange collisions as those that may occur during rekeying. This document describes a mechanism to detect reauthentication and avoid renegotiating the Child SAs. In addition, this document describes proper handling of exchange collisions that may occur during reauthentication. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2. IKE SA Reauthentication With N(REAUTH_SA) . . . . . . . . . . . 3 3. Simultaneous IKE SA Reauthentication Without N(REAUTH_SA) . . . 5 4. Simultaneous IKE SA Reauthentication With N(REAUTH_SA) . . . . . 5 4.1. Simultaneous IKE SA Reauthentication Detected By One Peer . 8 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 9 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1 Normative References . . . . . . . . . . . . . . . . . . 10 5.2 Informative References . . . . . . . . . . . . . . . . . 10 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Keith Welter Expires April 1, 2011 [Page 2] INTERNET DRAFT Reauthentication Extension for IKEv2September 28, 2010 1. Introduction Reauthentication was an afterthought in IKEv2. The term did not appear in [RFC4306] and was first defined in [Clarif] section 5.2 and this section was then copied nearly verbatim into [IKEv2] section 2.8.3. This document specifies a new notification for identifying the IKE SA that is being reauthenticated. This enables exchange collisions that occur during reauthentication to be detected and handled with the same degree of robustness that is afforded to exchange collisions that occur during IKE SA rekeying. The new notification specified in this document also makes it possible to move the Child SAs from the IKE SA being reauthenticated to the reauthenticating IKE SA in the same fashion as the movement of Child SAs following IKE SA rekeying while maintaining backwards compatibility with implementations that do not support the new notification. 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 RFC 2119 [RFC2119]. 2. IKE SA Reauthentication With N(REAUTH_SA) The IKE_SA_INIT request for reauthenticating an IKE SA is: Initiator Responder ------------------------------------------------------------------- HDR, N(REAUTH_SA), SAi1, KEi, Ni --> HDR, SAi1, KEi and Ni are as described in [IKEv2] section 1.2. The SPI field of the REAUTH_SA notification contains the SPIi followed by the SPIr of the IKE SA to be reauthenticated. There is no data. Once a peer receives a request to reauthenticate an IKE SA or sends a request to reauthenticate an IKE SA, it SHOULD NOT start any new CREATE_CHILD_SA exchanges on the IKE SA that is being reauthenticated. Keith Welter Expires April 1, 2011 [Page 3] INTERNET DRAFT Reauthentication Extension for IKEv2September 28, 2010 The IKE_SA_INIT response for reauthenticating an IKE SA is: Initiator Responder ------------------------------------------------------------------- <-- HDR, [N(REAUTH_SA),] SAr1, KEr, Nr, [CERTREQ] HDR, SAr1, KEr and Nr are as described in [IKEv2] section 1.2. If the responder recognizes the IKE SA identified by SPIi and SPIr in the REAUTH_SA notification sent by the initiator then the same REAUTH_SA notification is included in the response. If the response does not include the REAUTH_SA notification it indicates that either the responder does not recognize the IKE SA to be reauthenticated or the responder does not support the REAUTH_SA notification. In either of these cases, the initiator SHOULD continue with reauthentication as described in [IKEv2] section 2.8.3. If the SPIs in the REAUTH_SA notification in the response do not match the SPIs in the REAUTH_SA notification in the request or if the IKE_AUTH response contains a REAUTH_SA notification but the IKE_AUTH request did not, then the initiator SHOULD close the new IKE SA. The negotiation proceeds with the IKE_AUTH exchange as described in [IKEv2] section 1.2 but without the SAi2, SAr2, TSi or TSr payloads. Initiator Responder ------------------------------------------------------------------- HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH} --> <-- HDR, SK {IDr, [CERT,] AUTH} The new IKE SA created as a result of the reauthentication inherits all of the original IKE SA's Child SAs, and the new IKE SA is used for all control messages needed to maintain those Child SAs. After the new IKE SA is created, the initiator deletes the old IKE SA, and the Delete payload to delete itself MUST be the last request sent over the old IKE SA. Keith Welter Expires April 1, 2011 [Page 4] INTERNET DRAFT Reauthentication Extension for IKEv2September 28, 2010 3. Simultaneous IKE SA Reauthentication Without N(REAUTH_SA) IKE SA reauthentication as defined in [IKEv2] is accomplished by creating a new IKE SA, creating new Child SAs, and deleting the old IKE SA. Simultaneous authentication of an IKE SA may result in redundant IKE SAs and Child SAs similar to how redundant SAs result from simultaneous rekeying of an IKE SA. However, though [IKEv2] defines a mechanism for resolving simultaneous rekeying of an IKE SA in section 2.8.2 it does not define a mechanism for resolving simultaneous reauthentication. To solve this problem, a host which sends or receives a reauthentication request containing the N(REAUTH_SA) notification will stop sending or accepting CREATE_CHILD_SA exchanges on the IKE SA being reauthenticated and it will resolve simultaneous reauthentication by deleting redundant SAs in a manner similar to that described in [IKEv2] section 2.8.2. 4. Simultaneous IKE SA Reauthentication With N(REAUTH_SA) If the two ends have the same reauthentication policies, it is possible that both will initiate a reauthentication at the same time which will result in redundant SAs. To reduce the probability of this happening, the timing of reauthentication requests SHOULD be jittered (delayed by a random amount of time after the need for reauthentication is noticed). After the IKE_SA_INIT and IKE_AUTH exchanges in a simultaneous reauthentication case, three IKE SAs exist between A and B: the old IKE SA and two new IKE SAs. The new IKE SA containing the lowest nonce SHOULD be deleted by the node that created it, and the other surviving new IKE SA MUST inherit the Child SAs that existed under the old IKE SA. Deletion of the old IKE SA SHOULD be done by the node that created the surviving new IKE SA. Keith Welter Expires April 1, 2011 [Page 5] INTERNET DRAFT Reauthentication Extension for IKEv2September 28, 2010 The following is an explanation on the impact this has on implementations. Assume that hosts A and B have an existing IKE SA pair with IKE SPIs (SPIi1,SPIr1), and both start reauthenticating it at the same time. Host A Host B ------------------------------------------------------------------- send req1: HDR(SPIi2,0), N(REAUTH_SA, SPIi1, SPIr1), SA, Ni1, KEi1 --> <-- send req2: HDR(SPIi3,0), N(REAUTH_SA, SPIi1, SPIr1), SA, Ni2, KEi2 recv req2 <-- At this point, A knows there is a simultaneous reauthentication going on. However, it cannot yet know which of the exchanges will have the lowest nonce. It responds with N(REAUTH_SA). send resp2: HDR(SPIi3,SPIr2), N(REAUTH_SA, SPIi1, SPIr1), SA, Nr1, KEr1 --> --> recv req1 Now B also knows there is a simultaneous reauthentication going on. It responds with N(REAUTH_SA). <-- send resp1: HDR(SPIi2,SPIr4), N(REAUTH_SA, SPIi1, SPIr1), SA, Nr2, KEr2 recv resp1 <-- --> recv resp2 send req3: HDR(SPIi2,SPIr4), SK{ IDi,[CERT,][CERTREQ,] [IDr,] AUTH} --> <-- send req4: HDR(SPIi3,SPIr2), SK{ IDi,[CERT,][CERTREQ,] [IDr,] AUTH} --> recv req3 Keith Welter Expires April 1, 2011 [Page 6] INTERNET DRAFT Reauthentication Extension for IKEv2September 28, 2010 <-- send resp3: HDR(SPIi2,SPIr4), SK{IDr,[CERT,] AUTH} recv req4 <-- send resp4: HDR(SPIi3,SPIr2), SK {IDr, [CERT,] AUTH} --> recv resp3 <-- --> recv resp4 At this point, there are three IKE SA pairs between A and B (the old one and two new ones). A and B can now compare the nonces. Suppose that the lowest nonce was Nr1 in message resp2; in this case, B (the sender of req2) deletes the redundant new SA. <-- send req5: HDR(SPIi3,SPIr2),D() recv req5 <-- send resp5: HDR(SPIi3,SPIr2) --> Both A and B move any Child SAs from the IKE SA that was reauthenticated to the surviving IKE SA which in this example has SPIi2 and SPIr4. Once A finishes moving any Child SAs from the reauthenticated IKE SA to the surviving IKE SA, A deletes the old IKE SA. send req6: HDR(SPIi1,SPIr1), D() --> --> recv req6 <-- send resp6: HDR(SPIi1,SPIr1) The reauthentication is now finished. Keith Welter Expires April 1, 2011 [Page 7] INTERNET DRAFT Reauthentication Extension for IKEv2September 28, 2010 4.1. Simultaneous IKE SA Reauthentication Detected By One Peer In addition to the normal simultaneous reauthentication case, there is a special case where one peer finishes its reauthentication before it notices that the other peer is doing a reauthentication. If only one peer detects a simultaneous reauthentication, redundant SAs are not created. In this case, when the peer that did not notice the simultaneous reauthentication gets the request with N(REAUTH_SA) referring to the IKE SA that it has already successfully reauthenticationed, it SHOULD return TEMPORARY_FAILURE because it refers to an IKE SA that it is currently trying to close (whether or not it has already sent the delete notification for the SA). If the peer that did notice the simultaneous reauthentication gets the delete request from the other peer for the old IKE SA, it knows that the other peer did not detect the simultaneous reauthentication, and the first peer can forget its own reauthentication attempt. Host A Host B ------------------------------------------------------------------- send req1: (IKE_SA_INIT request with N(REAUTH_SA)) --> <-- send req2: (IKE_SA_INIT request with N(REAUTH_SA)) --> recv req1 <-- send resp1: (IKE_SA_INIT response with N(REAUTH_SA)) recv resp1 <-- send req3: (IKE_AUTH request without SA,TSi,TSr) --> --> recv req3 <-- send resp3: (IKE_AUTH response without SA,TSi,TSr) recv resp3 <-- send req4: HDR, SK{D()} --> If host A receives req2 at this point, it sees a request to reauthenticate an IKE SA that it is trying to close. In this case host A replies with TEMPORARY_FAILURE. recv req2 <-- send resp4 HDR, SK{N(TEMPORARY_FAILURE)} --> --> recv req4 Keith Welter Expires April 1, 2011 [Page 8] INTERNET DRAFT Reauthentication Extension for IKEv2September 28, 2010 At this point, host B sees a request to close the IKE SA that it is trying to reauthenticate. There's not much more to do than to reply as usual. However, at this point host B should stop retransmitting req2 since the IKE SA is already reauthenticated. <-- send resp5: HDR,SK{} 5. Collisions While Reauthenticating IKE SAs In this section, a request to reauthenticate an IKE SA is taken to mean an IKE_SA_INIT request containing the REAUTH_SA notification as described in section 4. In the absence of a REAUTH_SA notification, it is ambiguous whether an IKE_SA_INIT request represents a request to reauthenticate an existing IKE SA or not. If a peer receives a request to reauthenticate an IKE SA for which it has already sent a request to reauthenticate, but has not received the response, it SHOULD reply as usual, and SHOULD prepare to close redundant SAs and prepare to move Child SAs from the reauthenticated IKE SA to the surviving IKE SA based on the nonces (see Section 3). If a peer receives a request to reauthenticate an IKE SA with an N(REAUTH_SA) notification referring to an IKE SA that it is currently trying to close, it SHOULD reply with TEMPORARY_FAILURE. If a peer receives a request to close an IKE SA that it is currently reauthenticating, it SHOULD reply as usual, and forget about its own reauthentication request. If a peer receives a request to create or rekey a Child SA when it is currently reauthenticating the IKE SA, it SHOULD reply with TEMPORARY_FAILURE. If a peer receives a request to delete a Child SA when it is currently reauthenticating the IKE SA, it SHOULD reply as usual, with a Delete payload. If a peer receives a request to reauthenticate an IKE SA that it does not recognize it MAY log the event and SHOULD reply as usual but without the REAUTH_SA notification. 3 Security Considerations Since the REAUTH_SA notification is included in the IKE_SA_INIT exchange it is not encrypted. However, the information that notification contains, namely IKE SPIs, are normally transmitted in the clear in the IKE header so no new information is revealed that a man in the middle could not already observe. Also, successful authentication of the IKE SA proves that the messages in the IKE_SA_INIT exchange have not been altered in transit so an attacker Keith Welter Expires April 1, 2011 [Page 9] INTERNET DRAFT Reauthentication Extension for IKEv2September 28, 2010 can not profit by tampering with the REAUTH_SA notification any more than he could by tampering with any other part of an IKE_SA_INIT exchange message. 4 IANA Considerations One new addition to the IKEv2 parameters "NOTIFY MESSAGES - STATUS TYPES" registry are defined here: {TBA} REAUTH_SA 5 References 5.1 Normative References [IKEv2] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. [RFC2119] Bradner, S., "Key Words for use in RFCs to indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 5.2 Informative References [RFC4306] Kaufman, C., Ed., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [Clarif] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and Implementation Guidelines", RFC 4718, October 2006. Author's Addresses Keith Welter IBM 425 Market Street San Francisco, CA 94105-2406 USA EMail: welterk@us.ibm.com Keith Welter Expires April 1, 2011 [Page 10]