EAP WG

1. EAP WG EAP Key Management Framework Draft-ietf-eap-keying-08.txt Bernard Aboba Microsoft Monday, November 7, 2005 IETF 64, Vancouver, CA

2. Outline • Document status • Security Assumptions & Goals • EAP Invariants • EAP key hierarchy and key flow • Open Issues

3. 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

4. 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) | | | | |

5. 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.

6. 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.

7. 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.

8. 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

9. 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)

10. 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.

11. 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

12. 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

13. 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

14. 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

15. 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 | | | | | ! | | ! | +-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-!-+-+-+-+ +-+-+-!-+-+-+ ! ! ! ! +---------<-------+

16. 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.

17. 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

18. Open Issues • EMSK handling • Parent/Child Linkage • EAP authorization

19. 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

20. 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.

21. 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.

22. 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?

23. 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

24. 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: PMK Lower 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

25. 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.

26. Feedback?