Subject: [IPsec] Last Call: <draft-kivinen-ipsecme-signature-auth-06.txt> (Signature Authentication in IKEv2) to Proposed Standard

From: The IESG <[email-masked]>
Date: Tue, 01 Jul 2014 09:11:12 -0700

The IESG has received a request from the IP Security Maintenance and
Extensions WG (ipsecme) to consider the following document:
- 'Signature Authentication in IKEv2'
  <draft-kivinen-ipsecme-signature-auth-06.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2014-07-15. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   The Internet Key Exchange Version 2 (IKEv2) protocol has limited
   support for the Elliptic Curve Digital Signature Algorithm (ECDSA).
   The current version only includes support for three Elliptic Curve
   groups, and there is a fixed hash algorithm tied to each group.  This
   document generalizes IKEv2 signature support to allow any signature
   method supported by the PKIX and also adds signature hash algorithm
   negotiation.  This is a generic mechanism, and is not limited to
   ECDSA, but can also be used with other signature algorithms.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-signature-auth/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-kivinen-ipsecme-signature-auth/ballot/

No IPR declarations have been submitted directly on this I-D.

This draft updates RFC5996, however RFC5996 is in process of being updated in RFC5996-bis and will likely be published before this draft.  Each mention of RFC5996 should be replaced with the new RFC number for RFC5996-bis once a number has been assigned.

---

From: Johannes Merkle <[email-masked]>
Date: Fri, 4 Jul 2014 16:29:19 +0200

Nice work, the wording is really improved. However, I still have two comments:

1. The wording in A.4 is confusing.

   With RSASSA-PSS, the algorithm object identifier is always id-RSASSA-
   PSS, but the hash function is taken from the optional parameters, and
   is required.

It is not the hash function or the optional parameters that are required but the OID id-RSASSA-PSS. Secondly, the "but"
in the second part of the sentence indicates some contrast but I don't see one. Furthermore, not only the hash function
is determined from the parameters but also the other options for the padding.

Why not changing the text to

   With RSASSA-PSS, the algorithm object identifier must always be
   id-RSASSA-PSS, and the hash function and padding parameters are
   conveyed in the optional parameters.

2. The wording in A.4.1 is also not unambiguous:

   Parameters are empty, but the ASN.1 part of the sequence must be
   there.  This means default parameters are used (same as the next
   example).

Here "next example" does not refer to the example following immediately after this paragraph but to the example in the
next section. A reference to A.4.2 should be included.

--
Johannes

The IESG wrote on 01.07.2014 18:11:
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> 

-- 
Mit freundlichen Grüßen,
Dr. Johannes Merkle
Principal Beratung, Elektronische Identitäten
Public Sector
secunet Security Networks AG
Mergenthaler Allee 77
65760 Eschborn
Germany
Telefon +49 201 54 54-3091
Telefax +49 201 54 54-1325
Mobil   +49 175 2224439
[email-masked]
www.secunet.com

---

From: Tero Kivinen <[email-masked]>
Date: Sun, 20 Jul 2014 22:02:59 +0300

Johannes Merkle writes:
> It is not the hash function or the optional parameters that are
> required but the OID id-RSASSA-PSS. Secondly, the "but" in the
> second part of the sentence indicates some contrast but I don't see
> one. Furthermore, not only the hash function is determined from the
> parameters but also the other options for the padding.
> 

Changed to:

	With RSASSA-PSS, the algorithm object identifier must always
	be id-RSASSA-PSS, and the hash function and padding parameters
	are conveyed in the parameters (which are not optional in this
	case). See <xref target="RFC4055"/> for more information.

In the RSASSA-PSS the parameters are required, but they can be empty,
so they are not optional in this case.

> Here "next example" does not refer to the example following
> immediately after this paragraph but to the example in the next
> section. A reference to A.4.2 should be included.

Changed to:

	Parameters are empty, but the ASN.1 part of the sequence must
	be present. This means default parameters are used.

I.e removed the reference to next example.
	
-- 
[email-masked]

---

From: Johannes Merkle <[email-masked]>
Date: Fri, 25 Jul 2014 11:39:00 +0200

Tero,

thanks for updating the document. However, I'm not sure the first issue is solved.

> so they are not optional in this case.

Really? Section 3.1 of RFC 4055 states
   When RSASSA-PSS is used in an AlgorithmIdentifier, the parameters
   MUST employ the RSASSA-PSS-params syntax.  The parameters may be
   either absent or present when used as subject public key information.

My understanding of this is that the parameters can indeed be absent not just empty.

IMHO the semantic is different: If the parameters are empty (empty sequence in RSASSA-PSS-param), the default values
apply, and according to Section 3.3, case 3, of RFC 4055, the parameters in a signature MUST be validated against the
(default) parameters specified in SPKI. However, if the parameters are absent, then, according to Section 3.3, case 2,
of RFC 4055, no parameter validation is needed in a signature validation, i.e. a signature may use any parameters.

Maybe, I misinterpret the spec here?

-- 
Johannes