On Jul 18, 2012, at 9:45 PM, Tero Kivinen wrote:

> Adding them to ECDSA is more difficult. Adding them for Diffie-Hellman
> use requires updating of one expert review 16-bit registry for IKEv2.
> The same registry in the IKEv1 is RFC required, so it does not require
> standard track RFC.
> 
> 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...
> 
> 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. 

How about standardizing just one more authentication method?

Call it "public key signature" or some such, and make the signing algorithm 
depend on the public key in the CERT payload.

If it's RSA, go by bit strength:
 - <=1024 - SHA-1 with RSA
 - 1024<x<=2048 - SHA2-256 with RSA
 - 2048<x<=4096 - SHA2-384 with RSA
 - >4096 - SHA2-512 with RSA

DSA - always SHA-1

ECDSA will be defined by curve. The three NIST curves that everyone uses 
already have hashes associated with them. Any new curve would have to specify 
the signature algorithm in the same document.

Since the same certificate can be used with both the old authentication method 
and the new, we'd have to signal support in a Notify, and that Notify could 
have bits for indicating support for other signature algorithms such as those 
that go with SHA3.

Wouldn't this make adding future curves and other signature variants easier?

Yoav

_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec

Reply via email to