.Extensible Authentication Protocol WG (eap)


THURSDAY, March 4 at 1300-1500 


CHAIRS: Bernard Aboba <aboba@internaut.com>
        Jari Arkko <Jari.Arkko@ericsson.com>


SCRIBES: Dirk Kroeselberg
         Henrik Levkowetz


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/dr
aft-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/dr
aft-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/dr
aft-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/dr
aft-ietf-eap-netsel-problem-00.txt
   - 
http://www.ietf.org/internet-drafts/dr
aft-adrangi-eap-netwo
rk-discovery-and-selection-01.txt
   - 
http://www.ietf.org/internet-drafts/dr
aft-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