2.6.7 Profiling Use of PKI in IPSEC (pki4ipsec)

NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-02-12

Paul Knight <paul.knight@nortelnetworks.com>
Gregory Lebovitz <gregory@netscreen.com>
Security Area Director(s):
Russell Housley <housley@vigilsec.com>
Steven Bellovin <smb@research.att.com>
Security Area Advisor:
Russell Housley <housley@vigilsec.com>
Mailing Lists:
General Discussion: pki4ipsec@icsalabs.com
To Subscribe: http://honor.icsalabs.com/mailman/listinfo/pki4ipsec
In Body: (un)subscribe
Archive: http://honor.icsalabs.com/mailman/listinfo/pki4ipsec
Description of Working Group:
IPsec has been standardized for over 5 years, and the use of X.509 certificates have been specified within the IPsec standards for the same time. However, very few IPsec deployments use certificates. One reason is the lack of a clear description of how X.509 certificates should be used with IPsec. Another is the lack of a simple, scalable, and clearly specified way for IPsec systems to obtain certificates and perform other certificate lifecycle operations with PKI systems.


1) A standards-track document that gives specific instructions on how X.509 certificates should be handled with respect to the IKEv1 and IKEv2 protocols. This document will include a certificate profile, addressing which fields in the certificate should have which values and how those values should be handled. This effort is the WG's primary priority.

2) An informational document identifying and describing requirements for a profile of a certificate management protocol to handle PKI enrolment as well as certificate lifecycle interactions between IPsec VPN systems and PKI systems. Enrolment is defined as certificate request and retrieval. Certificate lifecycle interactions is defined as certificate renewals/changes, evocation, validation, and repository lookups.

These requirements will be designed so that they meet the needs of enterprise scale IPsec VPN deployments.

Once the above to items enter WG last call, we will begin work on:

3) A standards-track document describing a detailed profile of the CMC (Certificate Management Messages over CMS protocol, RFC 2797 at this writing) that meets the requirements laid out in the requirements document. Profile documents for other enrolment and/or management protocols may also be created.

SCOPE The working group will focus on the needs of enterprise scale IPsec VPN deployments. Gateway-to-gateway access (tunnel and transport mode) and end-user remote access to a gateway (either tunnel or transport mode) are both in scope.


User-to-user IPsec connections will be considered, but are not explicitly in scope. We will consider the requirements for this scenario only until doing so significantly slows the progress of the explicitly scoped items, at which point it will be dropped.

Specification of communications between an IPsec administrative function and IPsec systems is explicitly out of scope.

Purely PKI to PKI issues will not be addressed. Cross-certification will not be addressed. Long term non-repudiation will also not be addressed.

Goals and Milestones:
Jan 04  Post Certificate Profile and Use in IKE as an Internet Draft
Feb 04  Post Management Protocol Profile Requirements as I-D
Apr 04  Submit Certificate Profile and Use in IKE as WG last call
Apr 04  Rev Requirements for management protocol profile as needed
Apr 04  Submit Requirements for Management Protocol Profile as WG last call
Jun 04  Submit Certificate Profile and Use to IESG, Proposed Standard
Jun 04  WG decision on other Enrolment/Management protocols to profile
Jul 04  Submit Requirements for Management protocol Profile to IESG, Informational
Jul 04  Post CMC for IPsec VPN Profile as Internet Draft
Jul 04  Post other enrolment/management profiles as I-D
Sep 04  Rev CMC for IPsec VPN profile as needed
Sep 04  Rev other enrolment/management profiles as needed
Nov 04  CMC for IPsec VPN profile to WG last call
Nov 04  Other enrolment/management profiles to WG last call
Jan 05  Submit CMC for IPsec VPN Profile to IESG, Proposed Standard
Jan 05  Submit other Profiles for enrolment/management to IESG, Proposed Standard
Feb 05  Re-charter or close
No Current Internet-Drafts
No Request For Comments

Current Meeting Report


IETF #59 (Seoul, Korea)

Monday, 1 March 2004, 1300-1500


            Gregory Lebovitz, Netscreen

            Paul Knight, Nortel Networks


