4. Handoff Vulnerabilities
A handoff occurs when an EAP peer moves to a new authenticator.
Several mechanisms have been proposed for reducing handoff latency
within networks utilizing EAP. These include:
In EAP pre-authentication, an EAP peer pre-establishes EAP keying
material with an authenticator prior to arrival. EAP
pre-authentication only affects the timing of EAP authentication,
but does not shorten or eliminate EAP (phase 1a) or AAA (phase 1b)
exchanges; Discovery (phase 0) and Secure Association Protocol
(phase 2) exchanges occur as described in Section 1.3. As a
result, the primary benefit is to enable EAP authentication to be
removed from the handoff critical path, thereby reducing latency.
Use of EAP pre-authentication within IEEE 802.11 is described in
[IEEE-802.11] and [8021XPreAuth].
Proactive key distribution
In proactive key distribution, keying material and authorizations
are transported from the backend authentication server to a
candidate authenticator in advance of a handoff. As a result, EAP
(phase 1a) is not needed, but the Discovery (phase 0), and Secure
Association Protocol exchanges (phase 2) are still necessary.
Within the AAA exchange (phase 1b), authorization and key
distribution functions are typically supported, but not
authentication. Proactive key distribution is described in
[MishraPro], [IEEE-03-084], and [HANDOFF].
Caching of EAP keying material enables an EAP peer to re-attach to
an authenticator without requiring EAP (phase 1a) or AAA (phase
1b) exchanges. However, Discovery (phase 0) and Secure
Association Protocol (phase 2) exchanges are still needed. Use of
key caching within IEEE 802.11 is described in [IEEE-802.11].
In context transfer schemes, keying material and authorizations
are transferred between a previous authenticator and a new
authenticator. This can occur in response to a handoff request by
the EAP peer, or in advance, as in proactive key distribution. As
a result, EAP (phase 1a) is eliminated, but not the Discovery
(phase 0) or Secure Association Protocol exchanges (phase 2). If
a secure channel can be established between the new and previous
authenticator without assistance from the backend authentication
server, then the AAA exchange (phase 1b) can be eliminated;
otherwise, it is still needed, although it can be shortened.
Context transfer protocols are described in [IEEE-802.11F] (now
deprecated) and "Context Transfer Protocol (CXTP)" [RFC4067].
"Fast Authentication Methods for Handovers between IEEE 802.11
Wireless LANs" [Bargh] analyzes fast handoff techniques, including
context transfer mechanisms.
In token distribution schemes, the EAP peer is provided with a
credential, subsequently enabling it to authenticate with one or
more additional authenticators. During the subsequent
authentications, EAP (phase 1a) is eliminated or shortened; the
Discovery (phase 0) and Secure Association Protocol exchanges
(phase 2) still occur, although the latter can be shortened. If
the token includes authorizations and can be validated by an
authenticator without assistance from the backend authentication
server, then the AAA exchange (phase 1b) can be eliminated;
otherwise, it is still needed, although it can be shortened.
Token-based schemes, initially proposed in early versions of IEEE
802.11i [IEEE-802.11i], are described in [Token], [Tokenk], and
The sections that follow discuss the security vulnerabilities
introduced by the above schemes.
4.1. EAP Pre-Authentication
EAP pre-authentication differs from a normal EAP conversation
primarily with respect to the lower-layer encapsulation. For
example, in [IEEE-802.11], EAP pre-authentication frames utilize a
distinct Ethertype, but otherwise conforms to the encapsulation
described in [IEEE-802.1X]. As a result, an EAP pre-authentication
conversation differs little from the model described in Section 1.3,
other than the introduction of a delay between phase 1 and phase 2.
EAP pre-authentication relies on lower-layer mechanisms for discovery
of candidate authenticators. Where discovery can provide information
on candidate authenticators outside the immediate listening range,
and the peer can determine whether it already possesses valid EAP
keying material with candidate authenticators, the peer can avoid
unnecessary EAP pre-authentications and can establish EAP keying
material well in advance, regardless of the coverage overlap between
authenticators. However, if the peer can only discover candidate
authenticators within listening range and cannot determine whether it
can reuse existing EAP keying material, then it is possible that the
peer will not be able to complete EAP pre-authentication prior to
connectivity loss or that it can pre-authenticate multiple times with
the same authenticator, increasing backend authentication server
Since a peer can complete EAP pre-authentication with an
authenticator without eventually attaching to it, it is possible that
phase 2 will not occur. In this case, an Accounting-Request
signifying the start of service will not be sent, or will only be
sent with a substantial delay after the completion of authentication.
As noted in "IEEE 802.1X RADIUS Usage Guidelines" [RFC3580], the AAA
exchange resulting from EAP pre-authentication differs little from an
ordinary exchange described in "RADIUS Support for EAP" [RFC3579].
For example, since in IEEE 802.11 [IEEE-802.11] an Association
exchange does not occur prior to EAP pre-authentication, the SSID is
not known by the authenticator at authentication time, so that an
Access-Request cannot include the SSID within the Called-Station-Id
attribute as described in [RFC3580] Section 3.20.
Since only the absence of an SSID in the Called-Station-Id attribute
distinguishes an EAP pre-authentication attempt, if the authenticator
does not always include the SSID for a normal EAP authentication
attempt, it is possible that the backend authentication server will
not be able to determine whether a session constitutes an EAP
pre-authentication attempt, potentially resulting in authorization or
accounting problems. Where the number of simultaneous sessions is
limited, the backend authentication server can refuse to authorize a
valid EAP pre-authentication attempt or can enable the peer to engage
in more simultaneous sessions than they are authorized for. Where
EAP pre-authentication occurs with an authenticator which the peer
never attaches to, it is possible that the backend accounting server
will not be able to determine whether the absence of an
Accounting-Request was due to packet loss or a session that never
In order to enable pre-authentication requests to be handled more
reliably, it is RECOMMENDED that AAA protocols explicitly identify
EAP pre-authentication. In order to suppress unnecessary EAP
pre-authentication exchanges, it is RECOMMENDED that authenticators
unambiguously identify themselves as described in Section 2.3.
4.2. Proactive Key Distribution
In proactive key distribution schemes, the backend authentication
server transports keying material and authorizations to an
authenticator in advance of the arrival of the peer. The
authenticators selected to receive the transported key material are
selected based on past patterns of peer movement between
authenticators known as the "neighbor graph". In order to reduce
handoff latency, proactive key distribution schemes typically only
demonstrate proof of possession of transported keying material
between the EAP peer and authenticator. During a handoff, the
backend authentication server is not provided with proof that the
peer successfully authenticated to an authenticator; instead, the
authenticator generates a stream of accounting messages without a
corresponding set of authentication exchanges. As described in
[MishraPro], knowledge of the neighbor graph can be established via
static configuration or analysis of authentication exchanges. In
order to prevent corruption of the neighbor graph, new neighbor graph
entries can only be created as the result of a successful EAP
exchange, and accounting packets with no corresponding authentication
exchange need to be verified to correspond to neighbor graph entries
(e.g., corresponding to handoffs between neighbors).
In order to prevent compromise of one authenticator from resulting in
compromise of other authenticators, cryptographic separation needs to
be maintained between the keying material transported to each
authenticator. However, even where cryptographic separation is
maintained, an attacker compromising an authenticator can still
disrupt the operation of other authenticators. As noted in [RFC3579]
Section 4.3.7, in the absence of spoofing detection within the AAA
infrastructure, it is possible for EAP authenticators to impersonate
each other. By forging NAS identification attributes within
authentication messages, an attacker compromising one authenticator
could corrupt the neighbor graph, tricking the backend authentication
server into transporting keying material to arbitrary authenticators.
While this would not enable recovery of EAP keying material without
breaking fundamental cryptographic assumptions, it could enable
subsequent fraudulent accounting messages, or allow an attacker to
disrupt service by increasing load on the backend authentication
server or thrashing the authenticator key cache.
Since proactive key distribution requires the distribution of derived
keying material to candidate authenticators, the effectiveness of
this scheme depends on the ability of backend authentication server
to anticipate the movement of the EAP peer. Since proactive key
distribution relies on backend authentication server knowledge of the
neighbor graph, it is most applicable to intra-domain handoff
scenarios. However, in inter-domain handoff, where there can be many
authenticators, peers can frequently connect to authenticators that
have not been previously encountered, making it difficult for the
backend authentication server to derive a complete neighbor graph.
Since proactive key distribution schemes typically require
introduction of server-initiated messages as described in [RFC5176]
and [HANDOFF], security issues described in [RFC5176] Section 6 are
applicable, including authorization (Section 6.1) and replay
detection (Section 6.3) problems.
4.3. AAA Bypass
Fast handoff techniques that enable elimination of the AAA exchange
(phase 1b) differ fundamentally from typical network access scenarios
(dial-up, wired LAN, etc.) that include user authentication as well
as authorization for the offered service. Where the AAA exchange
(phase 1b) is omitted, authorizations and keying material are not
provided by the backend authentication server, and as a result, they
need to be supplied by other means. This section describes some of
4.3.1. Key Transport
Where transported keying material is not supplied by the backend
authentication server, it needs to be provided by another party
authorized to access that keying material. As noted in Section 1.5,
only the EAP peer, authenticator, and server are authorized to
possess transported keying material. Since EAP peers do not trust
each other, if the backend authentication server does not supply
transported keying material to a new authenticator, it can only be
provided by a previous authenticator.
As noted in Section 1.5, the goal of the EAP conversation is to
derive session keys known only to the peer and the authenticator. If
keying material is replicated between a previous authenticator and a
new authenticator, then the previous authenticator can possess
session keys used between the peer and new authenticator. Also, the
new authenticator can possess session keys used between the peer and
the previous authenticator.
If a one-way function is used to derive the keying material to be
transported to the new authenticator, then the new authenticator
cannot possess previous session keys without breaking a fundamental
As a part of the authentication process, the backend authentication
server determines the user's authorization profile and transmits the
authorizations to the authenticator along with the transported keying
material. Typically, the profile is determined based on the user
identity, but a certificate presented by the user can also provide
The backend authentication server is responsible for making a user
authorization decision, which requires answering the following
(a) Is this a legitimate user of this network?
(b) Is the user allowed to access this network?
(c) Is the user permitted to access this network on this day and at
(d) Is the user within the concurrent session limit?
(e) Are there any fraud, credit limit, or other concerns that could
lead to access denial?
(f) If access is to be granted, what are the service parameters
(mandatory tunneling, bandwidth, filters, and so on) to be
provisioned for the user?
While the authorization decision is, in principle, simple, the
distributed decision making process can add complexity. Where
brokers or proxies are involved, all of the AAA entities in the chain
from the authenticator to the home backend authentication server are
involved in the decision. For example, a broker can deny access even
if the home backend authentication server would allow it, or a proxy
can add authorizations (e.g., bandwidth limits).
Decisions can be based on static policy definitions and profiles as
well as dynamic state (e.g., time of day or concurrent session
limits). In addition to the Accept/Reject decisions made by AAA
entities, service parameters or constraints can be communicated to
The criteria for Accept/Reject decisions or the reasons for choosing
particular authorizations are typically not communicated to the
authenticator, only the final result is. As a result, the
authenticator has no way to know on what the decision was based. Was
a set of authorization parameters sent because this service is always
provided to the user, or was the decision based on the time of day
and the capabilities of the authenticator?
When the AAA exchange (phase 1b) is bypassed, several challenges
arise in ensuring correct authorization:
Theft of service
Bypassing the AAA exchange (phase 1b) SHOULD NOT enable a user to
extend their network access or gain access to services they are
not entitled to.
Consideration of network-wide state
Handoff techniques SHOULD NOT render the backend authentication
server incapable of keeping track of network-wide state. For
example, a backend authentication server can need to keep track of
simultaneous user sessions.
Elevation of privilege
Backend authentication servers often perform conditional
evaluation, in which the authorizations returned in an
Access-Accept message are contingent on the authenticator or on
dynamic state such as the time of day. In this situation,
bypassing the AAA exchange could enable unauthorized access unless
the restrictions are explicitly encoded within the authorizations
provided by the backend authentication server.
A handoff mechanism that provides proper authorization is said to be
"correct". One condition for correctness is as follows:
For a handoff to be "correct" it MUST establish on the new
authenticator the same authorizations as would have been created
had the new authenticator completed a AAA conversation with the
backend authentication server.
A properly designed handoff scheme will only succeed if it is
"correct" in this way. If a successful handoff would establish
"incorrect" authorizations, it is preferable for it to fail. Where
the supported services differ between authenticators, a handoff that
bypasses the backend authentication server is likely to fail.
Section 1.1 of [RFC2865] states:
A authenticator that does not implement a given service MUST NOT
implement the RADIUS attributes for that service. For example, a
authenticator that is unable to offer ARAP service MUST NOT
implement the RADIUS attributes for ARAP. A authenticator MUST
treat a RADIUS access-accept authorizing an unavailable service as
an access-reject instead.
This behavior applies to attributes that are known, but not
implemented. For attributes that are unknown, Section 5 of [RFC2865]
A RADIUS server MAY ignore Attributes with an unknown Type. A
RADIUS client MAY ignore Attributes with an unknown Type.
In order to perform a correct handoff, if a new authenticator is
provided with RADIUS authorizations for a known but unavailable
service, then it MUST process these authorizations the same way it
would handle a RADIUS Access-Accept requesting an unavailable
service; this MUST cause the handoff to fail. However, if a new
authenticator is provided with authorizations including unknown
attributes, then these attributes MAY be ignored. The definition of
a "known but unsupported service" MUST encompass requests for
unavailable security services. This includes vendor-specific
attributes related to security, such as those described in [RFC2548].
Although it can seem somewhat counter-intuitive, failure is indeed
the "correct" result where a known but unsupported service is
Presumably, a correctly configured backend authentication server
would not request that an authenticator provide a service that it
does not implement. This implies that if the new authenticator were
to complete a AAA conversation, it would be likely to receive
different service instructions. Failure of the handoff is the
desired result since it will cause the new authenticator to go back
to the backend server in order to receive the appropriate service
Handoff mechanisms that bypass the backend authentication server are
most likely to be successful when employed in a homogeneous
deployment within a single administrative domain. In a heterogeneous
deployment, the backend authentication server can return different
authorizations depending on the authenticator making the request in
order to make sure that the requested service is consistent with the
authenticator capabilities. Where a backend authentication server
would send different authorizations to the new authenticator than
were sent to a previous authenticator, transferring authorizations
between the previous authenticator and the new authenticator will
result in incorrect authorization.
Virtual LAN (VLAN) support is defined in [IEEE-802.1Q]; RADIUS
support for dynamic VLANs is described in [RFC3580] and [RFC4675].
If some authenticators support dynamic VLANs while others do not,
then attributes present in the Access-Request (such as the
NAS-Port-Type, NAS-IP-Address, NAS-IPv6-Address, and NAS-Identifier)
could be examined by the backend authentication server to determine
when VLAN attributes will be returned, and if so, which ones.
However, if the backend authenticator is bypassed, then a handoff
occurring between authenticators supporting different VLAN
capabilities could result in a user obtaining access to an
unauthorized VLAN (e.g., a user with access to a guest VLAN being
given unrestricted access to the network).
Similarly, it is preferable for a handoff between an authenticator
providing confidentiality and another that does not to fail, since if
the handoff were successful, the user would be moved from a secure to
an insecure channel without permission from the backend
5. Security Considerations
The EAP threat model is described in [RFC3748] Section 7.1. The
security properties of EAP methods (known as "security claims") are
described in [RFC3748] Section 7.2.1. EAP method requirements for
applications such as Wireless LAN authentication are described in
[RFC4017]. The RADIUS threat model is described in [RFC3579] Section
4.1, and responses to these threats are described in [RFC3579],
Sections 4.2 and 4.3.
However, in addition to threats against EAP and AAA, there are other
system level threats. In developing the threat model, it is assumed
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 can be a principal or an outsider.
The attacker can compromise any key that is sufficiently old.
Threats arising from these assumptions include:
(a) An attacker can compromise or steal an EAP peer or
authenticator, in an attempt to gain access to other EAP peers
or authenticators or to obtain long-term secrets.
(b) An attacker can attempt a downgrade attack in order to exploit
known weaknesses in an authentication method or cryptographic
(c) An attacker can try to modify or spoof packets, including
Discovery or Secure Association Protocol frames, EAP or AAA
(d) An attacker can attempt to induce an EAP peer, authenticator, or
server to disclose keying material to an unauthorized party, or
utilize keying material outside the context that it was intended
(e) An attacker can alter, forge, or replay packets.
(f) An attacker can cause an EAP peer, authenticator, or server to
reuse a stale key. Use of stale keys can also occur
unintentionally. For example, a poorly implemented backend
authentication server can provide stale keying material to an
authenticator, or a poorly implemented authenticator can reuse
(g) An authenticated attacker can attempt to obtain elevated
privilege in order to access information that it does not have
(h) An attacker can attempt a man-in-the-middle attack in order to
gain access to the network.
(i) An attacker can compromise an EAP authenticator in an effort to
commit fraud. For example, a compromised authenticator can
provide incorrect information to the EAP peer and/or server via
out-of-band mechanisms (such as via a AAA or lower-layer
protocol). This includes impersonating another authenticator,
or providing inconsistent information to the peer and EAP
(j) An attacker can launch a denial-of-service attack against the
EAP peer, authenticator, or backend authentication server.
In order to address these threats, [RFC4962] Section 3 describes
required and recommended security properties. The sections that
follow analyze the compliance of EAP methods, AAA protocols, and
Secure Association Protocols with those guidelines.
5.1. Peer and Authenticator Compromise
Requirement: In the event that an authenticator is compromised or
stolen, an attacker can gain access to the network through that
authenticator, or can obtain the credentials needed for the
authenticator/AAA client to communicate with one or more backend
authentication servers. Similarly, if a peer is compromised or
stolen, an attacker can obtain credentials needed to communicate with
one or more authenticators. A mandatory requirement from [RFC4962]
Prevent the Domino effect
Compromise of a single peer MUST NOT compromise keying material
held by any other peer within the system, including session keys
and long-term keys. Likewise, compromise of a single
authenticator MUST NOT compromise keying material held by any
other authenticator within the system. In the context of a key
hierarchy, this means that the compromise of one node in the key
hierarchy must not disclose the information necessary to
compromise other branches in the key hierarchy. Obviously, the
compromise of the root of the key hierarchy will compromise all of
the keys; however, a compromise in one branch MUST NOT result in
the compromise of other branches. There are many implications of
this requirement; however, two implications deserve highlighting.
First, the scope of the keying material must be defined and
understood by all parties that communicate with a party that holds
that keying material. Second, a party that holds keying material
in a key hierarchy must not share that keying material with
parties that are associated with other branches in the key
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 members will result in the disclosure of the group key.
Some of the implications of the requirement are as follows:
In order to be able to determine whether keying material has
been shared, it is necessary for the identity of the EAP
authenticator (NAS-Identifier) to be defined and understood by
all parties that communicate with it. EAP lower-layer
specifications such as [IEEE-802.11], [IEEE-802.16e],
[IEEE-802.1X], IKEv2 [RFC4306], and PPP [RFC1661] do not involve
AAA Credential Sharing
AAA credentials (such as RADIUS shared secrets, IPsec pre-shared
keys or certificates) MUST NOT be shared between AAA clients,
since if one AAA client were compromised, this would enable an
attacker to impersonate other AAA clients to the backend
authentication server, or even to impersonate a backend
authentication server to other AAA clients.
Compromise of Long-Term Credentials
An attacker obtaining keying material (such as TSKs, TEKs, or
the MSK) MUST NOT be able to obtain long-term user credentials
such as pre-shared keys, passwords, or private-keys without
breaking a fundamental cryptographic assumption. The mandatory
requirements of [RFC4017] Section 2.2 include generation of EAP
keying material, capability to generate EAP keying material with
128 bits of effective strength, resistance to dictionary
attacks, shared state equivalence, and protection against
5.2. Cryptographic Negotiation
Mandatory requirements from [RFC4962] Section 3:
Cryptographic algorithm independent
The AAA key management protocol MUST be cryptographic algorithm
independent. However, an EAP method MAY depend on a specific
cryptographic algorithm. The ability to negotiate the use of a
particular cryptographic algorithm provides resilience against
compromise of a particular cryptographic algorithm. Algorithm
independence is also REQUIRED with a Secure Association Protocol
if one is defined. This is usually accomplished by including an
algorithm identifier and parameters in the protocol, and by
specifying the algorithm requirements in the protocol
specification. While highly desirable, the ability to negotiate
key derivation functions (KDFs) is not required. For
interoperability, at least one suite of mandatory-to-implement
algorithms MUST be selected. Note that without protection by
IPsec as described in [RFC3579] Section 4.2, RADIUS [RFC2865] does
not meet this requirement, since the integrity protection
algorithm cannot be negotiated.
This requirement does not mean that a protocol must support both
public-key and symmetric-key cryptographic algorithms. It means
that the protocol needs to be structured in such a way that
multiple public-key algorithms can be used whenever a public-key
algorithm is employed. Likewise, it means that the protocol needs
to be structured in such a way that multiple symmetric-key
algorithms can be used whenever a symmetric-key algorithm is
Confirm ciphersuite selection
The selection of the "best" ciphersuite SHOULD be securely
confirmed. The mechanism SHOULD detect attempted roll-back
EAP methods satisfying [RFC4017] Section 2.2 mandatory requirements
and AAA protocols utilizing transmission-layer security are capable
of addressing downgrade attacks. [RFC3748] Section 7.2.1 describes
the "protected ciphersuite negotiation" security claim that refers to
the ability of an EAP method to negotiate the ciphersuite used to
protect the EAP method conversation, as well as to integrity protect
the ciphersuite negotiation. [RFC4017] Section 2.2 requires EAP
methods satisfying this security claim. Since TLS v1.2 [RFC5246] and
IKEv2 [RFC4306] support negotiation of Key Derivation Functions
(KDFs), EAP methods based on TLS or IKEv2 will, if properly designed,
inherit this capability. However, negotiation of KDFs is not
required by RFC 4962 [RFC4962], and EAP methods based on neither TLS
nor IKEv2 typically do not support KDF negotiation.
When AAA protocols utilize TLS [RFC5246] or IPsec [RFC4301] for
transmission layer security, they can leverage the cryptographic
algorithm negotiation support provided by IKEv2 [RFC4306] or TLS
[RFC5246]. RADIUS [RFC3579] by itself does not support cryptographic
algorithm negotiation and relies on MD5 for integrity protection,
authentication, and confidentiality. Given the known weaknesses in
MD5 [MD5Collision], this is undesirable, and can be addressed via use
of RADIUS over IPsec, as described in [RFC3579] Section 4.2.
To ensure against downgrade attacks within lower-layer protocols,
algorithm independence is REQUIRED with lower layers using EAP for
key derivation. For interoperability, at least one suite of
mandatory-to-implement algorithms MUST be selected. Lower-layer
protocols supporting EAP for key derivation SHOULD also support
secure ciphersuite negotiation as well as KDF negotiation.
As described in [RFC1968], PPP ECP does not support secure
ciphersuite negotiation. While [IEEE-802.16e] and [IEEE-802.11]
support ciphersuite negotiation for protection of data, they do not
support negotiation of the cryptographic primitives used within the
Secure Association Protocol, such as message integrity checks (MICs)
5.3. Confidentiality and Authentication
Mandatory requirements from [RFC4962] Section 3:
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
secret values used in the authentication process. When a secure
association protocol is used to establish session keys, the
parties involved in the secure association protocol MUST identify
themselves using identities that are meaningful in the lower-layer
protocol environment that will employ the session keys. In this
situation, the authenticator and peer may be known by different
identifiers in the AAA protocol environment and the lower-layer
protocol environment, making authorization decisions difficult
without a clear key scope. If the lower-layer identifier of the
peer will be used to make authorization decisions, then the pair
of identifiers associated with the peer MUST be authorized by the
authenticator and/or the AAA server.
AAA protocols, such as RADIUS [RFC2865] and Diameter [RFC3588],
provide a mechanism for the identification of AAA clients; since
the EAP authenticator and AAA client are always co-resident, this
mechanism is applicable to the identification of EAP
When multiple base stations and a "controller" (such as a WLAN
switch) comprise a single EAP authenticator, the "base station
identity" is not relevant; the EAP method conversation takes place
between the EAP peer and the EAP server. Also, many base stations
can share the same authenticator identity. The authenticator
identity is important in the AAA protocol exchange and the secure
association protocol conversation.
Authentication mechanisms MUST NOT employ plaintext passwords.
Passwords may be used provided that they are not sent to another
party without confidentiality protection.
Keying material confidentiality and integrity
While preserving algorithm independence, confidentiality and
integrity of all keying material MUST be maintained.
Conformance to these requirements is analyzed in the sections that
Per-packet authentication and integrity protection provides
protection against spoofing attacks.
Diameter [RFC3588] provides support for per-packet authentication and
integrity protection via use of IPsec or TLS. RADIUS/EAP [RFC3579]
provides for per-packet authentication and integrity protection via
use of the Message-Authenticator Attribute.
[RFC3748] Section 7.2.1 describes the "integrity protection" security
claim and [RFC4017] Section 2.2 requires EAP methods supporting this
In order to prevent forgery of Secure Association Protocol frames,
per-frame authentication and integrity protection is RECOMMENDED on
all messages. IKEv2 [RFC4306] supports per-frame integrity
protection and authentication, as does the Secure Association
Protocol defined in [IEEE-802.16e]. [IEEE-802.11] supports per-frame
integrity protection and authentication on all messages within the
4-way handshake except the first message. An attack leveraging this
omission is described in [Analysis].
Both RADIUS [RFC2865] and Diameter [RFC3588] implementations are
potentially vulnerable to a rogue authenticator impersonating another
authenticator. While both protocols support mutual authentication
between the AAA client/authenticator and the backend authentication
server, the security mechanisms vary.
In RADIUS, the shared secret used for authentication is determined by
the source address of the RADIUS packet. However, when RADIUS
Access-Requests are forwarded by a proxy, the NAS-IP-Address,
NAS-Identifier, or NAS-IPv6-Address attributes received by the RADIUS
server will not correspond to the source address. As noted in
[RFC3579] Section 4.3.7, if the first-hop proxy does not check the
NAS identification attributes against the source address in the
Access-Request packet, it is possible for a rogue authenticator to
forge NAS-IP-Address [RFC2865], NAS-IPv6-Address [RFC3162], or
NAS-Identifier [RFC2865] attributes in order to impersonate another
authenticator; attributes such as the Called-Station-Id [RFC2865] and
Calling-Station-Id [RFC2865] can be forged as well. Among other
things, this can result in messages (and transported keying material)
being sent to the wrong authenticator.
While [RFC3588] requires use of the Route-Record AVP, this utilizes
Fully Qualified Domain Names (FQDNs), so that impersonation detection
requires DNS A, AAAA, and PTR Resource Records (RRs) to be properly
configured. As a result, Diameter is as vulnerable to this attack as
RADIUS, if not more so. [RFC3579] Section 4.3.7 recommends
mechanisms for impersonation detection; to prevent access to keying
material by proxies without a "need to know", it is necessary to
allow the backend authentication server to communicate with the
authenticator directly, such as via the redirect functionality
supported in [RFC3588].
5.3.3. Channel Binding
It is possible for a compromised or poorly implemented EAP
authenticator to communicate incorrect information to the EAP peer
and/or server. This can enable an authenticator to impersonate
another authenticator or communicate incorrect information via
out-of-band mechanisms (such as via AAA or the lower layer).
Where EAP is used in pass-through mode, the EAP peer does not verify
the identity of the pass-through authenticator within the EAP
conversation. Within the Secure Association Protocol, the EAP peer
and authenticator only demonstrate mutual possession of the
transported keying material; they do not mutually authenticate. This
creates a potential security vulnerability, described in [RFC3748]
As described in [RFC3579] Section 4.3.7, it is possible for a
first-hop AAA proxy to detect a AAA client attempting to impersonate
another authenticator. However, it is possible for a pass-through
authenticator acting as a AAA client to provide correct information
to the backend authentication server while communicating misleading
information to the EAP peer via the lower layer.
For example, a compromised authenticator can utilize another
authenticator's Called-Station-Id or NAS-Identifier in communicating
with the EAP peer via the lower layer. Also, a pass-through
authenticator acting as a AAA client can provide an incorrect peer
Calling-Station-Id [RFC2865] [RFC3580] to the backend authentication
server via the AAA protocol.
As noted in [RFC3748] Section 7.15, this vulnerability can be
addressed by EAP methods that support a protected exchange of channel
properties such as endpoint identifiers, including (but not limited
to): Called-Station-Id [RFC2865] [RFC3580], Calling-Station-Id
[RFC2865] [RFC3580], NAS-Identifier [RFC2865], NAS-IP-Address
[RFC2865], and NAS-IPv6-Address [RFC3162].
Using such a protected exchange, it is possible to match the channel
properties provided by the authenticator via out-of-band mechanisms
against those exchanged within the EAP method. Typically, the EAP
method imports channel binding parameters from the lower layer on the
peer, and transmits them securely to the EAP server, which exports
them to the lower layer or AAA layer. However, transport can occur
from EAP server to peer, or can be bi-directional. On the side of
the exchange (peer or server) where channel binding is verified, the
lower layer or AAA layer passes the result of the verification (TRUE
or FALSE) up to the EAP method. While the verification can be done
either by the peer or the server, typically only the server has the
knowledge to determine the correctness of the values, as opposed to
merely verifying their equality. For further discussion, see
It is also possible to perform channel binding without transporting
data over EAP, as described in [EAP-CHANNEL]. In this approach the
EAP method includes channel binding parameters in the calculation of
exported EAP keying material, making it impossible for the peer and
authenticator to complete the Secure Association Protocol if there is
a mismatch in the channel binding parameters. However, this approach
can only be applied where methods generating EAP keying material are
used along with lower layers that utilize EAP keying material. For
example, this mechanism would not enable verification of channel
binding on wired IEEE 802 networks using [IEEE-802.1X].
5.3.4. Mutual Authentication
[RFC3748] Section 7.2.1 describes the "mutual authentication" and
"dictionary attack resistance" claims, and [RFC4017] requires EAP
methods satisfying these claims. EAP methods complying with
[RFC4017] therefore provide for mutual authentication between the EAP
peer and server.
[RFC3748] Section 7.2.1 also describes the "Cryptographic binding"
security claim, and [RFC4017] Section 2.2 requires support for this
claim. As described in [EAP-BINDING], EAP method sequences and
compound authentication mechanisms can be subject to
man-in-the-middle attacks. When such attacks are successfully
carried out, the attacker acts as an intermediary between a victim
and a legitimate authenticator. This allows the attacker to
authenticate successfully to the authenticator, as well as to obtain
access to the network.
In order to prevent these attacks, [EAP-BINDING] recommends
derivation of a compound key by which the EAP peer and server can
prove that they have participated in the entire EAP exchange. Since
the compound key MUST NOT be known to an attacker posing as an
authenticator, and yet must be derived from EAP keying material, it
MAY be desirable to derive the compound key from a portion of the
EMSK. Where this is done, in order to provide proper key hygiene, it
is RECOMMENDED that the compound key used for man-in-the-middle
protection be cryptographically separate from other keys derived from
Diameter [RFC3588] provides for per-packet authentication and
integrity protection via IPsec or TLS, and RADIUS/EAP [RFC3579] also
provides for per-packet authentication and integrity protection.
Where the authenticator/AAA client and backend authentication server
communicate directly and credible key wrap is used (see Section 3.8),
this ensures that the AAA Key Transport (phase 1b) achieves its
security objectives: mutually authenticating the AAA
client/authenticator and backend authentication server and providing
transported keying material to the EAP authenticator and to no other
[RFC2607] Section 7 describes the security issues occurring when the
authenticator/AAA client and backend authentication server do not
communicate directly. Where a AAA intermediary is present (such as a
RADIUS proxy or a Diameter agent), and data object security is not
used, transported keying material can be recovered by an attacker in
control of the intermediary. As discussed in Section 2.1, unless the
TSKs are derived independently from EAP keying material (as in
IKEv2), possession of transported keying material enables decryption
of data traffic sent between the peer and the authenticator to whom
the keying material was transported. It also allows the AAA
intermediary to impersonate the authenticator or the peer. Since the
peer does not authenticate to a AAA intermediary, it has no ability
to determine whether it is authentic or authorized to obtain keying
However, as long as transported keying material or keys derived from
it are only utilized by a single authenticator, compromise of the
transported keying material does not enable an attacker to
impersonate the peer to another authenticator. Vulnerability to
compromise of a AAA intermediary can be mitigated by implementation
of redirect functionality, as described in [RFC3588] and [RFC4072].
The Secure Association Protocol does not provide for mutual
authentication between the EAP peer and authenticator, only mutual
proof of possession of transported keying material. In order for the
peer to verify the identity of the authenticator, mutual proof of
possession needs to be combined with impersonation prevention and
channel binding. Impersonation prevention (described in Section
5.3.2) enables the backend authentication server to determine that
the transported keying material has been provided to the correct
authenticator. When utilized along with impersonation prevention,
channel binding (described in Section 5.3.3) enables the EAP peer to
verify that the EAP server has authorized the authenticator to
possess the transported keying material. Completion of the Secure
Association Protocol exchange demonstrates that the EAP peer and the
authenticator possess the transported keying material.
5.4. Key Binding
Mandatory requirement from [RFC4962] Section 3:
Bind key to its context
Keying material MUST be bound to the appropriate context. The
context includes the following:
o The manner in which the keying material is expected to be used.
o The other parties that are expected to have access to the
o The expected lifetime of the keying material. Lifetime of a
child key SHOULD NOT be greater than the lifetime of its parent
in the key hierarchy.
Any party with legitimate access to keying material can determine
its context. In addition, the protocol MUST ensure that all
parties with legitimate access to keying material have the same
context for the keying material. This requires that the parties
are properly identified and authenticated, so that all of the
parties that have access to the keying material can be determined.
The context will include the peer and NAS identities in more than
one form. One (or more) name form is needed to identify these
parties in the authentication exchange and the AAA protocol.
Another name form may be needed to identify these parties within
the lower layer that will employ the session key.
Within EAP, exported keying material (MSK, EMSK,IV) is bound to the
Peer-Id(s) and Server-Id(s), which are exported along with the keying
material. However, not all EAP methods support authenticated server
identities (see Appendix A).
Within the AAA protocol, transported keying material is destined for
the EAP authenticator identified by the NAS-Identifier Attribute
within the request, and is for use by the EAP peer identified by the
Peer-Id(s), User-Name [RFC2865], or Chargeable User Identity (CUI)
[RFC4372] attributes. The maximum lifetime of the transported keying
material can be provided, as discussed in Section 3.5.1. Key usage
restrictions can also be included as described in Section 3.2. Key
lifetime issues are discussed in Sections 3.3, 3.4, and 3.5.