2.3.3 Extensible Authentication Protocol (eap)

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-10-24

Chair(s):
Bernard Aboba <aboba@internaut.com>
Jari Arkko <Jari.Arkko@ericsson.com>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <margaret.wasserman@nokia.com>
Internet Area Advisor:
Margaret Wasserman <margaret.wasserman@nokia.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
Internet-Drafts:
  • - draft-ietf-eap-rfc2284bis-06.txt
  • - draft-ietf-eap-statemachine-01.txt
  • - draft-ietf-eap-keying-01.txt
  • No Request For Comments

    Current Meeting Report

    Minutes of the Extensible Authentication Protocol (eap) WG at IETF-58
    
    
    Time: Monday, November 10, 2003 at 1930-2200
    
    
    Chairs: Bernard Aboba <aboba@internaut.com>
            Jari Arkko <Jari.Arkko@ericsson.com>
    
    
    Minutes: Dirk Kroeselberg (Dirk.kroeselberg@web.de)
             Henrik Levkowetz (henrik@levkowetz.com)
             Edited by Jari Arkko (jarkko@piuha.net)
    
    
    URLs: Issue Status: 
    http://www.drizzle.com/~aboba/EAP/eapissues.html
          Presentations: 
    http://www.drizzle.com/~aboba/IETF58/EAP.zip
    
    
    Preliminaries
    =============
    
    
     - Agenda Bashing. No comments on the agenda.
    
    
     - Bluesheets going around and note takers assigned.
    
    
     - Document Status. Jari summarized the document status:
       
       o EAP base spec passed WG last call, is in IETF last call.
    
    
       o EAP state machine (informational) is in WG last call.
    
    
       o EAP keying framework has been adopted as WG document. There is still a 
    number of open issues, needs more work than the other docs.
    
    
       o EAP over Radius (2289bis) approved, now RFC 3579.
    
    
       o Method documents: Approval of methods needs to wait for 
    completion of base EAP specifications.  Currently not in EAP WG charter to 
    work on methods. Future methods might be specified either as 
    individual submissions, Informational documents outside the WG or as 
    chartered EAP WG work
    
    
    WG Work Items -- RFC 2284bis, Henrik Levkowetz
    
    ==============================================
    
    
     - 
    http://www.levkowetz.com/pub/ietf/draft
    s/eap/rfc2284bis/draf
    t-ietf-eap-rfc2284bis-07.d.html
    
    
     - 3rd last call on the document was held in September. There are two open 
    issues left:
    
    
       1) Handling of Identity response
       2) Editorial comments by J. Puthenkulam
     
       Margaret missed her editorial comments among the open issues, but these 
    were already fixed.
    
    
       No other questions.
    
    
    WG Work Items -- EAP State Machine, Pasi Eronen
    
    ===============================================
    
    
     - 
    http://www.ietf.org/internet-drafts/dra
    ft-ietf-eap-statemachine-01.pdf
     - 
    http://www.ietf.org/internet-drafts/dra
    ft-ietf-eap-statemachine-01.txt
    
    
     - Now in WG last call. Next steps: Handle issues from last call, and 
    publish as informational.
    
    
     - Draft describes state machine for EAP peer and EAP 
    authenticator. No changes on peer side since IETF-57.
    
    
     - The approach for the authenticator now is changed, due to comments on AAA 
    interaction: three state machines:
    
    
       o Standalone (no pass-through or AAA)
    
    
       o Backend (Interfaces to AAA module (RFC3579, Diameter), EAP 
    methods).
    
    
       o Full authenticator (Interfaces to lower layer (matching 
    802.1X-REV), EAP methods, AAA module)
    
    
     - Discussion: 
    
    
       o Bernard: What is the difference for handling tunneled methods 
    (tunneled variable)?  Pasi Eronen: If you are not inside the tunnel, you are 
    not allowed to do multiple authentication  methods. Complicated, 
    tunneled-variable will be taken out. Joe: Makes me somewhat nervous to have 
    that in there.  Bernard: For now, should be in there to stimulate 
    discussion.
    
    
       o I'd also like to say that the quality is very good, and thank the 
    authors, and tell people to set aside 4+4 hours and go and read it.
    
    
    WG Work Items -- EAP Key Framework, Bernard Aboba
    
    =================================================
    
    
     - 
    http://www.ietf.org/internet-drafts/dra
    ft-ietf-eap-keying-01.txt
    
    
     - Normative statements relating to EAP moved to RFC2284bis. As a 
    result, EAP methods no longer depend on keying framework. 
    Substantial revisions are in progress, currently the draft lacks a threat 
    model.
    
    
     - Open issues:
    
    
       o 15 (key distr. Insecure),
       o 179 (EAP PRF), and
       o 187 (Service SAs).
    
    
     - Security issues are:
    
    
       o Key scoping: AAA protocols authenticate at NAS granularity Client may 
    not be able to recognize NAS scope without assistance from the lower 
    layer. Possible solutions:
    
    
         . AAA agent checks
         . Logging
         . Key Mixing
         . Method-specific binding
    
    
       o Correctness in fast handoff & context transfer
    
    
       o Lying NAS Problem
    
    
     - There were no questions.
    
    
    
    Related Work -- Network Discovery and Selection, Farid Adrangi & Pasi 
    Eronen
    
    ========================================
    ====================================
    
    
     - 
    http://www.ietf.org/internet-drafts/dra
    ft-adrangi-eap-networ
    k-discovery-and-selection-00.txt
    
    
     - Discussion scoping by Jari: there's been previous question marks on 
    whether this functionality is needed. Since feedback is required from 
    other organizations, and we don't have much time for discussion in the 
    meeting, we will assume that network selection is needed. Lets use the 
    meeting time to discuss what alternatives we have for providing this 
    feature.
    
    
     - Problem: Even if you select an AP (based on e.g. SSID) you haven't 
    selected a mediating network which will carry your traffic back to your 
    home network
    
    
     - Farid presented examples of mediating networks, such as iPass, 
    3GPP-VPLMN, GRIC.  Home service network is e.g. wireless provider. Access 
    networks are public hotspot.  Problem is not AP selection in hotspot. 
    EAP-based client needs information on which home network /mediating 
    networks are affiliated to the access network.  The proposed solution 
    complies with the EAP spec and uses EAP-Identity Requests to deliver 
    network information.
    
    
     - Proposed solution is to use a "decorated NAI" inside the Identity 
    Response, on first or subsequent Identity Request. Identity Request may 
    carry information about the network which makes it possible for the peer to 
    select an appropriate NAI (if more than one is available).
    
    
     - There is a 3GPP dependency for this work (3GPP TSG CN).
    
    
     - Related presentation by Pasi Eronen: Based on a discussion between 
    Jari, Bernard, Pasi.
    
    
       o But other solutions are possible, e.g. SSID-based.
    
    
       o Suffix routing on a NAI is better than prefix routing.
    
    
       o If an eap-layer based solution is used, EAP identity request hints are 
    probably OK.
    
    
       o The network cannot always ( and maybe should not ) do the 
    selection. So information has to be provided to the users.
    
    
       o If you try to encode the mediary network information into virtual AP's 
    ssid's, the amount of beacons needed might end up consuming a 
    significant part of the bandwidth.
    
    
       o On the other hand, if you have to associate with each of a large 
    number of APs, and start a EAP exchange with each in order to get the 
    information about
    
    
     - Discussion:
    
    
       Margaret Wasserman: Are there lessons to learn from loose source 
    routing? Can we become victims of single points of failure?
    
    
       Pete: Seems we are limiting us to a solution which doesn't scale very 
    well. And I'm not sure we should be doing this at all.
    
    
       Bernard: Today we have internet connectivity and DNS-based routing. This 
    was not possible with RADIUS.  Why are we doing this? It looks like there is 
    no layer-2 alternative that can handle all cases.
    
    
       Margaret: Assume I can choose based on some string between 
    mediating networks. Does not seem to be right as there should be some 
    policy. Do we gain something over the existing solutions today?
    
    
       Farid: These policies can be pushed to the subsciber device from the 
    home network
    
    
       Farooq: It's the home network which has to settle the roaming cost.
       
       Farid: Some users may care about QoS, some about cost. Policy can be 
    pushed by the user's home network.  Margaret: There are other WGs that 
    investigated the concept, should be looked at as well. Bernard Aboba: Take it 
    to the list.
    
    
       Jari: We have a cost factor in selecting the right network. End users 
    care about the cost.
    
    
     - Strawpoll: 
    
    
       Should this be solved in the IETF? Consensus that the problem is worth 
    solving.
    
    
       Should the EAP WG solve the problem? Consensus that it should be 
    solved in WG, but less strong than for the first question.
    
    
     - Comment by Pasi: There are solutions that do not involve EAP at all. But 
    EAP WG could be a good place to explore this.
    
    
    
    Related Work -- EAP Key Derivation for Multiple Applications, Joe 
    Salowey
    
    ========================================
    =================================
    
    
     - 
    http://www.ietf.org/internet-drafts/dra
    ft-salowey-eap-key-deriv-02.txt
    
    
     - Changed the draft name to "EMSK usage guidelines"
    
    
     - 2284bis defines the EMSK. Several applications have been suggested that 
    use the EMSK (eap-keying, aaaarch-handoff, eap-protectedtlv) The current 
    proposal should either be incorporated into key framework draft, or the 
    keying framework should reference it.
    
    
     - Jari: May be a separate specification as well. Joe: Key framework 
    itself references EMSK. So either take that out, or reference it. Russ: Its 
    just two pages, merge it in. Jari: Ok
    
    
    Related Work - The Compound Binding Problem, Farid Adrangi (on behalf of 
    Jose Puthenkulam)
    
    ========================================
    ====================
    ==============================
    
    
     - 
    http://www.ietf.org/internet-drafts/dra
    ft-puthenkulam-eap-binding-04.txt
    
    
     - Status update for 04 version of the draft: mostly editorial 
    improvements. Three issues (64, 191, 192) are still open.  Some crypto 
    experts have reviewed the draft, no issues so far.  Timeline is to 
    resolve open issues this year. Revise section 4, synchronize with keying 
    framework. Submit for final review in January, close in February 04.
    
    
     - Issue: The EMSK may not be the best thing to use for the compound 
    bindings. We need to look a this
    
    
     - Bernard: We started looking at this because many other groups needed 
    something like this. Now IKEv2 is doing something similar, and .... is 
    doing something similar. Right now it seems like the IETF is going 
    violently in different directions and we get 
    incompatibilities. An there may be different views of whether there is a 
    problem.
    
    
     - Russ Housley: True, need solution, proposal to formulate this in a few 
    slides for broader presentation in SAAG.  Farid: his has already been done in 
    former IETFs. Bernard: We got no input then.
    
    
    
    EAP methods - EAP SIM/AKA, Pasi Eronen
    ======================================
    
    
     - 
    http://www.ietf.org/internet-drafts/dra
    ft-haverinen-pppext-eap-sim-12.txt
     - 
    http://www.ietf.org/internet-drafts/dra
    ft-arkko-pppext-eap-aka-11.txt
    
    
     - No open issues with the drafts. It is part of 3GPP Release 6 WLAN 
    inter-working. EAP/SIM products are available, deployment is 
    beginning.  Plan is to do individual submissions as 
    informational, once EAP base docs finalized.  No implications to 
    2284bis, state machine or keying framework.
    
    
    
    EAP Methods -- PEAPv2, Jose Salowey
    ===================================
    
    
     - 
    http://www.ietf.org/internet-drafts/dra
    ft-josefsson-pppext-eap-tls-eap-07.txt
    
    
     - Recently submitted draft -07. Features are complete. Added support for 
    sequences of EAP methods. Supports inner method binding.  Goal is to 
    submit as informational. Currently WG item not requested.
    
    
     - Margaret: All drafts are planned to be published as
       informational. I wonder about this. Bernard: It took so long to get this 
    WG started that much work was already more or less done, and it may be hard 
    for people to give up change control now, and make these WG 
    documents. Pasi: Correct with respect to EAP/SIM and EAP/AKA
    
    
    EAP METHODS - EAP-IKEv2, Dirk Kroeselberg
    
    =========================================
    
    
     - 
    http://www.ietf.org/internet-drafts/dra
    ft-tschofenig-eap-ikev2-02.txt
    
    
     - A number of issues have been improved in the update, e.g. error 
    handling, fragmentation.  There are still open issues like optimizing the 
    no. of messages, security claims section.  Another update planned before 
    next IETF to address these issues.
    
    
     - Michael Richardson: Tunneling seems to be complicated, suggestion 
    remove support of tunneled methods or to detail use case.  Dirk: True, but 
    applies to all tunneled methods. Is only an optional feature in IKEv2.
    
    
     - Bernard: Is it intended to handle address assignment in EAP-IKEv2, do we 
    need that?  Bernard: Are all identity payloads needed? Is IKEv2 a 
    limitation in terms of identity payloads? Dirk: Need to check this.
    
    
    
    EAP Methods - EAP Smartcard, Pascal Urien
    
    =========================================
    
    
     - 
    http://www.ietf.org/internet-drafts/dra
    ft-urien-eap-smartcard-03.txt
     
     - Goal of the proposal is to support EAP in smartcards. No 
    discussion.
    
    
    
    Roadmap discussion (10 minutes), WG Chairs and ADs
    
    ==================================================
    
    
     - Steven Hayes: (clarifying 3GPP position) 3GPP requires the two 
    methods discussed, and network selection. Otherwise there are no further 
    requirements on EAP. Request to publish EAP-SIM and EAP-AKA as 
    informational.
    
    
     - Someone: Are the available methods sufficient to progress the 
    documents to Draft Standard?
    
    
       Margaret: Good point. Especially for the keying framework, a method that 
    uses all the features is required.
    
    
       Bernard: There is no standard method required for this, just the use of 
    the features with any method.
    
    
       Russ: Requirement is two independent interoperable methods.
    
    
       Bernard: You can show interoperability without having particular 
    methods showing them
    
    
       Margaret: Are all the methods done informational forever? So what does 
    the EAP WG do - wait till somebody comes along with a method to be 
    standardized?
    
    
       Bernard: There is one standardized mandatory method
    
    
       Russ: But that one doesn't exercise all features.
    
    
       Bernard: Somebody has to ask for a standardization effort.
    
    
       Margaret: There is no interoperability without using 
    informational RFCs.
    
    
       Bernard: The same issue (mandate one method) has been brought to the 
    group by 802.11.
    
    
       Pasi: Could update EAP-TLS as this is the only key-generating RFC 
    method. Current status is experimental, however.
    
    
       Jari: Some defined methods should be standardized in their second 
    revision, e.g. EAP-TLS.
    
    
       Margaret: We don't have the rule that because something has been 
    deployed, it can't be a standards track document!
    
    
       Donald: It almost seems like everything developed outside never is to 
    become IETF standards. We have some examples where v2 of some 
    documents have become - after rework - standards track documents.
    
    
       Margaret: How will expert review differ from the expert review done for 
    standards track documents.
    
    
       Bernard: The intention is to basically raise the bar for new 
    methods, as many have already been allocated, but about 70 percent do not 
    have a useful documentation (expert review is defined in 2284bis).
    
    
       Bernard: If you already have a type code, it's not even sure that the 
    need for expert review will get triggered. Even if you have a code 
    allocated, that's not a guarantee that the RFC editor would publish a 
    document, he could decide this is awful.
    
    
         (Editor's note: Margaret later sent this e-mail to the list:
         "Apparently, I said something at the EAP meeting in Minneapolis that 
    has caused some confusion about the IANA allocation of EAP 
    codepoints.
    
    
          Just to erase any confusion, I want to make it clear that I 
    support the current wording in the EAP draft -- that EAP codepoints 
    should be allocated on the basis of expert review. This represents an 
    increase in scrutiny from the current policy (first- come- first- 
    served), which I think is appropriate. I do not believe that EAP 
    codepoints should require an IETF standard, and I do believe that it would be 
    appropriate to allocate EAP codepoints in some situations 
    (vendor-specific or environment-specific) where it wouldn't make sense to 
    produce an IETF standard.
    
    
          I do hope that the WG will consider standardizing secure, eneral 
    purpose EAP methods in the future, but I do not believe that we should 
    require a standards-track document in order to obtain a 
    codepoint.")
    
    
       Chris Elliot: I'd really like to se you take on methods work.
    
    
    Meeting adjourned.
    

    Slides

    Agenda
    EAP WG Document Status
    EAP State Machines
    EAP Key Framework
    EAP-based Mediating Network Discovery and Selection
    EMSK Usage Guidelines
    Compound Authentication Binding Problem (EAP Binding Draft : version 4)
    EAP/SIM and EAP/AKA
    Protected EAP version 2 (PEAPv2)
    EAP-IKEv2 Method Update
    EAP support in smartcards
    Network Selection Issues
    Network Selection -- Scoping the Discussion