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

"Glen Zorn" <gwz@cisco.com> Sat, 23 February 2002 05:59 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08418 for <dhcwg-archive@odin.ietf.org>; Sat, 23 Feb 2002 00:59:35 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id AAA19023 for dhcwg-archive@odin.ietf.org; Sat, 23 Feb 2002 00:59:38 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA18861; Sat, 23 Feb 2002 00:53:31 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id AAA18842 for <dhcwg@optimus.ietf.org>; Sat, 23 Feb 2002 00:53:30 -0500 (EST)
Received: from franklin.cisco.com (franklin.cisco.com [171.70.156.17]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08356 for <dhcwg@ietf.org>; Sat, 23 Feb 2002 00:53:22 -0500 (EST)
Received: from gwzpc (tokyo-vpn-client47.cisco.com [10.70.84.47]) by franklin.cisco.com (8.8.6 (PHNE_17190)/CISCO.SERVER.1.2) with SMTP id VAA08167; Fri, 22 Feb 2002 21:52:51 -0800 (PST)
Reply-To: gwz@cisco.com
From: Glen Zorn <gwz@cisco.com>
To: John Schnizlein <jschnizl@cisco.com>, rdroms@cisco.com
Cc: dhcwg@ietf.org
Date: Fri, 22 Feb 2002 21:52:49 -0800
Message-ID: <LMEEIEAEKIEGIECKAPBHGEFICEAA.gwz@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Content-Transfer-Encoding: 7bit
Subject: [dhcwg] comments on draft-ietf-dhc-agentopt-radius-00.txt
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org
Content-Transfer-Encoding: 7bit

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
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg