Subject: [eap] minutes from EAP WG at IETF-57

From: [email-masked] (Jari Arkko)
Date: Sun, 03 Aug 2003 13:41:52 +0300

This is a multi-part message in MIME format.
--------------060209000500080300020803
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

These are the preliminary minutes, collected by Dirk, Henrik, and John
(thanks!). If you have any comments related to the minutes, let me
know and I'll update them before posting them officially to the
proceedings.

--Jari

--------------060209000500080300020803
Content-Type: text/plain;
 name="ietf57_eap_minutes.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="ietf57_eap_minutes.txt"

Meeting Minutes of the EAP WG at IETF #57

LOCATION: Vienna Austria
DATE:	  July 2003
SLIDES:	  http://www.drizzle.com/~aboba/EAP/
NOTES:	  Dirk Kroeselberg, John Vollbrecht, and Henrik Levkowetz (edited by Jari
	  Arkko)

SESSION I, MONDAY

o Preliminaries (Jari Arkko)

  -    Bluesheets
  -    Agenda Bash

       No comments on the agenda.

o Document Status (Jari Arkko)

  - Base spec finished second last call with 4 open issues left, one
    of them major.

    Glenn asked about the 3 issues left for 2284bis(?), and said he'd
    found 3 editorial issues already on the first page. The chairs
    requested Glenn to report the issues he found.

  - 2869bis approved by IESG, however some issues were found
    afterwards with 802.11i.

  - State machine to become WG item.

  - Binding problem according to the authors has no open issues left
    after list discussion.

  - Methods need expert review, can be informational or standard, but
    cannot progress before base docs are done.

o EAP RADIUS - RFC 2869bis update, Bernard Aboba

  - Bernard talked about the 2869bis status. It has been approved for publication as an RFC.
    But two issues were raised afterwards, the intention is to discuss these and fix
    the document in author's 48 hours. The proposed fixes were 

    (1) Order of attribute processing #157: Proposal to resolve by
        adding some correctional text. Jesse Walker: Agreed.  Pasi
        Eronen: Order change is fine, but not sure whether this should
        be in 2869bis, because the order can be different for
        different link layers. Bernard Aboba: This is an EAP problem,
        because the order affects the operation of the protocol.

    (2) Identity privacy. Proposed Change: “the user-name attribute
        within the access-accept packet need not be the same as the
        user-name attribute in the access-request”) John Vollbrecht:
        thinks the user-name content has to be the same.

        Jari Arkko: Its unclear, who are we trying to protect. The AAA
        server does send ID of the user to the NAS anyway. Bernard
        Aboba: It is not only the identity of the user, but whatever
        is in the accounting message.

    Decision: Issues taken to the list for further discussion.

o EAP Base - RFC 2284bis, Henrik Levkowetz

  http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-04.txt
  http://www.levkowetz.com/pub/ietf/drafts/eap/draft-ietf-eap-rfc2284bis-04.html
  http://www.drizzle.com/~aboba/EAP/eapissues.html

  - Remaining issues are 150, 151, 152, and 160.

  - Issue 150: lower-layer behaviour for limited access: Put to the
    list, as this needs more discussion

  - Issue 152: Lower layer indications: Text in 3.4 is not aligned
    with state machine draft. Clarified by Pasi Eronen: If you loose
    success packet, you can count on lower layers success
    indication. State machine does this “always”, EAP spec only
    allows this for methods with success acknowledgement.

    Bernard Aboba: following a survey, no one did implement this. So
    it is no useful.

    John Vollbrecht: State machine approach the is better approach

    Jari Arkko and Pasi Eronen: The practical impact is a long timeout
    if you do it as EAP specifies

    Bernard Aboba: The major impact is for PPP.

    Pasi Eronen: In WLAN there is a higher possibility of loosing the
    success packet, so this is affected as well.

    Bernard Aboba: Why would a mutually authenticated method not have
    success indication.  This would be basically saying the client is
    happy when he authenticates the server.

    Pasi Eronen: But the server sends a link-layer success.

    John Vollbrecht: It may have been one of the major design flaws in
    EAP that both sides do not really know whether it succeeded
    
    Decision: The issue needs to be looked at in detail on the list.

  - Issue 160: Network selection assistance.

    EAP identity request, type field MUST not be null terminated
    according to spec. Some implementations embed a null octet to
    separate the message into a displayable and a non-displayable
    part.

    Glen Zorn: Not sure what the proposed solution is. Must be
    backwards-compatible. It is inappropriate to provide guidance on
    this.

    Someone: Need something, but it does not matter how this is
    done. Could be done as in the past with the null string.

    Zorn: The issue is at least 2 layers above EAP, not to be solved
    here.

    Conclusion: Discussion moved to the list?

