Re: [IPsec] Comments to draft-corcoran-cnsa-ipsec-profile-05

["RFC ISE (Adrian Farrel)" <[e-mail]>]

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.
> --
> [e-mail]
>


-- 
Adrian Farrel (ISE),
[e-mail]