Subject: RE: why authenticate with DHCP?

From: George Tsirtsis <[email-masked]>
Date: Fri, 2 Mar 2001 05:36:42 -0500

Hi all,

I have completely missed this discussion for some reason...Let me try to get
back in...I would not want to miss a party :-) I am also tempted to copy
BURP list but we are likely to hit the same people so I am refraining from
doing so...

I see that there is a certain momentum behind 802.X access control
mechanisms and I definitely think it makes some sense to try and rely on
such mechanisms given the leading role of 802 type link layers in the
Internet today.

I still find hard to come to terms, however, with the idea of preferring a
Link Layer mechanism over a network layer mechanism when this mechanism
(access control) is clearly needed across different link layers. And my
argument boils down to two things:

1. Relying on 802.X means that 802 type link layers will be able to use the
same mechanism. Moreover, we seam to imply that since 802 seams popular at
the moment, all future Link Layers should also comply with it...I think that
is dangerous and may limit the evolution of link layers and although some
will say "who needs another link layer" I would argue that in the wireless
world, there is a lot of room for innovation...we are basically just
starting...

2.  A meta argument that follows, is that of service integration. How would
a service provider deploy a AAA system that works across all its Access
Network offerings? It is clearly good that 802.X is using Radius (and I
guess in the future Diameter) for AAA, giving integration capabilities. But
each link layer, even if it is 802 based, may interface with AAA in slightly
different way...and I would argue that, based on 1. above, 802 may not
always cut it and thus break integration later on....

So, a network layer mechanism is always better or at least safer...since
that is the point of the network layer...i.e.: provide the same function
across different link layers...Since I will find hard to believe that anyone
will disagree with that, the discussion seams to be around the question of
how dominant 802 type link layers will be...

Regards
George

-----Original Message-----
From: John Schnizlein [mailto:[email-masked]]
Sent: Thursday, March 01, 2001 6:45 PM
To: DHCPv4 discussion list
Cc: Bill Gage
Subject: Re: why authenticate with DHCP?

At 11:49 AM 03/01/2001 -0500, Biswaroop Mukherjee wrote:
>
>1. ... An interface to AAA can be created at several layers. 
>... If DHCP is to be used as an alternative [to PPP], 
>we need to address the issue of _interfacing_ to AAA. 

It seems that the question should be how to best interface the AA
function, which might include (port) access control, with DHCP for
configuration that might depend on attributes of the AA.

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

Please give more details about UTRAN. A new link-layer protocol?
Does it have any access control mechanism?

>On Wed, 28 Feb 2001, Bernard Aboba wrote: 
>- 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. 
>- ...
>
>3. I agree, DHCP was not meant for access control...
>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. 

Ethernet and 802.11 are not the only cases. PPP has supported access 
control and initial configuration all along, while the 802 family
has only recently had access control through 802.1x, with configuration
still left to DHCP. Since 802.1x covers all 802 link-layer protocols,
not just ethernet, we seem to now have access-control coverage of most
(if not all) link layers that connect directly to hosts. (UTRAN?)

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

But 2. above only speculates about future link-layer protocols that 
might be created for new physical layers. It might make more sense, 
now that all the 802-family link-layer protocols - not just ethernet - 
have access control available through 802.1x (not 802.11) to expect 
similar functionality from any new link layer proposed in the future.

My impression is that a mechanism to coordinate between the AAA that
is used for link-layer access control and the configuration by DHCP,
providing the same capability that RFC 1332 provides for PPP, would
be sufficient.

John

---

From: "Bernard D. Aboba" <[email-masked]>
Date: Fri, 2 Mar 2001 11:14:39 -0800 (GMT-0800)

> same mechanism. Moreover, we seem to imply that since 802 seams popular at
> the moment, all future Link Layers should also comply with it.

Remember, IEEE 802 is not a single technology, it is a family of link 
layers with considerable diversity. And "popular at the moment" seems to 
imply that IEEE 802 technology is a passing fad, when in fact it seems 
more likely that IEEE 802  will outlast IPv4. 
 
> I would argue that in the wireless

I was just curious to understand some of the logic that is driving the 
evolution of wireless link layers. In many cases, wireless links do 
indeed use PPP or 802 framing. Are there specific reasons why these 
choices would not prove satisfactory in some cases?

> Network offerings? 

It's very important to understand the AAA extensibility model, and why 
we've had such trouble accomodating DHCP and MIP,  while extension to new 
link layers like VPN, ADSL, and 802 have been easy. 

AAA protocols support extensibility via addition of AVPs and attribute values. 
This is how RADIUS, which was created for dialup, has been able 
to be used in ADSL, VPNs, 802, etc. without any changes to the protocol. 

However, in the process, the assumption is that the AAA server does not 
actually need to add any code, only dictionary changes. This means that 
the AAA server MUST NOT be required to understand any details of the 
protocols that occur on the wire between the client and NAS. 

This critical assumption is broken if the AAA server is required to 
understand a new PDU type (such as parsing a DHCP or MIP 
registration message). This is why it is so hard for AAA to integrate 
with protocols that utilize a Message Integrity Check (MIC) that
needs to be verified by AAA. The problem is that the AAA implementation 
then needs to have a copy of the entire packet to verify the MIC -- which 
requires the AAA server to parse the packet. This breaks the AAA 
architectural model. 

> different way...

One of the major design points of AAA is to be able to handle new link 
layers with no changes to the protocol, only changes to the dictionary. 
That way these new access methods can be accomodated without code 
changes. Of the extensions, ADSL and 802 integration have been the most 
successful -- being accomplished without requiring new AVPs, only new 
attribute values. VPN integration was somewhat less successful, since 
the "tags" required were not supported well on some implementations, 
requiring dictionary code changes. But even there, no protocol changes 
were required, and no adjustment to the AAA architectural model.  

> always cut it and thus break integration later on....

As described early, the only thing that can "break integration" is 
changing the AAA architectural model, such as by requiring that it 
integrate with other protocols, thereby requiring large implementation 
changes. This is one of my issues with the DHCP/AAA integration proposal 
-- it would require the AAA server to understand DHCP, in order to be 
able to sign the authenticated DHCP packets. The alternative, which is to 
use challenge/response authentication, does not satisfy the authenticated 
DHCP security requirements since it would not integrity protect the 
packet. 

> So, a network layer mechanism is always better or at least safer...

Experience has told us that the biggest AAA integration problems actually 
occur with network-layer authentication methods that require integrity 
protection, such as authenticated DHCP and Mobile IP. Far from 
being "safe", this kind of integration has proven to take years to work 
through, changes in the fundamental AAA architecture, etc. Meanwhile, 
changes for new link layers have been relatively trivial.