[IPsec] Re: Comments on draft-ietf-ipsecme-ikev2-qr-alt

[Valery Smyslov <[e-mail]>]

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.