EAP WG

EAP Key Management Framework

Draft-ietf-eap-keying-03.txt

Bernard Aboba

Microsoft

Outline

The problem The participants The conversation The requirements

The invariants EAP key hierarchy Key naming Key lifetime issues

The Participants +-+-+-+-+ | | | EAP | | Peer | | | +-+-+-+-+ | | | Peer Ports / | \ / | \ Phase 0: Discovery / | \ Phase 1: Authentication / | \ Phase 2: Secure / | \ Association / | \ / | \ / | \ | | | | | | | | | Authenticator Ports +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ | | | | | | | Auth. | | Auth. | | Auth. | | | | | | | +-+-+-+-+ +-+-+-+-+ +-+-+-+-+ \ | / \ | / \ | / EAP over AAA \ | / (optional) \ | / \ | / \ | / \ | / +-+-+-+-+ | | | AAA | |Server | | | +-+-+-+-+

AAA WG

Conversation Phases

Phase 0: Discovery Phase 1: Authentication

1a: EAP authentication (RFC 3748) 1b: AAA-Key Transport (optional)

Phase 2: Secure Association Establishment 2a: Unicast Secure Association 2b: Multicast Secure Association (optional)

EAP WG

AAA WG

Lower Layer

Lower Layer

The Conversation

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

The Requirements

Outlined by Russ Housley at IETF 56 All AAA WG documents doing key distribution need

to meet these requirements EAP Key Management Framework document

chartered to analyze the security of the EAP system

Acceptable solution MUST…(Housley, IETF 56)

Be algorithm independent protocol For interoperability, select at least one suite of

algorithms that MUST be implemented Establish strong, fresh session keys

Maintain algorithm independence Include replay detection mechanism Authenticate all parties

Maintain confidentiality of authenticator NO plaintext passwords

Acceptable solution MUST also …

Perform client and NAS authorization Maintain confidentiality of session keys Confirm selection of “best” ciphersuite Uniquely name session keys Compromise of a single NAS cannot

compromise any other part of the system, including session keys and long-term keys

Bind key to appropriate context

EAP Invariants Media Independence

EAP methods can operate on any lower layer meeting the criteria outlined in [RFC3748], Section 3.1.

EAP methods cannot be assumed to have knowledge of the lower layer over which they are transported.

Method Independence Authenticators can support any method implemented on the peer

and server. Authenticators acts as forwarders for methods not locally

supported. Ciphersuite Independence

EAP methods negotiate the ciphersuite used in protection of the EAP conversation only; data protection is negotiated out-of-band.

The backend authentication server is not a party to the ciphersuite negotiation nor is it an intermediary in the data flow between the EAP peer and authenticator.

An EAP method may not have knowledge of the ciphersuite that has been negotiated between the peer and authenticator.

Types of EAP Keys

Keys calculated locally by the EAP method but not exported by the EAP method, such as the Transient EAP Keys.

Keys exported by the EAP method: MSK, EMSK, IV Keys calculated from exported quantities: AAA-Key,

Application Master Session Keys (AMSKs). Keys calculated by the Secure Association Protocol:

Transient Session Keys.

EAP Key Hierarchy +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ | EAP Method | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ | | | | | | | | | | | EAP Method Key |<->| Long-Term | | | | | Derivation | | Credential | | | | | | | | | | | | | +-+-+-+-+-+-+-+ | Local to | | | | | EAP | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method | | | | | | | | | | | | | | | | | | | | | | | | | | V | | | | | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | | | TEK | | MSK | |EMSK | |IV | | | | |Derivation | |Derivation | |Derivation | |Derivation | | | | +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ +-+-+-+-+-+-+ | | | | | | | | | | | | | V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ | | | ^ | | | | | MSK (64B) | EMSK (64B) | IV (64B) | | | | Exported| | | | by | V V V EAP | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ Method| | AAA Key Derivation, | | Known | | | Naming & Binding | |(Not Secret) | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+ V | ---+ | Transported | | AAA-Key by AAA | | Protocol | V V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+ | | ^ | TSK | Ciphersuite | | Derivation | Specific | | | V +-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---+

