Subject: [eap] preliminary meeting minutes from IETF-63

From: Jari Arkko <[email-masked]>
Date: Wed, 17 Aug 2005 17:21:51 +0300

Please send additions, corrections, and comments to the
list or to the chairs. Thank you Dirk and Jouni for taking
notes!

-----

EAP WG Meeting at IETF #63

Location: Paris, France
Date: August 2nd, 2005
Time: 14:00-16:20

Notes: Jouni korhonen and Dirk Kroeselberg (merging by Jari Arkko)

1. Preliminaries (5 min) -- Jari Arkko
   Agenda bashing
   Blue sheets and notes takers

    Arkko: Doing agenda bashing and presenting the issue tracker.
    No changes to the agenda.

2. Document Status (5 min) -- Jari Arkko

    o 2x RFCs out
    o 2x in RFC queue
        - EAP State Machine
        - EAP SIM & AKA

        o Keying framework: still some open issues

    o Netsel problem definition -> expired
        - Volunteers needed for this draft to make
          progress (several volunteers signed up later).

    o Adrangi Network discovery (draft-adrangi-eap-network-discovery-13.txt)
        - Should be in back IESG review shortly
        - Margaret Wasseman is in charge of this inividual
          draft, some discussion ongoing.

    o IANA allocatios and Individual RFC publications requested
        - EAP PAX, PSK, Smartcard Type, Double TLS, EAP IKEv2

    o EAP method revies req:
        - Double TLS, Smartcard Type, IKEv2 status currently DENIED
          pending modifications per reviewer's requests

3. Keying Framework issues (30 min) -- Joe Salowey
    Goal: Discuss issues
    http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-keying-08.txt

    Joe Salowey gives the presentation:
        - Whole thing has been split into three different documents
    o Housley-aaa-key
        - describes the general requirements for AAA key management,
          intended as BCP.
    o EAP-keying
        - Describes the existing EAP key management usage
    o EAP key management extensions
        - Describes extensions to EAP key management model.
                - 
www.drizzle.com/~aboba/EAP/draft-aboba-eap-keying-extns-00.txt
                - This is an early version.

        Jari: Are Russ' requirements binding? For
        EAP, there are pretty precise definitions of the requirements,
        what happens if there are conflicting requirements? Who gets
        to discuss the content of Russ' document? (Russ not present)

    Closed issues: 300, 305

    Issue 306: to be handled in Yoshi's presentation afterwards.

    Issues discussed today (read the slides for the content):
    294 - Analyzing existing EAP usage
        - Analyzy what (802.1X, PPP, 802,11i)
        - Analyze against (Housley criteria)
        - No one present in the meeting indicated having looked into
          this yet
        - Bernard has a detailed analysis in his site -- please comment.

    Alper: what are objectives of this analysis?
    Jari: understanding the security properties of the system
    Alper: there are a lot of systems than those 3 listed earlier
    Jari: Concentrate on known widely deployed cases.. however people
          are free to submit more analysis on other cases.
    Glen: widely deployed rules out PANA & IKEv2 etc
    Jari: that is debatable of course
    Someone: People willing to work on this is a good flow control..
             So if people are willing to work on some analysis then
             just do it.

        Action item: Hannes and Dirk will review Bernard's text and
        post comments to the list.

    ** 299 - key caching, keys internal to EAP methods may be cached
          fast re-auth etc)

    o Jari: Issue was started by confusing text mentioning key
      caching. Hopefully we can scope how we can name and cache
      these keys like EMSK etc. Should be explicitly stated what is
      cached and where

          Do we need to name the keys cached in the EAP layer?

          EMSK and AMSK may be cached outside o EAP as possible
          extension, but should be out-of-scope for the keying
          framework. Other keys (MSK/AAA-Key) do not appear to
          need caching. Also relates to naming: if they are not
          cached in EAP, do they need a name?

    Action item: Joe volunteers to write the missing text.

    ** 302 - Domino effect clarifications
    o Alper: should we use Housley as a normative reference or not?
    o Jari: Housley is supposed to cover things beyond EAP
    o Alper: What if the domino effect definition ends up in both docs?
             Then they need to be synchronized beyond recognition...
    o Jari: Agree. But in the keying framework we can state a
          very specific requirement, and verify that its fulfilled.

    Action item: Alper to take this further.

    ** 307 - deletion of the security requirements section
        o Mostly editorial.
    o Jari: Bernard already sent a text proposal, which appears to solve 
