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

["Graham Bartlett (grbartle)" <[e-mail]>]

Hi Paul

I’m a bit late to the party, but thought I’d chip in if it helps..

With regards to ‘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’

If you follow the logic below (I sent the following to Scott back in the day) with the GW (or responder) being configured with the PPK’s for the initiators first, then the initiators being configured and ONLY sending the PPK supported when it has a key for the peer you should be ok.

cheers

I would like to propose the following;
- Step 0 is "never use PPKs" (this is the existing IKE standard)

- Logic 1 is “if we are initiator only advertise PPK notify if we have a PPK for the peer”

- Step 1 is "if we're the initiator, then use PPKs if the responder signaled support for it"

    - Step 2 is "insist on PPKs if the peer support it (in both the initiator and the responder roles)"

So for a remote access VPN GW, you would configure the GW first and then each client. The GW will only respond with the PPK notify if the client had included the PPK notify. Once the client has the PPK it will include the PPK notify and pass authentication.

Likewise for Hub and Spoke, the same principle.

The issue I would foresee is something like DMVPN or a partial/full mesh, but my logic mitigates any issues.. the Hub has the PPK and Spoke 1 has the PPK.. The Spoke1 – Hub SA is protected by the PPK. If Spoke2 did not have a PPK and connected to the Hub, the Spoke2 – Hub is not PPK protected, then Spoke1 connected to Spoke2, because of the logic (“if we are initiator only advertise PPK notify if we have a PPK for the peer”) Spoke1 would not advertise the PPK notify and hence we get over this limitation.


Now where this falls down is if there’s a shared key, so in the example above is all spokes used a shared key and one of the spokes didn’t have it – then the logic would fail.


On 17/08/2017, 03:16, "IPsec on behalf of Paul Wouters" <[e-mail] on behalf of [e-mail]> wrote:

    
    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
    [e-mail]
    https://www.ietf.org/mailman/listinfo/ipsec