On Mon, July 23, 2012 4:31 am, Johannes Merkle wrote:
>>
>> 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.
>
> Actually, this is not strictly correct:
> ANSI X9.62 defies three ways to specify the curve (domain parameters) in a
> certificate (extracted from RFC 5480):
> ECParameters ::= CHOICE {
> namedCurve OBJECT IDENTIFIER
> implicitCurve NULL
> specifiedCurve SpecifiedECDomain
> }
> implicitCurve means that "the parameters are explicitly defined
> elsewhere".
>
> So we can safely assume that the parameters are available to a pier
> receiving the certificate of the other one.
>
>
> By the way: While RFC 5480 prohibits the use of implicitCurve and
> specifiedCurve, there are certainly still many
> implementations of RFC 3279 out there which allowed all three methods.
For a guy who's always reminding everyone about how there are many
implementations of an older RFC I should keep that in mind. Thank you
for pointing that out. But, as you note, RFC 5480 prohibits implicitCurve
and specificCurve so all we have left is namedCurve which is, as I noted,
how the particular curve can be determined from the subjectPublicKeyInfo.
>> 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
>
> I do not agree. The generic definition of the ECDSA auth method is
> analogous to the auth methods defined for RSA and DSA
> keys, and thus, is rather the proper (canonical) way to define it than a
> hack.
> Of course, the fact than there are already 3 specific auth methods for
> ECDSA (which are not canonically defined) makes
> specification of a generic ECDSA method more cumbersome.
With RSA the hash algorithm is encoded into the padding so there is
no real need to independently agree on a hash algorithm. For DSA,
I disagree. The DSA algorithm definition is hash-specific so the hash-
specific ECDSA auth methods are the canonical way. Let me point
out, though, that canon law is not necessarily correct and this is an
example.
FIPS 186-3 (The Digital Signature Algorithm) specifies that security
strength levels of DSA are a minimum of the security strength of the
hash algorithm and the (L,N) pair from the domain parameter set. If
one wished to achieve a security strength level with DSA that would
be valid, according to NIST, "beyond 2030" one would need to use
SHA-512 but IKEv2 only uses SHA-1 with "DSS Digital Signature"
(authentication method value of 3) so that wouldn't work.
Given that SP 800-57 requires that 80 bits of strength only be used
through 2010 (and SHA-1 does not provide more than that) and it
is now 2012 it appears that IKEv2 is not capable of producing a
signature of sufficient strength for certain customers (they might not
be your's but they do exist, and there's probably more of them than
there are people clamoring for AES-XCBC MAC).
So to actually address this in the hash-specific canonical way
requires new auth methods for different permutations of DSS with
SHA-224, SHA-256, SHA-384, and SHA-512 as well as different
permutations of ECDSA with brainpool curves using the 5 different
SHA varients. But this is getting, as you say, "cumbersome".
Of course one can decide not to use the hash-specific canonical
technique and come up with "generic DSA" and "generic ECDSA" to
address this but then we have the unfortunate state of hash-specific
(EC)DSA methods and "generic" methods and now it's getting ugly
(and hack-ish).
Instead of either negotiating a complete ciphersuite (the way TLS
does) or individual components (the way IKEv1 did), IKEv2 does both
and gets the worst of both worlds.
Dan.
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
