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 |