Subject: [IPsec] ECDSA for IKEv2

From: Paul Hoffman <[email-masked]>
Date: Fri, 2 Nov 2012 11:27:53 -0700

Greetings again. Here is the long-sought-after consensus report from the design team that was tasked with a proposal for better supporting ECDSA certificates in IKEv2.

If you have any concern for this topic, please read the proposal below and send comments to the list.

Thank you to the design team (Tero Kivinen, Johannes Merkle, Dan Harkins, Yoav Nir, David McGrew) for their efforts.

--Paul Hoffman

The design team decided it is best to add just one new authentication
method, that will support all kinds of signature methods. This
includes all ECDSA and other EC-based methods (ECGDSA) and can also
support other algorithms too (RSA-PSS or even ElGamal).

The EC group is assumed to be known from the certificate or raw key,
and there is no need to explicitly negotiate or identify it.

The Authentication Data field in the Authetication Payload will
contain the signature algorithm OID (sha1WithRSAEncryption,
dsa-with-sha1, dsa-with-sha256, ecdsa-with-SHA1, ecdsa-with-SHA256
etc) and the actual signature.

The design group considered adding full AlgorithmIdentifier ASN.1 blob
too big and as the other information (EC group etc) is already known
from the certificate or raw key, the only thing needed here is the
actual signature algorithm and hash OID. To make skipping the OID
easier it is prefixed with 8-bit length field (even though the ASN.1
encoding of the OID has length of oid value in 2nd byte).

To select suitable hash function for each EC-group we should refer to
the existing guidance (SEC1 and RFC5639), and specify that the method
of X9.62, SEC1 and IO 14888-3 MUST be used for hash truncation. We can
add some non-normative guidance also in the draft for "common" curves.

This new method will be negotiated using the Notify Payloads in the
IKE_SA_INIT, and those same payloads can be used to indicate the
supported hash algoritms.

The old EC-DSA method should be deprecated, but only after the new
methods are supported, meaning the document should say that if new
method is supported by both ends it SHOULD/MUST be used.

----------------------------------------------------------------------
The Authentication Paylod will look like this:

                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Next Payload  |C|  RESERVED   |         Payload Length        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Auth Method   |                RESERVED                       |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  ~                      Authentication Data                      ~
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 14:  Authentication Payload Format

  o  Auth Method (1 octet) - Specifies the method of authentication
     used.  

  Mechanism                              Value
  -----------------------------------------------------------------
  Digital Signature                      <TBD>
     Computed as specified in Section 2.15 of RFC5996 using a private
     key associated with the public key sent in certificate payload,
     and using one of the hash algoritms sent by the other end in the
     SIGNATURE_HASH_ALGORITHMS notify payload. If both ends send and
     receive SIGNATURE_HASH_ALGORITHMS and signature authentication
     is to be used, then this method MUST be used. The Authentication
     Data field has different format than in other Authentication
     methods (see below).

  o  Authentication Data (variable length) - see Section 2.15 of
     RFC5996. For "Digital Signature" format the Authentication data
     contains special format as follows:

                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | OID Length    | OID (0x06)    . OID value len . OID value     |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  ~                      OID value continuing                     ~
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  ~                      Authentication Data                      ~
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Where the OID Length is the length of the ASN.1 encoded OID
      value, and after that is the actual Signature Algorithm OID
      followed by the actual signature value. There is no padding
      between OID and signature value. ASN.1 encoded OIDs always
      start with byte of 0x06 followed by the length of the actual
      OID value (which is shown in the figure abow).

----------------------------------------------------------------------

The method is negotiated by sending and receiving
SIGNATURE_HASH_ALGORITHMS Notify payload:

                       1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  | Next Payload  |C|  RESERVED   |         Payload Length        |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |  Protocol ID  |   SPI Size    |      Notify Message Type      |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  ~                Security Parameter Index (SPI)                 ~
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |                                                               |
  ~                       Notification Data                       ~
  |                                                               |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

The Protocol ID is 0, SPI Size 0, and Notify Message Type <TBD from
status types>. The Notification Data value contains list of 16-bit
hash algorithm identifiers from the newly created Hash Algorithm
Identifiers for the IKEv2 IANA registry.

Sending this notification tells that new "Digital Signature"
authentication method is supported and that following hash functions
are supported by sending peer. Both ends sends their list of supported
hash-algorithms and when calculating signature a peer MUST pick one
algorithm sent by the other peer. Note, that different algorithms can
be used in different directions. The actual algoritm used when
calculating the signature is sent inside the Authentication Data field
of the Authentication Payload.

