Last Modified: 2005-06-27
| 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 |
1. Profiling Use of PKI in IPsec WG (pki4ipsec WG; SEC Area)IETF WG Meeting Paris, France, Wednesday August 3rd 2005Chairs: Gregory M. Lebovitz gregory-ietf@earthlink.netPaul 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. |