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
