July 16, 2003AAA WG, IETF 571 EAP Keying Framework Draft-aboba-pppext-key-problem-07.txt EAP WG IETF 57 Vienna, Austria Bernard Aboba

July 16, 2003AAA WG, IETF 572 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.

July 16, 2003AAA WG, IETF 573 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

July 16, 2003AAA WG, IETF 574 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, 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

July 16, 2003AAA WG, IETF 575 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

July 16, 2003AAA WG, IETF 576 The (Bermuda?) EAP Triangle

July 16, 2003AAA WG, IETF 577 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

July 16, 2003AAA WG, IETF 578 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?

July 16, 2003AAA WG, IETF 579 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

July 16, 2003AAA WG, IETF 5710 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 i group key handshake is one-way, from Authenticator to EAP peer, since only 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 adhoc

July 16, 2003AAA WG, IETF 5711 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

July 16, 2003AAA WG, IETF 5712 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

July 16, 2003AAA WG, IETF 5713 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

July 16, 2003AAA WG, IETF 5714 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 2 nd 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

July 16, 2003AAA WG, IETF 5715 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

July 16, 2003AAA WG, IETF 5716 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

July 16, 2003AAA WG, IETF 5717 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?

July 16, 2003AAA WG, IETF 5718 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

July 16, 2003AAA WG, IETF 5719 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

July 16, 2003AAA WG, IETF 5720 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?

July 16, 2003AAA WG, IETF 5721 Acceptable solution MUST also … Uniquely name session keys Response –Work in progress EAP SA name: –Potential for multiple EAP SAs between an EAP peer and EAP server MK name: MSK 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: TSK name: 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

July 16, 2003AAA WG, IETF 5722 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?

July 16, 2003AAA WG, IETF 5723 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?

July 16, 2003AAA WG, IETF 5724 Summary We are making progress Key naming and binding issues the most challenging Key Management Framework document will include system analysis

July 16, 2003AAA WG, IETF 5725 Feedback?