2.3.5 Extensible Authentication Protocol (eap)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-10-01


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. 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-05.txt
  • draft-ietf-eap-keying-03.txt
  • draft-ietf-eap-netsel-problem-02.txt

    Request For Comments:

    RFC3748 Standard Extensible Authentication Protocol (EAP)

    Current Meeting Report

    Extensible Authentication Protocol WG (eap)

    IETF-61 Minutes, Wednesday, November 10, 2004 at 0900-1130

    CHAIRS: Bernard Aboba <aboba@internaut.com>, Jari Arkko <Jari.Arkko@ericsson.com>

    SCRIBE: Gerardo Giaretta <Gerardo.Giaretta@TILAB.COM>


    Presentations on the web: http://www.drizzle.com/~aboba/EAP/IETF61

    Issues on the web: http://www.drizzle.com/~aboba/EAP/eapissues.html

    - Agenda Bashing

    - Documents Status

    RFC 3579 "EAP over RADIUS" published earlier
    RFC 3748 "2284bis" published earlier

    EAP state machine in RFC editor queue. Some comments -> back to the WGLC and then back to RFC editor.

    [Bernard]: We need a review and approve from others than authors

    [Hannes]: I'm not author and I approve. We implemented this state machine.

    [Bernard]: Did you find issues?

    [Hannes]: I'll let you know

    EAP Keying framework: discussion today

    EAP over Diameter (AAA WG - draft-ietf-aaa-eap-09.txt) approved by IESG

    Network Selection Problem (draft-ietf-eap-netsel-problem-02.txt): waiting input from IEEE WIEN next week

    Network Discovery Draft (draft-adrangi-eap-network-discovery-05.txt): to be sent to IESG

    NAI Update "RFC2486bis" [RADEXT WG]: when I-D submission re-opens will be submitted and sent to the IESG

    Methods documents
    3 submitted for RFC publication (EAP-SIM, EAP-AKA, EAP-PSK)
    Many issues in EAP-SIM reviewed by Bernard

    Binding Problem definition: not updated since IETF-58 (abandoned)

    Other work: need review from the WG
    EAP usage in PANA
    EAP usage in MIP6
    EAP usage in DHC

    [Hannes]: EAP in NSIS because of authorization issues. In NSIS WG we have a number of docs describing authentication and authorization issues and need comments

    [Bernard]: ISMS too

    [Glenn]: I have two questions about the directions of the WG. There is work that has nothing to do with authentication (netdisc). Moreover no standardization of EAP methods. 1) EAP for authorization and other usages. I think we should develop a flexible authentication and authorization protocol and include network selection and discovery. What do you think about this? Or would you continue to add stuff to EAP?

    [Bernard]: the scope of EAP is clear. Applicability statement and IANA considerations state the purposes of EAP

    [Glenn]: Which are the future policies?

    [Bernard]: to be described in future documents. Can you send an email question?

    [Glenn]: OK 2) Regarding EAP methods. People need guides from the IETF: IEEE for example. They did not standardize EAP methods. The 3 EAP methods mentioned in slides are about 3GPP

    [Jari]: Not for PSK

    [Glenn]: Are we going to standardize methods?

    [Bernard]: We have one method we need in standard track

    [Jari]: People can develop new methods and standard tracks. If there is interest in people and vendors we will standardize.

    [Glenn]: It's very difficult to publish standard as individual submission

    [Bernard]: We already developed the process for publication of EAP methods

    [Dorothy]: To clarify 802.11 prospective: 802.11 made the decision not to select an EAP method. There are only requirements for EAP methods in IEEE.


    See issue list page at http://www.drizzle.com/~aboba/EAP/eapissues.html

    Requirements from Rouss Housley
    Keying framework try to analyze the security of EAP system The requirements are a sort of charter for the document

    [Glenn]: I don't remember any WG consensus on Rouss requirements

    [Bernard]: We took these requirements as a challenge. So far we did not find any problems with these requirements.

    [Jari]: I agree with Glenn. We don't need to agree with Rouss' requirements if we think he is wrong

    [Glenn]: These requirements seem to drive many EAP method design and I think this is a problem. Could we have a WG document regarding these method-design principles?

    [Bernard]: EAP keying should do this

    [Glenn]: I don't think it is acceptable to base these principles on a presentation

    [Jari]: Let's discuss technical issues

    [Hannes]: One requirements states that an acceptable solution must authenticate all parties. We are not always authenticating all parties

    [Bernard]: the important thing is to be clear on limitations and state them

    21 issues (7 editorial and 14 technical)
    Discussion on most important open issues:

    EAP does not negotiate the lifetime of exported keys
    EAP does not support re-key of exported keys without re-authentication Secure Association protocol may support re-key without re-authentication
    EAP itself is not managing the lifetimes but SA protocol is responsible for lifetimes

    [Jari]: Just a clarification: re-key does not extend the original lifetime. Moreover, if an exported key expired, everything derived from it dies.

    [Bernard] (from slides): TEKs usually expire on the peer and server after the session ends

    [Joe]: I think that this is a good suggestion. Maybe deleted is better than expired.

    [Paul]: Agreed that expired is a wrong word.

    [Hannes]: Is AAA-key stored on the local AAA server?

    [Bernard]: It says only about expiration not storing

    [Jari]: What about fast handoff? we use the same AAA-key?

    [Bernard]: Need more thoughts on that. We have to guarantee the AAA-key freshness

    [Paul]: Something about SA protocol: EAP method generates fresh keys but then it is the SA protocol that is responsible of these.

    [Joe]: (about slide 7) better EAP server and not AAA server

    [Bernard]: not sure. Let's discuss on the mailing list

    [Joe]: EMSK has a shorter lifetime than MSK

    [Bernard]: the issue is that applications do not know the lifetimes of AMSKs

    [Joe]: These are problems of applications and are not fixable by EAP

    [Jari]: In theory we could negotiate all lifetimes. In practice, there are limitations so I think the approach of Bernard is trying to use is the usage of the session lifetime to regulate all lifetimes

    [Joe]: Session timeout is very specific to AAA protocol.

    [Bernard]: The idea is that we have a general timeout that could be a
    session timeout or another but it is generated by AAA server

    [Jari]: We can't describe generally but we have to look at the protocols that are used, Diameter or RADIUS

    [Joe]: Disagree. There are things that are independent of that.

    [Jari]: (about slide 8) Is it a maximum TSK lifetime or a minimum?

    [Bernard]: Maybe this the minimum TSK lifetime

    Text proposed in the mailing list
    Some methods do not have EAP server name and use the authenticator identity. Maybe there are some implicit requirements that derive from this text

    [Joe]: We should not have requirements on AAA server name

    [Hannes]: Key naming discussion is confusing. What means key naming?

    [Bernard]: The naming requirement derives from caching

    [Hannes]: Naming keys you generate state

    [Bernard]: It is needed to select exported keys

    [Hannes]: To select a state does not require strings or names

    [Bernard]: this is true but...(something lost)

    [Hannes]: Key naming has nothing to do with what you are talking about

    [Jari]: If you have a connection-oriented protocol you have state and you don't need key naming. But for caching you need. None is using key naming and existing systems use link-layer names. We could have potential requirements in the future and this is also why we are discussing name. Another question is which names we use.

    [Bernard]: (about slide 10) there are implicit methods requirements in this paragraph and we should be careful on this

    [Pasi]: we are not interested in naming keys but in naming state. I don't understand why we need to name keys but something else

    [Bernard]: we are naming sessions and not keys

    [Hannes]: short comment to Pasi. Half document talks about key naming and half about Security Association. Another issue MSK is never selected again, so it does not need to be named.

    [Bernard]: we need to name it for caching

    [Hannes]: it's the AAA-key not the MSK

    [Bernard]: Good point. We should make it clearer in the document

    Bernard states the proposed resolution
    No comments

    Bernard states the proposed resolution

    [Jari]: there must be something in the KDF to have different keys for different APs

    <Bernard added Generation # in the second bullet>

    [Joe]: there is the application data. The first purpose of the AMSK is not to have the EMSK around. We should discuss the requirements to understand if these keys must be different or not.

    [Hannes]: this key derivation can be used in some places and not in others. This is not clear in the document. I'd suggest to add usage cases.

    Bernard states the proposed resolution
    [Jari]: Security analysis and not requirements

    [Hannes]: I'd like to see architectural issues pointed out, for example how EAP is used in IKEv2 and some IEE examples. For people that do not have IEEE background it's difficult

    [Bernard]: Agree. This is missing

    [Paul]: is the document a best practice? or a survey of architectures?

    [Joe]: I'd like to see what are the expectations for EAP methods and how the applications can use the keys exported

    [Madjid]: I just want to know (if it possible) in a generic way how keys are derived without IEEE or TLS details

    [Jari]: we are trying to describe a system. We'll try to describe how key derivation works: this part should be simpler.

    [Madjid]: It's hard to read and the key derivation is only in the appendix

    [Jari]: it's an organizational problem and we are trying to tackle. The purpose is to describe the security of the system

    [Jari]: We are open to different suggestions to reorganize the doc.

    Bernard states the proposed resolution
    No comments

    Bernard states the proposed resolution
    No comments

    [Bernard]: the main challenge of the doc seems to be organizational


    [Jari]: Are there open issues?
    no comments


    (slide 3) If D is compromised it can pretend to B

    This is because EAP does not have a concept of service or NAS identity
    Solution: the AAA server tells the client to which service it is sending the key It is not the same thing of channel binding: the difference is between "I believe" and "he claims" Method independent framework for service identifiers. This method independent blob can be carried in AVPs in EAP methods

    [Hannes]: Good document and useful

    [Jari]: Channel binding vs Authentication. Do people think this distinction is useful?

    [Pat]: This is an interesting problem. IEEE has a group dealing with fast handoff and this could be an issue because in this case the key is not obtained from the AAA server.

    [Someone]: If AAA server and X have trust relationship and X has a trust relationship with Y, is this framework needed?

    [Pasi]: Yes. With this framework we want to prevent that a problem (e.g. a node is compromised) in a part of the system spreads in the whole system.

    [Yoshi]: PANA is also specifying service parameters. I think we need to add to PANA this service parameters

    [Pasi]: we decided not to include this in the document and eventually specify in a separate document

    [Paul]: why not change the direction and the client sends the information to the AAA server and the AAA server confirms? For example for SSID this could be useful.

    [Pasi]: SSID is also carried by RADIUS


    Network Selection Problem (draft-ietf-eap-netsel-problem-02.txt): waiting input from IEEE WIEN next week

    Network Discovery Draft (draft-adrangi-eap-network-discovery-05.txt): to be sent to IESG

    No comments


    Changes due to comments during last meeting
    Supports provisioning with a weak pre-shared key
    Supports key management with forward secrecy using Diffie-Hellman

    List of major changes from version 00:
    Address Crypto Concerns
    Protocol Implementation Issues
    support for HMAC-SHA1 and AES-CBC-MAC

    Description of the message flow both in no identity protection and identity protection cases

    Implementation using FreeRADIUS and XSupplicant Working on implementation for Windows XP supplicant

    Comparison between PAX implementation timings: PAX, EAP-TLS, PEAP-MSCHAPv2

    [Hannes]: EAP-TLS is unfair as comparison, you should use EAP-PSK

    [Clancy]: We just used what it was implemented in FreeRADIUS

    [Joe]: regarding TLS timeline, have you ran tests with session resume?

    [Clancy]: without

    [Joe]: it could be useful to compare with EAP-TLS with session resume

    [Robert]: Considering the complexity of the code, for slower devices this EAP method could be very useful

    [Hannes]: Yes, it's good to think about performance and for example memory space

    [Jari]: How much interest is there? Who read the draft?
    -> 6 people

    [Bernard]: Are you requesting a standard track?

    [Clancy]: Yes

    [Chairs]: Who thinks we should do something like this?
    -> 7 yes, 0 no

    [Robert]: This is very leight EAP method. For example it could be useful in bridges

    [Bernard]: We should have a discussion and write something about that



    EAP methods working with smartcards may conflict with purely software methods Proposal: one EAP type (EAP-SC) for all smartcards

    The EAP-SC model: three layers

    1. The EAP-SC handling layer receives and sends EAP packets, selects a Smart Card handler, and passes packets to the Smart Card handler

    2. The EAP Smart Card Handler layer handles the interface to the smart card and any EAP Method specific functions

    3. The Smart Card executes Authentication Method functions

    [Hannes], [Pasi]: EAP terminates in the smartcard itself. Why is it an issue?

    [Pascal]: You have a conflict because you may need software methods and smartcard methods for the same protocol

    [Pasi]: If you are solving a software problem on the client why do you need a new protocol?

    [Pascal]: There is a conflict from a software point of view

    [Jari]: I agree with Pasi and it seems to be other mechanisms to tackle this method selection. People have implemented without nothing on the wire.

    [Pascal]: IMO the authentication server always knows if smartcard is required or not

    [Jari]: Are you saying that there is a need of communication?

    [Pascal]: it's an issue for the client side that should not switch from a method to another

    [Joe]: I don't see the need. It seems an implementation side problem.

    [Pascal]: I don't agree

    [Hannes]: We have implemented EAP methods using smartcard and this was not needed. You really need to describe which is the problem you are trying to solve in order to understand

    [Pascal]: It's purely a practical issue

    [Pasi]: Smartcards are not so special to require a new EAP type code

    ---discussion cut----


    New support of EAP-TLS
    EAP Smart Cards and EAP-TLS Security Claims

    [Hannes]: The distinction between user authentication and computer authentication is an identity issue

    [Hannes]: I don't think this topic (implementation in SC) is related to EAP WG and IETF in general

    [Pascal]: If these devices are useful for IETF we should specify

    [Glenn]: I read this draft and it seems an API specification and is not for IETF. The implementation of EAP methods in smartcards is strictly internal to smartcards


    EAP Key Management Framework
    EAP WG Document Status
    Authenticated service identities for EAP
    EAP Password Authenticated eXchange (PAX)
    EAP Smart Card Protocol (EAP-SC)
    EAP-Support in Smartcard