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 protected]> 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 protected] > > _______________________________________________ > Gen-art mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/gen-art
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
