EAP Keying Framework

1
EAP Keying Framework

• Draft-aboba-pppext-key-problem-07.txt
• http//www.drizzle.com/aboba/IETF57/EAP/
• EAP WG
• IETF 57
• Vienna, Austria
• Bernard Aboba

2
Goals Objectives

• To provide a framework for evaluation of EAP key
  derivation mechanisms and transport mechanisms
• Terminology
• Architectural Model
• Security
• hierarchy overview
• Requirements for EAP methods, AAA protocols and
  secure association protocols
• Key derivation algorithms are not specified in
  this document.

3
EAP Invariants

• Media independence
• EAP methods are designed to function on any lower
  layer meeting criteria in RFC 2284bis, Section
  3.1
• Ciphersuite independence
• Ciphersuite negotiation occurs out of band of EAP
• EAP methods generate keying material suitable for
  use with any ciphersuite
• Method independence
• Pass-through authenticators cannot be assumed to
  implement method-specific code

4
Protocol Relationships

• Discovery Phase (Phase 0)
• EAP peer discovers the Authenticator
• Discovery phase is out of band of EAP and may not
  be secure
• Examples PPPOE, 802.11 Beacon, Probe
  Request/Response
• EAP (Phase 1)
• Protocol spoken between EAP peer and EAP server
• EAP SAs are bi-directional
• Mutual authentication required for key deriving
  methods
• EAP method provides keying material (MSK, EMSK)
• Method may have no explicit key lifetime
  negotiation
• EAP SA state may be cached for significant
  periods after authentication completes (e.g. fast
  resume)
• EAP only supports EAP SA creation, not deletion
• EAP peer or server can delete SA state at any
  time without notification
• Multiple EAP SAs possible between an EAP peer and
  EAP server
• TEKs derived for protection of EAP SA negotiation
• MSK, EMSK, TEKs must be fresh, not used to
  protect data
• Key deriving methods need to support replay
  protection

5
Protocol Relationships (contd)

• AAA
• Protocol spoken between NAS and AAA server
• Mutual authentication required (RADIUS or
  Diameter)
• Replay protection supported
• MSK transported from AAA server to NAS
• MSK is bound to a particular NAS
• Secure Association Protocol (Phase 2)
• Used by EAP peer to derive a security association
  with the EAP Authenticator in order to protect
  data, and indicate I want to join the network
  connected to this NAS
• Demonstrates proof of possession of Phase 1
  Keying Material
• Binds Phase 1 to Phase 2
• Supports secure capabilities negotiation
• Allows for secure verification of insecure
  discovery phase
• Derives unicast and multicast transient session
  keys
• Fresh TSKs derived (even if MSK is not fresh)
• Supports addition and deletion of Phase 2 SAs
• As with EAP, both peer and authenticator may
  delete Phase 2 key state at any time
• Secure Association SAs may not be bi-directional

6
The (Bermuda?) EAP Triangle
7
Why Is Binding/Naming Important?

• Unlike IKE, EAP and Secure Association protocol
  may not be run between the same parties
• EAP SA negotiated between EAP peer and EAP server
• Phase 2 SA negotiated between EAP peer and
  Authenticator
• May not be clear which EAP (Phase 1) SA a Phase 2
  SA is to be derived from
• An EAP peer may have negotiated multiple EAP SAs
  to several EAP servers
• Phase 2 SA may be based on a Phase 1 SA run
  through another NAS
• Key name needed in Secure Association protocol
  for clarification

8
Example

• EAP Peer A connects to NAS A, negotiates EAP SA
  with Server A
• Server A fails, NASes failover to Server B
• EAP Peer A connects to NAS B, negotiates EAP SA
  with Server B
• Server A recovers, NASes failback to Server A
• No synchronization between Server A and Server B
• EAP Peer A connects to NAS C, which indicates
  desire to skip EAP (Phase 1) and negotiate a
  secure association (Phase 2)
• Which EAP SA is the Phase 2 SA based on? Server
  A? Server B?

9
Issues with Synchronization of Key State

• EAP SA and secure association state can be
  deleted at any time by any party
