[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