EAP Method Update - EMU Meeting : IETF-80, Wednesday 30 March 2010 Location : Hilton Prague, Karlin II & III, 13:00-15:00 CHairs : Joe Salowey (jsalowey@cisco.com), Alan DeKok (aland@deployingradius.org) Minutes : Dorothy Stanley Version 1.0 ======================================== AGENDA 1. Administrivia (note takers, blue sheets, agenda) - 5 Min 2. EAP Session ID - EAP-SIM and EAP-AKA - 20 Min 3. EAP Channel Bindings - Sam Hartman - 35 Min draft-ietf-emu-chbind-07 4. EAP-FAST - Nancy Cam-Winget - 20 Min draft-zhou-emu-eap-fastv2-00 5. EAP-TEAM - Glen Zorn - 20 Min draft-zorn-emu-team-02 6. Tunnel Method discussion - 20 Min 7. EAP-IBAKE - Violeta Cakulev - time permitting draft-cakulev-emu-eap-ibake-00 ======================================== MEETING REPORT 1. Administrivia (note takers, blue sheets, agenda) - 5 Min Chair reviewed agenda, sent blue sheets around. Any questions on the agenda? None Dorothy Stanley agrees to take notes. 2. EAP Session ID - Bernard mail; issue with EAP-SIM, also affects EAP-AKA and AKA prime - Develop a document to update 5247 and other RFCs. Bernard agrees. Chair will get in touch with folks working on AKA. 3. EAP Channel Bindings - Sam Hartman Presents: - Sam has been working on a proposal since the Beijing meeting - Encoding decision needed - 2 options proposed - Diagrams needed - Need to confirm 802.11 attributes - Review of the two encoding options. Not including diameter options now - none identified. - To what extent does the name space depend on what is being encoded? - RADIUS AVPs encoded both ways. - Description of encoding - order of length and code values - don't match verbal description. Option1 - not using RADIUS namespace encoding. Option 2 - use RADIUS encoding. Advantage of option2 - get to re-use radius encoding on the server. One the peer, may not have an encoder/decoder to re-use. On the peer, need to know the length up front - concern when fragmenting. Not really concerned about these. - Is this protocol what we agreed to in Beijing? Are folks ok with this approach. Glen Zorn: didn't decide anything in Beijing. Both options are wasteful of space. Joe Salowey: This has been posted to the list, comments requested. Glen: Did the chair ask for consensus as to the approach? Sam: Do you agree with the proposal? If not, get comments regardless of consensus. Glen: Comment is that they are wasteful of space. No need for a length. If fixed in length, length is implied by the type. Sam: Have NSID, then type, value. - Namespace is from RADIUS. Why are we constrained to RADIUS/DIAMETER? - Can do a binary comparison of attributes received from different sources. - Argument made that you don't want to register attributes for channel binding. - Question of carrying non-RADIUS attributes is open. - Considered distributing RADIUS attributes only seemed problematic. - Compare each attribute separately. Sam: One reason for the length - encode in 255 octets? No 253. Support multiple attributes. Within channel space of RADIUS there are many attributes, encode each one, or all as a set. - Using RADIUS attributes or Diameter. Add one, or a new AAA protocol, need to channel bind something that is not RADIUS. Presence of namespace indicator is required. Allow to appear once, or many times? - Is all policy on the server? Server can indicate channel binding successful or unsuccessful, and authentication can succeed. - Client needs to know which attributes the server evaluated for channel binding. - General direction - including multiple namespaces, support RADIUS, servers ignore what they don't understand. - Request a hum on the above - no objection. Request to the chair to ask this question on the list also, to confirm consensus. - Request a hum on options 1 and 2 for encoding - option 2 indicated as preferred, no support for option 1. If attendees have another encoding - please propose it. - Are there other protocols that can use channel bindings? - Yes - if an EAP method wants to use them, yes. Get text on the EAP method use into this document. - Verify consensus on direction and encoding options, and solicit input on EAP method use. - What about the specific .11 attributes. Other attributes go in GSS-naming. 4. EAP-FAST - Nancy Cam-Winget and Steve Hanna - 20 Min, see http://www.ietf.org/proceedings/80/slides/emu-2.pptx Nancy Cam-Winget Presents: - draft-zhou-emu-eap-fastv2-00 - EAP-FASTv2 Overview - see slide 2 - EAP-FAST features - see slide 3 - Changes from Version 1 –see slide 4 - Claim that this is widely deployed. Dan Harkins: Is this version deployed? Nancy: No, Version 1 is widely deployed. Commitment to deploy the updated version. Steve Hanna Presents: - EAP-FASTv2 Advantages - see slide 5 Glen: Password change must be supported? Claim was that password change must be supported. However, light on details. How to tell difference between the two. Not enough detail to implement password change. Steve: Capability there using TLVs. Might need to improve language describing use. Glen: Question the "100%" figure Steve: Differences with TEAM - See slide 6 - The proposals are quite similar in many ways. - Call for Action - See slide 7 Stefan Winter: Discussion - Interested in one-time password methods. Have TLVs for password authentication? Verus GTC. Is this intentional? Specify additional TLVs? Steve: Can use EAP-GTC with either method. Simon Jossefson: But document recommends against use of EAP-GTC. Nancy: GTC can be used, but not as re-defined in EAP-FASTv1 (EAP-FAST-GTC). Simon: Similar issue (with token cards) arose in Kerberos group - if just concatenating, don't know where delimiter is, so send info to different servers. Simon: Implementation experience with EAP servers EAP-GTC - don't save passwords. Prefer another avenue for passwords in addition to GTC. 5. EAP-TEAM - Glen Zorn - 20 Min, see http://www.ietf.org/proceedings/80/slides/emu-3.pptx draft-zorn-emu-team-02 Dan Harkins Presents: - TEAM Overview, extension of PEAP - see slide 2 - - TEAM features, see slide 3. EAP FAST recommends another RFC to do initial authentication, uses MSCHAPv2, susceptible to offline dictionary attack - TEAM advantages, see slide 4 - TEAM advantages(2), see slide 5 6. Tunnel Method discussion - 20 Min (Moderated by Bernard Aboba) Dan Harkins: These protocols are unsurprisingly similar - like cousins, offshoots of PEAP. Editorial fixes will be made by the WG. See issue with IPR - Cisco has notified of IPR on FAST, license free with reciprocity. Issue of "reciprocity" offers - generous but not "free". Nancy: IPR was issued for FAST version 1, being used. Goal is to have this as a standard, not to aggressively claim royalties. Dan: Issue is on the receiving side, user will second guess going after the grantor on other issues. Steve: IP is a red herring, hate software patents; almost every proposal has something behind it. Steve: Change control - whichever proposal, IETF will have change control. Steve: Installed base - is running code a negative? Stefan: Question about Microsoft IPR on TEAM. Simon: There are no disclosures on FASTv2 posted. Nancy: It Has been filed, see IPR1519 Glen: All in favor of running code. TEAM is based on PEAP, which pre-dates TLS, FAST. IPR- always risk. Glen: Change control - 2 entities lock up the working group for 3 years, can influence. Have best of intentions. PEAP was done in the open. Glen invented when at Cisco, not IPR. Joe: Both similar from a technical perspective. Main difference, EAP-FAST is an existing type. Dorothy: Could a new type be selected for the new WG method? Potentially. Stefan: Microsoft IPR notices are posted on PEAP Bernard: will post to list Stefan : Prefer to use FAST number if choose that proposal. Bernard: Are we ready to decide? 12 hand for deciding, 2 hands for not to decide. - EAP-FASTv2 - 9 hands - and EAP-TEAM - 3 hands Verify on the mailing list. 7. EAP-IBAKE - Violeta Cakulev - see http://www.ietf.org/proceedings/80/slides/emu-4.ppt draft-cakulev-emu-eap-ibake-00 - Slide 7 - Targeted application - ETSI adopted IBAKE as a bootstrapping protocol, propose to carry in EAP. Targeted towards machine-to-machine applications. - Slide 2 - summary - Slide 3 - IBAKE Framework - Slide 4, 5 - Message Exchange and contents of messages - Slide 6 - EAP-IBAKE Features - Motivation - ETSI bootstrap protocol, now ETSI is discussing what protocol should be used to carry IBAKE messages. - Infrastructure for defining keys - ETSI TS 102 690 in Stage 2 now, not yet Stage 3 (implementation) Joe: There is an IPR declaration for IBAKE perhaps there should be one for EAP-IBAKE Adjourn 14:40