EAP Method Update (EMU) Minutes Meeting : IETF77, WEDNESDAY, March 24, 2010. Location: Anaheim Hilton, Manhattan room, 0900-1015 Chairs : Joseph Salowey Alan DeKok Minutes : Dirk Kroeselberg Nancy Cam-Winget Version : 0.1 ============================================================== Agenda 1. 0900 - 910: Preliminaries 2. 0910 - 0925: Channel Bindings http://tools.ietf.org/html/draft-ietf-emu-chbind 3. 0925 - 0935: EAP TLVs http://tools.ietf.org/html/draft-cam-winget-eap-tlv 4. 0935 - 0945: ITU Liason Statement 5. 0945 - 1010: Tunnel Requirements http://tools.ietf.org/html/draft-ietf-emu-eaptunnel-req 6. Extra: Session Policy http://tools.ietf.org/html/draft-mccann-session-policy-framework-using-eap ============================================================== 2) EAP channel bindings: http://tools.ietf.org/html/draft-ietf-emu-chbind Document not yet ready, needs more feedback. Some open comments. Issue 1: proposing to make it informational because the document is not really providing a solution. Issue 2: Channel binding container not defined - Discussion about whether creating a separate solution document (container definition) or putting it into this dc. - Joe: proposals exist for this in other documents (aaa-payloads,eap-tlv) - No objection to define the channel binding containers in a separate document. Issue 3: bad examples for lying NAS. Needs input what a better example would be. -Glen Zorn: comments that this is a fool’s quest as there really is no good example. Issue 4: unclear what assurances can be made wrt to lying NAS - Alan: believes this issue is closed - Glen Zorn: reiterates idea of stating authorization in this form is assenine. Last time he checked, crypto keys were derived as side effect of method (nothing to do with EAP); even if there were something like this to be done is outside the scope of EAP. Channel binding support in every EAP method is assenine…..believes EAP is broken already. Would be trivial to design method to run after EAP and before access was actually allowed to do authorization. Not sure why you’d want to do anything else, unless you don’t understand EAP and AAA are not the same thing. - Sam Hartman: states that if discussion comes to this level; failing to authenticate the party you’re authenticating to would be assenine. Don’t believe discussion is about authorization but rather naming the parties you are talking to, basically expanding part of the authentication (identity management) process….to make sure they are talking to the right party. The authorization question (“is the service that I’m getting the one I want”?) is not really what we’re talking about in channel binding….though it could be. If this is about “the client I want to permint”, then agree with Glen…it’s out of scope. But to do the identity check effectively is in scope and critical to EAP. - Glen: the problem with this is EAP by definition knows nothing about NAS’es (or entities physical in the network) other than the authenticating entities. An EAP server (5 or 6 AAA hops) will surely not know the name of the NAS that the peer is talking to….this is a nice idea to effectively identify the NAS and possibly the peer but this is not part of EAP without massively destroying EAP. Not like EAP started as wonderful protocol with SAML assertions, this is uses a “user name” and a credential and that’s it….the protocol has changed a little bit too so now it’s more a 3-party protocol but not official enough to assert that it is a 3-party protocol since as far as EAP is concerned, there is no NAS. - Alan: agrees that this is the case. Though real world deployments would like this…there doesn’t seem to be much else other than using EAP to achieve this. Not sure it will break EAP, though it will modify it. Realworld case is that the authenticator can know who the NAS is because there is a business relationship between them; so that authenticator can agree that there is a relationship….not a technical but rather business issue. - Glen: there’s a chain of trust thru AAA….if they really know the NAS then there shouldn’t be a lying or trust. - Sam: now confused. The chain of trust created is there; the point of the channel binding in EAP is that there is a way for the client to ask the AAA server whether the client’s idea of the chain of trust is what the AAA server believes. It is built on chain of trust created….don’t understand how that chain is sufficient. - Alan: there’s NAS and AAA trust and user and AAA trust (direct in latter); no trust between NAS and user. - Sam: right, so channel binding is to allow home AAA server to agree that parties who don’t have trust with each other are telling each other the same thing. So don’t understand how Glen doesn’t agree. - Glen: is now confused. - Sam and Glen will discuss offline - Joe: still issues with this draft and feel we’ve come full circle. Need new editor….Sam has offered. If anyone else is interested, let the chairs know. At the core is issue of what problems channel binding is solving; what the data is and how it would work. Glen is right that one can send the data but the EAP server may or may not have a clue if that data is correct; so we need to validate if this will really work in realworld scenarios/deployment. Need to evaluate if we are going to make progress in this area or not. So, let chairs know if you want to be an editor…. - The draft needs new editor, Sam Hartman offering to step in. Glen Zorn also volunteering. - In summary, the document needs more clarification about what channel bindings exactly address and what not. 3) EAP TLVs (Nancy Cam-WInget) http://tools.ietf.org/html/draft-cam-winget-eap-tlv Draft proposing a general container format to transport any sort of data (e.g. channel bindings, crypto bindings(bind all EAP conversations), NEA (TB-TNC)). The container has a simple TLV format. EAP-TLV may be run in parallel to inner EAP method through TLS tunnel. Discussion: - Glen Zorn: likes the draft. - Dan Harkins: Wrap this in another encapsulation? How to know a message is the inner EAP, or EAP-TLV? - Nancy: Will be solved with appropriate namespace. - Dan: Does not like to use this for sending back and forth proprietary information. - Alper Yegin: Needs guidelines for what types of data are allowed. E.g. configuration data. need to decide whether the group wants this or not. - Sam Hartman: does this work as is, or do we need more semantics for this, error handling, TLV supported by other side? - Dan: would be more useful if it could also be used outside tunneled methods. 4) ITU Liason Statement EMU review of ITU-T X.1034. Reviewers were not clear on the purpose of the document. Response points to existing EAP method requirements documents like RFC 4017. - Glen: thought response was too polite - No further comments in the session. 5) Tunnel Method Requirements http://tools.ietf.org/html/draft-ietf-emu-eaptunnel-req Getting close to closing the document. Issue: can mandatory attributes be ignored? What does this mean? If they’re truly mandatory then EAP should fail. - Dan Harkins: depends on behavior we want. Do we want EAP to fall apart if peers can’t agree? We can have different ways of having “fall apart” or graceful continuation or that it really doesn’t matter. - Alan: so this needs to be clarified in the document. Problem statement and solution needs to be clear. - Glen: there’s a description in which it states an attribute as mandatory but in some conditions is not; so agree with Alan - Joe: if it is in the EMU requirements then we need to clean it. - Sam: should be if we don’t understand it, then “blow up the world”…mandatory meaning, if we don’t support this, then let me know it’s not support it so I can recover/blow up/ignore. Most important one to consider is the crypto binding (not influencing the key derivation). Need some negative acknowledgement is something’s not right, but critical to signal to the other party what’s happened. - Mark Jones: using mandatory alone has been confusion (speaking from experience). Mandatory and optional is too black/white for the real world; nature of the attributes is more of a specification decision. Not convinced that they’re well described in the spec and need to be in the AVP - Sam: agree, “what do you do with an attribute you don’t understand”? - Mark: what you do has to be in a spec - Alan: if there’s a new spec that defines behavior, how does legacy handle it because they don’t understand the new spec? - Joe: the way it’s currently defined: if it’s mandatory and you don’t understand then you get a negative acknowledgement bit. Useful but perhaps not the only way. May need ACK and NAK and explicit policy that if receive one of these conditions then you truly blow up. - Alan: if the interpretation is more NAK requested bit, and if you don’t understand it and you get the NAK then reciepient can decide on whether to blow up or not. - Joe: how many folks have strong opinion on Mandatory bit behavior? Or do we have to define it detailed in the requirements document? - Sam: needs to be defined at level of detail so that things that are security sensitive (like crypto bind) are correct. - Joe: if we describe uses like crypto binding, would that help? - Sam: if its security critical, then both parties have to know to fail the authentication in time. That requirement should be sufficient to put the details to a later spec - Joe: does anyone object to that approach? (no comments). OK, will modify the requirements without being prescriptive of solution. Section 4.1.2 'draw from existing work' requirement is not technical. Remove? No objections to removing the text. Few in favor of removing. Will be taken back to list as there were some comments to keep it. Regarding the text "MUST NOT mandate anonymous tunnel": - Dan speaks to problem he’s trying to raise. People don’t come to IETF and misunderstanding to “mandatory to implement/use”. When I raised this as a “SHOULD” it gets misrepresented as a requirements. Concerned that this is creating confusion. - Sam: what do you want? - Dan: don’t be so negative on anonymous tunnel. - Joe: people writing document do understand the requirements and what they’re writing. - Dan: so why does slide say “required” when I didn’t say that - Joe: my opinion, if you’re doing anonymous cipher, have to do it with care. Can’t say “it’ll be fine” if we do anonymous….as we can easily get it wrong. Group didn’t think it was necessary to have something like this implemented nor desirable. Requirements doesn’t say you can’t do it. - Alan: true that there is a potential for confusion. So could add another line to say while it doesn’t mandate it, could add a “should” provide this - Joe: not sure that’s a good idea. Its not just anonymous cipher suite….not sure that we want to take on as base method. Could add it as addition. - Alan: saying that it should provide for later capability should be ok. - Dan: we have EAP methods that already do this. - Joe: not as straightforward as it may seem…as it enforces that an inner EAP method must be needed. May be throwing away benefit of the tunnel to provide security - Dan: already thought that stuff could go in the tunnel - Sam: need crypto binding - Dan: so we can do this as some of this is already in requirements - Henry Kotz(?): not disagreement in mechanism but rather on wording of the doc….need to include appropriate qualifications or references (like channel binding) as needed - Klaas: reading Katrin from jabber. This document is not the place to include all specifics….against the SHOULD because NIST requires non-anonymous tunnels. Have already talking about this topic in the list….so inner methods requirements would be deeper….longer list but running out of time (and typing speed) Will be taken to the list. 6) Session Policy Framework for EAP (S. McCann): (slide presented only) draft-mccann-session-policy-framework-using-eap-01 Draft updated to -01 version. Now uses EAP-TLV payloads. Not sure whether EMU is the right place for this. Feedback requested. - Glen Zorn: has nothing to do with EAP or AAA. …. Another misguided amalgams and treating EAP and AAA as the same thing. Diameter should not be turned into a SIP policy server. Concept of layering seems to have disappeared from the IETF; there’s no inner connections between DIME and SIP.