2.3.3 Extensible Authentication Protocol (eap)

Last Modified: 2003-08-11

Bernard Aboba <aboba@internaut.com>
Jari Arkko <Jari.Arkko@ericsson.com>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <mrw@windriver.com>
Internet Area Advisor:
Margaret Wasserman <mrw@windriver.com>
Technical Advisor(s):
William Arbaugh <waa@dsl.cis.upenn.edu>
Mailing Lists:
General Discussion: eap@frascone.com
To Subscribe: eap-request@frascone.com
In Body: subscribe in Subject line
Archive: http://mail.frascone.com/pipermail/eap/
Description of Working Group:
The EAP working group will restrict itself to the following work items
in order to fully document and improve the interoperability of the
existing EAP protocol:

1. IANA considerations for EAP.
2. Type space extension to support an expanded Type space.
3. EAP usage model.
4. Threat model and security requirements.
5. EAP state machine.
6. Documentation of interaction between EAP and other layers.
7. Resolution of interoperability issues.
8. EAP keying problem description and requirements.

Items 1-7 are intended to be covered within RFC 2284bis, the
revision to the EAP specification. Item 8 will be covered within
a separate document

The EAP WG is not currently chartered to review or standardize EAP
methods. However, when these work items are completed, the WG may be
rechartered, or a new WG may be formed to evaluate proposed methods.
Goals and Milestones:
Jun 03  EAP Keying Problem document submitted for publication as an Informational RFC
Aug 03  RFC 2284bis submitted for publication as a Proposed Standard
  • - draft-ietf-eap-otp-00.txt
  • - draft-ietf-eap-esteem-01.txt
  • - draft-ietf-eap-rfc2284bis-04.txt
  • No Request For Comments

    Current Meeting Report

    Meeting Minutes of the EAP WG at IETF #57
    LOCATION: Vienna Austria DATE: July 2003 SLIDES: 
    http://www.drizzle.com/~aboba/EAP/ NOTES: Dirk Kroeselberg, John 
    Vollbrecht, and Henrik Levkowetz (edited by Jari Arkko)
    o Preliminaries (Jari Arkko)
     - Bluesheets - Agenda Bash
     No comments on the agenda.
    o Document Status (Jari Arkko)
     - Base spec finished second last call with 4 open issues left, one of them 
     Glenn asked about the 3 issues left for 2284bis(?), and said he'd found 3 
    editorial issues already on the first page. The chairs requested Glenn to 
    report the issues he found.
     - 2869bis approved by IESG, however some issues were found 
    afterwards with 802.11i.
     - State machine to become WG item.
     - Binding problem according to the authors has no open issues left after 
    list discussion.
     - Methods need expert review, can be informational or standard, but 
    cannot progress before base docs are done.
    o EAP RADIUS - RFC 2869bis update, Bernard Aboba
     - Bernard talked about the 2869bis status. It has been approved for 
    publication as an RFC. But two issues were raised afterwards, the 
    intention is to discuss these and fix the document in author's 48 hours. The 
    proposed fixes were
     (1) Order of attribute processing #157: Proposal to resolve by adding some 
    correctional text. Jesse Walker: Agreed. Pasi Eronen: Order change is 
    fine, but not sure whether this should be in 2869bis, because the order can 
    be different for different link layers. Bernard Aboba: This is an EAP 
    problem, because the order affects the operation of the protocol.
     (2) Identity privacy. Proposed Change:  $B!H (Bthe user-name 
    attribute within the access-accept packet need not be the same as the 
    user-name attribute in the access-request $B!I (B) John Vollbrecht: 
    thinks the user-name content has to be the same.
     Jari Arkko: Its unclear, who are we trying to protect. The AAA server does 
    send ID of the user to the NAS anyway. Bernard Aboba: It is not only the 
    identity of the user, but whatever is in the accounting message.
     Decision: Issues taken to the list for further discussion.
    o EAP Base - RFC 2284bis, Henrik Levkowetz
     - Remaining issues are 150, 151, 152, and 160.
     - Issue 150: lower-layer behaviour for limited access: Put to the list, as 
    this needs more discussion
     - Issue 152: Lower layer indications: Text in 3.4 is not aligned with 
    state machine draft. Clarified by Pasi Eronen: If you loose success 
    packet, you can count on lower layers success indication. State machine 
    does this  $B!H (Balways $B!I (B, EAP spec only allows this for methods 
    with success acknowledgement.
     Bernard Aboba: following a survey, no one did implement this. So it is no 
     John Vollbrecht: State machine approach the is better approach
     Jari Arkko and Pasi Eronen: The practical impact is a long timeout if you do 
    it as EAP specifies
     Bernard Aboba: The major impact is for PPP.
     Pasi Eronen: In WLAN there is a higher possibility of loosing the 
    success packet, so this is affected as well.
     Bernard Aboba: Why would a mutually authenticated method not have 
    success indication. This would be basically saying the client is happy when 
    he authenticates the server.
     Pasi Eronen: But the server sends a link-layer success.
     John Vollbrecht: It may have been one of the major design flaws in EAP 
    that both sides do not really know whether it succeeded
     Decision: The issue needs to be looked at in detail on the list.
     - Issue 160: Network selection assistance.
     EAP identity request, type field MUST not be null terminated 
    according to spec. Some implementations embed a null octet to separate the 
    message into a displayable and a non-displayable part.
     Glen Zorn: Not sure what the proposed solution is. Must be 
    backwards-compatible. It is inappropriate to provide guidance on this.
     Someone: Need something, but it does not matter how this is done. Could be 
    done as in the past with the null string.
     Zorn: The issue is at least 2 layers above EAP, not to be solved here.
     Conclusion: Discussion moved to the list?
    o EAP State Machine, Pasi Eronen
     - Pasi Eronen spoke about the state of the EAP state machine draft. 
    Significant progress has been made since the previous IETF, and a 
    pre-alpha implementation by Yoshihiro Ohba.
     . Data flows are now shown in the diagram
     . Packets that should not occur are silently discarded.
     . Etc
     - Version 03 of the draft is incorporated in IEEE P802.1aa draft 6.1 
     - Discussion on the  $B!H (Bpass-through & backend $B!I (B slide. 
    Bernard Aboba: I don't understand what the passthrough method does - it 
    confuses the AAA action and the lower layer interfaces. There used to be a 
    AAA layer in there, but now it is gone. That is the flaw. Glenn Zorn: The 
    state machine has to look the same whether there is AAA or not. Pasi 
    Eronen: Then I'd split the authenticator and back-end state machines, so 
    that we can show how one gets the same result whether one uses a backend or 
    not. First we specified one authentication diagram. Then did two 
    separate, one for passthrough, one for back end. Bernard Aboba: AAA 
    client has to be there: It is a pass-through until the last EAP 
    message. Pasi Eronen: That is already reflected in the current draft, but 
    not in a very elegant way.
     - Farid Adrangi: State which parts have to be implemented and which not? 
    Pasi Eronen: The whole doc is informative, the specs are 2284bis and 
    2869bis. There are some cases where 2284bis says should but state 
    machine does not cover the alternative. Therefore it has to stay 
    informative. Future work may happen on EAP for tunnelled methods.
     In case there is a disagreement, 2284bis will be the normative 
     - Jari Arkko: Will this become WG doc? There are still issues, so fix 
    them, issue a new version and then make it WG doc. Bernard Aboba: How many 
    read the draft? Result: About 3-4. All want to make it WG item. 
    Decision: this will become a WG item.
    o Network Selection, Farid Adrangi
     - Farid Adrangi held a presentation on network selection in EAP. This 
    draft is related to some potential requirements from 3GPP on EAP.
     Visited networks have different agreements with home; user
     1) wants to be provided with a list of available visited networks 2) 
    should be able to specify the VN
     Focus here on the first question. Presentation proposal: Open work item in 
    EAP to analyse present requirements in an attempt to convey 
    information (through EAP) to the UE for network selection.
     - Glenn Zorn: What is the use of this? Why would the client want to 
    choose network?
     - Farid Adrangi: Because the different networks may have different 
    services or costs. Glenn Zorn: Why can't you first authenticate, and then 
    use some other protocol to choose? Farid Adrangi: It can cost to 
     - Glenn Zorn: Again, cannot this pre pre-configured, 
    automatically updated? Farid Adrangi: The number of operator can be in the 
    100's, there is a scalability issue with Glenn's proposed method
     - Someone: This is not really a thing for EAP, you are looking for a 
    service discovery method.
     - Glenn: Could you describe the difference between a service and a 
    network providing a service? Farid Adrangi: Trying to find a way to 
    select what network should route the packages.
     - Jari Arkko: Talk to the interested people to figure out what the right 
    protocol for network selection is, and then submit a draft to that WG.
    o EAP SIM & AKA P. Eronen
     - Pasi Eronen did a presentation on EAP SIM and AKA. The documents are 
    quite stable now. They has been aligned with the key derivation as per 
     - EAP-SIM: Recent clarification added related to the security analysis 
    (see below). When multiple RAND values are used, check that they are 
    different. Clarified security considerations.
     - EAP-AKA has relatively similar changes.
     - Next steps: Get reviews, wait until 2284bis is finished. Proposal to 
    publish method as informational
    o EAP-SIM Security Analysis, Uri Blumenthal
     - Uri Blumenthal presented the security analysis of EAP SIM.
     - There are some keyspace and mutual authentication weaknesses of 
    EAP-SIM compared to what the specification currently says.
     - EAP SIM claims to enhance the security to 128bits, mutually 
    authenticated with independent sessions. The analysis shows the 
    possibility of two 64-bit attacks, and disproves session 
     - Glen Zorn: Is that an EAP-SIM or a GSM issue? Uri Blumenthal: The 
    presentation just addresses the claims made in the EAP-SIM spec.
     - Bernard Aboba: Is the request, that lack of session independence 
    should be added to the security considerations? Uri Blumenthal: yes.
    EAP-SIM Analysis response, Pasi Eronen
     - Pasi Responded as follows:
     1) The text in the draft on key strength is somewhat different from what 
    the Security Analysis addresses as claim (see slides).
     2) There's a difference between an attack with probability 2^-64, and an 
    attack which requires work of 2 to the 64 (and give an attack 
    probability of 1)
     3) The current document strongly recomments using 2 or 3 triplets, 
    giving ~128 bit strength, rather than 1 triplet (giving ~64).
     In the newest version, text has been added to the latest draft that both 
    client and server must use at least 2 triplets.
     EAP-SIM requires that the server always uses fresh RANDs, but the client 
    cannot check (i.e. store). This is extensively discussed in security 
     4) The SIM used for authentication SHOULD NOT be used in GSM, because then 
    attacks can be done on that network which has weaknesses not present in EAP 
     5) There is no need to use SRES to increase key strength.
     - Jari Arkko: The conclusion is that methods need security review -- 
    would be interesting with a similar analysis of AKA, for instance. It is 
    essential that we agree what the security properties of the methods are 
    (but users of EAP may have different opinions on what properties they 
     We may also need additional requirements in 2284bis about session 
    o Report of the 802.1x ad-hoc interop test event (Karen O'Donoghue)
     - This event took place April 7-9, 2003 in Belmont, CA. Goal was to gain 
    insight into status of products, to improve state of 802.1X 
    interoperability, and to provide feedback to standards groups.
     - Issues identified were:
     . Specification interpretation issues. . Re-authentication, non-EAP 
    agnostic authenticators (EAP type support, negotiation). . Inner auth 
    methods (PEAP, TTLS), Wireless VLANs (no standards) . Bugs, bugs... . 
    Administrative issue: Certificates are hard. Setting up took up a day, so 
    prepare for more time next time.
     - Most of the problems were operational and implementation related. They 
    may have been a few issues related to the clarity of of 
    specifications, and Karen will send more information later on those.
     - InteropNet Labs is planning interop for next year. Test-suites are 
    developed by the University of New Hampshire.
    o EAP Keying Framework (Bernard Aboba)
     - Goal is to provide framework for evaluation of EAP key derivation 
    mechanisms and transport mechanisms. EAP invariants are 
    Media/Ciphersuite/Method independence.
     There are different relevant phases:
     0) Discovery phase; discover authenticator (out-of-band for EAP): Phase 0. 
    It is not secure.
     1) EAP is Phase 1 between EAP peer and server. EAP SAs are 
    bi-directional, Mutual authentication is required for key-deriving 
    methods. Method provides keys (MSK, EMSK). EAP only supports key 
    creation, no deletion.
     Running this phase does not mean that client want to connect at that time - 
    preauthentication SA may be bidirectional.
     2) SA Protocol (Phase 2): Used by EAP peer to derive SA with the EAP 
    authenticator to protect data. Demonstrates 
    "proof-of-possession " of phase 1 SA (key binding).
     - Jesse Walker: Are we going to discuss key/SA lifetime issue? Bernard 
    Aboba: Currently no lifetime negotiated. There is the lifetime of EAP, or 
    data, SA. EAP SA lifetime not relevant. Data SA lifetime should be done by 
    Data SA protocol. This should still be discussed at some point.
     Jesse Walker: Usually its time, but often with cryptographic devices it is 
    also other things, such as usage of a key for a large amount of data. 
    Bernard Aboba: There are two lifetimes, the phase 1 and phase 2. it is 
    conceivable that phase 1 could be used too many times, to cause 
    sequence number overflow or something. Jesse Walker: I don't think we need to 
    worry about that but the data key lifetime is relevant.
     - Why is binding/naming important? EAP and SA protocol may not run 
    between same parties. EAP key name required to identify SAs. A link that the 
    EAP runs on may have multiple authentications so need a name to be sure 
    know which authentication to base a secure association on.
     - James Kempf: Is it the name of the key or the SA? Bernard Aboba: in this 
    case it is the name of the key.
     - Lauri Tarkkala: Why not just refer to the latest key? If eap does not 
    have a delete mechanism, why bother with the naming. As EAP does not 
    delete keys, what is the policy how many keys are cached? 
    Implementation specific logic required, but this may lead to 
    interoperability issues.
     Bernard Aboba: Depends on the implementation or the load of the 
    affected device. No specification required here. For instance, how busy the 
    AP is could affect whether phase 1 can be cached for a day or 5 
    minutes. Lauri Tarkkala: I can agree with you reasoning, but it creates 
    application specific reasoning. in ikev1 this has caused problems. 
    Bernard Aboba: post the issue to the list so we can track this.
     - Bernard Aboba: EAP is a peer-to-peer protocol, but: AAA may not 
    support role reversal; EAP methods may be client/server.
     - Open issues:
     . Issue 15: missing security requirements. Proposal: add material to 
    address this in -07 draft
     . Issue 47: Key requirements unspecified (size of MSK/EMSK). 
    Proposal: add nonce exchange requirement.
     The proposals or 15 and 47 were accepted.
     . Issue 99: Double expansion: occurs from MK to MSK and MSK to TSK: 
    Proposal: reject, key strength is the issue, not double expansion.
     Jesse Walker: it is, there are papers. Bernard: please post 
     . Issue 119: EAP is inappropriate for peer-to-peer. Proposal: reject.
     Jari Arkko: This may belong to RFC 2284bis.
     Jesse Walker: Not enough implementation experience that people really know 
    about 119. Bernard Aboba: TLS methods are client-server, as they need 
    different credentials on both sides. However, the best thing to find out is 
    to try.
     . Issue 135: include SSID in PRF: Proposal: Reject (EAP is media 
    independent, SSID does not exist on all media. During 
    pre-authentication, SSID may not be available. There are issues for 
    virtual APs).
     Alper Yegin: Other counterexamples are PANA and IKEv2.
     Lauri Tarkkala: SSID is too 802.1x-specific.
     Jari Arkko: Don't think there is a practical problem here. Jari: What 
    about authorization? AP has to figure out which Phase 1 SAs it can use for 
    which SSIDs. Isn't this an authorization problem?
     Jesse Walker: The real question is if MSK can be given to more than one 
    NAS. If yes, don't care about the SSID. If no, Sometimes the 
    information has to be given to the client that these are all the same 
    thing so the MSK "compromise" is.
     Pat Calhoun: I ship a product that does this. Most clients get 
    confused on multiple SSIDs, need to use virtual APs. I don't think we 
    should share MSKs or move between virtual APs.
     - Bernard Aboba: I'll continue with updating 07 doc, resolve open 
     - Discussion continued about Russ Housley's requirements for key 
    derivation presented at last IETF:
     . Key naming: Proposal for appropriate naming of EAP-SA, MK, MSK, EMSK, 
    TSK. Issue: How do the NAS, EAP peer and AAA server come to agree on the key 
    names? (NAS operates in pass-through, does not have access to MK or EMSK. 
    Solution: AAA server needs to transmit this.
     . Comment: Discussion on this should be made part of the 2284bis Jari 
    Arkko: Better to keep separate in the informational keying framework doc. 
    Bernard Aboba: One document is standards track, the other is 
     . Alper Yegin: Where does the peer obtain the call-station-ID from? 
    Bernard Aboba: usually lower layer; in the case of PANA this might be the IP 
     . Someone: why is this keying framework informational? Bernard Aboba: 
    there is a lot of informational stuff in the keying framework.
     . Jari Arkko: The mandatory parts will go in 2284bis in the end.
    o EAP Key Derivation for Multiple Applications, H. Zhou
     - The idea of this draft is that multiple applications can be keyed from 
    same MSK (protected-TLV, DHCP, PANA, fast roaming). Derive AMSK 
    (application master keys) from EMSK.
     - Open issues: . KDF refinement . AAA attributes to request and deliver 
    keys . Integration with key naming
    o Use of EAP Keying for DHCP Bootstrap (Hannes Tschofenig)
     - Draft addresses EAP keying (derivation, distribution of MSK, derive PANA 
    key). Key derivation for DHCP is based on PANA. There is a relation to "EAP 
    Key Derivation for Multiple Applications" work.
     - Jari Arkko: What makes DHCP special, there are a lot of other things to be 
    done for network access?
     - Hannes Tschofenig: network entities are different here.
     - Alper Yegin: Work is primarily for DHCP WG. An out-of-band key 
    derivation scheme is missing. This is not meant to solve all the network 
    access problems.
     - James Kempf: Why is PANA used here, couldn't we just use 802.1x or 
    something that is there?
     - Hannes Tschofenig: PANA required; provides an additional set of 
    nonces. Carries additional parameters required to establish SA with DHCP 
    server. 802.1x does not allow this.
     - Kempf: One could extend 802.1x. Alper Yegin: Yes.
     - Result: Discussion taken offline.
    o EAP Compound Binding (Farid Adranghi)
     - Issues addressed in new version:
     . #64: Problem statement addressed in new version.
     . #65: Downgrading attack: Current draft now explains this.
     . #70: Which PRFs should be used? draft now says should be based on what 
    tunnelling protocol is used.
     . #88: Why tunnel keys are used? use keys of the inner methods? not 
    changed, tunnel keys are stronger.
     . #89: Review of version 1 draft now addressed.
     . #123: Non-key generating methods and binding: now addressed in 3.2.
     - Process for the doc: Submit for final crypto review, resolve new 
     - Farid: Time is of essence, should become WG doc soon.
     - Jari Arkko: former reviewers still need time to check their issues
    o EAP Client Side Transport (Florent Bersani)
     - Presentation just gives a concept, does not really fit in the WG right 
    now. Splits EAP endpoints in AuthToken (peer side) and AuthServer for 
    authentication; integrity/encryption runs between client (peer) and 
    server. Idea is separating authentication and service used later on. 
    Approach motivated by smartcards / security tokens.
     - Separate authentication from service carrying authentication. Don't need 
    to support smart cards inside device, e.g. can authenticate with Smart card 
    on phone to use notebook/pc talks about tokens rather than client 
    o EAP Archie (Jesse Walker)
     - Some Changes in -01 version: . Altered to use only one crypto 
    primitive . Bindings changed to use define numbers address family
     - No further changes planned. Will only evolve in response to Bugs, 
    suggestions to simplify.
     - Uri Blumenthal and Jesse Walker designing new Archie-like protocol 
    (based on Archie and SKE).
     - John Vollbrecht: Make it either a straight or a tunnelled protocol? 
    Jesse: No technical reasons against this, depends on the group's 
    o EAP IKEv2 ( Hannes Tschofenig)
     - Idea is to reuse good crypto and flexibility of IKEv2 as EAP method. 
    Inherits IKEv2 security properties, including DoS protection. Does not 
    exchange IPsec SA payloads.
     - Next steps: Incorporate comments already received, address key 
    derivation and naming according to the current discussion. Stable 
    version for the next IETF.
     - Open issues are sequencing of EAP methods, secure address 
    configuration, protection of outer EAP methods (needed?).
    o EAP LDAP, Avi Lior
     - EAP-LDAP is a challenge-based authentication using MD5, in 
    conjunction with the encryption algorithm used to store the password 
    within the LDAP identity store. Recommended to use in conjunction with 
    tunneled methods. Could be extended to any other data store. Idea is to 
    allow validation without passing password in clear. Draft requested to be WG 
     - Uri Blumenthal: But the cryptographic attack is the same for this as for 
    MD5, you just do an extra step, but a dictionary attack is still 
     - Discussion: Comments moved to the list.
    o PEAP Version 2 (J. Salowey/A. Palekar) (Hao Zhou)
     - New draft addresses compound binding problem. Clarifications for 
    implementors. Supports sequencing of methods in PEAP tunnel.
     - Lauri Tarkkala: Microsoft has IPR statement regarding PEAP. Does this 
    apply to the new draft? They have stated there is nothing on the new 
    draft? Zhou: cannot tell, not with MS.
     - Bernard Aboba: Why compound MAC and compound key are both done for 
    binding? IKEv2 did only one of them? Zhou: Authors felt compound key does 
    better security; did both however.
    o EAP Support in Smartcard, P. Urien
     - Defines universal ISO 7816 interface; EAP-application on 
    smartcard, that may be associated with different EAP-types. Supports lots of 
    services and EAP SIM is supported, others under discussion.
     - Current Interfaces are network / OS+terminal / 
    management+personalization / user. EAP-SSC (secure smartcard channel): uses 
    single EAP type, defines symmetric or asymmetric key exchange 
     - Future work: Rand number format rules for asymmetric case; message 
    ciphering support.


    EAP SIM and AKA
    EAP State Machines
    PEAP Version 2
    RFC 2869bis Issues
    Changes to Archie in rev 01
    EAP Keying Framework
    EAP Secured Smartcard Channel
    EAP support in smartcards
    Network Advertisement Requirements
    Analysis of EAP-SIM Session Key Agreement
    EAP Client- side Transport
    EAP-SIM Security Analysis