Good point Paul. The issue will also hold for an initiator. The initiator might have PPK enabled with other peers but not have a PPK_id configured for a responder after he gets her IKE_INIT response with N(PPK_SUPPORT) included. Practically the N(PPK_SUPPORT) is dictated by a global PPK support configuration on the initiator and responder, but that does not mean a PPK is configured for all their peers.
As Tero and Scott suggested, for the shake of simplicity it makes sense to tighten the text with normative language to make it clear to an implementer. For an initiator with PPK enabled but no PPK_id, regular IKE should be included in the initiators IKE_AUTH message. For the responder, imo a failure should occur after the initiator's IKE_AUTH if a PPK_id doesn't exist and PPK is enabled in the responder. And optionally the responder could add the initiator in a no_PPK_supported local cache. Rgs, Panos -----Original Message----- From: IPsec [mailto:ipsec-boun...@ietf.org] On Behalf Of Paul Wouters Sent: Wednesday, August 16, 2017 10:16 PM To: ipsec@ietf.org WG <ipsec@ietf.org> Cc: Vukasin Karadzic <vukasin.karad...@gmail.com>; Scott Fluhrer (sfluhrer) <sfluh...@cisco.com> Subject: [IPsec] draft-fluhrer-qr-ikev2 AUTH issue 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 IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
