EMU Minutes ========================== TUESDAY, December 4, 2007 0900-1130 Morning Session I Cypress ========================== Chair: Joe Salowey Note Takers: Nancy Cam-Winget, Steve Hanna, Susan Thomson =========================== + Draft updates - EAP-TLS (RFC2716bis) sent to the IESG - EAP-GPSK editorial fixes and comment resolution for EAP-GSK based on feedback from some researches ready for IESG Sam Harman: mentioned that he will prioritize to forward the EAP-TLS draft and when ready, the EAP-GSK drafts. ----------------------------- + Charter update * Add a charter item for a standard tunnel method * Modify the password-based item to use the tunnel method * Modify the enhanced TLS item to focus on adding channel binding to a TLS-based method (EAP-TLS or a tunnel method) * Update the milestones to include requirements draft + method name Joe Salowey: need to choose a consistent term: tunneled method, tunneling method, tunnel method. Propose "tunnel method" Steve Hanna: prefers "tunnel method". + RFC compliance requirements Hao Zhou: do we have an exact definition of "enhanced TLS mechanism" and what the enhancements are? Joe: no, that is something we'll need to define and clarify. Hao: when we say "additional authentication methods" are we talking about channel binding, or other things? Joe: channel binding is a requirement but the others, not sure that they will need to be explicitly called out in the charter. Bernard Aboba: clarifies that the bindings are optional based on RFC 3748. Sam: speaking as an individual, I don't see how we would meet the requirements of RFC 4962 without imposing channel bindings. It would be useless if we adopted something that didn't meet those requirements. Comment: RFC 4962 is currently not in the charter Sam: is EAP keying listed in the charter? Comment: given that it's still a draft, don't see how it could be included. Also not referenced in the current charter (EAP keying) Sam: if we're not bound by RFC 4962, then channel bindings are optional. But then this can jeopardize the efforts of Hokey as there's no way to ensure a method that can work with the work coming out of Hokey. Joe: there no mention of these items in the emu-charter, not sure if this was an oversight or intentional. Steve: raised that the charter doesn't call out requirements such as the keying framework….since other requirements list out the RFC's to reference other documents to extract requirements should we do the same for tunnels? Steve: perhaps we can just clarify generally "all mechanisms defined by EMU should meet the following requirements"….if there are other RFC's then we can just add it to one list. Update can read "All mechanisms standardized by this group must meet RFC 3748 and RFC 4017 requirements. This group is chartered to work on the following types of mechanisms:" Hao: are those the only 2 RFC's requirements? What about EAP-keying? Why would we single other requirements to only one particular Joe: does anyone else agree on this? Sam: am more concerned on RFC 4962….would recommend not adopting EAP-keying yet Charles Clancy: how is RFC 4962 required for Hokey? The fact that its bootstrapping its keying from RFC 4962 Sam: may put a requirement on an EAP method to get such keying material Charles: RFC 4962 still has gaps in how keys are distributed. Sam: there's an open issue with RFC 4962 and Hokey and how keys are delivered Charles: during authentication, the MSK needs to be delivered and its not something that is currently RFC 4962 be compliant. Sam: that was one of the intents of RFC 4962 Charles: if there's a proxy, then it will not help especially how all those keys are being managed Sam: yes, that is an issue that will be discussed tomorrow. There are some problems with RFC 4962 Joe: RFC 4962 does not have EAP requirements. Bernard: believe the issue is whether the method can determine that the authenticator (or the port) gets the key as the intended party. The channel binding can help as there is full agreement….there would worthwhile to have a document that explains and clarify what the channel binding architecture achieves since it has been hard to get the lower layer guys push up required material. Making a case to go in this direction is needed. Sam: need to move on. Joe: sounds like we need to require a statement that says methods must also support for RFC 4962. Hao: if we add this, then we'll have problems with EAP-PSK and EAP-TLS….are we going to backtrack to fulfill these requirements? Sam: sent question before regarding this. My recollection on mail sent, Sam will ask to make it clear on how channel binding could be added to these methods. Would be okay accepting this….did not recall getting negative comments for this. Hao: if we make the requirement to support channel binding, one of the problems for TLS is we would have to grandfather it in since there are implementations out there. Sam: EAP-TLS has already move forward so lets leave it Steve: lets remove it out of the list then. Sam: remove completed items. Paul Hoffman: that is weird. You're going to have a set of milestones that will have a hole in the middle of them. Where there's normative specs in the body but not in the ASN specs….while we're not meeting RFC 4962, to take it out of the deliverables but then above to imply that we've delivered it, is confusion. We need to be clear of where it is required. Joe: OK Sam: doesn't like that but it's not worth fighting over. Joe: includes RFC 4962 for some of the methods. There is a path to support this in EAP-PSK so authors are okay with this addition. Hao: suggests that we explicitly state channel binding versus calling out RFC 4962. Joe: believes it would be clearer though not sure it would be accurate as there may be other requirements. Sam: doesn't want to get into argument of what is and is not in RFC 4962 within the working group. So if 4962 is broken then we should fix it. Steve: though we have an unspoken agreement, not clear that there is a plan to address RFC 4962…don't think we should proceed "must meet 4962" when it may not be clear. Hao: we should be clear on what it means to meet RFC 4962 Joe: so can change to "mechanisms must be capable of supporting channel bindings." Bernard: we really should defined what it means to "support channel binding" should we add this as a work item? How do we ensure that it is added to the group? Joe: we will need to clearly define what this means…. Sam: agree with Bernard & must be written somewhere, though updates to EAP are outside this group. We can change charter to this group, but it will cause further review. This piece is missing and no one is fixing it. Joe: we need to fix this if we are to move forward. Nancy Cam-Winget: if we can't define it in this group, then we should remove it as a requirement on our charter revision. Tim Polk: its up to the area directors to figure out where this work is to be done. Perhaps we create an adhoc editing team to…may came back to this group or another group. Regardless of where it happens, it impacts many groups so leave it for now so it doesn't hinder our progress. Bernard: we will need to get consensus behind this. There will be requirements on L2 that they are not doing, so the IETF will need to motivate the lower layers to comply as well. Tim: yes, it will have to be compelling enough to make everyone do it. But we don't want to hold other work until this gets sorted out. + Enhanced TLS Joe: we can move off this update to next item on the "enhanced TLS" item. Bernard: how is this different from the "tunnel method"? Joe: feedback from Jari that definition may be slightly different even tho it's the same problem. Hao: to clarify, it's not 2 different methods. As far as the channel binding it's already covered in the top. Joe: will modify it to explicitly state that it’s not a new method. Hao: we do need to ensure that "emergency call" scenarios are supported. Joe: a response was made to TGu, that we "could" support them but until we understand the security requirements of the emergency call and operational requirements, it's not clear how we can tailor EAP-TLS to meet their requirements. Hao: am personally advocating that we should support such a scenario. Joe: that is fine, but we will need to get clarifications on requirements from them. Glen Zorn: combing slides 6 and 7, there is probably a politically morass given that these can constrain requirements to two methods that have already been deployed. Joe: while there is a desire to do that, it is not specifically requiring it to be a particular method. This particular item is to state that we don't want to create a new EAP TLS based method. Steve: can clarify by stating "based on EAP-TLS or a TLS based tunnel method in the preceding item". +Password Method Joe: Next item discussion are the updates on Slide 7: "A mechanism that makes use of existing password databases such as AAA databases. The implementation should strive to be usable in resource constrained environments. This item will make use of the above tunnel method." Dan Harkins: does the "constrain" mean no PKI? Sam: if don’t know what it means, then take it out. Glen: don't want to take it out, but we should clarify. It's a good thing to have as there are large customers do work in resource constrained environments like 3GPP and 3GPP2. For this to be really useful, we should be able to clarify such as "resource constrained environments, such as mobile phones." Bernard: we did have a discussion in GPSK. One of the conclusions was that couldn't do a full TLS…but adding this to the work item may Dan: a suggestion is to remove that sentence Joe: group has already chosen this direction. Pasi: note that current phone does support PKI Sam: adding example will not help. To be useful as a constraint, we need to be clear what the constraint is….must work in an environment without PKI would be fine, but is one that we would disagree with. If there's no volunteer to clarify, then drop it. Glen Zorn: volunteers to help make this concrete. + Milestone update - tunnel method items: add item for requirements draft Glen: this (requirements) would be a good place to impose resource constraints in here. Joe: we can discuss them during requirements, not sure it makes sense to impose in charter until we have clarity. Hao: there should be 3 things in tunnel method, two of which are mentioned but the inner method extensions are missing, not to mention what the clarification of "inner methods". Discussed tunnel and password method requirements but we need to define what the inner authentication mechanisms. Need to see a definition of what "inner authentication" (like method sequencing, data exchanges, vendor extensions) means. Joe: we should call that out in the charter though. At this point, need to determine what the requirements are. Hao: for the "extended tls method extension" deliverables, is that base on the EAP-TLS method or the new method? (Joe agrees that it may apply to both?) Steve: agree that constraint environments should be included. Suggest that "resource constraint" and level to which it is needed should be part of the requirements definition and not necessarily part of the charter. Tim & Joe: agree….during requirements definition is when we as a group can decide the constraints. Glen accepts this…though milestones don't quite mesh yet as there are no requirements for the password method in the deliverables. Point is that we should be more explicit. Joe: brought in by reference is that it would be included. But, we can remove the "resource constraints" from the charter. Joe: Take milestone discussion to the list. (presentation modified during discussion is available with proceedings) --------------------------------- Tunnel Method Presentations --------------------------------- + Steve Hanna Presents on EAP-TTLS * New drafts for crypto agility and extensions for TTLS. * Overview of TTLS protocol and supported features * Extensions to TTLS: PRF negotiation through TLS version; crypto binding through a key-confirmation AVP - Hao: what keys are used to generate the crypto-binding? So, if the inner method fails, TTLS can not do the key confirmation. - Steve: correct. Pat Calhoun: have addressed security issues with TTLS, that is good. Should the standard address current security requirements and how would the legacy be enabled and handled as it would have to be supported? Steve: this depends on the group, whether we start from an existing method and upgrade then to include the security extensions. TLS adds support for transition through turning on M bit. Up to WG to decide on whether new functionality falls under new EAP method or not. Not a strong position either way. + Gene Chang presents on EAP-FAST * description of deployed features inclusive of security considerations * features include flexibility and scalability of credential types and computational constraints Sam: PAC What is it? How can you get one? referred as RFC 4507. Joe: PAC is like a ticket as defined by the RFC Sam: how do you get a ticket if you don't get it via a certificate. Gene: can provision in-band through the protocol or manually (out-of-band). Hao: PAC is in RFC 4851 and used as defined in RFC 4507 -------------------------------- Requirements Discussion -------------------------------- * Can start with password based methods since members were already thinking of tunnel methods Hao: we'll need to add crypto agility Joe: hold that for now and add it during the brainstorm. Looking at current requirements, we'll need to make sure that we can meet RFC 3748, 4017, eap keying, etc. Hao: authentication of the EAP headers should be included and Identity privacy. Sam: if we are going to do anything with TLS, it needs to be reviewed by the TLS group. Any mechanism like the PAC should be reviewed by the TLS community. Joe: so any novel uses of TLS should be approved by the TLS community. Sam: how about requirement that the use of TLS and the tunnel method be removed by the TLS community before completion of our work. Consensus that suggestion is a good idea. Steve: are these requirements for the tunnel method or the password method? Joe: we need to cover both, thus far these requirements are for both. We could treat them as separate requirements. Steve: requirements for the two are largely disjoint; no strong opinion on whether its one or two documents. If it is one document, then they should be described as two totally different things. For example: password requirement may not need to include mutual authentication. Joe: since group has decided to address password thru tunnel, the combination must meet the requirement of mutual authentication. While the requirements are disjoint, there may be some specific to tunnel or to password, but there are interdependencies…so we need to make sure that the combined meet full requirements. Agreement that we do need to be clear. Kaushik: are we creating a new set of requirements? Shouldn't the requirements be to include existing password methods? Joe: don't know that it is part of the charter….we are to support existing databases not necessarily methods. If we're supporting EAP authentication mechanisms within the tunnel, those will have their set of requirements. Hao: just as we mentioned internationalization, agree with Steve that we need to list separate set of requirements. Glen: ultimate goal is to get secure password based method; tunnel method is to facilitate this. Joe: yes, but there are those that want to support other features beyond password authentication in the tunnel. Glen: having designed a tunnel method before, would like to state that it would be better to design these things together so that they work appropriately. Generalization would be the enemy of this. If we're to design a password based method, making the tunnel method support "the kitchen sink" is not a good idea….focus should be on password first and not make the goal to support other things. Steve: disagrees. If we look at them together, that is good; but its not desirable that we only focus on the password only. There was consensus by the group to not specialize for password based method only; not suggesting we expand the scope to include everything. But it would be an error to only consider password. Glen: intent was to ensure that the tunnel based and password based method and how they work together are extremely well understood. Generalizing makes it harder to do analysis. Joe: agreement that we need to consider the password method within the tunnel method. There is a constrained set, though not fully constrained yet, of other conversations that may happen within the tunnel. Glen: if tunnel method is well designed, then probability that its confined to only work with the particular password method is low. Not sure that password change really belongs here. Joe: there was consensus that this was a desirable feature. Steve: change of topic. Add requirement to include internationalization of human readable strings. Sam: should include "internationalization must be consistent with NAI, human typed passwords, and prompts. Consider errors and other indications." SASL RFC has good text on how to deal with internationalization. If you use something like RFC 4013, we should be on the right track. Glen: not sure what the point of internationalizing password. Sam: we need to ensure that it can work across different OS' which is why we need to ensure it meets the internationalization criteria. If the user has a password that contains an accented character, the bytecodes generated for that password may differ depending on which computer the user is typing on. Joe: earlier we had a requirement for Constrained devices Decide the charter updates through the working list Need to get working on requirements draft together Sam: RFC 4962 and channel bindings confusion. Could use some help here, so contact Joe, Tim and Sam on how to resolve this as it is more complicated than originally thought.