Subject: [eap] ietf-59 meeting minutes

From: Jari Arkko <[email-masked]>
Date: Wed, 24 Mar 2004 15:30:18 +0200

Thanks to Dirk and Henrik for taking minutes.
I'll submit the minutes to the proceedings
early next week, so if you want to clarify
something in the minutes, send e-mail before
that.

----

Extensible Authentication Protocol WG (eap)

THURSDAY, March 4 at 1300-1500

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

SCRIBES: Dirk Kroeselberg
          Henrik Levkowetz

PRESENTATIONS: http://www.arkko.com/publications/eap/ietf-59

No changes to agenda.

1. Status update (Jari)

- 2284bis has been approved as an RFC, IANA process will take some
   time...

- The state machine -02 draft is currently in 2nd WG last call. Read
   the document and send comments.

- The keying framework has not been updated since last IETF. Still has
   open issues. Current plan is to finish this in September 04. For
   this to go forward needs participation and input from the workgroup

- Draft-ietf-eap-netsel-problem-00.txt on network selection has been
   submitted as input to 3GPP, IEEE, some feedback is available.

- Binding problem definition: no update available.

- EAP-over Radius approved as RFC3579; EAP-Diameter is in AAA WG LC.

- EAP over diameter in aaa wg last call, read and comment

- A NAI (RFC2486bis) update is available in
   draft-arkko-roamops-rfc2486bis-00.txt.

- Methods can be submitted

- Lot of recent method activity.

- Since 2284bis was approved, expert review for IANA method allocation
   is necessary.

No comments on Jari's status update.

2. EAP State machine (Pasi Eronen)
    Drafts:
    - http://www.ietf.org/internet-drafts/draft-ietf-eap-statemachine-02.pdf
    Issues:
    - http://www.drizzle.com/~aboba/EAP/eapissues.html

A number of issues were found during 1st WGLC. The authors hope to
have addressed them all. Issue owners are requested to check whether
the issues are properly addressed in the draft.  The document does not
address tunneled methods any more.

Issues:

- Peer-to-peer operation: The authors believe no changes are
   necessary, considering IEEE.

- RFC editor issue: State diagrams will be provided in ASCII.

3. Keying framework issues (Pasi):
    Drafts:
    - http://www.ietf.org/internet-drafts/draft-ietf-eap-keying-01.txt
    - http://ietf.levkowetz.com/drafts/eap/keying/
    Issues:
    - http://www.drizzle.com/~aboba/EAP/eapissues.html

Presented by Pasi, since Bernard was not present.  There was no update
since IETF-58. A new version is in preparation. There are certain open
issues:

- AAA-Key vs. MSK: In normal 802.11i, AAA-Key=MSK. This may be different
   for lying-NAS.  The lying-NAS problem, however, can be solved by
   providing "channel bindings" in EAP methods rather than
   specifying AAA-Key=PRF(...). Solving the lying-NAS is not considered
   urgent.  The new draft will discuss channel binding issues.

   Alper Yegin: Are there general guidelines for when to set AAA-Key to
   MSK?

   Pasi: proposal is to set AAA-Key=MSK in general.

   Jari: This implies the MSK is reserved as AAA key only. If something
   else is to be done, e.g. for fast handoff, use EMSK.

- Issue 221: EMSK: draft-salowey-eap-key-deriv-02 will be included in
   the keying framework. This will mandate a prf: IKEv2 prf+ with
   HMAC-SHA-1.

   Florent: Why do we have to specify how to derive keys, instead of
   specifying that they have to be cryptographically independent?

   Pasi: If you use 2 different PRFs there is no guarantee that they
   are cryptographically independent, so we need to specify this.

   Jari: Does it have to be the same PRF for all keys for one session,
   or for all sessions?

   Pasi:	All sessions

   Jari: If this is done in the method, the method can still negotiate
   other prfs.

   Simon(?): We don't need a prf here. Why is the HMAC used.

   Pasi: This is the way it is typically done. Do not want to invent
   anything new.

