Hi Chris,
My idea is that responder can hash the received IKE_SA_INIT message
(actually, do a negotiated prf with some fixed or known key, since
hash is not negotiated in IKEv2) and include the result into the
response IKE_SA_INIT using some new status notification.
Responder’s IKE_SA_INIT message is directly included into the data the
responder authenticates, thus the attacker cannot change it unless
responder’s private key is compromised or the attacker can break the
authentication algorithm.
When the initiator receives the IKE_SA_INIT response, it can check
whether the content of this notification matches the IKE_SA_INIT message it
sent.
If not – the attack is detected. Initiator that does not support this
extension will just ignore the unknown notification.
Note that this does not protect against situation when responder’s
long-term key is compromised and initiator’s one is not.
But in this case if the responder selects the hybrid key exchange and
the attacker then modifies its selection as if only ECDH is selected, then the
protocol will stuck –
the responder will expect IKE_INTERMEDIATE as next exchange and won’t
accept IKE_AUTH that the attacker will initiate.
^^^^^^^^^^^^^^ the initiator
I’m not sure if the attacker can fix this situation (it seems to me the
answer is no, because even if it in between actively modifying
all IKE messages, eventually it will have to authenticate all these
messages on behalf on initiator, which seems
infeasible, since we assume that initiator’s key is not compromised).
And if both peers’ long-term keys are compromised and the attacker can
break ECDH, then no defense is possible.
Your opinion, will this defense work?
This sounds like a partial solution. I think you'd also want the initiator to
hash the responder's message as well. I believe we'd also want to include the
intermediate key exchange messages to make this more robust.
Intermediate exchange messages are already included into the AUTH
calculation (see RFC 9242). And they are included as “full transcript”
(in quotes, because it is a bit more complicated, but the result must
be the same).
And hashing the responder’s IKE_SA_INIT by the initiator won’t help in
the conditions that we assume –
the initiator can only send it back in the IKE_AUTH (we assume basic
IKEv2 with no intermediate exchanges)
and the attacker that broke ECDH in real time has full control over
IKE_AUTH messages: it can change this hash.
As I described above hashing the responder’s IKE_SA_INIT message is
less valuable.
If the attacker modifies it, changing responder’s selection of
algorithms, then peers
will have an inconsistent view of what should be done for SA to be
established and in
most (all?) cases the protocol will not complete. This requires a
deeper analysis, of course…
The solution I proposed relies on the fact that the only message that
is out of the attacker’s control
in IKE_SA_INIT response – it is directly authenticated by the
responder. whose key is the only
key that is not compromised in the situation you described. And the
responder adds hash of the IKE_SA_INIT request
there making it like a “full transcript” of IKE_SA_INIT exchange,
which then it authenticates.
Also, I believe the mechanism itself is subject to the downgrade attack, unless
it's marked as mandatory by the initiator. That is, if the responder doesn't
respond with the hash, then the initiator would need to abort.
There is no downgrade attack. The attacker cannot _force_ peers to not
use this mechanism if they support it –
if it removes this notification from the IKE_SA_INIT response then the
SA the authentication will fail.
But I agree that it must be supported by both sides. I doubt if there is a
value to have a configuration
knob (“on”/”off”) for such a mechanism for responders – the supporting
responder can also use this extension. The initiator
will have to make a decision whether to proceed if it supports this mechanism
and it did not receive
the notification from the responder – that’s true.
Let's call this the "bootstrap" problem: The mechanism by which we prevent
downgrading to ECDH only should not itself be subject to the same downgrade
attack.
I agree and in my proposal it is not.
I wonder what you think of the strawman I proposed upthread
(https://mailarchive.ietf.org/arch/msg/ipsec/EbgO8BkJVk-zlYasb9dUuOPmRzs/).
Basically instead of just signing their own messages, each host also signs its
peers messages. The idea being that a successful IKE_AUTH flow implies that the
initiator and responder agree on the transcript of the conversation. This
sounds a bit simpler than what you've sketched, but it also doesn't solve the
bootstrap problem.
In your proposal the initiator and responder negotiate the use of the
extension – initiator sends some notify an in the IKE_SA_INIT request
and the responder echoes it back in the response. This is a weak
point. In the scenario you described the attacker can remove
this notify from the IKE_SA_INIT request and the IKE SA authentication
will succeed since the attacker knows the initiator’s long term key.
Thus, it doesn’t protect against downgrade attack because it can be
downgraded itself.
In my proposal it is not possible, thus I believe it is a better
approach.
Regards,
Valery.
Chris P.
_______________________________________________
IPsec mailing list -- [email protected]
To unsubscribe send an email to [email protected]
