[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: REMINDER: Response to the review comments on draft-ietf-dhc-a gentopt-radius-06.txt
Thanks Bernard, very good!
Bert
> -----Original Message-----
> From: Bernard Aboba [mailto:aboba@internaut.com]
> Sent: vrijdag 9 juli 2004 16:52
> To: aaa-doctors@ops.ietf.org
> Subject: REMINDER: Response to the review comments on
> draft-ietf-dhc-agentopt-radius-06.txt
>
>
> Ralph Droms has posted suggested resolutions to the
> AAA-Doctors comments
> on draft-ietf-dhc-agentopt-radius-06.txt. Earlier I sent out
> a summary of
> the issues raised in the review.
>
> Please respond to this list whether the proposed resolutions are
> acceptable to you. I will collect the feedback and send it to Ralph.
>
> -- Bernard
>
> ----------------------------------------------------------------------
> Date: Wed, 23 Jun 2004 11:13:20 -0400
> From: Ralph Droms <rdroms@cisco.com>
> To: Thomas Narten <narten@us.ibm.com>
> Subject: Re: FW: Discuss on draft-ietf-dhc-agentopt-radius-06.txt
>
> Thomas (copying Bernard, as I think the aaa-doctors list is filtered),
>
> In fact, John and I have already responded to the comments from the
> aaa-doctors (see attached document). We sent this response
> to Bert about
> three weeks ago. As all of the substantive issues in the
> comments from
> the aaa-doctors have been discussed in the past and are
> answered in our
> response, there's probably no need for a discussion on the
> dhc WG mailing
> list.
>
> - Ralph
>
> At 10:51 AM 6/23/2004 -0400, Thomas Narten wrote:
> >Bernard (or some other volunteer):
> >
> >Bert is out, but I don't think this can wait.
> >
> >I think it is great that AAA doctors has been created. But we also
> >need to make it work for document authors/WGs that get feedback.
> >
> >In this case, a number of comments (some overlapping) were returned,
> >but there is frustration at the lack of clear process for resolving
> >the issues in a constructive fashion. In partcular...
> >
> >We need to get discussion going out on the DHC mailing list or some
> >other open forum.
> >
> >It is unclear whether the individual comments are supposed to be
> >anonymous or not. It is OK (if not ideal) for them to be anonymous,
> >but then we need someone who will act as a representative that will
> >deal with getting them resolved to mutual satisfaction.
> >
> >It is unclear whether the comments have been registered in ID Tracker
> >properly (I would argue that if they do not show up as "discuss"
> >comments, they are not properly recorded). In any case, they are hard
> >to find...
> >
> >So, could the AAA doctors please
> >
> >- assign a person (or persons) to act as a shepherd for dealing with
> > the issues for the document
> >
> >- can we agree to a plan for getting the technical discussion on the
> > issues moved to the DHC mailng list so we can get some sort of
> > closure?
> >
> >Thanks,
> >Thomas
>
> [BA] Here is the response to the review comments
>
> > - 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.
>
>
>