idnits 2.17.1 draft-smyslov-ikev2-pake-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 9, 2019) is 1691 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-26) exists of draft-irtf-cfrg-spake2-08 == Outdated reference: A later version (-06) exists of draft-krawczyk-cfrg-opaque-02 == Outdated reference: A later version (-10) exists of draft-ietf-ipsecme-ikev2-intermediate-02 Summary: 2 errors (**), 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: Informational September 9, 2019 5 Expires: March 12, 2020 7 Usage of PAKE Protocols with IKEv2 8 draft-smyslov-ikev2-pake-00 10 Abstract 12 This memo discusses how PAKE (Password Authenticated Key Exchange) 13 protocols can be integrated into the IKEv2 (Internet Key Exchange) 14 protocol. 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 https://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 March 12, 2020. 33 Copyright Notice 35 Copyright (c) 2019 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 52 3. Integrating PAKE protocols into IKEv2 . . . . . . . . . . . . 3 53 3.1. Using EAP methods . . . . . . . . . . . . . . . . . . . . 3 54 3.2. Using RFC6467 framework . . . . . . . . . . . . . . . . . 4 55 3.2.1. Algorithm Agility . . . . . . . . . . . . . . . . . . 5 56 3.2.2. AUTH Payload Calculation . . . . . . . . . . . . . . 5 57 3.2.3. Possible PAKE Protocols Instantiation . . . . . . . . 6 58 3.3. Alternative Approaches . . . . . . . . . . . . . . . . . 12 59 3.3.1. Using Secret Generator in IKE_SA_INIT . . . . . . . . 12 60 3.3.2. Using IKE_INTERMEDIATE Exchange . . . . . . . . . . . 13 61 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 63 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 66 1. Introduction 68 Recent interest in PAKE protocols in IETF resulted in launching the 69 PAKE selection process in CFRG. The goal of the process is to select 70 one (or more, or zero) PAKE protocol(s) that will be recommended to 71 be used in IETF security protocols, such as TLS 1.3, IKEv2 etc. 72 There are eight candidates nominated: four balanced PAKEs (SPAKE2 73 [I-D.irtf-cfrg-spake2], J-PAKE [RFC8236], SPERE [SPEKE] and CPace 74 [CPace-AuCPace]) and four augmented ones (OPAQUE 75 [I-D.krawczyk-cfrg-opaque], AuCPace [CPace-AuCPace], VTBPEKE 76 [VTBPEKE] and BSPAKE [BSPAKE]). The part of the selection process is 77 an evaluation of how well the candidates can be fit into existing 78 IETF security protocols. This memo aims to discuss how each of the 79 candidates can be integrated into IKEv2. 81 The IKEv2 protocol defined in [RFC7296] is a key part of IPsec (IP 82 Security) architecture, as it provides an authenticated key exchange 83 between peers who wish to establish an IPsec SA (Security 84 Association). Core IKEv2 specification allows peers to authenticate 85 each other either by using PSK (Pre-Shared Key) or by means of 86 digital signatures. In addition, the core IKEv2 specification allows 87 optional use of EAP (Extensible Authentication Protocol) in the 88 protocol. Note, that the way EAP was originally integrated into 89 IKEv2 still required using digital signatures by responder. However, 90 later an extension for the IKEv2 was developed, which allowed using 91 EAP-only authentication [RFC5998]. 93 2. Terminology and Notation 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 97 "OPTIONAL" in this document are to be interpreted as described in BCP 98 14 [RFC2119] [RFC8174] when, and only when, they appear in all 99 capitals, as shown here. 101 3. Integrating PAKE protocols into IKEv2 103 Authentication by means of PAKE protocols in IKEv2 is of high 104 interest in IPSECME WG. Both balanced and augmented PAKEs can be 105 employed - the former are suitable for peer to peer communication, 106 when each side can initiate, while the latter are good for remote 107 access scenarios. 109 Note, that for augmented PAKE protocols a password setup step is 110 needed, during which password verifier is generated and transferred 111 to server. This step is out of scope of this memo, we assume that 112 all the setup steps are already somehow done. 114 Early attempts to integrate PAKE protocols into IKEv2 were made in 115 IPSECME WG around 2009-2011. The easiest way to do it would be to 116 define new EAP methods based on PAKE protocols and to rely on build- 117 in EAP authentication (along with "EAP-only" extension). However, 118 the disadvantage of this approach is its inefficiency and complexity. 119 As a result, the WG developed a new experimental IKEv2 extension, 120 that aimed to provide a framework for integration of any PAKE 121 protocol into IKEv2 [RFC6467]. This extension generalizes any PAKE 122 protocol as a series of message exchanges resulted in the computing 123 of a shared secret. The extension defines how use of a particular 124 PAKE is negotiated and how PAKE messages are transferred in multi- 125 round IKE_AUTH exchange. Several PAKE protocols were then 126 instantiated using this extension: "Dragonfly" [RFC6617], AugPAKE 127 [RFC6628] and PACE [RFC6631]. 129 3.1. Using EAP methods 131 Integration of PAKE protocols into IKEv2 using EAP methods is the 132 simplest possible way from protocol point of view, because it 133 requires no modification to the IKEv2 (provided EAP is already 134 supported and "EAP-only" extension to IKEv2 is implemented). 135 However, this approach has the following drawbacks. 137 o Lack of flexibility. Using EAP is not negotiated in IKEv2, it's 138 done on initiator's discretion. It's better to have ability to 139 negotiate using PAKE or convenient authentication. 141 o Duplicated functionality. If some PAKE EAP methods are available 142 (or a single method with different parameters) it is EAP that 143 would negotiate using a particular one. IKEv2 has its own 144 negotiation mechanism that's better to be used instead. In 145 addition, EAP methods would have use their own variables, like 146 session id, peers identities etc. These variables are available 147 in IKEv2 and it's better to use them instead. 149 o Inefficiency. EAP methods for PAKE protocols would have included 150 a key confirmation step that would have required an additional 151 round trip and some computations. This step is not needed in case 152 of IKEv2, since IKEv2 will do this step itself anyway. 154 o Complexity. EAP adds an additional layer of encapsulation, that 155 is not always needed. 157 For these reasons integration of PAKE protocols into IKEv2 using EAP 158 methods is NOT RECOMMENDED. Note, that currently from the eight PAKE 159 candidates listed in Section 1, only for SPEKE a ready to use EAP 160 method is defined (see [EAP-IANA]. EAP methods for other PAKE 161 candidates are not yet defined. 163 3.2. Using RFC6467 framework 165 This framework was specifically designed as a lightweight alternative 166 to EAP for the purpose of PAKE protocols integration into IKEv2. The 167 framework models any PAKE protocol as a series of exchanges of opaque 168 data and defines a new IKEv2 payload called GSPM to carry this data 169 in the IKE_AUTH exchange. The number of these data exchanges depends 170 on the particular PAKE protocol and potentially is not limited, so 171 this framework makes the IKE_AUTH exchanges multi-round (as well as 172 in case of using EAP). The framework also defines how the use of 173 PAKE protocol is negotiated between peers in the IKE_SA_INIT 174 exchange. The framework however doesn't define how the AUTH payload 175 content is calculated in case of PAKE. SO, each PAKE protocol must 176 define the content of the GSPM payloads in each message and the way 177 the AUTH payload is calculated. Each PAKE protocol must also have a 178 unique identifier, registered by IANA in IKEv2 registry "IKEv2 Secure 179 Password Methods" [IKEv2-IANA], so that IKE is able to negotiate its 180 use. 182 RFC6467 has an "Experimental" status and, to the best of author's 183 knowledge, is not widely supported. It also complicates IKEv2 state 184 machine by making the IKE_AUTH exchange multi-round (note, that if 185 EAP is implemented in IKEv2, this complication must be already 186 there). Nevertheless it seems to be a primary way for integration 187 various PAKE protocols into IKEv2 and is RECOMMENDED to be used for 188 this purpose. Alternative approaches are discussed in Section 3.3. 190 3.2.1. Algorithm Agility 192 IKEv2 is able to negotiate usage of some cryptographic primitives, 193 such as (EC)DH group, PRF, encryption and integrity algorithms. Some 194 PAKE protocols are defined so that they can be used with different 195 cryptographic parameters. For the sake of algorithm agility it is 196 desirable when possible to use IKE-negotiated primitives in PAKE 197 protocols. Note, that IKEv2 doesn't negotiate some cryptographic 198 primitives that are widely used in PAKE protocols, such as hash 199 function, memory-hard function or KDF. In addition, negotiation of 200 MAC (integrity algorithm) can be omitted if AEAD algorithm is used in 201 IKEv2. Nevertheless, some of missing cryptographic primitives can be 202 constructed using those, that are negotiated in IKEv2 (e.g. use prf+ 203 construction defined in [RFC7296] as KDF, use AEAD with no encryption 204 as MAC in case no integrity algorithm is negotiated etc.). 206 We think the possibility to use as many of IKEv2 negotiated 207 primitives in PAKE protocols as possible should be considered, 208 however this may lead to the need to re-evaluate some of PAKE 209 protocols' security proof, especially if it highly depends on the 210 particular combination of used cryptographic primitives. In case of 211 augmented PAKEs an ability to use IKEv2 negotiation capabilities is 212 further restricted, because usually the group (and possibly some 213 other primitives) are fixed at the time the password verifier is 214 generated and cannot be changed at the time the protocol runs (unless 215 several password verifiers are generated for different primitives, 216 that is impractical). 218 Alternatively, it is possible to allocate several identifiers in the 219 "IKEv2 Secure Password Methods" registry for the same PAKE protocol 220 with different parameters. This approach is NOT RECOMMENDED, because 221 it increases the size of the IKE_SA_INIT request message, that may 222 lead to problems with IP fragmentation. 224 3.2.2. AUTH Payload Calculation 226 Note, that the way AUTH payload is computed in core IKEv2 227 specification ensures that all data exchanged between peers is 228 authenticated. So, when PAKE protocol redefines AUTH payload 229 calculation, it MAY take advantage of this fact and mot explicitly 230 include variables that are exchanged between peers, since they are 231 already implicitly included. Note also, that IKE SA always has a 232 unique session identifier (IKE SPIs) and IKE always include 233 identities of the peers in the IKE_AUTH exchange, so there is no need 234 to transfer them separately in PAKE protocol. 236 Note, that RFC6467 doesn't assume any change in IKEv2 key derivation 237 scheme, so that shared secrets generated by PAKE protocols are 238 assumed to be used only for the purpose of authentication and are not 239 included (either directly or indirectly) in calculation of SK_* keys 240 in IKEv2. 242 3.2.3. Possible PAKE Protocols Instantiation 244 Below are examples of how PAKE selection process candidates can be 245 instantiated with RFC6467 framework. Note, that these examples are 246 for illustrative purposes only, they need to be carefully examined 247 and may be reconsidered when the selection process is over. 249 3.2.3.1. SPAKE2 251 SPAKE2 is defined in [I-D.irtf-cfrg-spake2]. Possible instantiation 252 of SPAKE2 in IKEv2 is shown on Figure 1. 254 Initiator Responder 255 --------------------------------------------------------------------- 256 HDR, SK {IDi, [IDr,] GSPM(T), 257 SAi2, TSi, TSr} --> 258 <-- HDR, SK {IDr, GSPM(S)} 260 HDR, SK {AUTH} --> 261 <-- HDR, SK {AUTH, SAr2, TSi, TSr} 263 Figure 1: IKE_AUTH Exchange with SPAKE2 265 [I-D.irtf-cfrg-spake2] defines nine ciphersuites for SPAKE2 by 266 parameterizing the following cryptographic primitives: group, hash, 267 KDF, MAC and Memory-Hard hash Function (MHF). It is believed, that 268 some of these parameters may be directly borrowed from (or 269 constructed from) the IKEv2 negotiated cryptographic primitives. 270 Note also, that some parameters (e.g. KDF, MAC) are only used for 271 key derivation and confirmation, that in case of RFC6467 is done by 272 IKEv2 itself. 274 According to [I-D.irtf-cfrg-spake2] the result of a SPAKE2 protocol 275 run is a pair of shared secrets KcA and KcB that must be used in AUTH 276 payload computation for key confirmation. One of the possible ways 277 of doing this is shown in Figure 2. 279 AUTHi = prf( prf(KcA, "SPAKE2 for IKEv2"), ) 281 AUTHr = prf( prf(KcB, "SPAKE2 for IKEv2"), ) 283 Figure 2: AUTH Payload calculation in case of SPAKE2 285 We believe key derivation procedure for KcA and KcB defined in 286 [I-D.irtf-cfrg-spake2] may be optimized for the specific use in 287 IKEv2, however it's out of scope of this memo. 289 3.2.3.2. J-PAKE 291 J-PAKE is defined in [RFC8236]. Possible instantiation of J-PAKE in 292 IKEv2 is shown on Figure 3. 294 Initiator Responder 295 --------------------------------------------------------------------- 296 HDR, SK {IDi, [IDr,] 297 GSPM(G1), GSPM(G2), 298 GSPM(ZKP(x1), GSPM(ZKP(x2), 299 SAi2, TSi, TSr} --> 300 <-- HDR, SK {IDr, GSPM(G3), GSPM(G4), 301 GSPM(ZKP(x3), GSPM(ZKP(x4)} 303 HDR, SK {GSPM(A), GSPM(ZKP(x2*s)} --> 304 <-- HDR, SK {GSPM(B), GSPM(ZKP(x4*s)} 306 HDR, SK {AUTH} --> 307 <-- HDR, SK {AUTH, SAr2, TSi, TSr} 309 Figure 3: IKE_AUTH Exchange with J-PAKE 311 Note, that unlike other candidates J-PAKE requires two round trips 312 before shared secret is computed. 314 [RFC8236] allows using J-PAKE with different groups. It is believed 315 that the IKEv2 negotiated group can be used in case of J-PAKE. On 316 the other hand, J-PAKE uses a specific cryptographic primitive called 317 Zero Knowledge Proof (ZKP), for which Schnorr NIZK proof is used, and 318 it seems that it cannot be constructed from IKEv2 negotiated 319 primitives. Some other cryptographic primitives (H, MAC, KDF) are 320 only used for key derivation and confirmation, that in case of 321 RFC6467 is done by IKEv2 itself. 323 According to [RFC8236] the result of a J-PAKE protocol run is a 324 shared secret K that must be used in AUTH payload computation for key 325 confirmation. One of the possible ways of doing this is shown in 326 Figure 4. 328 AUTHi = prf( prf(K, "J-PAKE for IKEv2 Initiator"), 329 ) 331 AUTHr = prf( prf(K, "J-PAKE for IKEv2 Responder"), 332 ) 334 Figure 4: AUTH Payload calculation in case of J-PAKE 336 3.2.3.3. SPEKE 338 SPEKE is defined in [SPEKE]. Possible instantiation of SPEKE in 339 IKEv2 is shown on Figure 5. 341 Initiator Responder 342 --------------------------------------------------------------------- 343 HDR, SK {IDi, [IDr,] GSPM(g^x), 344 SAi2, TSi, TSr} --> 345 <-- HDR, SK {IDr, GSPM(g^y)} 347 HDR, SK {AUTH} --> 348 <-- HDR, SK {AUTH, SAr2, TSi, TSr} 350 Figure 5: IKE_AUTH Exchange with SPEKE 352 Although it seems that SPEKE can be used with different groups, 353 [SPEKE] describes using MODP groups only. It is not clear whether 354 IKEv2 negotiated group can generally be used in case of SPEKE. SPEKE 355 also uses hash function H for generating of key confirmation 356 messages, but we believe it is not necessary in case of RFC6467, 357 since key confirmation is done by IKEv2 itself. 359 According to [SPEKE] the result of a SPEKE protocol run is a shared 360 secret k that must be used in AUTH payload computation for key 361 confirmation. One of the possible ways of doing this is shown in 362 Figure 6. 364 AUTHi = prf( prf(k, "SPEKE for IKEv2 Initiator"), 365 ) 367 AUTHr = prf( prf(k, "SPEKE for IKEv2 Responder"), 368 ) 370 Figure 6: AUTH Payload calculation in case of SPEKE 372 3.2.3.4. CPace 374 CPace is defined in [CPace-AuCPace]. Possible instantiation of CPace 375 in IKEv2 is shown on Figure 7. 377 Initiator Responder 378 --------------------------------------------------------------------- 379 HDR, SK {IDi, [IDr,] GSPM(Ya), 380 SAi2, TSi, TSr} --> 381 <-- HDR, SK {IDr, GSPM(Yb)} 383 HDR, SK {AUTH} --> 384 <-- HDR, SK {AUTH, SAr2, TSi, TSr} 386 Figure 7: IKE_AUTH Exchange with CPace 388 CPace uses ssid (session identifier) and CI (connection identifier), 389 for which IKE SPIs can be used. 391 [CPace-AuCPace] specifies that CPace must only be used with 392 (hyper-)elliptic curves. It is not clear whether IKEv2 negotiated 393 group can generally be used in case of CPace. CPace also uses hash 394 function and memory-hard function primitives which are not negotiated 395 by IKEv2. 397 According to [CPace-AuCPace] the result of a CPace protocol run is a 398 shared secret sk1 that must be used in AUTH payload computation for 399 key confirmation. One of the possible ways of doing this is shown in 400 Figure 8. 402 AUTHi = prf( prf(sk1, "CPace for IKEv2 Initiator"), 403 ) 405 AUTHr = prf( prf(sk1, "CPace for IKEv2 Responder"), 406 ) 408 Figure 8: AUTH Payload calculation in case of CPace 410 3.2.3.5. OPAQUE 412 OPAQUE is defined in [I-D.krawczyk-cfrg-opaque]. Possible 413 instantiation of OPAQUE in IKEv2 is shown on Figure 9. 415 Initiator Responder 416 --------------------------------------------------------------------- 417 HDR, SK {IDi, [IDr,] GSPM(alpha), 418 SAi2, TSi, TSr} --> 419 <-- HDR, SK {IDr, GSPM(beta), 420 GSPM(EnvU), GSPM(vU)} 422 HDR, SK {AUTH} --> 423 <-- HDR, SK {AUTH, SAr2, TSi, TSr} 425 Figure 9: IKE_AUTH Exchange with OPAQUE 427 Unlike other PAKE candidates, the result of an OPAQUE protocol run is 428 a pair of private keys PrivU and PrivS (each known only to the 429 corresponding party), that must be used in AUTH payload computation 430 for key confirmation. One of the possible ways of doing this is 431 shown in Figure 10. 433 AUTHi = sig(PrivU, ) 435 AUTHr = sig(PrivS, ) 437 Figure 10: AUTH Payload calculation in case of OPAQUE 439 3.2.3.6. AuCPace 441 AuCPace is defined in [CPace-AuCPace]. Possible instantiation of 442 AuCPace in IKEv2 is shown on Figure 11. 444 Initiator Responder 445 --------------------------------------------------------------------- 446 HDR, SK {IDi, [IDr,] GSPM(), 447 SAi2, TSi, TSr} --> 448 <-- HDR, SK {IDr, GSPM(X), 449 GSPM(salt), GSPM(Ya)} 451 HDR, SK {GSPM(Yb), AUTH} --> 452 <-- HDR, SK {AUTH, SAr2, TSi, TSr} 454 Figure 11: IKE_AUTH Exchange with AuCPace 456 According to [CPace-AuCPace] the result of an AuCPace protocol run is 457 a shared secret sk1 that must be used in AUTH payload computation for 458 key confirmation. One of the possible ways of doing this is shown in 459 Figure 8. 461 AUTHi = prf( prf(sk1, "AuCPace for IKEv2 Initiator"), 462 ) 464 AUTHr = prf( prf(sk1, "AuCPace for IKEv2 Responder"), 465 ) 467 Figure 12: AUTH Payload calculation in case of AuCPace 469 3.2.3.7. VTBPEKE 471 VTBPEKE is defined in [VTBPEKE]. Possible instantiation of VTBPEKE 472 in IKEv2 is shown on Figure 13. 474 Initiator Responder 475 --------------------------------------------------------------------- 476 HDR, SK {IDi, [IDr,] GSPM(R'), 477 SAi2, TSi, TSr} --> 478 <-- HDR, SK {IDr, GSPM(salt), 479 GSPM(e), GSPM(Y)} 481 HDR, SK {GSPM(X), GSPM(r), 482 AUTH} --> 483 <-- HDR, SK {AUTH, SAr2, TSi, TSr} 485 Figure 13: IKE_AUTH Exchange with VTBPEKE 487 According to [VTBPEKE] the result of a VTBPERE protocol run is a 488 shared secret sk that must be used in AUTH payload computation for 489 key confirmation. One of the possible ways of doing this is shown in 490 Figure 14. 492 AUTHi = prf( prf(sk, "VTBPEKE for IKEv2 Initiator"), 493 ) 495 AUTHr = prf( prf(sk, "VTBPEKE for IKEv2 Responder"), 496 ) 498 Figure 14: AUTH Payload calculation in case of VTBPEKE 500 3.2.3.8. BSPAKE 502 BSPAKE is defined in [BSPAKE]. Possible instantiation of BSPAKE in 503 IKEv2 is shown on Figure 15. 505 Initiator Responder 506 --------------------------------------------------------------------- 507 HDR, SK {IDi, [IDr,] GSPM(R), 508 SAi2, TSi, TSr} --> 509 <-- HDR, SK {IDr, GSPM(B), GSPM(R')} 511 HDR, SK {GSPM(A), AUTH} --> 512 <-- HDR, SK {AUTH, SAr2, TSi, TSr} 514 Figure 15: IKE_AUTH Exchange with BSPAKE 516 According to [BSPAKE] the result of a BSPAKE protocol run is a shared 517 secret secretKey that must be used in AUTH payload computation for 518 key confirmation. One of the possible ways of doing this is shown in 519 Figure 16. 521 AUTHi = prf( prf(secretKey, "BSPAKE for IKEv2 Initiator"), 522 ) 524 AUTHr = prf( prf(secretKey, "BSPAKE for IKEv2 Responder"), 525 ) 527 Figure 16: AUTH Payload calculation in case of BSPAKE 529 3.3. Alternative Approaches 531 3.3.1. Using Secret Generator in IKE_SA_INIT 533 An alternative approach for using (at least some) PAKE protocols in 534 IKEv2 was suggested by Dan Harkins in [PAKE-ALT]. The idea is that 535 if peers share a secret generator (calculated from the password), 536 they can use it directly in (EC)DH computation performed in the 537 IKE_SA_INIT exchange. This approach has some advantages: 539 o requires little changes to IKEv2 (but see below) 541 o increases IKEv2 performance because only single (EC)DH operation 542 is needed (with RFC6467 framework all PAKE protocols discussed in 543 this memo require some group field operations in addition to 544 standard IKEv2 (EC)DH operation) 546 However, this approach has some limitations and drawbacks: 548 o initiator's identity need to be sent in the IKE_SA_INIT, that 549 require some change to the protocol 551 o identity protection is lost (at least for initiator); a method was 552 suggested to get identity protection in this case, but it requires 553 an additional round trip and in terms of complexity is no better 554 than RFC6467 approach 556 o a new authentication method is needed (probably NULL Auth 557 [RFC7619] will suffice) 559 o algorithm agility is limited (since password is tied to a 560 particular group, to change the group peers need to re-share 561 secret generator out of band) 563 o the approach is applicable only to specific PAKEs which have 564 static secret generator computed from the password (among the 565 candidates only SPEKE satisfies this requirement) 567 All these considerations make using this approach problematic in 568 general, however in some specific cases (no need for identity 569 protection, no need for algorithm agility etc.) it can be attractive. 571 3.3.2. Using IKE_INTERMEDIATE Exchange 573 It is possible to make use of the IKE_INTERMEDIATE exchange 574 [I-D.ietf-ipsecme-ikev2-intermediate] for the purpose of transferring 575 PAKE's messages. This approach would be similar to using RFC6467 576 framework, except that RFC6467 has "Experimental" status and is not 577 widely supported, while IKE_INTERMEDIATE framework will probably have 578 wider adoption (mostly for the purposes of Post-Quantum Key 579 Exchange). 581 On the other hand, using IKE_INTERMEDIATE exchange for PAKE protocols 582 yet has been to be defined. 584 4. Conclusions 586 IKEv2 proved to be a flexible protocol that can accommodate various 587 extensions. This memo discusses several ways of integration PAKE 588 protocols into IKEv2, making focus on using RFC6467 framework. It is 589 shown that there should be no problems integrating any of the 590 candidate PAKE protocols. Some alternative approaches are also 591 discussed. 593 5. Security Considerations 595 Discussion the security of CFRG PAKE candidates is out of scope of 596 this document. This memo only discusses how each of the candidates 597 can be integrated into IKEv2. Moreover, the details of this 598 integration (in particular how the content of AUTH payload is 599 calculated so that key confirmation is properly achieved) is only 600 sketched and need to be carefully re-examined when concrete PAKEs are 601 selected. 603 6. References 605 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 606 Requirement Levels", BCP 14, RFC 2119, 607 DOI 10.17487/RFC2119, March 1997, 608 . 610 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 611 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 612 May 2017, . 614 [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. 615 Kivinen, "Internet Key Exchange Protocol Version 2 616 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 617 2014, . 619 [RFC5998] Eronen, P., Tschofenig, H., and Y. Sheffer, "An Extension 620 for EAP-Only Authentication in IKEv2", RFC 5998, 621 DOI 10.17487/RFC5998, September 2010, 622 . 624 [RFC6467] Kivinen, T., "Secure Password Framework for Internet Key 625 Exchange Version 2 (IKEv2)", RFC 6467, 626 DOI 10.17487/RFC6467, December 2011, 627 . 629 [RFC6617] Harkins, D., "Secure Pre-Shared Key (PSK) Authentication 630 for the Internet Key Exchange Protocol (IKE)", RFC 6617, 631 DOI 10.17487/RFC6617, June 2012, 632 . 634 [RFC6628] Shin, S. and K. Kobara, "Efficient Augmented Password-Only 635 Authentication and Key Exchange for IKEv2", RFC 6628, 636 DOI 10.17487/RFC6628, June 2012, 637 . 639 [RFC6631] Kuegler, D. and Y. Sheffer, "Password Authenticated 640 Connection Establishment with the Internet Key Exchange 641 Protocol version 2 (IKEv2)", RFC 6631, 642 DOI 10.17487/RFC6631, June 2012, 643 . 645 [RFC8236] Hao, F., Ed., "J-PAKE: Password-Authenticated Key Exchange 646 by Juggling", RFC 8236, DOI 10.17487/RFC8236, September 647 2017, . 649 [I-D.irtf-cfrg-spake2] 650 Ladd, W. and B. Kaduk, "SPAKE2, a PAKE", draft-irtf-cfrg- 651 spake2-08 (work in progress), March 2019. 653 [I-D.krawczyk-cfrg-opaque] 654 Krawczyk, H., "The OPAQUE Asymmetric PAKE Protocol", 655 draft-krawczyk-cfrg-opaque-02 (work in progress), July 656 2019. 658 [SPEKE] Hao, F. and S. F. Shahandashti, "The SPEKE Protocol 659 Revisited", 2014, . 661 [CPace-AuCPace] 662 Haase, B. and B. Labrique, "AuCPace: Efficient verifier- 663 based PAKE protocol tailored for the IIoT", 2019, 664 . 666 [VTBPEKE] Pointcheval, D. and G. Wang, "VTBPEKE: Verifier-based Two- 667 Basis Password Exponential Key Exchange", 2017, 668 . 671 [BSPAKE] "BSPAKE", . 674 [IKEv2-IANA] 675 "Internet Key Exchange Version 2 (IKEv2) Parameters", 676 . 678 [EAP-IANA] 679 "Extensible Authentication Protocol (EAP) Registry", 680 . 683 [PAKE-ALT] 684 , . 687 [RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication 688 Method in the Internet Key Exchange Protocol Version 2 689 (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015, 690 . 692 [I-D.ietf-ipsecme-ikev2-intermediate] 693 Smyslov, V., "Intermediate Exchange in the IKEv2 694 Protocol", draft-ietf-ipsecme-ikev2-intermediate-02 (work 695 in progress), July 2019. 697 Author's Address 699 Valery Smyslov 700 ELVIS-PLUS 702 Email: svan@elvis.ru