Subject: [Gen-art] Gen-ART LC review of draft-kivinen-ipsecme-signature-auth-06.txt

From: Brian E Carpenter <[email-masked]>
Date: Mon, 07 Jul 2014 08:20:20 +1200

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-kivinen-ipsecme-signature-auth-06.txt
Reviewer: Brian Carpenter
Review Date: 2014-07-07
IETF LC End Date: 2014-07-15
IESG Telechat date:

Summary:  Almost ready
--------

Minor issues:
-------------

In the Security Considerations, it says:

   This means that the security of the authentication method is the
   security of the weakest component (signature algorithm, hash
   algorithm, or curve).  This complicates the security analysis of the
   system.  Note that this kind of mixing of security levels can be
   disallowed by policy.

As a security ignoramus, I would have liked to see some discussion of
downgrade attacks here. Also, the remark about "policy" seems incomplete.
Is it an implementation requirement that some sort of policy must be
supported? Is there a recommended default policy?

Nits:
-----

I found this sentence unnecessarily nested and hard to read:

   o  The RSA digital signature format in IKEv2 is specified to use
      RSASSA-PKCS1-v1_5 padding, but "Additional Algorithms and
      Identifiers for RSA Cryptography for use in PKIX Profile"
      ([RFC4055])) recommends the use of the newer RSASSA_PSS (See
      section 5 of [RFC4055]) instead.

Why not

   o  The RSA digital signature format in IKEv2 is specified to use
      RSASSA-PKCS1-v1_5 padding, but section 5 of "Additional Algorithms
      and Identifiers for RSA Cryptography for use in PKIX Profile"
      [RFC4055] recommends the use of the newer RSASSA_PSS instead.

---

From: Joel M Snyder <[email-masked]>
Date: Tue, 08 Jul 2014 13:01:28 +0200

I'll provide this and let Tero decode how to handle in concert with your 
feedback:

Nits:

You could write that sentence about 10 different ways and make it easier 
to read :-)  If I were to start from scratch, I would write it as:

- In IKEv2, authentication using RSA digital signatures calls for 
padding based on RSASSA-PKCS1-v1_5, although the newer RSASSA_PSS 
padding method is now recommended.  (See section 5 of "Additional 
Algorithms and Identifiers for RSA Cryptography for use in PKIX Profile" 
[RFC4055])

Issues:

1) Downgrade attacks.

Tero can correct me if I'm wrong, but it's inherent in the way that IKE 
works (and IKEv2) that downgrade attacks of the type you're thinking of 
are not possible because of the 'protection' that occurs in the IKE 
transaction.  I think that the best you can do is block an entire 
packet, but I don't believe that you can fiddle with the content, even 
this early in the IKE connection establishment.

If I'm correct, then perhaps a sentence such as: "Security downgrade 
attacks, where more secure methods are deleted or modified from a 
payloads by a Man-in-the-Middle to force lower levels of security, are 
not a significant concern in IKEv2 Authentication Payloads as discussed 
in this RFC.  This is because the IKEv2 Authentication Payload is 
protected and encrypted by the shared secret established earlier in the 
IKEv2 dialog." could be added after the paragraph you pointed out.

2) Policy

This is a "term of art" in the world of IKE, where it is always assumed 
that there is a policy database (actually a series of them) that define 
what traffic is encrypted and how it is encrypted, along with the rules 
for establishment of SAs.  So the reason for the glib notation is that 
all the IKEheads will automatically know what this means.

Of course this is no excuse, and your point is well taken.  I would 
suggest replacing the last sentence with a new paragraph as follows.

"IKEv2 peers have a series of policy databases (see [RFC4301] section 
4.4 "Major IPsec Databases") that define which security algorithms and 
methods should be used during establishment of security associations. 
To help end-users select the desired security levels for communications 
protected by IPsec, implementers may wish to provide a mechanism in the 
IKE policy databases to limit the mixing of security levels or to 
restrict combinations of protocols."

Anyway, those are my thoughts; I'll step out and see what Tero has to say.

Best regards,

Joel

-- 
Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
Senior Partner, Opus One       Phone: +1 520 324 0494
[email-masked]                http://www.opus1.com/jms

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 09 Jul 2014 08:02:14 +1200

Joel,

Thanks, I'd be very happy with your proposed updates.

Regards
   Brian

On 08/07/2014 23:01, Joel M Snyder wrote:
> methods should be used during establishment of security associations. To
> help end-users select the desired security levels for communications

---

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

> Minor issues:

Added two paragraphs, one about the policy and one about the downgrade
attacks:

    IKEv2 peers have a series of policy databases (see <xref
    target='RFC4301'/> section 4.4 "Major IPsec Databases") that
    define which security algorithms and methods should be used during
    establishment of security associations. To help end-users select
    the desired security levels for communications protected by IPsec,
    implementers may wish to provide a mechanism in the IKE policy
    databases to limit the mixing of security levels or to restrict
    combinations of protocols.

    Security downgrade attacks, where more secure methods are deleted
    or modified from a payloads by a Man-in-the-Middle to force lower
    levels of security, are not a significant concern in IKEv2
    Authentication Payloads as discussed in this RFC. This is because
    the IKEv2 Authentication Payload will be detected by the final
    AUTH payload verification.

>       [RFC4055] recommends the use of the newer RSASSA_PSS instead.

Changed to:

      In IKEv2, authentication using RSA digital signatures calls for
      padding based on RSASSA-PKCS1-v1_5, although the newer
      RSASSA_PSS padding method is now recommended. (See section 5 of
      "Additional Algorithms and Identifiers for RSA Cryptography for
      use in PKIX Profile" <xref target="RFC4055"/>).</t>
-- 
[email-masked]