Subject: Re: why authenticate with DHCP?

From: John Schnizlein <[email-masked]>
Date: Thu, 01 Mar 2001 13:45:00 -0500

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: John Schnizlein <[email-masked]>
Date: Fri, 02 Mar 2001 08:41:18 -0500

At 05:36 AM 03/02/2001 -0500, George Tsirtsis wrote:
>... to copy BURP list but we are likely to hit the same people

BURP might have other interests than coordinating AAA with the
initial configuration of a host.

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

802.1x provides port-level access control based on Internet-Standard AAA
which is comparable to the port-level access control for PPP.
The conjecture is that these two cover most (if not all) host-connected
link layers. If there are others now existing, it would help to know them.

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

I never intended to rely exclusively on 802 link layers and 802.1x. My
suspicion is that PPP will be around for a long time. The point is that
both of these use (or will as soon as ratified ;-) the Internet-Standard
AAA server for authentication. The convergence implied in this approach
is a GOOD THING.

Now that even the 802-family of link-layers have included authenticated
port-level access control, it would be reasonable to expect new link 
layers (especially wireless ones lacking physical access control) to 
perform similar functions. There is no intention to stifle innovation.

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

If each link layer provides a mechanism for the user to authenticate
through the host and its local connection, it makes sense to pass
the identity along for use in initial host configuration.
Notice that this configuration includes the IP (layer-3) address,
without which no network or higher layer communication occurs.

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

The use of the authentication that is used in the link layer for initial 
configuration does not preclude other higher-layer authentications once 
IP connectivity is possible. Many applications will require their own 
authentication, and may or may not be integrated with AAA.

John

---

From: George Tsirtsis <[email-masked]>
Date: Sat, 3 Mar 2001 08:59:55 -0500

-----Original Message-----
From: Bernard D. Aboba
To: George Tsirtsis
Cc: DHCPv4 discussion list; [email-masked]';
[email-masked]'; [email-masked]'
Sent: 02/03/01 14:14
Subject: RE: why authenticate with DHCP?

> 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. 
 
GT> Well, yes...:-) although I did not mean that 802 may soon go away but
rather that other, non-802 technologies, may also become important in the
future.

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

GT> Is it only framing we are talking about? Wireless data is a whole new
game...There is no widely (cellular scale) deployed wireless link layer
today that can cope with data speeds of more than a few Kbits/sec in an
economic, scalable and elegant way and...I would not hold my breath for 3G
to solve this problem since these are basically voice technologies adapted
to run data, while the likes of wavelan are not bad but they are spectrally
inefficient....I argue that wireless data is likely to produce some new link
layers as we go ahead...whether 802/PPP framing is going to be good enough
for them I could not say for sure...but that is the point....

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

GT> I understand.

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. 

GT> Agreed.

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

GT> I understand and I never suggested that...did you think I did?

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. 

GT> Just to make sure we are on the same page, what I suggested for DHCP is
exactly (triggering AAA at the DHCP RA) should work exactly the same with
PPP as far as AAA is concern. DHCP does not directly talk to AAA servers (as
PPP doesn't), it just carries the elements that the AAA client needs to put
in AVP pairs and send them to the AAA server.

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

GT> I agree but all these new link layers require their own link layer
trasport of user authentication/identity between the end node and wherever
the AAA client leaves...A network layer transport would work on top of any
link layer in exactly the same way...

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

GT> Well, we do seam to have a disconnect here...As I said, I never
suggested the AAA server should understand DHCP...but I might be missing
your point about integrity protection in relation to this... I will have to
go and have a look at the DHCP auth. req. draft...as I sain before I am not
a security expert...which makes me wonder why am I in the middle of a
security discussion ;-0 :)

Regards
George