Subject: RE: why authenticate with DHCP?

From: "Biswaroop Mukherjee" <[email-masked]>
Date: Wed, 14 Mar 2001 10:56:32 -0500

[Roop says]  Aside from the discussion about 802 being the protocol of the
future, I am trying to understand what is it that makes the link layer a
better place for a AAA client. There seems to be some other opinion around
like BURP proposal seems to see some value in doing it at the application
level for already configured terminals. Elaboration is inline.

> -----Original Message-----
> From:	Bernard D. Aboba [SMTP:[email-masked]]
> Sent:	Friday, March 02, 2001 2:15 PM
> To:	DHCPv4 discussion list
> Cc:	DHCPv4 discussion list; Gage, Bill [WDLN2:AN00-M:EXCH];
> [email-masked]'; [email-masked]'
> Subject:	RE: why authenticate with DHCP?
> 
> > I would argue that in the wireless
> > world, there is a lot of room for innovation...we are basically just
> > starting...
> 
> 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?
> 
[Roop says]  Wireless networks are moving towards becoming all-IP above the
link layer. The push there as I understand it is to restrict the link and
physical layers to their original functions of getting the best (throughput,
loss delay etc.) out of the radio channel. Ideally you would have almost
wire like links with IP and all of its companion protocols running over
them. Independence among layers and protocols is a crucial motivation. What
this argues for is that things like spread spectrum security should be dealt
with in lower layers but don't expect the lower layers to know about
communicating keys for protocols that are several layers above and are not
related to them.

[Roop says]  It seems that the point you make below is that changing AAA is
cumbersome. Agreed: but I cannot see why the IP layer (DHCP etc.) will cause
this. All that needs to be done is to generate the AAA messages in a
language that an AAA server can presently understand and this is the
responsibility of the AAA client. This client can reside in a DHCP box or
the anywhere else according to the requirements of a given network. It will
in turn extract the user credentials (again) in a way best suited to a given
network. I do not see why putting it in link layer or higher will be an
advantage.

> > 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'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. 
> 
> > each link layer, even if it is 802 based, may interface with AAA in
> slightly
> > 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. 
> 
[Roop says]  snip..

>  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. 
> 
[Roop says]  It remains to be seen what protocol outlasts what in the
future, and should not be the basis for selecting or rejecting mechanisms
that can be of use the near term.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 15 Mar 2001 09:28:34 -0800 (PST)

> loss delay etc.) out of the radio channel. 

What you've described is purely a function of the physical layer. You
still need a MAC layer. And you still haven't described why PPP or 802
MAC won't work for you. 

> them. Independence among layers and protocols is a crucial motivation. 

MAC layers are independent of the underlying PHYs. That is how PPP and 802
were architected. So the condition is already satisfied.

> with in lower layers 

Spectrum handling is by definition a PHY issue. This shouldn't affect
upper layers at all (and doesn't in a correctly architected design). 

> but don't expect the lower layers to know about

In practice, the way this works is that the chipsets support encryption in
hardware (RC4, DES, AES), and enable keys to be loaded into the
appropriate registers via a driver interface. It would be hard to build a
chipset that wouldn't work with this architecture -- you have to have a
way of loading keys if you're going to support hardware encryption. So
while we might argue whether encryption should be a lower layer or higher
level function, layer interfaces are not a problem. 

> cumbersome. 

Actually, my point is the opposite: AAA is architected to be extensible
without code changes EXCEPT in the area of authentication where code
changes are REQUIRED. In particular, the AAA for DHCP proposals will
require MAJOR changes to the AAA architecture, because they not only
involve new authentication methods, but also require AAA knowledge of
DHCP. So those proposals are uniquely hard to implement. 

> responsibility of the AAA client. 

Yes, life is easy for the AAA client. It is the AAA server that has to go
through major contortions to support AAA for DHCP. 

> I do not see why putting it in link layer or higher will be an
> advantage.

The reason higher layer authentication has been such a huge issue for AAA
is that major new AAA functionality has been required to accomodate it. In
RFC 2869, we already put in a code extensibility architecture (EAP), but
the upper layer authentication techniques (Mobile IP, AAA for DHCP) don't
use it. As a result, these new functions require a massive AAA
re-architecture, and in fact, are the major justification for an entirely
new AAA protocol (DIAMETER). Accomodating AAA for DHCP would require yet
another major re-architecture -- because now the AAA server wouldn't only
have to understand basic network access (dialup, ADSL, 802, etc.) but also
Mobile IP, DHCP and possibly other higher level protocols down the
line. That is a very messy and ultimately unscalable architecture. 
In contrast, 802.1X was designed to fit into the existing AAA
authentication extensibility architecture from the start (EAP), so that it
will work with any RFC 2869 compliant RADIUS server out of the box. 

> that can be of use the near term. 

Certainly, if can you ignore technical and market trends and commercial
concerns, then the problem gets a lot easier. However, at some point, you
will have to convince someone (customer, manager, etc.) why they should
care.

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 15 Mar 2001 09:34:54 -0800 (PST)

> better place for a AAA client. 

AAA runs over IP, not the link layer. But AAA was designed for use in
authentication and authorizing link layers, not upper layers. This meant
that via use of a simple data model and support for a few built-in
authentication types plus an auth extensibility model (EAP), AAA can
easily accomodate a very wide variety of link layers. 

Accomodation of upper layer protocols has proved much more complex. For
example, to accomodate Mobile IP, AAA has had to do things like address
allocation, key generation and distribution, etc. It would appear that
AAA support for DHCP will require similar major changes in functionality.