Subject: [eap] eap wg minutes from ietf-58

From: Jari Arkko <[email-masked]>
Date: Tue, 18 Nov 2003 17:34:36 +0200

Preliminary Minutes of the Extensible Authentication Protocol (eap) WG at IETF-58

Time: Monday, November 10, 2003 at 1930-2200

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

Minutes: Dirk Kroeselberg ([email-masked])
          Henrik Levkowetz ([email-masked])
          Edited by Jari Arkko ([email-masked])

URLs: Issue Status: http://www.drizzle.com/~aboba/EAP/eapissues.html
       Presentations: http://www.drizzle.com/~aboba/IETF58/EAP.zip

Preliminaries
=============

  - Agenda Bashing. No comments on the agenda.

  - Bluesheets going around and note takers assigned.

  - Document Status. Jari summarized the document status:

    o EAP base spec passed WG last call, is in IETF last call.

    o EAP state machine (informational) is in WG last call.

    o EAP keying framework has been adopted as WG document. There is
      still a number of open issues, needs more work than the other docs.

    o EAP over Radius (2289bis) approved, now RFC 3579.

    o Method documents: Approval of methods needs to wait for
      completion of base EAP specifications.  Currently not in EAP WG
      charter to work on methods. Future methods might be specified
      either as individual submissions, Informational documents outside
      the WG or as chartered EAP WG work

WG Work Items -- RFC 2284bis, Henrik Levkowetz
==============================================

  - http://www.levkowetz.com/pub/ietf/drafts/eap/rfc2284bis/draft-ietf-eap-rfc2284bis-07.d.html

  - 3rd last call on the document was held in September. There are two open issues left:

    1) Handling of Identity response
    2) Editorial comments by J. Puthenkulam

    Margaret missed her editorial comments among the open issues, but
    these were already fixed.

    No other questions.

WG Work Items -- EAP State Machine, Pasi Eronen
===============================================

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

  - Now in WG last call. Next steps: Handle issues from last call, and
    publish as informational.

  - Draft describes state machine for EAP peer and EAP
    authenticator. No changes on peer side since IETF-57.

  - The approach for the authenticator now is changed, due to comments
    on AAA interaction: three state machines:

    o Standalone (no pass-through or AAA)

    o Backend (Interfaces to AAA module (RFC3579, Diameter), EAP
      methods).

    o Full authenticator (Interfaces to lower layer (matching
      802.1X-REV), EAP methods, AAA module)

  - Discussion:

    o Bernard: What is the difference for handling tunneled methods
      (tunneled variable)?  Pasi Eronen: If you are not inside the
      tunnel, you are not allowed to do multiple authentication
      methods. Complicated, tunneled-variable will be taken out.
      Joe: Makes me somewhat nervous to have that in there.
      Bernard: For now, should be in there to stimulate discussion.

    o I'd also like to say that the quality is very good, and thank the
      authors, and tell people to set aside 4+4 hours and go and read
      it.

WG Work Items -- EAP Key Framework, Bernard Aboba
=================================================

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

  - Normative statements relating to EAP moved to RFC2284bis. As a
    result, EAP methods no longer depend on keying framework.
    Substantial revisions are in progress, currently the draft lacks a
    threat model.

  - Open issues:

    o 15 (key distr. Insecure),
    o 179 (EAP PRF), and
    o 187 (Service SAs).

  - Security issues are:

    o Key scoping: AAA protocols authenticate at NAS granularity Client
      may not be able to recognize NAS scope without assistance from
      the lower layer. Possible solutions:

      . AAA agent checks
      . Logging
      . Key Mixing
      . Method-specific binding

    o Correctness in fast handoff & context transfer

    o Lying NAS Problem

  - There were no questions.

