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

From: "Glen Zorn" <[email-masked]>
Date: Fri, 22 Feb 2002 21:52:49 -0800

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.

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.

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.

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?

~gwz

Glen Zorn
CTO Consulting Engineer
Security and Integrity Group
Consulting Engineering
Cisco Systems

PGP Key Fingerprint: 4F41 B93A 007D E2FC 9769  FB97 FBCF 7DA4 9A2D 1963

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

---

From: John Schnizlein <[email-masked]>
Date: Mon, 25 Feb 2002 16:37:18 -0500

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?

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

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

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

>a RADIUS server.  What should happen if this is the case _and_ an address is

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

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 26 Feb 2002 03:38:49 -0800

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

>       outside the scope of this specification.

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

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

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

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