Title: EAP WG
1EAP WG
- EAP Key Management Framework
- Draft-ietf-eap-keying-03.txt
- Bernard Aboba
- Microsoft
2Outline
- The problem
- The participants
- The conversation
- The requirements
- The invariants
- EAP key hierarchy
- Key naming
- Key lifetime issues
3The 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
4Conversation 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)
Lower Layer
EAP WG
AAA WG
Lower Layer
5The Conversation
EAP peer Authenticator
Auth. Server --------
------------- ------------
lt-----------------------------gt
Discovery (phase 0)
lt-----------------------------gtlt----------------
-------------gt EAP auth (phase 1a)
AAA pass-through (optional)
lt-----------------------------gt
AAA-Key transport
(optional phase 1b) lt-----------------
------------gt
Unicast Secure association
(phase 2a)
lt-----------------------------gt
Multicast Secure
association
(optional phase 2b)
6The 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
7Acceptable 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
8Acceptable 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
9EAP 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.
10Types 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.
11EAP Key Hierarchy
- ----------------------
------- --- - EAP Method
-
- -----------------
------- -
- EAP Method Key lt-gt
Long-Term - Derivation
Credential -
-
------- Local to -
EAP - -----------------
Method -
-
-
-
- V
- ------ ------ ------
------ - TEK MSK EMSK
IV - Derivation Derivation Derivation
Derivation
12Key Placement
----- -----
Cipher- Cipher-
Suite Suite
----- -----
V V
----- -----
-----
EAP, TEK Deriv.
lt--------------------------------gt
backend
Secure Assoc. AAA-Key
peer lt-------------gtAuthenti-lt-------
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)
-----
-----
13Key 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.
14Key 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.
15Key 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?
16Key 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.
17Thoughts 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
18Feedback?