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
Issue - Madjid’s Review (Cont’d)
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
Issue - Madjid’s Review (Cont’d)
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?
Top Related