The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX
draft-ietf-pki4ipsec-ikecert-profile-12

Reference [20] is not used in the text.

Acronyms need to be expanded on their first use. 

(from Gen-ART review by Gonzalo Camarillo)

Comments received by Frank Kastenholz from the Ops Directorate (and supported by Pekka Savola, also from the Ops directorate, see his comments at the bottom):

 no specific technical comments.

 i wonder how this profile was developed. was it based on
 operational experience ("gee my box doesn't speak with
 your box 'cuz...") or was it a bunch of experts
 sitting around saying "this looks vague, lets fix it"?
 if the latter, it's not clear that this document definitely will
 do any good. (and if the former, it's not clear that all the
 holes will be found).

 i don't think that there are any changes/etc to make now, but
 the iesg might wish to consider strongly vetting this document
 as it goes to the next level of standardization (if that ever
 happens...) to ensure that the profile 'works' (or perhaps
 asking that the wg monitor this stuff and report back in n-months
 on what is/isnot working and perhaps fixes for the latter)?

More comments by Pekka Savola from the the Ops directorate:

 "The document is aimed at PKI4IPSEC implementors as clarified by the
 editor (though it doesn't state that clearly in the introduction), not
 protocol designers (the rest of the IETF).

 If I wanted to use PKI and IPsec with (for example) OSPF or PIM (or
 any other protocol) or define extensions to do that, it's not clear
 how I should proceed.  So, to make PKI4IPSEC more useful to the rest
 of the IETF, more work (along the lines of draft-bellovin-useipsec but
 more detailed how to use PKI4IPSEC) seems to be necessary."

 The author stated that the document is not aimed at those who use the
 protocols or design protocols, but PKI4IPSEC folks.  Hence, there may
 or may not be a disconnect about the intended target audience and what
 this document is meant to achieve, because at least Sam Hartman seemed
 to think that this document would also serve the rest of the IETF on
 how to use certificates with IPsec in their applications.

 It's very obvious to me that the document is not very useful to either
 operators and protocol designers as written and a lot of further
 guidance would be needed to make it so.

   > ISAKMP and IKEv2 do not support Certificate Payload sizes over
   > approximately 64K, which is too small for many CRLs.

   I see that you require out of band delivery, good. In any
   case, the above text is a bit misleading.

   CRLs in IKE are unlikely to successfully work with even much
   smaller payload sizes. The protocols employ UDP, and can not break
   up a single CRL into different packets. As a result, a long payload
   would lead to fragmentation. Packets broken up in a large number of
   fragments may be unlikely to arrive at the other end for various
   reasons, such as the effect of packet loss or badly implemented
   middleboxes. This implies that the practical limits of certificate
   transport are lower than 64K in many environments. Suggest
   reformulation to something like "ISAKMP and IKEv2 have an
   approximately 64K theoretical limit to Certificate Payload
   sizes. In many environments the limit for effective use is even
   smaller. These sizes are too small for many CRLs."

Nits:

  > according to the PKIX certficate profile) and MUST make use of a base

  Typo

  > the PKIX certifiate profile and this document.  With respect to

  Typo

  > especially CRLs and ARLs in IKE would increase the liklihood of UDP

  Typo

  idnits warnings:

  Miscellaneous warnings:
  - Line 1192 has weird spacing: '...lements    bit...'

  Experimental warnings:
  - Unused Reference: '20' is defined on line 1749, but not referenced

Section 3.1.1., paragraph 1:

>    Implementations MUST support either the ID_IPV4_ADDR or ID_IPV6_ADDR
>    ID type, depending on whether the implementation supports IPv4, IPv6
>    or both. 

  "Either/or" excludes "both." I'd recommend rephrasing something like:
  "If an implementation supports IPV4, it MUST support ID_IPV4_ADDR. If
  an application supports IPv6, it MUST support ID_IPV6_ADDR."


Section 3.1.1., paragraph 3:

>    Deployments may only want to consider using the IP address as ID if
>    all of the following are true:

  "May only want" seems weak, considering the issues that can arise when
  this isn't followed. Upgrade to "SHOULD?"


Section 3.1.1., paragraph 8:

>    Implementations MAY support substring, wildcard, or regular
>    expression matching of the contents of ID to lookup policy in the
>    SPD, and such would be a matter of local security policy
>    configuration.

  Nit: Substring and wildcard matching are subsets of regular expression
  matching. Just talking about regular expression matching should be
  sufficient. (Also elsewhere in the document.)


Section 3.1.6., paragraph 1:

>    Implementations MUST NOT generate this type.

  And ignore it when they receive it?


Section 4.1.3., paragraph 2:

>    Certification Authority implementations SHOULD generate certificates
>    such that the extension criticality bits are set in accordance with
>    the PKIX certifiate profile and this document. 

  Nit: s/certifiate/certificate/


Section 4.2.2.4.1., paragraph 1:

>    IKE implementations that do not support delta CRLs MUST reject CRLs
>    which contain the DeltaCRLIndicator (which MUST be marked critical
>    according to the PKIX certficate profile) and MUST make use of a base
>    CRL if it is available.

  Nit: s/certficate/certificate/

Also from Steve's review:


-    3.1.1 ends with a discussion referring to "a VPN gateway device" which
would appear to be a "security gateway" as per RFC 2401.  The terminology used
here should be consistent with that of 2401.
-       3.1.10 addresses the topic of selecting which identity to assert in the
IKE ID payload, and how the recipient of the payload matches this asserted
identity against a "database" which is not defined.  This database would be the
PAD as per RFC 4301, and this section includes a reference to the PAD.  I
wonder why the text doesn't just suggest using the PAD as the model for what it
discusses in a less formal fashion. The text says: "In the presence of
certificates that contain multiple identities, implementations MUST select the
most appropriate identity from the certificate and populate the ID with that."
This strikes me as untestable and thus an inappropriate MUST!

Section 3.3 discusses CERT payloads.
-     the intro for this section says "Note, however, that while the sender of
the CERT payloads SHOULD NOT  send any trust anchors, it's possible that the
recipient may consider any given intermediate CA certificate to be a trust
anchor."  This should be reworded to more clearly state that  the sender ought
not send certificates that IT considers trust anchors, since the concept of a
TA is a purely local notion. The text indicates this, but in a very indirect
fashion.
-    The example of a MAY be supported URL form in 3.3.4 should say
specifically what makes it a MAY (vs. a MUST or SHOULD) be supported URL form.

It might be valuable to include the actual code points for the listed delimeters in Section 5 (as is done for the CR/LF combinations)