Capability advertisement (was RE: -01 version of Chargeable User Identity)

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

> The overhead is a potential issue if we are introducing
> a precedent that might be followed by many attributes
> in the future.  The current suggestion seems to be that
> _every_ Access-Request contain this advertisement (cf once
> per NAS which might be more reflective of capability).

RFC2865 says, in part:

"An Access-Request MAY contain additional attributes as a hint to
the server, but the server is not required to honor the hint."

RFC2865 already allows a relatively large number of attributes to appear
in Access-Request messages, many of them as hints.  I haven't included a
similar listing from other RADIUS RFCs, simply for the sake of brevity.

   0-1       0-1      0        0            1   User-Name
   0-1       0        0        0            2   User-Password [Note 1]
   0-1       0        0        0            3   CHAP-Password [Note 1]
   0-1       0        0        0            4   NAS-IP-Address [Note 2]
   0-1       0        0        0            5   NAS-Port
   0-1       0-1      0        0            6   Service-Type
   0-1       0-1      0        0            7   Framed-Protocol
   0-1       0-1      0        0            8   Framed-IP-Address
   0-1       0-1      0        0            9   Framed-IP-Netmask
   0-1       0-1      0        0           12   Framed-MTU
   0-1       0-1      0        0           19   Callback-Number
   0-1       0-1      0        0-1         24   State [Note 1]
   0-1       0        0        0           30   Called-Station-Id
   0-1       0        0        0           31   Calling-Station-Id
   0-1       0        0        0           32   NAS-Identifier [Note 2]
   0+        0+       0+       0+          33   Proxy-State
   0-1       0-1      0        0           34   Login-LAT-Service
   0-1       0-1      0        0           35   Login-LAT-Node
   0-1       0-1      0        0           36   Login-LAT-Group
   0-1       0        0        0           60   CHAP-Challenge
   0-1       0        0        0           61   NAS-Port-Type
   0-1       0-1      0        0           62   Port-Limit
   0-1       0-1      0        0           63   Login-LAT-Port

Most RAIUS servers have existing mechanisms to deal with hint attributes
in Access-Request messages.  Most of these implementations have some
notion of a match list, allowing the system administrator to specify
certain hint attribute match conditions that are required for a
successful authentication or cause the application of a certain
authentication and/or authorization policy to the request.

While it might become a burden if there were often a large number of
additional hints included in Access-Request messages, the potential for
this exists, to some extent, already.  The use of hints may be the
simplest way to extend RADIUS to encompass some notion of capability
advertisement (note that I avoid the term capability negotiation).

-- Dave


--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>