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

["Scott Fluhrer (sfluhrer)" <[e-mail]>]

> -----Original Message-----
> From: Paul Wouters [mailto:[e-mail]]
> Sent: Wednesday, August 16, 2017 10:16 PM
> To: [e-mail] WG
> Cc: Scott Fluhrer (sfluhrer); Vukasin Karadzic
> Subject: 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,

We never envisioned a situation where you would deliberately chose not to use a PPK.  Can we replace this with a situation where you don't know whether you share a PPK with the initiator?

> 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)

That's what we did in our original proposal (actually, it was a function of the PPK itself).  The problems with that were:

- If we made it a nondeterministic function (that is, include a randomizer), then the server had to do a linear scan over all their known PPKs to find the matching one.

- If we made it a deterministic function, then someone listening in can trivially determine when we're reusing the same PPK

(There's also a minor issue of "which hash function to use"; we haven't negotiated any at this time).

A linear scan over possibly 10,000 PPKs was considered unacceptable.  One of our proposals even allowed the server to specify the trade-off between the above two; that was considered too complex.

I'm not thrilled with Tero's answer of "lets be careful about the order we upgrade things in complex networks", but I don't know how to better solve it without adding lots of complexity to the protocol, potential anonymity leaks or requiring significant computation on the server side.


> 
> Paul