2.3.7 Extensible Authentication Protocol (eap)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional EAP Web Page

Last Modified: 2005-10-03


Bernard Aboba <aboba@internaut.com>
Jari Arkko <jari.arkko@ericsson.com>

Internet Area Director(s):

Mark Townsley <townsley@cisco.com>
Margaret Wasserman <margaret@thingmagic.com>

Internet Area Advisor:

Mark Townsley <townsley@cisco.com>

Technical Advisor(s):

William Arbaugh <waa@dsl.cis.upenn.edu>
Charles Clancy <clancy@cs.umd.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. Documentation of interaction between EAP and other layers.
6. Resolution of interoperability issues.
7. EAP state machine.
8. EAP keying framework.
9. EAP network selection problem definition

Items 1-6 were included within RFC 3748. Items 7-9 will be handled
as separate documents.

While the EAP WG is not currently chartered to standardize EAP
methods, with the publication of RFC 3748, the EAP WG will
assume responsibility for review of EAP methods requesting
a Type code allocation, as specified in the IANA considerations
section of RFC 3748.

When the current work items are completed, the WG may be
rechartered, or a new WG may be formed to standardize methods.

Goals and Milestones:

Done  RFC 2284bis submitted for publication as a Proposed Standard
Done  RFC 3748 published
Done  EAP state machine document submitted for publication as an Informational RFC
Sep 2004  EAP Keying Framework document submitted for publication as an Informational RFC
Oct 2004  EAP Network Selection Problem Definition document submitted as an Informational RFC


  • draft-ietf-eap-keying-08.txt
  • draft-ietf-eap-netsel-problem-03.txt

    Request For Comments:

    RFC3748 Standard Extensible Authentication Protocol (EAP)
    RFC4137 I State Machines for Extensible Authentication Protocol (EAP) Peer and Authenticator

    Current Meeting Report

    Minutes of EAP WG Meeting
    64th IETF Vancouver, BC  
    09:00-11:30 Nov 7, 2005  Salon 1
    Chairs: Jari Arkko, Bernard Aboba
    Minutes Editor: David Mitton (some edits by Jari Arkko)
    Agenda Review
    Presentation directory: http://www.drizzle.com/~aboba/IETF64/eap/
    WG Issues webpage: http://www.drizzle.com/~aboba/EAP/eapissues.html
    Document Status Review:
            RFC 3579 aka "EAP over RADIUS" published earlier [Individual]
            RFC 3748 aka "2284bis" has been published earlier
            RFC 4137 aka "EAP state machine" published recently
     In RFC Editor's Queue
            draft-haverinen-pppext-eap-sim-16.txt  [individual]
            draft-arkko-pppext-eap-aka-15.txt   [individual]
            draft-adrangi-eap-network-discovery-14 [individual]
            EAP keying framework - in WGLC
            Network selection problem definition
            New editors, new energy!
    Network Discovery and Selection Problem
      Jouni Korhonen, presenting
    Old EAP WG document updated to reflect current situation in 3GPP,
    IEEE, and new references.  Minor cleanups throughout.
    Proposal for Version 4 work:
    - Update based on discussion
    - Make Section 2 more network technology agnostic
    - Improve consistency between sections 2 and 4
    - Updates for 802.11u
    Discussion - Scope of Draft?
    - Is the problem limited to EAP?
    - Limited to certain technologies?
    - Limited to boot strapping?
    Jari Arkko: There was useful discussion of the potential solution areas
    and I don't want to see that limited to purely EAP layer.
    Bernard Aboba: One of the hardest part is to knowing what the
    appropriate use of EAP is, and there are problems with the use of AAA
    that need to be discussed.
    Glen Zorn: What does this have to do with EAP specifically? Other than
    a handy place to discuss it.
    Arkko: This is a problem that comes up often in EAP situations, but
    the solutions do not have be EAP based.  It could be moved to another
    802.11u Network Selection
    802.11-05/0822r3 had requirements for selection.  One proposal is to put
    NAI in Probe, AP probes AS, returns a result in Probe Response.
    Comment: There no formal proposals in 802.11u at this time, just
    presentations, so don't be quick to assume this is where the group
    will end up.
    More questions about the details of the nature of this probing.
    Bernard: Coming up a level, we got here because there is a limit on
    SSIDs and other things to select on.  There isn't a way for the AP to
    know if a given realm is reachable. So we invented a sort of AAA ping
    message to explore the proxy route. But there is ongoing discussion in
    IEEE of other methods that might make this unnecessary.
    Comment: In the TGu there is no statement supporting this function.
    Steering of Roaming
    - can we do something more efficent that doesn't depend on intential failures
    - Is AAA sufficent?
    Glen Zorn: This is a AAA Routing issue or even Layer 2 selection and has
    nothing to do with EAP. We should not be addressing them in this group.
    Comment: We really need to persue these issues, and we need a place to
    discuss them.  So we have permission of the ADs to discuss them here,
    but we would be willing to move to an appropriate WG as we progress.
    Bernard: We started this trying to understand and evaluate 
    draft-adrangi-eap-network-discovery, and this is an archive recording of
    the result of that discussion.
    Comment: If we were trying to go to another group, we couldn't fit in
    other groups which have narrower criteria.
    Comment: We should start a BOF to discuss.
    Glen Zorn: This group is not the right place.  Use IETF mechanisms like
    a BOF to find a proper place.
    Pasi Eronen: If the goal is archive the discussion. Then lets finish
    the editorial task in this group.
    Mark Townsley:  If there is no more work to be done, it could be done
    as an indivual submission.  Could I get a sense of the room?
    Is there more work to be done on the problem here in the IETF?
    And how about the solution?  
    If so, then you should get some people together, submit a proposal for
    forming a BOF and start that process.  But it sounds like EAP is not
    the place for this.
    --------------------------------------------------     [0:43:35]
    EAP Key Management Framework - Bernard Aboba
    WG Last Call to expire November 30th.
    Givens: Attacker can see, forge and replay all traffic, may be an
    insider.  Goals: Mutual authentication, Freshness, Bindings.  Server
    must not expose the keying material to anyone other than the
    Reviewed characteristics of: IKEv2, 802.16e, 802.11i, PPP
    Pasi: How likely is it for a AAA server to be sharing keys? Bernard:
    The impact depends on the lower layer, but if the AAA server shares a
    key, it potentially allows authenticators to masarade as the server.
    Sam Hartman: What about roaming and a peers that don't know the AAA server.
    Bernard: That is a problem, and we have to look at the chain of trust, and 
    after the authentication, whom has possession of the keys.
    Sam Hartman: we shouldn't be analyzing all the problems of other
    protocols.  Bernard: We are just describing the security
    characteristics with respect to the goals.
    Majiid: Are we discussing how to fix these protocols, we shouldn't.
    Bernard: We want to know what the consequences are of removing or not
    using optional features.
    Pasi: We don't want to spend time analying combinations that people
    don't use. Bernard: We have issues with Mandatory to implement vs
    Mandatory to use.  We should expect that people will not use some
    features, and should describe the consequences of not using those
    features. There is a legal mandate for government applications to
    secure their systems to FIPS compliance.
    Pasi: What about the mechanisms described in key wrapping documents?
    Bernard: There are issues that these solve and that's what the work is
    for. But not everyone wants to use them, and that changes the
    security value.
    Key Caching
    Comment: Why mention existing AAA servers instead of EAP servers?
    Bernard: Describing existing implementations, caching is not mentioned
    in current EAP documents, methods can have a cache, but the AAA lower
    layer does not.
    Parent/Child linkage:
    Sam: If we require deletion of keys, what about fast reconnect
    situations?  Bernard: Excellent question, we'll talk about it in the
    next presentation.
    Jari: Confusion on list about storing other parameters than
    credentials. The AAA server doesn't know, only the EAP method really
    Issues discussion:
    Glen: If there are problems with terminology because of errors in RFC
    3748.  Maybe we should try to fix RFC 3748, instead of creating new
    work. Bernard: Don't we have that many errors, we do have some
    confusing terms.
    Conclusion: Continue issue discussion on the list and submit
    reviews during WGLC.
    ------------------------------------------------------------   1:48
    EAP Key Management Extentions - Bernard Aboba
    AAA caching
    Bernard: We defined some interfaces, then we discover they aren't good
    enough.  These come from LPC vs RPC semantics.  When we defined that
    the EAP layer doesn't cache, we didn't understand all the
    Pasi: Redefine the standalone case to include another layer. Bernard:
    Define an internal layer that caches between the two.
    Comment: We could cache at a lower layer.  Bernard: Yes, we could, but
    we are discovering scenarios where that is not good enough. Some
    methods are trying to generate key state for multiple authenticators
    and run into cryptographic independance and binding issues.  We need
    to redraw some of the diagrams and figure out how to make these
    different situations work.
    Jari: Not trying to solve all possible ways. Only need to make sure
    that we understand some ways it could be done. Bernard: We want to
    understand the implications so we don't exclude something some people
    might want to do.
    Comment: Do we need understand neighbor graphs and distribution?
    Bernard: None of the keying is dependent on this. Just to show the
    implications and that this information is out there.
    -----------------------------------------------------------  [2:12]
    EAP Handover Support - Madjid Nakhjiri
    This draft is a discussion of how people are using the EAP framework,
    what they are trying to do, and given what they are doing, what
    requirements make sense or not. We should also try to decide how much
    of the work belongs here or can be done elsewhere.
    Wireless mobility goes beyond the original EAP model. Issues with key
    distribution between server, authenticators, mobile nodes.
    Sam: Why cannot the access node be an authenticator?  Handover. But
    you are introducting another trusted party into the trust network, and
    you have to convince us doing security reviews, that simpler scenarios
    don't work.
    Majiid: I didn't design them, these are the IEEE keying models.
    Comment: Can we understand (not guess) why they want to do it this
    way?  Comment: This is a matter of centralizing the authentication,
    and moving functions from the the 100s of base stations to a smaller
    number of NAS boxes.  Cost reasons and centralized management and
    control.  Pasi: This is not any different than the WiFi switch
    architecture, with dumb antenna and a central switch.  In the WiMax
    case they seem to be documenting this protocol. Whereas, many cell
    networks have similar protocols but they are propretary so we haven't
    gotten to bash them.  Jari: So they made the mistake of telling us.
    We need to move on.
    presentation continues...
    Majiid: I'm throwing out some suggestions and asking if this makes
    sense? Some it can be done in this group or some other.
    Jari: I think the discussion is very valuable.  I see two tracks, one,
    seeing if the Key Framework has the right stuff, and then, continue
    with review of specific proposals and see if another WG is needed.
    Bernard: Does the keying framework preclude things? Well we've seen a
    bunch of problems today.  So we'll go and fix those.  And then see if
    we can do what we need to do.  There are little assumptions that seem
    okay, but when put them alltogether they cause things to break.  Some
    of them we've had in there for awhile and we didn't understand their
    full effect.
    Wrap Up
    Network Selection
       Who cares? 11 yes  Not: 0
       Bernard: The history behind this draft is another individual
       submission (draft-adrangi), and the IESG asked whether it was
       compatibile with EAP? The EAP WG document attempted to analyze the
       problem space so that we could answer the IESG's question.
       Cares: Ambition level: 3=0, 2=0, 1=6
       Some people want to move this out of EAP,  but Jari points out that we can
       only vote for this group.
       EAP: 0
       Individual: 3
       BOF: 8
       Ambition level seems to be on the problem side, not solutions
       Glen: Try to address the problem that
       draft-adrangi-eap-network-discovery solves.


    EAP-Double-TLS Authentication Protocol
    document status
    network selection problem
    handover keys
    eap keying issues
    network selection scope discussion