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? > > 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 explictly define what hash function needs to be used with RSA. > 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: 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. 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 to give some kind of implementation guidelines to the hash algorithm selection, or we might even define a way to specify it. > > I have been under impression that the point compression is one of > > those items which are patented and that is the reason why it is not > > This is not an issue. According to > http://cr.yp.to/patents/us/6141420.html the patent is almost > certainly invalid because its authors revealed the (known) existence > of prior art to the patent office, and furthermore, the patent > expires in 2014. We cannot really say whether some patent is invalid or not, but on the other hand saying it will expire 2014 is something that will help... > > > been used in the IKEv2. Also as I said earlier the authentication > > methods are not negotiated, thus if one ends send KE payload in point > > compressed format and other end does not implement point compression > > because of licensing reasons they cannot talk to each other. > > > > I am not talking about authentication but about key exchange. For > authentication, no point compression can be applied, as an ECDSA > signature dies not represent a point on the curve but only to > integers (mod the group order). Ah, good. > But I admit that there might be an issue when an implementation not > supporting point compression receives a KE payload of unexpected > length. This might lead to undesired behavior. Thus, it might be > necessary to use separate group descriptions when using point > compression. But I have not sufficient experience with > implementations to assess that. With Diffie-Hellman groups things are easier, as they are negotiated in the IKEv2, and if someone send KE payload which other end does not support (i.e. uses point compression) but also proposes same group without point compression, the receiver can send INVALID_KE_PAYLOAD and tell the other end to fall back to common group. So to support point compression we can allocate allocate separate groups for compressed and non-compressed uses. I am not sure whether that is best option, but that is something we can look at on item 1 above in the WG. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
