eap Mailing List: ietf-59 meeting minutes

[Jari Arkko (jari.arkko]

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 <aboba [at] internaut.com>
        Jari Arkko <Jari.Arkko [at] ericsson.com>

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