Subject: Why authenticate with DHCP

From: Roop Mukherjee <[email-masked]>
Date: Thu, 15 Feb 2001 11:49:02 -0500 (EST)

In the midst of all the debate over the <draft-ietf-dhc-aaa-ra-00.txt> I
did not see any mention of the nomadic user scenario: A user with an IP
device wishes to access a network away from home. He can't always rely PPP
as, well its 'point to point', and not all networks are 
(e.g. wireless). In its present form the DHCP server will not recognize
the user, so it cant even send packets to a network entity in him home
network. 

What is such a user to do ?

Do we expect his home network operator to make special arangements with
the visited network operator or do we allow a common IP level mechanism to
make these arrangements for him? If the later is preferable, this
negotiation (in form of a widely used AAA protocol) should happen before
his IP stack is configured. Given the expected growth of a variety 
of wireless data networks and nomadic users using DHCP, should this
not be motivation to incorporate some nomadic access mechanism into
DHCP? 

-- Roop
________________________________________

---

From: "Bernard D. Aboba" <[email-masked]>
Date: Thu, 15 Feb 2001 16:20:30 -0800 (GMT-0800)

Your question relates to inter-domain DHCP authentication. 

It is true that draft-ietf-dhc-authentication-16.txt does not address
this scenario. However, other drafts do address this, in different ways:

draft-hornstein-dhc-kerbauth-04.txt (via PKINIT or Kerb cross-realm)
draft-smedvinsky-dhc-kerbauth-01.txt (ditto)

There was a also a draft on DHCP authentication via PKI that handled this 
case.

---

From: "William A. Arbaugh" <[email-masked]>
Date: Thu, 15 Feb 2001 20:23:05 -0500 (EST)

At the authentication sub-working group held many moons ago, we discussed
the issues of inter-domain roaming. And unfortunately, didn't get very
far.  But, I'll try and answer your questions as best I can.

> not be motivation to incorporate some nomadic access mechanism into
I believe the current DHCP authentication draft can support this type of
situation in several ways. First, the user could get a shared secret from
the network he wants to join out-of-band. An inconvience, yes, but with
the lack of a global PKI- probably the easiest. The second approach,
unfortunately, requires a shared PKI.

With respect to wireless, either the people are going to run their
wireless network completely open- i.e. no access control and no WEP. Or,
they'll control the access in some way.  In the former, there is no
problem. DHCP works as it always has.  In the latter, some form of
out-of-band coordination is required to either get the WEP key, provide
your MAC address, and/or get the network name (SSID).  We're actually
working on these issues at Univ. of Maryland as I speak.  We've designed a
mechanism for wireless access piggy backing on DHCP authentication, as
well as  support for WEP key mangement (which is badly needed).  We have a
rough prototype finished, but we need to polish it more.  I expect we'll
submit at least two drafts on a new authentication mechanism and a new
option for WEP keys soon.

Bill

---

From: Roop Mukherjee <[email-masked]>
Date: Fri, 16 Feb 2001 15:30:22 -0500 (EST)

Thanks for the responses, Bill and Bernard D. Aboba.

My concern was not just about cross domain authentication. The scenario of
providing service to nomadic users requires the networks to not just
authenticate the user by cooperating among each other, but also involves
all the other issues associated with managing a large population of
subscribers.

The service provider networks of today after verifying the identity of 
the user may wish to provide severals levels of authorization
(e.g. filters), bill the users for usage, provide VPN support, to name a
few. The AAA protocols provide a scalable means of doing all this. The AAA
protocols are being used in the service provider networks for dial up
(PPP) users. With new types of networks that do not adhere to the
PPP scenarios DHCP may be a potential alternative. My question then is
what is needed for DHCP to be a viable alternative in commenrcial access
networks? One possibility may be to add in general mechanisms to support
AAA interactions, instead of just adding in a specific mechanism that
performs cross domain authentication using Kerberos.

-- Roop

--

---

From: John Schnizlein <[email-masked]>
Date: Fri, 16 Feb 2001 16:11:41 -0500

At 03:30 PM 02/16/2001 -0500, Roop Mukherjee wrote:
>... The AAA protocols are being used in the service provider networks 
>for dial up (PPP) users. With new types of networks that do not adhere 
>to the PPP scenarios DHCP may be a potential alternative. 

Yes, but another alternative that has gained some momentum already is
to use the same AAA protocols (RADIUS) from the network access point
that supports any of the IEEE 802 link-layer protocols. This is the
IEEE 802.1x approach.

Following this alternative, the question becomes how to coordinate
between the port-level access control of 802.1x (and its AAA), 
and DHCP. Coordination with DHCP could provide the sort of parameters
to the 802-connected host that PPP provides over dial-up lines.
Recall that AAA can interact with PPP to assign host IP addresses, etc.

>My question then is what is needed for DHCP to be a viable alternative 
>in commenrcial access networks? One possibility may be to add in 
>general mechanisms to support AAA interactions, instead of just adding 
>in a specific mechanism that performs cross domain authentication 
>using Kerberos.

Instead of adding general AAA mechanisms to DHCP, it makes sense to
coordinate these services. A standard way to coordinate these should
be the primary focus of this item in the DCHP charter.

>> option for WEP keys soon.

We agree that authorization information such as SSID and WEP key should be
provided for wireless hosts. The "out-of-band transfer" of this information
could use existing AAA protocols from the AAA server to the access point,
with the (802.1x) mechanism between the host and the access point.

John

---

From: Roop Mukherjee <[email-masked]>
Date: Fri, 16 Feb 2001 16:53:35 -0500 (EST)

The issue with the 802.1x proposal is as follows:

> Recall that AAA can interact with PPP to assign host IP addresses, etc.

The suggestion above may be the answer if all the wireless networks we
were trying to address were '802.1x' networks. For those networks that are
802.1x one may find value in trying to coordinate with the lower layers
to
interact with AAA. Also, given that the solution is specific to a link
layer, a better forum for a proposal of that kind may be, 802.11's own
security group.

But it is expected that a whole plethora of devices, with different L1/L2s 
will run IP stacks. The solution then should be based on the commonality,
not the diversity of the lower layers. Hence the suggestion that a general
mechanism in the intial configuration protocol (DHCP for the purpose of
this mailing list) may be key to using DHCP in future access networks.

-- Roop

---

From: John Schnizlein <[email-masked]>
Date: Fri, 16 Feb 2001 17:19:09 -0500

At 04:53 PM 02/16/2001 -0500, Roop Mukherjee wrote:
>...
>The suggestion above may be the answer if all the wireless networks 
>we were trying to address were '802.1x' networks. 

I know about IP over 802.11 wireless.
What other wireless network needs dynamic IP address assignment?

>...Also, given that the solution is specific to a link layer, 
>a better forum for a proposal of that kind may be, 802.11's own
>security group.

Are you suggesting that standardizing the interaction of DHCP with 
802.1x be done in the IEEE instead of in the DHCP WG?

>But it is expected that a whole plethora of devices, with different 
>L1/L2s will run IP stacks. The solution then should be based on the 
>commonality, not the diversity of the lower layers. 

PPP assigns host parmeters, including IP addresses, coordinated by AAA.
DHCP could coordinate with AAA through 802.1x. One way of doing this
is (indicated in the 802.1x annex D) AAA specifying the VLAN, which
determines the giaddr based on the subnet of the VLAN.

What other specific link layer you want to support?
Recall that assigning IP addresses must be done at least partially
at the link layer because these addresses are needed prior to the
existence of any higher-layer communication.

John

---

From: "Bernard Aboba" <[email-masked]>
Date: Sat, 17 Feb 2001 09:08:19 -0800

>that supports any of the IEEE 802 link-layer protocols. This is the

The 802.1X specification is available below:
http://www.drizzle.com/~aboba/IEEE/8021x-d10.pdf.gz

In this approach, the VLAN can be determined dynamically and
communicated to the switch via AAA. DHCP is used for configuration
and address assignment.

Assuming that a VLAN-aware network is in place, and that DHCP
servers have interfaces on the appropriate VLANs, DHCP should
continue to work as it always has. Since the 802.1X authenticator
is assumed to be a layer 2 device, only layer 2 config (such as
802.11 SSID and WEP configuration) is carried out at that layer
and AAA attributes such as  Framed-IP-Address are not used.
Since there isn't much overlap in functionality, it's possible
in many cases to avoid having to coordinate DHCP with AAA.

For details on AAA usage in 802.1X, see:

http://www.ietf.org/internet-drafts/draft-congdon-radius-8021x-10.txt

>with the (802.1x) mechanism between the host and the access point.

WEP key assignment and SSID auto-config is already supported in the WEP v2.0
specification from 802.11 Task Group E:

http://www.drizzle.com/~aboba/IEEE/1-18.zip
http://www.drizzle.com/~aboba/IEEE/baseline.ppt.gz

Next meeting of 802.11 TGe is February 23, 2001 in Seattle.