Subject: Re: why authenticate with DHCP?

From: "Biswaroop Mukherjee" <[email-masked]>
Date: Thu, 1 Mar 2001 11:49:25 -0500

> Please find my comments embedded below.
> 
> On Wed, 28 Feb 2001, Bernard Aboba wrote:
> 
> - >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.
> 
> 1. There is nothing to disagree above. An interface to AAA can be created
> at several layers. But we believe that there may be factors that may argue
> for providing an AAA interface at the DHCP level. Initial access and
> configuration in commercial service provider networks has always involved
> interfacing to the local AAA NAS. For instance the dial in user would send
> his login information to the AAA NAS through PPP. PPP here was not just
> used as a link layer(LCP), but also as an initial access configuration
> protocol(NCP) for higher layers. If DHCP is to be used as an alternative,
> (I will argue later that there is motivation for this too), we need to
> address the issue of _interfacing_ to AAA.
> 
> -
> - >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.
> 
> 2. I would not presume to know about Ethernet being as pervasive as IP.
> But I see your point that Token Ring, ATM, FDDI, ARCnet etc. are seen less
> commonly. But I do see a proliferation of different physical media and
> associated protocols (e.g., fiber and a whole bunch of wireless
> protocols). Because the link layer is closer to the physical media as
> opposed to the network layer and deals with things like framing, I
> would not discount the possibility that non-Ethernet like protocols will
> be used for these new physical layers and thus gain popularity. In fact
> the advocates of UTRAN will tell you that there is indeed an enormous
> market that is expected to use their networks and thus their
> link layer protocols.
> 
> -
> - 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.
> 
> 3. I agree, DHCP was not meant for access control. I don't even know how
> one could do the same. What I see it being useful for is as an initial
> access
> and configuration protocol for several types of access networks,
> including the non-Ethernet ones.
> 
> My point:
> In some of the emerging access networks both 802.11 and PPP may
> not be suitable points for authentication and interface to AAA, NOT
> access control. DHCP with means for interfacing to AAA presents itself as
> an alternative for the function of initial access and configuration of the
> stack, thanks to its low administrative costs and the fact that it is to
> a large extent agnostic to the lower layers.
> 
> -
> - 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?
> 
> Addressed above in 2.
> 
> -
> - 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.
> 
> As pointed above in 3, I do not see access control as a function of DHCP.
> 
> -
> - 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?
> 
> I am advocating authentication for initial access and configuration via
> DHCP. Application (service) level authentication is beyond the scope of an
> initial access and configuration protocol as is access control. As far as
> the question about IPv4/v6 support goes, the initial
> configuration protocol (like DHCPv4/v6) that is responsible for getting
> the v4/v6 stacks up and running can interface to AAA.
> 
> Cheers,
> -- Roop
> ________________________________________
> 
> 
> 
> 
>

---

From: "Bernard Aboba" <[email-masked]>
Date: Thu, 1 Mar 2001 09:53:54 -0800

Re: why authenticate with DHCP? > I agree, DHCP was not meant for access
control. I don't even know how
 > one could do the same.

 > DHCP.

Aren't these two statements in contradiction? If authenticated DHCP is
not useful for access control, how can it be used for authentication for
initial access?

I understand how it can be used for configuration, though. In fact, DHCP
can be used for configuration in any of the layer 2 schemes too, including
PPP and 802.1X.

---

From: Roop Mukherjee <[email-masked]>
Date: Thu, 1 Mar 2001 14:51:38 -0500 (EST)

Allow me to clarify.

On Thu, 1 Mar 2001, Bernard Aboba wrote:

-  > I agree, DHCP was not meant for access
- control. I don't even know how
-  > one could do the same.
-
-  > I am advocating authentication for initial access and configuration via
-  > DHCP.
-
- Aren't these two statements in contradiction? If authenticated DHCP is
- not useful for access control, how can it be used for authentication for
- initial access?

Roughly, my idea of access control is not letting un-authorized people use
the network. DHCP is used by the clients to send its first few packets to
the network and ask for configuration. With authenticated DHCP the first
few packets that ask for configuration would also present credentials that
would be used to authenticate the user before sending him configuration
information. Access control on the other hand, would involve network
access points with filters etc. that keep packets from unauthorized users
out. It is not that the initial authentication (which may be done by DHCP)
and access control are unrelated. Indeed access regulator may use the
information that a user has been authenticated and authorized for access from say
AAA agents to configure its mechanisms (e.g. set parameters for filtering).

What the first sentence says is, I cant see how an initial access protocol
that carries credentials or configuration data can perform access control
(i.e. keep rouge packets out) on its own. While the second sentence says
that a protocol that is used to request configuration can involve the requestor
presenting credentials and the resource server verifying them. For the
purpose of this WG we are interested in the later.

-- Roop