Key Placement +-+-+-+-+-+ +-+-+-+-+-+ | | | | | | | | | Cipher- | | Cipher- | | Suite | | Suite | | | | | +-+-+-+-+-+ +-+-+-+-+-+ ^ ^ | | | | | | V V +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ | |===============| |========| | | |EAP, TEK Deriv.| | | | | |<-------------------------------->| backend | | | | | | | | | Secure Assoc. | | AAA-Key| | | peer |<------------->|Authenti-|<-------| auth | | |===============| cator |========| server | | | Link Layer | | AAA | (EAP | | | (PPP,IEEE 802)| |Protocol| server) | |MSK,EMSK | | | | | | AAA-Key | | AAA-Key | |MSK,EMSK,| | (TSKs) | | (TSKs) | | AAA-Key | | | | | | | +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ ^ ^ | | | MSK, EMSK | MSK, EMSK | | | | +-+-+-+-+-+ +-+-+-+-+-+ | | | | | EAP | | EAP | | Method | | Method | | | | | | (TEKs) | | (TEKs) | | | | | +-+-+-+-+-+ +-+-+-+-+-+

Key Naming MSK

MSK and EMSK names are only known by the EAP method, and are exported from the method.

Name is the (hash of the?) concatenation of the string "MSK", EAP Method Type, EAP peer name, EAP server name, EAP peer nonce, and the EAP server nonce.

EMSK (Hash of the?) concatenation of the string "EMSK", the EAP Method Type, EAP

peer name, EAP server name, EAP peer nonce, and the EAP server nonce. AMSK

(Hash of the?) concatenation of the string "AMSK", key label, application data (Appendix F) and EMSK Name.

AAA-Key (Hash of the?) concatenation of the string "AAA-Key", the authenticator name,

and the name of the key from which the AAA-Key is derived (MSK or AMSK Name).

For the purpose of identifying the authenticator, the contents of the NAS-Identifier attribute is recommended.

In order to ensure that all parties can agree on the authenticator name the authenticator needs to advertise its name.

Note that the AAA-Key name does not include the peer or authenticator port over which the EAP conversation took place. This is because the AAA-Key is not bound to a specific peer or authenticator port.

Key Name Characteristics

Key Name is not based on the key itself (unlike IEEE 802.11i)

Key Name used for cache negotiation between peer and authenticator

AAA server provides the Key Name (and AAA-Key) ot the authenticator

Key Name sent to the authenticator by the EAP server along with the key Key Name not known by the authenticator prior to this. No reason for an authenticator to ask the AAA server for a

key by name.

Key Lifetime Issues

Management How are the key lifetimes managed on the peer,

authenticator, and AAA server? Negotiation Out of band management

Resource reclamation What happens if resources need to be reclaimed

and key state is removed by one or more of the parties?

Key Lifetime Management

Transient EAP Keys (TEKs) Internal to the EAP method. Valid only for the duration of the EAP conversation.

MSK, EMSK, IV Existing attributes (e.g. Session-Timeout) define the lifetime of a key

that is in use. In EAP, not possible to re-key the exported keys without re-

authentication (but can re-key the TSKs) Exported keys may be cached prior to session start (pre-

authentication), and may continue to live after the session has ended. AAA-Key may be cached on the authenticator EMSK may be cached on the AAA server

Calculated keys The lifetime of keys calculated from key material exported by EAP

methods can be no larger than the lifetime of the exported keying material.

Thoughts on Exported Key Lifetimes

Where we are today EAP methods do not negotiate the lifetime of the exported keys. EAP, defined in [RFC3748], also does not support the negotiation of lifetimes

for exported keying material such as the MSK, EMSK and IV. To date, Secure Association Protocols also do not negotiate the lifetime of

exported keys. Gap may exist between EAP authentication and the Secure Association Protocol, so

not clear it would help Discovery (phase 0) solutions under investigation

Recommendations On the EAP server, it is RECOMMENDED that the cache lifetime of exported

keys be managed as a system parameter. Where a negotiation mechanism is not provided by the lower lower, it is

RECOMMENDED that the peer assume a default value of the exported key lifetime.

May be desirable to manage the TSK re-key time via AAA. Not clear it is helpful that AAA management of exported key cache lifetime is

helpful. AAA server is not aware of authenticator resource constraints Not clear how AAA server, authenticator and peer keep in sync Per-user cache lifetime management may complicate discovery phase solutions

Feedback?