Subject: [dhcwg] draft-ietf-dhc-agentopt-radius-00.txt

From: Thomas Narten <[email-masked]>
Date: Tue, 05 Mar 2002 02:36:45 -0500

I'd like to better understand the need for this document and what
problem it solves.

The model here seems to be:

1) client authenticates itself with access device using 802.1X L2
   signalling.

2) access device happens to also be a DHCP relay agent (required).

3) as part of 802.1x, access device talks to radius server, gets back
   some radius AVPs. It caches those AVPs.

4) when client sends DHCP packets, relay agent appends the radius AVPs
   to the DHCP message via an agent options sub-option.

5) DHC server then uses the radius AVPs to figure out which address to
   give out.

What I'd like to understand better:

1) is this used to (say) assign an address from the correct VLAN? If
   so, can't this be done without using the radius AVPs? I.e., say
   with a generic agent options sub-options that identifies the vlan

2) Seems like it might be dangerous to cache the radius stuff and then
   later (how much later? hours?) include it in messages to the DHC
   server. How does the server know the information is accurate or
   relevant? Moreover, should the DHC server trust those radius AVPs
   without itself checking with the radius server? I would think not,
   in which case what is the benefit of even including that info in
   the DHCP messages, when the DHC server can presumably just get the
   info directly from the radius server itself?

3) Seems like a more general (and less radius specific) approach would
   be for the relay agent to include the information that the client
   provided, and then let the DHC server query the radius server
   itself (just like the access device does). Or, in fact, maybe it
   will query a diameter server. Why wire the RADIUS stuff into the
   DHCP protocol?

Thomas

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ralph Droms <[email-masked]>
Date: Tue, 05 Mar 2002 07:48:59 -0500

Thomas,

Your summary of the model is basically correct.  In step 5, selecting an 
address is only one possible way in which the DHCP server might use the 
RADIUS AVPs.

Other comments in line...

- Ralph

>    with a generic agent options sub-options that identifies the vlan

The RADIUS server has specific information about the entity requesting the 
IP configuration, and authenticates the identity of the requester.  This 
option obviates the need for pre-loading that information in the access 
device and leverages the RADIUS authentication.

>    relevant?

Dangerous in what way?  Presumably the access device uses 802.1X to know 
reliably the identity of the device at the other end of the wire attached 
to the port through which the DHCP messages are subsequently received.  The 
DHCP server can then assume that the AVPs have been associated with the
correct DHCP messages.  How would the information become inaccurate or 
irrelevant?

>    Moreover, should the DHC server trust those radius AVPs

The access device, RADIUS server and DHCP server are all presumed to be 
part of the same administrative domain, so that the DHCP server has a trust 
chain through the access device back to the RADIUS server.  Additionally, 
the AVPs are signed by the RADIUS server so that the DHCP server can 
confirm their authenticity.

The DHCP server cannot check directly with the RADIUS server because the 
DHCP server does not have the authentication credentials from the 
requesting device that were presented during 802.1X authentication.

>    will query a diameter server. Why wire the RADIUS stuff into the

Are you suggesting that the access device pass along the 802.1X 
authentication stuff (identity & credentials) to the DHCP server?  How is 
caching that information for subsequent inclusion in a DHCP message any 
different from caching the RADIUS AVPs?  Requiring the DHCP server to query 
the RADIUS server would impose a performance constraint and require that 
the DHCP server and the access device be configured to use the same RADIUS 
service.

Our original proposal (presented in SLC) was not RADIUS-specific.  The WG 
asked for specificity, so we revised the spec to focus on RADIUS.

---

From: John Schnizlein <[email-masked]>
Date: Tue, 05 Mar 2002 07:50:13 -0500

>I'd like to better understand the need for this document and what

This draft specifies the particular use of the already accepted relay
agent information option to convey the user's identity from a RADIUS
authentication (as used with 802.1X) to the DHC server. This enables
the DHC server to allocate parameters, including addresses, based on 
the user's identity without requiring an additional (repetitive) 
demand for credentials from the user.

>The model here seems to be:

Correct summary deleted.

>   with a generic agent options sub-options that identifies the vlan

This option is not necessary for selecting the VLAN. An 802.1X authenticator
can get a VLAN ID as a AVP from the (RADIUS) AAA and put the port in that
VLAN. The DCH server would learn the subnet from which to assign an address
through the GIADDR field.

If different address pools within the VLAN were to be used for different
users, the radius agentopt could provide the additional information about
the user's identity.

>   server. 

Could you identify a specific danger due to the 802.1X switch holding
the identity of the user associated with the port, please?

>   How does the server know the information is accurate or relevant? 

The DHC server is assumed to trust the administration of the switch
and the RADIUS server. The only way for the information to get associated
with the port is a valid user authentication because it is sent by the
AAA (RADIUS) server with an Accept message. The switch and RADIUS server
are all part of the trusted network infrastructure, not necessarily the host.

We anticipate further discussion of the security considerations in 
Minneapolis because forgery and replay of the identity in the option may
not be blocked in sufficient depth. Perimeter protection may be insufficient.

>   info directly from the radius server itself?

In most cases the host's next requirement, after enabling forwarding
through the switch port, is an IP address to enable communication beyond
the local (layer-2) link. Why add another AAA transaction by the DHC
server when the user's identity has just been authenticated at the same
access point for 802.1X?

In order to check with the RADIUS server, the DHC server would need to
provide user's credentials. But since the user in not actually involved
in this check, any use of the user's credentials would be a replay, which
some authentication methods (e.g. one-time passwords) effectively prevent.

>   will query a diameter server. Why wire the RADIUS stuff into the

As answered above, the DHC server should not (cannot where one-time
passwords are used) replay the user authentication. The DCHP traffic 
cannot pass the 802.1X switch until the original authentication is done.

If the 802.1X switch is configured to use Diameter authentication, it
would need an agentopt very similar to this one for that method. Since
we have the Congdon et. al draft specifying RADIUS back-end authentication,
we specified that.

John