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

[John Schnizlein <[e-mail]>]

At 02:36 AM 3/5/2002, Thomas Narten wrote:
>I'd like to better understand the need for this document and what
>problem it solves.

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.

>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

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.

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

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.

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

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.

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

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


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