Last Modified: 2003-01-22
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.
| DEC 02 | RFC 2284bis submitted for publication as a Proposed Standard | |
| JUN 03 | EAP Keying Problem document submitted for publication as an Informational RFC |
Minutes from the IETF-56 Extensible Authentication Protocol WG (eap) meeting CHAIRS: Bernard Aboba <aboba@internaut.com> Jari Arkko <jarkko@piuha.net> MAILING LIST: Address: eap@frascone.com To subscribe: eap-request@frascone.com, with "subscribe" in Subject line. PRESENTATIONS: http://www.drizzle.com/~aboba/IETF56/EAP MINUTES: Henrik Levkowetz, Paul Funk, Bob Moskowitz (edited by Jari Arkko and Bernard Aboba) SESSION 1: Monday, March 17 at 1530-1730 1. Preliminaries (10 minutes) - Bluesheets - Minute Takers - Agenda Bashing Jari summarized the agenda for today and thursday, and asked for comments - none. 2. Networld+Interop (Karen O'Donoghue) N+I (in three short weeks) will have a 802.1x demo and a 3-day interoperability test session for EAP methods. Methods to be tested include EAP-TLS, EAP-TTLS, and EAP-PEAP, as well as a variety of inner methods. Please come, and bring your EAP method (better tell her first, though). 3. IEEE 802.11 Request (Dorothy Stanley) Dorothy represents the IEEE 802.11 group and is responsible for liaison with the IETF. The IEEE, as a user of IETF protocols, in particular EAP and RADIUS, has formally requested guidance in selection of EAP methods to meet their security goals, in the following categories: methods of authentication via certificate, user-password and GSM/UMTS secrets; key strength and key material (128 bit effective key strength needed); mutual authentication; resistance to dictionary attack; thwarting of MitM attack; replacement for EAP-MD5-Challenge (which is subject to MitM attack). The letter is available at http://www.drizzle.com/~aboba/IETF56/EA P/11-03-243r2-I-Input -to-IETF-EAP-WG-March-2003.doc In addition to the 802.11i work, 802.11f is working on inter-access-point protocols, which will utilize RADIUS. There are issues related to this, as it is necessary to add new Service-Type values and possibly change the behaviour of certain parts of RADIUS. Dorothy presented the IEEE 802 response to IETF issues, which is available here: http://www.drizzle.com/~aboba/IETF56/EA P/11-03-264r0-W-IETF_Liaison_Report_March_2003.ppt 4. Document status Jari summarized the document status: - 2284bis - a lot of issues handled, plan a WG last call when all issues closed. Pointed out that the background for 2284bis is unclear parts of 2284, and having interoperability problems. The goal for 2284bis is to clarify unclear points and ensure interoperability, and *not* add new features. - There's documents for EAP state machine, keying framework, and others. Mentioned the requirements for adopting new documents as working group items. Drafts adopted as working group items must have a level of maturity; there should have been significant review already performed and all major issues should already have been resolved. Bernard added timeframe: June for Keying document. Things may be dropped rather than let them slide. 5. RFC 2284bis, Henrik Levkowetz and Jari Arkko http://www.ietf.org/internet-drafts/dra ft-ietf-eap-rfc2284bis-01.txt Three major outstanding issues were presented, and a vigorous discussion ensued. Issue 80 - Is EAP-Success required? - There was some discussion of whether the new draft should allow the client to acknowledge success, whether particular EAP types should provide alternative means to acknowledge success, whether all methods that don't perform mutual authentication should be abolished. - Henrik made clear that this issue does not pertain to the authenticator, which always must issue Success if the authentication was successful. However, there are several choices for client behavior: (a) Client does not require Success. (b) Client requires Success, or it must refuse to proceed with connection. (c) Client normally requires Success, but if there is an alternative indication that implies Success client may proceed with connection. - Hum results: (a) inaudible (b) -70 dB (c) -43 dB Loudest: (c) Issue 97 - May packets of another type interrupt an authentication sequence (strict mode) - Some confusion was expressed by commentators as to whether this relates to serial authentications or interruptions of a sequence which may not have completed (e.g. DoS). Also the question was brought up as to whether the authenticator should be allowed to switch to a different method before the first completed; for example, if the authenticator determines that the original method cannot complete and wishes to try an alternative without failing the user. - In the interest of assessing how this decision would affect existing deployments, various implementors rose to describe how badly their code would react to receiving packets of unexpected type, though nobody actually shared source code. Most implementers currently silently discard packets of unexpected type. - Choices were: (a) Yes, they may (no strict mode). (b) No, and this is enforced by the state machine discarding packets of unexpected type (strict mode). (c) Not really, but this is enforced by state machine in consultation with currently running type, so exceptions may be made (limited strict mode). - Hum results: (a) -10 dB (disqualified because it originated from a single point source) (b) -50 dB (c) -49 dB Loudest: (c) Issue 87 - Type change during method - This issue was admittedly closely related to the previous (97). The issue pertains both to the authenticator switching to a new type before the first is complete and starting a new type after the first is complete (serial authentication). - Jesse Walker pointed out a use case for serial authentication that someone may actually want to do: authenticating first the machine, and then the user of the machine. - John Vollbrecht argued that a type change in the middle of a sequence can be distinguished by the client from serial authentication after the first type is complete, and therefore type change should not be outlawed. He also felt that behavior in this regard is a security choice, but should not constrain the protocol. - There was discussion as to whether the client can know that a method has completed. For example, it will know when it has successfully authenticated the server, but may not know whether the server has completed its authentication of the client. - Bernard Aboba felt that allowing type change would pose a challenge to existing implementations. Also, sentiments were expressed that serial authentication would pose problems to the state machine. Jose Puthenkulam argued that the key binding problem, absent a single EAP method that embraces the serial methods, is an open-ended one whose solution is not yet known. - The choices were how strongly to discourage type change: (a) The authenticator SHOULD NOT perform a type change. (b) The authenticator MUST NOT perform a type change. - Hum results: (a) -60 dB (b) -47 dB Loudest: (b) But with the following provision: There may be only a single outer EAP type. However, that type itself may tunnel EAP types, of which there may be multiple. That is, sequences outside tunnels are a MUST NOT. The outer protocol is responsible for defining how that is done and how the results of the inner types are combined to produce a unified session key. 6. EAP Support in Smartcards, Pascal Urien, 5 minutes http://www.ietf.org/internet-drafts/dra ft-urien-eap-smartcard-01.txt Presentation from Pascal about the capabilities of smartcards and the interface to EAP proposed for smartcards. Pascal described an API that would allow EAP to be embedded in a SmartCard. The SmartCard would receive EAP packets from and send them to the network, and perform all cryptographic processing internally as a closed system. A management interface would allow client software to provision the SmartCard with identities, policies, etc. Such a SmartCard could handle protocols such as EAP-SIM, EAP-TLS, etc. No questions 7. Compound Binding, Jose Puthekulam, 10 minutes http://www.ietf.org/internet-drafts/dra ft-puthenkulam-eap-binding-02.txt Presentation from Jose on compound methods. Turns out that there are man-in-the-middle attacks possible on tunnelled compound methods. Compound tunnelled methods may be used in order to - Secure legacy methods in new environments - Ease of deployment for securing legacy methods - Providing consistent security properties and other features for different methods - Securing multiple credentials in sequences. Non-tunnelled compound sequences are also vulnerable but not addressed by this draft. If such sequences were used somewhere, a compound key derivation would have to be designed for them as well. Requirements for the attack: - The MITM is able to run dual roles - rogue authenticator and rogue supplicant - Creds and method re-used with and without tunnel - Tunnel is one-way server authenticed - Use of tunnel session keys alone and no inner method session keys Yoshi: I believe that #3 is not necessary - it's possible also for mutually authenticated tunnells. Jose: Yes, but that's a *trusted* MitM - in which case all bets are off. Jose then laid out a general framework for providing solutions to the problem. Some of the solutions are policy-based (e.g. don't do that); others are cryptographic. Possible solutions: - for non-key deriving methods * Use of separate credentials inside and outside tunnels breaks the attack. * Always use methods inside tunnels?? - for key-deriving methods * Use cryptogrphic bindings: + Compound Keyed MACs + Compound Session keys The attack may be foiled either at the point of authentication or at the point of use. That is, there may be an additional authentication step to assure both parties of the absence of an MitM, or the validity of session keys generated for the connection may be made to depend on absence of MitM. Jose favors the former, as it nips the problem in the bud and precludes a connection from even being set up. Allowing the connection to be set up (only to fail to operate) is expensive and therefore encourages DoS attacks. Jose presented the notion of a "binding phase", which uses single round-trip cryptographic algorithm to perform the compound authentication at the conclusion of the EAP sequence. Bernard asked (a) which PRF is used in the binding phase, and (b) whether this is compatible with IKE v2. Jose replied that (a) each tunneling protocol selects its PRF, and (b) each tunneling protocol defines and exports its own session keys, so the tunneling protocol is independent of the context in which it is carried and is therefore compatible with IKE v2. SESSION 2: Thursday, March 17 at 1530-1730 8. RFC 2869bis, Bernard Aboba, 10 minutes http://www.ietf.org/internet-drafts/dra ft-aboba-radius-rfc2869bis-09.txt Bernard summarised the status of RFC2869bis, there's one open issue currently, issue 83. Here an AAA server can receive an invalid EAP packet from an authenticator in passtrough mode. The message cannot be just dropped, as the authenticator will retransmit the AAA request. Details of the proposed resolutions are the slides. A lot of little nits have been fixed. A solution for "the lying NAS problem" was described in the slides (RFC2869bis). The solution is to require RADIUS proxy verify NAS identifier. 9. EAP Archie, Jesse Walker, 5 minutes http://www.ietf.org/internet-drafts/dra ft-jwalker-eap-archie-00.txt Jesse Walker talked about EAP Archie, a proposed solution to the problem that none of the current mandatory 2284 methods are suitable to 802.11. Archie would if accepted be a new mandatory EAP method. The Archie exchange consists of the following message exchanges (see slides [Archie] for details <-- Random Session ID (Request) Hash of Session ID, Random Nonce, Binding (MAC addresses), MIC --> <-- Hash of prev Msg, Encrypted Nonce, Binding(MAC addresses), MIC Finish: Hash, MIC --> Can the EAP MD5 Challenge method be deprecated? Can EAP-Archie be adapted to be suitable for PPP? Is there interest in taking on this work? Simon Misikowski: What kind of hashes? Jesse: The hashes are SHA hashes. Bob Moskowitz: How would this work with a Proxy RADIUS? Not sure that EAP-AKA doesn't also meet the 802.11 requirements? Bernard Aboba: There is no Proxy RADIUS issue as long as the RADIUS server uses NAS-Identifier, NAS-IPv6-Address or NAS-IP-Address attributes to compose or check bindings, *not* the packet source addresses. Alper Yegin: Why should the method be made more suitable for it's transport (PPP) Jesse: I'm asking for input on the appropriate address type for PPP. This is the Called-Station-Id and Calling-Station-Id (e.g. phone number). Alper Yegin: WLAN is primary transport? We may need to change it to adapt to other protocols? Jesse: We'd have to look at whatever is needed to adapt it. The issue in adaptation was only the address type, nothing else. ?: Looking at the differences between this and AKA. There's also the ESE, which should be compared Joe Salowey: I liked the binding aspect, we may need to look at introducing this other places or in a generic fashion? 10. EAP Keying Framework, Bernard Aboba, 15 minutes http://www.ietf.org/internet-drafts/dr aft-aboba-pppext-key-problem-06.txt Bernard presented Goals and Objectives for EAP Keying. Slides [Keying]. This is a framework for evaluate keying methods, rather than a proposal of methods. Further: EAP Invariants for keying methods, Terms for Master Key Types, ... Paul Congdon: Should you define the length of these keys if you are trying to be ciphersuite independent? Bernard Aboba: You might get suites deriving keys with different length, maybe quite short keys. The answer could be to require ridiculously large keys, or to settle on lengths which are currently sufficient. It was noted that the issue was not the length of the EMSK or MSK but its equivalent key strength. 64B is plenty long enough -- but in the future the required key strength might increase. Today 802.11 is asking for the ability to negotiate 128-bits of key strength, tommorrow it might be more. Simon (?): The MSK could be derived from the EMSK (or MK)? Bernard Aboba: No, but the EMSK MUST be cryptographically independent of the MSK and MK. The EMSK can be derived from the MK via a one-way function, or it can be a completely independent quantity. Simon: What is the purpose? Bernard Aboba: Purpose not defined yet, but its essence is that it is known by Peer and Server, and *not* by NAS. The MK is never exported, so that the MK cannot be used in computations done outside the EAP method, such as fast handoff. Where PFS is required (such as in deriving a key given to a NAS that cryptographically separate from a key known by another NAS), the only exportable quantity available to derive this from is the EMSK, since NASes never have access to it. Bob Moskowitz: The MSK is known by at least 3 parties, and the 64 bytes keying material - it is distinct from the entroyp. This defines the key lenght, not the key strength. Bernard Aboba: Yes. Bernard, continuing presentation, covering: EAP Key Hierarchy, and EAP (Key) Exchanges. There's a two-way exchange: EAP client <-> NAS, no AAA server small network usable in larger There's also a three-way exchange: client, NAS, AAA frequently deployed in larger networks Bernard continues the presentation and talks about the EAP (Bermuda) triangle. This triangle is as follows: EAP peer /\ EAP mutual auth, / \ TSK derivation, MK, TEK, EMSK / \ mutual auth, / \ TSKs / \ Auth Server ------------ Authenticator AAA mutual auth, AAA session key (TLS, IPsec) Bernard talks about the security requirements: - mutual authentication each leg - fresh session keys on each leg - key protected from compromise - protection against MITM - per-packet authentitcation, integrity, replay protection each leg The Open Issues were: - #15 missing security requirements - #47 keying requirements unspecified (why 64 bytes) what about specifying key strength? - #99 double expansion MK->MSK & MSK->TSK T.J. Kniveton: You said you couldn't get a MK out of a SIM card, but section 17 of the draft describes certain derivations Bernard Aboba: There were papers written which assumed you could get the MK out of the SIM, but we needed to clarify that it never leaves the EAP method. The MK cannot and need not leave the SIM card or the MK box in the Key Hierarchy. Joe Salowey: There are implementations of EAP SIM where the entire calculation takes place on a SIM card. Bob Moskowitz: FIPS has a document which has a key derivation proces which which we maybe we should look at, to make sure it is compatible. May need this in order to be FIPS compliant. Bernard Aboba: The document won't recommend a KDF, but it will pose requirements on KDFs. John Vollbrecht: Wanted a clarification on which keys are carried where. Bernard Aboba: (Clarification given.) John Vollbrecht: Is it likely that these things will change in the future? Bernard Aboba: If we've done a good job, this should be future proof. John Vollbrecht: Can these keys be taken out of the method? Bernard Aboba: The MSK, EMSK and IV are exported from the method. However, only the MSK is sent by the AAA Server to the NAS. The EMSK MUST NOT Be sent by the AAA Server to the NAS. The MK and TEKs are never exported from the method. The IV isn't sent by the AAA Server to the NAS but it's not very useful since it is a known quantity (required by US Export Laws several years ago). As a result it is largely vestigial. Simon: Client is roaming; while in a session, which key is transported to the new (target) NAS? Bernard Aboba: Actually, the MSK is never transported between NASes. Some proposals derive a new master session key on the AAA server, based on the EMSK and send this to the new NAS. This provides PFS. Other proposals have one NAS send a key derived from the MSK via a one-way function and send this to the new NAS. This way the new NAS can't decrypt previous traffic but the old NAS can decrypt new traffic. Simon: But there has to be a coupling between EMSK and TSK, so... Bernard Aboba: There are example formulas and methods in the Appendix. The EMSK, TEKs and TSKs are cryptographically independent. Glenn Zorn: -- Long silence, looking at EAP key hierarchy. Is it true you're treating these entities equally - including a proxy? Bernard Aboba: Yes, although it gets complicated when you have a proxy. Glenn Zorn: It could be handy to have a key known to all, but only useful for a certain purpose, such as AAA interchanges? Bernard Aboba: Yes, but there's a question here from where you derived such a key - and depending on where you derived it from, would it be secret to the people it needed to be secret from? I.e. which key tree should you John Vollbrecht: Are there 1 quantity exported from AAA server? Bernard Aboba: There are 3 entities derived, and 1 exported. Dan Forsberg: Do you specify or recommend any lifetimes for these keys, and if some time out, how do they get renewed, and can ESMK be used for session resumptions? Bernard Aboba: The EMSK is *not* used to resume sessions, because it is known by more than 2 parties. We have talked about including a key lifetime parameter, but currently the key lifetime is equal to the session lifetime, but there's a question if that's sufficient or not. 11. EAP Key Derivation for Multiple Applications, Joe Salowey, 10 minutes http://www.ietf.org/internet-drafts/dr aft-salowey-eap-key-deriv-00.txt Joe Salowey made a presentation on EAP Key Derivation For Multiple Applications. See slides. Highlights: Motivation, Applications (WEP, 802.11i, MPPE, Fast Roaming, ...) Requirements, Key Derivation, and currently open issues. Bernard Aboba: How do we figure out how much material should be derived? Joe: 64 bytes are a lot of material. We need to get input from security experts. Simon: Lucent put out some papers, for 3GPP and 3GPP, requrements on keys for them to be acceptable in 20 years. The resulting key strength (entropy) of 84 bits. Joe Salowey: Yes, 64 bytes are much. Alper Yegin: Any constraints on which applications may use this? Joe: I'd rather make keying materials available to application that needs it, rather than making restrictions. Alper Yegin: There may be security considerations with making keying material available to random applications. Bernard Aboba: Did you choose TLS for some particular purpose, or as just an example? Joe Salowey: No particular significance. Simon: (Examples of other possible KDF). Bob Moskowitz: (Pointed out which documents in the references needed to be looked at in relation to this). 12. EAP Roadmap, Erik Nordmark & Thomas Narten, 10 minutes Erik Nordmark made a presentation about Methods, Methods, Methods, Or When can we start talking about methods? (See Slides). Highlights: Requirements, Simon: 3GGP2 Requirements should also be considered. Bernard Aboba: We don't have a liaison with 3GPP2 yet? In the case of IEEE and 3GPP, they have to us and told their requirements. Simon: Interoperation between 802.11 and CDMA is an active work item within 3GPP2. You're welcome to get all requirement from the 3GPP2 web site. Erik continued: Selecting methods?, Strawman proposal: Methods can be submitted as individual submission RFCs, need Expert Review but that can start now. Method RFCs must depend on the new versions of RFC 2284 etc, however. Keep MD5 as mandatory, Capture requirements from different scenarios in an informational RFC, start work on a BCP which captures mapping from environments to appropriate methods, and possibly later pick new mandatory methods. Significant delay (9-12) months possible if we tried to do that. Not select methods for other SDOs. John Vollbrecht: We need to test interoperability, so we need some mandatory methods that exercise the features we have in our protocols. Bernard : The reason 802.11 have asked for a new mandatory method is that they are not sure they could do it themselves, so this might leave them in a bit of a quandary. Bob Moskowitz: IEEE ... They have tradentionally have been reluctant to mess with other organizations babies. EAP is your method, so please make it acceptable to our needs. We should make sure that within a year we can provide what they need, a specification of what should be used. A BCP might be good enough, it mustn't necessary be a Standard. Alper: Agree with the strawman approach, it seems a way to go forward without specifying a new mandatory method for each new interested party - IEEE, 3GPP, 3GPP2, ... Simon: The original requirements originally came from 802.11? So whatever we present to them, it will be up to them to select from whatever smorgasbord we present to them. 64 bits, is that their req? Bob Moskowitz: Yes. Simon: and mutual authentication came from them? Bob Moskowitz: Yes. Dave (?): We need to have a recommendation of a mandatory method for use with 802.1i, and this is really out of our scope, this belongs to IETF. We need a published document we can reference in our documents, pointing out a method we can use. Erik Nordmark: So a BCP would be enough, a PS is not needed? John Vollbrecht: We need a specified method in order to measure interoperability Bob Moskowitz: Any methods we can get out quicker rather than later, in the form of an RFC rather than just a draft, makes it possible for them (802.xx) to reference it, and say to vendors "these are the methods to use, go out and implement them" 13. IEEE 802.1aa/EAP State Machine Reconciliation, Paul Congdon, 10 minutes Paul Congdon made a presentation on alignment of different 802.xx and EAP RFCs. (See slides) Highlights: Current status, Document List, Proposed and Agreed Changes to 802.1aa/D5, EAP/802.1X Interface, Key Interface with EAP, 802.1X, 802.11, LinkSec Task Group Formation in 802.1 14. EAP State Machine, John Vollbrecht, 15 minutes http://www.ietf.org/internet-drafts/dr aft-vollbrecht-eap-state-01.txt John Vollbrecht made a presentation on EAP State Machines. (See Slides). Highlights: URL's, State Machine Style, EAP Mux Model, Peer State Diagram (802.xx style state machine), Pass through, Policy Functions, State Machine next steps, 15. EAP Protected TLV, Joe Salowey, 5 minutes http://www.ietf.org/internet-drafts/dr aft-salowey-eap-protectedtlv-01.txt Joe Salowey, presentation on Protected EAP-TLV, a way to protect a (tunnelled) series of TLV's. (See Slides), and continued with EAP-Authorization, a method to request authorization for services and session attributes (See Slides) Dave (?): Which endpoints would exchange these TLVs? Joe Salowey: Supplicant and Auth. Server. John Vollbrecht: Is this going to be a method? Joe Salowey: Right now it's just a TLV, and maybe it makes sense to make it a method, but I don't know if it must be. John Vollbrecht: So it could be tagged into other methods? Joe Salowey: Essentially a method, could come at the end of other methods. Could happen inside an EAP message. John Vollbrecht: So I could run EAP within EAP within EAP... 16. EAP SIM and AKA, Joe Salowey, 10 minutes http://www.ietf.org/internet-drafts/dr aft-haverinen-pppext-eap-sim-10.txt http://www.ietf.org/internet-drafts/dr aft-arkko-pppext-eap-aka-09.txt Joe went on with a presentation on EAP-SIM drafts (multiple). (See Slides). Bob Moskowitz: I'd like to see a change in the AKA draft, to talk about a shared secret method, and then a particular GSM application in an Appendix Jari Arkko: So this is only a question of a change in terminology? Bob Moskowitz: Yes, and mapping to GSM terminology as a separate part. Jari Arkko: I think we can do this. Simon: How does SIM fill the 128 bits requirement? Joe: You use multiple triplets. Simon: These triplets doesn't provide mutual auth? Joe: No, but EAP-SIM does provide mutual auth based on these. Bernard suggested that even if this is not yet a WG document, the authors should already now get security reviewers, to speed up the process. 17. Tunneled MD5, Paul Funk, 5 minutes http://www.funk.com/documents/draft-fu nk-eap-md5-tunneled-00.txt Paul Funk made a presentation on The EAP MD5 Tunneled Authentication Protocol. (See Slides). This is an attempt to cure the MITM problem for tunnelled operation, (the Puthenkulam draft) 18. Meeting ended. |