eap Mailing List: RE: Issue 208: Physical Security

[Bernard Aboba (aboba]

> [Joe] I don't think this part should be removed.  You might make it
> conditional, but then we must explain when it can be relaxed.  I think
> there is some threat model in the document already that requires this.

I agree.  In looking at the Security Considerations section 7, it occurs
to me that the role of this section is really just to outline potential
threats as well as the security claims that address these threats.  Just
as the IPsec documents do not specify when ESP/AH are to be used, or even
when IKE is required for dynamic keying, it seems inappropriate to me for
RFC 2248bis to attempt to prescribe what kinds of EAP methods are
appropriate for use in each situation.

At IETF 56, Erik Nordmark talked about future documents which will provide
that kind of guidance, and requested that IEEE 802.11i provide such a
document for publication as an Informational RFC, based on the liason
letter of March 2003. I think it is worth making it clear in the
Section 7 that we are relying on those future documents and therefore do
not need to provide guidance on those requirements within RFC 2284bis.

Otherwise, it seems likely that we could become bogged down in a
never-ending applicability discussion.

Here is my proposed resolution of Issue 208, taking this into account:

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. EAP does not require
lower layers to provide security services such as
per-packet confidentiality, authentication, integrity and
replay protection. However, where these security
services are available, EAP methods supporting Key
Derivation (see Section 7.2.1) can be used to provide dynamic keying
material. This makes it possible to bind the EAP authentication
to subsequent data and protect against security threats such as
data modification, spoofing, or replay (see Section 7.1 for details)."

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. It is
desirable to provide assurance that the entities transmitting data
are the same ones that successfully completed EAP authentication.
To accomplish this, it is necessary for the lower layer to provide
per-packet integrity, authentication and replay protection and
to bind these per-packet services to the 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 a generic threat model and security terms and
describes the security claims section required in EAP method
specifications.

Since the specific threats applicable to a given environment may
differ, this section only attempts to provide a general outline
of potential threats and the corresponding EAP method security claims
mitigating those threats.

It is expected that the generic threat model and corresponding
security claims will used to define EAP method requirements for
use in specific environments. An example of such a requirements
analysis is provided in [IEEE80211iReq]."

Add as an informative reference:

"[IEEE80211iReq]
Kerry, S., "Input the IETF EAP Working Group on Methods and Key
Strength", IEEE 802.11 liason letter,
http://www.ietf.org/IESG/LIAISON/LS-ieee-80211.txt, March 2003."

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
supporting protected ciphersuite negotiation, mutual authentication
and key derivation as well as integrity and replay protection are
recommended. See Section 7.2.1 for definition of these security claims."

In Section 7.6, change:

"In order to protect against dictionary attacks, authentication
algorithms 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, authentication
methods resistant to dictionary attacks (as defined in Section 7.2.1)
are recommended."

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 vulnerable to attack by a rogue authenticator. Methods
supporting mutual authentication (as defined in Section 7.2.1)
address this vulnerability."

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:

"To protect against modification or snooping of data, it is
recommended that EAP methods supporting mutual authentication,
and key derivation (as defined by Section 7.2.1) be used, along with
a lower layers providing per-packet confidentiality, authentication,
integrity and replay protection. "

Change Section 7.12 to:

"There are 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, where lower layer
lower layer security services such as per-packet confidentiality,
authentication, integrity and replay protection will be enabled,
a secure association protocol SHOULD be run between
the peer and authenticator in order to provide mutual authentication
between the peer and authenticator; guarantee liveness of transient
session keys; provide protected ciphersuite and capabilities negotiation
for subsequent data; and synchronize key usage."

In Section 7.14, change:

" EAP does not support cleartext password authentication. This
omission is intentional. Where EAP is carried over physically
insecure lower layers, including wireless LANs [IEEE-802.11] or the
Internet, use of cleartext passwords would allow the password to be
captured by an attacker with access to the lower layer.

Since protocols encapsulating EAP, such as RADIUS [RFC3579], may not
provide confidentiality, even where the lower layer is physically
secure, EAP frames may be subsequently encapsulated for transport
over the Internet where they may be captured by an attacker."

To:

" EAP does not support cleartext password authentication. This
omission is intentional. Use of cleartext passwords would
allow the password to be captured by an attacker with access to the link.

Since protocols encapsulating EAP, such as RADIUS [RFC3579], may not
provide confidentiality, EAP frames may be subsequently encapsulated for
transport over the Internet where they may be captured by an attacker."