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

[Ralph Droms <[e-mail]>]

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

At 02:36 AM 3/5/2002 -0500, Thomas Narten wrote:
>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

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.


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

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

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.


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

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.


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


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