Minutes by Chris Bonatti and Sean Turner of IECA


Charter Page:         http://www.ietf.org/html.charters/pki4ipsec-charter.html

Mailing List:            pki4ipsec@icsalabs.com

Info:                       http://www.icsalabs.com/pki4ipsec

To Subscribe:         http://honor.icsalabs.com/mailman/listinfo/pki4ipsec [(un)subscribe in body]

Archive:                  http://honor.icsalabs.com/mailman/listinfo/pki4ipsec



Intro and Agenda Bashing


Paul Knight reviewed the WG mailing list provisions, and indicated that the WG documents were available from the info website above.


Chris Bonatti and Sean Turner agreed to serve as scribes.  In addition, one person volunteered as Jabber scribe.


Gregory Lebovitz noted that the group will be using an issue tracker, and solicited a volunteer.  There were no immediate takers.



Recap of WG Charter and Key Issues


Gregory Lebovitz reviewed the final approved charter.


Steve Kent asked whether it was appropriate to have deliverable (2) from the WG charter as an informational RFC state requirements for a standards track profile – item (3) in the WG charter.  Russ Housley stated that all requirements documents are informational, but that it is really identifying what WILL BE done in (3).  This helped clarify the point that Steve Kent was concerned that (2) would address (1).  Russ Housley indicated that this would not be the case.


Steve Kent also asked about the scope where it highlights “tunnel and transport mode” which is erroneous in the context of the current RFC 2401.  Gregory Lebovitz suggested that Russ Housley suggested that he provide new text to clarify the relation to RFC 2401 and RFC2401bis and it would be considered.



Requirements for an IPsec Certificate Management Profile


Chris Bonatti presented an overview of the proposed requirements document.  See http://www.icsalabs.com/html/communities/pki4ipsec/040225-IETF-PKI4IPSEC-Requirements-Briefing-02.ppt.


Russ Housley asked about the point on key escrow; wanting to know what we changed.  Chris Bonatti responded that essentially the document now doesn't say if you do it, where to do it, or how you'd do it.  This is necessary because we don’t really characterize enough about how the key management is done.


Gregory Lebovitz asked about the issue of expanding the scope to include the case where is no VPN admin.  He noted that the VPN admin function was intended to be just a logical construct.  A device might have VPN peer and admin functions resident in single box.  He suggested that we might just need a small fix to the wording to clarify this.  Chris Bonatti agreed, but pointed out that there were some small potential impacts because you then don't have a central VPN admin.  He gave the example that if there is no central admin function, then preauthorization doesn’t make much sense.  He agreed, however, that this could be dealt with some small wording changes.  Gregory Lebovitz suggested that perhaps we need to identify some top-level use case scenarios.  Chris Bonatti indicated that he thought this was a good idea.  He noted that the document had some use cases at present under key management, but they were well buried in the requirements.


Steve Kent remarked that section 3.5 establishes a certificate profile.  He asked how we propose to deal with the overlap with the certificate profile in deliverable (1).  Chris Bonatti responded that the PKCs described in this document are not for IPSec, but for support of ongoing cert management.  He noted that the certs used for the two purposes *might* be different according to the WG charter.  He noted that the potential difference between this was one of the “Big” Issues highlighted.  Gregory Lebovitz stated that he believed that we are going to move it to deliverable (1), so this is just editing.


Paul Knight asked how many people had reviewed the draft, noting that it had come out fairly late.  Paul Hoffman stated that we still need this document or something like it, in that it has a more IPSEC flavor than a PKI flavor.  What's confusing is that in IPsec we need to have pictures to explain what's going on where.  He suggested that we need use cases.


Bill Sommerfeld stated that this document is needlessly specific to IPSEC use of VPN, where it is truly applicable to all IPSEC usage.  He noted that the requirements described would be virtually unchanged if all of IPsec were considered.  Chris Bonatti stated that this may be true, but that maybe it would be best to tackle the VPN scenario.  He asked how this related to Steve Kent’s charter question about tunnel vs. transport mode.  Russ Housley responded that he thought the two issues were orthogonal.  Steve Kent asked whether the goal is to make this work with existing practice, or to influence vendors.  Paul Hoffman responded that we wanted to influence vendors.  Steve Kent noted that in that event limiting the scope is bad because you could get vendors to do something that is inconsistent with the later, broader solution.


