IETF 73 - Minneapolis, MN November 17, 2008 EMU Working Group EAP-GPSK - Last call completed - In IESG review - Comments from Pasi - Open issues (potentially not impacting doc) need response to IESG Tunnel Method Requirements - Joe Saloway presented - Discussion of open issues with latest spec - Summary of changes in -01 - Only 6 WG participants have reviewed document so far - Open issues o Resource constrained environments - Bernard: Concern about having method be minimal so supported by very small devices - Question about can we remove requirement for supporting very resource constrained environments. Room consensus of the room - Question about can we remove requirement for supporting very resource constrained environments. Room consensus of the room was to remove the requirement. . Zorn had issue with removing it but would rather suggest defining what a resource constrained environment means (e.g. PDA). . Klaas W. suggests define is precisely or remove it . Hoffman also suggests removing requirement unless the requirements are very precise. . Pasi suggests document defines exactly what resources it requires to be implemented (e.g. num of pub key ops) . Bernard raised concern about how to precisely describe resource requirements which might need to be role oriented (client, server) which makes these more complex to be precise. . Pasi summarized topic that editors believe they will select a lightweight approach even without this requirement. o Authentication Support - Salway: Should we provide support for other then basic password and EAP? - Proposal to include case for extensibility in section 3.9 - Room had no issues with proposal o Tunnel MITM Protection - Proposal is tunnel provide MITM protection (server auth and data integrity) and MUST NOT weaken MITM provided by inner. - Katrin Hoeper if you have inner method that derives keys then we need this requirement. Other types of methods (password oriented) don't need this. - Open issue is where to put proposed text so it applies to appropriate inner methods - No other concerns in room about proposal, Katrin took AI to propose how to integrate into spec o Bypass of Server Authentication - For emergency use may bypass server auth - Bernard: didn't we discuss this and decide bypass is a bad idea - Hannes: with post to acrid (?) WG alias to determine if the security issues raised are balanced by the needs for emergency access. Also concern about regulatory requirements might exist for emergency access (e.g. VoIP calls for emergency services when phone lacks needed call credits). o Certificate revocation - Is current text too onerous? - Stefan is ok with proposal since its just an implement it requirement not that a deployment has to be able to use it (may lack infra). - WG quiet on issue o Session resumption - Should it stay a MUST? - Proposal to stay as is. - No concerns raised about this proposal o Call for other open issues? - Hanna suggests that we cc NEA on the WG last call so they can provide comments - Agreement to take this through WG last call and on to IETF last call Chennel Bindings - Katrin presented EAP Channel Binding - Preented history and scope of spec -04 - Currently updating spec to address ongoing comments from Bernard - Reviewed resolved issues/updates to current draft based on earlier comments - Open issues o Cost benefit analysis - lacking hard numbers, is this ok? - Bernard: For deployments with emergency services the incremental cost might be negliable (just alittle more information entered into NAS database). - Alan: beleves hard numbers aren't required in spec since the diff to add channel binding after a software update this has a small impact on deployment costs - Zorn concered about home network lieing to peer in order to gain more funds. What can peer do about such a lie? - Alan: we need to root the solution on the relationship between the peer and the home network. We aren't trying to make the world better just not worse by adding this protocol. o Lower layer binding - What other protocols (e.g. RSN-IE)? - Bernard: RSN-IE or the whole beacon? Seem beacon based attacks. o Open discussion - Gabriel Montenegro: cost benefit not required for the IETF specs so can be removed - Hannes concerned about issues in spec and not solving a critical problem so they don't plan to implement it. - Spec is a working group charter item so the cost/benefit may help provider evaluate whether to deploy solution - Hannes concerned that implementers won't add protocol to there AAA servers - Hoffman concerns that MUST language should not be in the security considerations section - Stefan Winter sees a real need for this protocol to indicate to user if they are roaming or not (eduroam use case) - Stefan this is useful for the user in case they are being charged more for roaming (eduroam is free) and to know that there traffic might be crossing other networks - Chair question about whether we should take this on as a WG item? o 11 in favor and noone against adoption of spec - Zorn questions whether we can change our mind later if we agree to work on this draft. What is the point of accepting a WG item at the very item right before WGLC. Question about process not about this document - Pasi said some show of WG support for a new WG item before the WG takes it on. - Bernard: "Documents are not like kittens, they look real cute and then later start scratching the furniture" :) You generally don't like them less down the road. - Lakinath: is this really in the charter? - Agreement is that there was text in charter covering it RFC 4282 and Internationalization - Some items that are legal in radius but can't be done in 4282 specifically realm names I18N o ASCII only requirements causing problem (IDN-unware doman name slot) o Pasi gave history on text and suggested it might not have been a great reason to go this direction but it was backword compatible o Problem is that 4282 is being ignored since RADIUS and other protocols use UTF8 but that is not in 4282 so implementers don't follow 4282. o Bernard: we probably have several specs requiring errata and we need new bakeoffs using new protocol o Hoffman concerned that defining a spec for how to do this that contradicts with today's deployments/implementations will cause more problems. Suggests to use IDNA and not punycode the username. o Pasi implementations already do lots of things that aren't compatible with the specs so how will new specs solve this issue. o Bernard has hope that this will fix since the spec can document current implementer practices. Suggests not going with IDNA since this impacts several other protocols including RADIUS. o Hoffman concern about the lack of support for dropping non-printable characters as required by IDNA. Expresses concern about moving away from IDNA to UTF8 but not the other semantics needed for arabic for example. o Bernard: radius makes allowances for sticking things received in punycode in DNS requests so concern about moving these strings to something not compatible with DNS. Other considerations also exist. o Alan's proposal is 4282bis to match existing practices and fix I18N issues recognizing UTF8 usage. Proposal draft already available. This would be a radext work item proposal. o Hanna believes core issue is human entering realm names. This issue was addressed years ago during creation of IDNA. Should we ignore it? Proxies shouldn't need to do canonicalization of the realm. o Alan notes endpoint does canonicaization not proxy. The realm is largely treated as an opaque string o Hanna are we creating an 8-bit clean IDNA or a counter proposal since only IDNA tried to solve I18N of the realm name. o Hoffman key is that supplicants treat realm name as a blob (opaque token) and largely not interpreted. Problem is that some protocols wish that use blob assume syntax/semantics (can be sent to DNS) o Hanna suggests that using UTF-8 isn't acceptable since internationalized domained users wouldn't be able to roam. o Alan suggest using e-mail address for roaming cases and reiterates that most software doesn't interpret the blob (except the DNS lookup) o Hanna suggests this work should be a WG item that is well reviewed by experts and not be an individual submission o Alan states this was the plan but which WG? o Alan asks if anyone is using punycode in supplicants? o Alan notes that people in China already are joining the net and are roaming so this is possible. o Stefan: his involvement with eduroam is including China so will look into how this is working and report back to WG o Question is should we mess with the current situation which sort of works but question will go to other WG