4. Binding problem update, Farid Adrangi, (5 min)
    Drafts:
    - http://www.ietf.org/internet-drafts/draft-puthenkulam-eap-binding-04.txt
    Issues:
    - http://www.drizzle.com/~aboba/EAP/eapissues.html

   Version 4 of the draft is available for
   review. Version 5 is currently being worked on for next IETF.

   Update plan is to synchronize the draft with keying framework.  The
   authors want to verify if this understanding is correct:

   - Compound binding MAC key - EMSK
   - Compound session key - MSK

   (please comment)

   Jari: Are people referring to this draft when developing new
   methods? Have people checked whether the solutions e.g. of IKEv2 or
   PEAPv2 conform to the draft? Otherwise it may not have much
   relevance.

   Glenn: Does the draft solve any problem at all? In fact there is no
   MITM attack. It is a combination of other attacks where the draft
   does not help. The draft only solves a small subset that can easily
   be bypassed.

   If an evil access point negotiates plaintext passwords, any keys can
   be derived.  If you cannot negotiate down from PEAP, there is no
   MitM attack. The draft's assumptions are ill-specified.

   Jari: Can't say that I agree, have to think about it.  Needs to be
   discussed, please post to the list

   Glenn: Done, stunning silence.

   Jari:	Document useless?

   Glenn: No, it points out valid things for tunneled methods, but it does not solve the problem it poses.

   Jari: Please comment on the list

