Subject: [eap] ietf-56 eap meeting notes

From: [email-masked] (Jari Arkko)
Date: Fri, 28 Mar 2003 17:57:19 +0200

This is a preliminary version of the meeting minutes. Please
e-mail the chairs if we missed something or if you took
additional minutes that aren't already described here. Thank
you Henrik and Paul for taking notes. And Paul: did you have
a measurement tool for the decibel numbers that you documented
as a result of the hums? ;-)

----

Minutes from the IETF-56 Extensible Authentication Protocol WG (eap)
meeting

CHAIRS: Bernard Aboba <[email-masked]>
	Jari Arkko <[email-masked]>

PRESENTATIONS: http://www.drizzle.com/~aboba/IETF56/EAP

MINUTES: Henrik Levkowetz and Paul Funk (edited by Jari Arkko)

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 MPLSI 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, though).

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;
    mutual authentication; resistance to dictionary attack; thwarting
    of MitM attack; replacement for EAP-MD5-Challenge (which is subject
    to MitM attack).

    In addition to the 802.11i work, another group is working on
    inter-access-point protocols, which will utilize RADIUS.

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 others.

    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

    http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-01.txt

    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
             connection.

      (c)    Client normally requires Success, but if there is an alternative
             indication that implies Success client may proceed with connection.

    - 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.

    - 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 source)

      (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.  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

    http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-01.txt

    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

    http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-02.txt

    Presentation from José 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 potentially vulnerable
    but not addressed by this draft.

    Requirements for the attack:
    - The MITM is able to run dual roles - rogue authenticator and
      rogue supplicant
    - 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 attack.
	* 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

    http://www.ietf.org/internet-drafts/draft-aboba-radius-rfc2869bis-09.txt

    Bernard summarised the status of RFC2869bis, there's one open issue
    currently.  A lot of little nits have been fixed. The open issue is
    "The lying NAS problem", described in the slides (RFC2869bis)

    Bernard then described some other issues which has come up: Issue
    83, where 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. Details of the
    proposed resolution in the slides.

9. EAP Archie, Jesse Walker, 5 minutes

    http://www.ietf.org/internet-drafts/draft-jwalker-eap-archie-00.txt

    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?

    Alper Yegin: Why should the method be made more suitable for it's
    transport (PPP)

    Jesse: I'm asking for input, ...

    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.

    ?: 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

     http://www.ietf.org/internet-drafts/draft-aboba-pppext-key-problem-06.txt

     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.

     Simon (?): The MSK could be derived from the EMSK (or MK)?

     Bernard Aboba: No, but the EMSK should be cryptographically independent
     from the MSK

     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

     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, EAP
     (Key) Exchanges (two-way exchange, three-way-exchanges), The EAP
     (Bermuda) Triangle, Security Requirements, Open Issues.
	
     The Open Issues were:

       Issue 15, missing sequirty requirements
       Issue 47, key requirements unspecified (why 64 bits)
	        what about specifying key strength?
       Issue 99, Double expansion, is this acceptable

     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 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 where.
     Bernard Aboba: (Clarification given.)

     John Vollbrecht: Is it likely that these things will change in the
     future?

     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: Only the MSK leaves the method.

     Simon: Client is roaming; while in a session, which key is
     transported to the new (target) NAS?

     Bernard Aboba: None - you don't transport keys between NAS'es.  Some
     proposals derive different keys from one EMSK to multiple NAS
     keys, but it is not wise to pass keys between NASes.

     Simon: But there has to be a coupling between EMSK and TSK, so...

     Bernard Aboba: There are example formulas and methods in the Appendix
     (Further explanation).

     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 proxy.

     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 minutes

     http://www.ietf.org/internet-drafts/draft-salowey-eap-key-deriv-00.txt

     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 derived?

     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: Requirements,

     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 site.

     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. 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 protocols.

     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
     interoperability

     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 minutes

     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

     http://www.ietf.org/internet-drafts/draft-vollbrecht-eap-state-01.txt

     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

     http://www.ietf.org/internet-drafts/draft-salowey-eap-protectedtlv-01.txt

     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

     http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-10.txt
     http://www.ietf.org/internet-drafts/draft-arkko-pppext-eap-aka-09.txt

     Joe went on with a presentation on EAP-SIM drafts (multiple). (See
     Slides).

     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 Appendix

     Jari Arkko: So this is only a question of a change in terminology?

     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
     process.

17. Tunneled MD5, Paul Funk, 5 minutes

     http://www.funk.com/documents/draft-funk-eap-md5-tunneled-00.txt

     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.