Subject: [Ipsec] Last Call: 'IKE and IKEv2 Authentication Using ECDSA' to Proposed Standard

From: The IESG <[email-masked]>
Date: Mon, 6 Feb 2006 16:09:54 -0800

The IESG has received a request from an individual submitter to consider the
following document:

- 'IKE and IKEv2 Authentication Using ECDSA '
    <draft-ietf-ipsec-ike-auth-ecdsa-05.txt> as a Proposed Standard

This document is an individual submission.  It was discussed in the
IPsec Working Group, but that working group was closed before reaching
consensus on this document.  Thus, it is not affiliated with any IETF
Working Group.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2006-03-06.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-auth-ecdsa-05.txt

_______________________________________________
IETF-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf-announce

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: [email-masked]
Date: Fri, 17 Feb 2006 17:05:55 +0200

Some last call comments about draft-ietf-ipsec-ike-auth-ecdsa-05:

1) First of all, it looks like properly reviewing (or implementing)
   this draft is quite difficult if you don't have X9.62. Too bad
   it's not free (as in beer)...

2) References: The reference to X9.62 should be updated to 
   X9.62-2005 (which was approved in November; i.e., after this 
   Internet-Draft was published).

3) Section 3: "signature consisting [..] of a pair of integers s 
   and t": X9.62 calls these integers "r" and "s", and it also 
   looks like Section 6 uses different symbols than X9.62. 
   I'd strongly recommend using the same notation!

4) Section 3: "Implementers may find it convenient, when using ECDSA
   as the authentication method, to specify the hash used by ECDSA as 
   the value of the hash algorithm attribute."

   First of all, this text applies only to IKEv1, as IKEv2 does not
   have a hash algorithm attribute. Second, I think the text is
   misleading.  To me it looks like the signature algorithms are each
   "tied to a particular hash algorithms" (in the RFC2409 Section 5.1
   sense), so it would be perfectly OK to use a different algorithm
   for the signature and IKEv1 hash algorithm attribute, right? The
   "may find it convenient" part smells of interoperability problems
   to me: either the algorithms MUST always be the same, or
   implementations MUST NOT assume they're the same!

5) Section 3: "The Diffie-Hellman group is understood to use the base
   points supplied in [IKE-ECP].  Therefore the selection of IANA
   identifier from the above table completely specifies the parameters
   necessary for verifying the signature."

   According to X9.62 Section 7.4.1, to verify a signature you need
   the message, the signature, the domain parameters, the public key,
   and the hash function. The domain parameters and the public key
   come from the certificate, right? And the hash function is given 
   by the authentication attribute number. But where does the
   Diffie-Hellman group come in? (Perhaps I'm missing something here,
   I'm not that familiar with EC math details...)

   (IKE/IKEv2 of course do Diffie-Hellman, but ECDSA signatures could
   be used with non-ECC DH as well, or the curve used for ECDSA could
   be totally different from the one used for IKE_SA_INIT DH
   exchange.)

   BTW, if everything except the hash algorithm is already conveyed
   in the certificate, we could just use the IKEv1 hash algorithm
   attribute to indicate the hash algorithm, and a single number for
   ECDSA would be enough (but maybe we still need three for IKEv2).

6) Section 3: "the signature payload SHALL contain an encoding of the
   computed signature consisting of the concatenation of a pair of
   integers s and t."

   Concatenated how? Suggested change: "the signature payload SHALL
   contain a DER-encoded ECDSA-Sig-Value structure as specified 
   in [X9.62]".

7) Section 5 (IANA Considerations) and Section 2: The current text 
   covers only IKEv1 authentication algorithm numbers. IKEv2
   has separate registries.

Purely editorial comments:

8) idnits produced number of boilerplate and formatting errors.
   Presumably, the RFC editor will fix most of them.

9) s/IKE-SA-INIT/IKE_SA_INIT/ and s/IKE-AUTH/IKE_AUTH/

10) References: [IANA] is probably not a normative reference,
   maybe not [IKE-ECP] either.

Best regards,
Pasi