2.3.3 Extensible Authentication Protocol (eap)

NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-01-22

Bernard Aboba <aboba@internaut.com>
Jari Arkko <Jari.Arkko@ericsson.com>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Erik Nordmark <erik.nordmark@sun.com>
Internet Area Advisor:
Erik Nordmark <erik.nordmark@sun.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:
DEC 02  RFC 2284bis submitted for publication as a Proposed Standard
JUN 03  EAP Keying Problem document submitted for publication as an Informational RFC
  • - draft-ietf-eap-otp-00.txt
  • - draft-ietf-eap-esteem-01.txt
  • - draft-ietf-eap-rfc2284bis-01.txt
  • No Request For Comments

    Current Meeting Report

    Minutes from the IETF-56 Extensible Authentication Protocol WG (eap) 
    CHAIRS: Bernard Aboba <aboba@internaut.com>
        Jari Arkko <jarkko@piuha.net>
    MAILING LIST: Address: eap@frascone.com
                  To subscribe: eap-request@frascone.com, with 
    "subscribe" in Subject line.
    MINUTES: Henrik Levkowetz, Paul Funk, Bob Moskowitz (edited by Jari Arkko 
    and Bernard Aboba)
    SESSION 1: Monday, March 17 at 1530-1730
    1. Preliminaries (10 minutes)
       - Bluesheets
       - Minute Takers
       - Agenda Bashing
         Jari summarized the agenda for today and thursday, and asked for 
    comments - none.
    2. Networld+Interop (Karen O'Donoghue)
       N+I (in three short weeks) will have a 802.1x demo and a 3-day 
    interoperability test session for EAP methods. Methods to be tested 
    include EAP-TLS, EAP-TTLS, and EAP-PEAP, as well as a variety of inner 
    methods. Please come, and bring your EAP method (better tell her first, 
    3. IEEE 802.11 Request (Dorothy Stanley)
       Dorothy represents the IEEE 802.11 group and is responsible for 
    liaison with the IETF. The IEEE, as a user of IETF protocols, in 
    particular EAP and RADIUS, has formally requested guidance in 
    selection of EAP methods to meet their security goals, in the 
    following categories: methods of authentication via certificate, 
    user-password and GSM/UMTS secrets; key strength and key material (128 bit 
    effective key strength needed); mutual authentication; resistance to 
    dictionary attack; thwarting of MitM attack; replacement for 
    EAP-MD5-Challenge (which is subject to MitM attack).
       The letter is available at
       In addition to the 802.11i work, 802.11f is working on 
    inter-access-point protocols, which will utilize RADIUS. There are issues 
    related to this, as it is necessary to add new Service-Type values and 
    possibly change the behaviour of certain parts of RADIUS. Dorothy 
    presented the IEEE 802 response to IETF issues, which is available here:
    4. Document status
       Jari summarized the document status:
       - 2284bis - a lot of issues handled, plan a WG last call when all 
    issues closed. Pointed out that the background for 2284bis is unclear 
    parts of 2284, and having interoperability problems. The goal for 
    2284bis is to clarify unclear points and ensure 
    interoperability, and *not* add new features.
       - There's documents for EAP state machine, keying framework, and 
       Mentioned the requirements for adopting new documents as working group 
    items. Drafts adopted as working group items must have a level of 
    maturity; there should have been significant review already performed and 
    all major issues should already have been resolved.
       Bernard added timeframe: June for Keying document. Things may be 
    dropped rather than let them slide.
    5. RFC 2284bis, Henrik Levkowetz and Jari Arkko
       Three major outstanding issues were presented, and a vigorous 
    discussion ensued.
       Issue 80 - Is EAP-Success required?
       - There was some discussion of whether the new draft should allow the 
    client to acknowledge success, whether particular EAP types should 
    provide alternative means to acknowledge success, whether all methods that 
    don't perform mutual authentication should be abolished.
       - Henrik made clear that this issue does not pertain to the 
    authenticator, which always must issue Success if the 
    authentication was successful. However, there are several choices for 
    client behavior:
         (a)    Client does not require Success.
         (b)    Client requires Success, or it must refuse to proceed with 
         (c)    Client normally requires Success, but if there is an 
    alternative indication that implies Success client may proceed with 
       - Hum results:
         (a)    inaudible
         (b)    -70 dB
         (c)    -43 dB
         Loudest: (c)
       Issue 97 - May packets of another type interrupt an 
    authentication sequence (strict mode)
       - Some confusion was expressed by commentators as to whether this 
    relates to serial authentications or interruptions of a sequence which may 
    not have completed (e.g. DoS). Also the question was brought up as to 
    whether the authenticator should be allowed to switch to a different 
    method before the first completed; for example, if the 
    authenticator determines that the original method cannot complete and 
    wishes to try an alternative without failing the user.
       - In the interest of assessing how this decision would affect 
    existing deployments, various implementors rose to describe how badly 
    their code would react to receiving packets of unexpected type, though 
    nobody actually shared source code. Most implementers currently 
    silently discard packets of unexpected type.
       - Choices were:
         (a)    Yes, they may (no strict mode).
         (b)    No, and this is enforced by the state machine discarding 
    packets of unexpected type (strict mode).
         (c)    Not really, but this is enforced by state machine in 
    consultation with currently running type, so exceptions may be made 
    (limited strict mode).
       - Hum results:
         (a)    -10 dB (disqualified because it originated from a single point 
         (b)    -50 dB
         (c)    -49 dB
         Loudest:    (c)
       Issue 87 - Type change during method
       - This issue was admittedly closely related to the previous (97).  The 
    issue pertains both to the authenticator switching to a new type before the 
    first is complete and starting a new type after the first is complete 
    (serial authentication).
       - Jesse Walker pointed out a use case for serial 
    authentication that someone may actually want to do: 
    authenticating first the machine, and then the user of the machine.
       - John Vollbrecht argued that a type change in the middle of a 
    sequence can be distinguished by the client from serial 
    authentication after the first type is complete, and therefore type 
    change should not be outlawed. He also felt that behavior in this regard is a 
    security choice, but should not constrain the protocol.
       - There was discussion as to whether the client can know that a method 
    has completed. For example, it will know when it has successfully 
    authenticated the server, but may not know whether the server has 
    completed its authentication of the client.
       - Bernard Aboba felt that allowing type change would pose a 
    challenge to existing implementations. Also, sentiments were expressed that 
    serial authentication would pose problems to the state machine. Jose 
    Puthenkulam argued that the key binding problem, absent a single EAP 
    method that embraces the serial methods, is an open-ended one whose 
    solution is not yet known.
       - The choices were how strongly to discourage type change:
         (a)    The authenticator SHOULD NOT perform a type change.
         (b)    The authenticator MUST NOT perform a type change.
       - Hum results:
         (a)    -60 dB
         (b)    -47 dB
         Loudest:    (b)
         But with the following provision: There may be only a single outer EAP 
    type. However, that type itself may tunnel EAP types, of which there may be 
    multiple.  That is, sequences outside tunnels are a MUST NOT. The outer 
    protocol is responsible for defining how that is done and how the 
    results of the inner types are combined to produce a unified session key.
    6. EAP Support in Smartcards, Pascal Urien, 5 minutes
       Presentation from Pascal about the capabilities of smartcards and the 
    interface to EAP proposed for smartcards. Pascal described an API that 
    would allow EAP to be embedded in a SmartCard. The SmartCard would 
    receive EAP packets from and send them to the network, and perform all 
    cryptographic processing internally as a closed system. A management 
    interface would allow client software to provision the SmartCard with 
    identities, policies, etc.
       Such a SmartCard could handle protocols such as EAP-SIM, EAP-TLS, etc.
       No questions
    7. Compound Binding, Jose Puthekulam, 10 minutes
       Presentation from Jose on compound methods. Turns out that there are 
    man-in-the-middle attacks possible on tunnelled compound methods.
       Compound tunnelled methods may be used in order to
        - Secure legacy methods in new environments
        - Ease of deployment for securing legacy methods
        - Providing consistent security properties and other features for 
    different methods
        - Securing multiple credentials in sequences.
       Non-tunnelled compound sequences are also vulnerable but not 
    addressed by this draft. If such sequences were used somewhere, a 
    compound key derivation would have to be designed for them as well.
       Requirements for the attack:
       - The MITM is able to run dual roles - rogue authenticator and rogue 
       - Creds and method re-used with and without tunnel
       - Tunnel is one-way server authenticed
       - Use of tunnel session keys alone and no inner method session keys
       Yoshi: I believe that #3 is not necessary - it's possible also for 
    mutually authenticated tunnells. Jose: Yes, but that's a *trusted* MitM - in 
    which case all bets are off.
       Jose then laid out a general framework for providing solutions to the 
    problem. Some of the solutions are policy-based (e.g.  don't do that); 
    others are cryptographic.
       Possible solutions:
        - for non-key deriving methods
        * Use of separate credentials inside and outside tunnels breaks the 
        * Always use methods inside tunnels??
        - for key-deriving methods
        * Use cryptogrphic bindings:
            + Compound Keyed MACs
            + Compound Session keys
       The attack may be foiled either at the point of authentication or at the 
    point of use. That is, there may be an additional authentication step to 
    assure both parties of the absence of an MitM, or the validity of 
    session keys generated for the connection may be made to depend on 
    absence of MitM. Jose favors the former, as it nips the problem in the bud 
    and precludes a connection from even being set up. Allowing the 
    connection to be set up (only to fail to operate) is expensive and 
    therefore encourages DoS attacks.
       Jose presented the notion of a "binding phase", which uses single 
    round-trip cryptographic algorithm to perform the compound 
    authentication at the conclusion of the EAP sequence.
       Bernard asked (a) which PRF is used in the binding phase, and (b) 
    whether this is compatible with IKE v2. Jose replied that (a) each 
    tunneling protocol selects its PRF, and (b) each tunneling protocol 
    defines and exports its own session keys, so the tunneling protocol is 
    independent of the context in which it is carried and is therefore 
    compatible with IKE v2.
    SESSION 2: Thursday, March 17 at 1530-1730
    8. RFC 2869bis, Bernard Aboba, 10 minutes
       Bernard summarised the status of RFC2869bis, there's one open issue 
    currently, issue 83. Here an AAA server can receive an invalid EAP packet 
    from an authenticator in passtrough mode. The message cannot be just 
    dropped, as the authenticator will retransmit the AAA request. Details of 
    the proposed resolutions are the slides.
       A lot of little nits have been fixed. A solution for "the lying NAS 
    problem" was described in the slides (RFC2869bis). The solution is to 
    require RADIUS proxy verify NAS identifier.
    9. EAP Archie, Jesse Walker, 5 minutes
       Jesse Walker talked about EAP Archie, a proposed solution to the 
    problem that none of the current mandatory 2284 methods are suitable to 
    802.11.  Archie would if accepted be a new mandatory EAP method. The 
    Archie exchange consists of the following message exchanges (see slides 
    [Archie] for details
         <--     Random Session ID (Request)
         Hash of Session ID, Random Nonce, Binding (MAC addresses), MIC -->
         <-- Hash of prev Msg, Encrypted Nonce, Binding(MAC addresses), MIC
         Finish: Hash, MIC -->
       Can the EAP MD5 Challenge method be deprecated?  Can EAP-Archie be 
    adapted to be suitable for PPP?  Is there interest in taking on this work?
       Simon Misikowski: What kind of hashes?
       Jesse:  The hashes are SHA hashes.
       Bob Moskowitz: How would this work with a Proxy RADIUS?  Not sure that 
    EAP-AKA doesn't also meet the 802.11 requirements?
       Bernard Aboba: There is no Proxy RADIUS issue as long as the RADIUS 
    server uses NAS-Identifier, NAS-IPv6-Address or NAS-IP-Address 
    attributes to compose or check bindings, *not* the packet source 
       Alper Yegin: Why should the method be made more suitable for it's 
    transport (PPP)
       Jesse: I'm asking for input on the appropriate address type for PPP. 
    This is the Called-Station-Id and Calling-Station-Id (e.g. phone 
       Alper Yegin: WLAN is primary transport? We may need to change it to 
    adapt to other protocols?
       Jesse:  We'd have to look at whatever is needed to adapt it.
       The issue in adaptation was only the address type, nothing else.
       ?: Looking at the differences between this and AKA. There's also the 
    ESE, which should be compared
       Joe Salowey: I liked the binding aspect, we may need to look at 
    introducing this other places or in a generic fashion?
    10. EAP Keying Framework, Bernard Aboba, 15 minutes
        Bernard presented Goals and Objectives for EAP Keying. Slides 
    [Keying]. This is a framework for evaluate keying methods, rather than a 
    proposal of methods. Further: EAP Invariants for keying methods, Terms for 
    Master Key Types, ...
        Paul Congdon:  Should you define the length of these keys if you are 
    trying to be ciphersuite independent?
        Bernard Aboba: You might get suites deriving keys with different 
    length, maybe quite short keys. The answer could be to require 
    ridiculously large keys, or to settle on lengths which are currently 
    sufficient. It was noted that the issue was not the length of the EMSK or 
    MSK but its equivalent key strength. 64B is plenty long enough -- but in the 
    future the required key strength might increase. Today 802.11 is asking for 
    the ability to negotiate 128-bits of key strength, tommorrow it might be 
        Simon (?): The MSK could be derived from the EMSK (or MK)?
        Bernard Aboba: No, but the EMSK MUST be cryptographically 
    independent of the MSK and MK. The EMSK can be derived from the MK via a 
    one-way function, or it can be a completely independent quantity.
        Simon:  What is the purpose?
        Bernard Aboba: Purpose not defined yet, but its essence is that it is 
    known by Peer and Server, and *not* by NAS. The MK is never exported, so 
    that the MK cannot be used in computations done outside the EAP method, 
    such as fast handoff. Where PFS is required (such as in deriving a key 
    given to a NAS that cryptographically separate from a key known by 
    another NAS), the only exportable quantity available to derive this from is 
    the EMSK, since NASes never have access to it.
        Bob Moskowitz: The MSK is known by at least 3 parties, and the 64 
    bytes keying material - it is distinct from the entroyp. This defines the 
    key lenght, not the key strength.
        Bernard Aboba: Yes.
        Bernard, continuing presentation, covering: EAP Key Hierarchy, and EAP 
    (Key) Exchanges. There's a two-way exchange:
        EAP client <-> NAS, no AAA server
        small network
        usable in larger
        There's also a three-way exchange:
        client, NAS, AAA
        frequently deployed in larger networks
        Bernard continues the presentation and talks about the EAP 
    (Bermuda) triangle. This triangle is as follows:
                    EAP peer
         EAP mutual auth,             /  \               TSK derivation,
           MK, TEK, EMSK             /    \               mutual auth,
                                    /      \                 TSKs
                                   /        \
                    Auth Server   ------------   Authenticator
                                   mutual auth,
                            AAA session key (TLS, IPsec)
        Bernard talks about the security requirements:
        - mutual authentication each leg
        - fresh session keys on each leg
        - key protected from compromise
        - protection against MITM
        - per-packet authentitcation, integrity, replay protection each leg
        The Open Issues were:
        - #15 missing security requirements
        - #47 keying requirements unspecified (why 64 bytes)
                  what about specifying key strength?
        - #99 double expansion  MK->MSK & MSK->TSK
        T.J. Kniveton: You said you couldn't get a MK out of a SIM card, but 
    section 17 of the draft describes certain derivations
        Bernard Aboba: There were papers written which assumed you could get the 
    MK out of the SIM, but we needed to clarify that it never leaves the EAP 
    method. The MK cannot and need not leave the SIM card or the MK box in the 
    Key Hierarchy.
        Joe Salowey: There are implementations of EAP SIM where the entire 
    calculation takes place on a SIM card.
        Bob Moskowitz: FIPS has a document which has a key derivation proces 
    which which we maybe we should look at, to make sure it is 
    compatible. May need this in order to be FIPS compliant.
        Bernard Aboba: The document won't recommend a KDF, but it will pose 
    requirements on KDFs.
        John Vollbrecht: Wanted a clarification on which keys are carried 
        Bernard Aboba: (Clarification given.)
        John Vollbrecht: Is it likely that these things will change in the 
        Bernard Aboba: If we've done a good job, this should be future proof.
        John Vollbrecht: Can these keys be taken out of the method?
        Bernard Aboba: The MSK, EMSK and IV are exported from the method. 
    However, only the MSK is sent by the AAA Server to the NAS. The EMSK MUST 
    NOT Be sent by the AAA Server to the NAS. The MK and TEKs are never 
    exported from the method.  The IV isn't sent by the AAA Server to the NAS 
    but it's not very useful since it is a known quantity (required by US 
    Export Laws several years ago). As a result it is largely vestigial.
        Simon: Client is roaming; while in a session, which key is 
    transported to the new (target) NAS?
        Bernard Aboba: Actually, the MSK is never transported between NASes. 
    Some proposals derive a new master session key on the AAA server, based on 
    the EMSK and send this to the new NAS. This provides PFS. Other 
    proposals have one NAS send a key derived from the MSK via a one-way 
    function and send this to the new NAS. This way the new NAS can't 
    decrypt previous traffic but the old NAS can decrypt new traffic.
        Simon: But there has to be a coupling between EMSK and TSK, so...
        Bernard Aboba: There are example formulas and methods in the 
    Appendix. The EMSK, TEKs and TSKs are cryptographically 
        Glenn Zorn: -- Long silence, looking at EAP key hierarchy. Is it true 
    you're treating these entities equally - including a proxy?
        Bernard Aboba: Yes, although it gets complicated when you have a 
        Glenn Zorn: It could be handy to have a key known to all, but only 
    useful for a certain purpose, such as AAA interchanges?
        Bernard Aboba: Yes, but there's a question here from where you 
    derived such a key - and depending on where you derived it from, would it be 
    secret to the people it needed to be secret from?  I.e. which key tree 
    should you
        John Vollbrecht: Are there 1 quantity exported from AAA server?
        Bernard Aboba: There are 3 entities derived, and 1 exported.
        Dan Forsberg: Do you specify or recommend any lifetimes for these 
    keys, and if some time out, how do they get renewed, and can ESMK be used 
    for session resumptions?
        Bernard Aboba: The EMSK is *not* used to resume sessions, because it is 
    known by more than 2 parties.  We have talked about including a key 
    lifetime parameter, but currently the key lifetime is equal to the 
    session lifetime, but there's a question if that's sufficient or not.
    11. EAP Key Derivation for Multiple Applications, Joe Salowey, 10 
        Joe Salowey made a presentation on EAP Key Derivation For Multiple 
    Applications. See slides. Highlights: Motivation, Applications (WEP, 
    802.11i, MPPE, Fast Roaming, ...) Requirements, Key Derivation, and 
    currently open issues.
        Bernard Aboba: How do we figure out how much material should be 
        Joe: 64 bytes are a lot of material. We need to get input from 
    security experts.
        Simon: Lucent put out some papers, for 3GPP and 3GPP, 
    requrements on keys for them to be acceptable in 20 years. The 
    resulting key strength (entropy) of 84 bits.
        Joe Salowey: Yes, 64 bytes are much.
        Alper Yegin: Any constraints on which applications may use this?
        Joe: I'd rather make keying materials available to application that 
    needs it, rather than making restrictions.
        Alper Yegin: There may be security considerations with making keying 
    material available to random applications.
        Bernard Aboba: Did you choose TLS for some particular purpose, or as 
    just an example?
        Joe Salowey: No particular significance.
        Simon: (Examples of other possible KDF).
        Bob Moskowitz: (Pointed out which documents in the references needed to 
    be looked at in relation to this).
    12. EAP Roadmap, Erik Nordmark & Thomas Narten, 10 minutes
        Erik Nordmark made a presentation about Methods, Methods, Methods, Or 
    When can we start talking about methods? (See Slides). Highlights: 
        Simon: 3GGP2 Requirements should also be considered.
        Bernard Aboba: We don't have a liaison with 3GPP2 yet?  In the case of 
    IEEE and 3GPP, they have to us and told their requirements.
        Simon: Interoperation between 802.11 and CDMA is an active work item 
    within 3GPP2. You're welcome to get all requirement from the 3GPP2 web 
        Erik continued: Selecting methods?, Strawman proposal: Methods can be 
    submitted as individual submission RFCs, need Expert Review but that can 
    start now. Method RFCs must depend on the new versions of RFC 2284 etc, 
    however.  Keep MD5 as mandatory, Capture requirements from different 
    scenarios in an informational RFC, start work on a BCP which captures 
    mapping from environments to appropriate methods, and possibly later pick 
    new mandatory methods. Significant delay (9-12) months possible if we 
    tried to do that. Not select methods for other SDOs.
        John Vollbrecht: We need to test interoperability, so we need some 
    mandatory methods that exercise the features we have in our 
        Bernard : The reason 802.11 have asked for a new mandatory method is 
    that they are not sure they could do it themselves, so this might leave 
    them in a bit of a quandary.
        Bob Moskowitz: IEEE ... They have tradentionally have been 
    reluctant to mess with other organizations babies.  EAP is your method, so 
    please make it acceptable to our needs. We should make sure that within a 
    year we can provide what they need, a specification of what should be 
    used. A BCP might be good enough, it mustn't necessary be a Standard.
        Alper: Agree with the strawman approach, it seems a way to go 
    forward without specifying a new mandatory method for each new 
    interested party - IEEE, 3GPP, 3GPP2, ...
        Simon: The original requirements originally came from 802.11?
        So whatever we present to them, it will be up to them to select from 
    whatever smorgasbord we present to them.
        64 bits, is that their req?
        Bob Moskowitz: Yes.
        Simon: and mutual authentication came from them?
        Bob Moskowitz: Yes.
        Dave (?): We need to have a recommendation of a mandatory method for use 
    with 802.1i, and this is really out of our scope, this belongs to IETF. We 
    need a published document we can reference in our documents, pointing out a 
    method we can use.
        Erik Nordmark: So a BCP would be enough, a PS is not needed?
        John Vollbrecht: We need a specified method in order to measure 
        Bob Moskowitz: Any methods we can get out quicker rather than later, in 
    the form of an RFC rather than just a draft, makes it possible for them 
    (802.xx) to reference it, and say to vendors "these are the methods to use, 
    go out and implement them"
    13. IEEE 802.1aa/EAP State Machine Reconciliation, Paul Congdon, 10 
        Paul Congdon made a presentation on alignment of different 802.xx and 
    EAP RFCs. (See slides) Highlights: Current status, Document List, 
    Proposed and Agreed Changes to 802.1aa/D5, EAP/802.1X Interface, Key 
    Interface with EAP, 802.1X, 802.11, LinkSec Task Group Formation in 802.1
    14. EAP State Machine, John Vollbrecht, 15 minutes
        John Vollbrecht made a presentation on EAP State Machines. (See 
    Slides). Highlights: URL's, State Machine Style, EAP Mux Model, Peer State 
    Diagram (802.xx style state machine), Pass through, Policy Functions, 
    State Machine next steps,
    15. EAP Protected TLV, Joe Salowey, 5 minutes
        Joe Salowey, presentation on Protected EAP-TLV, a way to protect a 
    (tunnelled) series of TLV's. (See Slides), and continued with 
    EAP-Authorization, a method to request authorization for services and 
    session attributes (See Slides)
        Dave (?): Which endpoints would exchange these TLVs?
        Joe Salowey: Supplicant and Auth. Server.
        John Vollbrecht: Is this going to be a method?
        Joe Salowey: Right now it's just a TLV, and maybe it makes sense to 
    make it a method, but I don't know if it must be.
        John Vollbrecht: So it could be tagged into other methods?
        Joe Salowey: Essentially a method, could come at the end of other 
    methods. Could happen inside an EAP message.
        John Vollbrecht: So I could run EAP within EAP within EAP...
    16. EAP SIM and AKA, Joe Salowey, 10 minutes
        Joe went on with a presentation on EAP-SIM drafts (multiple). (See 
        Bob Moskowitz: I'd like to see a change in the AKA draft, to talk 
    about a shared secret method, and then a particular GSM application in an 
        Jari Arkko: So this is only a question of a change in 
        Bob Moskowitz: Yes, and mapping to GSM terminology as a separate part.
        Jari Arkko: I think we can do this.
        Simon: How does SIM fill the 128 bits requirement?
        Joe: You use multiple triplets.
        Simon: These triplets doesn't provide mutual auth?
        Joe: No, but EAP-SIM does provide mutual auth based on these.
        Bernard suggested that even if this is not yet a WG document, the 
    authors should already now get security reviewers, to speed up the 
    17. Tunneled MD5, Paul Funk, 5 minutes
        Paul Funk made a presentation on The EAP MD5 Tunneled 
    Authentication Protocol. (See Slides). This is an attempt to cure the MITM 
    problem for tunnelled operation, (the Puthenkulam draft)
    18. Meeting ended.


    Agenda - 2
    InteropNet Labs WLAN Security Initiative - Las Vegas
    Response to Solicitation of Letter of Assurance
    802.1X & EAP & Keying - State Machines and Interfaces
    EAP Archie
    EAP Key Derivation for Multiple Application
    EAP Keying Framework
    IEEE P802.11-03/243r2
    EAP support in smartcards
    Compound Authentication Binding Problem
    802.1X & EAP & Keying - Status Update
    EAP Roadmap (or) What to do about Methods?
    Protected EAP-TLV
    EAP Issues List
    IETF Liaison Report
    EAP Key Derivation For Multiple Applications
    EAP State Machines
    RFC 2284bis Open Issues
    Protected EAP-TLV
    RFC 2869bis Issues