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.
NON-GOALS
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 <gregory-ietf@earthlink.net> GL Agenda bashing,
blue sheets, scribe selection 2 agenda slides Milestones updated
slide All docs are posted
at: Review
draft-ietf-pki4ipsec-certlike Review of draft by Brian Korver [BK] briank@xythos.com 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: 4.1.3.6.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. GL: yes ??: Pointed out case of IP v4 embedded in IP
v6. Couldn’t this be a problem. GL: Agreed. 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 22 issues 4 or so are big Key Use (KU) and
extended KU (EKU) Reviewed text BS: Would suggest
“do not reject cert because..” language that is on later slide. Cheryl Madsen
[CM]: So what does PKI buy us here??? [buzz] 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 4.1.3.12”
is not in doc and is a proposal PH: Clarify the use of the word “Critical” in
this use RH: Agreed 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 4.1.3.12 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. BK: Agreed. GL: Agreed 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
direction. 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 Questions 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 |