Last Modified: 2003-10-24
1. IANA considerations for EAP. 2. Type space extension to support an expanded Type space. 3. EAP usage model. 4. Threat model and security requirements. 5. EAP state machine. 6. Documentation of interaction between EAP and other layers. 7. Resolution of interoperability issues. 8. EAP keying problem description and requirements.
Items 1-7 are intended to be covered within RFC 2284bis, the revision to the EAP specification. Item 8 will be covered within a separate document
The EAP WG is not currently chartered to review or standardize EAP methods. However, when these work items are completed, the WG may be rechartered, or a new WG may be formed to evaluate proposed methods.
Jun 03 | EAP Keying Problem document submitted for publication as an Informational RFC | |
Done | RFC 2284bis submitted for publication as a Proposed Standard |
Minutes of the Extensible Authentication Protocol (eap) WG at IETF-58 Time: Monday, November 10, 2003 at 1930-2200 Chairs: Bernard Aboba <aboba@internaut.com> Jari Arkko <Jari.Arkko@ericsson.com> Minutes: Dirk Kroeselberg (Dirk.kroeselberg@web.de) Henrik Levkowetz (henrik@levkowetz.com) Edited by Jari Arkko (jarkko@piuha.net) URLs: Issue Status: http://www.drizzle.com/~aboba/EAP/eapissues.html Presentations: http://www.drizzle.com/~aboba/IETF58/EAP.zip Preliminaries ============= - Agenda Bashing. No comments on the agenda. - Bluesheets going around and note takers assigned. - Document Status. Jari summarized the document status: o EAP base spec passed WG last call, is in IETF last call. o EAP state machine (informational) is in WG last call. o EAP keying framework has been adopted as WG document. There is still a number of open issues, needs more work than the other docs. o EAP over Radius (2289bis) approved, now RFC 3579. o Method documents: Approval of methods needs to wait for completion of base EAP specifications. Currently not in EAP WG charter to work on methods. Future methods might be specified either as individual submissions, Informational documents outside the WG or as chartered EAP WG work WG Work Items -- RFC 2284bis, Henrik Levkowetz ============================================== - http://www.levkowetz.com/pub/ietf/draft s/eap/rfc2284bis/draf t-ietf-eap-rfc2284bis-07.d.html - 3rd last call on the document was held in September. There are two open issues left: 1) Handling of Identity response 2) Editorial comments by J. Puthenkulam Margaret missed her editorial comments among the open issues, but these were already fixed. No other questions. WG Work Items -- EAP State Machine, Pasi Eronen =============================================== - http://www.ietf.org/internet-drafts/dra ft-ietf-eap-statemachine-01.pdf - http://www.ietf.org/internet-drafts/dra ft-ietf-eap-statemachine-01.txt - Now in WG last call. Next steps: Handle issues from last call, and publish as informational. - Draft describes state machine for EAP peer and EAP authenticator. No changes on peer side since IETF-57. - The approach for the authenticator now is changed, due to comments on AAA interaction: three state machines: o Standalone (no pass-through or AAA) o Backend (Interfaces to AAA module (RFC3579, Diameter), EAP methods). o Full authenticator (Interfaces to lower layer (matching 802.1X-REV), EAP methods, AAA module) - Discussion: o Bernard: What is the difference for handling tunneled methods (tunneled variable)? Pasi Eronen: If you are not inside the tunnel, you are not allowed to do multiple authentication methods. Complicated, tunneled-variable will be taken out. Joe: Makes me somewhat nervous to have that in there. Bernard: For now, should be in there to stimulate discussion. o I'd also like to say that the quality is very good, and thank the authors, and tell people to set aside 4+4 hours and go and read it. WG Work Items -- EAP Key Framework, Bernard Aboba ================================================= - http://www.ietf.org/internet-drafts/dra ft-ietf-eap-keying-01.txt - Normative statements relating to EAP moved to RFC2284bis. As a result, EAP methods no longer depend on keying framework. Substantial revisions are in progress, currently the draft lacks a threat model. - Open issues: o 15 (key distr. Insecure), o 179 (EAP PRF), and o 187 (Service SAs). - Security issues are: o Key scoping: AAA protocols authenticate at NAS granularity Client may not be able to recognize NAS scope without assistance from the lower layer. Possible solutions: . AAA agent checks . Logging . Key Mixing . Method-specific binding o Correctness in fast handoff & context transfer o Lying NAS Problem - There were no questions. Related Work -- Network Discovery and Selection, Farid Adrangi & Pasi Eronen ======================================== ==================================== - http://www.ietf.org/internet-drafts/dra ft-adrangi-eap-networ k-discovery-and-selection-00.txt - Discussion scoping by Jari: there's been previous question marks on whether this functionality is needed. Since feedback is required from other organizations, and we don't have much time for discussion in the meeting, we will assume that network selection is needed. Lets use the meeting time to discuss what alternatives we have for providing this feature. - Problem: Even if you select an AP (based on e.g. SSID) you haven't selected a mediating network which will carry your traffic back to your home network - Farid presented examples of mediating networks, such as iPass, 3GPP-VPLMN, GRIC. Home service network is e.g. wireless provider. Access networks are public hotspot. Problem is not AP selection in hotspot. EAP-based client needs information on which home network /mediating networks are affiliated to the access network. The proposed solution complies with the EAP spec and uses EAP-Identity Requests to deliver network information. - Proposed solution is to use a "decorated NAI" inside the Identity Response, on first or subsequent Identity Request. Identity Request may carry information about the network which makes it possible for the peer to select an appropriate NAI (if more than one is available). - There is a 3GPP dependency for this work (3GPP TSG CN). - Related presentation by Pasi Eronen: Based on a discussion between Jari, Bernard, Pasi. o But other solutions are possible, e.g. SSID-based. o Suffix routing on a NAI is better than prefix routing. o If an eap-layer based solution is used, EAP identity request hints are probably OK. o The network cannot always ( and maybe should not ) do the selection. So information has to be provided to the users. o If you try to encode the mediary network information into virtual AP's ssid's, the amount of beacons needed might end up consuming a significant part of the bandwidth. o On the other hand, if you have to associate with each of a large number of APs, and start a EAP exchange with each in order to get the information about - Discussion: Margaret Wasserman: Are there lessons to learn from loose source routing? Can we become victims of single points of failure? Pete: Seems we are limiting us to a solution which doesn't scale very well. And I'm not sure we should be doing this at all. Bernard: Today we have internet connectivity and DNS-based routing. This was not possible with RADIUS. Why are we doing this? It looks like there is no layer-2 alternative that can handle all cases. Margaret: Assume I can choose based on some string between mediating networks. Does not seem to be right as there should be some policy. Do we gain something over the existing solutions today? Farid: These policies can be pushed to the subsciber device from the home network Farooq: It's the home network which has to settle the roaming cost. Farid: Some users may care about QoS, some about cost. Policy can be pushed by the user's home network. Margaret: There are other WGs that investigated the concept, should be looked at as well. Bernard Aboba: Take it to the list. Jari: We have a cost factor in selecting the right network. End users care about the cost. - Strawpoll: Should this be solved in the IETF? Consensus that the problem is worth solving. Should the EAP WG solve the problem? Consensus that it should be solved in WG, but less strong than for the first question. - Comment by Pasi: There are solutions that do not involve EAP at all. But EAP WG could be a good place to explore this. Related Work -- EAP Key Derivation for Multiple Applications, Joe Salowey ======================================== ================================= - http://www.ietf.org/internet-drafts/dra ft-salowey-eap-key-deriv-02.txt - Changed the draft name to "EMSK usage guidelines" - 2284bis defines the EMSK. Several applications have been suggested that use the EMSK (eap-keying, aaaarch-handoff, eap-protectedtlv) The current proposal should either be incorporated into key framework draft, or the keying framework should reference it. - Jari: May be a separate specification as well. Joe: Key framework itself references EMSK. So either take that out, or reference it. Russ: Its just two pages, merge it in. Jari: Ok Related Work - The Compound Binding Problem, Farid Adrangi (on behalf of Jose Puthenkulam) ======================================== ==================== ============================== - http://www.ietf.org/internet-drafts/dra ft-puthenkulam-eap-binding-04.txt - Status update for 04 version of the draft: mostly editorial improvements. Three issues (64, 191, 192) are still open. Some crypto experts have reviewed the draft, no issues so far. Timeline is to resolve open issues this year. Revise section 4, synchronize with keying framework. Submit for final review in January, close in February 04. - Issue: The EMSK may not be the best thing to use for the compound bindings. We need to look a this - Bernard: We started looking at this because many other groups needed something like this. Now IKEv2 is doing something similar, and .... is doing something similar. Right now it seems like the IETF is going violently in different directions and we get incompatibilities. An there may be different views of whether there is a problem. - Russ Housley: True, need solution, proposal to formulate this in a few slides for broader presentation in SAAG. Farid: his has already been done in former IETFs. Bernard: We got no input then. EAP methods - EAP SIM/AKA, Pasi Eronen ====================================== - http://www.ietf.org/internet-drafts/dra ft-haverinen-pppext-eap-sim-12.txt - http://www.ietf.org/internet-drafts/dra ft-arkko-pppext-eap-aka-11.txt - No open issues with the drafts. It is part of 3GPP Release 6 WLAN inter-working. EAP/SIM products are available, deployment is beginning. Plan is to do individual submissions as informational, once EAP base docs finalized. No implications to 2284bis, state machine or keying framework. EAP Methods -- PEAPv2, Jose Salowey =================================== - http://www.ietf.org/internet-drafts/dra ft-josefsson-pppext-eap-tls-eap-07.txt - Recently submitted draft -07. Features are complete. Added support for sequences of EAP methods. Supports inner method binding. Goal is to submit as informational. Currently WG item not requested. - Margaret: All drafts are planned to be published as informational. I wonder about this. Bernard: It took so long to get this WG started that much work was already more or less done, and it may be hard for people to give up change control now, and make these WG documents. Pasi: Correct with respect to EAP/SIM and EAP/AKA EAP METHODS - EAP-IKEv2, Dirk Kroeselberg ========================================= - http://www.ietf.org/internet-drafts/dra ft-tschofenig-eap-ikev2-02.txt - A number of issues have been improved in the update, e.g. error handling, fragmentation. There are still open issues like optimizing the no. of messages, security claims section. Another update planned before next IETF to address these issues. - Michael Richardson: Tunneling seems to be complicated, suggestion remove support of tunneled methods or to detail use case. Dirk: True, but applies to all tunneled methods. Is only an optional feature in IKEv2. - Bernard: Is it intended to handle address assignment in EAP-IKEv2, do we need that? Bernard: Are all identity payloads needed? Is IKEv2 a limitation in terms of identity payloads? Dirk: Need to check this. EAP Methods - EAP Smartcard, Pascal Urien ========================================= - http://www.ietf.org/internet-drafts/dra ft-urien-eap-smartcard-03.txt - Goal of the proposal is to support EAP in smartcards. No discussion. Roadmap discussion (10 minutes), WG Chairs and ADs ================================================== - Steven Hayes: (clarifying 3GPP position) 3GPP requires the two methods discussed, and network selection. Otherwise there are no further requirements on EAP. Request to publish EAP-SIM and EAP-AKA as informational. - Someone: Are the available methods sufficient to progress the documents to Draft Standard? Margaret: Good point. Especially for the keying framework, a method that uses all the features is required. Bernard: There is no standard method required for this, just the use of the features with any method. Russ: Requirement is two independent interoperable methods. Bernard: You can show interoperability without having particular methods showing them Margaret: Are all the methods done informational forever? So what does the EAP WG do - wait till somebody comes along with a method to be standardized? Bernard: There is one standardized mandatory method Russ: But that one doesn't exercise all features. Bernard: Somebody has to ask for a standardization effort. Margaret: There is no interoperability without using informational RFCs. Bernard: The same issue (mandate one method) has been brought to the group by 802.11. Pasi: Could update EAP-TLS as this is the only key-generating RFC method. Current status is experimental, however. Jari: Some defined methods should be standardized in their second revision, e.g. EAP-TLS. Margaret: We don't have the rule that because something has been deployed, it can't be a standards track document! Donald: It almost seems like everything developed outside never is to become IETF standards. We have some examples where v2 of some documents have become - after rework - standards track documents. Margaret: How will expert review differ from the expert review done for standards track documents. Bernard: The intention is to basically raise the bar for new methods, as many have already been allocated, but about 70 percent do not have a useful documentation (expert review is defined in 2284bis). Bernard: If you already have a type code, it's not even sure that the need for expert review will get triggered. Even if you have a code allocated, that's not a guarantee that the RFC editor would publish a document, he could decide this is awful. (Editor's note: Margaret later sent this e-mail to the list: "Apparently, I said something at the EAP meeting in Minneapolis that has caused some confusion about the IANA allocation of EAP codepoints. Just to erase any confusion, I want to make it clear that I support the current wording in the EAP draft -- that EAP codepoints should be allocated on the basis of expert review. This represents an increase in scrutiny from the current policy (first- come- first- served), which I think is appropriate. I do not believe that EAP codepoints should require an IETF standard, and I do believe that it would be appropriate to allocate EAP codepoints in some situations (vendor-specific or environment-specific) where it wouldn't make sense to produce an IETF standard. I do hope that the WG will consider standardizing secure, eneral purpose EAP methods in the future, but I do not believe that we should require a standards-track document in order to obtain a codepoint.") Chris Elliot: I'd really like to se you take on methods work. Meeting adjourned. |