2.3.3 Extensible Authentication Protocol (eap)

NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-02-06

Bernard Aboba <aboba@internaut.com>
Jari Arkko <Jari.Arkko@ericsson.com>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <margaret@thingmagic.com>
Internet Area Advisor:
Margaret Wasserman <margaret@thingmagic.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
Done  RFC 2284bis submitted for publication as a Proposed Standard
  • - draft-ietf-eap-rfc2284bis-09.txt
  • - draft-ietf-eap-statemachine-02.txt
  • - draft-ietf-eap-keying-01.txt
  • - draft-ietf-eap-netsel-problem-00.txt
  • No Request For Comments

    Current Meeting Report

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


    Document Status
    EAP State Machines
    EAP Key Management Framework
    Compound Authentication Binding Problem
    Network Selection
    EAP-based Mediating Network Selection
    Methods Update
    EAP Bluetooth Extension
    EAP-PSK: a simple symmetric key EAP method
    Extension for EAP Authentication in IKEv2
    802.1X/EAP Ad-Hoc Interoperability Test Event
    EAP-SIM open source implementation status