o EAP State Machine, Pasi Eronen

  http://www.cs.umd.edu/~npetroni/EAP/draft-vollbrecht-eap-state-04.html
  http://www.ietf.org/internet-drafts/draft-vollbrecht-eap-state-04.txt

  - Pasi Eronen spoke about the state of the EAP state machine
    draft. Significant progress has been made since the previous IETF,
    and a pre-alpha implementation by Yoshihiro Ohba.
 
    . Data flows are now shown in the diagram

    . Packets that should not occur are silently discarded.

    . Etc

  - Version 03 of the draft is incorporated in IEEE P802.1aa draft 6.1
    (annex).

  - Discussion on the “pass-through & backend” slide. Bernard Aboba:
    I don't understand what the passthrough method does - it confuses
    the AAA action and the lower layer interfaces.  There used to be a
    AAA layer in there, but now it is gone. That is the flaw. Glenn
    Zorn: The state machine has to look the same whether there is AAA
    or not. Pasi Eronen: Then I'd split the authenticator and back-end
    state machines, so that we can show how one gets the same result
    whether one uses a backend or not. First we specified one
    authentication diagram. Then did two separate, one for
    passthrough, one for back end.  Bernard Aboba: AAA client has to
    be there: It is a pass-through until the last EAP message.  Pasi
    Eronen: That is already reflected in the current draft, but not in
    a very elegant way.

  - Farid Adrangi: State which parts have to be implemented and
    which not? Pasi Eronen: The whole doc is informative, the specs are
    2284bis and 2869bis. There are some cases where 2284bis says
    should but state machine does not cover the alternative. Therefore
    it has to stay informative. Future work may happen on EAP for
    tunnelled methods.

    In case there is a disagreement, 2284bis will be the normative
    document.

  - Jari Arkko: Will this become WG doc? There are still issues, so
    fix them, issue a new version and then make it WG doc. Bernard
    Aboba: How many read the draft?  Result: About 3-4. All want to
    make it WG item. Decision: this will become a WG item.

o Network Selection, Farid Adrangi

  - Farid Adrangi held a presentation on network selection in
    EAP. This draft is related to some potential requirements from
    3GPP on EAP.

    Visited networks have different agreements with home; user

    1) wants to be provided with a list of available visited networks
    2) should be able to specify the VN

    Focus here on the first question. Presentation proposal: Open work
    item in EAP to analyse present requirements in an attempt to
    convey information (through EAP) to the UE for network selection.

  - Glenn Zorn: What is the use of this? Why would the client want to
    choose network?

  - Farid Adrangi: Because the different networks may have different
    services or costs. Glenn Zorn: Why can't you first authenticate,
    and then use some other protocol to choose? Farid Adrangi: It can
    cost to authenticate.

  - Glenn Zorn: Again, cannot this pre pre-configured, automatically
    updated?  Farid Adrangi: The number of operator can be in the
    100's, there is a scalability issue with Glenn's proposed method

  - Someone: This is not really a thing for EAP, you are looking for a
    service discovery method.

  - Glenn: Could you describe the difference between a service and a
    network providing a service? Farid Adrangi: Trying to find a way to
    select what network should route the packages.

  - Jari Arkko: Talk to the interested people to figure out what the
    right protocol for network selection is, and then submit a draft
    to that WG.

o EAP SIM & AKA P. Eronen

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

  - Pasi Eronen did a presentation on EAP SIM and AKA. The documents
    are quite stable now. They has been aligned with the key
    derivation as per 2284bis.

  - EAP-SIM: Recent clarification added related to the security
    analysis (see below). When multiple RAND values are used, check
    that they are different. Clarified security considerations.

  - EAP-AKA has relatively similar changes.

  - Next steps: Get reviews, wait until 2284bis is finished. Proposal
    to publish method as informational

o EAP-SIM Security Analysis, Uri Blumenthal

  http://www.drizzle.com/~aboba/EAP/AnalyisOfEAP.pdf

   - Uri Blumenthal presented the security analysis of EAP SIM.

   - There are some keyspace and mutual authentication weaknesses of
     EAP-SIM compared to what the specification currently says.

   - EAP SIM claims to enhance the security to 128bits, mutually
     authenticated with independent sessions. The analysis shows the
     possibility of two 64-bit attacks, and disproves session
     independence.

   - Glen Zorn: Is that an EAP-SIM or a GSM issue?  Uri Blumenthal:
     The presentation just addresses the claims made in the EAP-SIM
     spec.

   - Bernard Aboba: Is the request, that lack of session independence
     should be added to the security considerations?  Uri Blumenthal:
     yes.

