EAP WG

EAP WG

EAP Key Management Framework

Draft-ietf-eap-keying-08.txt

Bernard Aboba

Microsoft

Monday, November 7, 2005

IETF 64, Vancouver, CA

Outline

Document status Security Assumptions & Goals EAP Invariants EAP key hierarchy and key flow Open Issues

Document status WG Last call to expire on 11/30/05 Issues resolved in -08

Security considerations Issue 279: Keying requirements Issue 294: Rewrite of security considerations Issue 302: Clarifications on the domino effect Issue 307: Rewrite of security requirements

Lower layer issues Issue 299: Key cache structure Issue 300: Port Issue 305: Appendix cleanup Issue 306: Channel bindings Issue 308: Rewrite of lower layer section

EAP Conversation Overview

EAP peer Authenticator Auth. Server -------- ------------- ------------ |<----------------------------->| | | Discovery (phase 0) | | |<----------------------------->|<----------------------------->| | EAP auth (phase 1a) | AAA pass-through (optional) | | | | | |<----------------------------->| | | AAA Key transport | | | (optional; phase 1b) | |<----------------------------->| | | Unicast Secure association | | | (phase 2a) | | | | | |<----------------------------->| | | Multicast Secure association | | | (optional; phase 2b) | | | | |

Security Assumptions

All traffic is visible to the attacker. The attacker can alter, forge or replay

messages. The attacker can reroute messages to

another principal. The attacker may be a principal or an

outsider. The attacker can compromise any key that is

sufficiently old.

Overall Security Goals The EAP peer and authenticator mutually authenticate and

establish fresh transient session keys known only to them. Mutual authentication

Implies identification of EAP peer and authenticator Involves proof of possession of fresh EAP keying material

which only peer and authenticator can know Requires integrity, authentication, replay protection of

messages. Freshness

Requires that TSKs be fresh, even if EAP keying material has been previously used between the parties.

Security Goals (cont’d) TSK confidentiality exists if:

EAP peer and authenticator securely negotiate ciphersuites so as to be able to protect against downgrade attacks.

EAP peer does not expose keying material to another party. EAP authenticator does not expose keying material to another party. EAP server does not share EAP keying material with another party

other than the EAP authenticator; this implies that EAP server transports keying material to the authenticator without exposing it to another party.

EAP keying material is known to be fresh by EAP peer, server, authenticator

AAA server deletes transported keys. Key lifetime is known by the EAP peer, server and authenticator so

that the key can be deleted before it becomes stale.

TSK Freshness: Examples IKEv2

EAP used only for authentication, not TSK generation TSKs are generated using nonces from both parties TSKs are unknown to EAP server even if it does not delete transported keys Compromise of EAP keying material does not lead to disclosure of TSKs

802.16e EAP keying material only used for key wrap, authentication/integrity, not TSK

generation TSKs are generated by the EAP authenticator and transported, so EAP peer does

not know TSKs are fresh TSKs are unknown to EAP server even if it does not delete transported keys Compromise of EAP keying material leads to compromise of TSKs

802.11i TSKs generated from EAP keying material Nonce exchange required to guarantee freshness if EAP keying material is cached TSKS are known to EAP server if it does not delete transported keys Compromise of EAP keying material leads to compromise of TSKs

PPP TSKs generated directly from EAP keying material, no nonce exchange EAP peer and authenticator do not mutually authenticate or identify each other Caching of EAP keying material is not possible since it leads to TSK reuse Compromise of EAP keying material reveals TSKs

Security Goals of EAP EAP peer and server mutually authenticate and derive

fresh keying material known only to them. Mutual authentication: Required by RFC 4017

EAP peer typically identified but EAP server may not be Peer-ID, Server-ID can be made available to EAP

authenticator Freshness: RFC 3748 RECOMMENDS nonce exchange

If EAP keying material is cached, key lifetime needs to be determined (but probably not in EAP)

Integrity and replay protection (RFC 4017 requirements) Key confidentiality

Sufficient key strength, dictionary/MiTM attack protection, session independence, etc. (RFC 4017 requirements)

Security Goals for AAA EAP authenticator and AAA server mutually authenticate and AAA server

transports fresh EAP keying material to EAP authenticator while not disclosing keys to another party. Mutual authentication

Requires EAP authenticator and AAA server to identify each other, have credentials unique to those parties.

Key confidentiality Requires a credible key wrap algorithm and direct conversion between EAP

authentication and AAA server. Known issues here.

EAP authenticator may assume keys are fresh if AAA conversation is authenticated, integrity and replay protected, if the EAP Session-ID does not repeat, if the AAA server deletes transported keys, and if a key lifetime attribute has been provided and has not expired. Stale keys require bad random number generator on EAP peer & authenticator Best to guarantee that TSKs are fresh even if EAP keying material is not.

Breaking Security Goals Sharing of keys between authenticators or peers Lack of EAP authenticator/peer identification

EAP peer and authenticator can’t mutually authenticate as part of TSK derivation EAP peer and authenticator can’t know what keys to use in communicating with each

other Sharing of AAA credentials

EAP authenticator and AAA server can’t mutually authenticate AAA server/proxy caching of transported keys

AAA server/proxy may know the TSKs, or be able to masquerade as the EAP authenticator

Violation of fundamental cryptographic assumptions MSK and EMSK are not cryptographically independent Long term credentials can be obtained from MSK/EMSK

Lack of channel bindings EAP authenticator can provide different information to EAP peer and AAA server

Undefined key lifetimes Keys may not be fresh

EAP Invariants Mode Independence

Identical key state on EAP authenticator, regardless of whether it operates in “stand-alone” or “pass-through” mode

Media independence EAP methods agnostic about lower layers AAA server is lower layer agnostic

Method independence Pass-through authenticator is method agnostic

Ciphersuite independence EAP methods generate keying material, not session keys AAA server is ciphersuite agnostic

EAP Method Exports+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+| | ^| EAP Method | || | || +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | || | | | | | || | EAP Method Key |<->| Long-Term | | || | Derivation | | Credential | | || | | | | | || | | +-+-+-+-+-+-+-+ | Local to || | | | EAP || +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method || | | | | || | | | | || | | | | || | | | | || | | | | || | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | || | | TEK | |MSK, EMSK | |IV | | || | |Derivation | |Derivation | |Derivation | | || | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | || | | | | || | ^ | | | V+-+-|-+-+-+-+-+-+-+-+-|-+-+-+-+-+-|-+-+-+-+-+-+-+-+-|-+-+-+ ---+ | | | | ^ | Peer-ID, | | | Exported| | Server-ID, | Channel | MSK (64+B) | IV (64B) by | | Method-ID, | Bindings | EMSK (64+B) | EAP | | Key-Lifetime | & Result | | Method | V V V V V

EAP Layering Model +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | EAP method | | | | MSK, EMSK, IV, Channel | | Peer-ID, Server-ID, Bindings | | Method-ID, | | Key-Lifetime | | | | V ^ ^ | +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+ | ! ! ! | | EAP ! Peer or Authenticator ! ! | | ! layer ! ! | | ! ! ! | +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+ | ! ! ! | | EAP ! layer ! ! | | ! ! ! | | ! Session-ID = ! ! | | ! Expanded-Type || ! ! | | ! Method-ID ! ! | | ! ! ! | +-+-+-+-!-+-+-+-+-+-+-+-+-+-+-+-!-+-+-+-+-!-+-+ | ! ! ! | | Lower ! layer ! ! | | ! ! ! | | V V ^ | | MSK, IV, Peer-ID, Channel Result | | Server-ID, Bindings | | Session-ID, | | Key-Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Flow of EAP Keying Material Peer Pass-through Authenticator Authentication Server

