idnits 2.17.1 draft-nir-ipsecme-cafr-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the new IKE SA is not fully authenticated, or if the peer authenticated identity in the new IKE SA is not the same as in the current IKE SA, a conformant Responder MUST NOT send the HAND_OVER_CHILD_SAS Notification, and MUST not move the Child SAs. -- The document date (April 13, 2014) is 3659 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-04) exists of draft-kivinen-ipsecme-ikev2-rfc5996bis-00 -- Possible downref: Normative reference to a draft: ref. 'RFC5996bis' Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPsecME Working Group Y. Nir 3 Internet-Draft Check Point 4 Intended status: Standards Track April 13, 2014 5 Expires: October 15, 2014 7 Handing Over Child SAs Following Re-Authentication in IKEv2 8 draft-nir-ipsecme-cafr-04 10 Abstract 12 This document describes an extension to the IKEv2 protocol whereby 13 Child SAs are moved to the new IKE SA following re-authentication. 14 This allows for a smoother transition with no loss of connectivity. 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on October 15, 2014. 33 Copyright Notice 35 Copyright (c) 2014 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1. Conventions Used in This Document . . . . . . . . . . . . . 3 52 2. Handing Over Child SAs . . . . . . . . . . . . . . . . . . . . 4 53 2.1. The HAND_OVER_CHILD_SAS Notification . . . . . . . . . . . 4 54 2.2. Verifying the HAND_OVER_CHILD_SAS Notification . . . . . . 5 55 3. The Illustrated Protocol . . . . . . . . . . . . . . . . . . . 5 56 4. Interaction with Other Standards . . . . . . . . . . . . . . . 6 57 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 60 8. Changes from Previous Versions . . . . . . . . . . . . . . . . 7 61 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 63 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 The Internet Key Exchange version 2 (IKEv2) protocol, as specified in 69 [RFC5996bis] associates Child SAs with the IKE SAs under which the 70 exchange that created them took place. With the deletion of the IKE 71 SA due to expiry, policy change, or an explicit message from the 72 peer, the child SAs associated with it are implicitly closed as 73 described in section 1.4.1 of the IKEv2 document. This behavior is 74 not desired when IKE SAs are replaced rather than deleted, because 75 those child SAs could still be valid and there is no security reason 76 to create new ones prematurely. 78 There are two cases where an IKE SA is replaced. 79 1. Rekeying, where new keys are generated. This is described in 80 section 2.18 of RFC 5996. This is done mainly for key freshness. 81 2. Re-Authentication, where both sides authenticate, and new keys 82 are generated. This is done as part of a risk management policy, 83 to limit the time that compromised IKE SA keys can be used to 84 provide the attacker access to the network. No reauthentication 85 exchange is specified in the RFC. Instead, it's simply the 86 Initial and Authentication exchanges done as if from scratch. 87 This is described in section 2.8.3 of RFC 5996. 89 For rekeying, RFC 5996 provides a way to avoid having to re-create 90 all child SAs. When an IKE SA is rekeyed, all the Child SAs under 91 the old IKE SA are inherited by the new IKE SA, so that the 92 subsequent deletion of the old IKE SA does not affect the Child SAs. 93 This behavior is described in section 2.8 paragraph 4 of RFC 5996. 95 For reauthentication, RFC 5996 does not provide a similar mechanism, 96 and section 2.8.3 explicitly says that Child SAs need to be created 97 from scratch. This is often inconvenient, as IPsec systems usually 98 create Child SAs only in response to traffic and multiple Child SAs 99 may exist for a single IKE SA. The protocol extension in this draft 100 closes this gap. 102 1.1. Conventions Used in This Document 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in [RFC2119]. 108 The terms IKE SA, Child SA, Rekeying, and Reauthentication are as 109 described in the RFC 5996. 111 2. Handing Over Child SAs 113 This document defines a new notification that can be sent over an old 114 IKE SA, just after an IKE_AUTH exchange has been used to re- 115 authenticate. The notification tells the peer to transfer all Child 116 SAs that belong to the current (old) IKE SA to be owned by the new 117 IKE SA, so that when the old IKE SA is deleted, those Child SAs are 118 not. If both peers send this notification, all Child SAs belonging 119 to the old IKE SA are immediately inherited by the new IKE SA. 121 In addition to the Child SAs, any IP address assigned to either peer 122 through the use of the CFG payload (as described in section 2.19 of 123 RFC 5996), is also associated with the new IKE SA. 125 The new notification MAY be accompanied by a DELETE payload, so as to 126 transfer the Child SAs and delete the old IKE SA at the same time. 127 These payloads don't have to be in the same exchange, and it is 128 perfectly valid for the initiator to send the HAND_OVER_CHILE_SA 129 notification in one exchange, and only then send the DELETE payload 130 in a different exchange. A responder, however, MUST support 131 receiving both payloads in the same exchange, and MUST transfer the 132 child SAs and assigned IP address before acting on the DELETE 133 payload. 135 2.1. The HAND_OVER_CHILD_SAS Notification 137 The HAND_OVER_CHILD_SA notification is formatted as follows: 139 1 2 3 140 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 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 ! Next Payload !C! RESERVED ! Payload Length ! 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 ! Protocol ID ! SPI Size ! HAND_OVER_CHILD_SAS Type ! 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | | 147 ~ New IKE Security Parameter Index (SPI) ~ 148 | | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 Figure 1 153 o Protocol ID (1 octet) MUST be zero, as specified in Section 3.10 154 of RFC 5996. 155 o SPI Size (1 octet) MUST be zero, in conformance with Section 3.10 156 of RFC 5996. 158 o HAND_OVER_CHILD_SAS Notify Message Type (2 octets) - MUST be 159 xxxxx, the value assigned for HAND_OVER_CHILD_SAS. TBA by IANA. 160 o Notification Data, or New IKE Security Parameter Index (16 or zero 161 octets) - In the request, this field contains the concatenated 162 SPIs of the new IKE SA. The Initiator SPI comes first, similar to 163 the first 16 bytes of the IKE header. Note that this is not the 164 SPI field of the notification payload, but the data field. In the 165 response, this field is omitted (zero-length). 167 2.2. Verifying the HAND_OVER_CHILD_SAS Notification 169 To go through with the new IKE SA inheriting the SAs of the old IKE 170 SA, all of the following MUST apply: 171 o Both sides have to be successfully authenticated, and the new IKE 172 SA has to be established. 173 o The authenticated identities of both sides under the new IKE SA 174 are the same as those under the old IKE SA. If the authenticated 175 identity of one peer differs from the authenticated identity that 176 it had in the previous IKE SA, the Responder MUST NOT return the 177 HAND_OVER_CHILD_SAS notification. Such an error indicates either 178 an attack or a bug in the peer, so this should be logged and 179 reported. 180 o The New IKE SPIs in the notifications from both peers MUST match 181 bit for bit. 183 If the new IKE SA is not fully authenticated, or if the peer 184 authenticated identity in the new IKE SA is not the same as in the 185 current IKE SA, a conformant Responder MUST NOT send the 186 HAND_OVER_CHILD_SAS Notification, and MUST not move the Child SAs. 188 If the Initiator has not sent the HAND_OVER_CHILD_SAS notification, 189 but has received it in a response, it MUST ignore it and MUST NOT 190 move the Child SAs. 192 If the Initiator has sent the notification, but the Responder has not 193 sent it, then the Initiator MUST NOT move the Child SAs. 195 If the Initiator has sent the notification, but the notification from 196 the Responder contains IKE SPIs (whether correct or not), then the 197 Initiator MUST send a SYNTAX_ERROR notification and MUST NOT transfer 198 the Child SAs. 200 3. The Illustrated Protocol 202 The Informational exchange after creating a new IKE SA: 204 Initiator Responder 205 ----------------------------------------------------------------- 206 HDR, SK { 207 N(HAND_OVER_IKE_SAS, new IKE SA SPIs), 208 DELETE 209 } --> 210 HDR, SK { 211 N(HAND_OVER_IKE_SAS, new IKE SA SPIs) 212 <-- } 214 Figure 2 216 Note that in the above figure, the HDR has the IKE SPIs of the old 217 IKE SAs, and the SK payload uses the keys of the old IKE SA, because 218 this message is sent over the old IKE SA. 220 4. Interaction with Other Standards 222 This document changes things so that there is often no need to create 223 new Child SAs along with the new IKE SA when reauthenticating. This 224 makes the full IKE_AUTH exchange with the piggy-backed Child SA 225 exchange (as described in RFC 5996) superfluous. Implementations 226 should consider implementing the childless extension of IKEv2 227 ([RFC6023]) in addition to this specification. 229 5. Acknowledgements 231 The author would like to thank Valery Smyslov for the suggestion of 232 moving the hand-over from the IKE_AUTH to an Informational under the 233 old IKE SA and other suggestions. This changed (in version -01) 234 simplified the protocol significantly. Tero Kivinen provided 235 valuable input about the security considerations and error handling. 237 6. IANA Considerations 239 IANA is requested to assign a notify message type from the status 240 types range (16418-40959) of the "IKEv2 Notify Message Types" 241 registry with name "HAND_OVER_CHILD_SAS" 243 7. Security Considerations 245 The HAND_OVER_CHILD_SAS notification is sent protected by the old IKE 246 SA. This protects against stealing child SAs. The requirement for 247 sameness of authenticated identity protects against errors by one 248 peer transferring child SAs to some other peer. It also protects 249 against an attempt by one endpoint to transfer ownership of SAs to 250 another endpoint, so as to assume the authorization assigned by the 251 peer to the other endpoint. 253 8. Changes from Previous Versions 255 [NOTE TO RFC EDITOR: PLEASE REMOVE THIS SECTION] 257 Version -01 moved the sending of the notification from the IKE_AUTH 258 exchange that is part of reauthentication to the Informational 259 exchange that is part of closing the old IKE SA. This made 260 cryptographic binding to the old IKE SA unnecessary. 262 Version -02 changed the notification payload so that the IKE SPI of 263 the other IKE SA is now in the data field of the notification 264 payload, rather than the SPI field. This makes it more in line with 265 how the notification payload is defined in RFC 5996. 267 Version -03 tightened the security considerations, the format of the 268 notification in the response, and error handling. 270 9. References 272 9.1. Normative References 274 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 275 Requirement Levels", BCP 14, RFC 2119, March 1997. 277 [RFC5996bis] 278 Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 279 Kivinen, "Internet Key Exchange Protocol Version 2 280 (IKEv2)", draft-kivinen-ipsecme-ikev2-rfc5996bis-00 (work 281 in progress), August 2013. 283 9.2. Informative References 285 [RFC6023] Nir, Y., Tschofenig, H., Deng, H., and R. Singh, "A 286 Childless Initiation of the Internet Key Exchange Version 287 2 (IKEv2) Security Association (SA)", RFC 6023, 288 October 2010. 290 Author's Address 292 Yoav Nir 293 Check Point Software Technologies Ltd. 294 5 Hasolelim st. 295 Tel Aviv 6789735 296 Israel 298 Email: ynir.ietf@gmail.com