Joel, Thanks, I'd be very happy with your proposed updates.
Regards Brian On 08/07/2014 23:01, Joel M Snyder wrote: > 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 > > On 7/6/14, 10:20 PM, Brian E Carpenter wrote: >> 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. >> > _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
