Skip to main content

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

Revision differences

Document history

Date Rev. By Action
2012-08-22
12 (System) post-migration administrative database adjustment to the No Objection position for Sam Hartman
2007-04-04
12 (System) IANA Action state changed to No IC from In Progress
2007-04-04
12 (System) IANA Action state changed to In Progress
2007-04-02
12 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2007-03-27
12 Amy Vezza IESG state changed to Approved-announcement sent
2007-03-27
12 Amy Vezza IESG has approved the document
2007-03-27
12 Amy Vezza Closed "Approve" ballot
2007-03-27
12 Russ Housley State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by Russ Housley
2007-03-27
12 Sam Hartman [Ballot Position Update] Position for Sam Hartman has been changed to No Objection from Discuss by Sam Hartman
2007-03-08
12 Sam Hartman
[Ballot discuss]
This discuss is based significantly on a review from Steve Kent. 

-    This section[section 3 ]  also imposes a requirement for an …
[Ballot discuss]
This discuss is based significantly on a review from Steve Kent. 

-    This section[section 3 ]  also imposes a requirement for an IPsec implementation be
configured (by default) to check the "outermost" IP source address of incoming
traffic against the IP address used as the IKE ID, if that form of IKE ID was
used. This is not a check specified by RFC 2401, and so it is inappropriate for
a "profile" document. Moreover, this requirement runs counter to the IPsec
architecture model, which says that only the inner address of a tunnel mode SA
need be checked against the SPD or SAD entry. A road warrior IPsec
implementation might  be configured with a certificate asserting an IP address
and might use that address as an IKE ID, with the intent that this address be
the INNER address in the tunnel established between the road warrior and an
enterprise security gateway.  This also seems odd in that Section 2 (Terms and
Definitions) contains the following definition: "Peer source address: The
source address in packets from a peer. This address may be different from any
addresses asserted as the "identity" of the peer."

Section 5.1.3.12 does not explain why EKU should not be used with
IPsec.  Either remove this requirement or explain why it exist and
what circumstances the SHOULD should be violated under.
This specification needs to make it clear whether IPsec relying
parties need to implement EKU and needs to make it clear that if  EKU
is implemented it cannot be ignored even if not marked critical.
Also the summary for EKU handling in peer certificate validation
doesn't seem like a summary to me as it expresses requirements found
no where else.
2007-02-23
12 (System) New version available: draft-ietf-pki4ipsec-ikecert-profile-12.txt
2006-11-08
12 Sam Weiler Assignment of request for Early review by SECDIR to David Harrington was rejected
2006-11-08
12 (System) Request for Early review by SECDIR is assigned to David Harrington
2006-11-08
12 (System) Request for Early review by SECDIR is assigned to David Harrington
2006-09-28
12 (System) Sub state has been changed to AD Follow up from New Id Needed
2006-09-28
11 (System) New version available: draft-ietf-pki4ipsec-ikecert-profile-11.txt
2006-08-04
12 Amy Vezza State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation by Amy Vezza
2006-08-03
12 Sam Hartman
[Ballot comment]
Also from Steve's review:


-    3.1.1 ends with a discussion referring to "a VPN gateway device" which
would appear to be a …
[Ballot comment]
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.
2006-08-03
12 Sam Hartman
[Ballot discuss]
This discuss is based significantly on a review from Steve Kent.  As a
matter of process, the working group needs to consider and …
[Ballot discuss]
This discuss is based significantly on a review from Steve Kent.  As a
matter of process, the working group needs to consider and respond to
the points mentioned in that review that are not explicitly part of
this discuss.

Steve raises a significant architectural issue that must be addressed
before this document is published and that will require significant
effort and possibly additional expertise in the working group.Steve
says "It is worrisome that the document provides a profile applicable
to both IKE v1 and v2, but the normative references cite only the
older IPsec architecture document (RFC 2401).  IKE v2 is tied to the
new IPsec architecture (RFC 4301); it includes features to support
that architecture and to support the revised versions of AH and ESP,
so it is inconsistent to include IKE v2 in this profile, but to view
the new IPsec architecture as merely informative."  I think he
understates the problem.  One area where this failure to consider the
IPsec architecture is most pronounced in section 3 and particular 3.1,
where the PAD should figure prominently but is not.  The document
assumes that versions of IKE consult the SPD and interact with the SPD
when authorizing peers, choosing peer identities and validating
certificates.  Most of these roles are filled by the PAD in RFC 4301.
The current text will increase the confusion about what roll the PAD
fills and about differences between RFC 4301 and 2401; I think this
increased confusion will more than outweigh the advantages of clarity
in identity matching and certificate handling for IPsec.  I'm not sure
it is possible to write text for an IKE profile that applies both to
the 2401 or 4301 architecture that will not be horribly confusing.
This document certainly fails.  I would recommend considering
approaches such as focusing on the newer architecture because it is
more well defined or writing a separate IKE and IKEV2 profile.  I
think having someone become involved in the effort who is familiar
with the PAD but who has not read this document so many times that
they will miss the problems is critical to forward progress on this
item.

