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.