2.6.13 Profiling Use of PKI in IPSEC (pki4ipsec)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. 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-06-27


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,
    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
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
not be addressed. Long term non-repudiation will also not be addressed.

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


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

    No Request For Comments

    Current Meeting Report

    1. Profiling Use of PKI in IPsec WG (pki4ipsec WG; SEC Area)

    IETF WG Meeting Paris, France, Wednesday August 3rd 2005

    Chairs: Gregory M. Lebovitz gregory-ietf@earthlink.net
    Paul Knight paul.knight@nortel.com

    Review of Milestones, Chairs

    The WG is about six months behind schedule. It is about to submit the Certificate Profile ID to WG LC; then, the Management Profile Requirements within a month or so.

    Profiling the Use of Certificates with IKEv1/ISAKMP/IKEv2 for IPsec, draft-ietf-pki4ipsec-ikecert-profile-05 - Presented by Greg Lebovitz

    Version 04 was released in December 2004

    As of July 27th, a new version was just submitted after the deadline and can be found at www.icsalabs.com/pki4ipsec.

    Slides from Brian Korver are also at the ICSA site.

    This is a PKI Profile for IKE, ISAKMP, and IKEv2 using PKIX certificates as the authentication mechanism. Version -05 addressed about 12 open issues. Three remain. See the changes in Section 3.1.

    The document describes matchings of Certificate Attributes with an IKE Identity payload, to enable matching and validation. But policies that permit or deny may be different and were not clarified in RFC 2401. Now, rfc2401bis has a PAD, which this document now references.

    See also added text in Section 3.1.10.

    An issue tracker is in use. One issue remains: it was deferred to the end of the meeting.

    Consensus, otherwise, was to go to WG LC.

    Requirements for an IPsec Certificate Management Profile, draft-ietf-pki4ipsec-mgmt-profile-rqts-03, Jim Schaad

    After the last meeting, many editorial changes were made. Many were minor: removed non-repudiation, community realm concept, update type field, and manual approval option; replaced printable string with UTP8 in the authorization token; capitalize IPsec correctly; removed normative use of "can."

    Duplicated material was stripped out. Sections were reorganized based on functions. A major section now exists for each management function. A Trust section was added. The Abstract was corrected to state that Admin-Peer transactions are *not* within scope.

    The architecture was missing some interactions: added [G] and [M] between PKI and Peer/Admin; added [G], [E], [M], and [R] between Peer and Admin; renamed two other items

    The remaining work is to collect the Requirements in an appendix and the Operator Options in another appendix.

    Reviewers are needed to try to get to WG LC in September.

    A major discussion topic followed:

    Ref : https://newlabs.icsalabs.com/pki4ipsec/Certificate%20Management%20Models.ppt

    One open comment was then presented by Stefan Santesson: The item missing from a generic model of the management domain is a database from which the system can be administered and accessed by the different entities. Then, schema, templates, etc., can be defined.

    GL: It was pointed out that this is a major restart for the document.

    SS: The viewpoint was that data exist first, and a CA is added after that.

    GL: The reply was that this looks like a "use case."

    Bill Sommerfield: It is hard to pick a database everyone likes, so defining the interfaces is hard.

    SS: The protocol flows with a database model may be quite different. There are performance differences.

    JS: How much of this is "VPN Admin to VPN entity" specific? Answer: Quite a bit.

    GL: Have systems in the marketplace changed enough to make this change advisable now?

    Chair: This needs to be documented, preferably in an ID. Then, discuss on the ML whether to reopen this as a use case.

    RH: There are multiple ways the WG can resolve this on the ML. Clarification paragraph at the beginning of the document, with the recognition that there are other use cases

    Unidentified speaker: This should perhaps be a separate use-case informational document?

    RG: The ML should sort out whether this model is a compatible use case or not. Then, whether it wants to add this case to the original Informational RFC as a use case, rewrite the document completely, or produce a second one.

    The Open Issue with the ikecert-profile: Key Purpose OIDs, R. Housley et al.

    Ref: - https://newlabs.icsalabs.com/pki4ipsec/PKI4IPsec%20use%20of%20the%20ExtendedKeyUsage.ppt

    Many key purpose OIDs were almost included in RFC 3280. They were assigned but not used. The current document and WG consensus deprecate these. Client processing supports this approach under EKU (extended key usage) processing. The open issue is whether to support a certificate validation library that allows for many applications on a given platform. In this case, EKU is helpful to ensure that certificates are used as intended. But the OIDs have not been used, perhaps because they were assigned somewhat haphazardly over time. There are three somewhat relevant OIDs: id-kp-ipsecEndSystem, ip-kp-ipsecTunnel, and id-kp-ipsecUser. But actually, a new one is needed. Should non-critical EKU extensions be ignored? This may not be advisable.

    BS: The old three OIDs should be ignored. One new one is acceptable. In constrained cases, the IPsec rfc2401bis PAD can specify the EKU. The core issue is how to handle certificates that can be used with IKE and something else.

    The proposal was to accept the certificate in the case in which an EKU extension is present and either anyExtendedKeyUsage or <new-ike-oid> is included. There was also a request to delete the case in which the configuration is to ignore a non-critical EKU.

    Draft -05 will make this change. The consensus, then, was to go to WG LC.

    Discussion: Interest in a CMC profile for IPsec/VPN use? Chairs

    This is within Charter, but it is unclear whether there are resources to complete it. VPN vendors appear interested, but PKI vendors do not seem so. Dropping this part of the charter got a medium hum. Keeping it got silence. The decision will be vetted on the ML.


    PKI4IPsec: Management Profile Requirements
    Certificate Management Models
    PKI4IPsec use of the ExtendedKeyUsage Certificate Extension