Subject: [IPsec] ECDSA in IKEv2

From: Yaron Sheffer <[email-masked]>
Date: Tue, 24 Jul 2012 19:08:26 +0300

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

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 24 Jul 2012 10:43:35 -0700 (PDT)

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:
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

---

From: Yoav Nir <[email-masked]>
Date: Tue, 24 Jul 2012 21:04:38 +0300

Hi Yaron

I would like to participate.

A few comments on the proposed "charter":

 - Flexibility in associating hash functions should not a unlimited. There is no reason to allow a 521-bit EC group with MD4 as the hash function, or even with SHA2-256 as the hash function. I'm perfectly happy to limit that curve to SHA2-512 and SHA3-512.

 - I don't think "ECDSA" as opposed to "ECGDSA" or "DSA" or "RSA" should be an authentication method. It seems much more intuitive to me to expand that to "certificate authentication" or "public key signatures". The user gets a certificate by some method, installs it on their IKE endpoint, and then proceeds to use it. The public key in the certificate is suitable for verifying one or more kinds of signature, so it does influence the content of the AUTH payloads, but whatever kind of certificate you use, the method IMO should be the same. Since we're taking the public key from a SPKI structure in a certificate anyway (or from Tero's OOB draft that uses the same SPKI structure), the type of signature possible is already determined. Or if there is more than one possibility (as in ECDSA and ECGDSA) this can be signaled in the same way as the hash algorithm.

Yoav

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 24 Jul 2012 21:28:06 +0300

Hi Yoav,

please see below.

Thanks,
	Yaron

>   - Flexibility in associating hash functions should not a unlimited. There is no reason to allow a 521-bit EC group with MD4 as the hash function, or even with SHA2-256 as the hash function. I'm p…

This is for the group to decide, of course. Personally I'm fine with a 
fully flexible or with a somewhat flexible solution. But not with a 
solution where we invent a mapping from curve to hash, and the next 
curve to come along disproves our theory.
>   - I don't think "ECDSA" as opposed to "ECGDSA" or "DSA" or "RSA" should be an authentication method. It seems much more intuitive to me to expand that to "certificate authentication" or "public k…

I would agree if we were designing a new protocol. In this case, we are 
solving a problem and I'd like to focus on it. I am sure modular DSA or 
RSA have their own challenges, and I see no reason to tackle these 
challenges, seeing that the existing solutions work just fine.

As to ECGDSA, I would prefer to leave it out for now. My feeling is that 
its constituency is too small to justify the effort. Plus, it can be 
tacked on later as an Informational RFC.

---

From: "Dan Harkins" <[email-masked]>
Date: Tue, 24 Jul 2012 11:52:06 -0700 (PDT)

On Tue, July 24, 2012 11:04 am, Yoav Nir wrote:
>  - Flexibility in associating hash functions should not a unlimited. There
> is no reason to allow a 521-bit EC group with MD4 as the hash function,
> or even with SHA2-256 as the hash function. I'm perfectly happy to limit
> that curve to SHA2-512 and SHA3-512.

  There is no reason to "allow" the 768-bit FFC group to be used to
generate a shared secret that is to be authenticated with an ECDSA
signature with a 521-bit curve and have SHA-1 be used as the key
derivation function either, but such a thing is permissible and it
will be permissible in IKEv2 even if we were to prohibit the use of
SHA-256 with a 521-bit curve.

  Any attempt to enforce coherent use of primitives-- e.g. define
what primitives are valid for different security levels, or what certain
combinations of primitives are permissible and what are forbidden--
should only be  done as part of an IKEv3.

  Dan.

---

From: "David McGrew (mcgrew)" <[email-masked]>
Date: Tue, 24 Jul 2012 20:15:29 +0000

Hi Yaron,

>- Supports currently used and proposed ECDSA certificates.

Has there been a formal proposal for new ECDSA certificates?   Or do you
mean the informal idea of using different elliptic curve parameters inside
ECDSA?    The latter suggestion is something that needs to be reviewed,
and if it goes forward, would need to be well specified.   (Thanks to Dan
Brown for offering to help with this analysis.)

"Supports other protocols than IKEv2" is another desirable property.  If
there is interest in ECDSA with other curves in IKEv2, then it is likely
that there will be interest in other protocols such as TLS and SMIME.   To
avoid parallel and potentially divergent solutions for other protocols, it
makes sense to consider extensions to ECDSA and its certificate format.

>- Allows flexibility in associating hash functions with EC groups.

I do not think that flexibility in hash/curve pairs is desirable (though
it might be acceptable if there is well written guidance on which pairs to
use).  If the number of signature parameters is significantly larger than
256, as suggested below, then there are enough numbers to go around that
we can assign every hash/curve pair that we care about its own number.

>unless it is trivially supported by the proposal.

Another requirement: the solution should work with certificate chains,
without requiring that all certificates in the chain have the exact same
signature algorithm and parameters.

>
>The solution should be an extension to IKEv2,

Why should this be a requirement?   It is something of a layer violation
to require the protocol to provide the information about how to process
the signatures in the certificates that it carries.

>and should not break the

David

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 24 Jul 2012 23:51:50 +0300

Hi David,

please see my responses below.

Thanks,
     Yaron

> Brown for offering to help with this analysis.)
Sorry about the sloppy language. I meant the latter: the use of 
certificates based on different EC domain parameters.

