--- 1/draft-ietf-ipsecme-ikev2-multiple-ke-02.txt 2021-07-06 11:13:09.746138300 -0700 +++ 2/draft-ietf-ipsecme-ikev2-multiple-ke-03.txt 2021-07-06 11:13:09.798139596 -0700 @@ -1,28 +1,28 @@ Internet Engineering Task Force (IETF) C. Tjhai Internet-Draft M. Tomlinson Updates: 7296 (if approved) Post-Quantum Intended status: Standards Track G. Bartlett -Expires: July 14, 2021 Quantum Secret +Expires: January 7, 2022 Quantum Secret S. Fluhrer Cisco Systems D. Van Geest ISARA Corporation O. Garcia-Morchon Philips V. Smyslov ELVIS-PLUS - January 10, 2021 + July 6, 2021 Multiple Key Exchanges in IKEv2 - draft-ietf-ipsecme-ikev2-multiple-ke-02 + draft-ietf-ipsecme-ikev2-multiple-ke-03 Abstract This document describes how to extend the Internet Key Exchange Protocol Version 2 (IKEv2) to allow multiple key exchanges to take place while computing a shared secret during a Security Association (SA) setup. The primary application of this feature in IKEv2 is the ability to perform one or more post-quantum key exchanges in conjunction with the classical (Elliptic Curve) Diffie-Hellman key exchange, so that the resulting shared key is resistant against @@ -47,21 +47,21 @@ 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 July 14, 2021. + This Internet-Draft will expire on January 7, 2022. Copyright Notice Copyright (c) 2021 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 @@ -76,26 +76,26 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Problem Description . . . . . . . . . . . . . . . . . . . 3 1.2. Proposed Extension . . . . . . . . . . . . . . . . . . . 3 1.3. Changes . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4. Document Organization . . . . . . . . . . . . . . . . . . 6 2. Design Criteria . . . . . . . . . . . . . . . . . . . . . . . 6 3. Multiple Key Exchanges . . . . . . . . . . . . . . . . . . . 8 3.1. Overall Design . . . . . . . . . . . . . . . . . . . . . 8 3.2. Overall Protocol . . . . . . . . . . . . . . . . . . . . 10 3.2.1. IKE_SA_INIT Round: Negotiation . . . . . . . . . . . 10 - 3.2.2. IKE_INTERMEDIATE Round: Additional Key Exchanges . . 11 - 3.2.3. IKE_AUTH Exchange . . . . . . . . . . . . . . . . . . 12 - 3.2.4. CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 12 + 3.2.2. IKE_INTERMEDIATE Round: Additional Key Exchanges . . 12 + 3.2.3. IKE_AUTH Exchange . . . . . . . . . . . . . . . . . . 13 + 3.2.4. CREATE_CHILD_SA Exchange . . . . . . . . . . . . . . 13 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 - 5. Security Considerations . . . . . . . . . . . . . . . . . . . 16 - 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.1. Normative References . . . . . . . . . . . . . . . . . . 18 7.2. Informative References . . . . . . . . . . . . . . . . . 18 Appendix A. Alternative Design . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction 1.1. Problem Description @@ -138,31 +138,32 @@ Authentication Header (AH) [RFC4302], i.e. Child SAs, in order to provide a stronger guarantee of forward security. Some post-quantum key exchange payloads may have sizes larger than the standard maximum transmission unit (MTU) size, and therefore there could be issues with fragmentation at the IP layer. IKE does allow transmission over TCP where fragmentation is not an issue [RFC8229]; however, we believe that a UDP-based solution will be required too. IKE does have a mechanism to handle fragmentation within UDP [RFC7383], however that is only applicable to messages - exchanged after the IKE_SA_INIT. To use this mechanism, this - specification relies on the IKE_INTERMEDIATE exchange as outlined in - [I-D.ietf-ipsecme-ikev2-intermediate]. With this mechanism, we do an - initial key exchange, using a smaller, possibly non-quantum resistant - primitive, such as ECDH. Then, before we do the IKE_AUTH exchange, - we perform one or more IKE_INTERMEDIATE exchanges, each of which - contains an additional key exchange. As the IKE_INTERMEDIATE - exchange is encrypted, the IKE fragmentation protocol [RFC7383] can - be used. The IKE SK_* values are updated after each exchange, and so - the final IKE SA keys depend on all the key exchanges, hence they are - secure if any of the key exchanges are secure. + exchanged after the IKE_SA_INIT exchange. To use this mechanism, + this specification relies on the IKE_INTERMEDIATE exchange as + outlined in [I-D.ietf-ipsecme-ikev2-intermediate]. With this + mechanism, we do an initial key exchange, using a smaller, possibly + non-quantum resistant primitive, such as ECDH. Then, before we do + the IKE_AUTH exchange, we perform one or more IKE_INTERMEDIATE + exchanges, each of which contains an additional key exchange. As the + IKE_INTERMEDIATE exchange is encrypted, the IKE fragmentation + protocol [RFC7383] can be used. The IKE SK_* values are updated + after each exchange, and so the final IKE SA keys depend on all the + key exchanges, hence they are secure if any of the key exchanges are + secure. Note that readers should consider the approach defined in this document as providing a long term solution in upgrading the IKEv2 protocol to support post-quantum algorithms. A short term solution to make IKEv2 key exchange quantum secure is to use post-quantum pre- shared keys as discussed in [RFC8784]. Note also, that the proposed approach of performing multiple successive key exchanges in such a way that resulting session keys depend on all of them is not limited to achieving quantum resistance @@ -177,28 +178,38 @@ requirement. However, if such a requirement is needed, [I-D.tjhai-ikev2-beyond-64k-limit] discusses approaches that should be taken to exchange huge payloads. 1.3. Changes RFC EDITOR PLEASE DELETE THIS SECTION. Changes in this draft in each version iterations. + draft-ietf-ipsecme-ikev2-multiple-ke-03 + + o More clarifications added. + + o Figure illustrating initial exchange added. + + o Minor editorial changes. + draft-ietf-ipsecme-ikev2-multiple-ke-02 o Added a reference on the handling of KE payloads larger than 64KB. draft-ietf-ipsecme-ikev2-multiple-ke-01 o References are updated. + draft-ietf-ipsecme-ikev2-multiple-ke-00 + o Draft name changed as result of WG adoption and generalization of the approach. o New exchange IKE_FOLLOWUP_KE is defined for additional key exchanges performed after CREATE_CHILD_SA. o Nonces are removed from all additional key exchanges. o Clarification that IKE_INTERMEDIATE must be negotiated is added. @@ -362,29 +373,29 @@ is also renamed from "Diffie-Hellman Group Transform IDs" to "Key Exchange Method Transform IDs". In order to support IKE fragmentation for additional key exchanges that may have long public keys, the proposed framework utilizes the IKE_INTERMEDIATE exchange defined in [I-D.ietf-ipsecme-ikev2-intermediate]. In order to minimize communication overhead, only the key shares that are agreed to be used are actually exchanged. In order to achieve - this several new Transform Types are defined, each sharing possible + this several new Transform Types are defined, each sharing allowed Transform IDs with Transform Type 4. The IKE_SA_INIT message includes one or more newly defined SA transforms that lists the extra key exchange policy required by the initiator; the responder selects a single transform of each type, and returns them in the response IKE_SA_INIT message. Then, provided that additional key exchanges are negotiated, the initiator and the responder perform one or more - IKE_INTERMEDIATE exchanges; each such exchange includes a KE payload - for one of the negotiated key exchanges. + IKE_INTERMEDIATE exchanges; every such exchange includes a KE payload + for the next method from the negotiated list. Here is an overview of the initial exchanges: Initiator Responder --------------------------------------------------------------------- <-- IKE_SA_INIT (additional key exchanges negotiation) --> <-- {IKE_INTERMEDIATE (additional key exchange)} --> ... @@ -405,63 +416,62 @@ The concern is that some of these hard problems may turn out to be easier to solve than anticipated and thus the key agreement algorithm may not be as secure as expected. A hybrid solution allows us to deal with this uncertainty by combining a classical key exchange with a post-quantum one, as well as leaving open the possibility of multiple post-quantum key exchanges. The method that we use to perform additional key exchanges also addresses the fragmentation issue. The initial IKE_INIT messages do not have any inherent fragmentation support within IKE; however that - can include a relatively short KE payload (e.g. one for group 14, 19 - or 31). The rest of the KE payloads are encrypted within - IKE_INTERMEDIATE messages; because they are encrypted, the standard - IKE fragmentation solution [RFC7383] is available. + can include a relatively short KE payload. The rest of the KE + payloads are transferred within IKE_INTERMEDIATE messages; because + these messages are encrypted, the standard IKE fragmentation solution + [RFC7383] is available. - The fact that all Additional Key Exchange Transform Types share the - same registry with Transform Type 4 allows additional key exchanges + The fact, that all Additional Key Exchange Transform Types share the + same registry with Transform Type 4, allows additional key exchanges to be of any type - either post-quantum ones or classical (EC)DH ones. This approach allows any combination of defined key exchange methods to take place. This also allows performing a single post- quantum key exchange in the IKE_SA_INIT without additional key exchanges, provided that IP fragmentation is not an issue and that hybrid key exchange is not needed. 3.2. Overall Protocol In the simplest case, the initiator is happy with a single key exchange (and has no interest in supporting multiple), and it is not concerned with possible fragmentation of the IKE_SA_INIT messages (either because the key exchange it selects is small enough not to fragment, or the initiator is confident that fragmentation will be handled either by IP fragmentation, or transport via TCP). - In this case, the initiator performs the IKE_SA_INIT as standard, + In this case, the initiator performs the IKE_SA_INIT as usual, inserting a preferred key exchange (which is possibly a post-quantum algorithm) as the listed Transform Type 4, and including the initiator KE payload. If the responder accepts the policy, it responds with an IKE_SA_INIT response, and IKE continues as usual. - If the initiator desires to negotiate multiple key exchanges, or it - needs IKE to handle any possible fragmentation, then the initiator - uses the protocol listed below. + If the initiator desires to negotiate multiple key exchanges, then + the initiator uses the protocol listed below. 3.2.1. IKE_SA_INIT Round: Negotiation Multiple key exchanges are negotiated using the standard IKEv2 mechanism, via SA payload. For this purpose several new transform types, namely Additional Key Exchange 1, Additional Key Exchange 2, Additional Key Exchange 3, etc., are defined. They are collectively called Additional Key Exchanges and have slightly different semantics than existing IKEv2 transform types. They are interpreted as additional key exchanges that peers agreed to perform in a series of - IKE_INTERMEDIATE exchanges. The possible transform IDs for these + IKE_INTERMEDIATE exchanges. The allowed transform IDs for these transform types are the same as IDs for the Transform Type 4, so they all share a single IANA registry for transform IDs. Key exchange methods negotiated via Transform Type 4 MUST always take place in the IKE_SA_INIT exchange. Additional key exchanges negotiated via newly defined transforms MUST take place in a series of IKE_INTERMEDIATE exchanges, in an order of the values of their transform types, so that key exchange negotiated using Transform Type n always precedes that of Transform Type n + 1. Each IKE_INTERMEDIATE exchange MUST bear exactly one key exchange method. @@ -495,27 +506,41 @@ exchange as described in [I-D.ietf-ipsecme-ikev2-intermediate], by including INTERMEDIATE_EXCHANGE_SUPPORTED notification in the IKE_SA_INIT request message. If the responder agrees to use additional key exchanges, it MUST also return this notification, thus confirming that IKE_INTERMEDIATE exchange is supported and will be used for transferring additional key exchange data. The presence of Additional Key Exchanges transform types in SA payload without negotiation of using IKE_INTERMEDIATE exchange MUST be treated as protocol error by both initiator and responder. + Initiator Responder + --------------------------------------------------------------------- + HDR, SAi1(.. AKE*...), KEi1, Ni, + N(INTERMEDIATE_EXCHANGE_SUPPORTED) ---> + HDR, SAr1(.. AKE*...), KEr1, Nr, + [CERTREQ], + <--- N(INTERMEDIATE_EXCHANGE_SUPPORTED) + The responder performs negotiation using standard IKEv2 procedure described in Section 3.3 of [RFC7296]. However, for the Additional Key Exchange types the responder's choice MUST NOT contain equal transform IDs (apart from NONE), and the ID selected for Transform Type 4 MUST NOT appear in any of Additional Key Exchange transforms. In other words, all selected key exchange methods must be different. + If the responder selected NONE for some Additional Key Exchange types + (provided they were proposed by the initiator), then the + corresponding IKE_INTERMEDIATE exchanges should not take place. The + IKE_INTERMEDIATE exchanges MUST only be performed for Additional Key + Exchange types containing non-NONE responders choices. + 3.2.2. IKE_INTERMEDIATE Round: Additional Key Exchanges For each extra key exchange agreed to in the IKE_SA_INIT exchange, the initiator and the responder perform one IKE_INTERMEDIATE exchange, as described in [I-D.ietf-ipsecme-ikev2-intermediate]. These exchanges are as follows: Initiator Responder --------------------------------------------------------------------- @@ -528,91 +553,92 @@ On receiving this, the responder sends back key exchange payload KEr(n); again, this packet is protected with the current SK_er/SK_ar keys. The former "Diffie-Hellman Group Num" (now called "Key Exchange Method") field in the KEi(n) and KEr(n) payloads MUST match the n-th negotiated additional key exchange. Note that the negotiated transform types (the encryption type, integrity type, prf type) are not modified. - Once this exchange is done, then both sides compute an updated keying + Once this exchange is done, both sides compute an updated keying material: SKEYSEED(n) = prf(SK_d(n-1), KE(n) | Ni | Nr) where KE(n) is the resulting shared secret of this key exchange, Ni and Nr are nonces from the IKE_SA_INIT exchange and SK_d(n-1) is the last generated SK_d, (derived from the previous IKE_INTERMEDIATE exchange, or the IKE_SA_INIT if there have not already been any IKE_INTERMEDIATE exchanges). Then, SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, SK_pr are updated as: {SK_d(n) | SK_ai(n) | SK_ar(n) | SK_ei(n) | SK_er(n) | SK_pi(n) | SK_pr(n)} = prf+ (SKEYSEED(n), Ni | Nr | SPIi | SPIr) Both the initiator and the responder use these updated key values in - the next exchange. + the next exchange (IKE_INTERMEDIATE or IKE_AUTH). 3.2.3. IKE_AUTH Exchange After all IKE_INTERMEDIATE exchanges have completed, the initiator and the responder perform an IKE_AUTH exchange. This exchange is the standard IKE exchange, except that the initiator and responder signed octets are modified as described in [I-D.ietf-ipsecme-ikev2-intermediate]. 3.2.4. CREATE_CHILD_SA Exchange - The CREATE_CHILD_SA exchange is used in IKEv2 for the purpose of + The CREATE_CHILD_SA exchange is used in IKEv2 for the purposes of creating additional Child SAs, rekeying them and rekeying IKE SA itself. When creating or rekeying Child SAs, the peers may optionally perform a Diffie-Hellman key exchange to add a fresh entropy into the session keys. In case of IKE SA rekey, the key exchange is mandatory. If the IKE SA was created using multiple key exchange methods, the peers may want to continue using multiple key exchanges in the CREATE_CHILD_SA exchange too. If the initiator includes any Additional Key Exchanges transform in the SA payload (along with Transform Type 4) and the responder agrees to perform additional key exchanges, then the additional key exchanges are performed in a series of new IKE_FOLLOWUP_KE exchanges that follows the CREATE_CHILD_SA exchange. The IKE_FOLLOWUP_KE exchange is introduced - as a dedicated exchange type to transfer data of additional key + as a dedicated exchange for transferring data of additional key exchanges following the key exchange performed in the CREATE_CHILD_SA. Its Exchange Type is . - These key exchanges are performed in an order of the values of their - transform types, so that key exchange negotiated using Transform Type - n always precedes key exchange negotiated using Transform Type n + 1. - Each IKE_FOLLOWUP_KE exchange MUST bear exactly one key exchange - method. Key exchange negotiated via Transform Type 4 always takes - place in the CREATE_CHILD_SA exchange, as per IKEv2 specification. + Additional key exchanges are performed in an order of the values of + their transform types, so that key exchange negotiated using + Transform Type n always precedes key exchange negotiated using + Transform Type n + 1. Each IKE_FOLLOWUP_KE exchange MUST bear + exactly one key exchange method. Key exchange negotiated via + Transform Type 4 always takes place in the CREATE_CHILD_SA exchange, + as per IKEv2 specification. Since after IKE SA is created the window size may be greater than one and multiple concurrent exchanges may be in progress, it is essential to link the IKE_FOLLOWUP_KE exchanges together and with the corresponding CREATE_CHILD_SA exchange. A new status type notification ADDITIONAL_KEY_EXCHANGE is used for this purpose. Its Notify Message Type is , Protocol ID and SPI Size are both set to 0. The data associated with this notification is a blob meaningful only to the responder, so that the responder can correctly link successive exchanges. For the initiator the content of this notification is an opaque blob. The responder MUST include this notification in a CREATE_CHILD_SA or - IKE_FOLLOWUP_KE response message in case the next exchange is - expected, filling it with some data that would allow linking this - exchange to the next one. The initiator MUST copy the received - notification with its content intact into the request message of the - next exchange. + IKE_FOLLOWUP_KE response message in case the next IKE_FOLLOWUP_KE + exchange is expected, filling it with some data that would allow + linking current exchange to the next one. The initiator MUST send + back the content of the received notification intact in the request + message of the next exchange. Below is an example of three additional key exchanges. Initiator Responder --------------------------------------------------------------------- HDR(CREATE_CHILD_SA), SK {SA, Ni, KEi} --> <-- HDR(CREATE_CHILD_SA), SK {SA, Nr, KEr, N(ADDITIONAL_KEY_EXCHANGE)(link1)} HDR(IKE_FOLLOWUP_KE), SK {KEi(1), @@ -646,56 +672,56 @@ has, it MUST send back a new error type notification STATE_NOT_FOUND. This is a non-fatal error notification, its Notify Message Type is , Protocol ID and SPI Size are both set to 0 and the data is empty. If the initiator receives this notification in response to IKE_FOLLOWUP_KE exchange performing additional key exchange, it MUST cancel this exchange and MUST treat the whole series of exchanges started from the CREATE_CHILD_SA exchange as failed. In most cases, the receipt of this notification is caused by premature deletion of the corresponding state on the responder (the time period between IKE_FOLLOWUP_KE exchanges appeared too long from - responder's point of view, e.g. due to a temporary network failure). - After receiving this notification the initiator MAY start a new - CREATE_CHILD_SA exchange (eventually followed by the IKE_FOLLOWUP_KE - exchanges) to retry the failed attempt. If the initiator continues - to receive STATE_NOT_FOUND notifications after several retries, it - MUST treat this situation as a fatal error and delete IKE SA by - sending a DELETE payload. + the responder's point of view, e.g. due to a temporary network + failure). After receiving this notification the initiator MAY start + a new CREATE_CHILD_SA exchange (eventually followed by the + IKE_FOLLOWUP_KE exchanges) to retry the failed attempt. If the + initiator continues to receive STATE_NOT_FOUND notifications after + several retries, it MUST treat this situation as a fatal error and + delete IKE SA by sending a DELETE payload. When rekeying IKE SA or Child SA, it is possible that the peers start doing this at the same time, which is called simultaneous rekeying. - Sections 2.8.1 and 2.8.2 of [RFC7296] describes how IKEv2 handles - this situation. In a nutshell IKEv2 follows the rule that if in case - of simultaneous rekeying two identical new IKE SAs (or two pairs of + Sections 2.8.1 and 2.8.2 of [RFC7296] describe how IKEv2 handles this + situation. In a nutshell IKEv2 follows the rule that if in case of + simultaneous rekeying two identical new IKE SAs (or two pairs of Child SAs) are created, then one of them should be deleted. Which one is to be deleted is determined by comparing the values of four nonces, that were used in the colliding CREATE_CHILD_SA exchanges - the IKE SA (or pair of Child SAs) that was created by the exchange in which the smallest nonce was used should be deleted by the initiator of this exchange. With multiple key exchanges the SAs are not yet created when the CRETE_CHILD_SA is completed, they would be created only after the series of IKE_FOLLOWUP_KE exchanges is finished. For this reason if additional key exchanges were negotiated in the CREATE_CHILD_SA initiated by the losing side, there is nothing to delete and this side just stops the rekeying process - this side MUST not initiate IKE_FOLLOWUP_KE exchange with next key exchange. In most cases, rekey collisions are resolved in the CREATE_CHILD_SA exchange. However, a situation may occur when due to packet loss, - one of the peers receives CREATE_CHILD_SA message requesting rekeying - SA that is already being rekeyed by this peer (i.e. the + one of the peers receives the CREATE_CHILD_SA message requesting + rekey of SA that is already being rekeyed by this peer (i.e. the CREATE_CHILD_SA exchange initiated by this peer has been already completed and the series of IKE_FOLLOWUP_KE exchanges is in - progress). In this case, a TEMPORARY_FAILURE notification MUST be - sent in response to such a request. + progress). In this case, TEMPORARY_FAILURE notification MUST be sent + in response to such a request. If multiple key exchanges were negotiated in the CREATE_CHILD_SA exchange, then the resulting keys are computed as follows. In case of IKE SA rekey: SKEYSEED = prf(SK_d, KE | Ni | Nr | KE(1) | ... KE(n)) In case of Child SA creation or rekey: KEYMAT = prf+ (SK_d, KE | Ni | Nr | KE(1) | ... KE(n)) @@ -801,22 +827,22 @@ negotiate the post-quantum algorithms using the existing KE payload. The authors are also grateful to Tobias Heider and Tobias Guggemos for valuable comments. 7. References 7.1. Normative References [I-D.ietf-ipsecme-ikev2-intermediate] Smyslov, V., "Intermediate Exchange in the IKEv2 - Protocol", draft-ietf-ipsecme-ikev2-intermediate-05 (work - in progress), September 2020. + Protocol", draft-ietf-ipsecme-ikev2-intermediate-06 (work + in progress), March 2021. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, .