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.
--
Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719
Senior Partner, Opus One Phone: +1 520 324 0494
[email protected] http://www.opus1.com/jms
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