But I'm certainly not suggesting that we should define the certificate, 
or that we should extend the ECDSA algorithm. The scope is very strictly 
limited to IKEv2 use of ECDSA certs specified elsewhere.
> makes sense to consider extensions to ECDSA and its certificate format.
I strongly disagree on this point. The is a short-term effort to solve a 
problem related to IKEv2. I'm not advocating diverging from TLS on 
purpose. But I'm not out to solve a problem for all of the IETF protocols.
> we can assign every hash/curve pair that we care about its own number.
I'll be happy to see such guidance coming from CFRG. I doubt that we 
have the relevant expertise in ipsecme to formulate or review this 
"pairing". If we have "enough numbers to go around" we can have all the 
useful pairs and there will also be some silly pairs, and it's not 
reasonable to try to outlaw the silly ones in advance.
> signature algorithm and parameters.
I'm not disagreeing but I think that in the context of IKEv2 (and other 
protocols), the only thing that touches the protocol is the end-entity 
certificate. So we don't care about the rest of the chain.
> the signatures in the certificates that it carries.
The existing protocol indicates how to generate the AUTH payload based 
on the public key that's provided by the certificate. So it's not about 
"processing the signatures in the certs", it's about "using the cert to 
sign other stuff".

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 24 Jul 2012 14:00:32 -0700

On Jul 24, 2012, at 1:15 PM, David McGrew (mcgrew) wrote:

> and if it goes forward, would need to be well specified.

It is the latter, and that's exactly why having the output of a design team would be useful.

> "Supports other protocols than IKEv2" is another desirable property.  

Not for this work, no. Maybe that would be appropriate for CFRG or SAAG, but not the IPsecME WG.

> If
> that there will be interest in other protocols such as TLS and SMIME.   

There are already specifications from those WGs.

> To

Of course.

> use).  

Others might disagree. For example, NIST seems to be of multiple minds when they are choosing strengths.

> If the number of signature parameters is significantly larger than

One thing that the design team needs to consider is the amount of flexibility. Note that the proposal says "allows flexibility", not "forces maximal flexibility".

> signature algorithm and parameters.

Good suggestion, yes.

> the signatures in the certificates that it carries.

If you have other concrete proposals, that would be grand. There has been enough disagreement in the thread this last week where it is likely that there are multiple ways to do things.

--Paul Hoffman

---

From: Johannes Merkle <[email-masked]>
Date: Wed, 25 Jul 2012 18:47:52 +0200

> 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.

I would also like to participate. Though I am not an expert in IKEv2, I hope that my background on PKI standards and
crypto can help.

> - Allows flexibility in associating hash functions with EC groups.
I is certainly not bad if the proposed solution could be trivially applied to (non-EC) DSA as well. I understand that
this is not a requirement that fits in here but it is a nice-to-have.

> - Is not limited to 256 values
Does this requirement also apply to the hash functions if we are going to define separate code points for these?

Johannes

---

From: Yaron Sheffer <[email-masked]>
Date: Wed, 25 Jul 2012 20:14:56 +0300

Hi Johannes,

re: your last point, I think not. IMHO 256 values would be sufficient 
for the hash functions, if defined separately (though I would prefer 16 
bits, of course).

Thanks,
	Yaron

---

From: Tero Kivinen <[email-masked]>
Date: Thu, 26 Jul 2012 16:33:32 +0300

> unless it is trivially supported by the proposal.

I would also like to solve the problem with non-EC DSA. 

> used as a starting point.

Actually I think adding the signatureAlgorithm from the PKIX 4.1.1.2
to be included in the Authentication data inside the new
authentication method as proposed in my email today to the list would
be even better, but this is something that should be discussed in the
design team.

-- 
[email-masked]