Re: RADIUS Design Guidelines

["Alan DeKok" <aland@ox.org>]

"Bernard Aboba" <Bernard_Aboba@hotmail.com> wrote:
> "I have no objections to the guidelines permitting the definition of
> new attributes that re-use existing formats, however awkward.  The
> practice should be discouraged, but not forbidden."
> 
> Question:  what would you define as "existing formats"? 

  For the most part, attribute contents currently defined in the
RFC's.

> For example, the following compound attributes are described in
> RFC 2865, 2868, 2869 and 3162.   Note the similarity between
> RFC 2869 ARAP-Features and RFC 3162 Framed-IPv6-Prefix. 

  Yup.  There is existing code to deal with those attributes, so
adding more attributes of the same "format" isn't a major change to
RADIUS.

  Where those attributes require per-attribute special handling
(e.g. CHAP-Password), we should discourage new attributes of the same
format.  But even for those cases, I think most of the existing "odd"
formats are so special purpose that no one will be defining new
standards based on them.

 To iterate over the attributes you quoted:

> Section 5.3  CHAP-Password

  I think the WG will reject any attempt to define new authentication
methods based on CHAP.

> Attributes utilizing a one-octet tag field:

  Defining more tagged integers or strings will involve nothing more
than dictionary updates for most implementations.

> Section 5.5 ARAP-Features

  I don't even know if anyone is using this.  I do know many RADIUS
servers don't even support it, and the format is mostly an array of
values, which we could support through a slightly more complex data
model.

> 2.3 Framed-IPv6-Prefix

  Many implementations have IPv6 prefixes as a data type, so adding
more isn't much of a problem.

  Alan DeKok.

--
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/>