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

["Glen Zorn" <[e-mail]>]

John Schnizlein [mailto:[e-mail]] writes:

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

I don't know why not, though if this is a Cisco-proprietary thing, you might
want to make it vendor-specific...

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

That's OK, but I would think it would be better to be accurate in the
description of how .1X works, and just state that this document describes
how to do it _if_ the Authentication Server happens to be a RADIUS server...

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

Actually, I think that that sentence refers to the String field of the
attribute, not the attribute itself...

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

Generally, I believe, documents that violate RFCs don't become RFCs
themselves ;-). More to the point, though, most (if not all) RADIUS servers
are stateless, so trying to move your state on to them just wouldn't work.
The client is expected to hold its own state, not push it onto the RADIUS
server.

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

I don't have any problem w/it, I was just curious.  Bear in mind, however,
that multiple instances of the Class attribute can be sent in an
Access-Accept, so either the relay agent or DHCP server will need some way
to distinguish between them.

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

Ouch!  As one of the co-authors of that memo, I think that might be just a
little bit too anal...

>
> 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
[e-mail]
https://www1.ietf.org/mailman/listinfo/dhcwg