eap Mailing List: Re: Issue 208: Physical Security

[Bernard Aboba (aboba]

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

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:

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

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:

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

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:

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

Section 7.7 says:

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

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