Resend with corrected email alias Adrian
RFC ISE (Adrian Farrel) wrote: > Thanks Tero, much appreciated. > > I will discuss this with the authors. > > It is sometimes the case that this type of document (i.e. an NSA profile), > tightens the 2119 language from the referenced RFCs or removes options. > The argument in the past has been that, while the base spec gives some > degree of permissible variance, the specific deployment environment > requires particular behavior. > > (FYI, these documents *never* relax the 2119 language.) > > Nevertheless, I will check that the authors intended this behavior and > flag it to the responsible AD for confirmation. > > Best, > Adrian > > > Tero Kivinen wrote: >> While doing IANA expert review on the document I found some issues >> with this document, so here are my comments to it. >> >> In section 5 there is text which says: >> >> In particular, since AES-GCM is an AEAD >> algorithm, ESP implementing AES-GCM MUST indicate the integrity >> algorithm NONE. [RFC7296] >> >> This does not match the recommendation for the RFC7296 which says in >> section 3.3: >> >> Combined-mode ciphers include >> both integrity and encryption in a single encryption algorithm, and >> MUST either offer no integrity algorithm or a single integrity >> algorithm of "NONE", with no integrity algorithm being the >> RECOMMENDED method. >> >> This would mean that this document if approved would make the >> recommended method of RFC7296 of no integrity algorithm not allowed by >> this draft. >> >> I do not think it is appropriate to this draft make such change, and I >> would propose to change the wording on the section 5 to match the >> RFC7296, i.e., say that it is RECOMMENDED that no integrity algorithm >> is being sent in proposal at all, but it is also allowed to send >> single integrity algorithm of "NONE". >> >> -- >> >> And then some nits: >> >> -- >> >> In the abstract there is unexpanded acronym NSA on first line. On the >> introduction this is spelled out but there is acronym (NSA) listed >> there, it is only included on the first line of section 3. Usually it >> would be best to include the full expanded version of the acronym on >> the first use, and then use the acronym, and also expand all acronyms >> in the abstract. >> >> -- >> >>>From section 5 forward the references to RFCs use bit funny format, >> where the reference is AFTER the period of the sentence. This makes it >> hard to parse the text, as some times you could assume that the >> reference refers to the next sentence not the previous one. >> >> For example the text: >> >> User Interface (UI) suites are named suites that cover some typical >> security policy options for IPsec. [RFC4308] Use of UI suites does >> not change the IPsec protocol in any way. >> >> does not make clear where the RFC4308 reference belongs. Looking that >> the text I think it belongs to the first sentence, so better format >> would be: >> >> >> User Interface (UI) suites are named suites that cover some typical >> security policy options for IPsec ([RFC4308]). Use of UI suites does >> not change the IPsec protocol in any way. >> >> (with or without parenthesis). >> >> Same with some other references in the document. >> >> -- >> >> In section 5.1, 5.2, 5.3, it would be good idea to explictly mention >> that ENCR_AES_GCM_16 is to be used with key size of 256 bits. This is >> already mentioned in the section 4, but implementors might just jump >> to section 5 and define suites from there, so changing: >> >> Encryption: ENCR_AES_GCM_16 >> >> to >> >> Encryption: ENCR_AES_GCM_16 (with key size of 256 bits) >> >> would make all information needed available in that section. >> >> -- >> >> I think we can still keep the >> >> Integrity: NONE >> >> even if we fix the section 5 to use the recommended way of not >> including integrity algorithm at all, as this should be clear enough. >> >> -- >> >> Section 6 is not really part of the UI suites, as they authentication >> is separate from the algorithm negotiation in the IKEv2, but I think >> including it here will make sense, but I wonder why text is written in >> such way that RSA with 3072-bit or 4096-bit modulus using SHA-512 is >> not allowed? I would have assumed that either SHA-384 or SHA-512 would >> have been good enough for RSA. >> >> With ECDSA I can see that match hash length with the group length, but >> that does not really apply with RSA. >> >> -- >> >> Section 7 has again text that changes RFC7296. >> >> RFC7296 section 3.5 explictly says that: >> >> This identity may >> be used for policy lookup, but does not necessarily have to match >> anything in the CERT payload; >> >> Text in section 7 says that: >> >> The identity authentication >> method MUST use an end-entity certificate provided by the >> authenticating party and MUST NOT use the Identification Payload for >> policy lookup. >> >> >> Usually implementations do so that they use the Identification Payload >> to find the matching Peer Authorization Database (PAD) entry and from >> there they can then find the rules how the certificates needs to be >> matched. >> >> The problem is that there is general way of taking certificate and >> getting some information there and matching that to PAD. The >> information in certificate can come from multiple locations, i.e., it >> might be Subject or from SubjectAltName etc. Usually what field is >> used depends on the policy, and the identification payload is used to >> find the PAD entry, and then PAD entry will tell that end entity >> certificate must have matching entry in for example SubjectAltName if >> the Identification payload happened to be ID_RFC822_ADDR. >> >> I have no idea how to implement section 7, i.e., how do I use the >> end-entity certificate provided by the authentication party to find >> policy... >> >> -- >> >> In section 11 there is bit more of this Identification payloads text, >> but I do not think it helps at all, just repeats the confusion: >> >> For CNSA compliant systems, the IKEv2 authentication method MUST use >> an end-entity certificate provided by the authenticating party. >> Identification Payloads (Idi and IDr) in the IKE_AUTH exchanges MUST >> NOT be used for the IKEv2 authentication method , but may be used for >> policy lookup. >> >> here it actually contradicts the section 7, which said "MUST NOT use >> the Identification Payload for policy lookup". >> >> -- >> >> In section 12 there is text: >> >> For all applications to which this section applies, PSK >> authentication MUST be performed using HMAC-SHA-384 [RFC4868]. >> >> which is contradicting section 6 which says that >> >> >> For CNSA compliant systems, authentication methods other than >> ECDSA-384 or RSA MUST NOT be accepted for IKEv2 authentication. >> >> thus PSK is not allowed authentication method, so why specify MUST use >> HMAC-SHA-384 for authentication method which is not allowed? >> >> -- >> >> I do not think any of the issues affect the IANA allocations, thus I >> will go forward with that, but I would prefer that the authors would >> fix at least the issues where this document is not matching RFC7296, >> and perhaps clarify how the implementations are supposed to use the >> Identification payload and end entity certificate. >> -- >> kivi...@iki.fi >> > > > -- > Adrian Farrel (ISE), > rfc-...@rfc-editor.org > -- Adrian Farrel (ISE), rfc-...@rfc-editor.org _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
