< draft-ietf-eap-keying-21.txt   draft-ietf-eap-keying-22.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 11, 2008 Nokia
31 October 2007 11 November 2007
Extensible Authentication Protocol (EAP) Key Management Framework Extensible Authentication Protocol (EAP) Key Management Framework
draft-ietf-eap-keying-21.txt draft-ietf-eap-keying-22.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 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 1, 2008. This Internet-Draft will expire on May 11, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). All rights reserved. Copyright (C) The IETF Trust (2007). All rights reserved.
Abstract Abstract
The Extensible Authentication Protocol (EAP), defined in RFC 3748, The Extensible Authentication Protocol (EAP), defined in RFC 3748,
enables extensible network access authentication. This document enables extensible network access authentication. This document
specifies the EAP key hierarchy and provides a framework for the specifies the EAP key hierarchy and provides a framework for the
skipping to change at page 2, line 48 skipping to change at page 2, line 48
5.5 Authorization ................................... 57 5.5 Authorization ................................... 57
5.6 Replay Protection ............................... 59 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 ....................... 63 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 .......................... 64 7.2 Informative References .......................... 64
Acknowledgments .............................................. 70 Acknowledgments .............................................. 69
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
in situations in which the Internet Protocol (IP) protocol is not in situations in which the Internet Protocol (IP) protocol is not
skipping to change at page 5, line 35 skipping to change at page 5, line 35
Keying Material Keying Material
Unless otherwise qualified, the term "keying material" refers to Unless otherwise qualified, the term "keying material" refers to
EAP keying material as well as derived keying material. EAP keying material as well as derived keying material.
Key Scope Key Scope
The parties to whom a key is available. The parties to whom a key is available.
Key Wrap Key Wrap
The encryption of one symmetric cryptographic key in another. The The encryption of one symmetric cryptographic key in another. The
algorithm used for the encryption is called a key wrap algorithm or algorithm used for the encryption is called a key wrap algorithm or
a key encryption algorithm. The key used in the encryption process a key encryption algorithm. The key used in the encryption process
is called a key-encryption key (KEK). is called a key-encryption key (KEK).
Long Term Credential Long Term Credential
EAP methods frequently make use of long term secrets in order to EAP methods frequently make use of long term secrets in order to
enable authentication between the peer and server. In the case of enable authentication between the peer and server. In the case of
a method based on pre-shared key authentication, the long term a method based on pre-shared key authentication, the long term
credential is the pre-shared key. In the case of a public-key credential is the pre-shared key. In the case of a public-key
based method, the long term credential is the corresponding private based method, the long term credential is the corresponding private
key. key.
skipping to change at page 12, line 10 skipping to change at page 12, line 10
the EAP server will not authenticate the identity of the EAP peer the EAP server will not authenticate the identity of the EAP peer
with which it derived keying material. with which it derived keying material.
Server-Id Server-Id
If an EAP method that generates keys authenticates one or more If an EAP method that generates keys authenticates one or more
method-specific server identities, those identities are exported method-specific server identities, those identities are exported
by the method as the Server-Id(s). It is possible for more than by the method as the Server-Id(s). It is possible for more than
one Server-Id to be exported by an EAP method. Not all EAP one Server-Id to be exported by an EAP method. Not all EAP
methods provide a method-specific server identity; where this is methods provide a method-specific server identity; where this is
not defined, the Server-Id is the null string. If the EAP method not defined, the Server-Id is the null string. If the EAP method
not generate keying material, the Server-Id MUST be the null does not generate keying material, the Server-Id MUST be the null
string. Where an EAP method that derives keys does not provide a string. Where an EAP method that derives keys does not provide a
Server-Id, the EAP peer will not authenticate the identity of the Server-Id, the EAP peer will not authenticate the identity of the
EAP server with which it derived EAP keying material. EAP server with which it derived EAP keying material.
Session-Id Session-Id
The Session-Id uniquely identifies an EAP session between an EAP The Session-Id uniquely identifies an EAP session between an EAP
peer (as identified by the Peer-Id) and server (as identified by peer (as identified by the Peer-Id) and server (as identified by
the Server-Id). Where non-expanded EAP Type Codes are used (EAP the Server-Id). Where non-expanded EAP Type Codes are used (EAP
Type Code not equal to 254), the EAP Session-Id is the Type Code not equal to 254), the EAP Session-Id is the
skipping to change at page 13, line 42 skipping to change at page 13, line 42
between the EAP peer and authenticator that are known only to those between the EAP peer and authenticator that are known only to those
parties, and for both the EAP peer and authenticator to demonstrate parties, and for both the EAP peer and authenticator to demonstrate
that they are authorized to perform their roles either by each other that they are authorized to perform their roles either by each other
or by a trusted third party (the backend authentication server). or by a trusted third party (the backend authentication server).
Completion of an EAP method exchange (Phase 1a) supporting key Completion of an EAP method exchange (Phase 1a) supporting key
derivation results in the derivation of EAP keying material (MSK, derivation results in the derivation of EAP keying material (MSK,
EMSK, TEKs) known only to the EAP peer (identified by the Peer-Id(s)) EMSK, TEKs) known only to the EAP peer (identified by the Peer-Id(s))
and EAP server (identified by the Server-Id(s)). Both the EAP peer and EAP server (identified by the Server-Id(s)). Both the EAP peer
and EAP server know this keying material to be fresh. The Peer-Id and EAP server know this keying material to be fresh. The Peer-Id
and Server-Id are discussed in Section 1.4 and Appendix A. Key and Server-Id are discussed in Sections 1.4, 2.4 and 2.5 as well as
freshness is discussed in Sections 3.4, 3.5 and 5.7. in Appendix A. Key freshness is discussed in Sections 3.4, 3.5 and
5.7.
Completion of the AAA exchange (Phase 1b) results in the transport of Completion of the AAA exchange (Phase 1b) results in the transport of
keying material from the EAP server (identified by the Server-Id(s)) keying material from the EAP server (identified by the Server-Id(s))
to the EAP authenticator (identified by the NAS-Identifier) without to the EAP authenticator (identified by the NAS-Identifier) without
disclosure to any other party. Both the EAP server and EAP disclosure to any other party. Both the EAP server and EAP
authenticator know this keying material to be fresh. Disclosure authenticator know this keying material to be fresh. Disclosure
issues are discussed in Sections 3.8 and 5.3; security properties of issues are discussed in Sections 3.8 and 5.3; security properties of
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. needed to do so.
The authenticator is also a trusted party. The authenticator is The authenticator is also a trusted party. The authenticator is
trusted not to distribute keying material provided by the backend trusted not to distribute keying material provided by the backend
authentication server to any other parties. If the authenticator authentication server to any other parties. If the authenticator
uses a key derivation function to derive additional keying material, uses a key derivation function to derive additional keying material,
the authenticator is trusted to distribute the derived keying the authenticator is trusted to distribute the derived keying
material only to the appropriate party that is known to the peer, and 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 no other party. When this approach is used, care must be taken to
ensure that the resulting key management system meets all of the ensure that the resulting key management system meets all of the
principles in this document, confirming that keys used to protect principles in [RFC4962], confirming that keys used to protect data
data are to be known only by the peer and authenticator. 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 19, line 27 skipping to change at page 19, line 27
IEEE 802.1X-2004 IEEE 802.1X-2004
When used with wired networks, IEEE 802.1X-2004 [IEEE-802.1X] does When used with wired networks, IEEE 802.1X-2004 [IEEE-802.1X] does
not support link layer ciphersuites and a result, it does not not support link layer ciphersuites and a result, it does not
provide for generation of TSKs, or caching of EAP keying material provide for generation of TSKs, or caching of EAP keying material
and parameters. Once EAP authentication completes, it is assumed and parameters. Once EAP authentication completes, it is assumed
that EAP keying material and parameters are discarded; on IEEE 802 that EAP keying material and parameters are discarded; on IEEE 802
wired networks there is no subsequent Secure Association Protocol wired networks there is no subsequent Secure Association Protocol
exchange. Perfect Forward Secrecy (PFS) is only possible if the exchange. Perfect Forward Secrecy (PFS) is only possible if the
negotiated EAP method supports this. negotiated EAP method supports this.
PPP PPP, defined in [RFC1661] does not include support for a Secure PPP PPP, defined in [RFC1661], does not include support for a Secure
Association Protocol; nor does it support caching of EAP keying Association Protocol; nor does it support caching of EAP keying
material or parameters. PPP ciphersuites derive their TSKs material or parameters. PPP ciphersuites derive their TSKs
directly from the MSK, as described in [RFC2716]. This is NOT directly from the MSK, as described in [RFC2716]. This is NOT
RECOMMENDED, since if PPP were to support caching of EAP keying RECOMMENDED, since if PPP were to support caching of EAP keying
material, this could result in TSK reuse. As a result, once the material, this could result in TSK reuse. As a result, once the
PPP session is terminated, EAP keying material and parameters MUST PPP session is terminated, EAP keying material and parameters MUST
be discarded. Since caching of EAP keying material is not be discarded. Since caching of EAP keying material is not
permitted within PPP, there is no way to handle TSK re-key without permitted within PPP, there is no way to handle TSK re-key without
EAP re-authentication. Perfect Forward Secrecy (PFS) is only EAP re-authentication. Perfect Forward Secrecy (PFS) is only
possible if the negotiated EAP method supports this. possible if the negotiated EAP method supports this.
IKEv2 IKEv2
IKEv2, defined in [RFC4306] only uses the MSK for authentication IKEv2, defined in [RFC4306], only uses the MSK for authentication
purposes and not key derivation. The EMSK, IV, Peer-Id, Server-Id purposes and not key derivation. The EMSK, IV, Peer-Id, Server-Id
or Session-Id are not used. As a result, the TSKs derived by IKEv2 or Session-Id are not used. As a result, the TSKs derived by IKEv2
are cryptographically independent of the EAP keying material and are cryptographically independent of the EAP keying material and
re-key of IPsec SAs can be handled without requiring EAP re- re-key of IPsec SAs can be handled without requiring EAP re-
authentication. Within IKEv2 it is possible to negotiate PFS, authentication. Within IKEv2 it is possible to negotiate PFS,
regardless of which EAP method is negotiated. IKEv2 as specified regardless of which EAP method is negotiated. IKEv2 as specified
in [RFC4306] does not cache EAP keying material or parameters; once in [RFC4306] does not cache EAP keying material or parameters; once
IKEv2 authentication completes it is assumed that EAP keying IKEv2 authentication completes it is assumed that EAP keying
material and parameters are discarded. The Session-Timeout material and parameters are discarded. The Session-Timeout
attribute is therefore interpreted as a limit on the VPN session attribute is therefore interpreted as a limit on the VPN session
skipping to change at page 25, line 26 skipping to change at page 25, line 26
entry. entry.
(c) It is RECOMMENDED that each virtual authenticator identify itself (c) It is RECOMMENDED that each virtual authenticator identify itself
consistently to the peer and to the backend authentication server, consistently to the peer and to the backend authentication server,
so as to enable the peer to verify the authenticator identity via so as to enable the peer to verify the authenticator identity via
Channel Binding (see Section 5.3.3). Channel Binding (see Section 5.3.3).
(d) It is RECOMMENDED that each virtual authenticator identify itself (d) It is RECOMMENDED that each virtual authenticator identify itself
distinctly, in order to enable the peer and backend server to tell distinctly, in order to enable the peer and backend server to tell
them apart. For example, this can be accomplished by utilizing a them apart. For example, this can be accomplished by utilizing a
distinct NAS-Identifier attribute. distinct value of the NAS-Identifier attribute.
2.4. Peer Identification 2.4. Peer Identification
As described in [RFC3748] Section 7.3, the peer identity provided in As described in [RFC3748] Section 7.3, the peer identity provided in
the EAP-Response/Identity can be different from the peer identities the EAP-Response/Identity can be different from the peer identities
authenticated by the EAP method. For example, the identity provided authenticated by the EAP method. For example, the identity provided
in the EAP-Response/Identity can be a privacy identifier as described in the EAP-Response/Identity can be a privacy identifier as described
in "The Network Access Identifier" [RFC4282] Section 2. As noted in in "The Network Access Identifier" [RFC4282] Section 2. As noted in
[RFC4284], it is also possible to utilize a Network Access Identifier [RFC4284], it is also possible to utilize a Network Access Identifier
(NAI) for the purposes of source routing; an NAI utilized for source (NAI) for the purposes of source routing; an NAI utilized for source
skipping to change at page 48, line 28 skipping to change at page 48, line 28
in a key hierarchy must not share that keying material with in a key hierarchy must not share that keying material with
parties that are associated with other branches in the key parties that are associated with other branches in the key
hierarchy. hierarchy.
Group keys are an obvious exception. Since all members of the Group keys are an obvious exception. Since all members of the
group have a copy of the same key, compromise of any one of the group have a copy of the same key, compromise of any one of the
group members will result in the disclosure of the group key. group members will result in the disclosure of the group key.
Some of the implications of the requirement are as follows: Some of the implications of the requirement are as follows:
No Key Sharing Key Sharing
An EAP authenticator MUST NOT share any keying material with In order to be able to determine whether keying material has been
another EAP authenticator, since if one EAP authenticator were shared, it is necessary for the identity of the EAP authenticator
compromised, this would enable the compromise of keying material on (NAS-Identifier) to be defined and understood by all parties that
another authenticator. In order to be able to determine whether communicate with it. EAP lower layer specifications such as
keying material has been shared, it is necessary for the identity [IEEE-802.11], [IEEE-802.16e], [IEEE-802.1X], IKEv2 [RFC4306] and
of the EAP authenticator (NAS-Identifier) to be defined and PPP [RFC1661] do not involve key sharing.
understood by all parties that communicate with it. Similarly, an
EAP peer MUST NOT share any keying material with another EAP peer.
EAP lower layer specifications such as [IEEE-802.11],
[IEEE-802.16e], [IEEE-802.1X], IKEv2 [RFC4306] and PPP [RFC1661] do
not involve key sharing.
No AAA Credential Sharing AAA Credential Sharing
AAA credentials (such as RADIUS shared secrets, IPsec pre-shared AAA credentials (such as RADIUS shared secrets, IPsec pre-shared
keys or certificates) MUST NOT be shared between AAA clients, since keys or certificates) MUST NOT be shared between AAA clients, since
if one AAA client were compromised, this would enable an attacker if one AAA client were compromised, this would enable an attacker
to impersonate other AAA clients to the backend authentication to impersonate other AAA clients to the backend authentication
server, or even to impersonate a backend authentication server to server, or even to impersonate a backend authentication server to
other AAA clients. other AAA clients.
No Compromise of Long-Term Credentials Compromise of Long-Term Credentials
An attacker obtaining keying material (such as TSKs, TEKs or the An attacker obtaining keying material (such as TSKs, TEKs or the
MSK) MUST NOT be able to obtain long-term user credentials such as MSK) MUST NOT be able to obtain long-term user credentials such as
pre-shared keys, passwords or private-keys without breaking a pre-shared keys, passwords or private-keys without breaking a
fundamental cryptographic assumption. The mandatory requirements fundamental cryptographic assumption. The mandatory requirements
of [RFC4017] Section 2.2 include generation of EAP keying material, of [RFC4017] Section 2.2 include generation of EAP keying material,
capability to generate EAP keying material with 128-bits of capability to generate EAP keying material with 128-bits of
effective strength, resistance to dictionary attacks, shared state effective strength, resistance to dictionary attacks, shared state
equivalence and protection against man-in-the-middle attacks. equivalence and protection against man-in-the-middle attacks.
5.2. Cryptographic Negotiation 5.2. Cryptographic Negotiation
skipping to change at page 50, line 8 skipping to change at page 49, line 51
confirmed. The mechanism SHOULD detect attempted roll-back confirmed. The mechanism SHOULD detect attempted roll-back
attacks. attacks.
EAP methods satisfying [RFC4017] Section 2.2 mandatory requirements EAP methods satisfying [RFC4017] Section 2.2 mandatory requirements
and AAA protocols utilizing transmission layer security are capable and AAA protocols utilizing transmission layer security are capable
of addressing downgrade attacks. [RFC3748] Section 7.2.1 describes of addressing downgrade attacks. [RFC3748] Section 7.2.1 describes
the "protected ciphersuite negotiation" security claim that refers to the "protected ciphersuite negotiation" security claim that refers to
the ability of an EAP method to negotiate the ciphersuite used to the ability of an EAP method to negotiate the ciphersuite used to
protect the EAP method conversation, as well as to integrity protect protect the EAP method conversation, as well as to integrity protect
the ciphersuite negotiation. [RFC4017] Section 2.2 requires EAP the ciphersuite negotiation. [RFC4017] Section 2.2 requires EAP
methods satisfying this security claim. Since TLS v1.2 [I-D.ietf- methods satisfying this security claim. Since TLS v1.2
tls-rfc4346-bis] supports negotiation of Key Distribution Functions
(KDFs), EAP methods based on TLS will, if properly designed, inherit [I-D.ietf-tls-rfc4346-bis] supports negotiation of Key Distribution
this capability. However, negotiation of KDFs is not required by RFC Functions (KDFs), EAP methods based on TLS will, if properly
4962 [RFC4962], and EAP methods not based on TLS typically do not designed, inherit this capability. However, negotiation of KDFs is
support KDF negotiation. not required by RFC 4962 [RFC4962], and EAP methods not based on TLS
typically do not support KDF negotiation.
Diameter [RFC3588] provides support for cryptographic algorithm Diameter [RFC3588] provides support for cryptographic algorithm
negotiation via use of IPsec [RFC4301] or TLS [RFC4346]. Since IKEv2 negotiation via use of IPsec [RFC4301] or TLS [RFC4346]. Since IKEv2
[RFC4306] does not support KDF negotiation, support for KDF [RFC4306] does not support KDF negotiation, support for KDF
negotiation is only available when Diameter runs over TLS v1.2. negotiation is only available when Diameter runs over TLS v1.2.
RADIUS [RFC3579] does not support cryptographic algorithm negotiation RADIUS [RFC3579] does not support cryptographic algorithm negotiation
and relies on MD5 for integrity protection, authentication and and relies on MD5 for integrity protection, authentication and
confidentiality. Given the known weaknesses in MD5 [MD5Collision] confidentiality. Given the known weaknesses in MD5 [MD5Collision]
this is undesirable, and can be addressed via use of RADIUS over this is undesirable, and can be addressed via use of RADIUS over
IPsec, as described in [RFC3579] Section 4.2. IPsec, as described in [RFC3579] Section 4.2.
skipping to change at page 50, line 41 skipping to change at page 50, line 37
As described in [RFC1968], PPP ECP does not support secure As described in [RFC1968], PPP ECP does not support secure
ciphersuite negotiation. While [IEEE 802.16e] and [IEEE-802.11] ciphersuite negotiation. While [IEEE 802.16e] and [IEEE-802.11]
support ciphersuite negotiation for protection of data, they do not support ciphersuite negotiation for protection of data, they do not
support negotiation of the cryptographic primitives used within the support negotiation of the cryptographic primitives used within the
Secure Association Protocol, such as message integrity checks (MICs) Secure Association Protocol, such as message integrity checks (MICs)
and KDFs. and KDFs.
5.3. Confidentiality and Authentication 5.3. Confidentiality and Authentication
Requirement: Each party in the EAP, AAA and Secure Association Mandatory requirements from [RFC4962] Section 3:
Protocol conversations MUST be authenticated to the other parties
with whom they communicate. Mandatory requirements from [RFC4962]
Section 3:
Authenticate all parties Authenticate all parties
Each party in the AAA key management protocol MUST be
authenticated to the other parties with whom they communicate.
Authentication mechanisms MUST maintain the confidentiality of any Authentication mechanisms MUST maintain the confidentiality of any
secret values used in the authentication process. When a secure secret values used in the authentication process. When a secure
association protocol is used to establish session keys, the association protocol is used to establish session keys, the
parties involved in the secure association protocol MUST identify parties involved in the secure association protocol MUST identify
themselves using identities that are meaningful in the lower-layer themselves using identities that are meaningful in the lower-layer
protocol environment that will employ the session keys. In this protocol environment that will employ the session keys. In this
situation, the authenticator and peer may be known by different situation, the authenticator and peer may be known by different
identifiers in the AAA protocol environment and the lower-layer identifiers in the AAA protocol environment and the lower-layer
protocol environment, making authorization decisions difficult protocol environment, making authorization decisions difficult
without a clear key scope. If the lower-layer identifier of the without a clear key scope. If the lower-layer identifier of the
skipping to change at page 57, line 26 skipping to change at page 57, line 11
Peer and authenticator authorization MUST be performed. These Peer and authenticator authorization MUST be performed. These
entities MUST demonstrate possession of the appropriate keying entities MUST demonstrate possession of the appropriate keying
material, without disclosing it. Authorization is REQUIRED material, without disclosing it. Authorization is REQUIRED
whenever a peer associates with a new authenticator. The whenever a peer associates with a new authenticator. The
authorization checking prevents an elevation of privilege attack, authorization checking prevents an elevation of privilege attack,
and it ensures that an unauthorized authenticator is detected. and it ensures that an unauthorized authenticator is detected.
Authorizations SHOULD be synchronized between the peer, NAS, and Authorizations SHOULD be synchronized between the peer, NAS, and
backend authentication server. Once the AAA key management backend authentication server. Once the AAA key management
protocol exchanges are complete, all of these parties should hold protocol exchanges are complete, all of these parties should hold
a common view of the authorizations associated the other parties. a common view of the authorizations associated with the other
parties.
In addition to authenticating all parties, key management In addition to authenticating all parties, key management
protocols need to demonstrate that the parties are authorized to protocols need to demonstrate that the parties are authorized to
possess keying material. Note that proof of possession of keying possess keying material. Note that proof of possession of keying
material does not necessarily prove authorization to hold that material does not necessarily prove authorization to hold that
keying material. For example, within an IEEE 802.11, the 4-way keying material. For example, within an IEEE 802.11, the 4-way
handshake demonstrates that both the peer and authenticator handshake demonstrates that both the peer and authenticator
possess the same EAP keying material. However, by itself, this possess the same EAP keying material. However, by itself, this
possession proof does not demonstrate that the authenticator was possession proof does not demonstrate that the authenticator was
authorized by the backend authentication server to possess that authorized by the backend authentication server to possess that
keying material. As noted in [RFC3579] in Section 4.3.7, where keying material. As noted in [RFC3579] in Section 4.3.7, where
AAA proxies are present, it is possible for one authenticator to AAA proxies are present, it is possible for one authenticator to
impersonate another, unless each link in the AAA chain implements impersonate another, unless each link in the AAA chain implements
checks against impersonation. Even with these checks in place, an checks against impersonation. Even with these checks in place, an
authenticator may still claim different identities to the peer and authenticator may still claim different identities to the peer and
the backend authentication server. As described in [RFC3748] the backend authentication server. As described in [RFC3748]
Section 7.15, channel binding enables the peer to verify that the Section 7.15, channel binding is required to enable the peer to
authenticator claim of identity is both consistent and correct. verify that the authenticator claim of identity is both consistent
and correct.
Recommendation from [RFC4962] Section 3: Recommendation from [RFC4962] Section 3:
Authorization restriction Authorization restriction
If peer authorization is restricted, then the peer SHOULD be made If peer authorization is restricted, then the peer SHOULD be made
aware of the restriction. Otherwise, the peer may inadvertently aware of the restriction. Otherwise, the peer may inadvertently
attempt to circumvent the restriction. For example, authorization attempt to circumvent the restriction. For example, authorization
restrictions in an IEEE 802.11 environment include: restrictions in an IEEE 802.11 environment include:
 End of changes. 20 change blocks. 
42 lines changed or deleted 40 lines changed or added

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