Last Modified: 2004-02-06
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 |
.Extensible Authentication Protocol WG (eap) THURSDAY, March 4 at 1300-1500 CHAIRS: Bernard Aboba <aboba@internaut.com> Jari Arkko <Jari.Arkko@ericsson.com> SCRIBES: Dirk Kroeselberg Henrik Levkowetz No changes to agenda. 1. Status update (Jari) - 2284bis has been approved as an RFC, IANA process will take some time... - The state machine -02 draft is currently in 2nd WG last call. Read the document and send comments. - The keying framework has not been updated since last IETF. Still has open issues. Current plan is to finish this in September 04. For this to go forward needs participation and input from the workgroup - Draft-ietf-eap-netsel-problem-00.txt on network selection has been submitted as input to 3GPP, IEEE, some feedback is available. - Binding problem definition: no update available. - EAP-over Radius approved as RFC3579; EAP-Diameter is in AAA WG LC. - EAP over diameter in aaa wg last call, read and comment - A NAI (RFC2486bis) update is available in draft-arkko-roamops-rfc2486bis-00.txt. - Methods can be submitted - Lot of recent method activity. - Since 2284bis was approved, expert review for IANA method allocation is necessary. No comments on Jari's status update. 2. EAP State machine (Pasi Eronen) Drafts: - http://www.ietf.org/internet-drafts/dr aft-ietf-eap-statemachine-02.pdf Issues: - http://www.drizzle.com/~aboba/EAP/eapissues.html A number of issues were found during 1st WGLC. The authors hope to have addressed them all. Issue owners are requested to check whether the issues are properly addressed in the draft. The document does not address tunneled methods any more. Issues: - Peer-to-peer operation: The authors believe no changes are necessary, considering IEEE. - RFC editor issue: State diagrams will be provided in ASCII. 3. Keying framework issues (Pasi): Drafts: - http://www.ietf.org/internet-drafts/dr aft-ietf-eap-keying-01.txt - http://ietf.levkowetz.com/drafts/eap/keying/ Issues: - http://www.drizzle.com/~aboba/EAP/eapissues.html Presented by Pasi, since Bernard was not present. There was no update since IETF-58. A new version is in preparation. There are certain open issues: - AAA-Key vs. MSK: In normal 802.11i, AAA-Key=MSK. This may be different for lying-NAS. The lying-NAS problem, however, can be solved by providing "channel bindings" in EAP methods rather than specifying AAA-Key=PRF(...). Solving the lying-NAS is not considered urgent. The new draft will discuss channel binding issues. Alper Yegin: Are there general guidelines for when to set AAA-Key to MSK? Pasi: proposal is to set AAA-Key=MSK in general. Jari: This implies the MSK is reserved as AAA key only. If something else is to be done, e.g. for fast handoff, use EMSK. - Issue 221: EMSK: draft-salowey-eap-key-deriv-02 will be included in the keying framework. This will mandate a prf: IKEv2 prf+ with HMAC-SHA-1. Florent: Why do we have to specify how to derive keys, instead of specifying that they have to be cryptographically independent? Pasi: If you use 2 different PRFs there is no guarantee that they are cryptographically independent, so we need to specify this. Jari: Does it have to be the same PRF for all keys for one session, or for all sessions? Pasi: All sessions Jari: If this is done in the method, the method can still negotiate other prfs. Simon(?): We don't need a prf here. Why is the HMAC used. Pasi: This is the way it is typically done. Do not want to invent anything new. 4. Binding problem update, Farid Adrangi, (5 min) Drafts: - http://www.ietf.org/internet-drafts/dr aft-puthenkulam-eap-binding-04.txt Issues: - http://www.drizzle.com/~aboba/EAP/eapissues.html Version 4 of the draft is available for review. Version 5 is currently being worked on for next IETF. Update plan is to synchronize the draft with keying framework. The authors want to verify if this understanding is correct: - Compound binding MAC key - EMSK - Compound session key - MSK (please comment) Jari: Are people referring to this draft when developing new methods? Have people checked whether the solutions e.g. of IKEv2 or PEAPv2 conform to the draft? Otherwise it may not have much relevance. Glenn: Does the draft solve any problem at all? In fact there is no MITM attack. It is a combination of other attacks where the draft does not help. The draft only solves a small subset that can easily be bypassed. If an evil access point negotiates plaintext passwords, any keys can be derived. If you cannot negotiate down from PEAP, there is no MitM attack. The draft's assumptions are ill-specified. Jari: Can't say that I agree, have to think about it. Needs to be discussed, please post to the list Glenn: Done, stunning silence. Jari: Document useless? Glenn: No, it points out valid things for tunneled methods, but it does not solve the problem it poses. Jari: Please comment on the list 5. Network selection, Farid Adrangi, Jari Arkko (25 min) Drafts: - http://www.ietf.org/internet-drafts/dr aft-ietf-eap-netsel-problem-00.txt - http://www.ietf.org/internet-drafts/dr aft-adrangi-eap-netwo rk-discovery-and-selection-01.txt - http://www.ietf.org/internet-drafts/dr aft-arkko-roamops-rfc2486bis-00.txt Presentation by Jari/Farid: Network selection comes with multiple problems: 1. Access network discovery 2. Identifier selection 3. Selection of roaming intermediaries 4. Payload routing Activities to perform are - Discovery - Decision - Indicating the selected network Recommendations * All 4 problems are relevant * Potential need for new solutions These problems are _really_ _really_ hard if * there are a lot of networks * you want to do it securely * there are many different ways to do this Given that the problem _is_ hard, it may be that we can't solve it all now. 3GPP and 802.11 were requested to provide feedback: 3GPP SA2 WLAN group: - problems 1 and 3 are relevant to 3gpp, but not the others. - 3gpp uses existing l2 mechanisms for problem 1 - they expect an IETF solution to problem 3 for Release 6 (pretty soon) IEEE 802.11 meeting summary - alternatives are relevant for one of their study groups - they don't know what kind of solutions they need now - other groups also working on related problems * Solution space - Believe there is interest in problems 1 and 3 - Pretty clear problem 1 belongs to link layer - Problem 3 belongs at least in part in IETF. There may be mechanisms at lower layers that effectively advertise relevant information also for higher levels than L2 - If there's an IETF intermediary solution, it will probably be relatively short-term - We already today have configured databases on the client, and advertised information; must be able to switch to other source. - NAIs discussed in roamops draft Osok: SA2 ready to use EAP based solutions not only for problem 3 but also for problem 1. Agreed that ESSID cannot always be used to select access point. Farid: Problems 1 and 3 may be intertwined, may need to do 1 based on result of 3 Osok: Cannot use ESSID only, also in situations where we don't want David Johnston (Chair of 802.21 group): There are ways of doing link layer discovery and maybe better ways upcoming. 802.21 is talking about providing media-independent link-layer discovery. EAP may be viable for the near-term, but the critical part is the information in the discovery. This information needs to map into a wider information model used by 3GPP, IEEE, etc. Glenn: The only reason this needs to be in EAP is that - We're selecting from private networks here - commercial or not - and have to select the path of the aaa packets because providers won't carry other people's aaa packets. Serge Manning: Don't know if EAP solutions are the best, but even if .21 comes up with something, we'll have to be able to work with existing .11 APs Pasi: Why is aaa routing difficult - all AccessAccept packets forwarded indicates willingness to carry the traffic of somebody, and may result in monetary pain if you do it without getting paid Glenn: Forwarding of aaa packet is an implied contract? The routing of aaa packets? How can that be?? That's crazy! Pasi: The AAA signaling is about accepting responsibility to cover costs. The operators want to be in control. Glenn: Have to pick what network to carry your traffic, that's ok. And you have to have an agreement between providers. But just_forwarding_ the aaa packets, to set up the correct route for traffic should not be a problem. Jari: Two problems, finding an access network and selecting who is to carry the traffic. Glenn: The first part I understand, but not why the rest of the stuff has to be done in EAP. Farid: Selecting mediating networks is required by 3GPP, operators etc. Jari: Discuss this offline. Someone: Are there plans to have PP2 review this as well? They do not have problem 3, but the others. Jari: I have received unofficial indications that they are fine with what IEEE does. Farid's presentation on 3GPP approach: EAP-based mediating network selection Use case 1: WLAN client moves into a hotspot advertising the clients HSN SSID. Use case 2 : WLAN client moves into hotspot advertising one or more of WLAN clients HSN roaming partner SSIDs but not its HSN SSID. Use case 3: WLAN client moves into a hotspot advertising only unrecognized SSIDs (continued). Different agreements between hotspots, mediating networks and HSN are in place. How to find the best path? (e.g. unrecognized SSID belongs to a HSN that has a roaming agreement with a specific mediating network only. The hotspot could have an agreement with one HSN only) Alper: Can there be more than one mediating network in the path? Farid: 3GPP only considers one level of indirection. Lauri: Is there any implicit assumption that client will have to know paths through the net? Farid: No, looks up each intermediary network discovered in an preconfigured database. Problem scope: Access network selection, mediating network selection. Presentation solution overview for each scenario. Solution proposed: - complies with 2284bis, uses 2486bis bang syntax - may not require any changes to access points - uses EAP Identity Rewquest to deliver identities from the local aaa server Jari's presentation on next steps for network selection: - need to ask IEEE 802 whether discovery part of problem 3 is being considered, and when results would be available. - need a clear problem definition as input for the groups working on the long-term L2 solutions. - need to decide how to accommodate the selection of roaming intermediaries; bang syntax? - next steps for the NAIbis update are currently being discussed with ADs - this will not be part of the EAP WG - need to decide how roaming discovery is performed - wait for final l2 solution - short-term solution now until L2 solution arrives Comment by 802.21 chair: Both solutions are appropriate. Jari: What to do: - We could turn this entirely over to future Layer 2 mechanisms - We could handle this within EAP, according to Farid's draft or similar - We could leave this up to individual vendors and proprietary solutions - We could decide to do nothing. L2 is the best scheme efficiency-wise. Needs at least a firmware upgrade. Farid's draft: no AP upgrades if done from AAA proxy. Fast to specify. Not very clean way, but only short-term solution. Vendor-specific: Might get many, even from SDOs. Alper: Why does the first option pass information between EAP and L2? Jari: If the lower layer discovers something, it is passed up? Alper: Could use PANA to do discovery at lower level.. Glenn: If these are private networks, they can do it on their own, without any standard. Goes back to the point: Who cares if there are many? Farid: Many solutions create market fragmentation Jari: France telecom may have their own scheme, but they won't have their own Windows or their own phone. Glenn: Informational is not enough, Standard is going to be required to make vendors pick it up. Jari: There are tradeoffs with the vendor-specific thing Steven Hayes (3G-IETF coordinator): 3GPP timeframe needs clear indication where IETF wants to go on this problem. Stage3 work needs to be done in about 6 Months. Better for the market not to have a "vendor" solution. Yoshi Ohba: Don't prefer any particular solution, but needs to consider threats. Farid's proposal has weaknesses. Jari: AAA works within the constraints of the contracts in place. So security problems in network are limited. Cisco guy (speaking as 3GPP2 member): Question to Steve (3G), whether there is any preference. Steven: 3GPP preference is to progress Farid's draft which is the quickest solution. Strawpoll: - Option 1: ~3 - Option 2: ~11 - Option 3: ~2 - Option 4: ~1 Alper: If we go for option 2, will we still come up with recommendations for L2 designers? Jari: Yes, that is an issue, but session needs to move on. Steven: What is the time plan? Jari: We have consensus here on working on this, but we need to ask the same question on the mailing list. 6. Methods update, Jari Arkko (15 min) Current state: - only 4 methods in RFC - There are lots of methods in Internet drafts, lots of old/expired ones, or even undocumented methods (almost the majority). Conclusion: This is not good. - Many methods have a similar intent like tunneling methods. - There were many requests to IANA before 2284bis was approved. - Now after 2284 bis approval, you either use the vendor-specific method way defined there, or you do a draft and get expert review. 7. New method presentations: EAP Bluetooth (Hamsang Kim, INRIA): - Scenario is a Bluetooth zone, e.g. in a Wi-Fi network. Infrastructure-based methods (EAP/AAA) are considered useful here. Scenario includes wireless station (STA), AP, AS. - Objective is to support Bluetooth security. - Approach is EAP over EAP. Relies on generic EAP protocols (e.g. EAP-TLS). - Additional backend exchanges are required, and still need to be defined. Draft has been sent to Bluetooth SDO for comments. - Comments on the EAP list are solicited. Jari: Send comments to the list, as we are running out of time. EAP-PSK (Florent Bersani): - Defines a simple symmetric-key EAP method - Uses AES-128 as its sole primitive. - It is designed with WLAN in mind. - It is currently being implemented, sources will be made available. - Should be mature at next IETF. According to the presenter the method is IPR-free. 8. 802.11 requirements, Jari: - We have request from IEEE to publish EAP method requirements (draft-jwalker-...). This is currently in IESG last call. Please review and send comments to the list. Question: How can we move forward to have a method standardized Jari: This needs to be discussed with the ADs. 9. Pasi (IKEv2 and EAP): Draft with Hannes Tschofenig. IKEv2 supports EAP authentication. It has specific requirements to EAP methods. The draft explores how to skip public-key signatures (that is mandated in IKEv2 for the responder-side) for strong EAP methods. This avoids unnecessary PKIs. An example method is EAP-AKA. First draft explores various alternatives how to implement this in IKEv2. Comments are welcome. Question: How to take this forward? Is the EAP WG the right place? Pasi: IPsec does not take new work items. So possibly an individual submission? Jari: Talk to the security ADs Steve Bellovin: Be cautions about modifications to IKEv2. Extensions are ok, but do not modify. Pasi: The proposal has an option to avoid such changes. Someone: Is there any overhead for EAP mutual auth.? Pasi: No, the overhead is actually the IKEv2 server authentication. Darryl Piper: Is there a requirements document associated with this? As an IKEv2 person I'm a bit curious about the motivation for this draft. Don't see a point of forking off an EAP investigation on adding authentication to IKEv2, we have enough problem with getting the 5 or so we have to work together. Pasi: It seems the motivation is that this IKEv2 feature is not only used for legacy-EAP. Darryl: There should be a requirements doc. Jari: As the draft is short, it does not make sense to have a separate requirements document. Work is grown out of discussion in IPsec mailing list. It is motivated by 3GPP work, as there mutually authenticating EAP methods are already in place. 10. Further announcements: 802.1X/EAP ad-hoc interop test (Karen O'Donoghue). - Planned April 4-7, 2004 in Las Vegas. - Follow-on to similar event last year. Announcement on Free Radius (Michael Haberler): - EAP-SIM implementation status (Internet foundation Austria) - Available as module of freeradius in the CVS tree on www.freeradius.org - Done by Michael Richardson. Part of openlx project. - EAP-SIM supplicant: online on www.open1x.org - Some interop tests done with Cisco, Nokia and others. In the pipe: Cisco windows dll. - Next step is to integrate (U)SIM cards, implement EAP-AKA. Implement RFC3310 http/digest, www.iptel.org 11. Meeting |