> Hmm... so the EC domain parameters can be seen from the certificate? I > wonder why did the RFC4753 then made separate allocations for each EC > group?
As I wrote to Dan, there is actually also the option of not specifying the parameters in the cert, but this method (implicitCurve) is supposed to be used only if the parameters are known to the other pier by other means (e.g. by local configuration) > >>> I think we should have made the ECDSA support for IKEv2 in such way >>> that we had added some subfields to the authentication field, i.e. >>> only allocated one value for ECDSA and put the curve number inside the >>> authentication payload and perhaps even separated the hash algorithm >>> from it. There is 3 bytes of reserved data in the authentication >>> payload immediately after the auth method. Perhaps we could use those. >> >> Adding hash algorithm flexibility is of course a more general topic >> concerning not only ECDSA but also RSA and DSA. This is out-of-scope >> of our endeavor and should be discussed separately. > > We already have this same problem in the RSA, and we do assume that it > is not a problem in real life. I.e. every implementation will use hash > algorithm that is supported by other end. I.e. if some impementation > is SHA-1 only then certificates are also SHA-1 only and everybody uses > SHA-1, and if certificates uses SHA-2, then everybody using those > certificates do support both SHA-1 and SHA-2, and it does not really > matter which hash function is used... This is the reason why we do not Even if the pier supports both SHA-1 and all SHA-2 functions, it would require try-and-error to find out which one was used for the signature. Maybe in most cases the tier uses the same hash function as the CA, but this does not need to be the case. I know of large-scale PKIs, where the CAs use longer hash functions than the end entities. This can be motivated by the (indisputably) higher security requirements for CAs than for end users. >> You touch the same point as Yoav, who pointed out that a generalized >> authentication method (e.g. ECDSA_generic) would imply that the same >> certificate (for a key pair using one of the NIST curves listed in >> RFC 4754) could be used ith two different authentication methods. >> Yoav has suggested to indicate support for the general method in the >> Notify payload, another option could be to introduce a new transform >> type AUTH, so that support for this AUTH method is indicated in the >> SA payload. Again, this is a protocol extension that exceeds our >> intended scope, and should be specified separately. >> >> An alternative to avoid the interoperability problems with existing >> implementations of RFC 4754 could be to require that ECDSA_generic >> MUST not be used for the curves listed in RFC 4754, or that >> implementations encountering authentication failures by the other >> peer MUST re-try using the "old" authentication methods from RFC >> 4754. > > I think the way forward is to take this WG and as whether WG would be > willing to recharter and add new items to its charter: Accidentally, I included by response to this in my reply to Dan. For completeness, I will repeat it here. > > 1) Add Brainpool curves to the IKEv2 IANA registry (this can also be > done as individual draft, and does not need to be WG item, but if > we are doing the rest in WG then I think this should also be WG > item too). I am not sure. If the rest is not specific for the Brainpool curves (e.g. defining a generic ECDSA auth method) it is not so clear that both efforts should be bundled. > 2) Define a way to use Brainpool curves in ECDSA (and perhaps ECGDSA) > in the IKEv2. This may require new standard track RFC defining new > generic ECDSA method, and might also need solutions how hash > function is selected for each group. > According to the policy of the IANA registry for ath methods, standard track is not required but only IETF consensus, i.e. an informational WG document would suffice. > Then we can start thinking in the WG what would be the best way to > solve those problems. I think the correct solution would be to make > new ECDSA_generic method and specify where the domain parameters come > (both with certificates and with raw public keys), and we might want >From a cryptographic point of view, the correctness (and hence, the integrity >and authenticity) of the domain parameters is crucial, it is not a restriction to require that, if a raw (trusted) EC public key is used, the parameters must also be available by trusted means (e.g. local configuration). Johannes _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
