Here are the draft minutes for the EMU session, let me know if you have any corrections:
Minutes for EAP Method Update (EMU) at IETF 66 --------------------------------------------- Date: 7/12/2006 Time: 9 - 11:30 AM Place: Montreal, QC Note takers: Nancy Cam-Winget, Madjid Nakhjiri Summary --------------------------------------------- The first topic of discussion was presented by Hannes Tschofenig on the draft Generalized Pre-shared key (GPSK) EAP method which specifies a PSK EAP Method. There was consensus in the room to take this on as a working group item to meet the PSK charter item with a modification to the defined cipersuites (switch AES-CCM for AES-EAX). The action is to solicit comments on if this should be accepted as a working group item on the EMU list. Next Bernard Aboba discussed the RFC2716bis (EAP-TLS) document. The presentation discussed some open issues of the draft. Interoperability problems with the TLS 3DES ciphersuites were discussed. It was noted that some variants of EAP methods based on TLS method used the same label strings in deriving the MSK from the TLS master secret. This is thought to lead to some potential problems so it might be advisable to use different label strings for this in the future. Lastly, identity privacy using TLS was discussed. The draft needs to be updated and listed as a working group draft on the charter page. Next we had some presentations on EAP-TLS related methods. Hannes Tschofenig presented on EAP-TLS-PSK which is an EAP method specifically for TLS PSK ciphersuites. Pascal Urien presented on an identity privacy scheme for TLS. The general feeling was this would be better evaluated by the TLS group. Hao Zhou presented on some possible enhancements for EAP-TLS. More discussion on enhanced EAP-TLS is needed on the list. Dave Mitton presented on issues implementing new EAP methods. One problem was that some access points don't pass some EAP types they don't know about. The action is to assist the WIFI alliance develop tests for this. Detailed Minutes ----------------------------------------------- 1. Generalized Pre-Shared Key Method (GPSK) - Hannes Tschofenig Hannes Presented Slides Discussion - Key confirmation Russ Housley: wants to make sure that last message has confirmation on last message that both parties have derived the same key Hannes: Message 4 is optional and the encrypted part is also optional Uri Blumenthal: questions need for explicit confirmation since Message 2 and Message 3 provides the information Bernard Aboba: may be confused, in 2nd message should know what the enc and MAC keys are used. The SEC_SK message is authenticated using a new key? Hannes: Confusion was around notation, the MAC's in the messages are using the SK which is derived from the nonces and the PSK. - identity protection Bernard: asks on how identity protection may be achieved? Hannes: Out of scope one approach may be to use only the key identifier Joe Salowey: temporary ID may be used, encrypted payload can deliver it. - ciphersuites Russ: asked why not choosing NIST approved modes? Consider changing it to AES-CCM. David McGrew: recommended use AES-CCM Sam Hartman: questions why have a NULL? Uri: mentioned simplicity thus a reduction, mode was chosen to ensure AES was used and most efficient thus why EAX was chosen. Pasi Eronen: why can it not be replaced with CBC, other people gave other options Joe: mentions crypto selection should not be contentious + Needs discussion on the list and with the ADs. - key hierarchy Hannes: Jouni has already made first cut an implementation of this method. Only took 8 hours. Joe: How many people have read the document? Hands -- 4 - 5 Joe: Hum for "is this in the right direction?" for: lots against: none Joe: Hum to accept as a working group item for: lots against: none + take it to the list 2. RFC 2716bis - Bernard Aboba Bernard presents - Key derivation Bernard: Not a good idea to derive keys using the same label, though this may not be as easy as it seems. Sam: mentions that TLS community should make it easy to change labels for key derivation - Multiple layers of negotiation Sam: does multiple layers of negotiation with EAP-TLS introduce a vulnerability? Bernard: 3748 with respect to protect against downgrade attack, you could NACK it if it is something you don't want to do. - Ciphersuite support Bernard: mandatory to implement ciphersuites: 3DES/HMAC-SHA1 failed interop tests. Some very popular EAP-TLS implementations with 3DES failed to even complete. Possibly results from some changes in openssl. Russ: how about the old openssl? Bernard: not tested Bernard: does anybody has AES implementations we can use and test? + question the list about AES support - Privacy Bernard: what does it mean to be backward compatibility especially with respect to privacy? Bernard's interpretation is that client requiring privacy must fail with server w/no privacy but must connect if it's not configured for privacy with a server with or without privacy. Russ: questions how documentation will clarify these transitions; wants to make sure it's captured. Bernard: responds that all this will be captured in the i-d. Vidya Narayanan: why its an issue with EAP-TLS vs. just TLS. Bernard: responds that it's heightened at least in this group. Hao Zhou: asks whether privacy updates will be mandatory or optional? Bernard: states it'll be made optional Bernard: I will send out a survey for the implementations (so far 4 responses) and work with interop. 3. Enhanced TLS - various presentations *EAP-TLS-PSK - Hannes Tschofenig presents on EAP-TLS-PSK - privacy Bernard: is it possible to support privacy in it. Hannes: I have seen some papers on it that does it without too much work Pasi: you could do within the first handshake, but it is probably a hack.. Hannes: it was not initially a requirement, now it depends who you talk to. - method number and negotiation Question: why is there a mapping of a specific EAP method to negotiate this versus doing it inside EAP-TLS itself? Hannes: responds that they should be equivalent. Sam: comments that options may cause problems when for example, if preference is to do EAP-TLS with some cipher suites vs. EAP-AKA but that fails then it may be better to do it through the EAP-TLS to choose a different ciphersuite then you get into a situation you need to decide which method you are committing before you start the method. EAP does not have a good way of saying this is the method I want to use or half way through it thinks I have a problem with this and want to start another one. Hannes: Isn't this a problem with any general EAP method. Hao: comments that EAP Identity response may include the realm shouldn't that help? Hannes: no, unless credentials are shared. RFC 4284 is there to provide identity selection hint from the server to help; Bernard: comments that while it may hint the network connecting to, but it doesn't really relate to the EAP method so not sure how it helps. John Vollbrecht: mentions that this is important work, but its not clear how we can best proceed forward. *EAP-TLS identity protection - Pascal Urien presents Joe: it seems to be a change in TLS, what would the TLS WG think about this? Sam: post this to TLS as an extension to TLS, and if they are ok, bring back Pasi: as an individual this seems that it would the same end result as adding a couple of roundtrips *EAP-TLS enhancements - Hao Zhou Presents Bernard: comments that this is more like the kitchen sink. Some of the requirements seem viable, but putting them all under one identifier is not good. Joe: agrees but questions that perhaps there is merit to considering trying to put them as one base for several methods. Bernard: responds that having too many options may break interoperability; mixing Kerberos, PSK seem to put things over the top. John: mentions that we should consider this, though its not clear that we could put this into a single standard...but states that this would be a very good thing and mentions that NEA group would need something like this. Joe: mentions that NEA is out of scope for this group. Stefan Santesson: using protected TLS tunnel is a very useful thing. Joe: comments that since TLS is evolving; 2716bis is only a subset and since the presentations today of how to make use of the extensions, it seems that this work is within the scope of this group. There could be one base framework and potentially manifest itself in multiple methods, but we must consider support for the requirements within the group. Joe: Asks whether other people would be willing to edit on the TLS enhancements? 3.5 folks Joe: review? 6.5 folks Password based mechanism discussion Joe: What about weak password mechanisms? Are there other alternative to methods like TTLS, PEAP or EAP-FAST? Sam: mentions that tunneled methods is out of scope for our charter, but addressing weak passwords may be within the scope of our charter. Bernard: asks how we're going to deal with PSK, is GPSK it or EAP-TLS-PSK should be considered? Joe: states that GPSK should be it. Sam: it seemed that there was no consensus to consider EAP-TLS-PSK, but it has not been decided yet. Hannes: mentioned that there was enough interest to trigger the design group to generate the GPSK method draft; also mentions the focus of the preso is on passwords not PSK. Stefan: questions the limits of the enhancements, better to include all of the TLS enhancements. Joe: agrees that the intent is to make the interface allow for supporting the new TLS enhancements. Bernard: questions having multiple standards for PSK. Sam: mentions difference between group's adoption of using something that may be widely adopted in our own GPSK versus defining or constraining the ability to use all of the TLS options just because they also support PSK. + Joe concludes: since there's enough interest, we should continue the discussion in the list to see where it leads. 4. Implementation experience - David Mitton David presents Bernard: we had an EAP bakeoff long time ago, maybe we need to have another Bakeoff. Russ: why would the vendors have to come to bakeoff if it is not a new EAP method? Sam: you can figure out characteristics of the problems people are running into and design test case accordingly to have people come and test it ?: In Korea some people have deliberately only allowed specific EAP methods Pasi: there is already procedure where all WiFi vendor come to (alliance), so maybe you can include that right there. Dorothy Stanley: that is a great idea, we can take that idea to WiFi alliance. vendors do their best, nobody is perfect, also iEEE does not do these kinds of tests, WiFi is the best places. Bernard: I have a lot of weirdo problems that maybe RADIUS related not EAP. Joe: it is within our interest that methods that this group develops will be tested. _______________________________________________ Emu mailing list [email protected] https://www1.ietf.org/mailman/listinfo/emu