5. Network selection, Farid Adrangi, Jari Arkko (25 min)
    Drafts:
    - http://www.ietf.org/internet-drafts/draft-ietf-eap-netsel-problem-00.txt
    - http://www.ietf.org/internet-drafts/draft-adrangi-eap-network-discovery-and-selection-01.txt
    - http://www.ietf.org/internet-drafts/draft-arkko-roamops-rfc2486bis-00.txt

   Presentation by Jari/Farid:

   Network selection comes with multiple problems:
   1.	Access network discovery
   2.	Identifier selection
   3.	Selection of roaming intermediaries
   4.	Payload routing

   Activities to perform are
   -	Discovery
   -	Decision
   -	Indicating the selected network

   Recommendations
   * All 4 problems are relevant
   * Potential need for new solutions

   These problems are _really_ _really_ hard if
   * there are a lot of networks
   * you want to do it securely
   * there are many different ways to do this

   Given that the problem _is_ hard, it may be that we can't solve it
   all now.

   3GPP and 802.11 were requested to provide feedback:

   3GPP SA2 WLAN group:
   - problems 1 and 3 are relevant to 3gpp, but not the others.
   - 3gpp uses existing l2 mechanisms for problem 1
   - they expect an IETF solution to problem 3 for Release 6 (pretty soon)

   IEEE 802.11 meeting summary
   - alternatives are relevant for one of their study groups
   - they don't know what kind of solutions they need now
   - other groups also working on related problems

   * Solution space
   - Believe there is interest in problems 1 and 3
   - Pretty clear problem 1 belongs to link layer
   - Problem 3 belongs at least in part in IETF. There may be
     mechanisms at lower layers that effectively advertise relevant
     information also for higher levels than L2
   - If there's an IETF intermediary solution, it will probably be
     relatively short-term
   - We already today have configured databases on the client, and
     advertised information; must be able to switch to other source.
   - NAIs discussed in roamops draft

   Osok: SA2 ready to use EAP based solutions not only for problem 3
   but also for problem 1.  Agreed that ESSID cannot always be used to
   select access point.

   Farid: Problems 1 and 3 may be intertwined, may need to do 1 based
   on result of 3

   Osok: Cannot use ESSID only, also in situations where we don't want

   David Johnston (Chair of 802.21 group): There are ways of doing link
   layer discovery and maybe better ways upcoming. 802.21 is talking
   about providing media-independent link-layer discovery. EAP may be
   viable for the near-term, but the critical part is the information
   in the discovery. This information needs to map into a wider
   information model used by 3GPP, IEEE, etc.

   Glenn: The only reason this needs to be in EAP is that - We're
   selecting from private networks here - commercial or not - and have
   to select the path of the aaa packets because providers won't carry
   other people's aaa packets.

   Serge Manning: Don't know if EAP solutions are the best, but even if
   .21 comes up with something, we'll have to be able to work with
   existing .11 APs

   Pasi: Why is aaa routing difficult - all AccessAccept packets
   forwarded indicates willingness to carry the traffic of somebody,
   and may result in monetary pain if you do it without getting paid

   Glenn: Forwarding of aaa packet is an implied contract? The routing
   of aaa packets? How can that be?? That's crazy!

   Pasi: The AAA signaling is about accepting responsibility to cover
   costs. The operators want to be in control.

   Glenn: Have to pick what network to carry your traffic, that's
   ok. And you have to have an agreement between providers. But just
   _forwarding_ the aaa packets, to set up the correct route for
   traffic should not be a problem.

   Jari: Two problems, finding an access network and selecting who is
   to carry the traffic.

   Glenn: The first part I understand, but not why the rest of the
   stuff has to be done in EAP.

   Farid: Selecting mediating networks is required by 3GPP, operators
   etc.

   Jari: Discuss this offline.

   Someone: Are there plans to have PP2 review this as well? They do
   not have problem 3, but the others.

   Jari: I have received unofficial indications that they are fine with
   what IEEE does.

   Farid's presentation on 3GPP approach: EAP-based mediating network selection

   Use case 1: WLAN client moves into a hotspot advertising the clients
   HSN SSID.

   Use case 2 : WLAN client moves into hotspot advertising one or more
   of WLAN clients HSN roaming partner SSIDs but not its HSN SSID.

   Use case 3: WLAN client moves into a hotspot advertising only
   unrecognized SSIDs (continued).

   Different agreements between hotspots, mediating networks and HSN are
   in place. How to find the best path? (e.g. unrecognized SSID belongs
   to a HSN that has a roaming agreement with a specific mediating
   network only. The hotspot could have an agreement with one HSN only)

   Alper: Can there be more than one mediating network in the path?

   Farid: 3GPP only considers one level of indirection.

   Lauri: Is there any implicit assumption that client will have to
   know paths through the net?

   Farid: No, looks up each intermediary network discovered in an
   preconfigured database.

   Problem scope:
   Access network selection, mediating network selection.
   Presentation solution overview for each scenario.

   Solution proposed:
   - complies with 2284bis, uses 2486bis bang syntax
   - may not require any changes to access points
   - uses EAP Identity Rewquest to deliver identities from the local
     aaa server

   Jari's presentation on next steps for network selection:

   - need to ask IEEE 802 whether discovery part of problem 3 is being
     considered, and when results would be available.

   - need a clear problem definition as input for the groups working on
     the long-term L2 solutions.

   - need to decide how to accommodate the selection of roaming
     intermediaries; bang syntax?
     - next steps for the NAIbis update are currently being discussed
       with ADs
     - this will not be part of the EAP WG

   - need to decide how roaming discovery is performed
     - wait for final l2 solution
     - short-term solution now until L2 solution arrives

   Comment by 802.21 chair: Both solutions are appropriate.

   Jari: What to do:
   - We could turn this entirely over to future Layer 2 mechanisms
   - We could handle this within EAP, according to Farid's draft or similar
   - We could leave this up to individual vendors and proprietary solutions
   - We could decide to do nothing.

   L2 is the best scheme efficiency-wise. Needs at least a firmware
   upgrade. Farid's draft: no AP upgrades if done from AAA proxy. Fast
   to specify. Not very clean way, but only short-term solution.
   Vendor-specific: Might get many, even from SDOs.

   Alper: Why does the first option pass information between EAP and L2?
   Jari: If the lower layer discovers something, it is passed up?
   Alper: Could use PANA to do discovery at lower level..

   Glenn: If these are private networks, they can do it on their own,
   without any standard. Goes back to the point: Who cares if there are
   many?

   Farid: Many solutions create market fragmentation

   Jari: France telecom may have their own scheme, but they won't have
   their own Windows or their own phone.

   Glenn: Informational is not enough, Standard is going to be required
   to make vendors pick it up.

   Jari: There are tradeoffs with the vendor-specific thing

   Steven Hayes (3G-IETF coordinator): 3GPP timeframe needs clear
   indication where IETF wants to go on this problem. Stage3 work needs
   to be done in about 6 Months. Better for the market not to have a
   "vendor" solution.

   Yoshi Ohba: Don't prefer any particular solution, but needs to
   consider threats.  Farid's proposal has weaknesses.

   Jari: AAA works within the constraints of the contracts in place. So
   security problems in network are limited.

   Cisco guy (speaking as 3GPP2 member): Question to Steve (3G),
   whether there is any preference.

   Steven: 3GPP preference is to progress Farid's draft which is the
   quickest solution.

   Strawpoll:
   - Option 1: ~3
   - Option 2: ~11
   - Option 3: ~2
   - Option 4: ~1

   Alper: If we go for option 2, will we still come up with
   recommendations for L2 designers?

   Jari: Yes, that is an issue, but session needs to move on.

   Steven: What is the time plan?

   Jari: We have consensus here on working on this, but we need to ask
   the same question on the mailing list.