• EAP peer may delete EAP SA or Phase 2 SA
• EAP authenticator may delete MSK or Phase 2 SA
• AAA server may delete MK, MSK, EMSK, etc.
• Not clear whether AAA protocol should attempt to
  negotiate an explicit key lifetime with the NAS
• May be no way for EAP peer to be informed of the
  key lifetime
• NAS may not keep MSK around for the full lifetime
  if it reboots or needs to reclaim resources
• Result AAA server cannot assume key lifetime is
  obeyed by the NAS
• Lack of synch of SA state addressed by
  negotiating a new EAP SA
• EAP peer request for fast resume is denied if
  EAP Server does not retain MK state
• Phase 2 delete operation may not be protectable
• If EAP authenticator has deleted Phase 2 key
  state, there is no way to protect a delete
  message
• If EAP peer has deleted Phase 2 key state, it
  cannot validate (or decrypt?) a delete message
• Result timeouts may be unavoidable

10
Issues with Peer-to-Peer Operation

• EAP is a peer-to-peer protocol, but
• AAA protocol may not support role reversal (RFC
  2869bis, Diameter EAP)
• EAP methods may be client/server
• Example EAP TLS
• TLS client certificate not the same as TLS server
  cert
• Implies that EAP peers must have two certs if
  role reversal is supported
• Secure association SAs may not be bi-directional
• Example IEEE 802.11i group key handshake is
  one-way, from Authenticator to EAP peer, since
  only 802.11 AP can multicast
• Result two EAP SAs may be required, one in each
  direction, even where mutual authentication is
  supported
• Example two group key exchanges, 4-way
  handshakes and EAP exchanges are needed in 802.11
  adhoc

11
Open Issues

• Issue 15 missing security reqts.
• Additional discussion of key naming,
  synchronization and binding required
• Proposal Add material to address this in -07
• Issue 47 key requirements unspecified
• Size of MSK and EMSK
• Minimum key strength in some/all scenarios?
• Nonce exchange required in EAP methods?
• Proposal add nonce exchange requirement
• Issue 99 Double expansion
• Expansion typically occurs from MK to MSK and MSK
  to TSK
• Proposal Reject key strength is the issue, not
  double expansion
• Issue 119 EAP is inappropriate for Peer-to-Peer
• Proposal Add discussion of Peer-to-Peer issues
  in -07

12
Open Issues (contd)

• Issue 135 SSID in PRF
• Proposal Reject
• EAP is media independent, SSID equivalent does
  not exist on all media
• Not clear that the MSK is bound to a particular
  SSID, only to a particular Physical NAS
• Example Virtual AP
• Can support multiple SSIDs
• During pre-authentication, SSID may not be
  available or may only be inferred from the
  Called-Station-Id
• Virtual APs may share MSKs enabled by key
  naming
• Result Phase 2 SA may be negotiated based on
  Phase 1 SA derived via another Virtual AP (in
  another SSID!) on same physical AP

13
Roadmap

• Update -07 document
• Include resolution of open issues
• Post -07 strawman for examination and discussion
• Request permission to submit as an EAP WG work
  item

14
Requirements Overview

• Key Management requirements presented by Russ
  Housley at IETF 56
• EAP Key Management Framework document to provide
  system analysis
• EAP, AAA, Secure Association requirements
• Detailed discussion in EAP WG 2nd session
• AAA documents can no longer reference Diameter
  CMS (work discontinued)
• Best alternative is Diameter Re-direct
• Outstanding Issues
• Key naming/binding (EAP Key Framework)
• Re-direct authorization

15
Acceptable solution MUST

• Be algorithm independent protocol
• For interoperability, select at least one suite
  of algorithms that MUST be implemented
• Response
• Diameter supports IKE, TLS security
• Can negotiate ciphersuites, security parameters
  for protecting AAA sessions
• EAP provides algorithm, media independence
• Any EAP method can work with any media and
  ciphersuite
• EAP provides a mandatory-to-implement method
• Issue Mandatory method does not support key
  derivation or mutual authentication

16
Acceptable solution MUST

• Establish strong, fresh session keys
• Maintain algorithm independence
• Include replay detection mechanism
• Response
• Diameter security protocols (TLS, IKE) negotiate
  strong, fresh session keys to protect traffic,
  provide replay protection