Paul Knight asked for a show of hands in support of adopting the document in the WG.  Several endorsed the document.  There was no dissent expressed.



The Internet IP Security PKI Profile of ISAKMP and PKIX


Paul Hoffman presented slides on behalf of Brian Korver, who was unfortunately not present.  See file Korver_status.ppt.


Steve Kent noted that the IP range is not used because there is no standard way to convey these certificates.  This has been addressed so presumably we would reconsider the MUST NOT classification.  Paul Hoffman noted that the real reason is that nobody is using this, so having one peer include it is bad for interoperability.


Steve Kent also challenged the prohibition on KeyIDs.  Paul Hoffman noted that there are multiple ways of obtaining KeyIDs, and there is no way to standardize how this is done.  The main justification for prohibiting them is that nobody does these.


Somebody suggested that stating that "The target is matching the ID to the certificate" is the wrong goal.  We should want to explain how we establish that the IKE ID is acceptable, in the context of the certificate.  Paul Hoffman noted that this could be taken up on the mailing list.  Steve Kent stated that it was difficult to raise this in the absence of a requirements context.  Paul Hoffman stated that the requirement is maximum interoperability and functionality without compromising security.  Steve Kent stated that it is impossible to judge the importance of something without that context.  He gave the example of the benefits of passing certificates in-band vs. retrieving them from a repository.  Gregory Lebovitz noted that the discussion on the list is strongly colored by what vendors are doing.  IP range hasn’t come up explicitly on the list because nobody is doing it.  So we don’t begin consideration of solutions from an entirely blank slate.  Gregory Lebovitz proposed that further discussion be deferred to the list.


Paul Hoffman noted a bit of a chicken and egg problem with getting CRLs without an existing SA.  Gregory Lebovitz asked whether the missing piece was the ENROLL solution?  Paul Hoffman said no.  The problem is a lack of a secure means of obtaining CRLs, etc. from a repository.


Lauri Tarkkala stated that he was very skeptical of a document making changes to existing implementations.  You will end up with just the lowest common denominator with nobody changing anything.  He stated that this should be done in an OPS group.  Paul Hoffman stated that we have an assumption that vendors ARE willing to make changes to products.  A secondary question is can they change their implementations without breaking interoperability with themselves.  Gregory Lebovitz noted that a lot of issues that we didn’t deal well with in IKEv1 are going to be a lot more important for IKEv2.  The goal for v1 is really to improve to the point where we can have CAs, IPSEC peers, etc. all from different vendors.  For v2 we want to shift the focus to helping the profile be implemented.  Paul Hoffman stated that this was fundamental to the WG, and should be discussed on the WG list.  If all we can do is boil down the lowest common denominator, then we can finish early because this isn’t going to do any good.


Gregory Lebovitz reviewed the list of open issues for the IKE certificate profile.  See file profile-04_OpenIssues.ppt.  The following issues were discussed:


How or does NAT-T stuff affect us?

Somebody stated that he had reviewed the document for impacts, but thinks we’re mostly okay.  ID payloads or certificates containing IP addresses will create a problem.  Gregory Lebovitz suggested we add text discouraging use of the IP address for this reason.  Paul Hoffman stated that he thought we should not be matching the outer IP address to the asserted IP address.  Gregory Lebovitz noted that he thinks this has already been agreed by Brian Korver, but the document may not yet reflect the agreement.


Certificate type (PKIX, PGP, etc.).

Gregory Lebovitz proposed a PKIX X.509 with RSA/SHA-1 signature.  Bill Sommerfeld stated that he has no problem with any of these types provided that it does not preclude another profile.  This approach seemed agreed.


PKI Life-cycle Stuff in-band?

