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:
* 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).
* 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?
* 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.
* 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.
* 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.
_______________________________________________
IPsec mailing list -- ipsec@ietf.org
To unsubscribe send an email to ipsec-le...@ietf.org
