Notes from EMU meeting at IETF 69 Tuesday, July 24, 2007 Chicago Agenda ----------------------- + Administrivia (5 min) Note takers, blue sheets, agenda bashing + Document Status (20 min) EAP-TLS (5 min) EAP-GPSK (15 min) + IEEE Liaison Request (20 min) + Password based method (75 min) Requirements (10 min) PP-EAP - draft-zhou-emu-pp-eap-01.txt (20 min) EAP-TTLS - draft-funk-eap-ttls-v0-01.txt (20 min) Discussion (25 min) Document Status --------------------- + EAP-TLS Ready to go to the IESG + EAP-GPSK Some open comments still need to be addressed that will be addressed in security considerations. + IEEE Liaison Request Matthew Gast presented overview of work in 802.11u related to requirements for an EAP method for emergency services. Joe Salowey: surprised by request. There is already a WG in IETF working on emergency related technology. thought that group would be tapped instead of EMU. Matthew Gast: Highlighted the EMU was tapped instead of ECRIT because they deal with high-order call handling. EMU seen as better WG to answer question at hand. - Matthew Gast Presents Bernard Aboba: asserted that EAP methods have poorer DoS resistance than PSK. Joe: agrees Matthew: admits he was loose with usage of DoS Presentation Continues Paul Hoffman: in what way EAP is used by 802.11 Matthew: it's for link-layer operations Presentation continues: - Basic requirements for emergency services: 1) No pre-existing trust relationships - anonymous cryptography is acceptable to them - Is it secure? 2) Small number of round-trips - concern that TLS messages are too long, they'd like to reduce latency - want fast speed of access since they realize the call will be of short duration Hannes Tschofenig: suggests that a new EAP type be allocated that then leverages a watered-down version of EAP-TLS that satisfies the reduced security requirements for 802.11u. Bernard: questions the requirement for regulatory requirements driving need for link encryption. Points out that the encryption without authentication is not satisfying any useful security requirements. Matthew: responds that operators/carriers sometimes reject having an open SSID. Bernard: most will have at least one open SSID. Matthew: in 11u, an SSID is set up that is dedicated only to emergency services. Objections in 802.11 to design a network only for emergency services....there is some fear that they conversation will have to be protected somehow, at least from hijacking, spoofing or splicing. From a network implementation view, the username in the public credential can be defined as being part of the emergencies architecture to know to treat it in a special way without having to reconstruct the infrastructure. Bernard: questions who the regulatory compliance requirements apply to: Is it enterprise or carrier. Joe: points out that there are still questions about requirements, but doesn't feel that EMU WG is not the right forum to discuss or change the initial requirements. there may still be some requirements based on the presentation. It's not clear that requirements are valid or that EMU can address this. Most of the work items and the way EAP works is focused on authenticating the peer. There may be possible solutions, as Hannes brought up a special method for it. Steve Hana: EAP-TTLS supports server-side auth only if needed. Joe: take discussion to list to see if there is anyone on list that has additional insight on what could solve 802.11u requirement Hao Zhou: asks about timelines Matthew: says this exercise is not critical path for their work. They ultimately just want to point to the IETF recommendation at the end. Dorothy: it would be extremely desirable to have a final recommendation by July '08. Hao: feels that there is no need for a new EAP method. Existing EAP protocols can be leveraged as long as a pre-defined policy is adhered to that satisfies 802.11u requirements. Joe: don't know of any standard track methods that could address this. If there is work to be done, we'll need a liaison to keep the work going. Hao: based on some current methods, it doesn't seem like a new protocol is needed but rather a policy to help validate the server cert or client credential. If we can make the current EAP method that can be configured in such a way, no new method is needed. Joe: to do something expedient, there may be more work that is required since the current methods do not meet all of the requirements presented by TGu. + Password Based Method Joe: excused himself that he was not able to dedicate as much time as desired into this work item. Other high-priorities (EAP-TLS and EAP-GPSK) took his time. Joe goes through password based requirements Paul: Question whether password need to be truly randomized or can it be human "memorizable". Joe: says that password can be anything perceived as a "password". Gareth: asks whether OTP have been considered, asks if this would preclude POTP Chair: this mechanism is looking at supporting a password, could be but not limited to OTP Gareth: only mentioned other password - Hao Zhou presents PP-EAP Kaushik Narayan: asks how this work is different from EAP-PEAPv2 or EAP-TTLS? Is this a new method? Hao: says that they leveraged common design details from existing EAP methods and that a new EAP type will be likely allocated. This work may conceptually boil down to just extensions of existing methods, but because versioning brings its own set of disadvantages the cleaner approach is to treat it as a separate EAP method. Kaushik: responds that he felt the desire of IETF was to reduce the number of EAP methods, not increase them. Hao: a lot of these constructs were taken from other methods. But because other constructs are added and to solve interoperability issues, a new EAP method type is to be assigned. Kaushik: this is potentially a new version of an existing method. Joe: a concern of the extensibility, is that the WG charter item is to do a password based method. With the extensibility, will get us well beyond the WG item and make it more complex than it needs to be and cause interoperability issues. Make sure that the decisions we make do not confine us or cause more confusion. Kaushik: thought we need less not more methods Hao: but we need one that will be adopted by all and interoperate Glen Zorn: Asks where key material only comes from TLS exchange. Hao: yes. Glen: asks how crypto binding can be done if there is only a password. Glens asks whether the method has an inner method defined. Hao: no. Crypto binding left in method to allow future extensions that may require crypto binding. Today it's not required. If group feels that there should be no crypto binding, then it can be removed. Charles Clancy: the reason for the attack in MSCHAPv2 is because it could be done outside. Here there is no inner method, so it can not be run outside the tunnel. So, there's no need to bind the exchange to the keys derived. For this specific step....the binding is done for future. Doesn't believe we should support tunneled method inside this (like EAP-MSCHAPv2) the Glen: not really true. PEAP was that it could be used the same form of the password for other methods, this is true for stuff like VPN. We can not outlaw them for multi-use password Sam: needs to be documented in the security considerations David Nelson: points out that we should be careful on number of bells and whistles added. Points out that current proposal is a mega-method with ability to define any number of smaller sub-methods. Hannes: counters that there may be usefulness for allowing for future extensibility, in particular in light of desire to reduce number of future EAP methods. Dave: but then that should be another method. Dan Harkins: sarcastically points out that no one ever uses self-signed certificates on their authentication serves. Usage of self-signed certificates essentially nullifies any value of TLS. Passwords would be effectively transferred in the clear. Hao: but there are some backend databases where clear text password is not accessible. Hannes: EMU has already adopted methods like EAP-GPSK that could be used for such a purpose. Bernard: comments that the PEAP MiTM attack had nothing to do with the method. Hannes: so this should force us to put a requirement to guard against such an attack? Charles: http authentication over TLS. We're not worried about binding the password into the TLS key. Sam: but we should be Joe: seems like crypto-binding should not be required if we're trying to "keep it simple"". Kaushik: asks whether this new method could be run as a inner method to another method. Hao: says no, but there isn't any way to disallow it. Joe: the idea is to avoid that situation. Which is why we need to limit what is inside this tunnel (method). Glen: Original question: since problem is reuse of credentials and we can not force people to use the same password on different applications, how are we going to address this? Hao: we can not fix it because it is not on our scope. We can put the limits into the security considerations. Glen: points out since the re-use of credentials is the base weakness at root to many security vulnerabilities, is there anything this method that will prevent credential re-use. Hao: says no. Glen: isn't the layer EAP and PP-EAP mixed up? Hao: this is looking at it from a packet encapsulation layer Kaushik: are these EAP TLVs? Hao: these are just plain TLVs. Application layer TLS data. Joe: packet format looks like EAP-TLS Hao: yes. Sam Hartman: : we haven't had enough fun yet. Problem #1: what language should the password be in? Invite to side session on Thursday to talk about internationalization. The discussion will be on what lead to the stringprep discussion. Stringprep requires exact matching vs. fuzzy matching; not clear that passwords in all environment meet that requirement. It may be reasonable to try different normalization of a password. We had an attempt in SASL (for internationalization); but need to carefully consider when stringprep is used (profile and design of profile needs to be strongly reviewed). Hao: asks whether usage of just UTF-8 would suffice. Sam: Answer is an emphatic no from Sam. Hannes: asks for suggestions on what to do. Sam: says attend the Thursday SAAG meeting and read the draft that deals with issues on internationalization. Glen: L2TP talks about internationalization so you may take a look at that too. Charles: Asks whether we need to wait until TLS exchange completes in order to start exchanging challenges. Hao: says that it's possible to optimize and start exchanging information beforehand. - Steve Hanna presents EAP-TTLS Joe: asks why allow a DIAMETER AVP in EAP method? Steve: clarified that format is leveraged but not the code types. Bernard: this is not reusing Diameter, it is using the AVP format. Joe: only format or type codes? Steve: only the codes from RADIUS. Joe: it is confusing to reuse the typespace from RADIUS Allan: it is implicit, it seems like this is overly RADIUS. One should not put RADIUS stuff inside the authentication message originated by the client. Joe: agrees Bernard: but could use it for channel binding Sam: will need them for Housley key management Steve: Base assertion is that EAP-TTLS can cover all requirements, so why start over? Hannes: Hannes asserts whether after all the changes being introduced (channel binding and internationalization) can EAP-TTLS still be called as EAP-TTLS. Steve: what you'd be doing is providing additional AVPs, the client can send an AVP that it would prefer to use the new AVPs and the server would have to ignore them if it doesn't know it. Hannes: challenges whether EAP-TTLS can make the claim that it's free of IPR restrictions. Steve: the extensions that we would define in TTLS vs. starting from a new protocol. But do we want to start with something that has been widely implemented and extend AVPs or do we want to start from scratch that can only be used for passwords. Seems likely that the marketplace has been enthusiastic about TTLS, but if we create a new way for password; it seems unlikely to him that 'they' would abandon already existing code . Crypto binding are no longer considered a requirement. Hao: challenges statement that the other, PP-EAP, protocol is not widely implemented. Not true it is based on EAP-TLS which is widely deployed. There are also other protocol Steve: it would interoperate, it just wouldn't take advantage of the new features. If you want to add crypto agility to TTLS Hao: to meet this requirement, need to add crypto binding. This will need to be added. Steve: if there is an AVP it doesn't know, you ignore it. Hao: there are a lot of options that the negotiation of what's required versus not may be too confusing and complex. Vidya Narayanan: Adding TLV to address Hao's point, if there's extensions or changing the version number seems simple. So, would be a proponent to adopting something that is already deployed. What is missing from TTLS that we would have to add? Joe: there were requirements that TTLS is not meeting which is why the extensions to TTLS were proposed Kaushik: there are 2 options. What is being proposed is an "uber" method, but essentially do all the password based mechanism...that is the key difference between TTLS and PP-EAP. So, are we looking at an "uber" method approach? Because if we are doing that then we should look at EAP-FAST or other tunneled methods. Alan: TTLS uses the Diameter AVP, what are the IANA considerations for the number space because it is reusing some of the name space? Steve: Paul would be a better person to answer this. Bernard: the scourge comes from vendor specific. When talking to customers: they do not say "we need more EAP methods". If it possible to start from something that is widely implemented, then it would cause a lot less pail. The nice thing about TTLS, it supports the notion of non-mandatory AVPs so it makes it easy to add the channel and crypto binding. So there is a nice transition story since there is open source code available. For something like channel binding we will need code. Charles: advantages of PP-EAP over TTLS. The fact that PP-EAP cuts out the unneeded things is the advantage; from an interoperability standpoint. Hannes: comment on what's new and what's not: If you have a new protocol and put stuff to it, like changing or adding AVP's, is that new? It is a philosophical issue. To interoperability issue: it is a tighter specification versus "flexibility" in negotiation. There is rarely a chance to change or "fix" some of the concepts like key derivation, then it is not the same method. Joe: a notice on both approaches. We're looking for a password based method, but then we get the kitchen sink which worries me. There's a significant amount of things just to meet the password based method, like change of password, character sets that throwing other things is expanding the charter and in general introduces a lot of complexity. Gabriel Montenegro: seems painfully obvious that we need to start with something that runs is known, has been known not to be extended and very importantly has been adopted by different organizations. These are critical for actual deployment, TTLS is already being certified by WiFi and soon Wimax, that should not be discounted to easily. Alan and Steve: were going to say the same thing. - Joe puts out question whether group has opinion whether we should focus on just a simple password-based method or a more-complex, yet extensible, method. David: : this sounds like re-do the charter. Seems like the work that was chartered was just a password method. Now it sounds like we are trying to rescope the charter. Joe: there are potential implications in adopting something broader, like complexities and potentially more work. Glen: depends if you're pragmatic or theologian. TTLS is password based but happens to be more...so it can be considered outside the charter Sam: you can give me a TTLS and thou shall use it only for certain things. Glen: asserts that the editors of EAP-TTLS haven't been very active in WG. Nervous about accepting work. Sam: says we can steal it, as long as they are fine with it. Steve: suggests that Glen: if we do what Sam suggests, since it is being considered by other groups, they are not going to accept the idea of just plaintext passwords. So if our RFC says only plaintext then the other groups may not adopt. Steve: if we take TTLS as the start, then the TTLSv0 could be documented as the start. That could be the stable point to start from. Could also move forward in adding the AVPs to make sure that all requirements are being met....and then there could be another document to state how it is limited to address Hao: concerned that if only a subset of TTLS functionality is carved out whether it would introduce unacceptable interoperability problems. Alan: to a certain extent, EMU requirements could be to define a new type to carry the restrictions of TTLS. Bernard: procedural complexity of informational, standards and working drafts. But from a purely technical point, it could be done without having to bump a version number. Joe asks the WG to hum on two questions: - Should we focus efforts on a password method, which could be based on EAP-TTLS, EAP-PP, and can only be extended with channel bindings but nothing else? - Should we focus efforts on a method that performs password authentication and is extensible to do other forms of authentication? - Louder hum recorded to limit ourselves to just password method. - WG requests and Joe grants a hum on two additional questions Second question - Who would like to base this on EAP-TTLS? - Who would like to base this on a new method? Consensus of hum is difficult to discern. Joe: let's take it to the list.