Extensible Authentication Protocol (EAP) WG IETF-65, Dallas, Wednesday March 22 2006 Room Metropolitan Chairs: Bernard Aboba Jari Arkko 1. Administrative (Chairs) - Document status (see slides) The EAP WG has completed all of its work items other than the EAP Key Management Framework and Network Selection documents, both of which have completed WG last call. This will be the last meeting of the EAP WG; the goal of this meeting is to close the remaining issues on these documents. Status of WG last call issues is available here: http://www.drizzle.com/~aboba/EAP/eapissues.html 2. Remaining EAP keying framework issues (Bernard Aboba) http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-10.txt (See also slides) Purpose of the presentation is to close remaining issues from WGLC. Five of six filed issues have been closed. One issue remains. The resolution of issue 317 is to focus on the externally observable behavior and avoid overspecifying internal behaviour that has led us to the debates on the list. Comments? Joe Salowey -- one concern that I have is the use of term "lower layer" which has not been clearly defined. Bernard agrees that there's been prior confusion with this term in another issue, and some of that still remains. Bernard thinks we need to take another pass to clarify the terms. Conclusion: Still need to confirm if the proposed text is acceptable on the list. Question if channel bindings text is sufficient in the document. Process point brought up by Jari: we are not committed in the EAP keying framework to solving the channel binding problem. Yoshihiro Ohba: Would channel bindings be pursued in other working groups. Jari responds that there is no plan at this point about where to address it. Time for the individuals to progress their documents, could consider recharterting an existing WG or doing a BOF. Bernard points out that having running code would help in convincing the community that the proposals actually work. Nit about group keying brought up on the list. To be corrected. Plan is address the remaining issues and then bring the document to a final WG last call during April. 3. Remaining network selection issues (Jouni Korhonen, Farooq Bari) http://www.ietf.org/internet-drafts/draft-ietf-eap-netsel-problem-03.txt (See also slides) Purpose of the presentation is to close remaining issues from WGLC. Bernard: This item has been a long time on our charter and the purpose of the WGLC is to make clear what the working group wants to say in this matter. Ten open issues have been filed under last call. What we intend to do is to close these issues and publish the document. Jari's comment on sections 1, 2, 4 has been done. This includes cutting away all text on work that is in progress. Authors not sure if the latter was needed, however. No new draft revision published before the IETF because there were new issues brought up just before the deadline. Farooq's proposal on corrected terminology was posted on the list. Bernard thinks it would be useful to talk about the terminology in this meeting, because multiple SDOs are talking about this, and its hard to communicate without well defined terms. Basic problem is that we use the term "network" to mean many things -- prefixes, visited networks, home realms, roaming networks, etc. Most confusion is caused by selection between operators and ISPs, because its not well defined what it means. Access technology and access selection is fairly clear -- I chose 802.11 and this particular access node. Comment - operator selection is a business term. Bernard does not think its clear -- for instance, in 802.11 is SSID operator selection, or is Farid's id selection it? Or something else? Jari Arkko - we need to name these things according to the data item we select. For instance, SSID selection. "Operator selection" is not well defined because we have no data item "operator" in the protocols. Pasi Eronen - yes we need a terminology update. Suggests network attachment point selection, identity/credential selection. Glen Zorn - I think we are talking about two different terms in network selection, visited and home network selections. Comment - Might be better to speak about home server selection because its not really a network. Jouni - Agree with these comments. Current draft mixes these terms. Another issue - current document focuses too much on 802.11. Bernard Aboba - one of the issues brought up during IETF-64 was that the document does not talk about enough about the problems that come up with some of things that have been defined recently, such as draft-adrangi. In the Internet is that we do not know a priori if we can reach a given address; to find out you send a packet and see if you get a response. This is similar to what should happen with realms in network access. There's essentially an infinite number of them, which makes it hard to store reachable network identifiers in any one place. Some of these scalability issues should be addressed in the document. Glen Zorn - The document says that there is no experience on applying phone book mechanisms for wireless access. I do not think it is the main problem. With phone books you have a unique identifier, the phone number. In wireless networks you may not have such identifiers, since many of the identifiers such as SSIDs may not be unique. Bernard says that the phone book approach is used, but in a different way. You do not press a button and dial a particular network. You may attempt to go to a location where the book says there's network. Comments by others that some phone books do list SSIDs. Avi thinks this may be useful in wireless networks, because currently he can count the number of business partners with his two hands and feets. John Vollbrecht thinks that large consortiums have issues with unclear or unauthorized SSIDs. Hard to know of operator X is "X" or "X1" and if someone spoofed "X". This might be useful, but we can't count on it. 4. Generic EAP encapsulation proposal (Barany, Dondeti, Narayanan) http://www.ietf.org/internet-drafts/draft-barany-eap-gee-00.txt Purpose is to get feedback from the EAP community on this proposal. (See also slides). Looking at a model which may need two EAP authentications, one for pure access, another for "service" (such as mobility). Glen Zorn - Why do you need to parallelize the authentications. If you have no access, you are not going to get service. The authors are looking at latency issues. Another issue is that in EAP the sequence number does not allow easily to demux where messages should go to. Requirement for this model has come from MVNO deployments that wish to have two authentications. Question - What is a service network, why would you need to authenticate it? Its L2 vs. L3 difference. Jari Arkko - Not sure if that answer clarifies it sufficiently. What's special with the number 2. Why not 15? You can run multiple services over the Internet, you could even have multiple types of mobility services if we are not talking about application services... Question - If you do access authentication, do you have IP address? No. Discussion about the seperation between device and user authentication. It is possible that different credentials are used for the two authentications. Discussion about sequential vs. parallel authentication and when either one could be done. Bernard Aboba - Is there a separate link between the MN and access/service authenticators? There's just one link. So there is no possibility to multiplex different links etc? No. Question - Can you explain the business model, why would anyone buy access from someone and service from someone else -- but I confess I come from the enterprise space. MVNO is cited as the prime real-life example. Jari Arkko - I'm willing to entertain the idea that someone needs two authentications. But there's different ways of doing it. You could design your link layer so that you can do this. I'm less comfortable with changing EAP or inserting layers to do this just to shoehorn two EAPs where one EAP fits. If you want to do things like authentication for mobility service, you could use IP protocols to accomplish what you need, e.g., IKEv2 EAP. Better idea than trying trying to design a new layer. Authors respond that they would have to do it in multiple link layers, so that's why they come to the IETF. Question - what is the significance of colocating the authenticators? In the simple case there is one authenticator and two authentication servers. Then you need GEE to separate which protocol run you are using. But if you have two authenticators, then you have a more complicated picture. Discussion about whether its possible that there's one authentication server which serves two authentications for the same user for different "layers". Yoshihiro Ohba - Problem should be solved by the layer under EAP. PANA for instance allows two independent EAP authentications to be done. Discussion about whether the proposal is 2, 3 or 4 party protocol. Disagreement. Yoshihiro thinks that adding additional parties would make EAP architecture even more complicated. John Vollbrecht - I do not understand if the two authentications are needed to get access or if one authentication provides you something and the other something else. The answer is that both are needed. John notes that then its a sequence of EAP methods, at least in the logical sense, if not in the timing-sense. Then there is no reason why you couldn't have four or five methods. Why? I don't know - but why run two... Meeting run out of time and no further questions could be answered. 5. AOB 6. Meeting adjourned.