Subject: [eap] Re: security requirements

From: [email-masked] (Bernard Aboba)
Date: Fri, 24 Jan 2003 06:22:02 -0800 (PST)

> That's basically what I was suggesting -- if you're going to make it
> incompatible, then it's not EAP anymore and isn't suitable for the EAP
> RFC update, but it might work for some particular domain.

Since there are a lot of EAP clients and EAP-capable RADIUS servers
already deployed, backward compatibility is a practical necessity, not
just a nicety. Although it is worth noting that IEEE 802.1X does require
monotonically increasing Identifiers, and so as a result, most EAP-capable
RADIUS servers accomodate that requirement, regardless of what the lower
layer EAP transport is.

> It seems to me that there are other issues that need to be solved, and
> might as well be solved while the patient is on the table.  For
> instance, EAP assumes a peer-to-peer link.  PANA and 802.11 [1] have a
> common problem -- the use of multiaccess media.  (Note that both PPP
> and 802.1X are just point-to-point.)  It's not the wireless aspect
> that's really a special problem; it's the multiaccess nature that
> causes all the additional security headache.

The security issue comes in ensuring that actions resulting from
successful EAP authentication (such as opening a "controlled port")
only result in access for the authenticated peer.

In IEEE 802.1X it is assumed that there is only one peer per port, or that
if there are more, that the switch can detect this and shut down the port
or send appropriate alarms. Since the link is assumed to be point-to-point
and physically secure, EAP methods with lesser security (such as EAP MD5)
can be used, and there is no need to key a link layer ciphersuite, since
the presence of EAP authentication packets and data on the same
physically secure link is presumed to be enough to "bind" the data to the
initial authentication.

In IEEE 802.11, the ports are virtual -- formed as the result of an
association. So there can also only be one peer per "virtual port", but it
is no longer reasonable to assume physical security. As a result, the
"binding"  of the data to the identity of the peer occurs via a lower layer
ciphersuite -- one providing per-packet integrity protection,
authentication and replay protection. The key used in that ciphersuite can
either be static (PSK mode in IEEE 802.11i) or it can be dynamically
derived via the EAP method.

I'd also note that EAP can also be used in IEEE 802.11i for what is called
"pre-authentication" -- authentication that occurs prior to association
(pre-auth is also supported in IEEE 802.11-1997). In this case, there is
no valid port until *after* EAP authentication completes, so this is
completely a multiaccess scenario.

Among other things, this imposes considerably greater requirements on the
EAP method -- such as mutual authentication, key derivation, dictionary
attack resistance, etc.

> Why not define something
> that's specific to use on multiaccess networks and that can handle
> bootstrapping the security association required?

I'm curious as to your views on how an ideal protocol would differ
from EAP.

There are some obvious things that would be fixable -- such as handling of
fragmentation in the EAP layer, larger Identifier space, and addition of
a field for a CRC/checksum. I'm not sure that retransmission would
make the list.

In other words, the biggest issues tend to be the kinds of things that are
addressed by UDP and IP.

The problem of bringing up a security association over a medium which
cannot be assumed to be physically secure (e.g. the Internet) is one that
has been addressed by protocols such as IKE (running over UDP). So it's
not clear to me why an ideal protocol would have to do more than provide basic
datagram delivery services such as is provided by UDP and IP. After all,
UDP and IP don't need to do anything special to handle "multiaccess".