> -----Original Message----- > From: Paul Wouters [mailto:[email protected]] > Sent: Wednesday, August 16, 2017 10:16 PM > To: [email protected] 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 _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
