idnits 2.17.1 draft-nir-ipsecme-cafr-00.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 -- The document date (August 13, 2013) is 3907 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 (~~), 2 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 August 13, 2013 5 Expires: February 14, 2014 7 Adopting Child SAs Following Re-Authentication in IKEv2 8 draft-nir-ipsecme-cafr-00 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 February 14, 2014. 33 Copyright Notice 35 Copyright (c) 2013 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. Adopting Child SAs . . . . . . . . . . . . . . . . . . . . . . 4 53 2.1. The ADOPT_CHILD_SAS Notification . . . . . . . . . . . . . 4 54 2.2. Calculating the Proof of Possession Value . . . . . . . . . 5 55 2.3. Verifying the Proof of Possesion Value . . . . . . . . . . 5 56 3. Dealing With the Possible Race Condition . . . . . . . . . . . 6 57 4. Interaction with Other Standards . . . . . . . . . . . . . . . 6 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 60 7. Changes from Previous Versions . . . . . . . . . . . . . . . . 7 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 63 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 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. Adopting Child SAs 113 This document defines a new notification that is added to the 114 IKE_AUTH exchange that is used to re-authenticate. The notification 115 proves that the current participant in the IKE_AUTH exchange is the 116 same one that had participated in the old IKE SA. If both peers send 117 this notification, and it verifies correctly, all Child SAs belonging 118 to the old IKE SA are immediately inherited by the new IKE SA. 120 In addition to the Child SAs, any IP address assigned to either peer 121 through the use of the CFG payload (as described in section 2.19 of 122 RFC 5996, is also associated with the new IKE SA. 124 Following a successful re-authentication exchange, the old IKE SA is 125 deleted by the Initiator. 127 2.1. The ADOPT_CHILD_SAS Notification 129 The ADOPT_CHILD_SA notification is formatted as follows: 131 1 2 3 132 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 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 ! Next Payload !C! RESERVED ! Payload Length ! 135 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 136 ! Protocol ID ! SPI Size ! ADOPT_CHILD_SAS Message Type ! 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | | 139 ~ Security Parameter Index (SPI) ~ 140 | | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | | 143 ~ Notification Data ~ 144 | | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 Figure 1 149 o Protocol ID (1 octet) MUST be 1, denoting an IKE SA. Note that 150 previous versions of RFC 5996 explicitly mentioned the 151 possibility, but the current version omits this as prior to this 152 specification there were no cases where the value 1 should have 153 been used. 154 o SPI Size (1 octet) MUST be 16, as that is the size of the 155 concatenation of the IKE SPIs. 156 o Security Parameter Index (16 octets) - contains the concatenated 157 SPIs of the old IKE SA. The Initiator SPI comes first, similar to 158 the first 16 bytes of the IKE header. 160 o ADOPT_CHILD_SAS Notify Message Type (2 octets) - MUST be xxxxx, 161 the value assigned for ADOPT_CHILD_SAS. TBA by IANA. 162 o Notification Data (variable) - contains the proof of ownership of 163 the previous IKE SA. Calculation of this field is described in 164 Section 2.2. 166 2.2. Calculating the Proof of Possession Value 168 The notification data field in the ADOPT_CHILD_SAS notification is 169 calculated as follows: 171 InitiatorPOP = prf(SK_pi, "Adopting Child SAs for Initiator") 173 ResponderPOP = ptr(SK_pr, "Adopting Child SAs for Responder") 175 InitiatorPOP and ResponderPOP are respectively sent the initiator and 176 responder in the IKE_AUTH exchange that creates the reauthenticated 177 IKE SA. The roles may be reversed from those of the original IKE SA, 178 but it is still the new Initiator that uses the old SK_pi value. The 179 algorithms used, the PRF keys and the length of the output are all 180 those from the old IKE SA, not the new one. 182 2.3. Verifying the Proof of Possesion Value 184 Both sides of the IKE_AUTH exchange should be in possession of the 185 SK_pi and SK_pr values from the previous IKE SA. This allows both 186 sides to make the calculation and verify that it is correct. This 187 verification MUST be done only after the other side has been 188 authenticated. If the value does not verify, the IKE_AUTH exchange 189 MUST be terminated, and an INVALID_SYNTAX notification MUST be sent. 191 To go through with the new IKE SA inheriting the SAs of the old IKE 192 SA, all of the following MUST apply: 193 o Both sides have to be successfully authenticated. 194 o The authenticated identities of both sides are the same as those 195 in the old SA. If the authenticated identity of one peer differs 196 from the authenticated identity that it had in the previous IKE 197 SA, the other side MUST respond with an INVALID_SYNTAX 198 notification. See Section 3 for a discussion of a possible race 199 condition. 200 o The proof of possession values in the ADOPT_CHILD_SAS notification 201 both validated. The responder MUST NOT continue in sending the 202 last IKE_AUTH packet if this condition is not satisfied. See 203 Section 3 for a discussion of what happens if the responder's 204 notification does not validate. 206 3. Dealing With the Possible Race Condition 208 The sections above describe two kinds of failures in the IKE_AUTH 209 exchange: 210 1. An authentication failure. This could be something as sinister 211 as an attack, or as innocent as a temporary failure to contact an 212 OCSP server. 213 2. A validation failure of the ADOPT_CHILD_SAS notification. 215 If either of those failures occurs for the Initiator, there is no 216 problem. The IKE_AUTH exchange is aborted, the old IKE SA is still 217 valid, and all the Child SAs belong to that old IKE SA. 219 If, however, the failure occurs for the Responder, we may have a 220 problem. Having sent the last IKE_AUTH response, the responder is 221 confident that the exchange has completed successfully, and can 222 transfer the Child SAs to the new IKE SA. However, when the 223 Initiator sees that last response, one of the two errors happens, and 224 this leads it to delete the new IKE SA. The Responder erases the new 225 IKE SA, deleting with it all the Child SAs. The result is a mismatch 226 in databases, where the Initiator still has the valid SAs, while the 227 Responder does not. 229 If the Child SAs have been transferred, and the new IKE SA has been 230 deleted, but the old IKE SA has not yet been deleted, then the 231 Responder MUST delete the old IKE SA (using a DELETE payload) 232 immediately after receiving the deletion of the new IKE SA. If the 233 Child SAs have not yet been transferred, then the Responder MAY keep 234 the old IKE SA along with the Child SAs until they are deleted by the 235 peer or expire according to policy. 237 The Initiator MUST NOT delete the old IKE SA because of a failure of 238 IKE to create a new IKE SA. The old IKE SA may only be deleted if 239 policy dictates it, such as when a reauthentication timer expires. 241 Following a successful verification and transfer of the Child SAs, 242 the Initiator SHOULD delete the old IKE SA. 244 4. Interaction with Other Standards 246 This document changes things so that there is often no need to create 247 new Child SAs along with the new IKE SA when reauthenticating. This 248 makes the full IKE_AUTH exchange with the piggy-backed Child SA 249 exchange (as described in RFC 5996) superfluous. Implementations 250 should consider implementing the childless extension of IKEv2 251 ([RFC6023] in addition to this specification. 253 5. IANA Considerations 255 IANA is requested to assign a notify message type from the status 256 types range (16418-40959) of the "IKEv2 Notify Message Types" 257 registry with name "ADOPT_CHILD_SAS" 259 6. Security Considerations 261 Comparing the authenticated identities of the new IKE SA with those 262 of the old IKE SA is critical. Without it, attackers would be able 263 to authenticate as themselves, steal the Child SAs, and then close 264 them. The proof of possession seems to be superfluous, and in most 265 cases it really is. However, there are some uses of IKE by multiple 266 entities with a shared identity and a shared credential. Calculating 267 and verifying the proof of possession blocks such entities from 268 stealing each others SAs. 270 An on-path attacker may get the Initiator to send the ADOPT_CHILD_SAS 271 notification before failing authentication. This notification is a 272 PRF calculated with a secret key over a known message. The security 273 properties of PRFs are such that this does not reveal any secret data 274 such as IKE SA keys. 276 7. Changes from Previous Versions 278 First version 280 8. References 282 8.1. Normative References 284 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 285 Requirement Levels", BCP 14, RFC 2119, March 1997. 287 [RFC5996bis] 288 Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 289 Kivinen, "Internet Key Exchange Protocol Version 2 290 (IKEv2)", draft-kivinen-ipsecme-ikev2-rfc5996bis-00 (work 291 in progress), August 2013. 293 8.2. Informative References 295 [RFC6023] Nir, Y., Tschofenig, H., Deng, H., and R. Singh, "A 296 Childless Initiation of the Internet Key Exchange Version 297 2 (IKEv2) Security Association (SA)", RFC 6023, 298 October 2010. 300 Author's Address 302 Yoav Nir 303 Check Point Software Technologies Ltd. 304 5 Hasolelim st. 305 Tel Aviv 6789735 306 Israel 308 Email: ynir@checkpoint.com