[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[rdroms@cisco.com: Re: FW: Discuss on draft-ietf-dhc-agentopt-radius-06.txt]
Date: Mon, 21 Jun 2004 12:48:53 -0400
To: Margaret Wasserman <margaret@thingmagic.com>
From: Ralph Droms <rdroms@cisco.com>
Subject: Re: FW: Discuss on draft-ietf-dhc-agentopt-radius-06.txt
Cc: aaa-doctors@ops.ietf.org, Thomas Narten <narten@us.ibm.com>,
"Wijnen, Bert (Bert)" <bwijnen@lucent.com>, jschnizl@cisco.com
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.63
Before anyone on the aaa-doctors list writes up the summary Margaret
suggests...Bert sent a copy of the comments from the aaa-doctors list
(unsummarized) to John and me. We responded with comments on each of the
comments in a note we sent to Bert on 2004-06-04. Perhaps the easiest way
to proceed would be for the aaa-doctors to review our responses (included in
the attached document)...
- Ralph
At 12:22 PM 6/21/2004 -0400, Margaret Wasserman wrote:
>Hi AAA Doctors,
>
>Bert is on vacation, and I have not seen any response to this note...
>
>Did one of you volunteer to consolidate your comments and bring them to
>the DHCP WG?
>
>The draft-ietf-dhc-agentopt-radius document is being held until your
>issues are resolved, so we need to get some discussion started on the DHCP
>WG list about these issues and resolve them.
>
>We'd prefer not to cross-post the whole set of overlapping comments to the
>DHCP WG and the AAA Doctors list, as this might lead to a less structured
>conversation. So, it would be a big help if one of you could consolidate
>your notes into a single list of issues that need to be resolved, and take
>the token to work with the DHCP WG to resolve them. Volunteers?
>
>Thanks!
>
>Margaret
>
>
>At 1:03 AM +0200 6/10/04, Wijnen, Bert (Bert) wrote:
>>AAA doctors.
>>
>>I am holding the below DISCUSS for this document.
>>It is based on a whole set of comments from this AAA doctors team.
>>However, there is repetitive text and all that.
>>It would be best to have it all as one complete set (without duplication)
>>of issues, and then get it posted to the DHC WG mailing list as a
>>collective comment from the AAA-doctors. Pls keep Margaret copied
>>as she is shepherding the doc through the process.
>>
>>I did send the below to Ralph Droms, but probably best to post a
>>consolidated
>>statement to the DHC WG list, so we have our comments out in the open.
>>
>>I am about to leave for vacation (actually Friday) for 2.5 weeks.
>>So could one of you volunteer to do so.
>>
>>Thanks,
>>Bert
>>--------------------
>>> Discuss:
>>> Quite a set of comments and concerns from the AAA-doctors.
>>> Need to merge them into one set of DISCUSS and COMMENT statements.
>>Sorry for not having done so earlier.
>>
>>OK, here we go. Did not yet take the time to merge them. So just
>>forwarding raw comments so you have it right now. Can you let me know
>>if you need more info from me?
>>
>>- There was a review of revision 5 back in ..
>> I checkedith the reviewer of back then and aksed if the issues
>> raised against rev 5 were addressed. This is the response:
>> Yes, I did check and the comments that related to updates to
>> RFC 2865 were not addressed.
>> The AAA-doctors picked up on most of those issues (and found
>> a lot more things, too).
>> I have attached below (at the very bottom of this email),
>> the review copmments from Bernar on rev 5.
>>
>>- Comments on revision 6 (again from Bernard):
>> Draft -06 states:
>>
>> " The NAS truncates the RADIUS attributes to fit in the RADIUS
>> Attributes sub-option. For predictable behavior, the RADIUS
>> server should be configured to return few than 255 octets of
>> RADIUS attributes."
>>
>> In RADIUS, a single attribute (such as User-Name) can be 253 octets,
>> and packets may be up to 4096 octets in length. Since the draft does
>> not provide a way for the NAS to tell the RADIUS server that this
>> specification is implemented, it would seem like a RADIUS server
>> would always have to configured to return no more than 255 octets
>> of RADIUS attributes in order to function correctly.
>>
>> That's a pretty major constaint on RADIUS server implementations.
>> I'm not sure why this is necessary, since RFC 3396 enables encoding
>> of long options in DHCPv4.
>>
>> The draft also imposes other constraints on RADIUS implementations
>> using normative language. Given that it is not possible for the RADIUS
>> server to know if this specification is being implemented, the effect
>> is to update RFC 2865. This seems inappropriate to me.
>>
>>- Comments from various other AAA doctors below.
>>
>>Bert
>>
>>-----Original Message-----
>>From: Nelson, David [mailto:dnelson@enterasys.com]
>>Sent: woensdag 28 april 2004 19:59
>>To: aaa-doctors@ops.ietf.org
>>Subject: RE: Pls review/comment on:
>>draft-ietf-dhc-agentopt-radius-06.txt
>>
>>
>>
>>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
>>
>>-----Original Message-----
>>From: Greg Weber [mailto:gdweber@cisco.com]
>>Sent: donderdag 29 april 2004 3:23
>>To: bwijnen@lucent.com
>>Cc: aaa-doctors@ops.ietf.org
>>Subject: Re: Pls review/comment on:
>>draft-ietf-dhc-agentopt-radius-06.txt
>>
>>
>>
>>Some additional comments,
>>
>>The table in Section 4 lists RADIUS attributes which MAY be
>>returned by the server to the NAS, but most of these are
>>precluded from inclusion in Access-Accepts by RFC 2865 Section
>>5.44. E.g. Calling-Session-Id (attr.30) is not returned by
>>the server- it is sent to the server. If the intent is that
>>the NAS supplies these directly to the DHCP relay, that
>>conflicts with Section 5 of the draft:
>> "The RADIUS Attributes sub-option MUST only contain the
>> attributes provided in the RADIUS Access/Accept message."
>>
>>Guidance is needed on the lifetime of the authorization
>>data. DHCP is independent of 802.1x; there is no guarantee
>>that any DHCP packets will immediately (or ever) follow
>>the authentication process. How long is the NAS supposed to
>>hang on to this authorziation data hoping to insert it into
>>DHCP requests? Are the data inserted into all subsequent
>>DHCP requests- until what point?
>>
>>Guidance may be needed on how the NAS is supposed to correlate
>>DHCP requests with the previous RADIUS requests. Is this based
>>on MAC address? Does that pose a spoofing threat specific to
>>the proposed functionality which should be covered in the
>>Security Considerations section?
>>
>>Greg
>>
>>-----Original Message-----
>>From: Ashwin Palekar [mailto:ashwinp@windows.microsoft.com]
>>Sent: donderdag 29 april 2004 6:02
>>To: list,
>>Cc: bwijnen@lucent.com; Bernard Aboba
>>Subject: Comments on dhc-agentopt-radius-06.txt
>>
>>
>>I've looked at draft-ietf-dhc-agentopt-radius-06.txt.
>>
>>Here's my review:
>>
>>1. "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. "
>>
>>Comment 1: How does the RADIUS server know that the DHCP server will
>>provide the associated service?
>>
>>2. "The RADIUS server that implements this specification MUST be
>> configured to return the User-Name and Class attributes to the
>> NAS, and MAY return other attributes."
>>
>>
>> # Attribute
>> --- ---------
>> 1 User-Name (RFC 2865 [3])
>> 4 NAS-IP-Address (RFC 2865)
>> 6 Service-Type (RFC 2865)
>> 25 Class (RFC 2865)
>> 26 Vendor-Specific (RFC 2865)
>> 27 Session-Timeout (RFC 2865)
>> 30 Called-Station-Id (RFC 2865)
>> 31 Calling-Station-Id (RFC 2865)
>> 32 NAS-Identifier (RFC 2865)
>> 44 Acct-Session-Id (RFC 2866 [5])
>> 50 Acct-Multi-Session-Id (RFC 2866)
>> 87 NAS-Port-Id (RFC 2869 [6])
>> 88 Framed-Pool (RFC 2869)
>> 100 Framed-IPv6-Pool (RFC 3162 [8])
>>
>>
>>Comment 2: Newer EAP authentication protocols allow the RADIUS server to
>>authenticate multiple identities. What if the RADIUS server is
>>authenticating multiple identities user and machine? Which identity
>>should it return?
>>
>>Comment 3: The para possibly imposes a major constraint on RADIUS
>>implementations by requiring them to return User-Name attribute. Not all
>>RADIUS servers return this attribute.
>>
>>Comment 4: The para requires the DHCP relay agent to send many RADIUS
>>attributes to the DHCP server. In addition, the interoperability impact
>>is unclear if the DHCP relay does not forward certain attributes (like
>>Vendor-Specific). Instead, can't we achieve the same thing if the RADIUS
>>server returns one additional RADIUS attribute (DHCP-user-class)
>>specifically designed to be handled by DHCP relay-agents. The DHCP relay
>>agent only forwards the single attribute DHCP-user-class to the DHCP
>>server. The DHCP server can then assign configuration options based on
>>this option.
>>
>>Regards,
>>
>>Ashwin
>>
>>-----Original Message-----
>>From: Paul Funk [mailto:paul@funk.com]
>>Sent: donderdag 29 april 2004 11:29
>>To: Wijnen, Bert (Bert); aaa-doctors@ops.ietf.org
>>Subject: Re: Pls review/comment on:
>>draft-ietf-dhc-agentopt-radius-06.txt
>>
>>
>>Yet another approach would be to have a RADIUS attribute
>>that encapsulated a DHCP option. Then, the RADIUS server
>>could be configured to allow arbitrary options to be added to
>>a DHCP request. They could be vendor-specific as well.
>>
>>Paul
>>
>>----------------------
>>
>>Bert,
>>
>>I read the draft quickly, but it appears that the all the RADIUS
>>attributes are encoded into a single DHCP option. Since that
>>is limited to 255 bytes, I'm not sure how useful or reliable this
>>will be. RADIUS servers cannot be configured to limit the
>>total length of their attributes to 255 bytes and remain usable
>>for their main purpose, which is authentication and authorization.
>>
>>I'm not sure if it is legal in DHCP to repeat an option. If it is,
>>RADIUS attributes could be encoded one per option.
>>
>>An alternate approach would be to configure the RADIUS server
>>as to which attributes should be forwarded to the DHCP server.
>>There might be a new or VS attribute that would be useful in
>>some application to forward to the DHCP server, and it is always
>>more convenient to configure such things in the RADIUS server
>>rather than in the NAS. The NAS is best left to blindly do what
>>it is told rather than to make decisions like which attribute to
>>forward as a DHCP option.
>>
>>The basic problem is the sheer volume of information produced.
>>In such cases, maybe the best thing is to just to provide a method
>>of indirection, like a policy name or something. For example, to
>>configure a packet filter, you can send the name of the filter rather
>>than a list of rules. So maybe what's really required is a RADIUS
>>"DHCP-Policy" attribute, jointly configured at RADIUS server and
>>DHCP server, and the NAS simply forwards between the two.
>>
>>Paul
>>
>>---------- Forwarded message ----------
>>Date: Wed, 7 Apr 2004 09:47:51 -0700 (PDT)
>>From: Bernard Aboba <aboba@internaut.com>
>>To: Margaret Wasserman <margaret@thingmagic.com>
>>Subject: Re: Fwd: draft-ietf-dhc-agentopt-radius-05.txt
>>
>>Here's my review:
>>
>>Review of:
>>http://www.ietf.org/internet-drafts/draft-ietf-dhc-agentopt-radius-05.txt
>>
>>There should be an informative reference to the IEEE 802.1X standard:
>>
>>[IEEE-802.1X]
>> Institute of Electrical and Electronics Engineers, "Local
>> and Metropolitan Area Networks: Port-Based Network Access
>> Control", IEEE Standard 802.1X, September 2001.
>>
>>Section 1
>>
>>In Figure 1, change "Authentication confirm/deny" to
>>"Access-Accept/Reject"
>>
>>Change "RADIUS Service" to "RADIUS Server"
>>
>>" The RADIUS Attributes sub-option for the DHCP Relay Agent option
>> provides a way in which network elements can pass information
>> obtained through layer 2 authentication to a DHCP server [2]."
>>
>>Actually, the information is obtained via a RADIUS exchange, and
>>may not relate to layer 2 authentication (e.g. a VPN authentication
>>would still work). Suggest rephrasing to:
>>
>>" The RADIUS Attributes sub-option for the DHCP Relay Agent option
>> provides a way in which a NAS can pass selected attributes
>> obtained from a RADIUS server to a DHCP server [2]."
>>
>>"The NAS then supplies these
>>credentials to a RADIUS server, which either confirms or denies the
>>identity of the user of the device requesting network access. "
>>
>>Actually, the RADIUS server accepts or rejects access. This could
>>be due to failed authentication or it could be for other reasons
>>(insufficient authorization). Suggest rephrasing to:
>>
>>"The NAS then supplies these credentials to the RADIUS server,
>>which eventually sends either an Access-Accept or an Access-Reject in
>>response to an Access-Request."
>>
>>Section 2.2
>>
>>It would probably be safest to copy definitions from other
>>documents, such as from [RFC2865] Section 1:
>>
>> RADIUS Server
>> A RADIUS server is responsible for receiving user connection
>> requests, authenticating the user, and then returning all
>> configuration information necessary for the client to deliver
>> service to the user.
>>
>> Network Access Server
>> A Network Access Server (NAS) provides access to the network and
>> operates as a client of RADIUS. The client is responsible for
>> passing user information to designated RADIUS servers, and then
>> acting on the response which is returned.
>>
>> Attribute
>> A Type-Length-Value tuple encapsulating data elements as
>> defined in [RFC2865].
>>
>>Section 3
>>
>>You might say a few words about what happens if the Length of the enclosed
>>RADIUS attributes exceeds the potential length of the sub-option.
>>
>>Section 4
>>
>>" The RADIUS server that implements this specification MUST be
>> configured to return the User-Name and Class attributes to the NAS,
>> and MAY return other attributes.
>>
>> To avoid dependencies between the address allocation and other state
>> information between the RADIUS server and the DHCP server, only the
>> attributes in the table below SHOULD be included in this sub-option.
>> Because RADIUS servers rely on the directive in section 1.1 or RFC
>> 2865 that "A NAS MUST treat a RADIUS access-accept authorizing an
>> unavailable service as an access-reject instead.", 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. The following table, based on the analysis
>> in RFC 3580 [9], lists attributes that MAY be included:"
>>
>>Since there is no way for a RADIUS server to know that the NAS supports
>>this specification, I'm not sure how the directives in this paragraph
>>can be carried out. The implication here seems to be that the User-Name
>>and Class attributes are required to determine the IP configuration of the
>>host, even where the Framed-Pool or Framed-IPv6-Prefix attributes are
>>included.
>>
>>Since RFC 2865 specifies that the inclusion of the User-Name and Class
>>attributes in an Access-Accept is optional, the statement above
>>effectively implies an udpate to the attribute table in RFC 2865 Section
>>5.44.
>>
>>Also, I think the issue is not what a RADIUS server sends, but what a
>>DHCP relay encapsulates in the option or what the DHCP server
>>looks at or ignores, because the RADIUS server has no way to know
>>whether the NAS supports this specification or not.
>>
>>I'd prefer that these paragraphs be rephrased as follows:
>>
>>" The table below, based on the analysis in RFC 3580 [9], lists
>> attributes that MAY be included in the sub-option.
>> In order to avoid potential side effects that would change the
>> meaning of existing RADIUS attributes, a relay agent SHOULD only
>> encapsulate the attributes included in the table below.
>> The DHCP server MUST use the attributes that are included to provide
>> the service implied by those attributes and MUST NOT introduce
>> unintended side effects.
>>
>> Inclusion of the User-Name and Class attributes may be useful for
>> diagnostic purposes as well as to assist the DHCP server in
>> determining the appropriate configuration. However, since
>> this specification does not provide a mechanism for a RADIUS
>> server to determine whether the NAS supports this specification,
>> a RADIUS server cannot know that the User-Name and Class
>> attributes are expected.
>>
>> As indicated in [RFC2865] Section 5.44, the inclusion
>> of the User-Name and Class attributes within an Access-Accept is
>> optional. A DHCP server therefore cannot depend on these attributes
>> being present, and where they are ommitted, the DHCP server MUST
>> provide IP configuration as best it can, based on the contents of
>> the DHCP packet and the other RADIUS attributes present,
>> such as Framed-Pool and Framed-IPv6-Prefix.
>>
>> However, since inclusion of the User-Name and Class attributes
>> in an Access-Accept may be useful for other reasons (such as where
>> Identity privacy or tunneled EAP methods are supported), for
>> optimal diagnosability and interoperability, it is suggested
>> that RADIUS servers be configured to return the User-Name and
>> Class attributes in the Access-Accept whenever EAP authentication
>> is used."
>>
>>Section 5
>>
>>" The RADIUS Attributes sub-option MUST only
>> contain the attributes provided in the RADIUS Access/Accept message.
>> The DHCP relay agent MUST NOT add more than one RADIUS Attributes
>> sub-option in a message."
>>
>>This seems to imply that all the attributes are included. Suggest
>>rephrasing to:
>>
>>" The RADIUS Attributes sub-option MUST only contain a subset of
>> attributes provided in the RADIUS Access-Accept message.
>> The DHCP relay agent MUST NOT add more than one RADIUS Attributes
>> sub-option in a message."
>>
>>Section 6
>>
>>" When the DHCP server receives a message from a relay agent containing
>> a RADIUS Attributes sub-option, it extracts the contents of the
>> sub-option and uses that information in selecting configuration
>> parameters for the client. Even if the relay agent forwards other
>> RADIUS attributes from the RADIUS server, the DHCP server SHOULD
>> ignore any attributes it receives for which it cannot ensure that the
>> associated service will be provided either by the DHCP server or the
>> relay agent. If the DHCP server uses attributes not specified here,
>> it might result in side effects not anticipated in the existing
>> RADIUS specifications."
>>
>>Suggest rephrasing to:
>>
>>
>>" When the DHCP server receives a message from a relay agent containing
>> a RADIUS Attributes sub-option, it extracts the contents of the
>> sub-option and uses that information in selecting configuration
>> parameters for the client. If the relay agent forwards RADIUS
>> attributes not included in the table in Section 4, the DHCP server
>> SHOULD ignore them. If the DHCP server uses attributes not specified
>> here, this may result in side effects not anticipated in the existing
>> RADIUS specifications."
> - There was a review of revision 5 back in ..
> I checkedith the reviewer of back then and aksed if the issues
> raised against rev 5 were addressed. This is the response:
> Yes, I did check and the comments that related to updates to
> RFC 2865 were not addressed.
> The AAA-doctors picked up on most of those issues (and found
> a lot more things, too).
> I have attached below (at the very bottom of this email),
> the review copmments from Bernar on rev 5.
We addressed Bernard's comments on rev 5 in an earlier e-mail to you.
> - Comments on revision 6 (again from Bernard):
> Draft -06 states:
>
> " The NAS truncates the RADIUS attributes to fit in the RADIUS
> Attributes sub-option. For predictable behavior, the RADIUS
> server should be configured to return few than 255 octets of
> RADIUS attributes."
>
> In RADIUS, a single attribute (such as User-Name) can be 253 octets,
> and packets may be up to 4096 octets in length. Since the draft does
> not provide a way for the NAS to tell the RADIUS server that this
> specification is implemented, it would seem like a RADIUS server
> would always have to configured to return no more than 255 octets
> of RADIUS attributes in order to function correctly.
>
> That's a pretty major constaint on RADIUS server implementations.
> I'm not sure why this is necessary, since RFC 3396 enables encoding
> of long options in DHCPv4.
>
> The draft also imposes other constraints on RADIUS implementations
> using normative language. Given that it is not possible for the RADIUS
> server to know if this specification is being implemented, the effect
> is to update RFC 2865. This seems inappropriate to me.
Because the RADIUS server and NAS are in the same administrative
domain, the RADIUS server can be configured to return the appropriate
attributes to the NAS, sized to fit in the RADIUS Attributes
sub-option, and the RADIUS server can be aware of whether the NAS is
configured to use the RADIUS Attributes sub-option.
The last paragraph in section 5 of the draft is:
The relay agent SHOULD include the User-Name and Class attributes
in the RADIUS Attributes sub-option if available, and MAY include
other attributes.
which specifies how the relay agent should behave if the attributes
from the RADIUS server will not fit in the RADIUS Attributes
sub-option.
While RFC 3396 enables encoding of long options in DHCP, it does not
specify the encoding of long relay agent option sub-options.
Therefore, the RADIUS Attributes sub-option is still contrained to
carry 253 octets of data.
We don't believe the RADIUS Attributes sub-option specifies any
updates to RFC 2865, because the RADIUS server can be configured to
send the appropriate attributes.
> - Comments from various other AAA doctors below.
>
> Bert
>
> -----Original Message-----
> From: Nelson, David [mailto:dnelson@enterasys.com]
> Sent: woensdag 28 april 2004 19:59
> To: aaa-doctors@ops.ietf.org
> Subject: RE: Pls review/comment on:
> draft-ietf-dhc-agentopt-radius-06.txt
>
>
>
> Top of page 4:
>
> "...in RFC 2865, in octets b1...bN." In the corresponding figure, the
> octets are labeled as o1...oN.
Typo to be fixed...
> I concur with Bernard's comments about the attributes truncation
> issue.
We've addressed the truncation issue above.
> 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.
Because the RADIUS server, the relay agent and the DHCP server are all
presumed to be in the same administrative domain, the RADIUS server can
be configured to provide only the appropriate attributes.
> 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.
Many DHCP services make use of different pieces of information about
the DHCP client to determine the exact configuration information,
including the assigned IP address, to be returned to the client. The
intent of this sub-option is to make attributes supplied by the RADIUS
server, such as the User-Name, available to the DHCP server as part of
the information available about the DHCP client.
> 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.
We agree that modifying the RADIUS specifications would be
inappropriate and we don't believe the RADIUS Attributes sub-option
specification does so.
> 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.
The table in section 4 lists the attributes that can be used with the
RADIUS Attributes sub-option, and specifically does not include
Framed-IP-Address. Is that sufficient? Also, wouldn't
Framed-IP-Address typically not be used with 802.1X authentication?
> 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 DHCP
> 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
The summary above does reflect our intention for security model in
this specification. Yes, it involves transitive trust. It is beyond
the scope of security in DHCP to deal with the situation in which a
NAS has been compromised.
> -----Original Message-----
> From: Greg Weber [mailto:gdweber@cisco.com]
> Sent: donderdag 29 april 2004 3:23
> To: bwijnen@lucent.com
> Cc: aaa-doctors@ops.ietf.org
> Subject: Re: Pls review/comment on:
> draft-ietf-dhc-agentopt-radius-06.txt
>
>
>
> Some additional comments,
>
> The table in Section 4 lists RADIUS attributes which MAY be
> returned by the server to the NAS, but most of these are
> precluded from inclusion in Access-Accepts by RFC 2865 Section
> 5.44. E.g. Calling-Session-Id (attr.30) is not returned by
> the server- it is sent to the server. If the intent is that
> the NAS supplies these directly to the DHCP relay, that
> conflicts with Section 5 of the draft:
> "The RADIUS Attributes sub-option MUST only contain the
> attributes provided in the RADIUS Access/Accept message."
The table in section 4 was derived from the list in RFC 3580. We will
remove attributes 4, 30, 31, 32, 44, 50 and 87, which appear not to be
valid in Access-Accept messages. There is no intent for the NAS to
supply any attributes to the DHCP relay, so there is no conflict with
the text quoted from Section 5.
> Guidance is needed on the lifetime of the authorization
> data. DHCP is independent of 802.1x; there is no guarantee
> that any DHCP packets will immediately (or ever) follow
> the authentication process. How long is the NAS supposed to
> hang on to this authorziation data hoping to insert it into
> DHCP requests? Are the data inserted into all subsequent
> DHCP requests- until what point?
We assumed that the NAS would only insert the attributes received
from the RADIUS for the duration of the 802.1X session. We can
clarify if necessary. While we recognize there is no guarantee that
DHCP will be used with 802.1X, we expect that there will be many cases
in which the DHCP will be used through an 802.1X authorized port.
> Guidance may be needed on how the NAS is supposed to correlate
> DHCP requests with the previous RADIUS requests. Is this based
> on MAC address? Does that pose a spoofing threat specific to
> the proposed functionality which should be covered in the
> Security Considerations section?
>
> Greg
No guidance is needed because 802.1X enables forwarding on a single
port switch port for a single host. Any DHCP messages received on
that port then presumably were sent by the just authorized host.
> -----Original Message-----
> From: Ashwin Palekar [mailto:ashwinp@windows.microsoft.com]
> Sent: donderdag 29 april 2004 6:02
> To: list,
> Cc: bwijnen@lucent.com; Bernard Aboba
> Subject: Comments on dhc-agentopt-radius-06.txt
>
>
> I've looked at draft-ietf-dhc-agentopt-radius-06.txt.
>
> Here's my review:
>
> 1. "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. "
>
> Comment 1: How does the RADIUS server know that the DHCP server will
> provide the associated service?
The RADIUS server and the DHCP server are presumed to be in the same
administrative domain so the RADIUS server can be configured with the
knowledge of the DHCP server's behavior.
> 2. "The RADIUS server that implements this specification MUST be
> configured to return the User-Name and Class attributes to the
> NAS, and MAY return other attributes."
>
>
> # Attribute
> --- ---------
> 1 User-Name (RFC 2865 [3])
> 4 NAS-IP-Address (RFC 2865)
> 6 Service-Type (RFC 2865)
> 25 Class (RFC 2865)
> 26 Vendor-Specific (RFC 2865)
> 27 Session-Timeout (RFC 2865)
> 30 Called-Station-Id (RFC 2865)
> 31 Calling-Station-Id (RFC 2865)
> 32 NAS-Identifier (RFC 2865)
> 44 Acct-Session-Id (RFC 2866 [5])
> 50 Acct-Multi-Session-Id (RFC 2866)
> 87 NAS-Port-Id (RFC 2869 [6])
> 88 Framed-Pool (RFC 2869)
> 100 Framed-IPv6-Pool (RFC 3162 [8])
>
> Comment 2: Newer EAP authentication protocols allow the RADIUS
> server to authenticate multiple identities. What if the RADIUS
> server is authenticating multiple identities user and machine? Which
> identity should it return?
RFC number please?
> Comment 3: The para possibly imposes a major constraint on RADIUS
> implementations by requiring them to return User-Name attribute. Not
> all RADIUS servers return this attribute.
The network operator who want to use the RADIUS Attributes sub-option
would be wise to obtain a RADIUS server that can return the attributes
to be used by the DHCP server.
> Comment 4: The para requires the DHCP relay agent to send many
> RADIUS attributes to the DHCP server. In addition, the
> interoperability impact is unclear if the DHCP relay does not
> forward certain attributes (like Vendor-Specific). Instead, can't we
> achieve the same thing if the RADIUS server returns one additional
> RADIUS attribute (DHCP-user-class) specifically designed to be
> handled by DHCP relay-agents. The DHCP relay agent only forwards the
> single attribute DHCP-user-class to the DHCP server. The DHCP server
> can then assign configuration options based on this option.
Yes, the use of a new DHCP-user-class attribute would be an
alternative design. The first draft of this specification included a
specific options for the User-Name and a new User-Class attribute. We
were given wise counsel by the dhc WG to avoid the requirement of
establishing a new registry. Therefore, the current design reuses the
existing attributes for simplicity.
> Regards,
>
> Ashwin
>
> -----Original Message-----
> From: Paul Funk [mailto:paul@funk.com]
> Sent: donderdag 29 april 2004 11:29
> To: Wijnen, Bert (Bert); aaa-doctors@ops.ietf.org
> Subject: Re: Pls review/comment on:
> draft-ietf-dhc-agentopt-radius-06.txt
>
>
> Yet another approach would be to have a RADIUS attribute
> that encapsulated a DHCP option. Then, the RADIUS server
> could be configured to allow arbitrary options to be added to
> a DHCP request. They could be vendor-specific as well.
>
> Paul
This approach appears to be the beginning of a design that is not yet
compatible with the current DHCP specification. Relay agents can only
add relay agent information sub-options and cannot add arbitrary DHCP
options to a DHCP message. Why require the RADIUS server to pack, for
example, the User-Name attribute into a new DHCP option that would
require a new registry to be estalished by IANA.
> ----------------------
>
> Bert,
>
> I read the draft quickly, but it appears that the all the RADIUS
> attributes are encoded into a single DHCP option. Since that
> is limited to 255 bytes, I'm not sure how useful or reliable this
> will be. RADIUS servers cannot be configured to limit the
> total length of their attributes to 255 bytes and remain usable
> for their main purpose, which is authentication and authorization.
See above...
> I'm not sure if it is legal in DHCP to repeat an option. If it is,
> RADIUS attributes could be encoded one per option.
There is no standard for encoding long relay agent option sub-options
(the equivalent of RFC 3396 for sub-options).
> An alternate approach would be to configure the RADIUS server
> as to which attributes should be forwarded to the DHCP server.
> There might be a new or VS attribute that would be useful in
> some application to forward to the DHCP server, and it is always
> more convenient to configure such things in the RADIUS server
> rather than in the NAS. The NAS is best left to blindly do what
> it is told rather than to make decisions like which attribute to
> forward as a DHCP option.
Yes, the assumption is that the RADIUS server will have knowledge of
which requests will be forwarded to the DHCP server, and, therefore,
will be configured to send the appropriate attributes. This is not an
alternative approach but is exactly what is defined in the RADIUS
Attributes sub-option specification - the RADIUS server is configured
with the attributes to be sent and the NAS simply forwards all of the
attributes to the DHCP server.
> The basic problem is the sheer volume of information produced.
> In such cases, maybe the best thing is to just to provide a method
> of indirection, like a policy name or something. For example, to
> configure a packet filter, you can send the name of the filter rather
> than a list of rules. So maybe what's really required is a RADIUS
> "DHCP-Policy" attribute, jointly configured at RADIUS server and
> DHCP server, and the NAS simply forwards between the two.
>
> Paul
Why invent a new attribute with all of the baggage associated with
"policy" when all that's required is to let the DHCP server know the
outcome of a AAA decision? As indicated in the previous paragraph,
the volume of information is configurable at the RADIUS server and
can therefore be managed by the network administrator.