Valery Smyslov writes: > >> > 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.
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. If you are not happy with CERTREQs doing that you can also use the IDr in the IKE_AUTH request to tell from the initiator which key should be used by the responder. > 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. > 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). > 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. 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. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