Gregory Lebovitz suggested MUST NOT requesting or sending: CRLs, Trust Anchors, Intermediate Certs, and other revocation info.  Steve Kent stated that most of these things aren’t really “life cycle” in nature.  This is a mischaracterization.  Gregory Lebovitz suggested it maybe say “life cycle and validation”.


Steve Kent also alluded to the chicken and egg problem outlined by Paul Hoffman.  He noted that both choices have downsides, but the document does not sufficiently expose this.  Gregory Lebovitz asked if this meant another requirements document?  Chris Bonatti stated that he did not believe that the profile itself should be a rationale document.  Rationale should be exposed on the mailing list.  If it needs to be captured somewhere, so be it.  Russ Housley stated that he expressly wanted this to move quickly, and starting another document would slow things up.  If bits of rationale were needed then it's okay to keep them in the profile.  Bill Sommerfeld stated that he thought the rationale and the scenario needed to be exposed to vendors to aid them in implementation.  Gregory Lebovitz asked Bill Sommerfeld to take charge of this issue.


Critical Bit?  How do we handle critical private extensions?

Gregory Lebovitz suggested that we recommend against marking extensions critical except as required by RFC 3280.  He noted that we could clarify that if a critical extension isn’t recognized that it would cause validation to fail.  Steve Kent clarified that if the extension isn’t understood, then you only throw out that certificate.  Since it might be an unused cert wrt to the cert path, it won’t necessarily break validation.


Steve Kent also asked how this is any different from RFC 3280?  Paul Hoffman stated that the statement not to issue such certs is worthwhile.  He advocated not having embedded references to 3280 when the WHOLE of 3280 is already supposed to be supported.  Bill Sommerfeld stated that it would be helpful to have pointers to specific parts of 3280 that were pertinent.  Stefan Santesson agreed, but noted that it did not have to be embedded in the body of the text.  Paul Hoffman stated that this would be okay in an appendix.


Gregory Lebovitz concluded that the group saw value in embedded references.  Paul Hoffman suggested that this should then be done everywhere it applied.  Seemed this included revocation, chaining, cert path construction, and maybe naming.


2401bis Sync’ing

Paul Hoffman suggested that the question needs to be defined better.  Steve Kent stated that IPSEC is going ahead with definition of additional identity payloads.  This WG is only interested in scenarios involving certificates, but that isn’t the whole world.  He noted that there are a lot of places citing Security Policy Database (SPD) lookups that should be Peer Authorization Databases (PADs).  However, it is not a global.


Paul Hoffman noted that without this, the profile will be only an IKEv1 document.  David Black stated that we need to be precise about what exactly we are matching.  Paul Hoffman suggested that another approach would be to not try to keep alignment, but keep the differences documented so that we can update to IKEv2 later.  Could be an appendix or (better) a main section.


Gregory Lebovitz stressed that Brian Korver will be an editor from this point on, so we need to be sure to capture the resolution of this well for him.


CDP/AIA Inclusion?

Gregory Lebovitz proposed that we SHOULD send, MUST be able to process, must accept certs without it.  Paul Hoffman stated that he didn’t like the SHOULD because it may hobble implementations that don’t know how to do revocation without them.  He suggested that this is a local question within the enterprise.  Gregory Lebovitz indicated that this is a bigger question for some scenarios than others.  He characterized the differences between a VPN peer and a large-scale gateway doing this.  He indicated that is really hard for us to pre-judge this.  Stefan Santesson noted that in some use cases (like short term <10 min lifespan) you should never do revocation checking.


Steve Kent noted that it is really hard to know where to go (via (2) and (3)) in the cross-organization case.  Steve Kent also stated that push to (2) and (3) makes no sense, because the question of including CDP/AIA must be dealt with in (1).  Gregory Lebovitz noted that this was unclear in the slide, but really meant that you never include these and rely solely on the certificate management interaction to do all life-cycle things.


Key Usage and EKU

Discussion was deferred to the list.


Paul Knight asked for a consensus on accepting the document as a WG item.  Several were in favor and none opposed.



Profiling Use of PKI in IPSEC WG
Proposed PKI4IPSEC Certificate Management Requirements Document
Status report for draft-ietf-ipsec-pki-profile
(Potentially) Open Issues