+-+-+-+-+-+-+ +-+-+-+-+-+-+ | | | | |EAP method | |EAP method | | V | | V | +-+-+-!-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-!-+-+-+ | ! | |EAP | EAP | | | ! | | ! | |Peer | Auth.| EAP Auth. | | ! | |EAP ! peer| | | +-----------+ | |EAP !Auth.| | ! | | | ! | ! | | ! | +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ | ! | | ! | ! | | ! | |EAP !layer| | EAP !layer| EAP !layer | |EAP !layer| | ! | | ! | ! | | ! | +-+-+-!-+-+-+ +-+-+-+-!-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ | V | | V | ! | | ! | |Lower layer| | Lower layer| AAA ! /IP | | AAA ! /IP | | | | | ! | | ! | +-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ ! ! ! ! +---------<-------+

Interfaces & Key Flow EAP lower layer requests keying material from EAP layer EAP layer provides only requested keying material, throws the

rest away “Stand alone” Authenticator

EAP layer on authenticator receives MSK/EMSK from EAP method, calculates requested keying material, passes it down to lower layer

“Pass-through” Authenticator EAP layer on authenticator receives request from lower layer,

remotes it to the EAP layer on the EAP server which receives MSK/EMSK from the EAP method, calculates requested keying material, passes it back to EAP layer on authenticator

Model: AAA provides an LPC/RPC interface between lower layer and EAP layer.

Key Caching EAP methods may cache internal keys on EAP peer

and server EAP peer/authenticator layers and EAP layers do

not cache keys Since EAP layer can’t cache exported keys, keying

material not received by lower layer is presumed destroyed

EAP peer and authenticator lower layers may cache exported keying material, but cannot share it

Existing AAA servers delete received EAP keying material after EAP authentication completes Deletion of transported keying material required to fulfill

security assumptions

Open Issues

EMSK handling Parent/Child Linkage EAP authorization

Issue: EMSK Handling

Is EMSK provided to lower layer? This seems NOT wise:

AAA layer could obtain EMSK, but MUST NOT transport it (RFC 3748)

Compromise of EMSK would compromise all keys derived from it.

Simple approach: EMSK exported by the method, but held only temporarily in the EAP layer.

Lower layer is required to immediately request all keys that it will ever need for this session

Lower layer never obtains the EMSK

Issue: Parent/Child Linkage

Current text says that “Expiration of exported EAP keying material results in expiration of derived keys”

Counterexamples: Where TSKs are derived independent of EAP,

lifetime not dependent on EAP keying material (IKEv2, IEEE 802.16e)

Keys derived from EMSK: EMSK only stored temporarily in EAP layer, then discarded, but keys derived from it can live on.

Issue: EAP Authorization

Current text appears to imply that EAP server is involved in authorization

Authorization is handled by AAA EAP server only involved in credential storage

and verification.

Issue - Madjid’s Review

Terms EAP Server, AAA Server, backend authentication server are the same?

Need to define “export”? Definition of PMK made generic? Definition of AAA-Key is confusing? Use MSK as a basis for AMSKs? Define AMSK here vs. in extensions?

Issue - Madjid’s Review (Cont’d)

Terms EAP Server, AAA Server, backend authentication server are the same? EAP server is really a different entity. In standalone case

the EAP server is in the authenticator. The draft already indicates that the other two terms can be

used interchangeably Suggestion: use just one of the terms in the document, but

keep the two definition because of RFC 3748 compliance Need to define “export”?

Text appears to already make it clear that it’s a question of exporting data from one layer to the other

Not sure if anything beyond this is needed


Definition of PMK made generic? The draft is misleading in the sense that one may interpret

the 802.11 PMK definition as the only one. In reality, lower layers may use MSK and parts of it in the

way they want to Suggested text change:

PMKLower layers use MSK in a lower-layer dependent manner. For instance, in [802.11i] …. In [802.16e], …

And delete references to PMK from Appendix A


Definition of AAA-Key is confusing? It has been. Can not be deleted due to RFC 3748

references, however. Suggested new formulation: “The term AAA-Key is synonymous with MSK”

Use MSK as a basis for AMSKs? Not a good idea from a security perspective -- MSKs are

already being used. No change.

Define AMSK here vs. in extensions? Discussed later on.

Feedback?

Documents

EAP WG