Hi Scott,
thank you for your comments. Please see inline. I just went through the ikev2-qr-alt draft, and have these comments: - The last paragraph of 3.1 worries about the case where the two sides agree on a PPK, but after authenticating, it turns out that they're not configuring for using that PPK with the peer's identify. Thoughts: o Is this a real security issue? After all, I believe that the PPK is designed to enhance privacy, not authentication (and while it can does add some authentication, I do not believe that's its main role). o If we get to this step, both sides know the same PPK, however they're not configured to use it in that context. What would the security issue be if we were to ignore that? o If that is an issue, then we should have a better way of addressing it than "fail the connection". Perhaps we could pass some identity information in the IKE_INTERMEDIATE, so that both sides could make a better decision. While the primary goal of PPKs was enhance privacy, they affected authentication too - with both RFC 8784 and this specification mismatched PPKs would result in authentication failure. RFC 8784 assumed that PPKs are relatively static. With this assumption pairwise PPKs for each pair of peers in most cases have scalability issues, thus we explicitly said there that group PPKs are OK. This specification assumes that PPKs can be changed frequently (the means for this are out of scope, e.g. QKD), thus a situation with pairwise PPKs may change. Consider the following example. Alice and Carol both can connect to Bob with PPK and digital signature authentication. Alice is configured with PPK_a, Carol is configured with PPK_c. Bob obviously has both these PPKs. If Malory somehow knows PPK_a (e.g just stole it) and is equipped with CRQC, then she obviously gets access to all past communications between Alice and Bob and she also is able to impersonate Alice to Bob in future. But if Bob skips the check above (that Alice may only use PPK_a and Carol may only use PPK_c), then Malory can also impersonate Carol using PPK_a, if she breaks Carol's signature. Thus I believe that this is a security issue (depending on responder's policy, it is not an issue with group PPKs). What about the identity in IKE_INTERMEDIATE. We have PPK_ID there and it is responder's local security policy, that links PPK_IDs with IKE IDs. Thus we don't decrease identity protection (PPK_IDs can be made looking random and be changed frequently, and we do not expose IKE ID to an attacker who doesn't possesses a valid PPK). - In the PPK_IDENTITY_KEY notify, you have a variable length PPK_ID field followed by a fixed length PPK Confirmation field (and the parses is expected to deduce the length of the PPK_ID field). In my opinion, it would be cleaner if the fixed length field came first. Just a suggestion. The current format was inspired by typical authenticated message format, where a fixed-length ICV is usually appended to a variable-length message. I have no problem to swap them, if other vendors, who already implemented this draft, agree with you. But actually, the difference in the code would be minimal. - In 3.2, you omit the existing messages in the CREATE_CHILD_SA messages "for brevity". I believe it would explain how the new payloads would integrate into the existing exchange by listing the full exchange. Done. Regards, Valery.
_______________________________________________ IPsec mailing list -- ipsec@ietf.org To unsubscribe send an email to ipsec-le...@ietf.org
