ÿþPKI4IPSEC 1st BOF, IETF58 (Minneapolis, MN) Thur 2003.11.13, 0900-1130 Chairs: Gregory Lebovitz Steve Hanna (pinch-hitting) Minutes compiled by Gregory Lebovitz, from notes by: Tim Polk, Brian Korver, Chris Bonatti POC Information Mailing List: pki4ipsec@ honor.icsalabs.com Info: http://www.ic salabs.com/pki4ipsec To Subscribe: http:// honor.icsal abs.com/mailman /listinfo/pki4ipsec Archive: http://hono r.icsalabs .com/mailman/li stinfo/pki4ipsec Gregory: We're here to answer the question: How do we use certificates within IPSec? What goes in them, how do you get them, how do you exchange them, etc. Goals: to guage interest, refine the charter and decide whether or not to start a WG on this topic. Rules of engagement: A non-goal is to get into the worktoday. Want to focus on clarifying questions and then save enough time for charter bashing. Will go over work that has already been done, but only to see if that work is relevant to the work of the group. Not to go into the details of that work. Please limit questions to clarifying questions. Hold comment until the Charte Bashing. PRESO: Needs Assessment from OASIS PKI TC, Steve Hanna: <see Steve's slides> - OASIS PKI TC is customers, vendors, experts and is devoted to identifying obstacles to PKI deployment - items holding back deployment: PKI support in applications and cost were top two. - This BOF addresses 3 of the 5 top obstacles identified by their survey Their Action Plan identifies a need for this sort of group - The proposed charter being considered by this BOF is narrow. That's fine, but please do not do anything that precludes use of PKI for other applications as well! PRESO: PKI for IPsec Architecture, Gregory: <see Gregory's slides> presented the architecture for PKI-VPN administration from the old dPloy document three VPN components - an admin function and two peers three PKI components - CA, RA, repository six different types of action: authorization; authorization; generation; enrollment; IKE/IPsec; maintenance; renewal Barbara Fraser: What parts of the architecture slide are in-scope and out-of-scope of the working group? Gregory: What we're basically proposing (sneak preview): what you fill in a certificate, usage, that's in scope. We also want to talk about interaction wrt request and retrieval, and validation/revocation, lifecycle maintenance. Steve Hanna: 2 things: the PKI profile document and then lifecycle management (CMC). Bill Sommerfield: IPSec isn't just for VPNs. wants to note that VPN should not be the scope, IPsec should be the scope Gregory: It's intentional. We acknowledge that IPsec has other uses, but the charter is VPN-specific. The reason is that Russ (AD) wants to charter tightly, to get done the most important immediate need and then fill in the edge cases after a possible re-charter. Bill: That makes this effort less interesting to me. Thinks the scope is too narrow. Paul Hoffman: What Gregory has put up here is the architectual framework of the 2nd part of the charter. The 1st part, the certificate formats and what is allowed in the IKE messages, and the interaction in IPsec is applicable to all IPsec. Although the working group will not all be on VPNs. Wes Hardegar?: Is there a technical reason that caused the narrowing the focus, or was it a decision that we just didn't want to deal with it. I'd rather assume it includes everything until we come across something that causes us to drop the requirement to support all IPsec. Gregory: non-technical. More of a scoping thing. General agreement that we could continue along the path with host-to-host until such a time as the host-to-host was slowing things down, or seen as a big impediment, then drop it. Max ???: Can you clarify the PKI admin function? Is this admin for VPN and PKI, or just PKI-specific? What about key generation? Gregory: Admin is something that for this WG we might just want to toss. It's part of the VPN system. This is where the policy comes from. It could exist on some management system, or it could reside in the vpn boxes. It could be a separate daemon or an integrated fucntion. It is a functional component, not a network element. Whether or not it resides on the element depends on the vendor (and they are all over the board). Key generation occurs either in the Admin Function or in the IPsec Peer element. I could also, possibly, exist in the PKI system and be passed down to the VPN Admin function or directly to the IPsec Peer element. David Berkins - doesn t understand why the authorization function is muddled up with certificate generation? Gregory - authorization label on that part of the diagram in this architecture is authorization to be issued a certificate by the PKI system. It is a request from the VPN-Admin Function to the PKI system saying, I want this device/person to be issued a certificate with they so request. NOT authorization for access to a particular system or file, nor to a match to IPsec SPD. Max ???: I'm unclear about [G] (on the architecture ASCII graphic. Gregory: [G] is out of scope here. It's how the VPN Admin function, if off-vpn-box [not located on the network element itself], communicates to the VPN Peer. It is labeled and called out so that we can be clear about it, and clearly say it is out of scope PRESO: draft-ietf-ipsec -pki-profile-03.txt, Brian Korver: <see Brian's slides> one of the editors of IPsec PKI Profile; currently in IPsec group provides a profile of ISAKMP and PKIX for use in IPsec complements IKE v1 specification still a strawman, hasn t received sufficient attention to date Scope includes: when should you send certs and or CRLs what if CERTREQ is empty etc. Current draft is -03; has not changed substantially since -02 what is needed for -04: scope to match this WG incorporation of feedback Barbara Fraser: In IPsec WG, we were busy. his document was considered separable from the core documents and did not pursue it (1) in hopes of finishing the core IPsec documents and (2) in anticipation of formation of a new group that would handle this work. glad to see this document move forward. Gregory: how much comment received to date? Brian: only about five people have submitted comments Eric Rescalora (other editor): note that issues in IKEv2 should be able to be easily addressed in this specification; Eric believes IKEv2 should be in scope for this document PRESO: PKI Profile for IPsec, Paul Hoffman: (co-author of long dead PKI Profile document) <see Paul's slides> His spec differs from Brian and Erics; Paul has different view. [doesn't have a spec, but intends to write one or co-author with Brian and Eric. just presented the main outline of the doc he will write, and highlighted contention points with Korver draft.] Scope of old specification was: · assumptions · identities · key usage · cert expiration · req d algorithms · CERT and CERTREQ payloads · path validation · cert revocation · enrollment for devices Assumptions · purpose is to identify a device · both parties need to trust the CA(s) fully · most often, parties control their own CA · PKIX is full of features that are not needed in IPsec Identities (in certificates, not in payloads) · match access rights · no need to match the IP address · PKIX naming is a mess · cert should have NULL subject name. one discriminator between the proposals is whether or not the IP address of the identified entity is bound into the certificate. Not sure whether we should just come to agreement or whether he should rev his spec. Lauri T.: I'd be surprised if an organization would delegate authorization to their CA. CA does not establish access policies. Paul: Agreed. That's the role of the organization. Eric Rescorla: the point of IKE is to create table entries for SAs and allowed IP addresses. That can either be done by treating cert identities as opaque lookup keys for a policy table or as the addresses that should appear directly in the IPsec access control table. I think both are valuable. The goal of our draft here is to make the first kind of identity not look like the second. two ways of using this; may in fact want to match IP address and reject if they don t match. This is a place where the two documents diverge and EKR believes that both models needed to be supported. Steve Hanna noted that we have started the work of the WG, but we are a BOF. Let s hear our possibilities and move on to the charter discussion. Path validation is hell but may be unnecessary Summary of Hoffman slides: · Need to make it useable without reducing actual security · Must be willing to break some implementations · Acknowledge previous efforts inadequate and fix it. PRESO: Requirements for PKI-for-IPsec Profile, from Project Dploy work, Gregory: <see Gregory's slides> published a requirements document had about ten drafts although only the last was ever publicly issued Cert management requirements (CMC was selected after a lenghty analysis and debate between CMC vs CMP. We do not want to re-live that here). Cert profile finding certs and CRLs intra-IKE considerations Effort stalled after requirements document because PKI vendors were not really interested. Still, felt the project was valid and that the output should be considered as input to this project, i.e. take the contents and lessons learned and build them into a requirements draft or fit where applicable in profile draft. CHARTER REVIEW, Gregory: Latest version of charter was emailed to list this morning. Gregory gave overview of charter, with it on overhead. Eric Fleishman (Boeing): This work would be much more valuable if it included transport mode as well as tunnel mode. Not interested in tunnel mode at the moment but transport mode would be a valuable addition for other protocols such as SNMP I also object to putting IP addresses into certificates. IPaddress is not a fit basis for identity. For example, mobile networks etc do not fit that model at all! Suggest scope of the working group should be expanded to all of IPsec, specifically to include remote access vpn and site to site vpn. Gregory: I don't see why transport mode isn't a part of enterprise-scale IPsec deployments. By VPN we don't mean tunnel mode, we are using a more loose definition of VPN than that. Steve - please hold these comments until Gregory presents the draft charter WG Deliverables: (1) standards track document that gives specific instruction on how X.509 cert s should be formatted and populated, and handled in IKEv1 and IKEv2. (2) informational document describing and identifying requirements for a profile of CMC for these systems. (3) a standards track document CMC profile Skew: favor use cases for large single domain deployments (e.g., exclude very small or gov t - to gov t, or multi-inter-domain use cases) site to site VPN or end user remote access VPN deployments. Non -goals: exclude purely PKI issues Agreement that we should focus, but take the low hanging fruit when possible, but not let such slow us down. Milestones are aggressive. Bill Sommerfeld: Asked Paul Hoffman: why he said #2 was more applicable to tunnel mode, when he thinks that it is more applicable to transport mode. Paul: doc 2 is about lifecycle& diff scenarios Bill: You see the problem as getting certs to gateways is a different problem from getting them to users. But in large VPNs, the problem may be the same. Gregory: We're here to determine if there's enough interest in forming a working group. Asked Bill: what textual change would you make to the charter? Bill: The difference isn't tunnel vs. transport, it's between centrally managed deployments vs. end-user certs, and that's the way to slice it. [some attempt was made at creating appropriate text] Gregory: We don't have to finish the charter here. I think we get the spirit of the intention. We can wordsmith offline. Bill: "Gateway" implies VPN to me. ?: I didn't understand if the last comment changed the scope, or added to the scope. I think enterprise deployments are going to want to change. End-point to end-point IPsec is going to be needed because of Wireless. Need to take that into account. More useful to consider the problems of the future (the full problem) rather than concentrating on just the scope of the problem today. Gregory: do you think waiting a year to tackle that future problem is waiting too long? ?: No, that would be okay. But don't want to disregard it now, such that we exclude it later. Hoffman clarified that using IPsec in tunnel mode between two gateways has some very different PKI considerations than using IPsec to secure applications. Gregory: Proposal: add text to charter: let's consider the full problem until it bogs us down. [agreement] Steve Hanna: stated that he did not see this as a problem. The slope that housley was concerned with avoiding was the work of ENROLL, and this doesn t approach that. Tim Polk: I've got some concerns about the scope. This charter is an improvement to the original. I believe doc #1 is the most important one, and if it was the only document this group did it would be sufficient. That's the document that really matters. Re: doc #2, there's no reason that #2 has to be about CMC. Doc #3 is where CMC would be mandated (if that's the management protocol that group chooses). Certificate management protocols are a snake pit and I don't want to see #2 and #3 prevent progress on #1. I'd like to see the milestones restructured so that #1 gets done no matter what. Gregory: Agreed. I think the snake pit experience we had with dploy was the disagreement on which cert mgt protocol to use, rather than cert mgt protocols in general. That's why we choose to go with CMC. Tim Polk: You should be able to change the acronym "CMC" in the charter and it shouldn't change the contents of doc #1 at all. If that's not true, then PKIX screwed up. Lauri T.: I'd like to remind everyone of the aggressive schedule. If we're going to meet that schedule, we do need to keep the scope limited. Tero Kivinen: I'd like to recharter this now to include doc #1 and drop doc #2 and #3. I also don't like that the schedule has the group doing all 3 documents at the same time. Paul Hoffman: Perhaps we could split the difference and drop #3, since nothing in #2 should have any effect on #1. Also, if we are explicit about CMC, proponents for other mgt protocols will stick stuff into #2 that only their protocol supports. That's a problem that we experienced in dploy. #2 needs to be completely generic. Asked Brian, have you seen anything in your work where #1 would depend on anything on #3. Brian: No. Paul: Would be happy to hold #3 as a re-charter item; believes that WG is necessary to keep them honest at this point. Gregory: acknowledged that this was probably useful, but stated that he did not want to see the work on (2) or (3) deferred for a year. Bill Sommerfeld: believes that Document 2 may have minor dependencies for Document 1. Russ Weiser: I support doing #1 and #2, and holding off on #3. Gregory: The first thing someone needs to do is to get certificates on their box. So if we only do #1 and #2, then we've moved them no closer to deployment. It may be that we have to do #1 and #2 first before we can do #3. Brian: I'd like to vote for dropping #3 from the charter. There are enough contentious issues in #1 and #2 that doing #3 is parallel is a bad idea. I also like to vote for dropping CMC from #2. Tero: doesn t agree that is the first problem. believes interoperability is the first problem. Even once the keys are in the boxes it is hard. Paul: really need to do 2 first. writing requirements and implementation spec in parallel is a mistake. EKR: recommend re-chartering later to handle 3. Gregory: I think we're almost done with #2 using the dploy work. Tim Polk: I think that if we do a good job on #2, then #3 will be easy. Think it can still be done in a reasonable time frame. ?: There seems to be an assumption that producing these documents will be easy. But there are others in the group and see this as a chance to do some interesting work. The question is how much of the work of this group is a continuation of the existing work, or wether it's a fresh start. Gregory: I don't think it's a continuation, the scope of dploy was much larger, but I don't think we should throw it away either. We should start with it as a strawman. A hum showed that consensus was clearly achieved on mandating work on #3 not start until #1 and #2 are done, consensus on leaving #3 in. Brian Weiss: first two documents there is a lot of consensus that they are important and should be in there. I'd really like to see the requirements first before we decide on CMC. Steve Hanna: CMC is by fiat. Paul: I don't see why there can't be something beyond #3, other profiles. I believe we need to have a #3 there. I'm happy to have #3 be CMC. CMC is a reasonable choice; but should not exclude doing CMP or SCEP if someone and have the WG handle it. Mandating that #3 specify enrollment would exclude participants that had preexisting enrollments. He would like to see (2) consider enrollment, but not have (3) mandate a specific enrollment mechanism. adkins: stated that enrollment is too important to omit from (3). He stated that we should describe a single way of performing enrollment, but not mandate that it is the only way of doing it. Bill Weiss: I hope that leaving #3 in doesn't stop us from moving forward on chartering the WG. A hum showed that consensus was to remove "CMC" from #2. ?: asked whether the timeline should be tightened up to reflect the expressed urgency of this work. I'd like to see the milestones for #1 and #2 be done ASAP, and then #3 started within a year. Steve Hanna: indicated that he thought the milestones were already fairly aggressive. He did not see how we could compress the timetable for (1) and (2) further. ?: What does "done" mean, then? What do we have to do before we can begin work on #3? Gregory: I think "done" means through WG last call. Agreed? vs IESG last call or RFC. [Agreement.] Lauri: milestones need to be reworked Paul Hoffman: I don't believe that enrollment is part of lifecycle management. Derek believes that enrollment should be covered in a sufficient, but not necessary, e.g., a protocol that is not mandatory to implement Steve Hanna: Decisions of the BOF: First change agreed on was whether we could add support for transport mode. Is it the sense of the BOF that we'd like to try to include support for transport mode to the charter, until such a time as it would bog down the effort, at which point it could be removed? Agreement on that. Another change agreed on was that we'll do #1 and #2 first, and only then will proceed with #3. Also agreed that requirements will be generic, rather than specifically mention "CMC". CMC would be removed from #2. Also agreed that Charter will explicitly list what we mean by certificate lifecycle, what covered by any protocol that might be profiled for #3 (eg retrieval, etc.) Agreed (by hum) to add text that explicitly states that #1 is the most important. Agreed to the charter with the changes above. Agreed to move forward w/ charter and create WG. 25-ish people raised their hand to indicate that they were planning to *actively* participate in the WG. Lots of people want to edit or draft text for #1. No volunteers stepped forward to edit #2 during the BOF, but 5 or so came up to volunteer after. Steve: Looks like we've got enough interest to move forward on this, agreement on the charter, etc. Gregory: special thanks to Steve for pinch hitting in Chair role at the last moment. GREAT JOB, huge value add to the process. [strong applause of agreement] Next Steps Agreed to the amended charter, post, along with minutes, and then get final agreement on list. |