the issue.

    ** 279 -  Additional keying protocol requirements

        #307 may already remove the need for this. But need to make
        sure we cover these already.

    o Jari: Main thing is staying with the current system and not to look
            into stuff like fast handoffs
    o Jari: Any volunteer to go through Jesse's issue?
    o Joe: lets assign this to him..

        Action item: Jari to ask Jesse Walker to check whether the new
        draft covers his requirements.

    ** Next steps
    o More people are needed to review this draft.
          Please review -08 version on Bernards web site.

        o 09 version in approx. 6 weeks. WGLC for this version,
          revised final for IETF-64

        o Review draft-housley (AAA keying requirements) and resolve
          possible issues

        o Continue with extensions after IETF-64 and beyond.

4. Channel Bindings
   Goal: Discuss definitions, alternative schemes
   http://www.drizzle.com/~aboba/EAP/draft-ietf-eap-keying-08.txt
   http://www.ietf.org/internet-drafts/
    draft-ohba-eap-aaakey-binding-01.txt
    and draft-arkko-eap-service-identity-auth-03.txt

   Yoshihiro Obha gives the presentation on lower layer parameter & channel
   bindings (read the slides for then content):

   Background for the discussion explained by Jari: Yoshi has a draft which
   suggests a channel binding mechanism which, if adopted, needs to go to
   the keying framework document so that the key calculation rules can
   be documented and standardized. Lets focus on the question if this is
   the way to go for the keying framework discussion or not.

   Ohba: Yoshi's draft is based on the list discussion on alternatives
   for this.

   The draft defines a key binding blob carrying lower layer
   information. The blob is sent by the authenticator to the server,
   and is an input to the key derivation. If the lower layer
   parameters of EAP peer and authenticator do not match, the
   lower-layer security cannot be successfully established (keys of
   supplicant and authenticator not matching).

   The solution impacts the AAA protocol (e.g. new Radius attribute),
   but its advantage is that it works for all EAP methods without
   requiring an extension to them. Main drawback is impact to deployed
   APs, and possible also to lower layers protocols such as 802.11.
 
   Pasi: Does not work with existing 802.11 access points.
   Yoshi: Yes, in this case AP can still use the legacy version, then
   EAP method support for channel binding would be required.

   Pasi: There are code changes?
   Obha: Yes.

   Joe: This should not be part of current keying framework, needs to many
   changes to existing stuff.

   John: Naming (channel binding) should be changed, since exact
   problem is not clear.

   Jari: Does not really belong into Housley document. Housley does not
   have much text HOW to implement these things.

   Joe: We need to clearer what problem we are trying to solve. The
   channel binding name might be slightly misnomer.

   Glen: EAP is so mixed up with AAA stuff, which causes lots of
   trouble. Probably belongs into the protocol, but it is not EAP.

   Pasi: Some documents call this \u201cthe EAP system\u201d, which is
   EAP plus other things. This is really the scope of the keying
   framework.

   Jari: Sounds like Yoshi's draft should not be part of keying
   framework. It may be worked on separately later, however.

5. Methods Discussion (40 min)
   Goal: Talk about the results of the reviews, make progress
 
   EAP PSK Review (10 min) -- J. Walker
   http://www.ietf.org/internet-drafts/draft-bersani-eap-psk-08.txt

        Independent submission to IESG. Requested EAP method type
        number. Reviewed by Jesse Walker in June. Update integrating
        some review points in -08 version.  Still number of open
        issues, e.g. for key derivation. Key naming is not planned,
        since there is no application like fast reconnect. Discussion
        will be continued on list.

    Hannes: On key control issue: it wouldn't add more complexity to
            include it here.
    Bersani: ok, moving on adding the key control

    Jari: The right process for this is to talk about the issues and
        gather more expert reviews on the list

    Hannes: I am one of the authors of PSK, Jesse actually
    criticized some things he originally proposed so we are a bit
    confused what he wants.

   EAP IKEv2 Review (10 min) -- P. Eronen
   http://www.ietf.org/internet-drafts/draft-tschofenig-eap-ikev2-07.txt

    Pasi likes the approach, but document not considered ready.
    Inaccurate comparison to EAP-TLS mostly fixed in -07 version.
    Major issues e.g. with current fragmentation mechanism (since
    EAP is lock-step), fast reconnect does not clarify how the
    server picks the correct key, channel binding. Needs more
    work, but no major obstacles found.

    Dirk: Channel binding was not updated since authors had to
            wait for the outcome of Yoshi's proposal on channel binding.
    Hannes: Thanks to Pasi for the review. One additional issue on
            channel binding.. Could we come up with our own solution or
            reference to something (and if so to what?)
    Pasi: There are 2 ways how to do channel bindings (Obha and Pasi & 
Jari) no
          selection which one has been made
    Jari: I think we can do a decision on channel binding in the list
          after the meeting, which one of the two to select. We will send
          a question to the mailing list how to proceed with channel
          bindings.

   EAP Smartcard Type Review (5 min) -- G. Zorn
   http://www.ietf.org/internet-drafts/draft-urien-eap-smartcard-type-02.txt

       There are already a number of EAP methods on token or smartcard
       types.  Expert review has been performed by Glen Zorn.  Answers
       to the review comments: see presentation slides.  Pascal
       disagrees with review comments in a few points, e.g. on the
       IANA requirements compliance.  Some discussion about security
       claims. Glenn: Either take out security claims altogether, but
       then it must be clear that the method itself has no security
       properties.

       Jari: Running out of time, discuss this in the mailing list

   EAP Double TLS Review (5 min) -- H. Tschofenig
   http://www.ietf.org/internet-drafts/draft-badra-double-tls-03.txt

        Found some confusing text about "inner" method. Many optional parts
        make analysis quite difficult. Some issues, e.g. key strength and
        hierarchy not properly documented. Crypto-binding still needs
        investigation.

        Relation to other TLS methods is important to be discussed, but has
        not been subject of review.

        Pascal: Just motivate goal of the draft. This is to use
        TLS-based shared key authentication.

    Jari: More discussion on the mailing list.

   EAP PAX Update (5 min) -- T. Clancy
   http://www.cs.umd.edu/~clancy/eap-pax/draft-clancy-eap-pax-04.txt

    - HostAP has an implementation of the EAP-PAX..
    - IANA has allocated numbers
    - Would like to move it to standards track document either in this
      WG or in SECMECH

   Methods Work Situation Info (5 min) -- Jari Arkko

    Jari thanks the reviewers.

        Hopefully we will be able to work on few methods to get them
        into standards track, either here or in SECMECH. Please
        inform the list and the IESG on what needs to happen on
        this front.

