> And you can always retry when you notice that you get authentication
> error after using private key, provided you have multiple types of
> keys.
In general you can't if it is responder who selected wrong key.
That is something I realized on our way home, but it is easy to fix.
We add suggestion to the draft that the responder should use same type
of key than what initiator used.
That will not work in case of EAP.
I admit, that such situations are rare but not non-existent.
And manual configuration is not an option for large VPNs.
Large VPNs should use centralized management systems anyways, and all
of this is also avoidable by using suitable sub CA keys. You do not
need to change the root CA, it is enough to change the sub CA used to
signing the EE cert, and send CERTREQ containg that key instead.
Usually corporate CA infrastructure is used not only for IPsec,
and changing CA hierarchy will influence other services too.
Sometimes it is unacceptable.
Retry is not always possible and is a hack anyway.
For initiator it is possiblity, for responder adding the text which
says it should use same algoritm than other end will solve the issue.
I do not think it as a hack, we already do that in IKEv2 with
Diffie-Hellman group negotiation. On the other hand we do not want to
complicate the IKEv2 more by making the retry inside the exchange like
we do with INVALID_KE_PAYLOAD, but we could add new error notify that
the responder can send which says INVALID_AUTH_KEY_TYPE, and we could
even add supported key types in that notify. Or we can simply use the
It is a good idea, but it will not work in case of EAP. If responder picks
a wrong key, then initiator may send this notification, but it will
require responder to keep this information somewhere untill
initiator retries (if ever). Or we neet to complicate IKE_AUTH
to make retry inside the exchange (as with INVALID_KE_PAYLOAD),
this way it might work. But in this case it is more complex, than just
announcing supported signature algorithms in IKE_SA_INIT.
AUTHENTICATION_FAILED notify and assume that it might have been
because of wrong key type, and as we do not have anything better to
do, we can simply retry. Nothing will go through the tunnel anyways
unless we do something...
Not this way, please. That is a real protocol hack, IMHO...
Valery.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
