> 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.
True, so in that case the Initiator needs to use proper CERTREQ or IDr
payload to indicate to which responder key he wants other end to pick.
We already discussed CERTREQ, it may not always be an indicator.
The same for IDr - IDs are supposed to remain the same with different keys.
Usually corporate CA infrastructure is used not only for IPsec,
and changing CA hierarchy will influence other services too.
Sometimes it is unacceptable.
So then use IDr. That is what it is meant for. I.e. for the initiator
to tell the responder which of multiple identities the responder has
it is connecting to. If responder has multiple keys with different
algorithms, you can configure each of them having different identity
and use that to separate them.
Identities are usually linked to certificate's Subject (or AltSubject)
field.
And those fields will most probably be the same with different key types.
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).
Yes, it only works if the initiator picked wrong key. On the other
hand as I pointed out there are already 3 ways for the responder to
pick right key (optional IDr in initiators IKE_AUTH request, CERTREQ,
and AUTH payload sent by the initiator).
And none of them looks good.
Or we just say it is local implementation issue, as I do not really
belive this will happen in real world that often. Or we just say that
implementations having multiple types of public keys SHOULD use
different IDr for each of the keys if there is any possibility that
initiators do not support all of the public key types.
Of course we can always leave it to implemetations by the cost
of lacking interoperability in such situations.
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
