Pekka Riikonen writes: > : The EC group is assumed to be known from the certificate or raw key, > : and there is no need to explicitly negotiate or identify it. > : > It must be specified explicitly how this information can be retrieved from > different certs.
I would expect it to be completely obvious if you are already able to get the public key out from the certificate or from the raw key. I mean if you are able to find the public key, part of that public key does include the EC group to be used. I do not think we need to add very explicit instructions for this, but just say that as the CERT payload (either X.509 or raw key) contains the public key, and that public keys is required anyways to verify the AUTH payload, it is assumed that implemenations know how to parse that and get the EC group from there. > : This new method will be negotiated using the Notify Payloads in the > : IKE_SA_INIT, and those same payloads can be used to indicate the > : supported hash algoritms. > : > Why is the notify needed? Why can't the new method be like old > methods? If remote doesn't support the new authentication method, > authentication will fail. If it doesn't support the algorithm in the > OID, authentication will fail. Why does the hash algorithm have to > be negotiated? Why the extra complexity? And peer will indicate that > it supports the new method simply by using that method in the Auth > payload. What's the use case I'm missing here? I would be happy to just use notifications without hash algorithms, and assume that peer can properly guess which hash should work with the other end. This is how it is done in old methods, but other people considered as we are now getting more usable hash algoritms (sha-3), there might be more and more problems with this, and solving this problem now before it is really an issue is better. Currently if you want to make sure the hash is acceptable, you select SHA-1. If you do not want to use SHA-1 and want something stronger, you will then most likely use SHA-256 or similar. But if you want to prefer SHA-256, but still allow SHA-1 just in case the remote peer does not support it, this not something you can easily do now. You can make one IKE SA negotiation with SHA-256 and then when it fails, try again with SHA-1, but that is quite costly operation. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
