[IPsec] draft-fluhrer-qr-ikev2 AUTH issue

[Paul Wouters <[e-mail]>]

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