Related Work -- Network Discovery and Selection, Farid Adrangi & Pasi Eronen
============================================================================

  - http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-and-selection-00.txt

  - Discussion scoping by Jari: there's been previous question marks on
    whether this functionality is needed. Since feedback is required
    from other organizations, and we don't have much time for
    discussion in the meeting, we will assume that network selection is
    needed. Lets use the meeting time to discuss what alternatives we
    have for providing this feature.

  - Problem: Even if you select an AP (based on e.g. SSID) you haven't
    selected a mediating network which will carry your traffic back to
    your home network

  - Farid presented examples of mediating networks, such as iPass,
    3GPP-VPLMN, GRIC.  Home service network is e.g. wireless
    provider. Access networks are public hotspot.  Problem is not AP
    selection in hotspot. EAP-based client needs information on which
    home network /mediating networks are affiliated to the access
    network.  The proposed solution complies with the EAP spec and uses
    EAP-Identity Requests to deliver network information.

  - Proposed solution is to use a "decorated NAI" inside the Identity
    Response, on first or subsequent Identity Request. Identity Request
    may carry information about the network which makes it possible for
    the peer to select an appropriate NAI (if more than one is
    available).

  - There is a 3GPP dependency for this work (3GPP TSG CN).

  - Related presentation by Pasi Eronen: Based on a discussion between
    Jari, Bernard, Pasi.

    o But other solutions are possible, e.g. SSID-based.

    o Suffix routing on a NAI is better than prefix routing.

    o If an eap-layer based solution is used, EAP identity request
      hints are probably OK.

    o The network cannot always ( and maybe should not ) do the
      selection. So information has to be provided to the users.

    o If you try to encode the mediary network information into virtual
      AP's ssid's, the amount of beacons needed might end up consuming
      a significant part of the bandwidth.

    o On the other hand, if you have to associate with each of a large
      number of APs, and start a EAP exchange with each in order to get
      the information about

  - Discussion:

    Margaret Wasserman: Are there lessons to learn from loose source
    routing? Can we become victims of single points of failure?

    Pete: Seems we are limiting us to a solution which doesn't scale
    very well. And I'm not sure we should be doing this at all.

    Bernard: Today we have internet connectivity and DNS-based
    routing. This was not possible with RADIUS.  Why are we doing this?
    It looks like there is no layer-2 alternative that can handle all
    cases.

    Margaret: Assume I can choose based on some string between
    mediating networks. Does not seem to be right as there should be
    some policy. Do we gain something over the existing solutions
    today?

    Farid: These policies can be pushed to the subsciber device
    from the home network

    Farooq: It's the home network which has to settle the roaming
    cost.

    Farid: Some users may care about QoS, some about cost. Policy can
    be pushed by the user's home network.  Margaret: There are other
    WGs that investigated the concept, should be looked at as well.
    Bernard Aboba: Take it to the list.

    Jari: We have a cost factor in selecting the right network. End
    users care about the cost.

  - Strawpoll:

    Should this be solved in the IETF? Consensus that the problem is
    worth solving.

    Should the EAP WG solve the problem? Consensus that it should be
    solved in WG, but less strong than for the first question.

  - Comment by Pasi: There are solutions that do not involve EAP at
    all. But EAP WG could be a good place to explore this.

Related Work -- EAP Key Derivation for Multiple Applications, Joe Salowey
=========================================================================

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

  - Changed the draft name to "EMSK usage guidelines"

  - 2284bis defines the EMSK. Several applications have been suggested
    that use the EMSK (eap-keying, aaaarch-handoff, eap-protectedtlv)
    The current proposal should either be incorporated into key
    framework draft, or the keying framework should reference it.

  - Jari: May be a separate specification as well. Joe: Key framework
    itself references EMSK. So either take that out, or reference it.
    Russ: Its just two pages, merge it in. Jari: Ok

Related Work - The Compound Binding Problem, Farid Adrangi (on behalf of Jose Puthenkulam)
==========================================================================================

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

  - Status update for 04 version of the draft: mostly editorial
    improvements. Three issues (64, 191, 192) are still open.  Some
    crypto experts have reviewed the draft, no issues so far.  Timeline
    is to resolve open issues this year. Revise section 4, synchronize
    with keying framework. Submit for final review in January, close in
    February 04.

  - Issue: The EMSK may not be the best thing to use for the compound
    bindings. We need to look a this

  - Bernard: We started looking at this because many other groups
    needed something like this. Now IKEv2 is doing something similar,
    and .... is doing something similar. Right now it seems like the
    IETF is going violently in different directions and we get
    incompatibilities. An there may be different views of whether there
    is a problem.

  - Russ Housley: True, need solution, proposal to formulate this in a
    few slides for broader presentation in SAAG.  Farid: his has
    already been done in former IETFs. Bernard: We got no input then.

