Subject: [eap] minutes from the interim meeting

From: Jari Arkko <[email-masked]>
Date: Thu, 30 Oct 2003 07:16:55 +0200

Extensible Authentication Protocol (eap) Interim Meeting
Herndon, VA
October 15, 2003
0900 - 1230 EAP WG Interim Meeting
1330 - 1700 EAP WG - IEEE 802.11i Joint Meeting

Chair(s):
Bernard Aboba <[email-masked]>
Jari Arkko <[email-masked]>

READING MATERIAL
================

o  General Information:
    http://www.drizzle.com/~aboba/EAP/interim.txt

o  EAP Key Framework
    http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-00.txt

o  EAP State Machine
    http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-00.txt
    http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-00.pdf

o  RFC 2284bis
    http://www.ietf.org/internet-drafts/draft-ietf-eap-rfc2284bis-06.txt

o  IEEE 802.11i D6.0
    http://grouper.ieee.org/groups/802/11/private/Draft_Standards/11i/802.11i-D6.0.pdf
    Userid: p8021
    password: go_wildcats

o  IEEE 802.1X-REV-D7.1
    http://www.ieee802.org/1/files/private/x-REV-drafts/d7/802-1X-REV-d7-1.pdf

PRELIMINARIES
=============

o  Agenda Bashing

    No comments.

o  Bluesheets

    Participants:

o  Minutes

    Taken by Joe Salowey and John Vollbrecth (thanks!), merged by Jari
    Arkko.

o  Document Status

    Jari went through the document status, as described in
    http://www.drizzle.com/~aboba/EAP/int-03/eap_oct03interim_agenda.ppt

    - 2284bis has passed WG last call in AD evaluation Queue.

    - State machine is now a Working Group document. Two open issues
      to resolve with .1X (modifications will be made to the .1aa to
      fix this).  A WG Last Call will be issued soon. There is still
      time to get changes into .1aa Call for implementers to verify
      state machine. Testing organizations are developing conformance
      tests based on this draft.

      Not clear who is or will review this. Probably need
      implementations to check it -- maybe Yoshihiro will implement
      it. Has been released to 1.X and 11i for review, but not much
      feedback yet.

    - EAP Keying framework. This is also now Working Group document.
      More work is needed on it, though.

      This isn't a dependency of 2284bis. All requirements have been
      moved to 2284bis.

      Keying framework being copied by 11i, not pointed to -- mainly a
      timing issue.

      Diameter EAP depends on Keying Framework (RADIUS can also use it,
      probably based on Diameter work).

    - EAP RADIUS, RFC 3579, has been approved and published.

    - EAP Diameter, draft-ietf-aaa-eap-02.txt is being worked on in
      AAA WG.

    - Methods: There are several Internet Drafts on methods. As 2284
      progresses it should be possible to move these forward, however
      it is not exactly clear yet -- discussions
      ongoing with the IESG.

      Not in charter to work on Methods.  Individual methods may be
      individual/informational or may become working group items.
      Presumably charter would have to change to support this.

      Additional mandatory to implement mechanisms: Different
      requirements for different applications, no one method meets
      everyone's needs. Develop methods first and then see if agreement
      can be reached.

      Tunnelled methods have different requirement from 2284;
      requirements will likely be defined in methods.  discussion of
      what interface is required and how methods using tunneled methods
      interface. Some discussion that timeframe for definining
      anything in ietf will be too late to impact implementation.

      Methods can be coordinated as has been done with SIM and AKA.

      Public Key methods not widely discussed. Comments on Archie and
      IKEV2.

EAP KEY FRAMEWORK I
===================

o  Open Issues - Bernard Aboba

    http://www.drizzle.com/~aboba/EAP/eapissues.html

    Issue 179: EAP-PRF issue raised by Uri Blumenthal. PRFs are
    required for derivation of keys from the EMSK.  Some of the
    described PRFs associated with this issue may have IPR associated
    with them. Question is do we need a single PRF?  Many PRFs are
    described/implemented and ok. It would be good to pick one for
    interoperability. But people felt uncomfortable with a new PRF, and
    the proposal is to reject this issue.

    Issue 180: SA description. New text under discussion this meeting

    Issue 182: Authorization issues. New text incorporated into latest
    draft.

    Jari: Some additional issues have been opened since these slides.
    Minor things, however.

