2.6.11 Profiling Use of PKI in IPSEC (pki4ipse)

NOTE: This charter is a snapshot of the 62nd IETF Meeting in Minneapolis, MN USA. It may now be out-of-date.

Last Modified: 2005-01-24


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

Security Area Director(s):

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

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 PKI X.509
certificates have been specified within the IPsec standards for the
same rime. However, very few IPsec deployments use certificates. One
reason is the lack of a certificate profile or description about how
the various elements of a PKI ought to be constructed and how the
contents ought to be populated for use with IPsec. In addition, the
handling of certificates in various IPsec use cases requires better
description. The lack of such specifications has yielded PKI systems
whose support for IPsec applications is too obscure, complex, and
feature incomplete. Also, support within the IPsec systems for
interaction with the PKI is often equally complex and incomplete,
leaving deployers without interoperability.

Within IPsec VPNs, the PKI supports authentication of peers through
digital signatures during security association establishment using
To date, SCEP and "cut-and-paste" techniques are more commonly used to
accomplish end entity certificate acquisition for IPsec VPN usage, but
are better suited to small VPN deployments, and are out of scope for
this solution. A robust certificate management scheme is needed to
empower operators in large scale deployment and management efforts.
Multiple competing and incomplete protocols for certificate
acquisition, renewal and revocation exist today.  Deployers struggle
get products that support these technologies to work together nicely
order to accomplish their goals.

The protocol and PKI operational usages are considered in order to
define a common, single set of methods (which forces interoperability)
between PKI systems and IPsec systems for large-scale deployments. The
requirements address the entire lifecycle for PKI usage within IPsec
pre-authorization of certificate issuance, enrollment process
(certificate request and retrieval), certificate renewals and changes,
revocation, validation and repository lookups. They enable an IPsec
operator to:
  - authorize batches of certificate issuances based on locally
  - provision PKI-based user and/or machine identity to IPsec peers,
    large scale
  - set the corresponding gateway and/or client authorization policy
    for remote access and site-to-site connections
  - establish automatic renewal for certificates
  - ensure timely revocation information is available and retrievable