Section 3.1 says features are optional that are required by 4301.  For
example 4301 mandates sub-tree matching for rfc822 IDs, DNS IDs and
DNs.

The document also confuses requirements for IPsec implementations with
requirements for certificate authorities.  This needs to be cleaned up.

Section 3.2.7 says that implementations should not expect to receive
certificates if they do not send a CERTREQ; this disagrees with the
IKEv2 specification.

-    This section[section 3 ]  also imposes a requirement for an IPsec implementation be
configured (by default) to check the "outermost" IP source address of incoming
traffic against the IP address used as the IKE ID, if that form of IKE ID was
used. This is not a check specified by RFC 2401, and so it is inappropriate for
a "profile" document. Moreover, this requirement runs counter to the IPsec
architecture model, which says that only the inner address of a tunnel mode SA
need be checked against the SPD or SAD entry. A road warrior IPsec
implementation might  be configured with a certificate asserting an IP address
and might use that address as an IKE ID, with the intent that this address be
the INNER address in the tunnel established between the road warrior and an
enterprise security gateway.  This also seems odd in that Section 2 (Terms and
Definitions) contains the following definition: "Peer source address: The
source address in packets from a peer. This address may be different from any
addresses asserted as the "identity" of the peer."

Section 3.1.8 makes a requirement that the outbound ID SHOULD be the
one most likely to work.  How can this SHOULD be implemented?  Perhaps
this is mor of a requirement for system administrators than for
implementations.  If so, section 3.1.8 needs to be rewritten to
require implementations to provide system administrators the
facilities they need.


-    4.1.3.1 contains the phrase "  and thus SHOULD NOT generate certificate
hierarchies which are overly complex  " This sort of advice to a CA is not
testable, since there is no objective definition for what constitutes "overly
complex" and thus it is a poor candidate for a SHOULD
requirement. [Reword probably not using 2119 language]

Section 4.1.3.12 does not explain why EKU should not be used with
IPsec.  Either remove this requirement or explain why it exist and
what circumstances the SHOULD should be violated under.
This specification needs to make it clear whether IPsec relying
parties need to implement EKU and needs to make it clear that if  EKU
is implemented it cannot be ignored even if not marked critical.
Also the summary for EKU handling in peer certificate validation
doesn't seem like a summary to me as it expresses requirements found
no where else.
2006-08-03
12 Sam Hartman [Ballot Position Update] New position, Discuss, has been recorded for Sam Hartman by Sam Hartman
2006-08-03
12 Jari Arkko
[Ballot comment]
> ISAKMP and IKEv2 do not support Certificate Payload sizes over
  > approximately 64K, which is too small for many CRLs.

  …
