On Jul 21, 2012, at 7:28 PM, Dan Harkins wrote: > > 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.
Not much, but not all PRF functions are hashes. What hash will you use if your PRF is AES-XCBC? What if it's GHash? Sure we could extend both those to be hash functions (just use AES-XCBC with a fixed key) but we've never done this before, and I don't have any idea if the cryptographers will approve. > [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. In 6 years IKEv2 has gained very little traction. All major vendors offer it, but it's still not the default setting for any of them. It would be as bad as saying that IPv6 has problems, so we should begin work on IPv8. Yoav _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
