Hi Deb,
thank you for the review. Please see inline.
Thank you for your work on this draft. I found it to be well written and easy
to read (and super nice to be able to read a technical draft that I
understand!).
I have a few comments that I'd like you to address:
Section 1, para 2: Perhaps consider adding a phrase in the middle of this
sentence to say what the goal of this specification is: '...the data to be
authenticated in IKEv2 to prevent particular downgrade attacks, and thus.....'
[nothing else in the intro gives even a hint of the plan]
Done.
Section 4: Consider making two subsections, one for each attack type, just to
add clarity.
I’m a bit unsure whether this would help. First, the attacks are
almost identical, with very minor difference.
The prerequisites and the impact are different, but the attack steps
are the same and for this reason
only KCI attack is described in full details. Then, frankly we are not
sure that this list of two attacks
is exhaustive (and thus use “at least two attacks” wordings). Putting
them into subsections
will implicitly indicate that no other attacks are known.
I’d rather hear from Chris and others whether this change is needed.
Section 4, first # list, 3: Will either (initiator or responder) work? Or do
we really need the attacker know/be able to break the initiator's auth key?
The attack is described for the case the initiator’s key is
compromised, since this is the most
straightforward downgrade attack. If the responder’s key is
compromised (a mirror situation), then the negotiated
algorithms cannot be downgraded. However, for some IKE extensions,
when the responder sends
its preferences first in IKE_SA_INIT response, not in a response to
initiator’s proposals (e.g., Certificate Request, Auth Announce),
the attacker can change them unnoticed. This seems not as severe, as
the downgrade attack, but still.
We have some text about this later.
Do you think a clarification is needed in the list item?
Section 4, second # list: Are there initiator proposed protocol extensions
that can be removed/added to help the attacker?
I don’t think so. The attack is applied to the core IKEv2, irrelevant
to the proposed extensions.
Section 4, third # list, step 6: The attacker either knows the initiator's
long-term auth key, or must be able to break it in real time. At the expense
of brevity, I would add the additional phrase here. Perhaps 'and knows or can
break the initiator's long-term authentication key.'
How about:
The attacker is able to do this because it knows the
session keys and either knows the initiator's long-term
authentication key or can break its authentication algorithm.
This is a bit more accurate, since if attacker could be able forge the
signature without breaking the key.
Section 4, para after third # list: Is this in addition to knowing/breaking the
initiator's auth key? The attacker can still choose the weak key exchange if
they know/can break the responder's auth key?
No, this is an alternative use case. The attacker knows only one
long-term key – either the initiator’s one or the responder’s one.
We described attack in detail for the first case, but mention here,
that for the second case, while less severe, some attacks are also plausible.
If the attacker knows both long-term keys and can break into session
keys too, we are helpless…
Section 4, second to last para: I'm assuming that the attacker is not required
to be on the path for the whole session. If I am correct, consider a small
addition 'be able to passively read'. [if there is a more appropriate word for
'passively', I'm fine with that, it is just the way I think about it.]
Done.
Section 4, last para: Consider replacing 'because peers would disable' with
'which encouraged peers to disable', or something similar. I would remove 'on
the other hand', as this is part of the discussion - uncertainty about whether
algorithms are secure or insecure. During a migration period, it is harder to
determine which algorithms are secure/insecure, which makes these attacks more
relevant.
Done.
Section 5, second to last para: Not all attacks are a result of
knowing/breaking the initiator auth key, there is at least one variant where
the responder's auth key is know/breakable. Consider changing 'In particular,
for the attacks' to 'For example, for the attacks...
Done.
Section 5 or 6: Spelling out the actual detection mechanism: Can we add
something that says how the impersonated entity can determine that they have
been attacked by determining that Message1 (or Message2) is different than what
was originally sent? Presumably they have to construct the hash and then
validate the signature.
Yes, but not as some separate check. With this extension the way
authentication data (e.g. signatures) is calculated in IKEv2
is modified, so that both initial messages are now included under
signature. Thus we make sure that their modification
will be detected at least by one peer when it verifies the IKEv2
authentication data sent by the peer . And if the verification fails,
the peer cannot tell that it is due to the attempted impersonation
attack or due to any other reason (e.g., misconfigured long-term keys).
Should we add any clarification, and if yes, can you propose some
text, please?
Section 8, Note between para 3 and 4: This doesn't read properly, 'one of the
long term authentication information', but I can't quite figure out how to
suggest it be corrected.
Perhaps “credentials”?
Section 8, para 4 and 5: I would flip these paragraphs, start with 'avoid using
the same key for different purposes', and then talk about what the risk is.
OK.
Nits:
Section 4, before second numbered list: 'In case the'/'In the case where the'.
Fixed.
Thanks again for your review! I created a PR:
https://github.com/smyslov/ikev2-downgrade-prevention/pull/42
Regards,
Valery.
Deb Cooley
Sec AD
_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]