• Key strength, replay protection can be provided
  regardless of key management algorithm
• Key strength, Replay protection are security
  claims for EAP methods
• Issue Not all methods will provide strong keys
• Issue Not all methods will provide replay
  protection
• Proposal to add Key freshness requirement
• Nonce exchange in EAP method guarantees MSK/EMSK
  freshness, unique key naming
• Nonce exchange in secure association protocol
  guarantees freshness of transient session keys
  even if MSK/EMSK is not fresh

17
Acceptable solution MUST

• Authenticate all parties
• Maintain confidentiality of authenticator
• NO plaintext passwords
• Response
• EAP does not support PAP
• Diameter requires mutual authentication between
  NAS and AAA server, supports confidentiality
• Issue authorization issues being addressed
• Mutual authentication required for key-deriving
  EAP methods, secure association protocol
• Question What does maintain confidentiality of
  authenticator mean?
• Support for identity privacy?

18
Acceptable solution MUST also

• Perform client and NAS authorization
• Response
• Client authorization issues being addressed in
  RFC 2284bis
• NAS/AAA server authorization issues being
  addressed in NASREQ, Diameter EAP

19
Acceptable solution MUST also

• Maintain confidentiality of session keys
• Response
• MSK transport is protected by Diameter transport
  security (IPsec, TLS)
• Re-direct can restrict MSK access to those with
  need to know (NAS, AAA server, EAP peer)
• Transient Session Keys are derived via secure
  association protocol

20
Acceptable solution MUST also

• Confirm selection of best ciphersuite
• Secure association protocol responsible for
  secure capabilities negotiation
• Used for communication of data between the EAP
  peer and NAS
• Diameter security (IPsec, TLS) provides for
  secure negotiation of security parameters
• EAP methods negotiate ciphersuites for use in
  protecting the EAP conversation
• Issue Should we require that this negotiation be
  protected?

21
Acceptable solution MUST also

• Uniquely name session keys
• Response
• Work in progress
• EAP SA name ltEAP peer name, EAP server name,
  Peer Nonce, Server Noncegt
• Potential for multiple EAP SAs between an EAP
  peer and EAP server
• MK name ltEAP SA name, Method session-idgt
• MSK name ltEAP SA name, MSK, NAS Namegt
• Binds the MSK to a particular NAS, avoids
  (inappropriate) reuse
• Called-Station-Id best candidate for NAS Name
  since EAP peer may not know NAS-Identifier or
  NAS-IP-Address
• EMSK name ltEAP SA name, EMSKgt
• TSK name ltKey name, peer Nonce, NAS Noncegt
• Since names may be long, hash of the name used as
  a surrogate
• Issue How do the NAS, EAP peer and AAA server
  come to agree on the Key names?
• NAS operates in pass-through, does not have
  access to MK or EMSK

22
Acceptable solution MUST also

• Compromise of a single NAS cannot compromise any
  other part of the system, including session keys
  and long-term keys
• Response
• MK, EMSK only available to EAP peer, server, not
  to the NAS
• Key freshness required in EAP method, secure
  association protocol
• Requires that MSK, TEKs, TSKs at one NAS not be
  derivable based on quantities at another NAS
• For fast handoff, implies that master session
  keys be on different branches of the key
  hierarchy
• Diameter security uses dynamic, not static
  session keys, and well understood ciphersuites
• Compromise of one NAS will not reveal Diameter
  session keys of another NAS
• Issue Do we need to say not to use the same IKE
  pre-shared key for every NAS?

23
Acceptable solution MUST also

• Bind key to appropriate context
• Response
• Peer-Server
• Binding is implicit no explicit key lifetime
  negotiation or EAP SA delete message
• NAS-Peer
• Binding of TSKs to securely negotiated
  capabilities is the responsibility of the secure
  association protocol
• Binding of the key to the secure association SA
  the responsibility of the secure association
  protocol
• AAA server-NAS
• Binding and context provided by Grouped Key AVP
• Issue Does the key name need to be provided
  along with the key in the Key Grouped AVP?
• Issue What other AVPs are needed to define the
  context?

24
Summary

• We are making progress
• Key naming and binding issues the most
  challenging
• Key Management Framework document will include
  system analysis

25
Feedback?