---

From: Sean Turner <[email-masked]>
Date: Sun, 04 Nov 2012 11:26:05 -0500

> Thank you to the design team (Tero Kivinen, Johannes Merkle, Dan Harkins, Yoav Nir, David McGrew) for their efforts.

I'd like to echo the thanks.

> and there is no need to explicitly negotiate or identify it.

For the certificate case, I assume this means the draft will follow 
what's in the RFC 5480 wrt the SPKI AlgorithmIdentifier - i.e., the 
curve is always named by the OID.

Aside: For RSA-PSS parameters don't always appear in the SPKI 
AlgorithmIdentifier field - see RFC 5756.

> add some non-normative guidance also in the draft for "common" curves.

RFC 5480 which has some recommendations about this topic and is probably 
a better reference than RFC 5639 (one is IETF stream one is ISE stream). 
  It's basically the same recommendations, but RFC 5480 narrows the 
curve/hash algorithm recommendations more.  I want to avoid as many 
downrefs as possible.

> supported hash algoritms.

A new registry I assume? (yep after reading farther down it's listed).

> method is supported by both ends it SHOULD/MUST be used.

Make sure the draft indicates it updates RFC 5996.

In the examples above, *WithRSAEncryption and dsa-with-* are listed so 
are we really talking about deprecating all of the previous "signature" 
values from the IANA registry:

V  Alg                                   Ref
--------------------------------------------------
1  RSA Digital Signature                 [RFC5996]
3  DSS Digital Signature                 [RFC5996]
9  ECDSA with SHA-256 on the P-256 curve [RFC4754]
10 ECDSA with SHA-384 on the P-384 curve [RFC4754]
11 ECDSA with SHA-512 on the P-521 curve [RFC4754]

Assuming here that this new notify is normally sent during the 
IKE_SA_INIT exchange from the responder to the initiator:

a) The initiator actually figures out the signature algorithms supported 
by the responder based on the new Notify message, Alg ID parameter, and 
the cert's key usage extension?  The SPKI will include id-ecPublicKey 
not ecdsa-with-* right so you can't rely on that.  You can't rely on 
just the Alg ID parameter because the key usage extension can have any 
combination of digitalSignature, nonRepudiation, and keyAgreement set. 
So don't you have to look at all three?

Note: This approach ought to work for DSA to because they indicate the 
id-dsa and you'll also have the new hash value.  RSA is going to have 
the same problem as EC algs though because the parameters are NULL and 
the key usage might just be set to keyTransport.

b) I guess the question I have is whether inclusion of this notify means 
that the entity only supports the new way?  That is in the above is it:

Sending this notification tells that new "Digital Signature" 
authentication method is supported and that following hash function are 
supported by sending peer.

or

Sending this notification tells that new "Digital Signature" 
authentication method is *also* supported and that following hash 
functions are supported by sending peer.

If the initiator doesn't support it, then it just fails straight off? 
How would we transition?

spt

---

From: Pekka Riikonen <[email-masked]>
Date: Mon, 5 Nov 2012 08:22:09 +0100 (CET)

On Fri, 2 Nov 2012, Paul Hoffman wrote:

: The design team decided it is best to add just one new authentication
: method, that will support all kinds of signature methods. This
: includes all ECDSA and other EC-based methods (ECGDSA) and can also
: support other algorithms too (RSA-PSS or even ElGamal).
: 
Good, that's better than having per-auth method ids.

: The EC group is assumed to be known from the certificate or raw key,
: and there is no need to explicitly negotiate or identify it.
: 
It must be specified explicitly how this information can be retrieved from 
different certs.

: This new method will be negotiated using the Notify Payloads in the
: IKE_SA_INIT, and those same payloads can be used to indicate the
: supported hash algoritms.
: 
Why is the notify needed?  Why can't the new method be like old methods?  
If remote doesn't support the new authentication method, authentication 
will fail.  If it doesn't support the algorithm in the OID, authentication 
will fail.  Why does the hash algorithm have to be negotiated?  Why the 
extra complexity?  And peer will indicate that it supports the new method 
simply by using that method in the Auth payload.  What's the use case I'm 
missing here?

	Pekka

---

From: Johannes Merkle <[email-masked]>
Date: Mon, 05 Nov 2012 13:25:33 +0100

Sean,

> For the certificate case, I assume this means the draft will follow what's in the RFC 5480 wrt the SPKI
> AlgorithmIdentifier - i.e., the curve is always named by the OID.

