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

[John Schnizlein <jschnizl@cisco.com>]

Glen

A few responses to your comments below:

And a question, while we have attention from a RADIUS expert:-)

Would it be possible to get a new RADIUS attribute type assigned by IANA?
Or must we find existing attributes to carry information intended for
interworking between RADIUS and DHCP?

At 12:52 AM 2/23/2002, Glen Zorn wrote:
>A couple of comments:
>
>1) the description of 802.1X authentication is not completely accurate, in
>that 802.1X only refers to RADIUS in an exemplary fashion, on purpose.  The
>term used is "authentication server", and although RADIUS usage as an
>authentication protocol is well-developed in that document, many other
>protocols could be used, including Diameter or even COPS.

Understood.
We took our cue from draft-congdon-radius-8021x-17.txt, which is in
the RFC editors queue and the best developed alternative. While we 
anticipate the need to revise this DHCP relay-agent information option,
or define a new one for Diameter, we did not want to get into it yet.

>2) the draft appears to violate RFC 2865 in that the inclusion of the
>Calling-Station-Id Attribute in Access-Accept messages is disallowed by that
>document; this doesn't seem to be a major problem, however, since it's
>difficult to see why this data needs to be returned from the RADIUS server,
>since in almost any condition it would be known to the access device.

Why is this attribute (31) disallowed (in Access-Accept) in section 5.44 of 
RFC 2865? Section 5.31 gives no justification for prohibition, instead saying:
      The codification of the range of allowed usage of this field is
      outside the scope of this specification.

It seemed useful to include it in this response so that the switch could 
simply copy the attributes in the Access-Accept into the DHCP relay-agent 
option. The reason for keeping it there is to for a binding of user-ID
with address even prior to the allocation of an IP address by DHCP.
Would this use of attribute 31 hurt anything?

>3) the usage of the Class Attribute is novel: since that Attribute was
>designed to carry information from a RADIUS authentication server to a
>RADIUS accounting server, it would behelpful if the draft described what
>data was to be included in the Class Attribute to the DHCP server.

Thank you for clarifying the intended design of the Class Attribute (25).
Is there any objection to its use as a user "Classifier"?
The intention that its value enable the DHCP server to select the pool
of IP addresses from which the client address is allocated.
It had the desirable specification that "The client MUST NOT interpret the
attribute locally." and implied freedom in that:
      The codification of the range of allowed usage of this field is
      outside the scope of this specification.

>4) Attributes containing IP addresses for the supplicant can be returned by
>a RADIUS server.  What should happen if this is the case _and_ an address is
>requested via DHCP?

We had not considered this case because Congdon, et al says this:
 3.7. Framed-IP-Address, Framed-IP-Netmask
     Since IEEE 802.1X does not provide a mechanism for IP address
     assignment, the Framed-IP-Address and Framed-IP-Netmask attributes 
     are not used by IEEE 802.1X authenticators.

If the switch had a way to assign an IP address to the host, the host
would not need an address from DHCP. The host could use that IP address
in its DHCP-discover, or simply not request a lease for the address offered
by DHCP if it preferred the address it got from the switch (from RADIUS).
DHCP can still provide such a host with other useful configuration parameters.

John


_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg