2.7.11 Profiling Use of PKI in IPSEC (pki4ipsec)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.
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

Last Modified: 2005-10-03


Paul Knight <paul.knight@nortel.com>
Gregory Lebovitz <gregory-ietf@earthlink.net>

Security Area Director(s):

Russ Housley <housley@vigilsec.com>
Sam Hartman <hartmans-ietf@mit.edu>

Security Area Advisor:

Russ 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.

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

Goals and Milestones:

Done  Post Certificate Profile and Use in IKE as an Internet Draft
Done  Post Management Protocol Profile Requirements as I-D
Done  Rev Requirements for management protocol profile as needed
Jan 2005  Submit Certificate Profile and Use in IKE as WG last call
Feb 2005  Submit Requirements for Management Protocol Profile as WG last call
Mar 2005  Submit Certificate Profile and Use to IESG, Proposed Standard
Mar 2005  WG decision on other Enrolment/Management protocols to profile
Mar 2005  Submit Requirements for Management protocol Profile to IESG, Informational
Apr 2005  Post CMC for IPsec VPN Profile as Internet Draft
May 2005  Post other enrolment/management profiles as I-D
Jul 2005  Rev CMC for IPsec VPN profile as needed
Jul 2005  Rev other enrolment/management profiles as needed
Sep 2005  CMC for IPsec VPN profile to WG last call
Oct 2005  Other enrolment/management profiles to WG last call
Oct 2005  Submit CMC for IPsec VPN Profile to IESG, Proposed Standard
Nov 2005  Submit other Profiles for enrolment/management to IESG, Proposed Standard
Dec 2005  Re-charter or close


  • draft-ietf-pki4ipsec-ikecert-profile-06.txt
  • draft-ietf-pki4ipsec-mgmt-profile-rqts-03.txt

    No Request For Comments

    Current Meeting Report

    Pki4ipsec minutes – IETF64  by Will Ivancic (an innocent bystander)
    Agenda for PKI4IPSEC
    Profiling Use of PKI in IPSEC WG  
    TUESDAY, November 8, 2005
    1740-1840 Afternoon Session III 
    Salon 1 
    AREA: SEC 
    Min	Items
    10 - Blue sheets, scribe, and agenda bashing
    20 - Profile Document -06 revision update. EKU issue. WG Last Call?
    Stefan Santesson – sent comments to mail list regarding EKU.   
    Bill Sommerfeld -  many implementations may want to include a knob to turn this off.  Probably should not be a requirement, but might need a knob to turn this off.
    Stefan – Even if we know people will implement, 
    Comment from somewhere - People may be stuck using a certificate.  Want a switch to be used for security policy reasons.
    Tim Polk (NIST)- EKU is for people to know how to use the extension.  If extension is non-critical, you do not have to process this extension.  If you want to handle critical EKUs one needs this.
    Bill Sommerfeld – Question:  in a layered modular implementation using PKI, what does the critical bit mean if library supports it but application doesn’t understand this?
    Tim Polk – CA being operated without a good understanding of the use of EKU is most of the problem.  One can be specific and say "use only for these applications," or one can say "it is there, use it as one wishes."
    Stefan – EKU is defined to mean a specific extension.  We cannot redefine the meaning here.  The text is doing this.
    Gregory – We really are not redefining it here.  We are saying that we do not care how this is used.
    Jim Schaad - Difference between implementers doing things and us helping people doing things that is just right.
    Bill Sommerfeld – adding an EKU is not critical. Should resolve conflict with RFC3280.
    Michael Richardson – with respect to PKI people, we are trying to clean up a mess.  Without proper text, buyers cannot backup and policy their vendors.   Leave text as is.  It says “buy configuration”.
    Stefan – If one can process this extension one has to process it.  If you cannot process it and it is non-critical, then that is OK.  
    Tim Polk – change bullet to say if the implementation cannot process …. Then ….   If an implementation is configured.  If CANNOT process than we do not care.    We cannot just say we will ignore extensions if they are there.  
    Tero Kivinen – maybe not have the extension.  Regardless of what we put, people will probably do what they want.  It will be in product regardless of what we say.
    Richard Gray.    WG will write profile x509.  Not data constructs
    Tim Polk – causes additional problems if last bullets over ride first bullets.
    Stefan – Does not agree with wording “should not”.
    Request from chairs to resolve.  Should we allow to ignore if non-critical?  
    Gregory Lebovitz – if we do not encourage people to put switch in, there will be problems. 
    Michael Richardson – message has to be sent to PKI library vendors that we need switch.
    Gregory Lebovitz –   …….
    Stefan – to disallow or not allow a library to carry an implementation is not good.  This is an application issue and should not be performed in the library.
    Gregory Lebovitz – Will this be in products provided by vendors?
    There is a reason to do this.  It is consistent within the document that this switch exists.
    Tim Polk – maybe so, but this is not a good idea.  May create security risks.  If there isn’t a constraint on how the key is used, then constraint shouldn’t be there.  Extensions are not in there by accident.
    Stefan – What is the problem?  Are we stuck with CA issued stuff that we cannot use.   Should we write protocols that allow us to ignore what we do not like.
    Gregory – We are on 7 years of one path.  Agree with Stefan in principal, but reality says otherwise.
    Tim Polk – The problem is there is not a stable set of requirements.  This document helps get a stable set of requirements.  If we do not hold people to requirements, we will not get anywhere.  We need to give implementers a stable target or do we allow continual work arounds.
    Bill Sommerfeld – Perhaps we need to put in an escape clause.  
    Tim Polk – Agrees with Bill’s suggestion.  Should be seriously considered – perhaps placed at the appendix.
    Russ Housley – Frustrated.  Issue Last call, Fix it, and be done with it.  The issue is very small aspect and the rest needs to get out.
    Michael Richardson -  need to consider Internationalization and Nationalization issues.  When IDs come in from elsewhere, we need to consider them.
    Gregory – 
    Tero Kivinen – do we want to say something about HASHes for signing algorithms? 
    Bill – algorithm choice within the certificate is implementer's choice.  Perhaps indicate reference to current best practices, etc….
    Gregory – should we remove bullet – put escape clauses for everything or should we leave bullet and ignore is non-critical?  
    Sharon Boeyen – Make statement upfront that EKU is not required.  
    Gregory – This is already in text 
    Stefan – prefers general escape clause.  Thus there is no violation.  
    Tim Polk – The text is what CAs should do.  Not until one gets to logic flows does one get to implementation.   Still add in security section something about denial of service.   You do not need to support this EKU extension if you are a client.  However, if you do process this, here is how to process it.
    Gregory – it is one out of one thousand customers that uses this.  Now certs have EKUs.  Now they are using EKUs for other things.  Or they issued a bunch of certificates with EKUs but now do not want them used for IPSec.  So this is a corner case.
    Bill – just added text to mail list.   
    Stefan – Bill’s text carries security implications.  So something needs to be in security section to address this.
    Tim Polk – agrees with Stefan.
    Gregory – Proposal is go add Bill’s text to 4.1.3 Intro, remove some text in and and add text in security section. (Gregory captured text on screen.)
    Paul Knight – text will be put into document, sent to mail list and put out for last call.
    Michael Richardson – this is exactly why we have face-to-face meetings, to work things out and reach a consensus.
    Final two items on the agenda will be addressed on the mailing list:
    20 - requirements document. review. Path to WG last call?
    10 - Re-charter to:
            - remove CMC profile work. We seem to be out of steam on this.
            - update the dates


    Chair Slides
    IKE Certificate Profile