july 16, 2003aaa wg, ietf 571 eap keying framework draft-aboba-pppext-key-problem-07.txt...

July 16, 2003 AAA WG, IETF 57 1

EAP Keying FrameworkDraft-aboba-pppext-key-problem-07.txt

http://www.drizzle.com/~aboba/IETF57/EAP/EAP WGIETF 57

Vienna, AustriaBernard Aboba


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.


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


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


Protocol Relationships (cont’d)• 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


The (Bermuda?) EAP Triangle EAP peer /\ / \ Protocol: EAP / \ Protocol: Secure Association Auth: Mutual / \ Auth: Mutual Unique keys: MK, / \ Unique keys: TSKs TEKs,EMSK / \ / \ Auth. server +--------------+ Authenticator Protocol: AAA Auth: Mutual Unique key: AAA session key


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


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?


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


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


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


Open Issues (cont’d)• 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


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


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


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


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


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?


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



• 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


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?


Acceptable solution MUST also …• Uniquely name session keys• Response

– Work in progress• EAP SA name: <EAP peer name, EAP server name, Peer Nonce, Server Nonce>

– Potential for multiple EAP SAs between an EAP peer and EAP server

• MK name: <EAP SA name, Method session-id>• MSK name: <EAP SA name, “MSK”, NAS Name>

– 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: <EAP SA name, “EMSK”>• TSK name: <Key name, peer Nonce, NAS Nonce>• 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



• 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?


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?


Summary

• We are making progress

• Key naming and binding issues the most challenging

• Key Management Framework document will include system analysis


Feedback?

july 16, 2003aaa wg, ietf 571 eap keying framework draft-aboba-pppext-key-problem-07.txt...

Documents

eap authenticator

eap serverteks

eap serverphase

eap serversphase

eap sa creation

eap triangleaaa wg

eap servereap sas

derived froman eap peer