eap Mailing List: Re: Issue 208: Physical Security

[Alper Yegin (alper]

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

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. 

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

I was worried about the unintentional side effects.

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

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.

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

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