[Ballot comment]
> 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
2006-08-03
12 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko by Jari Arkko
2006-08-03
12 Jon Peterson [Ballot Position Update] New position, No Objection, has been recorded for Jon Peterson by Jon Peterson
2006-08-02
12 David Kessens
[Ballot comment]
Comments received by Frank Kastenholz from the Ops Directorate (and supported by Pekka Savola, also from the Ops directorate, see his comments at …
[Ballot comment]
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.
2006-08-02
12 David Kessens [Ballot Position Update] New position, No Objection, has been recorded for David Kessens by David Kessens
2006-08-02
12 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded for Ross Callon by Ross Callon
2006-08-01
12 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded for Mark Townsley by Mark Townsley
2006-07-31
12 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded for Lisa Dusseault by Lisa Dusseault
2006-07-31
12 (System) State Changes to IESG Evaluation from IESG Evaluation - Defer by system
2006-07-21
12 (System) Removed from agenda for telechat - 2006-07-20
2006-07-19
12 Yoshiko Fong IANA Last Call comment:

As described in the IANA Considerations section, we understand this document to
have NO IANA Actions.
2006-07-18
12 Brian Carpenter [Ballot comment]
Reference [20] is not used in the text.

Acronyms need to be expanded on their first use.

(from Gen-ART review by Gonzalo Camarillo)
2006-07-18
12 Brian Carpenter [Ballot Position Update] New position, No Objection, has been recorded for Brian Carpenter by Brian Carpenter
2006-07-18
12 Sam Hartman State Changes to IESG Evaluation - Defer from IESG Evaluation by Sam Hartman
2006-07-17
12 Cullen Jennings [Ballot Position Update] New position, No Objection, has been recorded for Cullen Jennings by Cullen Jennings
2006-07-17
12 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded for Dan Romascanu by Dan Romascanu
2006-07-17
12 Lars Eggert
[Ballot comment]
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 …
[Ballot comment]
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/
2006-07-17
12 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert by Lars Eggert
2006-07-17
12 Ted Hardie [Ballot Position Update] Position for Ted Hardie has been changed to No Objection from Discuss by Ted Hardie
2006-07-17
12 Ted Hardie
[Ballot comment]
It might be valuable to include the actual code points for the listed delimeters in Section 5 (as is done for the CR/LF …
[Ballot comment]
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)
2006-07-17
12 Ted Hardie [Ballot Position Update] New position, Discuss, has been recorded for Ted Hardie by Ted Hardie
2006-07-11
12 Russ Housley
[Ballot comment]
These minor concerns were discovered by Pasi Eronen.

  Throughout the document: s/caseless/case-insensitive/

  Section 3.1 says:
  >
  > Implementations SHOULD …
[Ballot comment]
These minor concerns were discovered by Pasi Eronen.

  Throughout the document: s/caseless/case-insensitive/

  Section 3.1 says:
  >
  > Implementations SHOULD populate ID with identity information
  > that is contained within the end-entity certificate [...]  The
  > only case where implementations MAY populate ID with information
  > that is not contained in the end-entity certificate is when ID
  > contains the peer source address (a single address, not a
  > subnet or range).
  >
  s/MAY/may/

  Section 7.1 says:
  >
  > The Contents of CERTREQ are not encrypted in IKE.
  >
  The initiator's CERTREQ is encrypted in IKEv2 (but since it's
  naturally sent before the initiator has authenticated the
  responder, this helps only against passive eavesdroppers).
2006-07-10
12 Russ Housley [Ballot Position Update] New position, Yes, has been recorded for Russ Housley
2006-07-10
12 Russ Housley Ballot has been issued by Russ Housley
2006-07-10
12 Russ Housley Created "Approve" ballot
2006-07-10
12 Russ Housley Placed on agenda for telechat - 2006-07-20 by Russ Housley
2006-07-10
12 Russ Housley State Changes to IESG Evaluation from Waiting for AD Go-Ahead by Russ Housley
2006-06-28
12 (System) State has been changed to Waiting for AD Go-Ahead from In Last Call by system
2006-06-14
12 Michael Lee Last call sent
2006-06-14
12 Michael Lee State Changes to In Last Call from Last Call Requested by Michael Lee
2006-06-13
12 Russ Housley Last Call was requested by Russ Housley
2006-06-13
12 Russ Housley State Changes to Last Call Requested from AD Evaluation::AD Followup by Russ Housley
2006-06-13
12 (System) Ballot writeup text was added
2006-06-13
12 (System) Last call text was added
2006-06-13
12 (System) Ballot approval text was added
2006-04-20
12 (System) Sub state has been changed to AD Follow up from New Id Needed
2006-04-20
10 (System) New version available: draft-ietf-pki4ipsec-ikecert-profile-10.txt
2006-04-20
12 Russ Housley State Changes to AD Evaluation::Revised ID Needed from AD Evaluation by Russ Housley
2006-04-17
09 (System) New version available: draft-ietf-pki4ipsec-ikecert-profile-09.txt
2006-04-02
08 (System) New version available: draft-ietf-pki4ipsec-ikecert-profile-08.txt
2006-03-10
12 Russ Housley State Changes to AD Evaluation from Publication Requested by Russ Housley
2006-03-09
12 Russ Housley Draft Added by Russ Housley in state Publication Requested
2005-11-14
07 (System) New version available: draft-ietf-pki4ipsec-ikecert-profile-07.txt
2005-10-25
06 (System) New version available: draft-ietf-pki4ipsec-ikecert-profile-06.txt
2005-08-01
05 (System) New version available: draft-ietf-pki4ipsec-ikecert-profile-05.txt
2005-04-12
04 (System) New version available: draft-ietf-pki4ipsec-ikecert-profile-04.txt
2004-10-01
03 (System) New version available: draft-ietf-pki4ipsec-ikecert-profile-03.txt
2004-09-08
02 (System) New version available: draft-ietf-pki4ipsec-ikecert-profile-02.txt
2004-07-22
01 (System) New version available: draft-ietf-pki4ipsec-ikecert-profile-01.txt
2004-06-03
00 (System) New version available: draft-ietf-pki4ipsec-ikecert-profile-00.txt