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
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
