Formats for structured attributes (was RE: RADEXT WG Last Call on "RADIUS Delegated IPv6 Prefix Attribute")

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

Emile van Bergen writes...
 
> Where there are two bits of information for one attribute, pre-RADEXT
> RADIUS has always taken the approach of simply putting them together
> into C struct-like subfields. That can hardly come as a surprise, and
> indeed, without a grouping mechanism, it's the most efficient and
> sensible approach.
> 
> As long as the compound format made sense for the actual entity
> generating or processing the attribute's contents and as long as the
> individual member values were not needed in any RADIUS policy nor
> generated dynamically by the RADIUS server proper, there's never been
a
> strong problem with such compound attributes, and I don't think there
> necessarily should be any such problem now.

I think it would be very valuable to allow the expression of compound
data elements in attribute formats that permit an extended form of data
dictionary driven RADIUS server to add new instances of these attributes
into the data dictionary.  What I advocate is a mechanism that
regularizes the on-the-wire encoding of the equivalent of C-language
structures in RADIUS attributes, such that new attributes can be added
to a data dictionary, and the sub-elements of the structure can be
described in that fashion.

> Case in point: MS-CHAP2-Response (RFC 2548); this attribute only makes
> sense as a whole and only to the actual MSCHAPv2 authenticator
endpoint;
> the values of the individual subfields are neither dynamically
generated
> at the RADIUS level nor interpreted by the server as part of executing
> any local policy.

If you implement the MS-CHAP authenticator as a "plug-in" module to the
RADIUS server, this makes some sense.
 
> If we want to deprecate ALL forms of C-structure like attributes, and
> expose all subfields as individual attributes, however grouped, then
for
> sure any new proposal for structuring needs a *thorough* assessment
> whether it can meet the challenge.

I don't want to deprecate them, per se.  I want to regularize them for
new work, as described above.  As to the need to thorough review of any
such proposal, and the desired timing of such work, I reiterate that I
think that is the single most important work item for RADEXT.  That's
why it was originally listed as one of the first milestones that WG was
supposed to deliver.  IMHO, it is lamentable that we are only now giving
this serious attention, but better late than never.

> The current Extended Attribute draft uses the DIAMETER format, and the
> only facility it has toward structured data is the 'Grouped' data
type,
> which is a *blank* container for *top level* attributes only.

Then maybe we need to discuss a more general notion of a regularized,
and extensible data model for RADIUS that easily encompasses structured
data.


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