idnits 2.17.1 draft-smyslov-ipsecme-ikev2-qr-alt-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC8784]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 2, 2021) is 997 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 (-10) exists of draft-ietf-ipsecme-ikev2-intermediate-06 == Outdated reference: A later version (-11) exists of draft-ietf-ipsecme-g-ikev2-03 == Outdated reference: A later version (-12) exists of draft-ietf-ipsecme-ikev2-multiple-ke-03 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group V. Smyslov 3 Internet-Draft ELVIS-PLUS 4 Intended status: Standards Track August 2, 2021 5 Expires: February 3, 2022 7 Alternative Approach for Mixing Preshared Keys in IKEv2 for Post-quantum 8 Security 9 draft-smyslov-ipsecme-ikev2-qr-alt-04 11 Abstract 13 An IKEv2 extension defined in [RFC8784] allows IPsec traffic to be 14 protected against someone storing VPN communications today and 15 decrypting it later, when (and if) quantum computers are available. 16 However, this protection doesn't cover an initial IKEv2 SA, which 17 might be unacceptable in some scenarios. This specification defines 18 an alternative way get the same protection against quantum computers, 19 but unlike the [RFC8784] solution it covers the initial IKEv2 SA too. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on February 3, 2022. 38 Copyright Notice 40 Copyright (c) 2021 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 57 3. Alternative Approach Description . . . . . . . . . . . . . . 3 58 4. Computing IKE SA Keys . . . . . . . . . . . . . . . . . . . . 5 59 5. Comparison of the Conventional and the Alternative Approaches 6 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 62 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 64 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 65 9.2. Informative References . . . . . . . . . . . . . . . . . 7 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 68 1. Introduction 70 The Internet Key Exchange Protocol version 2, defined in [RFC7296], 71 is used in the IPsec architecture to perform authenticated key 72 exchange. [RFC8784] defines an extension of IKEv2 for protecting 73 today's VPN traffic against future quantum computers. At the time 74 this extension was being developed, it was a consensus in the IPSECME 75 WG that only IPsec traffic needs to have such a protection. It was 76 believed that no sensitive information is transferred over IKE SA and 77 extending the protection to also cover IKE SA traffic would require 78 serious modifications to core IKEv2 protocol, that contradicted to 79 one of the goals to minimize such changes. For the cases when this 80 protection is needed it was suggested to immediately rekey IKE SA 81 once it is created. 83 In some situations it is desirable to have this protection for IKE SA 84 from the very beginning, when an initial IKE SA is created. An 85 example of such situation is Group Key Management protocol using 86 IKEv2, defined in [I-D.ietf-ipsecme-g-ikev2]. In this protocol 87 session keys are transferred from Group Controller/Key Server (GCKS) 88 to Group Members (GM) immediately once an initial IKE SA is created. 89 While it is possible to postpone transfer of the keys until the IKE 90 SA is rekeyed (and [I-D.ietf-ipsecme-g-ikev2] specifies how to do 91 this), the needed sequence of actions introduces an additional delay 92 and adds unnecessary complexity to the protocol. 94 Since [RFC8784] was written, a new IKE_INTERMEDIATE exchange for 95 IKEv2 was defined in [I-D.ietf-ipsecme-ikev2-intermediate]. While 96 the primary motivation for developing this exchange was to allow 97 multiple key exchanges to be used in IKEv2 (which is defined in 98 [I-D.ietf-ipsecme-ikev2-multiple-ke]), the IKE_INTERMEDIATE exchange 99 itself can be used for other purposes too. 101 This specification makes use of the IKE_INTERMEDIATE exchange to 102 define an alternative approach to [RFC8784], which allows getting 103 protection against quantum computers for initial IKE SA. 105 2. Terminology and Notation 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 109 "OPTIONAL" in this document are to be interpreted as described in BCP 110 14 [RFC2119] [RFC8174] when, and only when, they appear in all 111 capitals, as shown here. 113 We will use a term Conventional Approach in the content of using PPK 114 to refer to the [RFC8784] and a term Alternative Approach to refer to 115 this specification. 117 3. Alternative Approach Description 119 IKE initiator who supports the IKE_INTERMEDIATE exchange and wants to 120 use PPK includes both the INTERMEDIATE_EXCHANGE_SUPPORTED and the 121 USE_PPK notifications in the IKE_SA_INIT request. If responder 122 supports the IKE_INTERMEDIATE exchange and is willing to use PPK, it 123 includes both these notifications in the response. 125 Initiator Responder 126 ------------------------------------------------------------------ 127 HDR, SAi1, KEi, Ni, 128 N(INTERMEDIATE_EXCHANGE_SUPPORTED), 129 N(USE_PPK) ---> 130 <--- HDR, SAr1, KEr, Nr, [CERTREQ,] 131 N(INTERMEDIATE_EXCHANGE_SUPPORTED), 132 N(USE_PPK) 134 If the responder returned both these notifications, then the 135 initiator MAY choose to use the IKE_INTERMEDIATE exchange to 136 negotiate PPK identity with the responder. Note, that it is up to 137 the initiator whether to use the alternative or conventional 138 approaches, i.e. whether to send PPK identity in the 139 IKE_INTERMEDIATE exchange or in the IKE_AUTH exchange, as defined in 140 the [RFC8784]. 142 If the initiator decides to use alternative approach, it includes one 143 or more PPK_IDENTITY notification containing PPK identities the 144 initiator believes are appropriate for the IKE SA being created, into 145 the IKE_INTERMEDIATE request. If a series of the IKE_INTERMEDIATE 146 exchanges takes place, the PPK_IDENTITY notification(s) MUST be sent 147 in the last one, i.e. in the IKE_INTERMEDIATE exchange immediately 148 preceding the IKE_AUTH exchange. If the last IKE_INTERMEDIATE 149 exchange contains other payloads aimed for some other purpose, then 150 the notification(s) MAY be piggybacked with these payloads. 152 Initiator Responder 153 ------------------------------------------------------------------ 154 HDR, SK { ... N(PPK_IDENTITY, PPK_ID_1) 155 [, N(PPK_IDENTITY, PPK_ID_2)] ... 156 [, N(PPK_IDENTITY, PPK_ID_n)]} ---> 158 Depending on the responder's capabilities and policy the following 159 situations are possible. 161 If the responder doesn't support the alternative approach, it will 162 ignore the received PPK_IDENTITY notification(s) and won't include 163 any additional notifications in the response. If the responder 164 doesn't have any of the PPKs which IDs were sent by the initiator, 165 then it MUST behave as if it doesn't support the alternative 166 approach, i.e. include no additional notifications in the response. 168 Initiator Responder 169 ------------------------------------------------------------------ 170 <--- HDR, SK { ... } 172 In this case the initiator cannot make an initial IKE SA to be a 173 quantum computer resistant, so if this is a requirement for the 174 initiator, then it MUST abort creating IKE SA. Otherwise, the 175 initiator continues with the IKE_AUTH exchange and tries to use PPK 176 as described in [RFC8784]. 178 If the responder supports this extension and is configured with one 179 of the PPKs which IDs were sent by the initiator, then the responder 180 chooses one of these PPKs and returns back its identity in the 181 PPK_IDENTITY notification. 183 Initiator Responder 184 ------------------------------------------------------------------ 185 <--- HDR, SK { ... N(PPK_IDENTITY, PPK_ID_i)} 187 In this case the IKE_AUTH exchange is performed as defined in 188 [RFC7296], so that neither PPK_IDENTITY nor NO_PPK_AUTH notifications 189 are sent, since it's already known which PPK to use. The keys for 190 the IKE SA are computed using PPK, as described in Section 4. 192 If the responder returns PPK identity that was not suggested by the 193 initiator, then the initiator must treat this as a fatal error and 194 MUST abort the IKE SA establishment. 196 Since the responder selects PPK before it knows identity of the 197 initiator, a situation may occur, when the responder agrees to use 198 some PPK in the IKE_INTERMEDIATE exchange, but later discovers during 199 the IKE_AUTH exchange that this particular PPK is not associated with 200 the initiator's identity in its local policy. Note, that the 201 responder does have this PPK, but it is just not listed among the 202 PPKs for using with this initiator. In this case the responder 203 SHOULD abort negotiation and return back the AUTHENTICATION_FAILED 204 notification to be consistent with its policy. However, if using PPK 205 with this initiator is marked optional in the local policy, then the 206 responder MAY continue creating IKE SA using the negotiated "wrong" 207 PPK. 209 4. Computing IKE SA Keys 211 Once the PPK is negotiated in the last IKE_INTERMEDIATE exchange, the 212 IKE SA keys are recalculated. Note that if the IKE SA keys are also 213 recalculated as the result of the other actions performed in the 214 IKE_INTERMEDIATE exchange (for example, as defined in 215 [I-D.ietf-ipsecme-ikev2-multiple-ke], then applying PPK MUST be done 216 after all of them, so that recalculating IKE SA keys with PPK is the 217 last action before they are used in the IKE_AUTH exchange. 219 The IKE SA keys are computed as follows. A new SKEYSEED' value is 220 computed using the negotiated PPK and the most recently computed SK_d 221 key. Note, that PPK is applied to SK_d exactly how specified in 222 [RFC8784], and the result is used as SKEYSEED'. 224 SKEYSEED' = prf+ (PPK, SK_d) 226 Then the SKEYSEED' is used to recalculate all SK_* keys as defined in 227 Section 2.14 of [RFC7296]. 229 {SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr} 230 = prf+ (SKEYSEED', Ni | Nr | SPIi | SPIr ) 232 In the formula above Ni and Nr are nonces from the IKE_SA_INIT 233 exchange and SPIi, SPIr - SPIs of the IKE SA being created. 235 The resulting keys are then used in the IKE_AUTH exchange and in the 236 created IKE SA. 238 5. Comparison of the Conventional and the Alternative Approaches 240 This specification isn't intended to be a replacement for [RFC8784]. 241 Instead, it is supposed to be used in situations where the 242 conventional approach has a significant shortcomings. However, if 243 the partners support both approaches, then the alternative approach 244 MAY also be used in situations where convenient approach suffices. 246 The alternative approach has the following advantages: 248 1. The main advantage of the alternative approach is that it allows 249 an initial IKE SA to be protected against quantum computers. 250 This is important for those IKE extensions which transfer 251 sensitive information, e.g. cryptographic keys, over initial IKE 252 SA. The prominent example of such extensions is 253 [I-D.ietf-ipsecme-g-ikev2]. 255 2. Using the alternative approach allows the initiator to specify 256 several appropriate PPKs and the responder to choose one of them. 257 This feature could simplify PPK rollover. 259 3. With the alternative approach there is no need for the initiator 260 to calculate the content of the AUTH payload twice (with and 261 without PPK) to support a situation when using PPK is optional 262 for both sides. 264 The main disadvantage of the alternative approach is that it requires 265 an additional round trip (the IKE_INTERMEDIATE exchange) to set up 266 IKE SA. However, if the IKE_INTERMEDIATE exchange has to be used for 267 some other purposes in any case, then PPK stuff can be piggybacked 268 with other payloads, thus eliminating this penalty. 270 6. Security Considerations 272 Security considerations of using Post-quantum Preshared Keys in the 273 IKEv2 protocol are discussed in [RFC8784]. This specification 274 defines an alternative way of exchanging PPK identity information. 276 7. IANA Considerations 278 This specification makes no request to IANA. 280 8. Acknowledgements 282 The author would like to thank Paul Wouters for valuable comments. 284 9. References 286 9.1. Normative References 288 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 289 Requirement Levels", BCP 14, RFC 2119, 290 DOI 10.17487/RFC2119, March 1997, 291 . 293 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 294 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 295 May 2017, . 297 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 298 Kivinen, "Internet Key Exchange Protocol Version 2 299 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 300 2014, . 302 [RFC8784] Fluhrer, S., Kampanakis, P., McGrew, D., and V. Smyslov, 303 "Mixing Preshared Keys in the Internet Key Exchange 304 Protocol Version 2 (IKEv2) for Post-quantum Security", 305 RFC 8784, DOI 10.17487/RFC8784, June 2020, 306 . 308 [I-D.ietf-ipsecme-ikev2-intermediate] 309 Smyslov, V., "Intermediate Exchange in the IKEv2 310 Protocol", draft-ietf-ipsecme-ikev2-intermediate-06 (work 311 in progress), March 2021. 313 9.2. Informative References 315 [I-D.ietf-ipsecme-g-ikev2] 316 Smyslov, V. and B. Weis, "Group Key Management using 317 IKEv2", draft-ietf-ipsecme-g-ikev2-03 (work in progress), 318 July 2021. 320 [I-D.ietf-ipsecme-ikev2-multiple-ke] 321 Tjhai, C., Tomlinson, M., Bartlett, G., Fluhrer, S., 322 Geest, D. V., Garcia-Morchon, O., and V. Smyslov, 323 "Multiple Key Exchanges in IKEv2", draft-ietf-ipsecme- 324 ikev2-multiple-ke-03 (work in progress), July 2021. 326 Author's Address 327 Valery Smyslov 328 ELVIS-PLUS 329 PO Box 81 330 Moscow (Zelenograd) 124460 331 RU 333 Phone: +7 495 276 0211 334 Email: svan@elvis.ru