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

From: Jari Arkko <[email-masked]>
Date: Thu, 7 Aug 2014 14:26:57 +1200

Joel, Tero - thanks for the updates, and thank you Brian for the review. I have looked at the changes in the new version and they look reasonable.

I have balloted no-obj for this document in today’s IESG telechat.

Jari

On 21 Jul 2014, at 07:06, Tero Kivinen <[email-masked]> wrote:

> Brian E Carpenter writes:
>> 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?
> 
> 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.
> 
>> 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.
> 
> 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]
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art