eap Mailing List: Issue 208: Physical Security

[Bernard Aboba (aboba]

Issue 208: Physical Security
Submitter name: Steve Bellovin
Submitter email address: smb [at] research.att.com
Date first submitted: 12/17/2003
Reference:
Document:  RFC 2284bis-07
Comment type: E
Priority: S
Section: Various
Rationale/Explanation of issue:

I'm not at all happy with the stress on "physical security" of links.
The concept isn't defined in terms of properties, nor is the threat
model clear. Many wired Ethernets, even switched ones, are not secure
enough to meet what I believe to be the requirements here.

[BA] It would appear that the term "physical security" adds little value
to the document.  What if we eliminated use of the term entirely?

The option of cryptographic "security" as an alternative is very hard
-- you can't do crypto without at least one end authenticating itself
first. When I'm sitting in my favorite 802.11 hotspot, how do I know
if I'm authenticating (at the pre-EAP level) to the hotspot or to the
laptop on the table next to me? The implications here are that the
requirements need to be spelled out much more carefully.

5.1 says that identity messages are "not protected". Again, what are
the precise security requirements for the lower layers?

[BA] It would appear that the term "not protected" is used synonymously
with "cleartext" here.

5.2: there are no numeric codes, which creates internationalization
problems.

[BA] Not sure what is meant here;  the Text-Data field uses UTF-8
encoding.

[BA] Here are the proposed fixes:

In Section 3.1, change:

" [3] Lower layer security. EAP assumes that lower layers either
provide physical security (e.g., wired PPP or IEEE 802 links) or
support per-packet authentication, integrity and replay
protection. EAP SHOULD NOT be used on physically insecure links
(e.g., wireless or the Internet) where subsequent data is not
protected by per-packet authentication, integrity and replay
protection."

To:

" [3] Lower layer security. Lower layer support for per-packet
authentication, integrity and replay protection
and confidentiality for data traffic is RECOMMENDED. Where
this is available, EAP methods supporting Key Derivation
(see Section 7.2.1) can be used to provide dynamic keying
material. This makes it possible to protect against the
security threats such as data modification and spoofing
(see Section 7.1 for a detailed threat model)."

In Section 3.4, change:

" After EAP authentication is complete, the peer will typically
transmit data to the network via the authenticator. In order to
provide assurance that the peer transmitting data is the same entity
that successfully completed EAP authentication, the lower layer needs
to bind per-packet integrity, authentication and replay protection to
the original EAP authentication, using keys derived during EAP
authentication. Alternatively, the lower layer needs to be
physically secure. Otherwise it is possible for subsequent data
traffic to be hijacked or replayed.

As a result of these considerations, EAP SHOULD be used only when
lower layers provide physical security for data (e.g., wired PPP or
IEEE 802 links), or for insecure links, where per-packet
authentication, integrity and replay protection is provided."

To:

" After EAP authentication is complete, the peer will typically
transmit data to the network via the authenticator. In order to
provide assurance that the peer transmitting data is the same entity
that successfully completed EAP authentication, the lower layer needs
to bind per-packet integrity, authentication and replay protection to
the original EAP authentication, using keys derived during EAP
authentication. Otherwise it is possible for subsequent data
traffic to be hijacked or replayed."

In Section 5.1, change:

"Identity Requests and Responses are not protected, so
from a privacy perspective it is preferable for an EAP method to
include its own protected identity exchange."

To:

"Identity Requests and Responses are sent in cleartext, so
from a privacy perspective it is preferable for an EAP method to
include an identity exchange that supports authentication,
integrity and replay protection and confidentiality."

Change Section 7 to:

"7. Security Considerations

This section defines the threat model and security terms and
describes the security claims section required in EAP method
specifications. We then discuss threat mitigation."

In Section 7.1, change:

"On physically insecure networks, it is possible for an attacker to
gain access to the physical medium. This enables a range of attacks,
including the following:"

To:

"EAP was developed for use with dialup PPP [RFC1661] and was later
adapted for use in wired IEEE 802 networks [IEEE-802] in
[IEEE-802.1X].  Subsequently EAP has been proposed for use on wireless
LAN networks, and over the Internet.  In all these situations it is
possible for an attacker to gain access to the link.  For example,
attacks on telephone infrastructure are documented in
[DECEPTION].

An attacker with access to the link may carry out a number of attacks,
including:"

In Section 7.1, change:

" Where EAP is used over wired networks, an attacker typically requires
access to the physical infrastructure in order to carry out these
attacks. However, where EAP is used over wireless networks, EAP
packets may be forwarded by authenticators (e.g., pre-authentication)
so that the attacker need not be within the coverage area of an
authenticator in order to carry out an attack on it or its peers.
Where EAP is used over the Internet, attacks may be carried out at an
even greater distance."

To:

"Depending on the lower layer, these attacks may be carried out
without requiring physical proximity. where EAP is used
over wireless networks, EAP packets may be forwarded by
authenticators (e.g., pre-authentication) so that the attacker
need not be within the coverage area of an authenticator in
order to carry out an attack on it or its peers. Where EAP is
used over the Internet, attacks may be carried out at an
even greater distance."

In Section 7.2, delete:

" [a] Intended use. This includes a statement of whether the method is
intended for use over a physically secure or insecure network, as
well as a statement of the applicable lower layers."

In Sections 5.1, 5.2, 5.3.1, 5.3.2, 5.4, 5.5, 5.6 delete the Intended Use
claim.

In Section 7.5, change:

" In the case of PPP and IEEE 802 wired links, it is assumed that such
attacks are restricted to attackers who can gain access to the
physical link. However, where EAP is run over physically insecure
lower layers such as wireless (802.11 or cellular) or the Internet
(such as within protocols supporting PPP, EAP or Ethernet Tunneling),
this assumption is no longer valid and the vulnerability to attack is
greater.

To protect EAP messages sent over physically insecure lower layers,
methods providing mutual authentication and key derivation, as well
as per-packet origin authentication, integrity and replay protection
SHOULD be used."

To:

" To protect EAP messages against modification or spoofing,
methods providing mutual authentication and key derivation, as well
as per-packet origin authentication, integrity and replay protection
SHOULD be used."

In Section 7.6, change:

" In order to protect against dictionary attacks, an authentication
algorithm resistant to dictionary attack (as defined in Section 7.2)
SHOULD be used where EAP runs over lower layers which are not physically
secure."

To:

"In order to protect against dictionary attacks, an authentication
algorithm resistant to dictionary attack (as defined in Section 7.2)
SHOULD be used."

In Section 7.7, change:

"With EAP methods supporting one-way authentication, such as EAP-MD5,
the peer does not authenticate the authenticator. Where the lower
layer is not physically secure (such as where EAP runs over wireless
media or the Internet), the peer is vulnerable to a rogue
authenticator. As a result, where the lower layer is not physically
secure, a method supporting mutual authentication is RECOMMENDED."

To:

" With EAP methods supporting one-way authentication, such as EAP-MD5,
the peer does not authenticate the authenticator, making the,
peer is vulnerable to a rogue authenticator. To address this
vulnerability, a method supporting mutual authentication is
RECOMMENDED."

In Section 7.11, change:

" As a result, as noted in Section 3.1, where EAP is used over a
physically insecure lower layer, per-packet authentication, integrity
and replay protection SHOULD be used, and per-packet confidentiality
is also recommended."

To:

" As a result, per-packet authentication, integrity
and replay protection SHOULD be provided for data traffic,
and per-packet confidentiality is RECOMMENDED."

Change Section 7.12 to:

"There exist a number of reliability and security issues with link
layer indications in PPP, IEEE 802 LANs and IEEE 802.11 wireless LANs:

[a] PPP. In PPP, link layer indications such as LCP-Terminate (a
link failure indication) and NCP (a link success indication) are
not authenticated or integrity protected. They can therefore be
spoofed by an attacker with access to the link.

[b] IEEE 802. IEEE 802.1X EAPOL-Start and EAPOL-Logoff frames
are not authenticated or integrity protected. They can therefore
be spoofed by an attacker with access to the link.

[c] IEEE 802.11. In IEEE 802.11, link layer
indications include Disassociate and Deauthenticate frames (link
failure indications), and the first message of the 4-way
handshake (link success indication). These messages are not
authenticated or integrity protected, and although they are not
forwardable, they are spoofable by an attacker within range.

In IEEE 802.11, IEEE 802.1X data frames may be sent as Class 3
unicast data frames, and are therefore forwardable. This implies
that while EAPOL-Start and EAPOL-Logoff messages may be
authenticated and integrity protected, they can be spoofed by an
authenticated attacker far from the target when
"pre-authentication" is enabled.

In IEEE 802.11 a "link down" indication is an unreliable
indication of link failure, since wireless signal strength can
come and go and may be influenced by radio frequency interference
generated by an attacker. To avoid unnecessary resets, it is
advisable to damp these indications, rather than passing them
directly to the EAP. Since EAP supports retransmission, it is
robust against transient connectivity losses."

In Section 7.13, change:

" [c] Where EAP is used over lower layers which are not physically
secure, after completion of the EAP conversation, a secure
association protocol SHOULD be run between the peer and
authenticator in order to provide mutual authentication;
guarantee liveness of the TSKs; provide protected ciphersuite and
capabilities negotiation; synchronize key usage."

To:

" [c] After completion of the EAP conversation, a secure
association protocol SHOULD be run between the peer and
authenticator in order to provide mutual authentication;
guarantee liveness of the TSKs; provide protected ciphersuite and
capabilities negotiation; synchronize key usage."