RE: Guidelines suggested text for checklist:

["David B. Nelson" <dnelson@elbrysnetworks.com>]

Alan DeKok Writes...

>       * string (i.e. binary data), totalling 253 octets or less in
>         length. This includes the opaque encapsulation of data
>         structures defined outside of RADIUS.

I think it might make sense to add some text in the body of the document to
expand on the notion of "opaque encapsulation of data structures defined
outside of RADIUS".

The current text on this issue is limited to the following:

   The exception to this recommendation are attributes which can be
   treated as opaque data, such as the EAP-Message attribute, defined in
   [RFC3579] Section 3.1.

I think that EAP-Message is a good example of an "opaque encapsulation".
The format of the EAP message is completely defined elsewhere.  Even if you
consider the EAP peer as part of a RADIUS Server implementation, as a matter
of packaging, it is clearly a distinct entity from a logical perspective.

I think some of the attributes in the recent GEOPRIV document come close,
but fall short.  In those examples, the referenced format is not _exactly_
correct for encapsulation in a RADIUS attribute, so the GEOPRIV RADIUS
document defines a derivative format, based on the reference.

What should clearly be avoided is defining message formats for services
inside a RADIUS document.  RADIUS attributes are for (a) authenticating
users, (b) service provisioning and (c) accounting logging.  We want to be
careful that the service being provisioned isn't being _defined_ in a RADIUS
document.  Define it elsewhere, and provision it in RADIUS.

At one point we had come to consensus on the list about some criteria for
the use of "opaque encapsulations".  IIRC, the criteria hinged on whether
the RADIUS Server would need to take any action based on the purportedly
opaque information.  If it would, then the information didn't qualify for
treatment as an "opaque encapsulation".  If the RADIUS Server simply passed
the data to some "plug-in" module, and relied on a result from the "plug-in"
module to make a decision, then the data is opaque.  A concrete way of
judging this is whether the attribute definition in the RADIUS document
contains delineated fields for sub-parts of the data.  If fields need to be
delineated, then the data is not opaque.



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