Hi,
Vukasin Karadzic is working on implementing draft-fluhrer-qr-ikev2
for libreswan and stumbled upon a problem. The relevant text:
When the initiator receives this reply, it checks whether the
responder included the PPK_SUPPORT notify. If the responder did not,
then the initiator MUST either proceed with the standard IKE
negotiation (without using a PPK), or abort the exchange (for
example, because the initiator has the PPK marked as mandatory). If
the responder did include the PPK_SUPPORT notify, then it selects a
PPK, along with its identifier PPK_id. Then, it computes this
modification of the standard IKE key derivation:
A responder answering an IKE_INIT containing PPK_SUPPORT needs to
reply without knowing for which connection this IKE_INIT will be.
The responder has not yet received the initiator's ID. If the responder
has some connections that require a PPK and some connections that
require NO PPK, then it has to flip a coin on whether or not to send
the PPK_SUPPORT notify and if it guessed wrong, the AUTH payload on
the initiator will be wrong. Sending the notify commits to using a PPK
because the initiator uses it as input to the AUTH payload.
So this table from the RFC is incomplete:
This table summarizes the above logic by the responder
Received PPK_SUPPORT Have PPK PPK Mandatory Action
------------------------------------------------------------------
No No * Standard IKE protocol
No Yes No Standard IKE protocol
No Yes Yes Abort negotiation
Yes No * Standard IKE protocol
Yes Yes * Include PPK_SUPPORT
Basically, we are in the case where "Have PPK" is not yet known.
One way of solving this could be to allow PPK_SUPPORT to have some
notify data, which could for instance be a hash of the connection/group
name used by the responder. Another option is to use the PPK as one
of the inputs to some hash algorithm as PPK_SUPPORT data, so the
responder can go through its list of PPKs to match it back to a
connection/group. But we would need to be sure that this does not
open up the PPK to attacks (classic and quantum)
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
