Last Modified: 2005-02-04
|
Minutes from the BTNS BOF
IETF-62, Minneapolis Monday, 7 March 2005 Recorded by Yushun Wang Sam Weiler (chair): Today is mostly for charter bashing. Joe will give a brief overview presentation Then we'll go through list of items in the charter, milestones. Joe Touch - (Overview Presentation) Sam Hartman (AD) (respond to one of the slides) - From mailing list discussion: self-sign cert & raw RSA keys are only things we are doing, others not in charter. (end of slides) Steve Kent (Kent) - IKE is essentially supporting IPsec, so changing IKE is the same as changing IPsec. IPsec also does access control in SPD which seemed missing. Why not start with TLS. Why start (or target) only with IPsec? Joe Touch (Joe) - Attack against transport, we could either protect the network layer or change all transport layers. Transport layer headers also have copies of network header layer as the authentication of network identities. Kent - How about IPsec access control, exactly about who you are talking to. Joe - Identity in this case means "network layer" identity. Chair - Is this too dangerous? Kent - No, but starting from changing IPsec/IKE is not good. AD - Should focus on the charter. The decision/scope from DC bof is narrower than what Joe would like to do. But since we focus on IPsec, there is a sense of access control based on the first pkt. Kent - That's not access control, that's continuation of auth or session association. Chair - ...(?) Pekka Salova (Savola) - Please clarify how this deal with issues where valid (RST?) packets generated by firewall on path. Joe - Third party should not be sending packet to me. That should be considered an attack. Paul Hoffman (Paul) - We should reset the discussion according to the charter, not Joe's presentation. Kent - What is the purpose of the presentation? Chair - for those who weren't in dc, or who lost the context. Kent - go back to agenda, why are we discussion details? Chair - To find out if items are of sufficient interests and find people to work on. Kent - we should do charter bashing now. Chair - I want to show the list, and let people say we want to do this. Eric Resocorla (Eric) - Something has been snuck in there: "various security protocols in general". We have somewhere btn 10-57 security protocols. Chair - Real work items are c & d. Eric - Should we strike everything and change those to IKE/IPsec? Joe - Basically says that it will not just work/apply to IPsec/IKE, but also to all other security protocols. Chair - Is that ok? Eric - Fine. But "framework" is misleading, Don't think it's a framework. Chair - Do we need a framework according Joe's anonsec doc, or is problem statement ok? AD - App statement is also needed, there are times we do care about identities. it's important to scope the work. Eric - This is a problem, this is a app statement, I don't know what it is so can't decide what i want or not. Chair - Do we want problem statement & framework in the charter? Kent - Why do we say changing IPsec/IKE? Paul - (c) specifically says profile, it's not changing or extending IPsec/IKE. I don't see changing IPsec/IKE. Kent - Profile is part of standard. Chair - Other security protocols are also in the target, why is IPsec sacred? Kent - Should clarify what we want to do with IPsec. Sam - DC BOF already discussed all these issues and most wanted this work. From a process standpoint, want to see how to process your objection without stopping the progress. Kent - Someone who want to do this overall thing...(?) Nicolas William (Nico) - IPsec is the right thing to do here. We heard the arguments, there may be issues. Charlie Kauffman (Charlie) Issue 1 is a bit vague. Does it say we look at IPsec or include other possibilities? And whether now or later to look at other protocols. Chair - Just IPsec for this group and move forward or re-charter. Charlie - Should prevent other people from hijacking this group to do others. Joe - I do this because DC BOF asked what Steve said, don't make it too broad or it will be like IRTF. I also want to continue draft-anonsec, address Steve's concerns on why IPsec. I believe other protocols are already doing/allowing this. I'll address why not transport layer do this problem. Chair - Who else wants to work? Uri Blumenthal(?) - Will read drafts. Paul - Should discuss (d) first. Salova - (b) is the really important. (something about framework...) Chair - Who think this is important enough to take on. Write, not review. Nico - c, d, e Chair - Ff we don't do c/d/e, a/b may be lost. Chair - Blue sheet? David Black (David) - Half a hand for b & e. Chair - Protocol work: Paul - Strong preference on profiles over extensions, easier to implement. But which IKE? Probably IKEv2. Lets decide on which works. Must clarify. IKEv2 already had a bake-off. So should also be considered. Chair - Not a volunteer. Need volunteers. Charlie - Don't believe this needs extension nor profiles, and happy to write down the couter-doc. Chair - If tech analysis (shows it's not needed, ...?) Paul - WIll co-write profiles, probably very short profile needed. Chair - ... Nico - Just a short ID/cert type, should be short. An issue of processing mode, not much work to do there. AD - Didn't I get this text from you? Do you volunteer? Nico - Will do c/d/e. Joe what are you working on? Joe: (a), and maybe b which should be merged to (a). Not c/d/e. Not an expert and don't know how to make IPsec community happy. Paul - Me and Charlie for c/d. not a,b,e. AD - For (b). Russ pointed out what we asked for is unclear. If we want to do (d), we have to clarify. Assume 2401bis, one is a flag, not to be strongly auth. if two people want to talk securely, and flag set, they can communicate securely. Would not be susceptible to MITM attacks, once IKE is established, can do it securely. Another flag in SPD says I am willing to negotiate an SA for traffic that falls into this selector, but access bypass traffic. Implications for SAD/SPD caches. Another flag for SA, will bypass the traffic when failed. People had done this. But that's the 3 types of changes we should provide semantics for. In addition to asking if people want to do this, which of these SPD changes are important? Nico - Too details. Many OS's have this. It is possible to involve link or transport for SA negotiations. Already similar binding to other objects. Just need some interfaces to IPsec. Bill Sommerfeld's draft on IPsec interface requirement. Either do it in this wg, or make sure it's revived. Pekka Nikander (Nikander) - Interface to IPsec crypto services for identity is an important issue. Willing to work on (b). Chair: thanks. Russ Housley (Russ) - (c) is not huge, (d) is the one that concerned me. Where in the SPD & packet processing is unclear. Is it appropriate for DNS lookup? Another choice is plugging both together. A host that has some bypass, some auth, some the best we could do. AD - Implicit to me that we must do that for this to be useful, alongside IPsec. Chair: Who would be happy with ipsec but not this? (about 10 people) Chair: who want both ipsec & btns? (about 40-50) Bill - Produce implementations that could do either, but should not explode when seeing the other. Greg Lebovitz (Greg) - Might need to change local implementations, store/read/match, don't mod the protocol bits-on-the-wire. AD - Agree with the requirement, but stating would be complex. Greg - IKEv2 is not mature enough. Could do this on IKEv2. Chair - So it's bad for v1, why? Greg - Would affect v1 users if we add new id types. Nico - For unknown id type, would the responder blow up, or just doesn't care? The fomer is a bug, the later shouldn't matter for btns. Just mean that we can't do it. Why is that we can't add new id types for IKEv1? Greg - Not can't, just would not like to. Nico - This is optional, so failure is ok. Just don't do btns. Chair - Move on. Bill Sommerfeld (Bill) - (d) wouldn't be a simple extension. Extension to PAD(?) might be right. Chair - Should move on to milestones. Why we don't need ...(?) Paul - Even if BTNS can't coexist with IPsec VPNs, still would like to proceed. AD - Can not guarentee apps to separate usage. Chair - App that can do both? Nico - btns must/must not co-exist? Chair - Question: do we require them to co-exist? AD - Want to place requirements on the 3 options that I said. No. Chair: Nico/Bill/Pekka Nikander for c/d/e. Last one information doc. AD - Won't get consenses on standard track for interfaces, so informational. Will move there. Eric - If (e) is for general (security protocols), why here? AD - For channel binding stuff, must do it somewhere. Eric - Don't read that here. David - Mostly channel binding, and giving advice to design of higher auth. Bill - Standard track concerns. Either define an API or a model of API for information flow. Think it's critical to be on STD track. Paul - Not STD track and not in this wg. Kent worry about we are too far down the track. Other can use non-IPsec. might be generating an API for what we are doing, might include others. might not be a working group. Chair - Not here? how about infomational not API? Chair - who wants (e)? Bill, Nico, Charlie, Pekka N. Chair - who thinks it's bad? Steve? Kent - Issues for secure gateways. Nico - This is API, starts out abstract. Necessary for btns to be useful. Can be elsewhere. AD - Issues for STD track(?), but we will find out when we are done. Don't want to do it here. Chair - Who cares enough to read? West(?): API is more than btns, should not be here. if it's optional, why do apps care? Argue against. Bill - Need an abstract API to channel binding for interop. btns without API is still useful. But channel binding makes it much more useful. Not critical, but reasonable place to do that work. Chair - Stop the line and go to milestones. David - Need spec on what the bits are and what makes it work, not details. Could left for implementations. Eric - don't want 2nd thing David said. Not sure about 1st. Chair - What else do ADs need? AD - Steve are you uncomfortable with this work? Kent - Most people (3 groups) want different thing with same mechanism, but not overlapping motivation. Two of those three don't need IPsec. Joe did address the need for IPsec. AD - charter? Kent - As long as it's not affecting orig IPsec, I am not uncomfortable. AD - Would-be chairs should email Russ & Sam. Chair - Milestones: how long, might be unrealistic. First drafts in 2 month? Nico - Some already exist. First draft (in two months) should be fine. Chair - Like to see if authors agree. Joe - Will write the first two. Chair - Others? No one is saying not realistic. AD - We are done. |