6. Trusted Computing Group EAP Issues (20 min) -- John V.

    See the slides for the main content. Note: Different naming
    for lower layer nodes and functions in TNC than in IETF.

        General idea is to check client state before allowing network
        access (quarantined).  For EAP, TNC is considering a new EAP
        method (protected method, inner method carried by outer
        method). This method could map to IF-TNCCS (see slides). The
        presentation is meant to seek feedback from the IETF EAP
        community, maybe create a formal liaison later on. Possible
        work could be a protected method, a generic "outer method", or
        inner method keying requirements in the keying framework.

    Jari: If you want more feedback on this.. Do you have anything else
          than these slides??
    John: We have some but not all are publicly available. A
          participation to the consortium is generally required.
          May need a formal liaison, since TCG is a closed
          group. If such a method will be specified in IETF,
          this needs to be worked out.
    Jari: That has worked out earlier.. e.g. a certain consortium allows
          access to relevant documents for a certain WG.
    John: No standard "outer" method for protected EAP methods still
          exists. And is it possible to add "inner" capabilities to
          existing or planned methods??
    Pasi: Sounds interesting and worth doing. Maybe without the help of
          EAP group. And we need those documents.
    Hannes: Also likes the idea.. Security Ads won't like this however..
                Many of these things have already been
                discussed. But don't start with one specific tunnel
                method.  The tunneled method might be inefficient as
                everything can be run inside the tunnel
    Jari: Tunnel methods can sometimes be used to avoid the IANA
              registration rules :)
    Glen: EAP specs currently do not define sequencing details,
              I thought that was clearly outlawed!
    Alper: Why?
    Glen: It was not allowed to run a sequence of EAP authentications.
    Alper: The latest 802.16e supports sequencing.
        Glenn: But this is not supported by the EAP spec
        Alper: These are two independent EAP sessions. However,
        discussion in IEEE is already closed.
    Jari: Volunteers to review for TCG..? Contact Jari.

7. EAP Enrollment (5 min) -- Rohan Mahy
   http://www.ietf.org/internet-drafts/draft-mahy-eap-enrollment-00.txt

   Motivation is that small wireless devices (e.g. phones) are a pain
   to enrol onto WLANs.  Basic proposal is to start with some weak
   credentials and then let the client fetch stronger credentials
   after that. Use existing methods. Presentation just seeks thoughts
   on this.

    Hannes: Very good thoughts and has also been thought here in
      this and other WGs earlier. Why we never managed to move this
    forward earlier?
    Alper: It goes back EAP applicability statement.

        Hannes: a number of methods provide the capability to
        exchange config parameters. Want to see some guidance on how
        to move things forward.

        Someone: Does not believe that a strong credential is better if
        authentication is started with weak credentials before.
        Rohan: but the server is authenticated.

        Jari: sorry, we are sort of pushed out of the room
        now. Hannes, do you think there is a general solution?
        Hannes: personal opinion that this could be a general
        solution. Enrol would be a valid place to drive this.

        Jari: Further discuss this on the list, need to get this done
        somehow.

8. Meeting concluded 16:20

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