The IETF Extensible Authentication Protocol (EAP) Working Group

1
The IETFExtensible Authentication Protocol
(EAP)Working Group

• http//www.drizzle.com/EAP/int-03
• Interim Meeting
• Joint Discussion with IEEE 802.11i Ad Hoc
• October 15th, 2003

2
Agenda, 0900-1200 (EAP WG)

• Preliminaries (10 min)
• Agenda bashing
• Blue sheets and notes takers
• Document status
• EAP Key Framework
• Open Issues (10 min) -- Bernard Aboba
• - http//www.drizzle.com/aboba/EAP/eapissues.htm
  l
• Conversation phases (20 min) -- Pasi Eronen
• Security Associations (50 min) -- Pasi Eronen

3
IETF EAP WG andIEEE 802.11iJoint Discussion

• http//www.drizzle.com/EAP/int-03
• October 15th, 2003

4
Agenda, 1330-1700 (EAP WG and 11i)

• Preliminaries (10 min)
• Agenda bashing
• Blue sheets, notes takers
• Document Status
• IETF Document Status and Process -- Bernard
  Aboba
• IEEE Document Status and Process -- Dave Halaz
• Specific Technical Issues
• Key scoping and fast handoff (30 min) -- Bernard
  Aboba
• Authorization issues and fast handoff (20 min)
  -- Jari Arkko
• Fast roaming implementation results (30 min) --
  Bill Arbaugh
• Open Discussion
• Conclusions and Next Steps

5
Reading Materials

• Slides
• http//www.drizzle.com/aboba/EAP/int-03
• EAP Key Framework
• http//www.ietf.org/internet-drafts/draft-ietf-eap
  -keying-00.txt
• EAP State Machine
• http//www.ietf.org/internet-drafts/draft-ietf-eap
  -statemachine-00.pdf
• EAP Base Specification
• http//www.ietf.org/internet-drafts/draft-ietf-eap
  -rfc2284bis-06.txt
• EAP Open Issues
• http//www.drizzle.com/aboba/EAP/eapissues.html
• IEEE 802.11i Drafts
• Userid p8021, Password go_wildcats
• http//grouper.ieee.org/groups/802/11/Private/Draf
  t_Standards/11i/802.11i-D6.0.pdf
• http//www.ieee802.org/1/files/private/1-REV-draft
  s/d7/802-1X-Rev-d7-1.pdf

6
EAPStandards Development Status

• Jari Arkko
• Bernard Aboba

7
Dependencies
RFC 3575
RFC 3576
RFC 3579
EAP-SIM (and other methods)

1X-REV
EAP state machine
2284bis
RFC 3580
EAP keying framework
802.11i
RFC3588(Diameter base)
Diameter EAP
DiameterNASREQ
8
Document Status Summary

• Published as an RFC
• RFC 3575
• RFC 3576
• RFC 3579
• RFC 3580
• RFC 3588
• In AD evaluation
• Draft-ietf-eap-rfc2284bis-06.txt
• In IETF Last Call
• Draft-ietf-aaa-diameter-nasreq-13.txt
• AAA WG work items
• Draft-ietf-diameter-eap-02.txt
• EAP WG work items
• Draft-ietf-eap-statemachine-00.pdf
• Draft-ietf-eap-keying-00.txt

9
Authorization,EAP, and Fast Handoffs

• Jari Arkko
• Ericsson Research NomadicLab
• Bernard Aboba
• Microsoft

10
Background

• Discussions about SSID and its role in
  authentication and fast handoffs
• Discussions about the semantics of
  Session-Timeout and its role in fast handoffs
• Current authorization processes in AAA protocols
• Definition of the PMKSA
• Various fast handoff proposals
• gt Issue 182 and Section 1.4 in keying-00.txt

11
Classic Network Access Authorization

• Network access decision is not just about
  authentication, it is about authorization as well
• Typically, need to check that
• This user is a legitimate user for the this
  network
• The user has subscribed to the type of service
  requested
• What parameters, such as filters, the access
  network needs when serving this user
• The user is within time of day or concurrent
  session limits
• There are no fraud, credit limit, or other
  reasons preventing access for this user
• AAA makes these decisions

12
Access Authorization Using AAA

• AAA makes the decision, but the process is
  complex
• The decision isnt necessarily done in a single
  entity. Everyone on the path can affect the
  decision.
• We have both an on/off decision and parameter
  determination
• Decisions can be based on either static policies
  or dynamic state
• The decision criteria is not communicated to the
  access network, only the decision itself
• Currently there are no standardized attributes
  for the criteria
• Even the parameters might not be communicated
• If a request parameter is acceptable, there is no
  need for this

13
Fast Handoffs

• Definition Fast handoff network access where
  EAP authentication and associated AAA passthrough
  are bypassed
• Depending on the adopted solution
• AAA key transport may also be bypassed in favor
  of context transfer, or
• a pre-emptive AAA key transport may occur

14
Authorization Issues ...

• Fast handoffs raise several authorization issues
• Consistent application of session time limits
• When you move, your remaining session time should
  not increase
• Absolute vs. relative time
• Avoidance of privilege elevation
• Movement should not imply the possibility to e.g.
  log on to a corporate network from a guest
  network
• Encoding of restrictions
• Need to know the used criteria
• Decisions based on dynamic state
• Network-wide state can typically only be taken in
  account by the AAA server
• Keeping the dynamic state valid

15
Fast Handoff Correctness Criteria

• Definition A fast handoff mechanism is said to
  be correct if it creates the same context as a
  new AAA exchange would have
• If this can not be reached, it may be desirable
  to fail
• If the new and old NAS different in their
  capabilities, it is difficult to achieve
  correctness
