Network Working Group V. Smyslov Internet-Draft ELVIS-PLUS Intended status: Informational September 9, 2019 Expires: March 12, 2020 Usage of PAKE Protocols with IKEv2 draft-smyslov-ikev2-pake-00 Abstract This memo discusses how PAKE (Password Authenticated Key Exchange) protocols can be integrated into the IKEv2 (Internet Key Exchange) protocol. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on March 12, 2020. Copyright Notice Copyright (c) 2019 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 (https://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. Smyslov Expires March 12, 2020 [Page 1] Internet-Draft PAKE in IKEv2 September 2019 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology and Notation . . . . . . . . . . . . . . . . . . 3 3. Integrating PAKE protocols into IKEv2 . . . . . . . . . . . . 3 3.1. Using EAP methods . . . . . . . . . . . . . . . . . . . . 3 3.2. Using RFC6467 framework . . . . . . . . . . . . . . . . . 4 3.2.1. Algorithm Agility . . . . . . . . . . . . . . . . . . 5 3.2.2. AUTH Payload Calculation . . . . . . . . . . . . . . 5 3.2.3. Possible PAKE Protocols Instantiation . . . . . . . . 6 3.3. Alternative Approaches . . . . . . . . . . . . . . . . . 12 3.3.1. Using Secret Generator in IKE_SA_INIT . . . . . . . . 12 3.3.2. Using IKE_INTERMEDIATE Exchange . . . . . . . . . . . 13 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction Recent interest in PAKE protocols in IETF resulted in launching the PAKE selection process in CFRG. The goal of the process is to select one (or more, or zero) PAKE protocol(s) that will be recommended to be used in IETF security protocols, such as TLS 1.3, IKEv2 etc. There are eight candidates nominated: four balanced PAKEs (SPAKE2 [I-D.irtf-cfrg-spake2], J-PAKE [RFC8236], SPERE [SPEKE] and CPace [CPace-AuCPace]) and four augmented ones (OPAQUE [I-D.krawczyk-cfrg-opaque], AuCPace [CPace-AuCPace], VTBPEKE [VTBPEKE] and BSPAKE [BSPAKE]). The part of the selection process is an evaluation of how well the candidates can be fit into existing IETF security protocols. This memo aims to discuss how each of the candidates can be integrated into IKEv2. The IKEv2 protocol defined in [RFC7296] is a key part of IPsec (IP Security) architecture, as it provides an authenticated key exchange between peers who wish to establish an IPsec SA (Security Association). Core IKEv2 specification allows peers to authenticate each other either by using PSK (Pre-Shared Key) or by means of digital signatures. In addition, the core IKEv2 specification allows optional use of EAP (Extensible Authentication Protocol) in the protocol. Note, that the way EAP was originally integrated into IKEv2 still required using digital signatures by responder. However, later an extension for the IKEv2 was developed, which allowed using EAP-only authentication [RFC5998]. Smyslov Expires March 12, 2020 [Page 2] Internet-Draft PAKE in IKEv2 September 2019 2. Terminology and Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Integrating PAKE protocols into IKEv2 Authentication by means of PAKE protocols in IKEv2 is of high interest in IPSECME WG. Both balanced and augmented PAKEs can be employed - the former are suitable for peer to peer communication, when each side can initiate, while the latter are good for remote access scenarios. Note, that for augmented PAKE protocols a password setup step is needed, during which password verifier is generated and transferred to server. This step is out of scope of this memo, we assume that all the setup steps are already somehow done. Early attempts to integrate PAKE protocols into IKEv2 were made in IPSECME WG around 2009-2011. The easiest way to do it would be to define new EAP methods based on PAKE protocols and to rely on build- in EAP authentication (along with "EAP-only" extension). However, the disadvantage of this approach is its inefficiency and complexity. As a result, the WG developed a new experimental IKEv2 extension, that aimed to provide a framework for integration of any PAKE protocol into IKEv2 [RFC6467]. This extension generalizes any PAKE protocol as a series of message exchanges resulted in the computing of a shared secret. The extension defines how use of a particular PAKE is negotiated and how PAKE messages are transferred in multi- round IKE_AUTH exchange. Several PAKE protocols were then instantiated using this extension: "Dragonfly" [RFC6617], AugPAKE [RFC6628] and PACE [RFC6631]. 3.1. Using EAP methods Integration of PAKE protocols into IKEv2 using EAP methods is the simplest possible way from protocol point of view, because it requires no modification to the IKEv2 (provided EAP is already supported and "EAP-only" extension to IKEv2 is implemented). However, this approach has the following drawbacks. o Lack of flexibility. Using EAP is not negotiated in IKEv2, it's done on initiator's discretion. It's better to have ability to negotiate using PAKE or convenient authentication. Smyslov Expires March 12, 2020 [Page 3] Internet-Draft PAKE in IKEv2 September 2019 o Duplicated functionality. If some PAKE EAP methods are available (or a single method with different parameters) it is EAP that would negotiate using a particular one. IKEv2 has its own negotiation mechanism that's better to be used instead. In addition, EAP methods would have use their own variables, like session id, peers identities etc. These variables are available in IKEv2 and it's better to use them instead. o Inefficiency. EAP methods for PAKE protocols would have included a key confirmation step that would have required an additional round trip and some computations. This step is not needed in case of IKEv2, since IKEv2 will do this step itself anyway. o Complexity. EAP adds an additional layer of encapsulation, that is not always needed. For these reasons integration of PAKE protocols into IKEv2 using EAP methods is NOT RECOMMENDED. Note, that currently from the eight PAKE candidates listed in Section 1, only for SPEKE a ready to use EAP method is defined (see [EAP-IANA]. EAP methods for other PAKE candidates are not yet defined. 3.2. Using RFC6467 framework This framework was specifically designed as a lightweight alternative to EAP for the purpose of PAKE protocols integration into IKEv2. The framework models any PAKE protocol as a series of exchanges of opaque data and defines a new IKEv2 payload called GSPM to carry this data in the IKE_AUTH exchange. The number of these data exchanges depends on the particular PAKE protocol and potentially is not limited, so this framework makes the IKE_AUTH exchanges multi-round (as well as in case of using EAP). The framework also defines how the use of PAKE protocol is negotiated between peers in the IKE_SA_INIT exchange. The framework however doesn't define how the AUTH payload content is calculated in case of PAKE. SO, each PAKE protocol must define the content of the GSPM payloads in each message and the way the AUTH payload is calculated. Each PAKE protocol must also have a unique identifier, registered by IANA in IKEv2 registry "IKEv2 Secure Password Methods" [IKEv2-IANA], so that IKE is able to negotiate its use. RFC6467 has an "Experimental" status and, to the best of author's knowledge, is not widely supported. It also complicates IKEv2 state machine by making the IKE_AUTH exchange multi-round (note, that if EAP is implemented in IKEv2, this complication must be already there). Nevertheless it seems to be a primary way for integration various PAKE protocols into IKEv2 and is RECOMMENDED to be used for this purpose. Alternative approaches are discussed in Section 3.3. Smyslov Expires March 12, 2020 [Page 4] Internet-Draft PAKE in IKEv2 September 2019 3.2.1. Algorithm Agility IKEv2 is able to negotiate usage of some cryptographic primitives, such as (EC)DH group, PRF, encryption and integrity algorithms. Some PAKE protocols are defined so that they can be used with different cryptographic parameters. For the sake of algorithm agility it is desirable when possible to use IKE-negotiated primitives in PAKE protocols. Note, that IKEv2 doesn't negotiate some cryptographic primitives that are widely used in PAKE protocols, such as hash function, memory-hard function or KDF. In addition, negotiation of MAC (integrity algorithm) can be omitted if AEAD algorithm is used in IKEv2. Nevertheless, some of missing cryptographic primitives can be constructed using those, that are negotiated in IKEv2 (e.g. use prf+ construction defined in [RFC7296] as KDF, use AEAD with no encryption as MAC in case no integrity algorithm is negotiated etc.). We think the possibility to use as many of IKEv2 negotiated primitives in PAKE protocols as possible should be considered, however this may lead to the need to re-evaluate some of PAKE protocols' security proof, especially if it highly depends on the particular combination of used cryptographic primitives. In case of augmented PAKEs an ability to use IKEv2 negotiation capabilities is further restricted, because usually the group (and possibly some other primitives) are fixed at the time the password verifier is generated and cannot be changed at the time the protocol runs (unless several password verifiers are generated for different primitives, that is impractical). Alternatively, it is possible to allocate several identifiers in the "IKEv2 Secure Password Methods" registry for the same PAKE protocol with different parameters. This approach is NOT RECOMMENDED, because it increases the size of the IKE_SA_INIT request message, that may lead to problems with IP fragmentation. 3.2.2. AUTH Payload Calculation Note, that the way AUTH payload is computed in core IKEv2 specification ensures that all data exchanged between peers is authenticated. So, when PAKE protocol redefines AUTH payload calculation, it MAY take advantage of this fact and mot explicitly include variables that are exchanged between peers, since they are already implicitly included. Note also, that IKE SA always has a unique session identifier (IKE SPIs) and IKE always include identities of the peers in the IKE_AUTH exchange, so there is no need to transfer them separately in PAKE protocol. Note, that RFC6467 doesn't assume any change in IKEv2 key derivation scheme, so that shared secrets generated by PAKE protocols are Smyslov Expires March 12, 2020 [Page 5] Internet-Draft PAKE in IKEv2 September 2019 assumed to be used only for the purpose of authentication and are not included (either directly or indirectly) in calculation of SK_* keys in IKEv2. 3.2.3. Possible PAKE Protocols Instantiation Below are examples of how PAKE selection process candidates can be instantiated with RFC6467 framework. Note, that these examples are for illustrative purposes only, they need to be carefully examined and may be reconsidered when the selection process is over. 3.2.3.1. SPAKE2 SPAKE2 is defined in [I-D.irtf-cfrg-spake2]. Possible instantiation of SPAKE2 in IKEv2 is shown on Figure 1. Initiator Responder --------------------------------------------------------------------- HDR, SK {IDi, [IDr,] GSPM(T), SAi2, TSi, TSr} --> <-- HDR, SK {IDr, GSPM(S)} HDR, SK {AUTH} --> <-- HDR, SK {AUTH, SAr2, TSi, TSr} Figure 1: IKE_AUTH Exchange with SPAKE2 [I-D.irtf-cfrg-spake2] defines nine ciphersuites for SPAKE2 by parameterizing the following cryptographic primitives: group, hash, KDF, MAC and Memory-Hard hash Function (MHF). It is believed, that some of these parameters may be directly borrowed from (or constructed from) the IKEv2 negotiated cryptographic primitives. Note also, that some parameters (e.g. KDF, MAC) are only used for key derivation and confirmation, that in case of RFC6467 is done by IKEv2 itself. According to [I-D.irtf-cfrg-spake2] the result of a SPAKE2 protocol run is a pair of shared secrets KcA and KcB that must be used in AUTH payload computation for key confirmation. One of the possible ways of doing this is shown in Figure 2. AUTHi = prf( prf(KcA, "SPAKE2 for IKEv2"), ) AUTHr = prf( prf(KcB, "SPAKE2 for IKEv2"), ) Figure 2: AUTH Payload calculation in case of SPAKE2 Smyslov Expires March 12, 2020 [Page 6] Internet-Draft PAKE in IKEv2 September 2019 We believe key derivation procedure for KcA and KcB defined in [I-D.irtf-cfrg-spake2] may be optimized for the specific use in IKEv2, however it's out of scope of this memo. 3.2.3.2. J-PAKE J-PAKE is defined in [RFC8236]. Possible instantiation of J-PAKE in IKEv2 is shown on Figure 3. Initiator Responder --------------------------------------------------------------------- HDR, SK {IDi, [IDr,] GSPM(G1), GSPM(G2), GSPM(ZKP(x1), GSPM(ZKP(x2), SAi2, TSi, TSr} --> <-- HDR, SK {IDr, GSPM(G3), GSPM(G4), GSPM(ZKP(x3), GSPM(ZKP(x4)} HDR, SK {GSPM(A), GSPM(ZKP(x2*s)} --> <-- HDR, SK {GSPM(B), GSPM(ZKP(x4*s)} HDR, SK {AUTH} --> <-- HDR, SK {AUTH, SAr2, TSi, TSr} Figure 3: IKE_AUTH Exchange with J-PAKE Note, that unlike other candidates J-PAKE requires two round trips before shared secret is computed. [RFC8236] allows using J-PAKE with different groups. It is believed that the IKEv2 negotiated group can be used in case of J-PAKE. On the other hand, J-PAKE uses a specific cryptographic primitive called Zero Knowledge Proof (ZKP), for which Schnorr NIZK proof is used, and it seems that it cannot be constructed from IKEv2 negotiated primitives. Some other cryptographic primitives (H, MAC, KDF) are only used for key derivation and confirmation, that in case of RFC6467 is done by IKEv2 itself. According to [RFC8236] the result of a J-PAKE protocol run is a shared secret K that must be used in AUTH payload computation for key confirmation. One of the possible ways of doing this is shown in Figure 4. Smyslov Expires March 12, 2020 [Page 7] Internet-Draft PAKE in IKEv2 September 2019 AUTHi = prf( prf(K, "J-PAKE for IKEv2 Initiator"), ) AUTHr = prf( prf(K, "J-PAKE for IKEv2 Responder"), ) Figure 4: AUTH Payload calculation in case of J-PAKE 3.2.3.3. SPEKE SPEKE is defined in [SPEKE]. Possible instantiation of SPEKE in IKEv2 is shown on Figure 5. Initiator Responder --------------------------------------------------------------------- HDR, SK {IDi, [IDr,] GSPM(g^x), SAi2, TSi, TSr} --> <-- HDR, SK {IDr, GSPM(g^y)} HDR, SK {AUTH} --> <-- HDR, SK {AUTH, SAr2, TSi, TSr} Figure 5: IKE_AUTH Exchange with SPEKE Although it seems that SPEKE can be used with different groups, [SPEKE] describes using MODP groups only. It is not clear whether IKEv2 negotiated group can generally be used in case of SPEKE. SPEKE also uses hash function H for generating of key confirmation messages, but we believe it is not necessary in case of RFC6467, since key confirmation is done by IKEv2 itself. According to [SPEKE] the result of a SPEKE protocol run is a shared secret k that must be used in AUTH payload computation for key confirmation. One of the possible ways of doing this is shown in Figure 6. AUTHi = prf( prf(k, "SPEKE for IKEv2 Initiator"), ) AUTHr = prf( prf(k, "SPEKE for IKEv2 Responder"), ) Figure 6: AUTH Payload calculation in case of SPEKE Smyslov Expires March 12, 2020 [Page 8] Internet-Draft PAKE in IKEv2 September 2019 3.2.3.4. CPace CPace is defined in [CPace-AuCPace]. Possible instantiation of CPace in IKEv2 is shown on Figure 7. Initiator Responder --------------------------------------------------------------------- HDR, SK {IDi, [IDr,] GSPM(Ya), SAi2, TSi, TSr} --> <-- HDR, SK {IDr, GSPM(Yb)} HDR, SK {AUTH} --> <-- HDR, SK {AUTH, SAr2, TSi, TSr} Figure 7: IKE_AUTH Exchange with CPace CPace uses ssid (session identifier) and CI (connection identifier), for which IKE SPIs can be used. [CPace-AuCPace] specifies that CPace must only be used with (hyper-)elliptic curves. It is not clear whether IKEv2 negotiated group can generally be used in case of CPace. CPace also uses hash function and memory-hard function primitives which are not negotiated by IKEv2. According to [CPace-AuCPace] the result of a CPace protocol run is a shared secret sk1 that must be used in AUTH payload computation for key confirmation. One of the possible ways of doing this is shown in Figure 8. AUTHi = prf( prf(sk1, "CPace for IKEv2 Initiator"), ) AUTHr = prf( prf(sk1, "CPace for IKEv2 Responder"), ) Figure 8: AUTH Payload calculation in case of CPace 3.2.3.5. OPAQUE OPAQUE is defined in [I-D.krawczyk-cfrg-opaque]. Possible instantiation of OPAQUE in IKEv2 is shown on Figure 9. Smyslov Expires March 12, 2020 [Page 9] Internet-Draft PAKE in IKEv2 September 2019 Initiator Responder --------------------------------------------------------------------- HDR, SK {IDi, [IDr,] GSPM(alpha), SAi2, TSi, TSr} --> <-- HDR, SK {IDr, GSPM(beta), GSPM(EnvU), GSPM(vU)} HDR, SK {AUTH} --> <-- HDR, SK {AUTH, SAr2, TSi, TSr} Figure 9: IKE_AUTH Exchange with OPAQUE Unlike other PAKE candidates, the result of an OPAQUE protocol run is a pair of private keys PrivU and PrivS (each known only to the corresponding party), that must be used in AUTH payload computation for key confirmation. One of the possible ways of doing this is shown in Figure 10. AUTHi = sig(PrivU, ) AUTHr = sig(PrivS, ) Figure 10: AUTH Payload calculation in case of OPAQUE 3.2.3.6. AuCPace AuCPace is defined in [CPace-AuCPace]. Possible instantiation of AuCPace in IKEv2 is shown on Figure 11. Initiator Responder --------------------------------------------------------------------- HDR, SK {IDi, [IDr,] GSPM(), SAi2, TSi, TSr} --> <-- HDR, SK {IDr, GSPM(X), GSPM(salt), GSPM(Ya)} HDR, SK {GSPM(Yb), AUTH} --> <-- HDR, SK {AUTH, SAr2, TSi, TSr} Figure 11: IKE_AUTH Exchange with AuCPace According to [CPace-AuCPace] the result of an AuCPace protocol run is a shared secret sk1 that must be used in AUTH payload computation for key confirmation. One of the possible ways of doing this is shown in Figure 8. Smyslov Expires March 12, 2020 [Page 10] Internet-Draft PAKE in IKEv2 September 2019 AUTHi = prf( prf(sk1, "AuCPace for IKEv2 Initiator"), ) AUTHr = prf( prf(sk1, "AuCPace for IKEv2 Responder"), ) Figure 12: AUTH Payload calculation in case of AuCPace 3.2.3.7. VTBPEKE VTBPEKE is defined in [VTBPEKE]. Possible instantiation of VTBPEKE in IKEv2 is shown on Figure 13. Initiator Responder --------------------------------------------------------------------- HDR, SK {IDi, [IDr,] GSPM(R'), SAi2, TSi, TSr} --> <-- HDR, SK {IDr, GSPM(salt), GSPM(e), GSPM(Y)} HDR, SK {GSPM(X), GSPM(r), AUTH} --> <-- HDR, SK {AUTH, SAr2, TSi, TSr} Figure 13: IKE_AUTH Exchange with VTBPEKE According to [VTBPEKE] the result of a VTBPERE protocol run is a shared secret sk that must be used in AUTH payload computation for key confirmation. One of the possible ways of doing this is shown in Figure 14. AUTHi = prf( prf(sk, "VTBPEKE for IKEv2 Initiator"), ) AUTHr = prf( prf(sk, "VTBPEKE for IKEv2 Responder"), ) Figure 14: AUTH Payload calculation in case of VTBPEKE 3.2.3.8. BSPAKE BSPAKE is defined in [BSPAKE]. Possible instantiation of BSPAKE in IKEv2 is shown on Figure 15. Smyslov Expires March 12, 2020 [Page 11] Internet-Draft PAKE in IKEv2 September 2019 Initiator Responder --------------------------------------------------------------------- HDR, SK {IDi, [IDr,] GSPM(R), SAi2, TSi, TSr} --> <-- HDR, SK {IDr, GSPM(B), GSPM(R')} HDR, SK {GSPM(A), AUTH} --> <-- HDR, SK {AUTH, SAr2, TSi, TSr} Figure 15: IKE_AUTH Exchange with BSPAKE According to [BSPAKE] the result of a BSPAKE protocol run is a shared secret secretKey that must be used in AUTH payload computation for key confirmation. One of the possible ways of doing this is shown in Figure 16. AUTHi = prf( prf(secretKey, "BSPAKE for IKEv2 Initiator"), ) AUTHr = prf( prf(secretKey, "BSPAKE for IKEv2 Responder"), ) Figure 16: AUTH Payload calculation in case of BSPAKE 3.3. Alternative Approaches 3.3.1. Using Secret Generator in IKE_SA_INIT An alternative approach for using (at least some) PAKE protocols in IKEv2 was suggested by Dan Harkins in [PAKE-ALT]. The idea is that if peers share a secret generator (calculated from the password), they can use it directly in (EC)DH computation performed in the IKE_SA_INIT exchange. This approach has some advantages: o requires little changes to IKEv2 (but see below) o increases IKEv2 performance because only single (EC)DH operation is needed (with RFC6467 framework all PAKE protocols discussed in this memo require some group field operations in addition to standard IKEv2 (EC)DH operation) However, this approach has some limitations and drawbacks: o initiator's identity need to be sent in the IKE_SA_INIT, that require some change to the protocol o identity protection is lost (at least for initiator); a method was suggested to get identity protection in this case, but it requires Smyslov Expires March 12, 2020 [Page 12] Internet-Draft PAKE in IKEv2 September 2019 an additional round trip and in terms of complexity is no better than RFC6467 approach o a new authentication method is needed (probably NULL Auth [RFC7619] will suffice) o algorithm agility is limited (since password is tied to a particular group, to change the group peers need to re-share secret generator out of band) o the approach is applicable only to specific PAKEs which have static secret generator computed from the password (among the candidates only SPEKE satisfies this requirement) All these considerations make using this approach problematic in general, however in some specific cases (no need for identity protection, no need for algorithm agility etc.) it can be attractive. 3.3.2. Using IKE_INTERMEDIATE Exchange It is possible to make use of the IKE_INTERMEDIATE exchange [I-D.ietf-ipsecme-ikev2-intermediate] for the purpose of transferring PAKE's messages. This approach would be similar to using RFC6467 framework, except that RFC6467 has "Experimental" status and is not widely supported, while IKE_INTERMEDIATE framework will probably have wider adoption (mostly for the purposes of Post-Quantum Key Exchange). On the other hand, using IKE_INTERMEDIATE exchange for PAKE protocols yet has been to be defined. 4. Conclusions IKEv2 proved to be a flexible protocol that can accommodate various extensions. This memo discusses several ways of integration PAKE protocols into IKEv2, making focus on using RFC6467 framework. It is shown that there should be no problems integrating any of the candidate PAKE protocols. Some alternative approaches are also discussed. 5. Security Considerations Discussion the security of CFRG PAKE candidates is out of scope of this document. This memo only discusses how each of the candidates can be integrated into IKEv2. Moreover, the details of this integration (in particular how the content of AUTH payload is calculated so that key confirmation is properly achieved) is only Smyslov Expires March 12, 2020 [Page 13] Internet-Draft PAKE in IKEv2 September 2019 sketched and need to be carefully re-examined when concrete PAKEs are selected. 6. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October 2014, . [RFC5998] Eronen, P., Tschofenig, H., and Y. Sheffer, "An Extension for EAP-Only Authentication in IKEv2", RFC 5998, DOI 10.17487/RFC5998, September 2010, . [RFC6467] Kivinen, T., "Secure Password Framework for Internet Key Exchange Version 2 (IKEv2)", RFC 6467, DOI 10.17487/RFC6467, December 2011, . [RFC6617] Harkins, D., "Secure Pre-Shared Key (PSK) Authentication for the Internet Key Exchange Protocol (IKE)", RFC 6617, DOI 10.17487/RFC6617, June 2012, . [RFC6628] Shin, S. and K. Kobara, "Efficient Augmented Password-Only Authentication and Key Exchange for IKEv2", RFC 6628, DOI 10.17487/RFC6628, June 2012, . [RFC6631] Kuegler, D. and Y. Sheffer, "Password Authenticated Connection Establishment with the Internet Key Exchange Protocol version 2 (IKEv2)", RFC 6631, DOI 10.17487/RFC6631, June 2012, . [RFC8236] Hao, F., Ed., "J-PAKE: Password-Authenticated Key Exchange by Juggling", RFC 8236, DOI 10.17487/RFC8236, September 2017, . Smyslov Expires March 12, 2020 [Page 14] Internet-Draft PAKE in IKEv2 September 2019 [I-D.irtf-cfrg-spake2] Ladd, W. and B. Kaduk, "SPAKE2, a PAKE", draft-irtf-cfrg- spake2-08 (work in progress), March 2019. [I-D.krawczyk-cfrg-opaque] Krawczyk, H., "The OPAQUE Asymmetric PAKE Protocol", draft-krawczyk-cfrg-opaque-02 (work in progress), July 2019. [SPEKE] Hao, F. and S. F. Shahandashti, "The SPEKE Protocol Revisited", 2014, . [CPace-AuCPace] Haase, B. and B. Labrique, "AuCPace: Efficient verifier- based PAKE protocol tailored for the IIoT", 2019, . [VTBPEKE] Pointcheval, D. and G. Wang, "VTBPEKE: Verifier-based Two- Basis Password Exponential Key Exchange", 2017, . [BSPAKE] "BSPAKE", . [IKEv2-IANA] "Internet Key Exchange Version 2 (IKEv2) Parameters", . [EAP-IANA] "Extensible Authentication Protocol (EAP) Registry", . [PAKE-ALT] , . [RFC7619] Smyslov, V. and P. Wouters, "The NULL Authentication Method in the Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 7619, DOI 10.17487/RFC7619, August 2015, . [I-D.ietf-ipsecme-ikev2-intermediate] Smyslov, V., "Intermediate Exchange in the IKEv2 Protocol", draft-ietf-ipsecme-ikev2-intermediate-02 (work in progress), July 2019. Smyslov Expires March 12, 2020 [Page 15] Internet-Draft PAKE in IKEv2 September 2019 Author's Address Valery Smyslov ELVIS-PLUS Email: svan@elvis.ru Smyslov Expires March 12, 2020 [Page 16]