Profiling Use of PKI in IPSEC (pki4ipsec)

In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at: -- Additional PKI4IPSEC Web Page
NOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, California USA. It may now be out-of-date.

Last Modified: 2004-05-26

Paul Knight <>
Gregory Lebovitz <>
Security Area Director(s):
Russell Housley <>
Steven Bellovin <>
Security Area Advisor:
Russell Housley <>
Mailing Lists:
General Discussion:
To Subscribe:
In Body: (un)subscribe
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
  • - draft-ietf-pki4ipsec-ikecert-profile-01.txt
  • No Request For Comments

    Current Meeting Report


    pki4ipsec WG Minutes


    (taken by Brian Ford)


    Wednesday, August 04, 2004

    Gregory M. Lebovitz <>  GL
    Paul Knight <>

    Agenda bashing, blue sheets, scribe selection


    2 agenda slides


    Milestones updated slide


    All docs are posted at:



    Review draft-ietf-pki4ipsec-certlike


    Review of draft by

    Brian Korver [BK]


    Reviewed changes to draft


    Revised doc incorporates IKE v2


    Reviewed all changes as per slides


    Review of draft-ietf-pki4ipsec-ikecert-profile-01.txt

    By Gregory Lebovitz [GL]


    Reviewed changes from -00 to -01 and explained certain changes


    Paul Hoffman [PH]:  Notes that some of the discussions on list regarding certs with embedded IPs had not reached conclusion


    GL: Clarified position.  Don’t use IP address as identity or in certs.


    Bill Sommerfield [BS]: If you are building a network where IP are fixed, it's OK.  If you are building a network using certs this wording works.


    PH:  Paul agreed with the idea but didn’t feel the list had reached consensus.  Paul identified the different audiences for the draft and noted that this recommendation needs to be clear that this is aimed at certificate administrators.


    For issues list: needs a reference about building certs with embedded IPs


    Suresh:  If IP is used as ID then do you say that the IP must match the IP in the header


    GL:  By transitive property that is true.


    BS:  What about multiple IP header case?


    GL: So this should only be in the outer IP header.


    Suresh [S]:  Shouldn’t this at least do the same checks as pre-shared keys.

    GL:  yes


    ??:  Pointed out case of IP v4 embedded in IP v6.  Couldn’t this be a problem.


    GL:  Agreed.


    PH:  Editorial suggestion.  4.1.3 is not advice to certificate authority (CA) administrators.  You must more clearly delineate when you are making suggestions to specific audiences.  Document specifically needs to be clearer for CA admin audience.  Doesn’t think that this was addressed on list.


    ??1:  Agrees IP addresses should not be IDs.  Agrees that matching IP addresses in headers should not be mandated.


    PH:  Feels strongly that we need more consensus about IP address matching recommendations on list.


    GL:  Let's compromise that IPs shouldn’t be used.


    [Discussion about consensus on this topic on list.]


    BS:  Doc needs to be targeted at CA admins but also at CA implementers.  It would be helpful to have someone from that community to help here.

    GL: Agreed.  GL has tried to invite folks from that world in here.


    S: Can I say the responder doesn’t have to say what cert path he wants his cert auth’ed against?

    GL:  Defines how the response should be structured through the empty cert req.


    S: Points out that this may not be consistent with SSL


    PH: Seeking clarification about the cert req exchange. 

    GL:  It’s in the doc.  You know the policy that caused you to initiate.


    Big Open Issues slide

     22 issues

    4 or so are big


    Key Use (KU) and extended KU (EKU)

    Reviewed text


    BS: Would suggest “do not reject cert because..” language that is on later slide.


    Cheryl Madsen [CM]:  So what does PKI buy us here???




    BS: In PKIX docs there is an EKU value that says “do whatever you want”

    GL: All uses?


    Russ Housley [RH]: The reason for that is to accommodate certs written for specific applications.


    GL: So this an update to issue 22

    GL:  Note that info on slide “Proposal” is not in doc and is a proposal


    PH:  Clarify the use of the word “Critical” in this use

    RH:  Agreed


    GL, RH, PH, BS, Steve Kent, others:  EKU handling and the proposal slide?  In some cases the exchange completes but the app should not execute.


    Consult with RH about use of SHOULD and SHOULD NOT language.


    GL:  Will float a new proposal to list


    Stefan Stessanson [SS]: We cannot rely on applications to understand these setting. 


    BS: We should probably doc that you shouldn’t share IPSec CAs with CAs for other applications.


    PH:  Can you add the summary on “SUMMARY KU/EKU” in doc

    BS:  Needs to be revised to note criticality.  Could be re-structured a bit better.


    Issue #38  HTTP Cert Lookup slide


    Charlie Kaufman volunteered to help here.


    ??:  This is a useful but misunderstood feature.  Short explanation of Cert req type followed.

    BK:  Agreed.

    GL: Agreed


    Sync to 2401bis slide


    Steve Kent [SK]: Short explanation of issue #10 on slide and 2401bis.


    GL:  Discussion of SPDs, matching and traffic selectors.


    SK:  Explained 2401bis current doc status and direction.  Opportunity exists to fill in details not in 2401bis.


    GL:  We’ll beef up that section


    Next Steps slide


    GL:  BK hopes to release an -03 shortly based on changes defined at this meeting and in next weeks.  Will seek last call by end September.


    PH: Why are we waiting for the end of September?


    GL:  Get you issues out on list soon


    End with pic of GL’s daughter


    Review of Requirements for an IPsec Certificate Management Profile

    Chris Bonatti [CB]


    CB: Explained changes to draft


    Big Issues (2) slide


    GL:  Question about if you are interacting with an RA or CA …

    CB:  We want to be able to do it that way but not require it.


    Big Issues (3)


    GL: Seeking input on “Do we need to create a template…”

    PH: defined Project Deploy use case and experience

    Steve Barrow [SB]:  CMC changes would not be required




    SB:  Questions about requirements, scope XKMS, and CMC

    CB:  Not sure

    GL:  Described direction and the development of profiles.  Maybe addressed in a future profile. Let's get work done and see about handing this later.  Comments about CMC and XKMS adoption.


    Mike Meyers: There has been a submission about integrating OCSP and IKE v2.  Some consideration is underway.


    SK:  What needs to be addressed is if the model says certs will be retrieved via HTTP the docs need to fully reflect this HTTP based system.  The security issues in play here need to be fully disclosed and discussed.


    SK:  Discussion of what device would be a server for these certs and where it would be placed. 


    BS:  Discussed some real world experiences with these deployments


    Max Pritikin [MP]:  yes we are seeing people deploy CRL servers outside of the firewall.


    GL:  Always looking for help and editors



    The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX
    Proposed PKI4IPSEC Certificate Management Requirements Document