[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

FW: Discuss on draft-ietf-dhc-agentopt-radius-06.txt



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."