2.6.10 Profiling Use of PKI in IPSEC (pki4ipse)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-10-07


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

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 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 often
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 IKE.
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 to
get products that support these technologies to work together nicely in
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 addressed.
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
Sep 04  Submit Certificate Profile and Use in IKE as WG last call
Nov 04  Post CMC for IPsec VPN Profile as Internet Draft
Dec 04  Submit Requirements for Management Protocol Profile as WG last call
Dec 04  Submit Certificate Profile and Use to IESG, Proposed Standard
Dec 04  WG decision on other Enrolment/Management protocols to profile
Dec 04  Rev CMC for IPsec VPN profile as needed
Jan 05  Submit Requirements for Management protocol Profile to IESG, Informational
Mar 05  CMC for IPsec VPN profile to WG last call
May 05  Submit CMC for IPsec VPN Profile to IESG, Proposed Standard
Jun 05  Re-charter or close


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

    No Request For Comments

    Current Meeting Report

    Profiling Use of PKI in IPSEC (pki4ipse) Notes

    Profiling Use of PKI in IPSEC (pki4ipse) Notes

    Scribe John McLaughlin, johnmcl@us.ibm.com


    November 10, 2004



    Paul Knight <paul.knight@nortelnetworks.com>

    Gregory Lebovitz <gregory-ietf@earthlink.net>


     Jabber scribe: Bill Sommerfeld


    1.  Notes Structure


    Key Decisions

    Next Steps


    2.  Agenda and Milestones



    (Paul Hoffman)  Paul raises points out that thereís little traction being made on his issues.  He thinks his issues could swamp the last call, so recommends not going to last call on management protocol profile.


    Key Decisions

    (Russell Housley)  Milestones approved


    Next Steps



    3.  Status of draft: "Requirements for an IPsec Certificate Management Profile"



    (Barbara Fraser)  Barbara raises questions on the VPN admin role and the relationship of the admin role to work being done in other working groups.  She points out that the author appears not to have investigated that relationship.  That lack of investigation may cause conflict with other working groupís direction.


    (Gregory Lebovitz)  Gregory points out that the VPN admin function does not have definition or content beyond the scope of the PKI interaction.  The admin function is not a loaded term implying anything more than the authority in the document.  The function is simply an administrative function brokering communication services between IPSEC peers and the PKI system.  In addition, the function is not necessarily a stand alone device and could be co-hosted on the same platform as other functionality.


    (Paul Hoffman)  Paul sees the templates out of scope as the functions are out of scope.  Some basic components can be defined, but the external entity will define the rest of it.  He recommends not defining anything more than the base requirements.  He also notes  that the template will be human completed.  He thinks the content will be human defined so donít add more requirements or components


    (Gregory Lebovitz)  Gregory replies that the template format is defined so explicitly so that other CA vendors can interact.  Human interaction happens once for each individual registration so the specificity is probably not more than a one-time challenge.


    (Paul Hoffman) Asks if the scope of the VPN admin function is all X.509 attributes?  Author suggests that PKI negotiation will define the attributes.  Suggests that content is in excess of X.509 attributes.  Authorization attributes are an example.


    (Paul Hoffman)  CMC must change to be able to deliver desired qualities.  Paul has a concern that the level of change could be bigger than expected.  To protect against expanding change content, he wants to scope down the change capability.   To facilitate such, he suggests strong coordination with other working groups.


    (Gregory Lebovitz)  Gregory recognizes the above issues and points out the need for quicker resolution.  To facilitate quicker resolution, Gregory proposes an interim gathering of the WG.  Gregory takes the action to drive the interim meeting.


    Key Decisions

    An interim meeting will be scheduled for further work on  "Requirements for an IPsec Certificate Management Profile"


    Next Steps

    (Lebovitz) Schedule the WG Interim Meeting. 



    4.  Status of Draft and Review of Changes Between -01 and -03:    "The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX" (Brian Korver),




    (Gregory Lebovitz) Challenges CDP mandatory text can be removed. 


    (Paul Hoffman)  Paul disagrees that the negotiated settlement holds non-important content.  If entities can not rely on the CDP, then they must alternatively agree to the revocation process in advance.  In short, CDP text is not needed.


    Now onto issues 654 and 576.    The question is amount of content in certificates.  The question is reformed as to the degree of intermediate trust chain content.  The alternatives are to send everything in band or send only the minimal set of attributes.


    (Michael Richardson)   Michael points out that at the PMT meeting yesterday this idea was discussed.  The general consensus was to use IPsec and except for UDP issue, let people put as much content in as they wish.  Gregory Lebovitz asked how the UDP fragmentation issue was solved while including in-band intermediate certificates.  Without changes to IKE, Michael says no.  Michaelís position is forbid what people are going to do in normal course of business.  He also points out there should be some method for long chains.  Alternatives include IKE level fragmentation process or simply sending more packets.  Michael said his experience shows that VPN has broken on several systems and hosed up the UDP level.


    (Bill Sommerfeld)   Bill points out that the answer  may be to come up with a viable out of band (OOB) mechanism.  Donít bar in-band techniques through preclusionary specification until a viable out of band capability exists.  Gregory Lebovitz points out that the current RFCs do specify what an out of band mechanism is.  Gregory states there are out of band mechanisms available, just not specified.


    (Steve Kent)  It is reasonable to expect that certificates can be gotten by a single individual.  Donít use CMP/CMC as examples.  He also points out that UDP fragmentation is still the big issue.  Steve also agrees with Bill and Michael that a concrete description for an alternative should be in place prior to directing not to use in band processes.  He then speaks to infrastructure complexity. He draws an analogy showing the conflict within the security group being both paranoid and ready to relax complexity.  The example in front of us is that we favor of sending revocation in band and look for out of band solution. 


    (Charlie Kaufman)  Charlie prefers solutions that are backwards compatible.  PKI accessibility is a challenge for any out of band transmission technique.  Storage is a challenge too.


    (Paul Hoffman)  Paul agrees with Steve.  He thinks the problem is larger than UDP fragmentation.  He points out that each certificate has revocation information.  That revocation information needs to be transmitted too.  One can either can send the intermediate certificates and all revocation information or one doesnít need to send intermediate certificates.  He also agrees that an out of band solution is better and consequently we wait for an out of band solution.


    (Wes Hardaker)  Wes thinks we are not determining the target audience.  The challenge is that a lot of information needs to be sent in a protocol that doesnít support it.  One option is to solve the simple problem first.  The larger problem is that the infrastructure does not support the solution.   Proposes that an 80% solution could be more desirable than a more complete solution delivered far into the future..


    Wes also recommends that trust anchors are not to be sent in band.  Concerns are that infrastructure canít support all functionality.  Suggests that the number of people using intermediate certs is pretty small.   Does not see need for in band revocation information to be sent.  Recommends finishing the profile and publishing.  Then fix the problem for he small number of people using it.


    (Stefan Santesson)  Stefan sees another problem in that revocation information may need additional certificates, which might need revocation information of its own.


    (Bill Sommerfeld)  Bill accepts the idea of an OOB roadmap, even if it's not here yet.


    (Russell Housley)  Russ has an alternate position.  He sees it desirable to nail down what we can nail down now.  He recommends leaving out OOB and move forward on the rest of the stuff.


    (Michael Richardson)   Michael speaks that cert chains are difficult to test and inject uncertainty.  The point is that the payload can be either well defined or just pushed off to another function.


    (Charley Kaufman)  Observation on unsolvability of problem.   Decision is between an implementable standard now and those that look for viability of an alternative decision.


    (Steve Kent)  Alternative is put a reference in text that we are not addressing intermediate and OOB or not.  We are addressing format of the profile.  Publish that OOB decision and implementation is coming later.  Leaves acquisition method undefined. 


    (Hank Mauldin)  Reminds the group that the charter says donít break any functionality and heís concerned that a poorly implemented OOB decision will break functionality.


    (Paul Hoffman)   Puts forward the question on whether OOB would be used if a viable mechanism was available.   He recommends moving forward on list discussion on the question.


    (Michael Richardson)  Michael sees existing deployments as a red herring.  He points out that implementations will be 4001 compliant or not.  The real question is what would we do if this was a blank slate?


    (Wes Hardaker)  Wes points out that network operators should be polled.  Gregory points out that network customers just want it to work.


    Key Decisions


    Forbid CRL in band.  Refer to coming work for OOB acquisition.  Pass by consensus

    Allow CRL in band.  Failed by consensus


    Forbid intermediate certs in band.  Failed

    Allow intermediate certs in band.  Passed by majority


    Do we prefer IB ideally?  Some small number of hummers

    Do we prefer OOB ideally?  Some incrementally larger number of hummers.


    Proceed with draft and address intermediate certs.  Strong majority

    Proceed with draft and remain silent on intermediate certs.   Minority present


    Next Steps 

    Captured in brief by Brian

    Resolve issues

    Submit 04 draft

    WG last call


    5. "Refining the IPsec Peer Authorization DB" - presentation by Steve Kent




    (Michael Richardson)   Michael indicates that the NOT condition on SA constraints is not sufficient.  Proposes that logic condition is a lot more complicated than presented.  Recommends that Buttons WG work out the details.


    (Bill Sommerfeld)   Questions Steve Kent on his intent that the brief be turned into a draft.  Steve Kent replies yes if it can be done quickly. If not, then its separate draft to be considered at the next IETF meeting.


    Key Decisions


    Draft evolution is to done on the list by consensus (hum).


    Next Steps


    Participation level to increase.  Deadlines have been missed.  One of those move-out kind of things.


    Proposed PKI4IPSEC Certificate Management Requirements Document