Subject: Re: why authenticate with DHCP?

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 28 Feb 2001 09:16:07 -0800

>Are you assuming that all link layers will interface to AAA?

Actually, network access does not interface to AAA directly. NASes
act as gateways. So I don't think that this is a AAA question, it's
a network access question. AAA can be made to work, regardless of
the layer at which access control is enforced.

>is it necessarily the right place to do it for all networks?

I guess the answer to that depends on the ability to make a case
for new MAC layers. I gather that 3G has investigated use of PPP
or IEEE 802 framing, and concluded that this would not work. Can
you share some of the reasoning behind that?

I would note that in general, there seems to be a trend towards
decreased MAC layer diversity. Just as we are moving to an IP
Everywhere world, there is now movement towards Ethernet
everywhere. So just as IP will displace IPX, AppleTalk,
NetBEUI and SNA, so too will Ethernet displace Token Ring, ATM,
FDDI, ARCnet and SONET.

That doesn't mean that creating a new MAC is unjustified; it just
means that it's bucking a trend and needs to be thought through
carefully.

Will someone at the BURP BOF be taking about 3G MAC layers?

>What about non-802.11 networks?

I think there is some confusion about where authentication
occurs in 802.11 and other IEEE 802 technologies.

IEEE 802.1X authentication occurs above the 802.1 MAC layer, which
means that it can be used by any IEEE 802 technology, including
Ethernet (802.3), Token Ring (802.5), FDDI (ANSI), WLAN (802.11),
PAN (802.16), etc.

In IEEE 802.11b, authentication occurs below the 802.1 MAC layer.
That is, WEP v1.0 packets are not visible to a conventional
sniffer operating in promiscuous mode, although special 802.11
sniffers can get at it.

This wasn't a smart thing to do because it requires changes to
NIC and Access Point firmware in order to fix security bugs or
add a  new authentication method. The current intention is to
move the authentication function above the MAC layer in WEP v2.0.

> What about 3G networks?

I'm not familiar enough with the 3G physical and data link proposals
to give an opinion. But if 3G can honor the IEEE 802 hard and soft
invariants, then it is a candidate for use of the IEEE 802.1 MAC,
regardless of what the PHY is.

Hard invariants: Nonduplication, Sequential delivery
Soft invariants: Low delay, high bandwidth, low error rate

Note that 802.11 honors these invariants even though it operates
over the airwaves. The low error rate soft invariant (and sequential
delivery) is honored via ARQ, and could conceivably be honored by
other methods as well (e.g. FEC).

The "low delay" invariant is relative; I've seen 802.11 installations with
delay of > 200 ms that still function. "High bandwidth" was said to apply
to the initial 802.11 implementations running at 1-2 Mbps, and I've seen
applications using WAN mini-port drivers (e.g. latest Metricom cards) run
fine at 128 Kbps speeds. So "high bandwidth"  is somewhat relative too.

>Why not provide means of doing this at a higher layer, for instance DHCP?

I think that the architecture issues (layer 3/4 vs. layer 2) should be kept
separate from the implementation  issues (DHCP vs. alternative protocols).

We might decide that layer 3 or layer 4 authentication makes sense in some
cases, but that wouldn't necessarily imply DHCP as a solution. I'm not fond
of using authenticated DHCP for access control because it wasn't
developed to handle that scenario. After all, since a host can always
choose a static address, authenticated DHCP by itself can't function as
an access control mechanism. You need another mechanism, such as layer 3
filtering, in addition. See comments below relating to state requirements.

Since George has expressed frustration that I always seem to be answering
questions with more questions, I thought I'd keep up the tradition ;)

Here are the questions that you'd need to answer in order to justify
doing authentication at layer 3 or above:

1. Is there a compelling reason to invent a new MAC layer rather than just
reusing PPP and IEEE 802?

2. Are we providing port access control, machine access control or user
access control? Note that this is a separate issue from whether the
identity claimed is that of a machine, user or group.

Port access control requires the least state, since the maximum state
required is in proportion to the number of ports on the NAS.

Machine access control requires state for the maximum number of machines
that can be connected to a NAS. If the NAS supports LAN technologies, then
the number of machines can be considerably larger than the number of
ports. For example, if we need to authentication every node on a LAN
at layer 3, we could end up with thousands of nodes in the filter table;
this could impact throughput and increase cost.

The state requirements for user access control are even larger -- you could
have multiple users per machine.

Since state implies more hardware and higher cost as well as speed
penalties, low cost/high speed devices have tended to support only
port-based access control, which is the model implicitly assumed in
PPP and 802.1X.

3. If authentication is done at layer 3, how do we deal with multi-protocol
support? I am not thinking of AppleTalk, IPX, etc. so much as both IPv4 and
IPv6. Do we have an authentication per protocol, or can one authentication
be
done that applies to all protocols? If authentication is done at layer 4,
do we authenticate all applications? If so, how would this differ from
an application layer authentication framework such as SASL?

---

From: John Schnizlein <[email-masked]>
Date: Wed, 28 Feb 2001 13:40:36 -0500

>NetBEUI and SNA, so too will Ethernet displace Token Ring, ATM,

This market trend is not essential to the rest of the argument for 
the reason included below. (Not that I disagree with your observation.)