Yes, although it would also work with specifiedCurve which is deprecated in RFC 5480.

> 
> Aside: For RSA-PSS parameters don't always appear in the SPKI AlgorithmIdentifier field - see RFC 5756.
> 

RSA-PSS has certainly not been in the focus of our design, but only a side-product. Thus, we have tried support it only
as far as possible *without extending the mechanisms*. For this reason, only RSA-PSS SPKI AlgorithmIdentifiers with
parameters specified (either explicit or by using the defaults) are supported. Adding a means to signal RSA-PSS
parameters in IKEv2 would have introduced considerable complexity.

> In the examples above, *WithRSAEncryption and dsa-with-* are listed so are we really talking about deprecating all of
> the previous "signature" values from the IANA registry:
> 
> V  Alg                                   Ref

The design team decided to deprecate DSS in case that the new method is supported. There was no decision (or even
discussion) on whether to deprecate RSA Digital Signature. This is still to be discussed.

> Assuming here that this new notify is normally sent during the IKE_SA_INIT exchange from the responder to the initiator:
> 
> a) The initiator actually figures out the signature algorithms supported by the responder based on the new Notify
> message, Alg ID parameter, and the cert's key usage extension?  The SPKI will include id-ecPublicKey not ecdsa-with-*
> right so you can't rely on that.  You can't rely on just the Alg ID parameter because the key usage extension can have
> any combination of digitalSignature, nonRepudiation, and keyAgreement set. So don't you have to look at all three?
> 

I am not sure I get your point regarding the key usage extension. As we talk about authentication through digital
signatures, I guess that digitalSignature MUST be set in the KE extension anyway.

You correctly point out a limitation of the negotiation mechanism (through the notify payload) to the hash algorithm.
Negotiation of the signature algorithm was not considered as the focus was on the digital signature algorithms currently
supported in IKEv2, i.e. ECDSA, DSA and RSA. EC-based signature schemes other than ECDSA are hardly used in practice and
RFC 5480 does not list any. If someone desires to use Nyberg-Rueppel, EC-ElGamal or EC-Schnorr signatures, she can do so
but without negotiation.

Do you advocate a negotiation of the signature algorithm?

Note: ECGDSA keys (which are actually used for IKE in Germany) are not specified by id-ecPublicKe but by a dedicated OID
ecgPublicKey as the relation between private and public key differs from ECDSA keys.

-- 
Johannes

---

From: Johannes Merkle <[email-masked]>
Date: Mon, 05 Nov 2012 13:44:07 +0100

Pekka,

> simply by using that method in the Auth payload.  What's the use case I'm 

I think we have to distinguish two aspects: negotiation of the general auth method (old or new) and negotiation of the
hash algorithm.

Regarding the negotiation of the hash algorithm: If there is no intersection between the sets of hash algorithms
supported by the peers, failure is inevitable. But in case that there is an intersection, the negotiation allows to
agree on it.

-- 
Johannes

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 5 Nov 2012 21:02:26 +0200

> It must be specified explicitly how this information can be retrieved from 

I would expect it to be completely obvious if you are already able to
get the public key out from the certificate or from the raw key. I
mean if you are able to find the public key, part of that public key
does include the EC group to be used.

I do not think we need to add very explicit instructions for this, but
just say that as the CERT payload (either X.509 or raw key) contains
the public key, and that public keys is required anyways to verify the
AUTH payload, it is assumed that implemenations know how to parse that
and get the EC group from there. 

> Why is the notify needed? Why can't the new method be like old
> methods? If remote doesn't support the new authentication method,
> authentication will fail. If it doesn't support the algorithm in the
> OID, authentication will fail. Why does the hash algorithm have to
> be negotiated? Why the extra complexity? And peer will indicate that
> it supports the new method simply by using that method in the Auth
> payload. What's the use case I'm missing here?

I would be happy to just use notifications without hash algorithms,
and assume that peer can properly guess which hash should work with
the other end. This is how it is done in old methods, but other people
considered as we are now getting more usable hash algoritms (sha-3),
there might be more and more problems with this, and solving this
problem now before it is really an issue is better.

Currently if you want to make sure the hash is acceptable, you select
SHA-1. If you do not want to use SHA-1 and want something stronger,
you will then most likely use SHA-256 or similar. But if you want to
prefer SHA-256, but still allow SHA-1 just in case the remote peer
does not support it, this not something you can easily do now. You can
make one IKE SA negotiation with SHA-256 and then when it fails, try
again with SHA-1, but that is quite costly operation. 
-- 
[email-masked]