Minutes of the EAP WG Monday November 18, 2002, 15:30-17:30pm Note takers: Dorothy Stanley, John Vollbrecht, Bernard Aboba Welcome, Intro, call for note takers Review of Document Status - Bernard Aboba WG work items: Standards track: RFC 2284bis, draft-ietf-pppext-rfc2284bis-07.txt Goal: recycle EAP at Proposed Standard Standards tracK: OTP, GTC, draft-ietf-eap-otp-00.txt Originally part of RFC 2284. Separated due to lack of implementation experience, so as to allow RFC 2284bis to advance to Draft Standard, while OTP, GTC draft would remain at Proposed. Now that RFC 2284bis is recycling at proposed, can be left in, to see if it is implemented. Will be incorporated in -08, so that this draft will disappear. Informational: ESTEEM draft, draft-ietf-eap-esteem-00.txt Minutes of the EAP State Machine Design Team. Will be discussed later. Individual submissions: Standards track: draft-aboba-pppext-eap-iana-02.txt EAP IANA considerations, separated out into a separate document. If RFC 2284bis will go to last call soon, won't be needed. Informational: draft-aboba-pppext-key-problem-03.txt EAP Keying draft, required work item within WG charter, requested in 802.11 Liason Letter. Informational: draft-zorn-eap-eval-00.txt Draft on Security Claims. Recommends approach to be incorporated into RFC 2284bis. Informational: draft-puthenkulam-eap-binding-00.txt Description of security issues with compound authentication in EAP. Informational: draft-hiller-eap-tlv-00.txt EAP extension framework. Items in other WGs: Informational: draft-aboba-radius-rfc2869bis-04.txt This is a revision of RFC 2869, done in tandem with the IEEE 802.1aa revision. Goal is to clarify RFC 2869, reduce differences with IEEE 802.1X. IEEE 802.1aa references both RFC 2284bis and RFC 2869bis. Proposed Standard: draft-ietf-aaa-eap-00.txt Diameter EAP application. Shares much of the text with RFC 2869bis (needed for Diameter/RADIUS gateways). Since RFC 2869bis is so similar, comments on both can be posted to IETF AAA WG mailing list (aaa-wg@merit.edu). Liason Arrangement with IEEE 802.1aa IETF EAP WG has a liason arrangement with IEEE 802.1aa (revision of IEEE 802.1X). This means that EAP WG members have access to the IEEE 802.1 archive so as to be able to read the 802.1aa drafts in progress (latest is D4, just going into ballot). An important goal of RFC 2284bis/RFC2869bis is to reduce discrepancies between 802.1X and RFC 2284. Here is how to access the 802.1aa documents: http://www.ieee802.org/1/mirror/8021/aa-drafts/d4/802-1aa-d4.pdf username: p8021 password: go_wildcats In order to submit IEEE 802.1aa ballot comments, post your comments to the EAP WG mailing list and one of the IEEE voters will submit them in the correct format. Goals and Milestones - Bernard Aboba December 02 - Submission of RFC 2284bis as Proposed Standard. This includes IANA considerations, OTP/GTC, type space expansion, security considerations/claims. State machine will be a separate document. We are a bit behind on this milestone -- may not go into EAP WG last call until late December - January 2003. But cannot slip too much since IEEE 802.1aa references RFC 2284bis. June 03 - EAP keying framework document. This one needs work, will get more attention after RFC 2284bis, state machine are further along. RFC 2284bis-07: Bernard Aboba Goals for RFC 2284bis Understanding behavior of current implementations Original EAP implementation survey in 2001 Not many IEEE 802 EAP implementations then -- many more today. Survey will be repeated when RFC 2284bis goes to Draft Standard. Interoperability testing - ongoing. Recycling RFC 2284bis at Proposed Standard Considerable interoperability issues, clarifications needed To advance to Draft Standard, need more interop testing, need to document results of interop testing - will take a while Backwards compatibility is an important goal Recognizes support for multiple media RFC 2284bis is double the size of RFC 2284! IANA considerations needed Security considerations to be beefed up Need to describe EAP operational model Non-goals Re-writing EAP from scratch - this is not EAP NG! Making non-backwards compatible changes Revising RADIUS - RFC 2869bis/Diameter EAP handled in AAA WG Revising IEEE 802.1X - handled in IEEE 802.1aa Interoperability Testing opportunities CIUG - still in operation? No one knows. Networld Interop Report Karen O'Donague - WLAN security lead for N+I At Interop Las Vegas, Spring 2002 did testing of IEEE 802.1X with EAP TLS, TTLS and EAP MD5. Also tested VLAN configuration (draft-congdon-radius-8021x-20.txt). At Interop Atlanta, Fall 2002, tested PEAP. Interop Las Vegas, Spring 2003, preliminary discussions ongoing. Queston: Could this be an opportunity to work out interoperability issues? Karen: Hot staging is an opportunity for testing, open to the community. We have been talking to the University of New Hampshire about developing interoperability tests for IEEE 802.1X. We are interested in people's comments. EAP Survey Results EAP implementation surveys were sent to the PPPEXT, IEEE 802.1X mailing lists in 2001. This covered implementations of RFC 2284 on PPP and IEEE 802. Results covered 2 PPP implementations, 2 IEEE 802.3 (Ethernet) and 1 IEEE 802.11 implementation. Many implementations were "in process" at that time -- particularly IEEE 802.3 and IEEE 802.11. Survey disclosed some features not implemented: EAP OTP, GTC Default retransmission timer of 6 seconds "Alternative indications" on loss of EAP Success and Failure Display of Notification to user These features will be examined in more depth as part of RFC 2284, Issues have been filed. Since RFC 2284bis no longer going for Draft Standard, don't have to cut non-implemented features -- but often features aren't implemented because they are broken in some way -- so worth revisiting them. 2284bis Issues Process - Bernard Aboba You may have seen "Issues" postings to EAP WG mailing list (eap@frascone.com). This is a request for a change in an EAP WG document. Not just a question -- a request for *action*. Not just a problem description -- need to include proposed text for the solution! To file an issue fill in the following form to eap@frascone.com: Description of issue Submitter name: Your_Name_Here Submitter email address: Your_Email_Address_Here Date first submitted: Insert_Date_Here Reference: URL to e-mail describing problem, if available Document: Document Requiring change [RFC2284bis, RFC 2869bis, Keying Framework] Comment type: ['T'echnical | 'E'ditorial] Priority: ['S' Must fix | '1' Should fix | '2' May fix ] Section: Insert_Section_Number_Here Rationale/Explanation of issue: Lengthy description of problem Requested change: Proposal for what to do about it The issues list is kept at: http://www.drizzle.com/~aboba/EAP/eapissues.html Issues status report: 42 Issues raised so far RFC 2284bis (37) 20 resolved 3 rejected 14 still open RFC 2869bis (2) 2 resolved EAP keying framework (2) 2 still open EAP state machine (1) 1 still open Observations: Most issues relate to RFC 2284bis. Closed/still open ratio is not very good: have only resolved 20 out of 37 open issues on RFC 2284bis. Open 6 months or more: Issues 2,7,10,14,23,25,26,32 Relatively little discussion on posted RFC 2284bis issues so far If this continues, EAP WG will miss milestones, and IEEE 802.1aa and IEEE 802.11i will be delayed and impacted. Have to pick up the pace! After IETF 55, will post resolution to most of the open RFC 2284bis issues, based on EAP Design Team discussions. Please be prepared to debate the resolution, read the drafts and file more issues. Goal is to get RFC 2284bis to EAP WG last call by end of the year. Tell us your opinion on the mailing list. Open RFC 2284bis issues Alternative indications (#2) Authentication sequences (#7) Acknowledged Success/Failure (#10) Identifier usage (#13) EAP Transport behavior (#14) Identifier behavior (#18) Identity Request Payload (#23) Spoofing and duplicate detection (#25) Unprotected success and failure (#26) Keying confirmation (#32) Language negotiation (#38) Man-in-the-middle attacks (#40) NAK of Vendor-specific (#41) EAP enhancements (#42) EAP State machine Design Team (ESTEEM) - Jari Arkko Goal of the EAP State Machine Design Team (ESTEEM) is to prepare an EAP state machine document that is compatible with IEEE 802.1aa, RFC 2869bis, Diameter EAP, and correctly handled identity exchanges, sequences, re-authentication, retransmission, Naks, Notification, etc. Members: Bernard Aboba, Jari Arkko, Paul Congdon, Rodrigo Garces, Robert Moskowitz, Yoshihiro Ohba, Bryan Payne, Nick Petroni, Joseph Salowey, John Vollbrecht, Jesse Walker, Glen Zorn Operation Weekly teleconference calls, submission of Position Papers (incorporated into ESTEEM document), review of open RFC 2284bis issues, produced two state machine documents so far. Making headway on EAP state machines has required addressing open RFC 2284bis issues - we have to know what the protocol does before writing a state machine for it! ESTEEM Recommendations to EAP WG on Resolution of RFC 2284bis issues Basic issues Allow notification in any state; can’t be Nakked EAP layer (not method) handles duplicate detection and id numbers (#25) Follow IEEE 802.1aa format in EAP state machine definition Identity requests Identity request/response can only appear between methods, not in the middle Identity requests are optional. Nak disallowed for Identity Request Success and failure indications If an authenticated indication exists, should not believe non-authenticated indications Link-layer indications provided to EAP MUST be processed (#2) Unprotected success indications are only accepted after method is complete (#2) Peers should be able to accept Failure in unauthenticated state Authenticated success/failure indications require support for sequences or tunnels (#10) Sequences Methods can’t be executed in parallel; Nak if received No pre-negotiation of method sequencing capability, just Nak afterwards (#7) Any objections to these recommendations? None. Will be incorporated into RFC 2284bis-08. Further discussion of RFC 2284bis open issues: Bernard: Issue # 42 - Request to change EAP to support PAP, keepalive. Was originally submitted as an IEEE 802.1aa ballot comment. GZ: On that issue, we should reject both suggestions. PAP and heartbeat. We don't need to support these. BA: Any objections to recommending that comment 42 be rejected? No objections. Issue #42 resolved: Rejected BA: Comment #41: Ambiguity in actions for NAK of vendor specific commands. NAK needs to include vendor-specific type (255) plus vendor-type and command. Not hard as long as multiple methods are not included within the NAK -- if so, gets complicated. James Kempf: Didn't we have an issue in Diameter with vendor-specific AVPs? Bernard: No, this is the capabilities negotiation, a different issue. James Kempf: There were process issues with vendor-specific things in Diameter. Bernard: Yes, the issue was with Vendor-Specific commands in Diameter. Vendor-specific AVPs are still in the documents. The issue here is that most EAP allocations are for vendor-specific Types, and EAP space is finite (255). James Kempf: Will vendor-specific EAP Types be grandfathered in? Bernard: Since this has been in there for a while, leave it in Erik Nordmark: The IESG has no problem with this. The concern is with vendor specific and undocumented features that break interoperability. It is important to do features in a standard way. Also, deal with negotiation. The prime directive is interoperability. Paul Funk: One suggestion is to redo the list of NAK types by mapping normal EAP types into the zero vendor ID. When you get an FF as an EAP type, then the end of the list has been reached. Bernard: Wouldn't this break backward compatibility? Let's take discussion to the list. Bob Moskowitz: Need to look at denial of service attacks with the proposal Paul Funk: This is a general issue with a negotiating down attack. DOn't know if this has been looked at. Will write up some suggestions. Bernard: Issue #2, Alternate Indications. Lower layers have different alternate indications. RFC 2284bis indication behavior was not implemented -- because it is insecure. For example, could go into "Success" state based on receipt of PPP NCP packets. Design Team has rewritten the text so as to differentate been protected and unprotected indications. Unprotected indications cannot overrule protected ones. New text is more secure -- has been implemented, seems to prevent man-in-the-middle attacks. Any comments on proposed resolution? No comments. EAP Transport behavior #14: Default retransmission behavior of 6 seconds has not been implemented. Not all EAP methods require manual intervention (some are automatic). For those that require manual intervention, times can vary (you have to take out token, punch in numbers. Maybe more than 6 seconds is required?). Proposed solution is to allow Session-Time to determine behavior based on the EAP method, use RFC 2988 (TCP RTO) behavior where no hint is given. That way EAP retransmission can adapt to the media. Could prevent false retransmissions for media with high latency, like GPRS. Will discuss on the list. Issue #13 (Identifier Usage), #18 (Identifier Behavior): Design Team decision is not to specify behavior in detail, just that the Identifier must not repeat during a conversation. This allows IEEE 802.1X behavior (start at 0, increment by 1), but does not require it. Will discusson the list. Spoofing and duplicate detection (#25): Design team recommendation is that sequencing and duplicate detection be done in the EAP layer, so EAP method will get a non-duplicated and ordered stream of packets. This has disadvantages -- EAP method may never get packets that are valid but represent dupes due to an attacker. Would be more resilient to allow all packets to go up to the method and allow integrity protection check to be done prior to discard. But this would require EAP method to sit on top of an unordered, unreliable transport -- and EAP methods assume reliability. This is similar to the difference between SSL/TLS which runs on TCP/SCTP, and ISAKMP, which runs on UDP -- except that EAP sequence space is only one octet, so it's almost trivial to spoof or otherwise disrupt the sequence space. Will discuss on the list. Identity Request Payload (#23) is about how to know which network or NAS is being connected to. In most cases, this is know via out-of-band indications such as 802.11 Beacons and Probe Responses. In IEEE 802 wired networks there is no equivalent yet -- Layer 2 advertisement occurs *after* 802.1X, not before. Should it be moved before? Also, what if you want to do adhoc, with each side identifying themselves? Is it the Authenticator Id that goes in the Identity Request? The Network ID? Will discuss more on the list. Keying confirmation (#32): Recommendation is to accept the proposed change. Will discuss on the list. Will discuss Acknowledged Success/Failure (#10), Unprotected Success/Failure (#26), Man-in-the-middle attacks (#40) later on. Will put off discussion on Language Negotiation (#38) since this is an "extension", like #10, 26. Presentation on EAP State Machine - Nick Petroni, Chuck Yang Seng The latest draft (-01) is an update to prior work presented at IETF 53 Includes both Authenticator and Peer state machines Question: In the case where Authenticator resides separately from the NAS (AAA) do we need a NAS state machine, too? Possibly, there is one in IEEE 802.1X. Changes based on design team decisions IEEE 802.1X notation now used for state machine. Reflects decisions on Nak and Identity handling. Authenticator state machine - see http://www.cs.umd.edu/~npetroni/EAP/ietf55.pdf Since the EAP protocol is extensible, the state machine needs to reflect this. The notion of policy is introduced to enable what methods and subsequent behaviors may follow. For example, the "Success" state can only be reached if a method is finished (and has completed successfully). NAKs only arrive in response to the first request from the authenticator, within a method -- they are not used in the middle of a method. Commenter: State machine now indicates that if one method fails within a sequence, then authentication fails, as the Design Team recommended. BA: If any method fails, take as failure. Any comments? No comments, will be incorporated. Chuck: Review of EAP Peer State Machine Still to be done - explicit representation of timers, error handling, alternate indications of failure/Link changes, Pass-through authenticator. Any questions? No questions EAP IANA Considerations - Bernard Aboba 36 types allocated so far. Most do not have a specification available, since they are for vendor-specific use. Observations Rate of Method Type allocation is increasing RFC 2284bis was published in March 1998 PPP Number assignments handled by IANA: http://www.iana.org/assignments/ppp-numbers Only 8 new types (9-17) allocated by August 2001. Roughly 20 new types allocated in 12 months since then, almost 2 a month. Some methods have been allocated more than one type (EAP SRP). Not clear this should ever be necessary. Different type codes have been allocated for similar but perhaps not identical methods (two EAP-MSCHAPv2 variants). Not all allocated Method Types are used -- at least 5 Types appear to have never been used (15 percent of the allocated type space). Conclusions: Type allocation process is not running efficiently right now. At the present rate of allocation, half of EAP Type space would be exhausted within 4-5 years. So problem is not immediate, but given pace of IETF process, deployment of fixes, it is not too soon to standardize a solution now. For example, if we get a solution to RFC in a year, and it takes 3 years for wide implementation and another 3 years for deployment, solution will be widely available just when the problem has become severe. Recommended IANA considerations (included in RFC 2284bis): Packet Codes Codes 1-4 described in RFC 2284 Codes 5-255 allocated by Standards Action Method Types Method Types 1-36 already allocated by IANA Method Types 37-191 allocated via Designated Expert w/specification required Method Types 192-254 reserved; allocation requires Standards Action Method 255 for Vendor-Specific extensions when no interoperability is deemed useful (vendorID != 0), or for additional Type codes (>=256) when vendorID == 0. Allocation of more than one type code to a single method requires IETF Consensus Question: When is "IETF Consensus" required? When a single method requests more than one type code. Today in theory someone could request allocation of the entire EAP Type space for one method. Question: What do we do in the meantime before RFC 2284bis is published? Bernard: Go to IANA, request an allocation as you do today. Question: How immediate is the problem? Bernard: It will start to become an issue in 4-5 years. Within 10 years it will be severe. 4-5 years is not long given IETF standardization, product development and deployment time frames. Goal of IANA considerations is to slow down the exhaustion rate by creating a new vendor-specific space, since most types are allocated for vendor-specific currently. Could push out exhaustion of the standard space many, many years. Once existing (37-191) space runs out, can allocated from the extended (vendorid=0) IETF space. Thomas Narten: How about allocating a single EAP method Type for experimental use? Bernard: OK. Will put into RFC 2284bis-08. Bernard: The question has arisen as to whether IANA considerations should be kept within RFC2284bis or processed separately. Protocol specifications MUST have an IANA considerations section, so it needs to be done. Question: Does definition of the vendor-specific type (255) go into the IANA considerations document if it is separated? Bernard: It doesn't have to be in there. Question: If it isn't, what do people do in the meantime? It would put real development in limbo, since you'd need a specification to get a standard allocation. Bernard: That is an argument for putting them together in the same draft. Of course, then you'd need to define extended Nak along with Vendor-Specific type in the same document. Any opinion on how to advance them? Commenter: Keep IANA considerations part of RFC 2284bis -- ensures consistency. Question: This makes obtaining type values more difficult. Is it necessary? Bernard: The rate of allocation has been increasing -- we're now allocating up to two types per month. At current rate, we'll have a problem in 4-5 years, severe problem in 10 years. IETF process is slow, implementation is slow, deployment is slow. Need to get standards process started way in advance of when a severe problem would occur. Even 10 years ahead of time to get started is not too early -- witness IPv6, where it's not clear that we'll be ready in time. Bernard: Recommendation is to keep IANA Considerations in with RFC 2284bis, not separate it out. Any problems with this? No problems, will be kept as part of RFC 2284bis. EAP State Machine - John Vollbrecht Goal of this work was to produce an EAP state machine based on the EAP switch model -- interactions of EAP layer and method layer described in the ESTEEM document. It is desirable to keep the state machine as simple as possible -- to avoid interoperability problems. EAP Switch model: The EAP layer (called the "Switch") is responsible for negotiating methods with peer EAP layer "switch." Policy is implemented within the EAP layer, not within methods. This work has produced Authenticator and Peer state diagrams. The key to interaction between the EAP layer and methods are the "Primitives" by which the EAP layer (switch) and Method interact. ESTEEM Draft includes some proposed primitives -- for things like keying, success/failure indication from method to the EAP layer, etc. The Authenticator selects a method, sends a Request, and this causes the Peer to change states on receipt. The first Request need not be an EAP Identity. IEEE 802.1aa has been changed to reflect this -- it could be a method packet sent by the Authenticator. EAP State machine Issues How does method indicate failure to the EAP layer? Success? There needs to be a primitive for this, because it influences how the EAP layer will process subsequent EAP Success or Failure messages (unprotected indications) that arrive. What about a packet from an unexpected method? We've decided that the Type cannot switch in the middle. Until the method indicates success/failure, the EAP layer expects only packets of the same (negotiated) Type. What about unexpected NAKs? Again, a NAK can only be sent in response to the first Request within a method. If a method is ongoing, the EAP layer will not be expecting the NAK. In any cases, NAKs are not passed up to the EAP method, there is no primitive to do this. Notifications are not passed up -- although there is a primitive on the Authenticator for requesting that they be sent. There is a primitive for retrieving what is sent in the Identity Request or Response. So that is obtainable within any methods. Where does policy reside? How are variables passed among methods? We're just getting started with primitive definitions, which may shed light on this. How does EAP retransmission interact with RADIUS retransmission? We've seen some circumstances (IEEE 802.1X) where we can have duplicates arrive at the RADIUS server. IEEE 802.1X Supplicant sends EAPOL-Start, Authenticator sends EAP-Request, they cross in the night; two EAP-Responses end up being sent to the RADIUS server with different Identifier values. The current state machine draft in the ESTEEM Draft only deals with the Peer and Authenticator, not the NAS. Will post a revised draft, NAS state machine after IEEE 55. Jari Arkko: How do we go forward from here? Can the two groups working on state machines merge their proposals? John Vollbrecht: We can work on this. EAP TLV - Glen Zorn Glen Zorn noted that he has been talking with Paul Funk about EAP TLVs for some time. The basic idea is to create a "container" type for EAP allowing for a richer conversation between the peer and the authenticator. An EAP TLV exchange can be sent at any point during the EAP conversation; may be NAKed by methods that do not understand it. Example use - acknowledged success and failure. Bernard: Do you really mean at *any* time? Such as in the middle of a currently running EAP method? The Design Team recommends that new methods only be allowed at the beginning or after an existing method has terminated successfully. Glen Zorn: This needs to be worked on. Not sure what the answer is. Paul Funk has found uses for this, and I think it is really useful to have it. For example, it allows multiple current issues like #10 (acknowledge success/failure), #26 (protected success/failure), #38 (language negotiation), and even #40 (man-in-the-middle attack) to be handled. It's been discussed as a potential solution to MIP/802.11 integration as well. Compound Authentication - Jesse Walker This work has been done by a lot of people. I'd like to recognize the work of the Nokia Research Center which discovered the attack, and there are people within the EAP, IPSRA, and IPsec WGs that are working on analyzing it and finding a solution. The problem arises when multiple EAP types are used in a sequence or a tunnel. For example, you might have a strong authentication method that derives keys -- but if you put it inside a tunnel you now make it vulnerable to a nasty man in the middle attack. Weak methods, such as legacy authentication methods, have problems with and without a tunnel. Glen Zorn: Would you mind talking about the definition of "legacy"? I don't understand it. Jesse: EAP tunneling seems to have been invented to enable more secure use of legacy authentication methods. These are typically methods such as EAP-MD5 or a token card, that are one-way, and don't derive a key. They have traditionaly be used in dialup. The IT department monitors their use and looks for attacks. Legacy protocols typically don't support mutual authentication or key derivation -- so they are vulnerable to hijacking. This was not a concern for PPP, which was considered "physically secure". But 802.11 changes things, anyone can have access to the "medium." Glen Zorn: What does it mean to say "where tunnel termination is not on the real endpoints (client and server) and authentication protocol derives no keys"? Jesse: I agree, it's not clear. Glen Zorn: EAP-MSCHAPv2 is a method that derives keys and does mutual authentication. When used within a tunnel it is a compound method, no? Jesse: Yes. Glen Zorn: And the vulnerability still exists, no? Jesse: Yes, because the tunnel key and the EAP-MSCHAPv2 keys are not "bound". MN: A prerequisite for the attack of that the EAP method is used outside of the tunnel with the same set of credentials. Jesse: Good point. However, you can't just say "don't reuse credentials". Sometimes that is possible, but people want to reuse credentials like token cards, SIMs. They don't want users to have to carry around multiple devices. So in the real-world, you can't make this go away. MN:As soon as you don't re-use credentials, you are ok and the attack doesn't work. Jesse: As long as you *always* use EAP within the tunnel -- and the tunnel server is authenticated. Jesse: Let's review how the attack can be carried out when EAP-AKA is used within EAP TTLS. The problem is created because the tunnel is only authenticated one way -- the server authenticates to the client, but not the client to the server. Glen Zorn: That's not true. Lack of enforceable client policy enables the attack. If you can force the EAP method to only run through the tunnel you have solved the problem. If you don't have credential reuse you're ok. So it's an implementation problem with the client policy. And note that for true "legacy" methods as you've defined them -- crypto binding will not help, because there are no keys, nothing to "bind" with, and you've given the "legacy" credentials which are presumably insecure to the attacker. So you're still stuck, even once a "solution" is applied. Jesse: The market says "we want this." The GSM folks want to use SIM/AKA for web authentication, Cellular, 802.11. Companies want token cards to work in multiple applications. It might be worth our while to make it more difficult to do this -- but can we expect such a policy to be widely adopted? Seems unlikely. Commenter: The problem is not just specific to a one way tunnel. It also applies to a mutually authenticated outer tunnel if the outer tunnel is not tied to the inner tunnel. You can use the MAC or IP address or machine name as the outer identity, user identity for the inner identity. Association can be established when authentication is done. Commenter: However, when you have mutual authentication, it is possible to exercise access control based on the identity within the outer tunnel. You can only allow a set of identities within the inner tunnel that correspond to identities in the outer tunnel. For example, you can only allow a subset of users to authenticate themselves within a tunnel established to a given machine. So you can enforce a combination of machine and user authentication: only allow a user to authenticate from one of several possible locations/machines. That's not a vulnerability per se -- the user access can be explicitly authorized. Jesse: If one believes that this is a problem, then you have several ways to go about solving it. You can try to fix existing EAP methods. This could be hard because "legacy" methods are already deployed. You could try to fix new EAP methods -- this might be possible. You can try to fix the tunnel methods -- that might work. Jesse: EAP methods can be divided into "ciphering" (key deriving) and "non-ciphering" (no keys). Ciphering tend to support mutual auth, non-ciphering tend to not support this. I don't necessarily agree with the classification. If don't derive keys, tunneling doesn't make anything worse - eg. EAP-MD5 with TLS tunnel. You had a man-in-the-middle problem before, since the client didn't authenticate the server. You had a hijacking problem before, because there was no key to bind the authentication to subequent data. You have a potential dictionary attack. Not much changes with a tunnel. You still have man-in-the-middle. The attacker can obtain credentials for an offline dictionary attack. Jesse: However, if you were using a "ciphering" method -- one that does derive keys, such as EAP-SIM, putting it within a tunnel does make things worse. Before you didn't have a hijacking or man-in-the-middle vulnerability, because you did mutual authentication and derived keys to bind the authentication to subsequent data. Now with tunnels you have a man-in-the-middle vulnerability you didn't have before. How do you solve the problem? You add a handshake within the tunnel based on combining the tunnel keys and the authentication method key. The combination defeats the MiTM attack. This fixes the situation for key deriving protocols. However, it does not help "non-ciphering" protocols -- which includes most legacy protocols: CHAP/EAP-MD5, OTP, GTC, SECURID. Jesse: Recommend formation of a design team to study proposed fixes and recommend a solution to be added to the EAP Base protocol. Glen Zorn: There should be guidance in the security considerations section of RFC 2284bis, advising admins to define policies. For example, allow EAP-MD5 in dialup, but not for 802.11/wireless. Henry Haverinen: I agree with Jesse's presentation. Right way to look this is to look at a strong method such as UMTS and don't re-use credentials. Should we do the crypto binding? BA: Henry, the Nokia Research Center has also worked on this problem, and written papers and presentations. Do you agree on the characterization of the problem? Henry Haverinen: Yes BA: Do you agree with the solution? Henry Haverinen: Yes, it should be fixed with a crypto solution. We also can have policies. Jesse: One recommendation is that strong methods (key deriving, mutual authentication) SHOULD NOT be used with tunneling protocols like PEAP, EAP TTLS. Henry Haverinen and Nokia Research Organization started out this line of thinking. Commenter: But what about protocols such as PIC or PANA? They carry EAP over IP within a protected channel: ISAKMP (PIC) or TLS (PANA). How else should this be done? EAP over TCP/UDP Without protection? Commenter: Possibly. Single, strong methods can run "naked". Commenter: Can we prevent these attacks by having restrictions on the client? Jesse: Yes. MiTM comes about because people do stupid things -- credential reuse, use inside and outside of tunnels. Commenter: Mobile operators will put restrictions on the client, and can put policy on the server. This could be as simple as having the public key of the server. Bernard: Let's not design a solution here. We're still talking about the problem. Commenter: I agree with both sides. If we want to solve the problem, we need a cryptographic solution. I'd prefer to see the solution done in EAP, rather than in each tunneling protocol. Perhaps some authentication methods can be changed -- only RFC 2284 and RFC 2716 are RFCs yet, the rest are still IETF drafts. We just need to add the tunnel keys into the authentication method. Glen Zorn: We still need to characterize the problem. "A cryptographic solution" solves MITM for methods that derive keys. But tunneling is largely motivated by a desire to improve security of legacy methods -- that this "solution" doesn't help. So are we talking about something bigger? PF: A Cryptographic solution - combining keys to form compound MACs and compond keys, and then doing mutual validation based on those keys -- restores features of the protocols that we thought we arleady had. Glen Zorn: Yes, but the attacker has still been able to obtain the legacy credentials . If these were vulnerable to dictionary attack, then the attacker can obtain the passphrase -- after which it can access the network at will by whatever access method allows "naked" EAP access. If there were no such access, the attacker would not have been able to perpetrate the attack. With the solution, the attacker can still access the network. So what problem has been solved? Jesse walker: Right, the cryptographic solution only works completely where the encapsulated method is strong against dictionary attack, supports key derivation and probably mutual authentication. In which case -- why were we tunneling it?? Commenter: Cryptographic solution doesn't add any real value; it doesn't help legacy protocols or protocols with dictionary attack vulnerabilities. For strong protocols the right solution is not to use tunneling. So all we accomplish with the cryptographic "solution" is to add complexity. Bernard: We have with us Hugo Krawczyk, who has also been looking at this problem from the point of view of IPSRA WG (PIC). Hugo -- do you agree with the problem characterization? Hugo K.: Yes. Bernard: Any thoughts on the solution? Hugo K: It is also not clear to me that the "cryptographic solution" is worth implementing. The problem is credential reuse, in my opinion. Bernard: Humm if you feel that this is a problem. wg hmmed that it feels this is a problem. Somehow a solution needs to be found. Chairs will propose an approach on the mail list. Adjourned. EAP WG meeting Tuesday, November 19, 2002, 1700-1800 EAP Keying Problem -- Bernard Aboba Goals and Objectives To describe basic concepts of EAP To describe the EAP keying architecture To point out pitfalls in design of EAP methods that derive keys To identify problems that require solution The goal of this draft is to describe the EAP Keying framework and also to provide guidelines for EAP method developers, in terms of things to watch out for when developing a method that derives keys. The motivation for this draft came from reviewing EAP method specifications. There was a wide variety of keying behavior. Some methods derived keys. Others did not. Some methods derived keys with 128-bits of entropy. Somekeys had much less entropy -- or didn't use well understood key derivation technology. Some methods derived ciphersuite-specific "session keys". Other methods derived "master session keys" which were ciphersuite independent. Some methods included specifications for how session keys would be derived for specified ciphersuites -- only for that method. Presumably another EAP method could use a completely different mechanism to derive session keys -- for the same ciphersuite. The draft doesn't go into depth in key derivation techniques. This is a topic for professionals. But it does try to describe why certain practices, such as ciphersuite-specific session key derivation -- doesn't make sense in EAP methods. Why derive keys? Key derivation is not required in all cases. In wired networks like IEEE 802 or PPP, physical security is typically assumed so that EAP may be used purely for authentication, no confidentiality. In that case, there is no need to use an EAP method that derives keys -- and if it is assumed impossible to install a rogue switch, then mutual authentication isn't needed either. In wireless everything is different. You need confidentiality and to avoid hijacking, the authentication needs to be "bound" to the data via per-packet integrity protection. So you need an EAP method that derives keys. Also, as was discussed in the "EAP binding" session yesterday, keys can be used to bind an EAP method to the encapsulating tunnel or to other methods within a sequence. Some basic background on EAP key flows. Keys are derived between the EAP Peer and Authenticator. If the Authenticator and NAS are not colocated then keys need to be transferred from the Authenticator (Authentication server) to the NAS. In methods like Kerberos, it is also necessary to transfer keys from the Peer to the NAS. The key flows are discribed in the draft. Note that other geometries are possible. Even with an authentication server, you could have a tunneled protocol with the tunnel (e.g. TLS tunnel) terminated on the NAS and the inner authentication tunneled somewhere else. The EAP architecture assumes that the NAS serves as a "passthrough" for some or all authentication methods and users. It could act as a passthrough for some methods, but not all, or for some (local) users but not all users. But when the NAS acts as a passthrough the goal is to not require the NAS to implement the method -- this is implemented on the Peer and Authentication Server. Similarly, the Peer and NAS negotiate and implement the ciphersuite, not the Authentication Server -- because no data passes through the AS. The AS may not even know the negotiated ciphersuite -- it may be negotiated *after* authentication. So there may be no practical way to include the ciphersuite in the EAP method's key derivation. Even if this were possible -- such as if the EAP method supports ciphersuite negotiation -- it wouldn't be a good idea. New ciphersuites are continually created, on different media. But we don't want to have to revise the EAP method to support each new ciphersuite. The maintenance burden would be excessive. So the right approach is for EAP methods to generate ciphersuite independent keys -- and to get them to the NAS and Peer, which can then derive the key hierarchy for the negotiated ciphersuite. So EAP key derivation has two phases -- the derivation of what is called the "Master Session Key" (called the Pairwise Master Key in 802.11i), and the subsequent derivation of the ciphersuite-specific session keys. What is a key hierarchy? A description of how the session keys required by a particular cipher are derived from the keying material provided by EAP methods. You need a key hierarchy for each ciphersuite/media. Desirable characteristics: Key strength (64 bits is typically not enough). Cryptographic separation: the inability to get information about one of the keys in the hierarchy, based on having cracked another key in the hierarchy. Example key hierarchies: MPPE (RFC 3079), IEEE 802.11i, EAP TLS (RFC 2716). IEEE 802.11i derives the key hierarchies for TKIP, CCMP and WRAP solely from the Pairwise Master Key (PMK) transported in MS-MPPE-Recv-Key attribute defined in RFC 2548. So only 256 bits of keying material of the 512 bits that are transported in the RFC 2548 attributes are used to derive authentication and encryption keys plus keys for authenticating and encrypting the EAPOL-Key packets. See IEEE 802.11i for details. MPPE (RFC 3079) uses both MS-MPPE-Recv-Key and MS-MPPE-Send-Key in its key hierarchy, using 512 bits instead of just 256 bits. MPPE uses only encryption keys in each direction, no authentication keys. See Section 4 for details. Short summary (details in slides, but not discussed) In EAP TLS (RFC 2716), the Master Session Keys are computed via the TLS PRF (Diagram in presentation, small type): Details: Compute up to 128 bytes (1024 bits): PRF1 (master secret, "client EAP encryption", client_hello.random || server_hello.random) Compute up to 64 bytes (512 bits): PRF2("", "client EAP encryption", client_hello.random || server_hello.random) How is this keying material transported from authentication server to NAS? Attributes are provided in RFC 2548: MS-MPPE-Recv-Key: Corresponds to first 32 bytes of PRF1. This is known in IEEE 802.11i as the "Pairwise Master Key". MS-MPPE-Send-Key: Corresponds to second 32 bytes of PRF1. So, out of the total of 192 bytes of keying material generated by EAP TLS (and passed across via the interface from the EAP method to the EAP layer), the RFC 2548 RADIUS attributes only transport 64 bytes (512 bits) from the authentication server to the NAS. Why only 64 bytes, not 192? These attributes were created for use with MPPE, which only needed 64 bytes. That's still quite a bit (512 bits), and at least so far, it has been enough. How would you go about creating a key hierarchy for a new ciphersuite? Carefully, very carefully. RFC 2716 provides some general guidance on construction of a ciphersuite-specific key hierarchy: Use the First 32 bytes of PRF1 be used for the Peer to NAS Encryption Key. Use the Second 32 bytes of PRF1 be used for the NAS to Peer Encryption Key. Use the Third 32 bytes of PRF1 be used for the Peer to NAS authentication key. Use the Fourth 32 bytes of PRF1 be used for the NAS to Peer authentication key. Use the First 32 bytes of PRF2 be used for the Peer to NAS initialization vector (if necessary) Use the Second 32 bytes of PRF2 be used for the NAS to Peer initialization vector (if necessary) Of course, to take this advice, the NAS would actually need to obtain the third and fourth 32 bytes of PRF1, as well as the first and second 32 bytes of PRF2. So you'd need to define a separate set of RADIUS attributes for this purpose. This is needed anyway -- because RFC 2548 has a security weakness. You see, the keying attributes are encrypted using a stream cipher derived from MD5 (not HMAC-MD5) and the Salt is placed at the end. That means that if the MD5 keystream is compromised due to a plaintext attack on other hidden RADIUS attributes such as User-Password -- the Salt does no good at all, since it is sent in the clear and put at the end of the MD5 computation. That means that the compromised key stream can be extended by using the salt -- and so no protection is afforded by it. Oops! NIST has recently taken an interest in the "key wrap" issue -- and the security problems of RFC 2548. So, assuming that we can get enough cryptographic help in preparing new attributes, then perhaps a standard set of RADIUS keying attributes will be included in RFC 2869bis. How is master session key generated? It's unique for every EAP method. In many methods the "master key" is not directly accessible. Examples: TLS (RFC 2246), GSS-API. The APIs are not available for security reasons. In any case, you would not want to send the master key across the wire from authentication server to NAS. Instead, the Master Session key is derived via a one-way function from the master key. That way, the NAS cannot impersonate the authentication server -- because it doesn't possess the master key. In other words, there is cryptographic separation between 'fast reconnect' authentication and subsequent keys used for encryption and authentication of data. This is what you want. Pitfalls for the unwary Arbitrary AAA EAP key attributes -- the attributes define the keying primitives between the EAP method and the EAP layer, so a standard way of doing this is needed. Every vendor can't create their own keying attributes. The NAS expects an MSK, *not* session key! Sending a session key encourages ciphersuite-specific EAP methods - bad idea! Improper key hierarchies Key hierarchies that loop Key hierarchies that don't match the attributes sent to the NAS Insufficient entropy IEEE 802.11i assumes a 256-bit PMK. This was an issue for EAP GSS -- the PMK entropy is dependent on the GSS-API method negotiated. GSS_WRAP() may not generate the required entropy in all cases. Lack of nonce exchanges The TLS and IKE key derivation formulas both include client and server nonces. This ensures that the master session key will not repeat, even of the master key does. It works even if one side of the exchange cannot easily generate much randomness, as is the case in access points which may only boot with minimal entropy. Note that 802.11i now includes a nonce exchange in its "four way handshake" -- so that if a method is *only* used with 802.11i then it need not include a nonce exchange. Is this a wise assumption to make? Probably not -- what if you want to reuse the method with another link layer without a four way handshake. In general it is best if EAP methods are media agnostic. So put in the nonce exchange! This was missing in EAP SRP, as well as EAP GSS, for example. Summary Secure key derivation is important. EAP keys are used to "bind" authentication to subsequent link layer data encryption and authentication, and even other methods and tunnels (binding problem). Based on reading EAP methods, EAP key derivation concepts are not well understood. Have to read too many documents to understand how it works. Existing methods show large variation in practices -- and a signficant number of weaknesses. The Goal of the EAP Keying Framework document is to make things clearer. Status of the draft Still an individual submission. Needs significant additions to be ready is a WG work item: Section on EAP keying primitives (or does this belong in the state machine doc?) Reference to key attribute RFCs (RFC 2548, Diameter EAP, new RADIUS key attributes draft?) Section summarizing master session key derivation behavior of existing methods (e.g. EAP TLS). Section on example key hierarchies. "Key lifecycle" -- Better overview on how keys are generated, transported and used. (see below). EAP security claims - Glen Zorn The idea of this draft is to allow EAP method specifications to describe the security claims they are making in a standard way -- so that users requiring capabilities can match their requirements to the method claims. To accomplish this, we will need to define security claims within RFC 2284bis (and possibly within IEEE 802.11i), and then use the same terms, with the same meanings, in EAP method specifications. Proof of claims is encouraged (preferrably in an Appendix). Comment: This seems like a reasonable idea. Could make things clearer. Method presentations EAP GSS - Bernard Aboba Intended track: Experimental Goal was integrated network/Kerberos login. Depends on IAKERB GSS-API mechanism. It was developed for IEEE 802 and PPP media primarily. Kerberos user tickets are vulnerable to dictionary attack on wireless networks. Machine authentication is better because keys are random quantities -- harder to attack. But with keys based on passwords, Kerberos AS_REQ (with pre-auth data) and AS_REP are vulnerable. Attacks analyzed by Thomas Wu. Another problem was that master secrets are not available via a GSS-API call (this is a security vulnerability). So GSS_WRAP() has to be used to generate them -- but the entropy varies based on the GSS-API method that is negotiated. So we cannot say for certain that the IEEE 802.11i needs (256 bit PMK with at least 128-bits of entropy) has been met. Security claims: Mechanism: passwords or certs typically, but could be anything supported by GSS-API Mutual auth: Typically, yes. Key derivation: Typically, yes -- via GSS_WRAP(). Key size: depends on GSS-API method. Key hierarchy: Description of MSK generation included (and nonces added) Dictionary attack resistance: If used with Kerberos PKINIT, but not with Kerb V Identity hiding: Depends on GSS-API method, but generally not. Protection: Method negotiation: Yes (SPNEGO) Link layer Ciphersuite negotiation: No Success/Failure indication: No Method packets: Yes Fast reconnect: Yes (but only if NASen share keys) Issues: Where does the exchange end? With AS_REQ/AS_REP? With TGT_REQ/TGT_REP? With AP_REQ/AP_REP? Was decided to do last exchange outside EAP (in EAPOL-Key frames) Security: Method was removed from IEEE 802.11i because (among other things) it was vulnerable to dictionary attack. Keying: "Pseudo Master Key" had to be derived from GSS_WRAP () calls, since master key isn't available directly. Pseudo Master Key was then fed into the EAP TLS MSK generation formula, along with nonces added to the protocol. So had to adapt the existing EAP TLS formula, not entirely natural for GSS-API. EAP architecture: Method is difficult to fit within the EAP architecture since it transports keys from Peer to NAS (outside of EAP), and therefore requires the NAS to be EAP-aware. The NAS can talk to KDC either directly (NAS terminates EAP GSS and talks to KDC directly) or through the AAA Server (NAS passes through EAP GSS and lets AAA server talk to KDC). EAP AKA - Henry Haverinen Intended track: Informational EAP AKA is the USIM authentication solution for 3GPP WLAN internetworking (TS 23.234). Deadline for this is June 2003. Intended media is 802.11 and other wireless LAN standards. EAP AKA Security claims Mechanism: symmetric secret keys distributed on UICC cards with USIM application, UMTS f1…f5 algorithms Mutual authentication Key derivation supported 128-bit keys Key hierarchy described in the draft Not vulnerable to dictionary attacks Identity privacy with pseudonyms, identity string integrity protected Because EAP AKA is not a tunnelling method, it does not protect EAP method negotiation, EAP notifications, EAP success, EAP failure No ciphersuite negotiation EAP AKA packets integrity protected, some parts are encrypted Fast reconnect supported (called “re-authentication” in EAP AKA) EAP SIM - Henry Haverinen Intended track: Informational The GSM SIM authentication mechanism for 3GPP WLAN (TS 23.234). Deadline for this is June 2003. Intended media is 802.11 and other wireless LAN standards. EAP SIM Security Claims IPR Claim has been filed by Nokia with IETF secretariat, see IPR web page. Mechanism: symmetric secret keys distributed on GSM SIM cards, GSM A3 and A8 algorithms Mutual authentication Key derivation supported 128-bit keys If the same SIM is used in GSM and GPRS, then effective key length may be reduced to 64 bits with attacks over GSM/GPRS Key hierarchy described in the draft Not vulnerable to dictionary attacks Identity privacy with pseudonyms, identity string integrity protected Because EAP SIM is not a tunnelling method, it does not protect EAP method negotiation, EAP notifications, EAP success, EAP failure No ciphersuite negotiation EAP SIM packets integrity protected, some parts are encrypted Fast reconnect supported (called “re-authentication” in EAP SIM) EAP Smartcard - Pascal Urien Draft describes APIs for EAP authentication on a smartcard. This includes Get-Next-Identity, Set-Identity, Get-Pairwise-Master-Key (PMK). Smartcards now have EAP TLS, SIM built-in. So EAP is terminated on the smartcard. Functionality can be extended using the API. Adjourned.