On Wed, Dec 04, 2019 at 11:34:36AM +0300, Valery Smyslov wrote: > > thank you for the thorough review.
Seconded! > > Another issue I see is with connection selection and PPK selection. > > At the IKE_INTERMEDIATE exchange, we don't know yet which connection > > this will map to, as we haven't seen the AUTH payload nor the IDr > > payload. So I think you would at the minimum need to also send the > > IDr payload if you are sending a PPK payload. Or you need to overload > > or derive this information from the supplied PPK_ID. I feel this might > > cause operational problems. > > Well, I'm not sure this is a real issue. If PPKs are fixed, then I see no > problem: > the responder just selects one of the proposed PPKs and during IKE_AUTH > he verifies that the selected PPK is configured for the IDi. If the responder > selects a wrong PPK, then it means that there is a misconfiguration and > the connection won't be established anyway. > > Of course, the initiator must only propose the PPK identities that are > suitable > for the connection being created. Otherwise the following situation may > happen. > Consider there are two group of users each configured with own PPK (group > PPKs). > If initiator is a member of both groups and he doesn't know which > group the responder belongs to, he may include two PPK identities for the > responder > to select. If the responder is also a member of both groups, he will select > an arbitrary PPK (he owns both). But if due to misconfiguration (or some > transient > changes in configuration) it happens, that the responder thinks the initiator > belongs only to one of this groups (this becomes clear in IKE_AUTH) and > he made a wrong guess, the SA won't be set up (but it couldn't be if the > responder knew the IDi of initiator when he was selecting PPK). > I think it's rather weird situation and is also the result of > misconfiguration, > however I admit that including IDi would help in this case. > > The problem may also arise when PPK identity is generated and depends on peer > identity > (e.g. some OTP cases when each new connection uses new PPK_ID generated > using the initiator's identity). Currently these use cases are mostly > theoretical ones. It seems likely that some formal analysis would help shed light on the issues here, if we could find someone interested and able to do the work. I'll see if I can ask around... -Ben _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