6. Methods update, Jari Arkko (15 min)

   Current state:
   - only 4 methods in RFC
   - There are lots of methods in Internet drafts, lots of old/expired
     ones, or even undocumented methods (almost the majority).

   Conclusion: This is not good.
   - Many methods have a similar intent like tunneling methods.
   - There were many requests to IANA before 2284bis was approved.
   - Now after 2284 bis approval, you either use the vendor-specific
     method way defined there, or you do a draft and get expert review.

7. New method presentations:

EAP Bluetooth (Hamsang Kim, INRIA):

   - Scenario is a Bluetooth zone, e.g. in a Wi-Fi
     network. Infrastructure-based methods (EAP/AAA) are considered
     useful here. Scenario includes wireless station (STA), AP, AS.
   - Objective is to support Bluetooth security.
   - Approach is EAP over EAP. Relies on generic EAP protocols
     (e.g. EAP-TLS).
   - Additional backend exchanges are required, and still need to be
     defined. Draft has been sent to Bluetooth SDO for comments.
   - Comments on the EAP list are solicited.

   Jari: Send comments to the list, as we are running out of time.

EAP-PSK (Florent Bersani):

   - Defines a simple symmetric-key EAP method
   - Uses AES-128 as its sole primitive.
   - It is designed with WLAN in mind.
   - It is currently being implemented, sources will be made available.
   - Should be mature at next IETF. According to the presenter the
     method is IPR-free.

8. 802.11 requirements, Jari:

   - We have request from IEEE to publish EAP method requirements
     (draft-jwalker-...). This is currently in IESG last call.  Please
     review and send comments to the list.

   Question: How can we move forward to have a method standardized
   Jari: This needs to be discussed with the ADs.

9. Pasi (IKEv2 and EAP):

   Draft with Hannes Tschofenig. IKEv2 supports EAP authentication. It
   has specific requirements to EAP methods.  The draft explores how to
   skip public-key signatures (that is mandated in IKEv2 for the
   responder-side) for strong EAP methods. This avoids unnecessary
   PKIs. An example method is EAP-AKA.  First draft explores various
   alternatives how to implement this in IKEv2. Comments are welcome.

   Question: How to take this forward? Is the EAP WG the right place?
   Pasi: IPsec does not take new work items. So possibly an individual
   submission?
   Jari: Talk to the security ADs
   Steve Bellovin: Be cautions about modifications to IKEv2. Extensions
   are ok, but do not modify.
   Pasi: The proposal has an option to avoid such changes.

   Someone: Is there any overhead for EAP mutual auth.?
   Pasi: No, the overhead is actually the IKEv2 server authentication.

   Darryl Piper: Is there a requirements document associated with this?
   As an IKEv2 person I'm a bit curious about the motivation for this
   draft.  Don't see a point of forking off an EAP investigation on
   adding authentication to IKEv2, we have enough problem with getting
   the 5 or so we have to work together.

   Pasi: It seems the motivation is that this IKEv2 feature is not only
   used for legacy-EAP.

   Darryl: There should be a requirements doc.

   Jari: As the draft is short, it does not make sense to have a
   separate requirements document. Work is grown out of discussion in
   IPsec mailing list. It is motivated by 3GPP work, as there mutually
   authenticating EAP methods are already in place.

10. Further announcements:

802.1X/EAP ad-hoc interop test (Karen O'Donoghue).
   - Planned April 4-7, 2004 in Las Vegas.
   - Follow-on to similar event last year.

Announcement on Free Radius (Michael Haberler):
   - EAP-SIM implementation status (Internet foundation Austria)
   - Available as module of freeradius in the CVS tree on
     www.freeradius.org
   - Done by Michael Richardson. Part of openlx project.
   - EAP-SIM supplicant: online on www.open1x.org
   - Some interop tests done with Cisco, Nokia and others. In the pipe:
     Cisco windows dll.
   - Next step is to integrate (U)SIM cards, implement
     EAP-AKA. Implement RFC3310 http/digest, www.iptel.org

11. Meeting concluded

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