Hello,
I would like to participate. The problem I see is that the selection of
the hash algorithm has to be decoupled from the indication of the
authentication method. So I propose the following:
1. Determining the Domain Parameter Set
The curve SHALL be identified by name in the subjectPublicKeyInfo
of the certificate or raw public key.
2. Determining the hash algorithm
Use some of the RESERVED bits of the AUTH payload to
define a "hash algorithm." I propose using 16 bits and making
it align for shorts so use bits 16-31 and leave 8-15 as
RESERVED.
Then we should specify that the value of "hash algorithm"
SHALL be zero except for the following new Auth Method:
13: Elliptic Curve Digital Signature Algorithm
and the value of "hash algorithm" will come out of a new registry
created by IANA whose initial population will be:
- 1 : SHA-1
- 2 : SHA-224
- 3 : SHA-256
- 4 : SHA-384
- 5 : SHA-512
This has a number of benefits:
- it will work for raw public keys (as Tero is proposing) as well
as certified ECDSA keys.
- it will allow for growth too because when SHA-3 algorithms get
defined they can just further populate the new registry and we
can unambiguously identify the hash algorithm regardless of the
expected digest size or the curve.
- we can support more of the FIPS 186-3 options where a hash
producing a larger digest than the curve's prime is being used.
- it doesn't consume a scarce resource unnecessarily.
- the same approach could be used to fix non-EC DSA which I
believe is still broken (just define another "generic DSA" auth
method and use the hash registry this proposal creates).
There remains an open question about what to do with the existing
ECDSA curves and I suggest nothing. There will technically be two
ways to do a NIST P256 signature using SHA-256 (ditto for 384/384
and 521/512). No big deal.
Dan.
On Tue, July 24, 2012 9:08 am, Yaron Sheffer wrote:
> Hi,
> recent discussion on the list has indicated that there is some interest
> in better supporting ECDSA certificates in IKEv2, and that the existing
> solutions are not very extensible. The discussion was very useful in
> outlining the existing issues and pointing to some possible ways forward.
>
> Paul and I would like to propose setting up a design team with the goal
> of proposing a long-term solution to this problem. Some of the
> attributes of a reasonable solution include:
>
> - Supports currently used and proposed ECDSA certificates.
> - Allows flexibility in defining EC domain parameters.
> - Allows flexibility in associating hash functions with EC groups.
> - Is not limited to 256 values
> - ECDH is out of scope.
> - Non-certificate authentication using raw public keys is out of scope,
> unless it is trivially supported by the proposal.
>
> The solution should be an extension to IKEv2, and should not break the
> protocol. Some of the ideas in
> http://www.ietf.org/mail-archive/web/ipsec/current/msg07828.html can be
> used as a starting point.
>
> Please respond to us privately or to the list, indicating if you would
> like to participate in the design team, or if you only support the
> effort and would be willing to review the ensuing I-D.
>
> Thanks,
> Yaron
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
