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

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-bounces@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.karadzic@gmail.com>; Scott Fluhrer (sfluhrer) <sfluhrer@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