Subject: [eap] Issue 208: Physical Security

From: Bernard Aboba <[email-masked]>
Date: Thu, 18 Dec 2003 00:29:14 -0800 (PST)

Issue 208: Physical Security
Submitter name: Steve Bellovin
Submitter email address: [email-masked]
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."
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 18 Dec 2003 12:34:44 +0100

> (see Section 7.1 for a detailed threat model)."

s/protect against the/protect against/

[...]

> vulnerability, a method supporting mutual authentication is

I'd suggest ending this paragraph with "it is RECOMMENDED to use a method
supporting mutual authentication."

[...]

> layer indications in PPP, IEEE 802 LANs and IEEE 802.11 wireless LANs:
....

I'd suggest s/There exist/There exists/

	Henrik

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 18 Dec 2003 07:14:48 -0800 (PST)

> s/protect against the/protect against/

Sure.

> supporting mutual authentication."

OK.

> I'd suggest s/There exist/There exists/

OK.

---

From: Alper Yegin <[email-masked]>
Date: Thu, 18 Dec 2003 11:30:44 -0800

> to the document.  What if we eliminated use of the term entirely?

Does this mean that we are eliminating the concept of physical security in
the context of EAP, and tighten the requirements accordingly? I think this
is not the intention, but I hope the modified language change does not
suggest that... At the end, I should still be able to use EAP-MD5 over my
DSL networks or wired Ethernet and not violate the spec.

> as per-packet origin authentication, integrity and replay protection

...

> algorithm resistant to dictionary attack (as defined in Section 7.2)

...

> capabilities negotiation; synchronize key usage."

The current text in the above segments suggest one does not have to obey the
requirement if EAP is run over physically secured links. The new text is
removing this condition. But I don't think the situation is any different,
right? It's just that we don't have a text saying that now...

I think working out the details of what physical security means and keeping
the term in the draft is a better approach.

Alper

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 18 Dec 2003 18:58:29 -0800 (PST)

> the term in the draft is a better approach.

I believe that Steve's point (which I agree with) is that "physical
security" is a term that is very hard to define.  For example, which of
the networks below is "physically secure":

* The Ethernet network in my home, which is entirely internal and
is protected by a rather large dog who has not eaten recently because
I am working late tonite.

* The Ethernet network in my neighbor's house, which includes a tap on the
outside porch.  The neighbors are away for the weekend.

* The wireless network at work which is located in a test lab within a
Faraday cage behind a locked door.

* The wireless network in a deserted neighborhood Starbucks, which has
closed down for the night (but whose network is still up).

* The ARCNet network which was installed 15 years ago and but is still
functioning in a legacy installation in the data center, but where
the night watchman has left the door open.

In practice, the term "physically secure" is one which applies to a
particular installation and set of practices, not to a particular
networking technology, so it is difficult to use prescriptively.

In most of the changes proposed in Issue 208, the removal of the term
"physical security" does not change the meaning of the draft at all, and
so those changes seem relatively straightforward.

The changes that are somewhat trickier is where the term is used as the
basis for some guidance as to what kind of EAP methods should be deployed,
or whether EAP should be used at all.

As Erik Nordmark discussed at IETF 56,  there is a need for prescriptive
guidance in particular situations.  For example, at IETF 56, Erik
recommended that IEEE 802.11i provide EAP WG with a document stating the
requirements for EAP methods used with IEEE 802.11 security.  If we assume
that such documents will be produced, then it isn't clear to me that we
necessarily need this kind of prescriptive guidance within RFC 2284bis
itself.  One approach might be to remove the normative language.

For example, Section 7.5 says:

I think what these paragraphs are trying to say is that if you're
worried about an attacker gaining access to the link, then use an
EAP method that protects against that.  One way to get at this point
might be to say the following:

"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
can be used."

Section 7.6 says:

Again, I think the message is that if you're worried about dictionary
attacks, use an algorithm that deals with that.  One way to get at that
might be to say:

can be used."

Section 7.7 says:

In this particular paragraph, it strikes me that the issue is really
whether rogue authenticators are a concern or not.  If so, then
mutual authentication is important.  One way to get at this might be to
say:

"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.  Where this
vulnerability is a concern, a method supporting
mutual authentication can be used."

Section 7.11 says:

"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."

Instead, we might say:

"In order to address this vulnerability, lower layers providing per-packet
confidentiality, authentication, integrity and replay protection
can be used. "
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 18 Dec 2003 21:36:53 -0800 (PST)

How about this?

In Section 3.1, change:

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:

To:

In Section 5.1, change:

To:

Change Section 7 to:

In Section 7.1, change:

To:

In Section 7.1, change:

To:

In Section 7.2, delete:

In Section 7.5, change:

To:

In Section 7.6, change:

To:

In Section 7.7, change:

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.  To address this
vulnerability, a method supporting mutual authentication
can be used. "

In Section 7.11, change:

To:

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:

In Section 7.13, change:

To:

"[c] After completion of the EAP conversation, where the
lower layer supports security services such as
per-packet confidentiality, authentication, integrity and replay
protection, a secure association protocol SHOULD be run between
the peer and authenticator in order to provide mutual authentication;
guarantee liveness of transient session keys;
provide protected ciphersuite and capabilities negotiation; 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."
_______________________________________________
eap mailing list
[email-masked]
http://mail.frascone.com/mailman/listinfo/eap

---

From: Alper Yegin <[email-masked]>
Date: Fri, 19 Dec 2003 12:24:45 -0800

> networking technology, so it is difficult to use prescriptively.

I think we could define "physically secure link" as a "link that is not
accessible by unintended hosts for transmitting and receiving any data
packets". The methods (not always based on technologies) to achieve this,
and its implementations, would vary. Just like they vary for
cryptographically secure links.

Of course, as in some of your examples above, there would be inappropriate
implementations or deployments of this as well. Just like there are for
crypto. security. 

> so those changes seem relatively straightforward.

I was worried about the unintentional side effects.

> itself.  One approach might be to remove the normative language.

I agree with that. The point we need to make in RFC 2284bis is that, the
choice of EAP method has to be based on the network environment. When
per-packet authentication, encryption, etc. is required an appropriate EAP
method must be chosen. We should not have to elaborate on where "per-packet
auth., encryption" is required. That shall be dealt separately.

It might very well be the case that I'm using a supposedly physically secure
network, but I'm hiring the security guards on the cheap side who are likely
to snooze once in a while, hence I might still prefer using an EAP method
that derives keys as additional protection.

> confidentiality, authentication, integrity and replay protection

OK, these make sense to me. It'd be better if RFC 2284bis does not get into
the business of guiding people about EAP method selection.

Alper
P.S: I'll be taking off soon for vacation. I might not be able to follow up
the thread for a while..... But I think we are in agreement anyways..

---

From: Alper Yegin <[email-masked]>
Date: Fri, 19 Dec 2003 12:33:38 -0800

> How about this?

This looks good, except at couple of points below.

> traffic to be hijacked or replayed."

I'd drop the "using keys derived during EAP authentication." part. I can
rely on physical security for the binding.

> provide protected ciphersuite and capabilities negotiation; and

I think, we should either:
- change "SHOULD" to "MAY" or "can"; or
- "where the lower layer security services such as per-packet
confidentiality, authentication, integrity and replay protection will
to be enabled"

> "EAP does not support cleartext password authentication.

I don't think this is an "EAP support" issue. This is just a matter of
defining an "EAP method". Unless we explicitly forbid design of such a
method, we should remove the above statement. I don't think this is for EAP
specification to decide. [I understand why it's a bad idea to have cleartext
passwords, but the above statement is confusing the role of EAP, EAP
methods, etc.]

> This

Thanks.

Alper

---

From: "Joseph Salowey" <[email-masked]>
Date: Fri, 19 Dec 2003 13:02:20 -0800

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Alper Yegin
> Sent: Friday, December 19, 2003 12:34 PM
> To: Bernard Aboba
> Cc: [email-masked]
> Subject: Re: [eap] Issue 208: Physical Security
> 
> 
> 
> 
> > How about this?
> 
> physically 
> > secure. Otherwise it is possible for subsequent data traffic to be 
> > hijacked or replayed.
> > 
> > authentication.  Otherwise it is possible for subsequent 
> data traffic 
> > to be hijacked or replayed."
> 
> 
> I'd drop the "using keys derived during EAP authentication." 
> part. I can rely on physical security for the binding.

[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.

> 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:
> > 
> lower layer 
> > supports security services such as per-packet confidentiality, 
> > authentication, integrity and replay protection, a secure 
> association 
> > protocol SHOULD be run between the peer and authenticator 
> in order to 
> > provide mutual authentication; guarantee liveness of 
> transient session 
> > keys; provide protected ciphersuite and capabilities 
> negotiation; and
> > synchronize key usage."
> 
> confidentiality, authentication, integrity and replay 
> protection will to be enabled"
> 
> > 
> > In Section 7.14, change:
> > 
> I don't think this is an "EAP support" issue. This is just a 
> matter of defining an "EAP method". Unless we explicitly 
> forbid design of such a method, we should remove the above 
> statement. I don't think this is for EAP specification to 
> decide. [I understand why it's a bad idea to have cleartext 
> passwords, but the above statement is confusing the role of 
> EAP, EAP methods, etc.]
> 
> > This