Re: [IPsec] draft-fluhrer-qr-ikev2 AUTH issue

[Paul Wouters <[e-mail]>]

On Wed, 23 Aug 2017, Valery Smyslov wrote:

>> It is a good idea. A new optional notification that includes the auth_data as it would be calculated without the
>> PPK would work. With that, the corner case of ' PPK_id configured on initiator but missing on the responder' is
>> addressed. There is an additional cost of the extra notification message for every initiator that has no-
>> mandatory ppk configured for the responder.
>
> Yes, and there is also an extra cost for initiator of performing AUTH calculation (e.g. digital signature)
> twice - one with SK_p' and the other with SK_p. Good news are is that it is
> a) is performed by initiator only, so there is no risk of DoS attack on responder
> b) is needed only if initiator is configured in "permissive" mode - when its policy allows both PPK and non-PPK
>    SAs with the particular responder
>
>> In the worst case scenario the responder would need to go
>> through looking up the PPK_id and if that fails then authenticate the auth_data. Even though it is slightly
>> more work for the responder, I don't consider that heavy processing that would introduce attack concerns.
>
> Exactly.

This is a good idea. It solves our issue when both ends are configured
to initiate and/or respond, and one end is updated and the other isn't,
yet we don't know which endpoint will become initiator or responder.

The only thing I think we should double check with some cryptogrpahers,
is if this opens up any kind of quantum or classic attack. I don't think
it does, but it would be good to get confirmed.

> In general I think that if protocol allows more flexible operational conditions, then it is a good thing.
> If we add this feature, then it will be completely optional for both initiator and responder
> (neither initiator is required to send NO_PPK_AUTH, nor responder is required to understand it).
> So, if people strictly follow transition plan, then there is no much need in this feature.
> However, I suspect that in fields some folks may find these rules too restrictive under some circumstances.
> So we can add a bit more flexibility in the protocol for those folks for a relatively low cost.

Yes, one of the scenarios is the one where both endpoints are configured
to bring up the connection and you cannot predict which end will become
initiator or responder.

Paul