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

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

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.
>> --
>> [e-mail]
>>
>
>
> --
> Adrian Farrel (ISE),
> [e-mail]
>


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