Last Modified: 2004-05-26
THE WG WILL DELIVER:
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.
|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|
pki4ipsec WG Minutes
(taken by Brian Ford)
Gregory M. Lebovitz <firstname.lastname@example.org> GL
Agenda bashing, blue sheets, scribe selection
2 agenda slides
Milestones updated slide
All docs are posted at:
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: 22.214.171.124.2 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.
??: Pointed out case of IP v4 embedded in IP v6. Couldn’t this be a problem.
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
4 or so are big
Key Use (KU) and extended KU (EKU)
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 126.96.36.199” is not in doc and is a proposal
PH: Clarify the use of the word “Critical” in this use
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 188.8.131.52 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.
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
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] BonattiC@ieca.com
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