eap Mailing List: Proposed Resolution of Issue 15: NASREQ Key Distribution Insecure

[Bernard Aboba (aboba]

The text of Issue 15 is enclosed below.  The proposed resolution is as
follows:

Add Section 6.6 and 6.7:

"6.6 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 may enable an authenticator to impersonate
another authenticator or communicate incorrect information via
out-of-band mechanisms (such as via a AAA or lower layer protocol).

Where EAP is used in pass-through mode, the EAP peer typically does
not verify the identity of the pass-through authenticator, it only
verifies that the pass-through authenticator is trusted by the EAP
server. This creates a potential security vulnerability, described
in Section 7.15 of [RFC2284bis].

Section 4.3.7 of [RFC3579] describes how an EAP pass-through
authenticator acting as a AAA client can be detected if it attempts
to impersonate another authenticator (such by sending incorrect
NAS-Identifier [RFC2865], NAS-IP-Address [RFC2865] or
NAS-IPv6-Address [RFC3162] attributes via the AAA protocol).
However, it is possible for a pass-through authenticator acting as a
AAA client to provide correct information to the AAA server while
communicating misleading information to the EAP peer via a lower
layer protocol.

For example, it is possible for a compromised authenticator to
utilize another authenticator's Called-Station-Id or NAS-Identifier
in communicating with the EAP peer via a lower layer protocol, or for
a pass-through authenticator acting as a AAA client to provide an
incorrect peer Calling-Station-Id [RFC2865][RFC3580] to the AAA
server via the AAA protocol.

As noted in Section 7.15 of [RFC2284bis] this vulnerability can
be addressed by use of 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.

6.7 Key Scoping

A AAA-Key provided by the authentication server to the
authenticator, is for use only by that authenticator. While
AAA protocols such as RADIUS [RFC2865] or Diameter [RFC3588]
support mutual authentication between the AAA client and
server, the authentication is based on the claimed identity
of the AAA client. In the case of RADIUS, the shared secret
used for authentication is determined by the source address
of the RADIUS packet. As noted in [RFC3579] Section 4.3.7,
it is highly desirable that the source address be checked
against one or more NAS identification attributes so as to
detect and prevent impersonation attacks.

A wide variety of authenticator designs are possible,
including authenticators comprising a small or large number of virtual or
actual ports; authenticators supporting multiple
"virtual authenticators"; authenticators with multiple CPUs
utilizing symmetric multi-processing; clustered authenticators
supporting load balancing or failover, etc.

Similarly, a wide variety of peer designs are possible,
including peers supporting multiple interfaces; clustered
peers, etc.

AAA protocols merely mutually authenticate the AAA client
and server but do not distinguish between different authenticator
architectures. By default, the AAA-Key provided by the AAA server
may be used on an unrestricted basis solely by the authenticator
receiving the AAA-Key.

This may have some unexpected consequences. For example,
where a single physical authenticator can act as multiple
"virtual authenticators", unless each "virtual authenticator"
identifies itself distinctly to the AAA server, then a
AAA-Key provided by the AAA server is for use by any
of the "virtual authenticators".

This enables potential security vulnerabilities. For
example, an EAP peer could authenticate with the "guest"
"virtual authenticator" and negotiate a AAA-Key. The
peer could then attempt to use that AAA-Key to
do a fast handoff to the "Corporate Intranet"
virtual authenticator within the same physical
authenticator. If the virtual authenticators do not
identify themselves distinctly to the AAA server, then
the key cache will be shared in common and the
fast handoff attempt will be successful.

In order to address this vulnerability, authenticators
need to cache not only the AAA-Keys, but also the
associated authorizations. This ensures that an
attacker could not obtain elevated privileges even
if they could authenticate successfully to another
"virtual authenticator" hosted within the same physical
chassis.

If further protection is required, it is advisable for
the AAA server to explicitly restrict the AAA-Key
scope by including additional scope restriction
attributes within the AAA-Token. Examples of
scope restriction attributesw include:

* Virtual authenticator restrictions.
In the case of 802.11, this could
involve including a list of authorized
Called-Station-Ids or SSIDs for which the
AAA-Key is valid.

* Peer restrictions. In the case of 802.11,
this could involve including a list of
authorized Calling-Station-Ids for which
the AAA-Key is valid.

Note that in restricting the use of the AAA-Key it
is important to ensure that the EAP peer can be
made aware of the restriction so that the peer and
authenticator can behave consistently."

----------------------------------------------------------------------
Issue 15: Key Distribution Insecure
Submitter: Jesse Walker
Submitter email address: jesse.walker [at] intel.com
Date first submitted: March 2, 2002
Reference: http://www.drizzle.com/~aboba/AAA/issues3.html#Issue 294
Document: RFC2548
Comment type: T
Priority: S
Section: 2.4.2, 2.4.3
Rationale/Explanation of issue:

This issue relates to binding and scope restriction.