draft-ietf-eap-keying-20.txt   draft-ietf-eap-keying-21.txt 
EAP Working Group Bernard Aboba EAP Working Group Bernard Aboba
Internet Draft Dan Simon Internet Draft Dan Simon
Updates: 3748 Microsoft Corporation Updates: 3748 Microsoft Corporation
Category: Standards Track P. Eronen Category: Standards Track P. Eronen
Expires: May 1, 2008 Nokia Expires: May 1, 2008 Nokia
30 October 2007 31 October 2007
Extensible Authentication Protocol (EAP) Key Management Framework Extensible Authentication Protocol (EAP) Key Management Framework
draft-ietf-eap-keying-20.txt draft-ietf-eap-keying-21.txt
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1. Introduction .......................................... 3 1. Introduction .......................................... 3
1.1 Requirements Language ........................... 3 1.1 Requirements Language ........................... 3
1.2 Terminology ..................................... 3 1.2 Terminology ..................................... 3
1.3 Overview ........................................ 7 1.3 Overview ........................................ 7
1.4 EAP Key Hierarchy ............................... 9 1.4 EAP Key Hierarchy ............................... 9
1.5 Security Goals .................................. 13 1.5 Security Goals .................................. 13
1.6 EAP Invariants .................................. 14 1.6 EAP Invariants .................................. 14
2. Lower Layer Operation ................................. 18 2. Lower Layer Operation ................................. 18
2.1 Transient Session Keys .......................... 18 2.1 Transient Session Keys .......................... 19
2.2 Authenticator and Peer Architecture ............. 20 2.2 Authenticator and Peer Architecture ............. 20
2.3 Authenticator Identification ..................... 21 2.3 Authenticator Identification ..................... 21
2.4 Peer Identification ............................. 25 2.4 Peer Identification ............................. 25
2.5 Server Identification ........................... 26 2.5 Server Identification ........................... 26
3. Security Association Management ....................... 28 3. Security Association Management ....................... 28
3.1 Secure Association Protocol ..................... 29 3.1 Secure Association Protocol ..................... 29
3.2 Key Scope ....................................... 32 3.2 Key Scope ....................................... 32
3.3 Parent-Child Relationships ...................... 32 3.3 Parent-Child Relationships ...................... 33
3.4 Local Key Lifetimes ............................. 33 3.4 Local Key Lifetimes ............................. 34
3.5 Exported and Calculated Key Lifetimes ........... 34 3.5 Exported and Calculated Key Lifetimes ........... 34
3.6 Key Cache Synchronization ....................... 36 3.6 Key Cache Synchronization ....................... 37
3.7 Key Strength .................................... 37 3.7 Key Strength .................................... 37
3.8 Key Wrap ........................................ 37 3.8 Key Wrap ........................................ 37
4. Handoff Vulnerabilities ............................... 38 4. Handoff Vulnerabilities ............................... 38
4.1 EAP Pre-authentication .......................... 39 4.1 EAP Pre-authentication .......................... 39
4.2 Proactive Key Distribution ...................... 40 4.2 Proactive Key Distribution ...................... 41
4.3 AAA Bypass ...................................... 42 4.3 AAA Bypass ...................................... 42
5. Security Considerations .............................. 46 5. Security Considerations .............................. 46
5.1 Peer and Authenticator Compromise ............... 47 5.1 Peer and Authenticator Compromise ............... 47
5.2 Cryptographic Negotiation ....................... 48 5.2 Cryptographic Negotiation ....................... 49
5.3 Confidentiality and Authentication .............. 50 5.3 Confidentiality and Authentication .............. 50
5.4 Key Binding ..................................... 55 5.4 Key Binding ..................................... 56
5.5 Authorization ................................... 56 5.5 Authorization ................................... 57
5.6 Replay Protection ............................... 58 5.6 Replay Protection ............................... 59
5.7 Key Freshness ................................... 59 5.7 Key Freshness ................................... 59
5.8 Key Scope Limitation ............................ 61 5.8 Key Scope Limitation ............................ 61
5.9 Key Naming ...................................... 62 5.9 Key Naming ...................................... 62
5.10 Denial of Service Attacks ....................... 62 5.10 Denial of Service Attacks ....................... 63
6. IANA Considerations ................................... 63 6. IANA Considerations ................................... 63
7. References ............................................ 63 7. References ............................................ 63
7.1 Normative References ............................ 63 7.1 Normative References ............................ 63
7.2 Informative References .......................... 63 7.2 Informative References .......................... 64
Acknowledgments .............................................. 70 Acknowledgments .............................................. 70
Author's Addresses ........................................... 70 Author's Addresses ........................................... 70
Appendix A - Exported Parameters in Existing Methods ......... 71 Appendix A - Exported Parameters in Existing Methods ......... 71
Full Copyright Statement ..................................... 73 Full Copyright Statement ..................................... 73
Intellectual Property ........................................ 73 Intellectual Property ........................................ 73
1. Introduction 1. Introduction
The Extensible Authentication Protocol (EAP), defined in [RFC3748], The Extensible Authentication Protocol (EAP), defined in [RFC3748],
was designed to enable extensible authentication for network access was designed to enable extensible authentication for network access
skipping to change at page 14, line 13 skipping to change at page 14, line 13
AAA protocols are discussed in Sections 5.1-5.9. AAA protocols are discussed in Sections 5.1-5.9.
The backend authentication server is trusted to transport keying The backend authentication server is trusted to transport keying
material only to the authenticator that was established with the material only to the authenticator that was established with the
peer, and it is trusted to transport that keying material to no other peer, and it is trusted to transport that keying material to no other
parties. In many systems, EAP keying material established by the EAP parties. In many systems, EAP keying material established by the EAP
peer and EAP server are combined with publicly available data to peer and EAP server are combined with publicly available data to
derive other keys. The backend authentication server is trusted to derive other keys. The backend authentication server is trusted to
refrain from deriving these same keys or acting as a man-in-the- refrain from deriving these same keys or acting as a man-in-the-
middle even though it has access to the keying material that is middle even though it has access to the keying material that is
needed to do so. The authenticator is also a trusted party. It is needed to do so.
trusted not to provide keying material it obtains from the backend
authentication server to any other parties. The authenticator is also a trusted party. The authenticator is
trusted not to distribute keying material provided by the backend
authentication server to any other parties. If the authenticator
uses a key derivation function to derive additional keying material,
the authenticator is trusted to distribute the derived keying
material only to the appropriate party that is known to the peer, and
no other party. When this approach is used, care must be taken to
ensure that the resulting key management system meets all of the
principles in this document, confirming that keys used to protect
data are to be known only by the peer and authenticator.
Completion of the Secure Association Protocol (Phase 2) results in Completion of the Secure Association Protocol (Phase 2) results in
the derivation or transport of Transient Session Keys (TSKs) known the derivation or transport of Transient Session Keys (TSKs) known
only to the EAP peer (identified by the Peer-Id(s)) and authenticator only to the EAP peer (identified by the Peer-Id(s)) and authenticator
(identified by the NAS-Identifier). Both the EAP peer and (identified by the NAS-Identifier). Both the EAP peer and
authenticator know the TSKs to be fresh. Both the EAP peer and authenticator know the TSKs to be fresh. Both the EAP peer and
authenticator demonstrate that they are authorized to perform their authenticator demonstrate that they are authorized to perform their
roles. Authorization issues are discussed in Sections 4.3.2 and 5.5; roles. Authorization issues are discussed in Sections 4.3.2 and 5.5;
security properties of Secure Association Protocols are discussed in security properties of Secure Association Protocols are discussed in
Section 3.1. Section 3.1.
skipping to change at page 21, line 14 skipping to change at page 21, line 25
a given authenticator. Similarly, an authenticator can offer network a given authenticator. Similarly, an authenticator can offer network
access to multiple peers, each via a separate physical or logical access to multiple peers, each via a separate physical or logical
port. When a single physical authenticator advertises itself as port. When a single physical authenticator advertises itself as
multiple virtual authenticators, it is possible for a single physical multiple virtual authenticators, it is possible for a single physical
port to belong to multiple virtual authenticators. port to belong to multiple virtual authenticators.
An authenticator can be configured to communicate with more than one An authenticator can be configured to communicate with more than one
EAP server, each of which is configured to communicate with a subset EAP server, each of which is configured to communicate with a subset
of the authenticators. The situation is illustrated in Figure 3. of the authenticators. The situation is illustrated in Figure 3.
2.3. Authenticator Identification
The EAP method conversation is between the EAP peer and server. The
authenticator identity, if considered at all by the EAP method, is
treated as an opaque blob for the purpose of Channel Binding (see
Section 5.3.3). However, the authenticator identity is important in
two other exchanges - the AAA protocol exchange and the Secure
Association Protocol conversation.
The AAA conversation is between the EAP authenticator and the backend
authentication server. From the point of view of the backend
authentication server, keying material and parameters are transported
to the EAP authenticator identified by the NAS-Identifier attribute.
Since an EAP authenticator MUST NOT share EAP keying material or
parameters with another party, if the EAP peer or backend
authentication server detects use of EAP keying material and
parameters outside the scope defined by the NAS-Identifier, the
keying material MUST be considered compromised.
The Secure Association Protocol conversation is between the peer and
the authenticator. For lower layers which support key caching it is
particularly important for the EAP peer, authenticator and backend
server to have a consistent view of the usage scope of the
transported keying material. In order to enable this, it is
RECOMMENDED that the Secure Association Protocol explicitly
communicate the usage scope of the EAP keying material passed down to
the lower layer, rather than implicitly assuming that this is defined
by the authenticator and peer endpoint addresses.
+-+-+-+-+ +-+-+-+-+
| EAP | | EAP |
| Peer | | Peer |
+-+-+-+-+ +-+-+-+-+
| | | Peer Ports | | | Peer Ports
/ | \ / | \
/ | \ / | \
/ | \ / | \
/ | \ / | \
/ | \ / | \
skipping to change at page 21, line 48 skipping to change at page 22, line 40
\ | \ | \ | \ |
\ | \ | \ | \ |
\ | \ | \ | \ |
+-+-+-+-+-+ +-+-+-+-+-+ Backend +-+-+-+-+-+ +-+-+-+-+-+ Backend
| EAP | | EAP | Authentication | EAP | | EAP | Authentication
| Server1 | | Server2 | Servers | Server1 | | Server2 | Servers
+-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+ +-+-+-+-+-+
Figure 3: Relationship between EAP peer, authenticator and server Figure 3: Relationship between EAP peer, authenticator and server
2.3. Authenticator Identification
The EAP method conversation is between the EAP peer and server. The
authenticator identity, if considered at all by the EAP method, is
treated as an opaque blob for the purpose of Channel Binding (see
Section 5.3.3). However, the authenticator identity is important in
two other exchanges - the AAA protocol exchange and the Secure
Association Protocol conversation.
The AAA conversation is between the EAP authenticator and the backend
authentication server. From the point of view of the backend
authentication server, keying material and parameters are transported
to the EAP authenticator identified by the NAS-Identifier attribute.
Since an EAP authenticator MUST NOT share EAP keying material or
parameters with another party, if the EAP peer or backend
authentication server detects use of EAP keying material and
parameters outside the scope defined by the NAS-Identifier, the
keying material MUST be considered compromised.
The Secure Association Protocol conversation is between the peer and
the authenticator. For lower layers which support key caching it is
particularly important for the EAP peer, authenticator and backend
server to have a consistent view of the usage scope of the
transported keying material. In order to enable this, it is
RECOMMENDED that the Secure Association Protocol explicitly
communicate the usage scope of the EAP keying material passed down to
the lower layer, rather than implicitly assuming that this is defined
by the authenticator and peer endpoint addresses.
Since an authenticator can have multiple ports, the scope of the Since an authenticator can have multiple ports, the scope of the
authenticator key cache cannot be described by a single endpoint authenticator key cache cannot be described by a single endpoint
address. Similarly, where a peer can have multiple ports and sharing address. Similarly, where a peer can have multiple ports and sharing
of EAP keying material and parameters between peer ports of the same of EAP keying material and parameters between peer ports of the same
link type is allowed, the extent of the peer key cache cannot be link type is allowed, the extent of the peer key cache cannot be
communicated by using a single endpoint address. Instead, it is communicated by using a single endpoint address. Instead, it is
RECOMMENDED that the EAP peer and authenticator consistently identify RECOMMENDED that the EAP peer and authenticator consistently identify
themselves utilizing explicit identifiers, rather than endpoint themselves utilizing explicit identifiers, rather than endpoint
addresses or port identifiers. addresses or port identifiers.
 End of changes. 13 change blocks. 
45 lines changed or deleted 54 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/