o  Conversation Overview - Pasi Eronen

    Pasi presented EAP Keying phases as in
    http://www.drizzle.com/~aboba/EAP/int-03/eap_interim_slides.ppt

    There are three main phases, only one of which is EAP. Note that
    the discussion and implementation is only partly EAP.

    (0)  Discovery

         This is out of the scope of EAP, discovery handled by PPPoE or
         802.1x for example.

    (1a) EAP-authentication

         Authenticate EAP Peer and EAP Server.

    (1b) Access-Authorization

         Provide keying material and EAP authorizations to
         authenticator. Note that 1a and 1b typically overlap.

    (2)  Service Authentication

         For instance, 802.11i four-way exchange.

         Setup protection and negotiate parameters for services.
         Authentication may not be the best name for this process since
         no real authentication takes place. Key material from EAP is
         used in this phase. Not all of the parameter negotiation may
         be protected.

    Discussion in comparison of the proposed model with Kerberos. The trust
    model is very similar. All parties trust the AAA server which acts
    similar to a KDC.  The AAA access accept contains information that would
    be contained in a kerberos ticket. It could be possible for EAP methods
    to work like kerberos.  Instead of sending keys through AAA, credentials
    could be returned in EAP to the client. The client could use these
    credentials to establish phase 2. Perhaps this should be explored more.

o  Malicious AP problem, Pasi Eronen

    Continuing with the same slides as above.

    An AP can represent one set of information to the client and a different
    set of information to the AAA.  In particular it can do this with the
    SSID.  The SSID could be authenticated by one of the following methods:

    1. Incorporate it into key derivation

    2. Exchange the SSID in the authentication mechanism as authorization
       data.

    It would be best to have a generic means of authenticating arbitrary
    authorization data within the EAP channel. Existing mechanism such as
    EAP-TLS may be able to include authorization data (SSID) in a server
    certificate.  It is not clear how useful this would be.

    Is SSID spoofing a problem?  It is not clear that SSID spoofing is a
    problem that needs to be solved. The consensus at the interim meeting
    is that no one required this problem to be solved.

o  Security Associations - Pasi Eronen

    Security association Discussion, continuing with the
    same slides as above. There are the following SAs:

    - Long Term EAP-SA

      This is a long term security relationship based on a password,
      public key pair or shared secret.  Security is probably not the
      appropriate term for this, for public key Trust Anchor, for
      secret key security relationship?

    - Short term EAP-SA

      This was defined as an EAP method SA to support fast resume
      functionality.  It is not used external to the mechanism.

    - AAA SA

      Security association between AAA and authenticator based on
      shared secret, IPSEC or TLS.

    - Service SAs

      Service SAs are between the EAP-Peer and authenticator. They
      combine information from EAP, service negotiation and
      discovery. They are based on keying material from EAP.

    Discussion about whether MSK and EMSK state (or keys derived from
    that state) may be maintained on AAA for various reasons (Fast
    Handoff for example). This state would then be like security
    association derived from EAP. Currently this is not well defined
    and AAA implementations usually destroy the state after keys are
    distributed to the authenticator.

    Discussion of 802.11i specific service SAs:

    - PTKSA

      Created by 4 way handshake

      Addresses, PTK, Ciphersuite, cipher data(new), lifetime(new),
      reference to PMKSA (new not in document), authorization
      information (SSID, L2 filters, accounting)

    - PMKSA

      PMKID, PMK, SSID, sharing PMK between

    The keying document should describe problems with Using the AAA-Key
    directly. Pre 802.11i WEP can be used as an example. Note that
    Pasi's document has generic info as well as examples. The slides
    show only the examples. Discussion of whether examples belong in
    document.

EAP KEY FRAMEWORK II
====================

o  Key Scoping & Fast Handoff - Bernard Aboba
8o-09
    Postponed due to lack of time.

o  Authorization & Fast handoff - Jari Arkko

    Postponed due to lack of time.

o  Diameter EAP - Pasi Eronen & Jari Arkko

    An "AAA-Token" should consist of:
    - authorization AVP
    - key

    The key attribute only contains a key and is not a group attribute.
    Does a key name need to be included?

    If keys are derived from the EMSK or MSK and are cached then there
    is a reason to name them.  This name should be derived from the EAP
    mechanism so both EAP-Peer and Eap-Authenticator need to know the
    name.  If keys are going to be cached on the authenticator then AAA
    may need to return a name.

    Some discussion on naming techniques.  802.11i currently hashes the
    PMK with a known quantity to generate a name.  There was some
    reservation expressed as to whether this was a good idea or not.
    It would be better if the EAP mechanism derived a key that was not
    a direct static function of the key.

    Naming issues for SA's particularly the long term Key between the
    client and AAA server. There is some confusion about whether the
    key can be a Master Key and if it is different if a public key is
    used. We did not come to closure about this, but noted that Russ
    has requirement that there be a name. (Some discussion that name
    allows SA to be destroyed/tracked.)

AFTERNOON MEETING WITH IEEE
===========================

o  Minutes will be provided separately

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