EAP Method Update (EMU) Minutes Meeting : IETF-79, Wednesday 10 November 2010 Location: Shangri-La Hotel, Garden Ballroom 1, 15:10-16:10. Chairs : Joe Salowey Minutes : Paul Hoffman, Nancy Cam-Winget Version 1.1 ============================================================== AGENDA A. Meeting Administrivia B. Channel Bindings C. Milestones D. EAP-TEAM ======================================================= MEETING Report Minutes taken by Paul Hoffman Nancy Cam-Winget Does not repeat things that are on the slides A. Admisitrivia Paul and Nancy volunteer as note takers Tunnel Requirements draft in IETF last call, completes next week. B. Channel Bindings -- Sam HartmanPresenter Didn't do much since Maastricht on this, but will do much more before Prague Joe wanted clarity around use cases Not much traffic on the list Wants to be sure the use cases and intro are clear Thinks we are doing pretty well 3 people in audience have read the latest draft Sam: Might need help with ASCII art. Needs help with 802.11 attributes Nancy Cam-Winget: offers to help with 802.11 attributes Sam: Need to discuss the interaction of channel Bindings with tunnels Glen Zorn: Doesn't want this to use stuff from clancy-emu-aaapay. They used DIAMETER AVPs, which are big. Reminds EAP can run over very slow things like dsl lines. Sam: as individual who is implementing the draft, believes it is important (to him) that we use some existing registry of channel binding data (radius or diameter is OK) but it has to be existing registry vs creating a new one. Would prefer that we use diameter. if they don't work, then would like to find something existing to replace it. Joe: suggests limiting to certain avps Sam: Tends to agree, The set will be link-type AVPs Glen: Radius AVPs are much shorter, Some vendors use strings in practice Sam: thinks that the extra bits are not a problem andis willing to pay a millisecond or two for architectural cleanliness Glen: Look at Charles' draft to make sure that these are really Diameter attributes. Main concern is mainly size of attribute, possibly wasting space on a slow channel Joe: asks Glen if concern is just size of avp in diameter or something else? Glen: agrees that its just size.so depends on the number of avps that would be sent. Glen: points out namespace overhead is bigger also overhead for the length which radius does not, so the length overhead can add up if many attrs are sent. Sam: also clarifies Glen's point too that if method is transporting something that does exceed radius, then there may be something fundamentally wrong. C. Milestones Joe: Current milestones are way out of whack Sam: is more comfortable to do WGLC on channel bindings by summer (vs spring) Joe: WG LC for channel bindings for June 2011 Joe: Suggest call for submission for tunnel/password method by end of this month, evaluate them around March, do selection around July and do WGLC by Aug and IESG by Sep. Joe points that it may be aggressive, but it can motivate the group towards forward progress. Glen: is not understanding what evaluate methods mean as there's a 4 month gap. Joe: points that all proposals will have some work required, so that will have to be expressed. Discussion leads that evaluation can begin by Feb 201. Sam: suggests putting place to close submissions; so Feb is close submission dates. Nancy: what is the evaluation process Hannes: everyone loves their own thing, not the others Expects that all the methods will meet the requirements Sam: wants to hear comments by authors on the other methods Glen: it will probably not be decided on point-by-point evaluation Klaas: RRG tried something similar didn't help them to find a solution, but it got more clarity for readers Glen: we don't want to spend a lot of time Klaas: we need a process that will end in finite time We need to know when we are done Sam: there are alternative consensus method. Need to ask the question: Is it more important to have one solution than to have your solution? Sean: suggests that each proposer put how the proposal meets the criteria and then the group dukes it out. Sam: further suggests that other's comments would be of value too. Paul: also mentioned that it didn't work in IPSec either. Sam: believes there are not enough neutral parties to help, believes that A's comments on B's proposal are of value and vice versa. Sam: points out that WG is free not to come to consensus and have no solution. THe group needs to agree if coming up with a single solution is important. once that is done, perhaps getting consensus in a tie break method, or have it to the chair or ADs to decide. Urges group to consider whether it is more important to come to a solution or if you can not, this will be very educational for everyone. Joe: suggests that chairs discuss with AD to figure out a way forward. Milestones from meeting: Nov 2010 Call for Tunnel/Password Method Submissions Feb 2011 Close Tunnel/Password Method Submissions and Begin Evaluation Jun 2011 Channel Bindings Draft WGLC Jul 2011 Channel Bindings Draft to IESG July 2011 Tunnel/Password Method Selection Aug 2011 Tunnel/Password Method WGLC Sep 2011 Tunnel/Password Method to IESG D. EAP-TEAM (Glen Zorn) Glen: Derived from PEAP, typical TLS EAP protocol using TLV's and cert installation and strong password authentication Notes unconditionally compliant with requirements for WLAN Lists advantage because there's no backward compatibility (0 install base) complete IETF change control as there are no external (marketing) pressures Hannes: comments that long ago, the design team put something very similar to this proposal that led to the requirements process. The objection back then was it was simply not what the other mechanisms were. so how do you see that requirement changing? Would like to know if should have a good feeling? Paul: can't resist to comment that Glen's team is bigger.advantage of Glen's is that it adds another one. Glen's facetious slides state that we can't build yet another one, then it really doesn't matter as soon as you have more than 1 method as there are already several. Paul notes that why questions are usually a bad idea in the IETF. Comments from Glen and Hannes that history doesn't really matter. Glen: comments that 'if we join the team', then if the SDO likes it they'll use it, else not. Hannes: asks if someone is ready to implement this? Glen: says, no install base yet. Glen points that it is very close to an already used method with some extra stuf. Sam: is there a related-protocol attack? asks if it is close enough to anything else that it can be converted to that method (e.g. TEAM to PEAP)? Glen: asks if this is to the PEAP attack? Sam: notes that it would be more like 802.11 attacker oversees those packets and use that to turn it into PEAP. Glen: answers that it is different because it uses a different key derivation. Sam: says that it may not be good enough Glen: will look into this. Meeting Adjourns 1 minute early