RE: Pls review/comment on: draft-ietf-dhc-agentopt-radius-06.txt

["Nelson, David" <dnelson@enterasys.com>]

Top of page 4:

"...in RFC 2865, in octets b1...bN."  In the corresponding figure, the
octets are labeled as o1...oN.

I concur with Bernard's comments about the attributes truncation issue.

On page 4:

 " ...a RADIUS server SHOULD send only those
   attributes for which the relay agent can ensure that either the
   relay agent or the DHCP server will provide the associated
   service."

How would the RADIUS Server know?  RADIUS provides for the use of "hint"
attributes in Access-Request messages, which the RADIUS Server may use
to determine an appropriate set of atttributes for includion in an
Access-Accept message.  Does this ID anticiapte the use of hints for
conveying the capabiliites of the DHCP realy agent and/or server to the
RADIUS Server?  Otherwise, it is not clear how this "SHOULD" requirement
might be met.

Why does the DHCP Server want to see the RADIUS User-Name attribute?  Is
there an intent for the DHCP server to make AAA-like policy decisions
based on user identity? It should be mentioned that in some RADIUS use
cases, the User-Name attribute is only a "billing identity" or an
"anonymous" identity, with the acutal authenticated user identity only
available to the peers of an EAP session.

I agree with Bernard's comment that any normative text that would modify
the behavior described in the base RADIUS RFCs would seem to be
inappropriate in this document.

It seems to me that some guidance should be provided in this document,
specifically addressing the static IP address assignment attribute of
RADIUS, and the incompatibility of that attribute with DHCP.  While
static IP address assignment via RADIUS is little (not ?) used today, it
probably ought to be discusssed. 

If the DHCP Server is using the contents of the sub-option as advisory
material (i.e. "hints") as to how to provision DHCP information for the
DHCP client, then the security model as stated is probably sufficient.
This document specifies a transitive trust relationship.  The NAS and
RADIUS Server establish trust by means of a shared secret, and
optionally by use of IPsec protections.  The NAS (and therefore the DPCH
Relay Agent) and the DHCP Server establish trust by the measns
referenced in the Security Consideration section.  I haven't taken any
time to give serious consideration to whether this provides the
opportunity for any form of attack based on a compromised NAS, that
would not already be covered by the Security Considerations section of
the base RADIUS RFC(s).

-- Dave