EAP methods - EAP SIM/AKA, Pasi Eronen
======================================

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

  - No open issues with the drafts. It is part of 3GPP Release 6 WLAN
    inter-working. EAP/SIM products are available, deployment is
    beginning.  Plan is to do individual submissions as informational,
    once EAP base docs finalized.  No implications to 2284bis, state
    machine or keying framework.

EAP Methods -- PEAPv2, Jose Salowey
===================================

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

  - Recently submitted draft -07. Features are complete. Added support
    for sequences of EAP methods. Supports inner method binding.  Goal
    is to submit as informational. Currently WG item not requested.

  - Margaret: All drafts are planned to be published as
    informational. I wonder about this. Bernard: It took so long to get
    this WG started that much work was already more or less done, and
    it may be hard for people to give up change control now, and make
    these WG documents. Pasi: Correct with respect to EAP/SIM and
    EAP/AKA

EAP METHODS - EAP-IKEv2, Dirk Kroeselberg
=========================================

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

  - A number of issues have been improved in the update, e.g. error
    handling, fragmentation.  There are still open issues like
    optimizing the no. of messages, security claims section.  Another
    update planned before next IETF to address these issues.

  - Michael Richardson: Tunneling seems to be complicated, suggestion
    remove support of tunneled methods or to detail use case.  Dirk:
    True, but applies to all tunneled methods. Is only an optional
    feature in IKEv2.

  - Bernard: Is it intended to handle address assignment in EAP-IKEv2,
    do we need that?  Bernard: Are all identity payloads needed? Is
    IKEv2 a limitation in terms of identity payloads? Dirk: Need to
    check this.

EAP Methods - EAP Smartcard, Pascal Urien
=========================================

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

  - Goal of the proposal is to support EAP in smartcards. No
    discussion.

