EAP keying framework

1
EAP keying framework

• Jari ArkkoPasi Eronen
• October 15, 2003

2
Conversation phases

Discovery (phase 0)
EAP authentication (phase 1a)
Access authorization (phase 1b)
Service authentication (phase 2)
(service)
3
Discovery (phase 0)

• Peer authenticator
• Parties contact each other
• Exchange some parameters about the service to be
  provided
• Start EAP
• Example 802.11i
• Beacon
• Association Request

4
EAP authentication (phase 1a)

• Peer backend authentication server
• Parties authenticate each other
• And derive a shared session key
• Example EAP-TLS

5
Access authorization (phase 1b)

• Authenticator backend authentication server
• Parties authenticate each other
• Authenticator tells backend authentication server
  what kind of service is requested
• Backend authentication server approves accesss
  (or doesnt) and provides a key (Authorization
  key)
• Example RADIUS (RFC3579 RFC2548)

6
Service authentication (phase 2)

• Peer authenticator
• Exchange more parameters about service to be
  provided (including ciphersuite)
• Protect some of those parameters
• Agree about keys
• Example 802.11i
• Four-way handshake group key handshake

7
Limitation 1

• Protocol between peer and authenticator often
  protects only some of the parameters
• A man-in-the-middle can cause the parties to have
  different idea about unprotected parameters
• For example, 802.11i doesnt protect
• Capabilities
• Data rates
• SSID
• Not a fundamental property of EAP design

8
Limitation 2

• Phase 1a and 1b are almost completely separate
• Fundamental property of EAP design!
• Consequence Backend cant restrict what service
  parameters are advertised by the authenticator
• Or put otherwise, the peer only knows the backend
  trusts the authenticator for something, but
  nothing more specific

9
Limitation 2 (cont.)

• This actually makes sense for most parameters
• We dont include the backend in e.g. ciphersuite
  negotiation, or channels/data rates/etc.
• In 802.11i, only possible exception seems to be
  SSID
• Compromised or malicious AP can advertise a SSID
  it isnt supposed to
• Is this a big problem?
• (Its not easy to fix since it changes
  fundamental parts of EAP design)

10
Limitation 2 Overview of possible solution

• For each of the service parameters that need to
  be approved by the backend authentication server,
• Get values for those parameters to the backend
• Backend checks that the authenticator it is
  sending the keys to is authorized to use those
  values
• Prevent authenticator from telling different
  values to backend and peer
• Communicate values inside EAP exchange (protected
  by keys known only to peer and backend) EAPv2,
  Archie
• Include values when calculating Authorization key
  (from other keys known only to peer and backend)

11
Security associations
Backend authentication server (AAA)

Peer (STA)
Long-term EAP SAShort-term EAP method SA
AAA SA(s)
Service SAs (PMKSA, PTKSA, GTKSA)
Authenticator (AP)
12
Long-term EAP SA

• Peer backend authentication server
• Typically created manually
• Lifetime years
• Example shared secret/password

13
Short-term EAP method SA

• Peer backend authentication server
• Created by EAP method
• Just an optimization not all EAP methods have
  this
• Lifetime hoursdays
• Example EAP-TLS
• EAP method (EAP-TLS)
• Session Identifier
• Certificate of the other party
• Cipher spec and compression method
• Master secret
• Lifetime information

14
AAA SA(s)

• Authenticator backend authentication server
• Long-term SA
• Typically created manually
• Lifetime years
• Example RADIUS shared secret (and related
  authorization information)
• Could include short-term SAs
• For instance, IPsec ESP

15
Service SAs

• Peer authenticator
• Created by the combination of
• EAP conversation (peer backend), based on
  long-term EAP SA
• AAA protocol (authenticator backend), based on
  long-term AAA SA (AAA-Token)
• Service negotiation (peer authenticator)
• Lifetime hours
• Example PMKSA/PTKSA/GTKSA

16
Service SAs in 802.11i

• PMKSA
• PTKSA
• GTKSA

17
PTKSA

• Supplicant authenticator MAC addresses
  (name/index)
• PTK
• Selected cipher suite
• Cipher suite specific data (replay counters,
  countermeasures)
• Lifetime information
• Reference to PMKSA
• If we need a new four-way handshake (lifetime,
  TKIP countermeasures), we need to know which
  PMKSA to use
• Via the reference to PMKSA, or copied here
• SSID (for VLAN tag selection etc.)
• Authorization information (such as L2 packet
  filters)
• Reference to accounting context (right counters
  etc.)

18
PTKSA (diff to D6.1)

• Removed
• ANonce and SNonce (no need to store them)
• Changed
• Pairwise cipher suite list to Selected cipher
  suite
• Added
• Cipher suite specific data (such as replay
  counters)
• Lifetime
• Reference to PMKSA
• SSID (for VLAN tag selection etc.)
• Authorization information
• Reference to accounting context

19
PMKSA

• PMKID
• PMK
• SSID
• Supplicant authenticator group address
• Key replay counters (for EAPOL-Key messages)
• Lifetime information
• Reference to PTKSA (if any)
• To delete it (e.g. AAA-server initiated
  disconnect)
• To replace it when a new four-way handshake is
  done
• Authorization information (local or received from
  AAA server)
• Reference to accounting context

20
PMKSA (diff to D6.1)

• Removed
• Supplicant authenticator MAC addresses
• Added
• SSID
• Supplicant authenticator group address
• EAPOL key replay counters
• Reference to accounting context
• Updated
• PMKID shouldnt include MAC addresses
• No need to recalculate when doing fast handoff
• Not known in PSK case
• PTK flag changed to Reference to PTKSA

21
PMKSA and pre-shared keys

• Do we have a PMKSA when in PSK mode?
• If we do,
• We dont have group addresses?
• How are EAPOL Key replay counters handled?
• Since we can use different PSKs for different
  STAs, do we need some information how to select
  the right one?
• Do we need references to PTKSAs anymore?

22
GTKSA

• Direction bit
• Sender MAC address
• GTK
• Selected cipher suite
• Cipher suite specific data
• Via a reference to PMKSA, or copied here
• SSID (for VLAN tags)
• Reference to accounting context

23
Scope of PMKSA

• Client can propose to use an existing PMKSA if
  both the SSID and Supplicant/Authenticator group
  address stays the same
• BSSID can change, so can STA MAC
• Authorization infomation (local or received from
  AAA server) on the AP can include restrictions
• to allow only specific STA MAC address
• to allow only specific BSSID (no fast handoffs)
• Consequence PMKID should stay the same, so
  calculating it shouldnt include MAC addresses

24
Scope of PMKSA

• Rationale
• One level of optimization is enough
• Easy to understand
• Administrator can decide the size of Group
  address scope
• Make-before-break is easier way to reduce latency

25
Diameter EAP application

• Pasi Eronen
• October 15, 2003

26
Diameter EAP overview

• Basic EAP transport as in RFC 3579
• AAA-Token contents
• Authorization AVPs
• Key

27
Diameter EAP authorization issues

• Added Redirect support to avoid revealing session
  keys to nodes that have no need for them
• Redirect brings up tricky authorization issues
  for AAA nodes
• Is this node Ive just authenticated with TLS
  and certificates allowed to act as a NAS or AAA
  server?
• Not specific to Diameter EAP as such
• Several possible technical solutions exist,
  including local configuration and certificate
  extensions
• Proposal document the issue but do not mandate
  any particular solution