2.3.6 Extensible Authentication Protocol (eap)

NOTE: This charter is a snapshot of the 63rd IETF Meeting in Paris, France. 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-06-27


Bernard Aboba <aboba@internaut.com>
Jari Arkko <Jari.Arkko@piuha.net>

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 04  EAP Keying Framework document submitted for publication as an Informational RFC
Oct 04  EAP Network Selection Problem Definition document submitted as an Informational RFC


  • draft-ietf-eap-statemachine-06.txt
  • draft-ietf-eap-keying-07.txt

    Request For Comments:

    RFC3748 Standard Extensible Authentication Protocol (EAP)

    Current Meeting Report

    EAP WG Meeting at IETF #63

    Location: Paris, France
    Date: August 2nd, 2005
    Time: 14:00-16:20

    Notes: Jouni korhonen and Dirk Kroeselberg (merging by Jari Arkko)

    1. Preliminaries (5 min) -- Jari Arkko
    Agenda bashing
    Blue sheets and notes takers

    Arkko: Doing agenda bashing and presenting the issue tracker.
    No changes to the agenda.

    2. Document Status (5 min) -- Jari Arkko
    • 2x RFCs out
    • 2x in RFC queue
      • EAP State Machine
      • EAP SIM & AKA

      • Keying framework: still some open issues

    • Netsel problem definition -> expired
      • Volunteers needed for this draft to make progress (several volunteers signed up later).
    • Adrangi Network discovery (draft-adrangi-eap-network-discovery-13.txt)
      • Should be in back IESG review shortly
      • Margaret Wasseman is in charge of this inividual draft, some discussion ongoing.
    • IANA allocatios and Individual RFC publications requested
      • EAP PAX, PSK, Smartcard Type, Double TLS, EAP IKEv2
    • EAP method revies req:
      • Double TLS, Smartcard Type, IKEv2 status currently DENIED pending modifications per reviewer's requests
    3. Keying Framework issues (30 min) -- Joe Salowey
    Goal: Discuss issues

    Joe Salowey gives the presentation:
      • Whole thing has been split into three different documents
    • Housley-aaa-key
      • describes the general requirements for AAA key management, intended as BCP.
    • EAP-keying
      • Describes the existing EAP key management usage
    • EAP key management extensions
    Jari: Are Russ' requirements binding? For EAP, there are pretty precise definitions of the requirements, what happens if there are conflicting requirements? Who gets to discuss the content of Russ' document? (Russ not present)
    Closed issues: 300, 305

    Issue 306: to be handled in Yoshi's presentation afterwards.

    Issues discussed today (read the slides for the content):
    • 294 - Analyzing existing EAP usage
    • Analyzy what (802.1X, PPP, 802,11i)
    • Analyze against (Housley criteria)
    • No one present in the meeting indicated having looked into this yet
    • Bernard has a detailed analysis in his site -- please comment.
    Jari: understanding the security properties of the system
    Alper: there are a lot of systems than those 3 listed earlier
    Jari: Concentrate on known widely deployed cases.. however people are free to submit more analysis on other cases.
    Glen: widely deployed rules out PANA & IKEv2 etc
    Jari: that is debatable of course
    Someone: People willing to work on this is a good flow control..So if people are willing to work on some analysis then just do it.

    Action item: Hannes and Dirk will review Bernard's text and post comments to the list.
    ** 299 - key caching, keys internal to EAP methods may be cached fast re-auth etc)
    • Jari: Issue was started by confusing text mentioning key caching. Hopefully we can scope how we can name and cache these keys like EMSK etc. Should be explicitly stated what is cached and where
    • Do we need to name the keys cached in the EAP layer?

      EMSK and AMSK may be cached outside o EAP as possible extension, but should be out-of-scope for the keying framework. Other keys (MSK/AAA-Key) do not appear to need caching. Also relates to naming: if they are not cached in EAP, do they need a name?
    Action item: Joe volunteers to write the missing text.

    ** 302 - Domino effect clarifications
    • Alper: should we use Housley as a normative reference or not?
    • Jari: Housley is supposed to cover things beyond EAP
    • Alper: What if the domino effect definition ends up in both docs? Then they need to be synchronized beyond recognition...
    • Jari: Agree. But in the keying framework we can state a very specific requirement, and verify that its fulfilled.
    Action item: Alper to take this further.

    ** 307 - deletion of the security requirements section
    • Mostly editorial.
    • Jari: Bernard already sent a text proposal, which appears to solve the issue.
    ** 279 - Additional keying protocol requirements

    #307 may already remove the need for this. But need to make sure we cover these already.
    • Jari: Main thing is staying with the current system and not to look into stuff like fast handoffs<
    • Jari: Any volunteer to go through Jesse's issue?
    • Joe: lets assign this to him..
    Action item: Jari to ask Jesse Walker to check whether the new draft covers his requirements.
    ** Next steps
    • More people are needed to review this draft. Please review -08 version on Bernards web site.

    • 09 version in approx. 6 weeks. WGLC for this version, revised final for IETF-64

    • Review draft-housley (AAA keying requirements) and resolve possible issues

    • Continue with extensions after IETF-64 and beyond.

    4. Channel Bindings
    Goal: Discuss definitions, alternative schemes
    and draft-arkko-eap-service-identity-auth-03.txt

    Yoshihiro Obha gives the presentation on lower layer parameter & channel bindings (read the slides for then content):

    Background for the discussion explained by Jari: Yoshi has a draft which suggests a channel binding mechanism which, if adopted, needs to go to the keying framework document so that the key calculation rules can be documented and standardized. Lets focus on the question if this is the way to go for the keying framework discussion or not.

    Ohba: Yoshi's draft is based on the list discussion on alternatives for this.

    The draft defines a key binding blob carrying lower layer information. The blob is sent by the authenticator to the server, and is an input to the key derivation. If the lower layer parameters of EAP peer and authenticator do not match, the lower-layer security cannot be successfully established (keys of supplicant and authenticator not matching).

    The solution impacts the AAA protocol (e.g. new Radius attribute), but its advantage is that it works for all EAP methods without requiring an extension to them. Main drawback is impact to deployed APs, and possible also to lower layers protocols such as 802.11.

    Pasi: Does not work with existing 802.11 access points.
    Yoshi: Yes, in this case AP can still use the legacy version, then EAP method support for channel binding would be required.

    Pasi: There are code changes?
    Obha: Yes.

    Joe: This should not be part of current keying framework, needs to many changes to existing stuff.

    John: Naming (channel binding) should be changed, since exact problem is not clear.

    Jari: Does not really belong into Housley document. Housley does not have much text HOW to implement these things.

    Joe: We need to clearer what problem we are trying to solve. The channel binding name might be slightly misnomer.

    Glen: EAP is so mixed up with AAA stuff, which causes lots of trouble. Probably belongs into the protocol, but it is not EAP.

    Pasi: Some documents call this \\u201cthe EAP system\\u201d, which is EAP plus other things. This is really the scope of the keying framework.

    Jari: Sounds like Yoshi's draft should not be part of keying framework. It may be worked on separately later, however.

    5. Methods Discussion (40 min)
    Goal: Talk about the results of the reviews, make progress

    EAP PSK Review (10 min) -- J. Walker
    Independent submission to IESG. Requested EAP method type number. Reviewed by Jesse Walker in June. Update integrating some review points in -08 version. Still number of open issues, e.g. for key derivation. Key naming is not planned, since there is no application like fast reconnect. Discussion will be continued on list.
    Hannes: On key control issue: it wouldn't add more complexity to include it here.

    Bersani: ok, moving on adding the key control

    Jari: The right process for this is to talk about the issues and gather more expert reviews on the list

    Hannes: I am one of the authors of PSK, Jesse actually criticized some things he originally proposed so we are a bit confused what he wants.

    EAP IKEv2 Review (10 min) -- P. Eronen
    Pasi likes the approach, but document not considered ready. Inaccurate comparison to EAP-TLS mostly fixed in -07 version. Major issues e.g. with current fragmentation mechanism (since EAP is lock-step), fast reconnect does not clarify how the server picks the correct key, channel binding. Needs more work, but no major obstacles found.
    Dirk: Channel binding was not updated since authors had to wait for the outcome of Yoshi's proposal on channel binding.
    Hannes: Thanks to Pasi for the review. One additional issue on channel binding.. Could we come up with our own solution or reference to something (and if so to what?)
    Pasi: There are 2 ways how to do channel bindings (Obha and Pasi & Jari) no selection which one has been made
    Jari: I think we can do a decision on channel binding in the list after the meeting, which one of the two to select. We will send a question to the mailing list how to proceed with channel bindings.

    EAP Smartcard Type Review (5 min) -- G. Zorn
    There are already a number of EAP methods on token or smartcard types. Expert review has been performed by Glen Zorn. Answers to the review comments: see presentation slides. Pascal disagrees with review comments in a few points, e.g. on the IANA requirements compliance. Some discussion about security claims. Glenn: Either take out security claims altogether, but then it must be clear that the method itself has no security properties.
    Jari: Running out of time, discuss this in the mailing list

    EAP Double TLS Review (5 min) -- H. Tschofenig
    Found some confusing text about "inner" method. Many optional parts make analysis quite difficult. Some issues, e.g. key strength and hierarchy not properly documented. Crypto-binding still needs investigation.

    Relation to other TLS methods is important to be discussed, but has not been subject of review.

    Pascal: Just motivate goal of the draft. This is to use TLS-based shared key authentication.
    Jari: More discussion on the mailing list.

    EAP PAX Update (5 min) -- T. Clancy
    • HostAP has an implementation of the EAP-PAX..
    • IANA has allocated numbers
    • Would like to move it to standards track document either in this WG or in SECMECH
    Methods Work Situation Info (5 min) -- Jari Arkko

    Jari thanks the reviewers.
    Hopefully we will be able to work on few methods to get them into standards track, either here or in SECMECH. Please inform the list and the IESG on what needs to happen on this front.
    6. Trusted Computing Group EAP Issues (20 min) -- John V.

    See the slides for the main content. Note: Different naming for lower layer nodes and functions in TNC than in IETF.
    General idea is to check client state before allowing network access (quarantined). For EAP, TNC is considering a new EAP method (protected method, inner method carried by outer method). This method could map to IF-TNCCS (see slides). The presentation is meant to seek feedback from the IETF EAP community, maybe create a formal liaison later on. Possible work could be a protected method, a generic "outer method", or inner method keying requirements in the keying framework.

    Jari: If you want more feedback on this.. Do you have anything else than these slides??
    John: We have some but not all are publicly available. A participation to the consortium is generally required. May need a formal liaison, since TCG is a closed group. If such a method will be specified in IETF, this needs to be worked out.
    Jari: That has worked out earlier.. e.g. a certain consortium allows access to relevant documents for a certain WG.
    John: No standard "outer" method for protected EAP methods still exists. And is it possible to add "inner" capabilities to existing or planned methods??
    Pasi: Sounds interesting and worth doing. Maybe without the help of EAP group. And we need those documents.
    Hannes: Also likes the idea.. Security Ads won't like this however.. Many of these things have already been discussed. But don't start with one specific tunnel method. The tunneled method might be inefficient as everything can be run inside the tunnel
    Jari: Tunnel methods can sometimes be used to avoid the IANA registration rules :)
    Glen: EAP specs currently do not define sequencing details, I thought that was clearly outlawed!
    Alper: Why?
    Glen: It was not allowed to run a sequence of EAP authentications.
    Alper: The latest 802.16e supports sequencing.
    Glenn: But this is not supported by the EAP spec
    Alper: These are two independent EAP sessions. However, discussion in IEEE is already closed.
    Jari: Volunteers to review for TCG..? Contact Jari.

    7. EAP Enrollment (5 min) -- Rohan Mahy

    Motivation is that small wireless devices (e.g. phones) are a pain to enrol onto WLANs. Basic proposal is to start with some weak credentials and then let the client fetch stronger credentials after that. Use existing methods. Presentation just seeks thoughts on this.

    Hannes: Very good thoughts and has also been thought here in this and other WGs earlier. Why we never managed to move this forward earlier?

    Alper: It goes back EAP applicability statement.
    Hannes: a number of methods provide the capability to exchange config parameters. Want to see some guidance on how to move things forward.

    Someone: Does not believe that a strong credential is better if authentication is started with weak credentials before. Rohan: but the server is authenticated.

    Jari: sorry, we are sort of pushed out of the room now. Hannes, do you think there is a general solution? Hannes: personal opinion that this could be a general solution. Enrol would be a valid place to drive this.

    Jari: Further discuss this on the list, need to get this done somehow.
    8. Meeting concluded 16:20


    Document Status
    EAP Keying Framework
    AAA-Key Derivation with Lower-Layer Parameter Binding
    EAP-PSK v8
    EAP-IKEv2 review
    EAP Smart Card Protocol (EAP-SC)
    EAP Password Authenticated eXchange (PAX)
    Methods work at the IETF
    An EAP Enrollment Method
    Expert Review EAP Double TLS