Thanks Tero! -> https://github.com/smyslov/ikev2-downgrade-prevention/issues/26
Chris P. On Sat, Mar 28, 2026 at 10:25 AM Tero Kivinen <[email protected]> wrote: > This is my shepherd review of the > draft-ietf-ipsecme-ikev2-downgrade-prevention: > > -- > > In section 1 it might be better to just leave out "defined in" and > just use the references to point where it is defened in, i.e., change > to: > > The Internet Key Exchange version 2 protocol (IKEv2) [RFC7296] > provides authenticated key exchange in the IP Security (IPsec) > architecture. The cryptographic design of IKEv2 is based on the > SIGn-and-MAc (SIGMA) protocol [SIGMA]. > > -- > > In section 4 the text uses term "public key" to refer the contents of > Key Exchange Data. In IKEv2 RFC 7296 the public key is only used to > refer authentication public key, like X.509 key etc. I propose to > reword the text so that term "Key Exchange Data value" instead "public > key" is used. > > Change > > 2. The attacker intercepts this message and re-injects a modified > message without "strong" key exchange methods. Note that this > may require an additional step for the attack to succeed if the > initiator includes a public key for a "strong" key exchange > method in the request. In this case the attacker intercepts this > message and responds with the INVALID_KE_PAYLOAD notification > indicating that the initiator must include a public key for a > "weak" key exchange method. Then this message is intercepted and > re-injected without "strong" key exchange methods. > > to > > 2. The attacker intercepts this message and re-injects a modified > message without "strong" key exchange methods. Note that this > may require an additional step for the attack to succeed if the > initiator includes a Key Exchange Data value for a "strong" key > exchange method in the request. In this case the attacker > intercepts this message and responds with the > INVALID_KE_PAYLOAD notification indicating that the initiator > must include a Key Exchange Data value for a "weak" key > exchange method. Then this message is intercepted and > re-injected without "strong" key exchange methods. > > IKEv2 usually talksabotu the "Diffie-Hellman public value", or > "Diffie-Hellman public numbers", but as the key exchange methods are > no longer only for Diffie-Hellman, it is better to use the Key > Exchange Data value, where the "Key Exchange Data" refers to the field > inside the Key Exchange Payload. > > and also change: > > 4. Since the attacker has seen both public keys and can break the > selected "weak" key exchange method in real time, it calculates > the SK_* session keys that allow the attacker to read and modify > the content of the encrypted IKE messages. > > to > > 4. Since the attacker has seen both Key Exchange Payloads and can > break the selected "weak" key exchange method in real time, it > calculates the SK_* session keys that allow the attacker to > read and modify the content of the encrypted IKE messages. > > -- > > In section 4 expand the title before [DOWNGRADE] reference, i.e. > change to > > The second type of attack is an identity misbinding attack described > in [DOWNGRADE]. > > to > > The second type of attack is an identity misbinding attack > described in Downgrade Resilience in Key-Exchange Protocols > [DOWNGRADE]. > > -- > > The attacks are bit hard to undertand, perhaps having packet flows > would make it easier to understand. For example the identity > misbinding attack does not mention that the attacker of course also > need to modify the IDi sent by the initiator to IDa to match the long > term key of A. > > Perhaps change: > > In particular, suppose the attacker wants to eavesdrop on > communication between initiator I and responder R and has access to > the long-term authentication key of a different initiator A. The > attack works exactly the same way as the previous one, with one > exception: after decrypting and modifying I's AUTH payload, it > authenticates the modified AUTH payload with A's long-term > authentication key instead of I's, and changes the IDi to match the > identtiy of the initiator A. At the end of the attack, initiator I > will believe it has established a connection with responder R, but > responder R will believe it has established a connection with > initiator A (whose authentication key is known to the attacker). > Nevertheless, the attacker will be able to read the encrypted > messages sent between I and R. > > I think the message flow for this attack would be (optional payloads > omitted): > > original request --> IKE_SA_INIT(SA(strong, weak), KE, Ni) > > Attacker removes strong from the SA(strong, weak) > > modified request --> IKE_SA_INIT(SA(weak), KE, Ni) > > normal response <-- IKE_SA_INIT(SA(weak), KE, Nr) > > At this point all parties can calculate SK_* keys, as they > have seen KE payloads and attacker can break weak key exchange > method in real time. > > original request --> IKE_AUTH(IDi, AUTH(IDi), SA, TSi, TSr) > > Attacker changes IDi to IDa both in payload in MACedIDForI, > and also modifies the RealMessage1 to match its IKE_SA_INIT > message and that is then used in AUTH calculation and then > authenticates the A using A's long term key: > > modified request --> IKE_AUTH(IDa, AUTH(IDa), SA, TSi, TSr) > > response <-- IKE_AUTH(IDr, AUTH, SA, TSi, TSr) > > -- > > The first attack would be: > > original request --> IKE_SA_INIT(SA(strong, weak), KE, Ni) > > Attacker removes strong from the SA(strong, weak) > > modified request --> IKE_SA_INIT(SA(weak), KE, Ni) > > normal response <-- IKE_SA_INIT(SA(weak), KE, Nr) > > At this point all parties can calculate SK_* keys, as they > have seen KE payloads and attacker can break weak key exchange > method in real time. > > original request --> IKE_AUTH(IDi, AUTH(IDi), SA, TSi, TSr) > > Attacker recalculates the InitiatorSignedOctets using the > RealMessage1 it used in its IKE_SA_INIT so responder does not > notice downgrade attack. It signs it with initiator's long > term key. > > modified request --> IKE_AUTH(IDi, AUTH', SA, TSi, TSr) > > response <-- IKE_AUTH(IDr, AUTH, SA, TSi, TSr) > > If you think those diagrams would be useful, those could also be added > as Appendix at the end. > > -- > > In section 6, use name of the document instead of just rfc number, > i.e., change > > ZeroPrefix serves a role of a domain > separator making the new authentication blocks of data always > different from authentication blocks of data defined in [RFC7296], > > to > > ZeroPrefix serves a role of a domain > separator making the new authentication blocks of data always > different from authentication blocks of data defined in IKEv2 > [RFC7296], > > -- > > In section 7 again use document name instead of just RFC number, > change: > > The IKE_INTERMEDIATE exchange defined in [RFC9242] also modifies > blocks of data to be signed (or MAC'ed). This modification is > described in Section 3.3.2 of [RFC9242] and can be summarized as an > addition of a new piece of data (IntAuth) to the end of the blocks of > data from Section 2.15 of [RFC7296]. If peers support extension > defined in this document, then they MUST treat modified blocks of > data to be signed (or MAC'ed) defined in Section 6 as replacements > for blocks of data defined in Section 2.15 of [RFC7296], so that in > case of IKE_INTERMEDIATE the IntAuth is added to these modified > blocks. > > to > > The IKE_INTERMEDIATE exchange [RFC9242] also modifies blocks of > data to be signed (or MAC'ed). This modification is described in > Section 3.3.2 of IKE_INTERMEDIAE exchage [RFC9242] and can be > summarized as an addition of a new piece of data (IntAuth) to the > end of the blocks of data from Section 2.15 of IKEv2 [RFC7296]. If > peers support extension defined in this document, then they MUST > treat modified blocks of data to be signed (or MAC'ed) defined in > Section 6 as replacements for blocks of data defined in Section > 2.15 of IKEv2 [RFC7296], so that in case of IKE_INTERMEDIATE the > IntAuth is added to these modified blocks. > > -- > > In section 7.2 same, i.e., change: > > SA if this ticket is later presented by the client. [RFC5723] > contains the list of IKE SA parameters marking each of parameter as > either "restored from the ticket" or "re-negotiated at the time of > resumption". > > to > > SA if this ticket is later presented by the client. IKE Session > Resumption [RFC5723] contains the list of IKE SA parameters marking > each of parameter as either "restored from the ticket" or > "re-negotiated at the time of resumption". > > > -- > > In section 8, same thing, i.e., change: > > The attacks can also be mitigated by mixing a pre-shared key into the > session key calculation. An attacker that does not know this pre- > shared key will be unable to decrypt even if it manages to downgrade > the key exchange. However, the use of a pre-shared key is negotiated > by an extension [RFC8784], [RFC9867], and this negotiation is itself > > to > > The attacks can also be mitigated by mixing a pre-shared key into > the session key calculation. An attacker that does not know this > pre- shared key will be unable to decrypt even if it manages to > downgrade the key exchange. However, the use of a pre-shared key is > negotiated by an extension Mixing Preshared Keys in IKEv2 > [RFC8784], or Mixing Preshared Keys in the IKE_INTERMEDIATE and > CREATE_CHILD_SA Exchanges [RFC9867], and this negotiation is itself > > > Note, that mixing pre-shared keys to exchange does not help if PPK key > is one of the long term authentication information that has leaked. > > -- > > Section 10 is missing, there is just TODO... Fill it in or remove it. > > -- > > In section 11.1 I do not think IKE_INTERMEDIATE Exchange in IKEv2 RFC > 9242 or IKEv2 Session Resumption are really normative referenes. Yes, > this document do provide guidance how this and them are combined, but > you can implement this protocol without any need to implementing > IKE_INTERMEDIATE or Session Resumption. I would move those to > informative references. > > -- > > ID nits complains that there are 5 non-ascii characters (’ 0x2019) > instead of ascii version (' 0x27). > -- > [email protected] >
_______________________________________________ IPsec mailing list -- [email protected] To unsubscribe send an email to [email protected]
