July 26, 2011
Quebec City IETF 81
EMU Working Group Chair opened the meeting at 1:00pm • Chair displayed the “Note well” announcement and asked for volunteers for minute takers.
Minute taker: Dorothy Stanley. • Chair reviewed the agenda and completed preliminary items Tuesday, July 26, 2011 
1300 - 1500 
Room 202
Chairs: Joe Salowey, Alan DeKok

Jabber room: emu@jabber.ietf.org (please join) 1300 - 1310: Preliminaries - Bluesheets, Attendance, Note takers, Agenda bash, Document Status 1310 - 1325: Channel Bindings, http://tools.ietf.org/html/draft-ietf-emu-chbind 25 minutes 1325 - 1425: Tunnel Method, http://tools.ietf.org/html/draft-ietf-emu-tunnel-method 60 minutes 1425 - 14:35 Additional Capabilties for Extensible Tunnel Method Authentication 10 minutes Wrap-up (5 minutes) No additions to the agenda. • Chair reviewed document status • Channel Bindings – Sam Hartman presentation • Have done work on the draft; encoding discussion as per the list. • If in apathy, delete 802.11 bindings material.
If in done/active discussion – keep 802.11 channel bindings.
Work is underway for implementation of the draft when it starts WGLC. • Callback on success on channel binding success – who sends? AAA server does comparison? Has to be the EAP server that does the comparison (if AAA server and EAP server are independent entities). Client can send attributes to EAP server that client thinks are important, the success responses determined by attributes considered. For example SSID and data rate. Might be of different value to the client; intent is to let the server tell the client which attributes were checked. In other applications, some attributes required to be sent by the client. Need to know that the server has checked all required attributes. • Any EAP method supporting this needs at least 2 new TLVs, one to go up and one down. Can use same type code, but do need to send info. • What server are we talking about/ EAP server. I was unaware that any EAP server knows anything about 802.11 or SSIDs or networks. How will it check this? There is text in the draft describing alternatives. • EAP Servers have policy that includes this. Extensible Authentication protocol, Policy is Authorization, not Authentication. • Not revisiting whether or not this is the right approach, do that in last call. • EAP server makes data available to AAA server. Implementation realities make this tricky. Important to pass info to client indicating attributes that were reviewed. If colocated AAA and EAP server, yes on AAA side. When AAA and EAP server not collocated, need communication that exists today. Today, there are no AAA implementations that have a separate EAP Server. HostAPD – for testing only. • Don’t want to limit future options. Don’t require the two to be collocated. • Draft text discusses this, please review. • Either has a feature that no AAA has, or have an EAP server that has no feature. • Have a new protocol that isn’t implemented. • Either have to say how to talk to the AAA server, or create new functionality in EAP to deal with authorization. • 3748 makes it clear that if the EAP server is separate, that protocol between EAP and AAA is implementation specific. • Don’t use Diameter AVPs, Radius attributes also not desired. • Chair asks attendees to review the draft; if text needs to be clarified identify this. • Open action item is to review the list of attributes: channel binding attributes, general and 802.11 specific. NAS Port type (general), Called-Station-ID, Mobility domain ID. • Prefer to just keep general attributes; separate others out into a separate document. Address other in follow-on spec.
No such thing as a TSK, not 11r anymore; no value to binding SSID in 11r. • But if not doing 11r, SSID is important. • Remove text re: 11r. • Attributes specific to ABFAB? In separate ABFAB document. • Keep NAS-Port Type? Mostly L2, no PANA, no IKEv2. • Specific EAP lower layer – draft-aboba-radext-wlan-13, EAP-Lower-Layer. Do you always want to pay the cost of sending those attributes? Leery of any attribute being a “must”. Must have some attribute that differentiates the layer you’re sending at form other layers. Might want to standards others; Need to indicate which lower layer you are. • Do we define EAP-Lower layer as a RADIUS attribute? As a channel binding attribute in this document? • Can register a RADIUS attribute. • Fine to register RADIUS attributes, new attributes being defined, needs to be of general use. If not of general use, have as a channel binding attribute. • How does Radius server know what it is? EAP server doing the checking. • From a RADIUS use case, end user authenticating at the edge, know info. • RADIUS being used for lower layers for a long period of time, probably already knows. • NAS Port type for PANA, ABFAB • Isn’t there a service type? Distinguish shell access from management access. • Must send one of these two attributes; need to cover PANA, IKEv2. Use either an existing attribute or a new attribute. • Specific EAP lower layer attribute – leave to lower layer usages. • Whole use case is lying NAS. Nothing here to carry the info related to the use case. That’s the purpose of the underlying problem. • For a layer that doesn’t specify, “Called-Station-ID” is the default. May not be a differentiation of services. • Show of hands for finding a n approach to • Mandatory indication of EAP lower layer use (use existing attribute if possible) • Result is 12 hands yes, none no. • Should spec indicate that EAP lower layer use is only required specified attributes: 4 yes, 0 no. • Does anyone object to using Called-station-ID is the fallback if we haven’t said anyting about the lower layer? Wait – doesn’t make sense. • Should we move IEEE 802.11 attributes to a separate document? 12 hands yes, 1 hand no. • Need to close on specific attributes to use. Plan for mid-September last call. • Why “no”? Why a separate document? Don’t see value in yet another document, clean up what is in the document now. • Include material for every lower layer in this document? Yes. • Glen – checked on available attributes – there is one for Tunnel Type, not NAS port type. • Hao Zhou report – status of draft • IETF80 adopted as a basis • Email list discussion concluded on allocation of a new EAP type value. • Requested comments, some received • Proposed changes: • EAP Type – to be allocated by IANA • Version number to be changed to 1 • EAP Name – to be discussed • ITEM • ETA • TEAP • EAP-TUNNEL • TEAM • Plan to pick a name from the list; objection to re-using “EAP-FAST” • Add Outer TLV • Protection of inner and outer TLV • Remove dependency on RFC 5422; list TLVs required rather than dependency on 5422. • Next steps, submit a new revision with proposed changes and issue WGLC • Discussion: • Make sure this is in alignment with the channel bindings. Have one TLV that defines channel bindings. • Chair requests additional review of the draft. • Dan Harkins – Some Additional Capabilities for the Tunneled method • Certificate-less Password Auth • Server-side certificate authentication may not always be possible • The little checkbox is there for a reason, and it is used! • When it’s not we don’t want to use PAP! • Use tunnel method: • Phase 1 is a TLS cipher suite for anonymous D-H. • Phase 2 is an EAP method that supports mutual authentication using a password that is resistant to dictionary attack– EAP-pwd or EAP-EKE. • Why not just use the phase 2 EAP method by itself (outside the tunneled method)? • Tunneled method has channel bindings and a way to pass arbitrary stuff back and forth between client and authenticator. These EAP methods don’t. • Provisioning another Credential • Tunnel method has the concept of a PAC for subsequent fast(er) authentication • How does one get this PAC? • Ask for one after going through the whole tunnel method the first time (see previous slide). • If I only had a cert… (I’d do EAP-TLS) • Authenticate, even if there’s no trusted root or path for validation (see previous slide). • Issue PKCS#10-ish request, get PCKS#7-ish response. • Et voilà! • Discussion • How do I find out about these capabilities? • As done in EAP-TEAM; had a mechanism in EAP-FAST, indicate capabilities in outer TLVs. • Some applications need password in the certs. Both sides need same version of the passwords. • One case, send password protected over the tunnel; not removing this. • Important to protect selection. • If don’t have a server cert, shouldn’t send password. • If no cert, don’t use PAP. • Could add language to the draft to allow this case. • EAP-FAST had the capability of provisioning another credential, can add this back into the tunneled draft. • WG needs to decide if provisioning another credential is required. • Multiple items here, not clear on what is to be modified. • Want ability to have anonymous D-H followed by EAP method with password. • Provisioning is valuable, but is complex. Don’t have a requirement for this. Agree on a tunnel method, then do provisioning as a separate document. • Break into 2 – anonymous establishment – allow in this document? • As little in the base spec about provisioning as possible in this doc. • This doesn’t have to be a rathole. May be 10 ways to solve it. Pick one. Don’t think this is contentious. • First negotiate anonymous D-H, with inner method – ok, easy. • Provisioning – bootstrap for a certificate, simple PKCS TLV ok, another draft for new provisioning. • With respect to certificates, not comfortable with attributes that were defined. • Not in scope for the tunneled method. Concern will slow it down. Group has a track record of being slow. Market needs it now. Also might be IPR in this area. • Whole process took a long time, requirements doc took a long time. Believe IPR issue FUD. • Would need to add text for anonymous + method. Shall we add text to relax anonymous to allow for secure inner method: 11-yes, • Silent except for security considerations? 1. Rough consensus – Yes. • Requirements may have disallowed some use of anonymous, e.g. with PAP. • Need to discuss in security considerations- SASL. • Draft talks about using a PAC – uses an RFC 5077 reference. Does provisioning a PAC count as provisioning? No • Second item: provisioning in this document? – Rough consensus - no Chair repeats request for review of the tunnel method document. Meeting adjourned 2:15pm local time.