EAP-SIM Analysis response, Pasi Eronen

  - Pasi Responded as follows:

    1) The text in the draft on key strength is somewhat different from what
       the Security Analysis addresses as claim (see slides).

    2) There's a difference between an attack with probability 2^-64,
       and an attack which requires work of 2 to the 64 (and give
       an attack probability of 1)

    3) The current document strongly recomments using 2 or 3 triplets, 
       giving ~128 bit strength, rather than 1 triplet (giving ~64).

       In the newest version, text has been added to the latest draft
       that both client and server must use at least 2 triplets.

       EAP-SIM requires that the server always uses fresh RANDs, but
       the client cannot check (i.e. store). This is extensively
       discussed in security considerations.

    4) The SIM used for authentication SHOULD NOT be used in GSM, because
       then attacks can be done on that network which has weaknesses not 
       present in EAP SIM

    5) There is no need to use SRES to increase key strength.

  - Jari Arkko: The conclusion is that methods need security review --
    would be interesting with a similar analysis of AKA, for
    instance. It is essential that we agree what the security
    properties of the methods are (but users of EAP may have different
    opinions on what properties they require).
 
    We may also need additional requirements in 2284bis about session
    independence.

SESSION II, THURSDAY

o Report of the 802.1x ad-hoc interop test event (Karen O'Donoghue)

  - This event took place April 7-9, 2003 in Belmont, CA.  Goal was to
    gain insight into status of products, to improve state of 802.1X
    interoperability, and to provide feedback to standards groups.

  - Issues identified were:

    . Specification interpretation issues.
    . Re-authentication, non-EAP agnostic authenticators (EAP type support,
      negotiation).
    . Inner auth methods (PEAP, TTLS), Wireless VLANs (no standards)
    . Bugs, bugs...
    . Administrative issue: Certificates are hard. Setting up took up
      a day, so prepare for more time next time.

  - Most of the problems were operational and implementation
    related. They may have been a few issues related to the clarity of
    of specifications, and Karen will send more information later on
    those.

  - InteropNet Labs is planning interop for next year. Test-suites are developed
    by the University of New Hampshire.

o EAP Keying Framework (Bernard Aboba)

  http://www.drizzle.com/~aboba/EAP/draft-aboba-pppext-key-problem-07.txt

  - Goal is to provide framework for evaluation of EAP key derivation mechanisms
    and transport mechanisms. EAP invariants are Media/Ciphersuite/Method
    independence.

    There are different relevant phases:

    0) Discovery phase; discover authenticator (out-of-band for EAP):
       Phase 0. It is not secure.

    1) EAP is Phase 1 between EAP peer and server. EAP SAs are
       bi-directional, Mutual authentication is required for
       key-deriving methods. Method provides keys (MSK, EMSK). EAP
       only supports key creation, no deletion.

       Running this phase does not mean that client want to connect at
       that time - preauthentication SA may be bidirectional.

    2) SA Protocol (Phase 2): Used by EAP peer to derive SA with the
       EAP authenticator to protect data. Demonstrates
       "proof-of-possession " of phase 1 SA (key binding).

  - Jesse Walker: Are we going to discuss key/SA lifetime issue?
    Bernard Aboba: Currently no lifetime negotiated. There is the
    lifetime of EAP, or data, SA. EAP SA lifetime not relevant. Data
    SA lifetime should be done by Data SA protocol. This should still
    be discussed at some point.

    Jesse Walker: Usually its time, but often with cryptographic
    devices it is also other things, such as usage of a key for a
    large amount of data. Bernard Aboba: There are two lifetimes, the
    phase 1 and phase 2. it is conceivable that phase 1 could be used
    too many times, to cause sequence number overflow or
    something. Jesse Walker: I don't think we need to worry about that
    but the data key lifetime is relevant.

  - Why is binding/naming important?  EAP and SA protocol may not run
    between same parties. EAP key name required to identify SAs.  A
    link that the EAP runs on may have multiple authentications so
    need a name to be sure know which authentication to base a secure
    association on.

  - James Kempf: Is it the name of the key or the SA? Bernard Aboba: in
    this case it is the name of the key. 

  - Lauri Tarkkala: Why not just refer to the latest key? If eap does
    not have a delete mechanism, why bother with the naming. As EAP
    does not delete keys, what is the policy how many keys are cached?
    Implementation specific logic required, but this may lead to
    interoperability issues.

    Bernard Aboba: Depends on the implementation or the load of the
    affected device. No specification required here. For instance, how
    busy the AP is could affect whether phase 1 can be cached for a
    day or 5 minutes. Lauri Tarkkala: I can agree with you reasoning,
    but it creates application specific reasoning. in ikev1 this has
    caused problems.  Bernard Aboba: post the issue to the list so we
    can track this.

  - Bernard Aboba: EAP is a peer-to-peer protocol, but: AAA may not
    support role reversal; EAP methods may be client/server.

  - Open issues:

    . Issue 15: missing security requirements. Proposal: add material
      to address this in -07 draft

    . Issue 47: Key requirements unspecified (size of MSK/EMSK).
      Proposal: add nonce exchange requirement.

      The proposals or 15 and 47 were accepted.

    . Issue 99: Double expansion: occurs from MK to MSK and MSK to TSK:
      Proposal: reject, key strength is the issue, not double expansion.

      Jesse Walker: it is, there are papers. Bernard: please post
      references.

    . Issue 119: EAP is inappropriate for peer-to-peer. Proposal:
      reject.
 
      Jari Arkko: This may belong to RFC 2284bis.
    
      Jesse Walker: Not enough implementation experience that people
      really know about 119.  Bernard Aboba: TLS methods are
      client-server, as they need different credentials on both
      sides. However, the best thing to find out is to try.

    . Issue 135: include SSID in PRF: Proposal: Reject (EAP is media
      independent, SSID does not exist on all media. During
      pre-authentication, SSID may not be available. There are issues
      for virtual APs).

      Alper Yegin: Other counterexamples are PANA and IKEv2.

      Lauri Tarkkala: SSID is too 802.1x-specific.

      Jari Arkko: Don't think there is a practical problem here.  Jari:
      What about authorization? AP has to figure out which Phase 1 SAs
      it can use for which SSIDs. Isn't this an authorization problem?

      Jesse Walker: The real question is if MSK can be given to more
      than one NAS. If yes, don't care about the SSID. If no,
      Sometimes the information has to be given
      to the client that these are all the same thing so the
      MSK "compromise" is.

      Pat Calhoun: I ship a product that does this. Most clients get
      confused on multiple SSIDs, need to use virtual APs. I don't
      think we should share MSKs or move between virtual APs.

  - Bernard Aboba: I'll continue with updating 07 doc, resolve open
    issues.

  - Discussion continued about Russ Housley's requirements for key
    derivation presented at last IETF:

    . Key naming: Proposal for appropriate naming of EAP-SA, MK, MSK,
      EMSK, TSK.  Issue: How do the NAS, EAP peer and AAA server come
      to agree on the key names? (NAS operates in pass-through, does
      not have access to MK or EMSK.  Solution: AAA server needs to
      transmit this.

    . Comment: Discussion on this should be made part of the 2284bis
      Jari Arkko: Better to keep separate in the informational keying
      framework doc. Bernard Aboba: One document is standards track,
      the other is informational.

    . Alper Yegin: Where does the peer obtain the call-station-ID
      from?  Bernard Aboba: usually lower layer; in the case of PANA
      this might be the IP address.

    . Someone: why is this keying framework informational? Bernard
      Aboba: there is a lot of informational stuff in the keying
      framework.

    . Jari Arkko: The mandatory parts will go in 2284bis in the end.

o EAP Key Derivation for Multiple Applications, H. Zhou

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

  - The idea of this draft is that multiple applications can be keyed
    from same MSK (protected-TLV, DHCP, PANA, fast roaming).  Derive
    AMSK (application master keys) from EMSK.

  - Open issues: 
    . KDF refinement
    . AAA attributes to request and deliver keys
    . Integration with key naming

o Use of EAP Keying for DHCP Bootstrap (Hannes Tschofenig)

  http://www.ietf.org/internet-drafts/draft-tschofenig-pana-bootstrap-rfc3118-00.txt

  - Draft addresses EAP keying (derivation, distribution of MSK,
    derive PANA key). Key derivation for DHCP is based on PANA. There
    is a relation to "EAP Key Derivation for Multiple Applications"
    work.

  - Jari Arkko: What makes DHCP special, there are a lot of other things to be
    done for network access? 

  - Hannes Tschofenig: network entities are different here. 

  - Alper Yegin: Work is primarily for DHCP WG. An out-of-band key derivation
    scheme is missing. This is not meant to solve all the network access
    problems.

  - James Kempf: Why is PANA used here, couldn't we just use 802.1x or something
    that is there?

  - Hannes Tschofenig: PANA required; provides an additional set of nonces.
    Carries additional parameters required to establish SA with DHCP server.
    802.1x does not allow this.

  - Kempf: One could extend 802.1x. Alper Yegin: Yes.

  - Result: Discussion taken offline.

o EAP Compound Binding (Farid Adranghi)

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

  - Issues addressed in new version: 

    . #64: Problem statement addressed in new version.

    . #65: Downgrading attack: Current draft now explains this.

    . #70: Which PRFs should be used? draft now says should be based
           on what tunnelling protocol is used.

    . #88: Why tunnel keys are used? use keys of the inner methods? not changed,
      tunnel keys are stronger.

    . #89: Review of version 1 draft now addressed.

    . #123: Non-key generating methods and binding: now addressed in
    3.2.

  - Process for the doc: Submit for final crypto review, resolve new
    issues.

  - Farid: Time is of essence, should become WG doc soon.

  - Jari Arkko: former reviewers still need time to check their issues

o EAP Client Side Transport (Florent Bersani)

  http://www.ietf.org/internet-drafts/draft-boursetty-eap-cst-00.txt

  - Presentation just gives a concept, does not really fit in the WG
    right now.  Splits EAP endpoints in AuthToken (peer side) and
    AuthServer for authentication; integrity/encryption runs between
    client (peer) and server. Idea is separating authentication and
    service used later on. Approach motivated by smartcards / security
    tokens.

  - Separate authentication from service carrying authentication.
    Don't need to support smart cards inside device, e.g. can
    authenticate with Smart card on phone to use notebook/pc talks
    about tokens rather than client authenticator.

o EAP Archie (Jesse Walker)
  
  http://www.ietf.org/internet-drafts/draft-jwalker-eap-archie-01.txt

  - Some Changes in -01 version:
    . Altered to use only one crypto primitive
    . Bindings changed to use define numbers address family

  - No further changes planned. Will only evolve in response to Bugs,
    suggestions to simplify.

  - Uri Blumenthal and Jesse Walker designing new Archie-like protocol
    (based on Archie and SKE).

  - John Vollbrecht: Make it either a straight or a tunnelled
    protocol?  Jesse: No technical reasons against this, depends on
    the group's feedback.

o EAP IKEv2 ( Hannes Tschofenig)

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

  - Idea is to reuse good crypto and flexibility of IKEv2 as EAP
    method.  Inherits IKEv2 security properties, including DoS
    protection. Does not exchange IPsec SA payloads.

  - Next steps: Incorporate comments already received, address key
    derivation and naming according to the current discussion. Stable
    version for the next IETF.

  - Open issues are sequencing of EAP methods, secure address
    configuration, protection of outer EAP methods (needed?).

o EAP LDAP, Avi Lior

  http://www.ietf.org/internet-drafts/draft-mancini-pppext-eap-ldap-00.txt

  - EAP-LDAP is a challenge-based authentication using MD5, in
    conjunction with the encryption algorithm used to store the
    password within the LDAP identity store. Recommended to use in
    conjunction with tunneled methods. Could be extended to any other
    data store. Idea is to allow validation without passing password in
    clear. Draft requested to be WG draft.

  - Uri Blumenthal: But the cryptographic attack is the same for this as
    for MD5, you just do an extra step, but a dictionary attack is still
    possible.

  - Discussion: Comments moved to the list.

o PEAP Version 2 (J. Salowey/A. Palekar) (Hao Zhou)

  http://www.ietf.org/internet-drafts/draft-josefsson-pppext-eap-tls-eap-06.txt

  - New draft addresses compound binding problem. Clarifications for
    implementors. Supports sequencing of methods in PEAP tunnel.

  - Lauri Tarkkala: Microsoft has IPR statement regarding PEAP. Does
    this apply to the new draft? They have stated there is nothing on
    the new draft?  Zhou: cannot tell, not with MS.

  - Bernard Aboba: Why compound MAC and compound key are both done for
    binding?  IKEv2 did only one of them?  Zhou: Authors felt compound
    key does better security; did both however.

o EAP Support in Smartcard, P. Urien

  http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-02.txt
  http://www.ietf.org/internet-drafts/draft-urien-eap-ssc-00.txt

  - Defines universal ISO 7816 interface; EAP-application on
    smartcard, that may be associated with different
    EAP-types. Supports lots of services and EAP SIM is supported,
    others under discussion.

  - Current Interfaces are network / OS+terminal /
    management+personalization / user.  EAP-SSC (secure smartcard
    channel): uses single EAP type, defines symmetric or asymmetric
    key exchange procedures.

  - Future work: Rand number format rules for asymmetric case; message
    ciphering support.

--------------060209000500080300020803--