Roadmap discussion (10 minutes), WG Chairs and ADs
==================================================

  - Steven Hayes: (clarifying 3GPP position) 3GPP requires the two
    methods discussed, and network selection. Otherwise there are no
    further requirements on EAP. Request to publish EAP-SIM and EAP-AKA
    as informational.

  - Someone: Are the available methods sufficient to progress the
    documents to Draft Standard?

    Margaret: Good point. Especially for the keying framework, a method
    that uses all the features is required.

    Bernard: There is no standard method required for this, just the
    use of the features with any method.

    Russ: Requirement is two independent interoperable methods.

    Bernard: You can show interoperability without having particular
    methods showing them

    Margaret: Are all the methods done informational forever? So what
    does the EAP WG do - wait till somebody comes along with a method
    to be standardized?

    Bernard: There is one standardized mandatory method

    Russ: But that one doesn't exercise all features.

    Bernard: Somebody has to ask for a standardization effort.

    Margaret: There is no interoperability without using informational RFCs.

    Bernard: The same issue (mandate one method) has been brought to
    the group by 802.11.

    Pasi: Could update EAP-TLS as this is the only key-generating RFC
    method. Current status is experimental, however.

    Jari: Some defined methods should be standardized in their second
    revision, e.g. EAP-TLS.

    Margaret: We don't have the rule that because something has been
    deployed, it can't be a standards track document!

    Donald: It almost seems like everything developed outside never is
    to become IETF standards. We have some examples where v2 of some
    documents have become - after rework - standards track documents.

    Margaret: How will expert review differ from the expert review done
    for standards track documents.

    Bernard: The intention is to basically raise the bar for new
    methods, as many have already been allocated, but about 70 percent
    do not have a useful documentation (expert review is defined in
    2284bis).

    Bernard: If you already have a type code, it's not even sure that
    the need for expert review will get triggered. Even if you have a
    code allocated, that's not a guarantee that the RFC editor would
    publish a document, he could decide this is awful.

      (Editor's note: Margaret later sent this e-mail to the list:
      "Apparently, I said something at the EAP meeting in Minneapolis
       that has caused some confusion about the IANA allocation of EAP
       codepoints.

       Just to erase any confusion, I want to make it clear that I
       support the current wording in the EAP draft -- that EAP
       codepoints should be allocated on the basis of expert review.
       This represents an increase in scrutiny from the current policy
       (first- come- first- served), which I think is appropriate. I
       do not believe that EAP codepoints should require an IETF
       standard, and I do believe that it would be appropriate to
       allocate EAP codepoints in some situations (vendor-specific or
       environment-specific) where it wouldn't make sense to produce an
       IETF standard.

       I do hope that the WG will consider standardizing secure,
       general purpose EAP methods in the future, but I do not believe
       that we should require a standards-track document in order to
       obtain a codepoint.")

    Chris Elliot: I'd really like to se you take on methods work.

Meeting adjourned.

_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: John Vollbrecht <[email-masked]>
Date: Thu, 20 Nov 2003 16:46:50 -0500

Thanks very much for the good notes.  I have cut and pasted some comments 
below.

>        Presentations: http://www.drizzle.com/~aboba/IETF58/EAP.zip
.
.

>       the WG or as chartered EAP WG work
When will the group decide whether to work on methods?  Seems like this is 
very close.

>   -
> http://www.levkowetz.com/pub/ietf/drafts/eap/rfc2284bis/draft-ietf-eap-rf
> c2284bis-07.d.html
>
.
.
I think the identity response should be worked on by the group for the long 
term, but not as part of 2284bis.

> WG Work Items -- EAP State Machine, Pasi Eronen
As I noted in response to Pasi, I think this should stay in as well.  I 
think it says that tunnelled and non-tunnelled EAP and EAP methods have the 
same structure, except that tunnelled methods are allowed to do sequences 
of methods.
> WG Work Items -- EAP Key Framework, Bernard Aboba
I think this is good work, and is making progress.  I am confused about why 
it is not needed for methods, especially methods that generate, and 
possibly keep keys.  I would like to see at least one required to implement 
method that generates and keeps keys for anyone who implements such 
capabilities.  I don't care much which method is required, but I think that 
TLS could be one since it is widely implemented, or I personally think 
requiring an Archie method, or an IKEv2 method would be good.  I think such 
a requirement should go at least with implementing the Key Framework RFC.

I also would suggest that the document might be helped with a framework 
that    shows as outside the EAP/RADIUS framework, but that EAP/RADIUS is 
one place that it can be used.

> ===
>   -
> http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-a
> nd-selection-00.txt
>
I think a question is who interprets the identity and how is it used.  Do 
we expect the identiy response to be kept whole for the method but brokenup 
by the NAS for routing?  This seems a big question, which I think should 
not be included in 2284bis, but possibly considered by the working group.

> =================
>   -
> http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-04.txt
>
Can someone describe the different directions?

>   -
> http://www.ietf.org/internet-drafts/draft-haverinen-pppext-eap-sim-12.txt
>   -
> http://www.ietf.org/internet-drafts/draft-josefsson-pppext-eap-tls-eap-07
> .txt
>
This draft is very long, and for me sometimes confusing.  I would like to 
see an overview of what the overall flow is, including key generation and 
use, how the innner and outer keys are bound, how methods are sequenced, 
whether remote authorization over the tunnel is permitted (and what the 
reasoning is- perhaps this is here, but I am not finding it).  I also am 
confused about what the crypto binding TLV does and why it is necessary.

I think a diagram in a PDF document would be very helpful in this case, 
along with a text document, like the State Machine doc.

> EAP METHODS - EAP-IKEv2, Dirk Kroeselberg
Can just the initial authentication part of IKEv2 be used as a "norm", not 
including other payloads?

Is the "normal" authentication in IKEv2 (not EAP) without Intellectual 
Property hindrances?