---------------------- EAP Method Update (EMU) Minutes IETF-68 Prague, Czech Republic March 19, 2007 -------------------------------- Chair: Joseph Salowey Note Taker: Nancy Cam-Winget -------------------------------- -------------------------------- Agenda -------------------------------- 1. rfc2716-bis 2. EAP-GPSK 3. Password-based method 4. Additional Item - EAP extensions -------------------------------- RFC 2716bis - Bernard Aboba -------------------------------- - Discussion of changes in version 08 - Open Issues mostly around certificate usage + Discussion on multiple names in certificate Joe Salowey: what if there is more than one subjectAltName? Tim Polk: states that we need to define the same context and rules. Stefan Santesson: having more names in a cert is not a problem so long as matching the name requirement is okay in general. Tim: retorts that it can get tricky as it depends on where the name "sought" is in the appropriate place. Sam Hartman: trying to authorize access; all names provided in a cert should be valid, so if any of those names match an authorizable name, then access should be granted. Tim: questions whether there would be an issue if there's a distinguished name versus an RFC2716 name... Sam and Tim: agree that as long as there is a searchable name, it should be "good enough". Bernard Aboba: comments AAA server should try to see for the name to match in any and all the fields. Hannes Tschofenig: comments it may just be an implementation issue by the EAP server. Doesn't believe the checks need to be constrained and precise as it would require full description of what is to be matched; in this case it shouldn't matter. + Discussion on where to put MAC address in certificate raised by Ryan Hurst on list Bernard: comments that it arose from cert applicability of whether the MAC address is in the subjectAltName and whether they should be colon delimited or not. Stefan: comments on 3 alternatives: (1) distinguished name; (2) permanent serial number and (3) creating a new "other" field. Concern of use of (2) and (3); suggests the use of an OID as part of the TLS exchange. + Some consensus that the previous comment should not be part of this spec. Tim: agrees its out of scope for this group. All names should be equally valid for the subject; they are for specific contexts. + back to multiple names in certificate Joe: comments that subjectName may have multiple components. Sam: mentions that all parts in the subjectName needs to be valid. Tim: notes that especially for distinguished name, one should not extract a portion it should be used as a whole. Sam: mentions RFC 2818 describes exactly what Tim said not to do. Bernard: summarizes it may not take long to resolve. Paul Hoffman: comments on how prior descriptions still may not give us interoperability. Servers tend to be lazy as they will scan for first match and then fail (too easily). Bernard: concurs and notes that we'd need to add more text. Gregory Liebowitz: mentions that there should be a clear indication of what name should be sought. Hannes: mentions that IPSec has experience on this, 802.16 also has this application. We should find out where the MAC address validation occurs, if it is terminated by the EAP server, AAA server or otherwise. Vidya Narayanan: comments TLS cipher suites not supported by the draft, questions which ones are. Several respond that there are quite a few that are documented as SHOULD and SHALLs to enumerate the supported ones. Bernard: mentions behavior of 2716 requires that request for cert is still be made. Sam: mentions that this is last call issues and to be cognizant of this state so that we do not open up more new issues. Bernard: states that we should look at text and see if there's anything wrong. If there's nothing broken, then we can open it to a wider group to get more eyes that have deeper certificate expertise to help review. -------------------------------- EAP-GPSK - Hannes Tschofenig -------------------------------- Current status and mention of reviewers. - discussion of cipher suites and KDFs - 2 current cipher suites: AES-CBC-128, NULL - suggested change #1 CBC to CTR in ciphersuite #1 - suggested change #2 KDF use MAC-based vs. hash based KDF. The commenter mentions that the change is not aligned with http://tools.ietf.org/html/draft-dang-nistkdf-01 + KDF discussion Tim (with NIST "hat"): tries to clarify without having looked at this document. NIST has a standard for keys derived from key establishment (DH, MQV)...they way NIST works, it looks at a standard to use one of the approved methods. There's nothing against using MAC's in KDFs by NIST, previous guidance may have been misled on the belief that key establishment was based on DH. Charles Clancy: comments there were other suggestions but HASH vs. MAC requires a new cryptographic function in the draft. Sam: argues that there's no theoretical basis for why hashes are good for KDFs. Tim: apologizes that NIST's SP856 can be confusing, he hopes to do a presentation in Chicago to help clarify. Suspects the suggested reordering may be warranted but change from MAC to HASH is not a requirement. Lakshminath Dondeti: comments that he'd like to see the draft before commenting. Sam: mentions that if a MAC constructions meets the desired properties, that should be fine...unless you want to do something different and its aptly justified it could also be accepted. Lakshminath: comments to the contradicting opinions on hash vs. mac constructions. From the current feedback, perception is that hash may be stronger. Hannes: comments that the draft will revert back to the MAC construction. Tim: mentions there is sensitivity to ordering and unambiguous ordering. But this group is not in the space of SP856 so that document should not have an impact on this body of work. + CTR vs. CBC + Hannes: brings back suggestion to change CBC to CTR mode. Lakshminath: as one who suggested change, notes that it is not such a big deal; but mentions that CBC mode requires implementation of both encrypt and decrypt. Hannes and Joe: mention that performance is not an issue. Hannes: also mentions that code size is also not an issue as the code bloat is not that large. Document explicitly notes that other ciphersuites may be used. Joe: notes there's no strong compelling reason to change Sam: notes the group has to have consensus to change which is not apparent -------------------------------- Password based method design team update Madjid Nakhjiri -------------------------------- + Discussion of requirements + Open issues on requirements to discuss: - Should we require password/pin change - Other password based protocols (CHAP, MSCHAP, etc) - Cryptographic binding of password exchange keys to keys of the protection layer - extension mechanism (data exchanges inside tunnel) - transport of channel binding data - protected result indication - OCSP for cert-based "server authentication" + Leaning direction: towards Use of TLS - presentation of how TLS is used - data format alternatives discussed: XDR (RFC1832), AVP, ASN.1....leaning towards AVPs + Discussion of Remaining Open issues: + new EAP method type: do we use one method type for passwords only? Sam: cautions multi-layer negotiation as being a potential issue + Do we need messaging framework or just TLVs? Sam: comments on crypto binding as being a requirement that authentication at one layer be tied to authentication at another layer. Like using the TLS finished message. This is as an alternative to mixing key derivation but notes that crypto binding is a requirement. Hao Zhou: mentions that using the TLS finished message signing may require extensions to this. Sam: mentions that we could sign the TLS finished message Hao: mentions that we may not get a key from the password method Sam: agrees that if we use the key from TLS that is another way to get the crypto binding. Hannes: mentions the crypto binding discussion came from the tunneling; the best work showed that crypto binding is a requirement. If a password is done on top of the EAP exchange, it wasn't clear that we needed the crypto binding....still not sure on how to handle that case. Hao: responds to Sam that the TLS tunnel is used to generate the EMSK and MSK since its not guaranteed that a key is generated from the password exchange. Joe: mentions other issues with other password based protocols, where some methods require the passing of username and passwords during the exchange. Hao: mentions to adopt a consistent crypto binding as there are different password exchanges + Joe: asks whether we want to adopt other schemes than just plaintext password, asks the general group if there is use to adopt something other than plaintext password. Hao: mentions that some client implementations only obtain the hash of the password. Bernard: you can always ask the user Joe: Hao are you referring to the case where single sign on or some other mechanism restricts access to password Hao: yes Joe: mentions there's not much excitement in adopting more than plaintext but discussion to be continued on the thread. Lakshminath: asks how this work would be different than PAP? Joe: mentions it will not be any more different than TTLS, PEAP or EAP-FAST but wants to make sure we do not support everything under the sun. Keep the model simple. Lakshminath: asks on EAP-TLS and discussions on how to use EAP with TLS. Hannes: mentions that it is not new, it is new in the sense that one author dropped from the original draft. Sam: mentions that EAP has limited applicability. Hannes: comments EAP applicability in TLS has also been rationale in IKEv2 Sam: mentions there are different mechanisms for doing authentication; doesn't want groups adopting frameworks based on methods supported. Unless all frameworks are made to work together, he will make strict ruling on applicability. But it is outside of scope to this group. Bernard: comments that customers are tired of this and wants to standardize on a single one and not to create more tunneled EAP methods. - Joe: returns to open issues and discussion of password/pin change: Sam: believes it is very hard to achieve Paul: email did this (POP) and no-one used it Hao: believes we need to address it, if we don't, a new method will be created to address it Paul: iterates that we need it though is not convinced that we need to spend a lot of time to get it "right" Jeff Hutzelman: mentions a requirement for extension as a pro and suggest that at a minimum, defer the password change mechanism until we get to the extensibility. As the extensibility should allow us to do password change in the future. Hao: speaks as an implementer to getting many customer requirements to support OTP and password change. Hannes: asks if there is such a mechanism documented. Sam: mentions there isn't one and this environment may be different than an email environment. Today, with EAP, it may not be feasible to get anywhere until the password is changed. Paul: agree Joe: closes that there is agreement that we need to support password change...we may need to go further Paul: mentions that this (password change) may be a good test of extensibility Joe summarizes: + crypto binding may be taken care of thru the use of the EAP TLS tunnel for key generation. More discussion to continue on the email thread. + extension mechanism is a requirement as it will be used as a means to address other requirements such as password change. + transport of channel binding data: may be another use for an extension + requiring protection of the result indication Sam: You need to explain how you are going to meet draft housley AAA requirements - Discussion of the results being reliable Jefferey: asks if the EAP fails, how do we authenticate the result indication? Joe agrees it is a hard problem, but could authenticate the other failures like bad password or other conditions within the tunnel. More people think its good and no one was against implementing this. Sam: asks to look at the Housley requirement if we choose not to do this. - OCSP for cert-based "server authentication" Sam: comments that this may be not enough as it doesn't give you status of intermediate, nor anything else that could be done to remedy this without touching TLS. Charlie: mentions that SCVP could help. Sam: doesn't quite agree as TLS would have to be modified to do SCVP within TLS....though it could be done within the tunnel (as a blob). But the catch is that SCVP may not be widely implemented to force this be implemented by this group. Joe: asks whether OCSP should be mandatory? Jeff: comments that question is not well formed. Joe: clarifies that this would require OCSP extensions to be mandatory to implement. Jeff: mentions that requirement imposes a deployment requirement on the protocol Joe's: concern is more on implementation that if its not supported, then there is no means to enable vs. disable this feature. Stefan: notes that it is different to say support (enforce) OCSP versus require to implement Joe: means require to implement OCSP Tim and Sam: agree that there has to be a strategy for certificate checking including revocation; given the proposals there must be one mandatory to implement Joe: wants to continue discussion Yoshihiro Obha: mentions that his presentation discusses channel binding Joe: mentions target is to have draft out by next meeting (this concludes working group Discussion of Working group items) Sam: asks if there are any Hokey chairs and caucus with them to determine that Yoshi's presentation is out of scope for this group. Yoshiro: retorts that his presentation is on an EAP method Glen Zorn (HOKEY Co-Chair): Does not have an objection to the presentation -------------------------------- EAP-EXT - Yoshihiro Obha -------------------------------- * Proposal to use EMSK usage * Channel binding issues: two approaches and lack of support * EAP notes: no version, lack of backward compatibility * Design discussion on how to extend EAP to allow for: - sequencing in a single EAP conversation - sequencing multiple EAP conversations - allow for channel binding * Proposes EAP-EXT: a tunneled method with protected capabilities exchange to enable sequencing inside the tunnel and allow for backwards compatibility. - proposal includes TLV for accomplishing Key (EMSK) derivation, channel binding and crypto binding but using its own construction. - proposal was also presented in HOKEY meeting Hao: questions how this is different than TTLS, PEAPv2, EAP-FAST Yoshi: mentions capability negotiation and being able to do "other" things. Glen: likes the capability negotiation and would like to see it expanded, though there's not much applicability in HOKEY it is work looking at other uses Alan: going on capability discussion there's a lot of discussion in RADEXT Joe: mentions there's no space to take this up as a work item. Jeff: What do you recommend the author? Sam: clarifies that this working group has a fixed charter and this is not one of them; revising core EAP is not in this group's charter. Jeff: concludes that there's no current home Sam: suggests a BOF Joe: says need to articulate the problem we're trying to solve in the BOF Sam: mentions it could be an individual submission but is leery of this given that it is more intrusive to the EAP protocol