• AAA servers often have conditional authorization
  rules
• RADIUS Access-Accept rules
• Known attribute for a service which is not
  supported gt fail
• Unknown attribute gt ignore
• These should apply even in a context transfer!

16
Examples

• 1. NAS 1 with VLAN support -gt NAS 2 without
• Should not result in access outside the original
  VLAN
• 2. NAS 1 with confidentiality support -gt NAS 2
  without
• Should not result in sudden loss of
  confidentiality
• 3. Users subscription revoked at AAA, user
  continues to get access via fast handoff
• Chasing the user around and trying to disconnect
  him

17
Conclusions

• PMK SA is intimately tied to the authorization
  decision by AAA
• We can not bypass authorization issues when doing
  fast handoff
• Fast handoff most likely to succeed in homogenous
  environment
• Neither RADIUS or DIAMETER was designed for the
  requirements that fast handoff sets for them
• Still, we need correct fast handoff mechanisms
• Allow-Fast-Handoff attribute from AAA is one easy
  solution
• Would avoid many of the above problems
• Only sent when dynamic state etc not an issue
• Disallow-Fast-Handoff is another solution
• Problematic if dynamic state or decisions
  involved and DFH not set
• But deployment of FH is easier even if home AAA
  does not care about it
• In addition, we may need
• Authorization attributes
• Authorization criteria attributes
• Get the details of context transfer acceptance
  decision right

18
Action Items

• EAP keying draft and 11i draft should clarify
  that authorization parameters are a part of the
  PMKSA
• The definition of the AAA-Token should include
  authorization parameters in Diameter EAP
• Existing authorization parameters listed
• New ones that we need should be defined
• Authorized-Calling-Station-Id
• Disallow/Allow-Fast-Handoff attribute is needed
  (but when?)
• Fast handoff designers should take these issues
  into account

19
Backup Slides for Other Issues

• Jari Arkko
• Ericsson Research NomadicLab

20
Diameter EAP Issues

• Basic EAP processing rules as in RFC 3579
• Added Redirect support to avoid revealing session
  keys to nodes that have no need to know them
• Authorization of AAA nodes to act as
  authenticators or backend servers
• Problem comes up in particular with Redirect
• Several possible technical solutions exist,
  including local configuration and certificate
  extensions
• Proposed way forward is to document the issue but
  not mandate a particular solution
• AAA-Token contents
• The raw key (construction formula defined by
  eap-keying)
• Authorization AVPs

21
EAP Keying Document Editorial Issues

• Reordering the document
• Starts with the solution and ends with
  requirements
• But hard to move sections since they have
  dependencies
• IEEE specific issues
• Necessary to keep examples
• But some text might be better in an appendix
• Suggestion PMK definition and IEEE terms only in
  an appendix, the rest of the examples would stay?

22
EAP Keying Document Small Technical Issues

• Are we really disallowing link layer specific
  identifiers
• Section 2.1.1 says so
• Even in the generic fashion as is done in EAP
  Archie?
• Multicast SA text needs work
• Are these derived from unicast SAs or PMKSAs?
• Multicast SAs contain common material for several
  EAP authenticated clients and PMKSAs
• No IANA considerations?
• What about PRF(ltsomethinggt,Constant)?

23
Backwards Compatibility and Scoping

• Backwards compatibility issues need to be
  addressed
• We currently use the plain key in AAA-Key
• We (may) now switch to a scoped key calculated
  via a hash
• These are not interchangeable
• Client cant use hash(key) if server uses key
• Need to be signaled somehow for the client and
  the AAA server
• AAA server needs to know if AP is doing WPA or
  final 11i
• Cant wait until the 4-way handshake to find out
  -- use beacon frame
• If someone gets the plain key, he can manufacture
  scoped keys
• The use EMSK as a starting point for the scoped
  key would prevent this
• Cases
• Use the old key through an old access point
• A new access point can upgrade old AAA servers
  key
• Bidding down issues involved
• But RSN IE is already protected by WPA, may help
  here...

24
Parameter Agreements and Scoping

• Agreement over (some) parameters may be important
• SSID is currently the only really significant one
• Service type might be important, if more than one
  service allows fast handoffs
• MAC addresses might be important
• Do we need this?
• Two ways to achieve secure binding to the
  parameters
• 1) Mix the parameter information to AAA-Key
  (PMKSA key)
• 2) Securely exchange the parameters over EAP,
  either using a generic approach (TLV/EAPv2) or
  method-specific mechanisms (Archie)
• Implications of the choice
• With mixing, new parameter introduction is hard
• Secure EAP exchange of the parameters does not
  exist at the moment
• But, we could add it to SIM, AKA, TLS, and
  Archie -- would that be enough?

25
SA definition changes in eap-keying

• EAP SA
• AAA-Key SA
• Unicast Secure Association SA
• Multicast Secure Association SA
• gt
• Long-term EAP SA
• Service SA ( PMKSA)
• Service Sub-SAs ( PTKSA, GTKSA)
• (AAA-Key is an algorithm and a protocol, not an
  SA)

26
SA definition changes in 11i D6

• MAC addresses away from PMKSA
• Clarify authorization parameter role in PMKSA
• Need references between PMKSA - PTKSA/GTKSA for
  re-authentication and SA removal purposes
• May need an accounting context reference in PMKSA

27
IEEE EAP Issues Mentioned Tuesday

• Rejected in 6.1
• Use EAP Name for PMKID
• Remaining in 6.1
• Do not refer to EAP keying doc so EAP security
  association is not defined
• PMK naming / EAP naming. Current PMKID problem
  for PSK
• 8.4 EAP security association