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]
