Hi Tero,
I think it is a bit early to discuss particular approaches,
before the WG makes a decision to adopt the document.
However, just for the record (see below).
Earlier I have proposed very simple method where the IKE_SA_INIT
contains just some kind of notification messages identifying the
"oob-key" to be use. This identification information is completely
opaque, and fully depends on the implementation.
It could be fixed random string, which would immediately leak out the
identity of the users, just like IKEv1 IP-address did. It could just
random identifier, which identifies the one-time-use shared secret
from big table (which is shared between the end nodes), it could be
some kind of encrypted blob, which is encrypted with some kind of
system wide group shared key (i.e., everybody in the group know it,
but outsiders do not, so it protects identities for outsiders, but not
for insiders), or it could be something more complicated like what
current draft proposes.
For the IKEv2 protocol point of view it is just opaque binary object
which is given to the subsystem which will then return a shared key to
be used for him.
In all cases both ends must share the same shared key or table of
shared keys or access to the QKD subsystem, so this code that knows
how this blob is interpreted can be left to the implementations. We do
not need to standardize it, we can leave it open, just like we leave
cookie or the IKEv2 session resumption ticket format. We could include
some proposals in the appendix, and we might want to add 16-bit
"format identifier" in the beginning just in case people want mix
multiple methods in same implementations.
This means that the level of shared key identity protection is left to
implementation and to it depends on the policy settings.
When IKEv2 then has the shared secret then it needs to mix that to
some parts of the cryptographic protection to provide quantum
resistant IKEv2.
There are multiple levels on that:
1) Include it only in KEYMAT. This will protect all IPsec SAs, i.e.
the actual traffic transmitted over IPsec is protected from
attackers able to break the Diffie-Hellman of the IKEv2. I.e.,
replace SK_d in there with (SK_d | OOB_secret). Note, this have
also the side effect that after the first IKEv2 rekey also the
IKEv2 SA traffic is protected, as new keying material after the
IKEv2 rekey depends on the SK_d.
2) In addition to the 1, include it also in the SK_pi and SK_pr. This
will mean that even if the attacker is able to break Diffie-Hellman
and the Signature method, he will not be able to authenticate as
user, as he cannot calculate the MACedIDforI/MACedIDforR for
authentication. I.e. replace SK_pi and SK_pr with (SK_pi |
OOB_secret) and (SK_pr | OOB_secret).
3) Include it in the SKEYSEED calculation. This will has the side
effect that we are no longer able to get meaningfull error messages
in case something goes wrong in the OOB key identification process,
i.e., in case the OOB_secrets do not matchi, we just drop the frame
and wait for next one, thus we cause timeout if OOB_secret is
wrong. This is bad for user experience, but this will also protect
the IKEv2 SA traffic with the OOB_secret.
Not necessary. In particular, the current draft allows to detect
OOB key mismatch and to act gracefully in this situation.
And I don't think it is far too complicated.
Regards,
Valery.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
