On Sat, July 21, 2012 8:56 am, Tero Kivinen wrote: > Johannes Merkle writes: >> > Adding them for authentication use (ECDSA use) will most likely get >> > more opposition. First of all, I am not at all happy how the ECDSA >> > groups are added to the IKEv2 authentication method. The >> > authentication methods registry is only 8-bit in IKEv2 (it is 16-bit >> > registry in IKEv1). This does not matter if we have only few ECDSA >> > groups with one hash algorithm for each, but when we are adding more >> > groups it seems to bad idea for each of them having separate number. >> > Especially if someone later decides that they want to use all ECDSA >> > groups with SHA 3 too... >> >> Today, I responded to Yoav's idea of taking algorithms details from >> the certificate. At least the EC domain parameters could be taken >> from it, and for the hash function, a default could be defined per >> curve. So one new authentication method ECDSA_generic or >> ECDSA_cert_defined could be sued for any EC domain parameters. > > 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?
The particular curve can be determined from the subjectPublicKeyInfo. Section 4.1 of RFC 5639 gives the ASN.1 encodings to name the brainpool curves. I'm not so sure it makes sense to define a new hash algorithm per curve though. I would suggest just using the negotiated hash function. That is going to be used for key derivation and will influence the level of security that the exchange affords. That is, if you define SHA-384 to use with brainpoolP384r1 but the two sides end up using SHA-1 for key derivation then I'm not sure what using SHA-384 for authentication is buying you. [snip] > > 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: > > 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). > 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. If we're gonna recharter, maybe we should just work on an IKEv3 because the problems in IKEv2 are becoming apparent. This "new authentication mode" suggestion, or the need for a "generic ECDSA" algorithm are just hacks that should not be necessary for a properly defined protocol. In addition, the issues with the incorrect definition of representation of the result of an ECDH (it's the x-coordinate, not the concatenation of the x- and y-coordinates) that's lead to interoperability issues, and the inability to handle point compression all lead one to the conclusion that this stuff should all be fixed once and for all and fixed cleanly. Dan. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