Requirements for both the IPsec and the PKI products will be
The goal is to create a set of requirements from which a specification
document will be derived. The requirements are carefully designed to
achieve security without compromising ease of management and
deployment, even where the deployment involves tens of thousands of
IPsec users and devices. These requirements will be used to identify a
specific protocol that may be leveraged to accomplish such large-scale

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-03.txt
  • draft-ietf-pki4ipsec-mgmt-profile-rqts-02.txt

    No Request For Comments

    Current Meeting Report

    pki4ipsec summary for saag

    Profiling Use of PKI in IPSEC (pki4ipsec)


    Monday, March 7 at 1530-1730



    Paul Knight <paul.knight@nortelnetworks.com>

    Gregory Lebovitz <gregory-ietf@earthlink.net>


    The minutes reported here consist of two parts: a summary, and details noted by Nico Williams.  Many thanks (and $4.00) to Nico for his efforts.




    The pki4ipsec WG addressed two current drafts:


    (1) "Requirements for an IPsec Certificate Management Profile,"


    Most of the WG meeting was focused on this draft.


    This draft describes the requirements for a profile of a certificate management protocol to handle PKI enrolment (certificate request and retrieval) as well as certificate lifecycle interactions (certificate renewals/changes, revocation, validation, and repository lookups) between IPsec VPN systems and PKI systems.


    Key decisions:

    - The authorization ID and token formats need to consider internationalization (i18n) requirements such as the use of UTF8, and explicitly describe the reasons why the format is chosen.  stringprep may be appropriate for the passphrase (token)

    - Enrollment TYPE field currently has change/renew/re-key values.  A consensus call on this point resulted in a decision to drop the requirement for secondary request type -- no update/renew/rekey, just enrollment and renewal.  This should allow removal of the TYPE field. The consensus was unanimous.

    - There was also unanimous support for recognizing that there are still requirements for changing, renewing, and rekeying, but the TYPE field is not the way to address these requirements.

    - There was no clear decision at the meeting on whether to remove from requirements the ability to have the PKI (not admin or peer) to generate key pairs.  This will be decided on the mailing list.

    ACTIONS:  Document authors to issue a call for consensus on the mailing list to validate the decisions, and to decide on the undecided issue.  Then update the document to reflect WG decisions, and make a WG last call.


    (2) "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX,"


    Due to a series of unfortunate events, this draft was not discussed in detail

    - Author unable to attend IETF 62

    - Although submitted in January, the updated draft never appeared in IETF repository.

    ACTIONS: Chairs and author to ensure draft is available on IETF site.  It is currently on the ICSA site, http://www.icsalabs.com/html/communities/pki4ipsec/draft-ietf-pki4ipsec-ikecert-profile-04.txt.


    Other decisions:

    Jim Schaad will begin as author/editor of a profile or protocol document to address the requirements described in draft (1) above.


    FUTURE: Move drafts (1) and (2) to WG last call ASAP, focus on new draft.


    **************** End Summary ***************


    Detailed minutes




    Speaker (Sean Turner) describes interim meeting, talks through slides


    Talked about confirmation handshake, no consensus -> need to go to list.


    Internationalization (I18N) issues for "authorization token format" -- questions from floor: what is that?


     Chair: "Whoever is working with the PKI admin is going to gen for a user or set of users an ID and a passphrase, which will be communicated to the End Entity (EE) somehow, OOB."


    From the floor: "Anything that doesn't do I18N will get bounced by the APPS area." (Marcus Leech)


    Back and forth, Sam Hartman and chair,

     "what's this for, who gens it"

    "it's an ID, it's genned by the admin"

    "so it can be all-ASCII, but does it have to correspond the user's name"

    "sort of, (yes)"

    "so then you MUST do I18N, learn about stringprep or this will be blocked"

     "so why aren't we internationalizing this, because it's hard?"


    someone says "we can I18N the ID part, but don't want to I18N the passphrase"


    all: :) "no, you can and should stringprep the passphrase"






    Issue: 'Enrollment TYPE field'


     How to figure out change/renew/re-key type?


    Whether to specify type or let peer figure it out and do the right thing.


      -> Take it to the list


    Issue: 'Cancel/New Auth -- need new identifier for replay protection'


    Issue: 'DNS support for PKC path lookup and revocation?'


    Issue: 'Certificate Authority (CA) state info needed'

    "The CA will have to maintain some state, it's pretty obvious; has to be added to the document."


    Issue: 'Organization'


     'Key generation/PKC request options'


    Chair and Speaker agree to fix up text/figures, let WG decide key gen issues.




    Chair: People should review, contribute to the requirements document.



        'CMC and PKI4IPSEC'

        Speaker: Jim Schaad


    Issue: 'What does a MAY really mean in a reqs doc?"

    Issue: 'What does a SHOULD really mean in a reqs doc?"

    Issue: 'Reqs on admin <-> peer connections'

    Issue: 'Reqs on PKI structure and other structures in the system'

    Chair: "Can you give an example"

     Jim: "Like 'you have to have a repository' -- why's it there, how do you use it"


    'Pretty Picture'

    'Basic Enrollment Process'

    'Admin Authorization Process'

    'Template Creation'

    'Request Authorizations'

    'Get Authorizations Back'

    'Authorization Cancel'

    'EE Request Structure'

    'EE Response Structure'

    'Error Responses'

    'Update, Renewal & Rekey'

     Renewal -> cert is same

     Rekey -> cert content is same but pubkey is diff

     Update -> cert content is diff, pubkey possibly included



    'Renewal & Rekey'


    Jim:  What happens when a rekey turns into an update due to policy changes?


    'CMC Requirements'

    'Unmet Criteria'

    'Open Issues'

     'Queue and Manually Approve'


    Chair: "Don't want to mandate automatic process"

    Jim: "Internals of CA are out of scope for this document"

    Bill Sommerfeld: "But the reply may not be instantaneous, does the doc say this?"

    Jim: "Yes"




    Chair: "How do you define controls"

     Jim: "By OIDs"

    Chair: "So the issue 'what if the template changed...', can we discuss that?  I think the options are: yes we need renew rekey, update, or no we don't."

     Jim: "Well, the renew/rekey are easy, no need to change current behaviour...  The question is: do you allow update, or is update a new enrollment."

     Sam: "Wait does that mean that a new authz ID/token?"

     Jim: "Yes"

    Sam: "Ow"

     Sam: "Reviewing manually is different from getting a new authz token"


    Is the template tied to the DB?

     Jim: "Probably not."


     Nico Williams: "So, can new templates indicate whether old tokens must be updated, not renewed?"

     Jim: "Yes.  The DB can recall the template that had been used for a given cert."


    Stefan Santesson: "Could use an extension"



    Sam groaned.


    Russ Housley: "Would a VPN as a rule only need a single template?"


    Sam: "At a protocol level can you make it work if people are willing to store certain info?"

    Jim: "Yes"


     Chair: "Let's say nothing changes in the template, can you still renew."



     Stefan: "Why does the client need to know which of update/renew/rekey to do?" "Why can't it be told?"


    Chair: "The req that the EE be able to gen the keys forces us to have the EE involved in this"


     Someone: "Who's the most likely party to recognize that there's a security problem?"


     Jim: "What kind of attack are we looking at?  It depends on the attack."


    Chair: "Can we make a decision here?" "Does anyone object to the dismissal of the 'update' type?"


    <lots of discussion, redundant discussion, not following>


    Will go to list.  The answer from Russ is: separate authentication and authorization.


    Consensus call: "We are going to drop the requirement for  secondary request type -- no update/renew/rekey, just enrollment and renewal."  Unanimous YES.


    Consensus call: "Then, do we keep the requirements for the functionality."  Unanimous YES.


    Back to PKI generation of keys.


    Consensus call: "Remove from requirements the ability to have the PKI (not admin or peer) to generate key pairs."

    Take it to the list.










    Certificate Management Requirements Status