Valery Smyslov writes: > > 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.
We do have 3 ways proposed to the implementors how they can pick key if they want to implement them. Some of those will require configuration changes, some might require external changes, some requires using certain authentication methods. For example IDr, IDr does NOT HAVE to come from certificate it can also have mapping from IDr -> certificate subject key. The RFC4301 says ID is used to find the PAD entry. The PAD entry is then used to find the X.509 certificate and private key: ---------------------------------------------------------------------- 4.4.3.2. IKE Peer Authentication Data ... This document does not require that the IKE ID asserted by a peer be syntactically related to a specific field in an end entity certificate that is employed to authenticate the identity of that peer. However, it often will be appropriate to impose such a requirement, e.g., when a single entry represents a set of peers each of whom may have a distinct SPD entry. ... ---------------------------------------------------------------------- > > 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. This is implementation issue anyways. The implementations do have information (IDr, CERTREQ, AUTH payload algoritm other end sent, PAD entry, IP address etc) and then the implementation will pick the private key to be used and the associated certificate. I do not want to make this even more complex by adding yet another way to send the same information. I assume you problem is that implementations you are thinking of, are too limited in the way they can express the IDr -> PAD -> private key -> certificate mapping, and thats why you think that solution is not suitable. That does not have to be that way, as the RFC4301 already allows all kind of things there, and there is nothing for allowing implementations to implement that kind of code. The fact that current implementations do not do that, is most likely because implementors have not felt it would be important enough feature for them to implement. This document will require changes in the implementation anyways, so those implementors who feel this situation is common enough to require special coding can implement the IDr processing in their code... -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
