Re: Guidelines suggested text for checklist:

[Alan DeKok <aland@deployingradius.com>]

David B. Nelson wrote:
>>       * 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".

  Suggested text (long quote for context)

   Code changes can also be required in the RADIUS server's receive
   path, due to limitations in RADIUS server policy languages, which
   typically only provide for limited operations (such as comparisons or
   arithmetic operations) on the basic data types.  Most existing RADIUS
   policy languages typically are not capable of parsing sub-elements,
   or providing sophisticated matching functionality.

   Given these limitations, the introduction of complex attributes can
   require code changes on the RADIUS server which would be unnecessary
   if basic data types had been used instead.  In addition, attribute-
   specific parsing means more complex software to develop and maintain.
   More complexity can lead to more error prone implementations, and
   inter-operatibility problems.  This issues can increase costs to
   network administrators as well as reducing reliability and
   introducing deployment barriers.  As a result, the introduction of
   new complex data types within RADIUS attribute specifications SHOULD
   be avoided.

   The exception to this recommendation is for complex types that can be
   treated as opaque data by the RADIUS server.  For example, the EAP-
   Message attribute, defined in [RFC3579] Section 3.1 contains a
   complex data type that is an EAP packet.  Since these complex types
   do not need to be parsed by the RADIUS server, the issues arising
   from policy language limitations do not arise.  Similarly, since
   attributes of these complex types can be configured on the server
   using a data type of String, dictionary limitations are also not
   encountered.  Appendix A includes a series of checklists that may be
   used to analyze a design for RECOMMENDED and NOT RECOMMENDED
   behavior.

   If the RADIUS Server simply passes the contents of an attribute to
   some non-RADIUS portion of the network, then the data is opaque, and
   SHOULD be defined to be of type "string".  A concrete way of judging
   this requirement is whether or not the attribute definition in the
   RADIUS document contains delineated fields for sub-parts of the data.
   If fields need to be delineated in RADIUS, then the data is not
   opaque, and it SHOULD be separated into individual RADIUS attributes.

   An examination of existing RADIUS RFCs discloses a number of complex
   attributes that have already been defined.  Appendix B includes a
   listing of complex attributes utilized within [RFC2865], [RFC2868],
   [RFC2869], [RFC3162], [RFC4818], and [RFC4675].  The discussion of
   these attributes includes reasons why a complex type is acceptable,
   or suggestions for how the attribute could have followed the RADIUS
   data model.

   As can be seen in Appendix B, most of the complex attributes involve
   authentication or security functionality.  Supporting this
   functionality requires code changes on both the RADIUS client and
   server, regardless of the attribute format.  As a result, in most
   cases, the use of complex attributes to represent these methods is
   acceptable, and does not create additional interoperability or
   deployment issues.

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

  Suggested text:

2.1.4.  Service definitions and RADIUS

   New specifications SHOULD avoid defining message formats for services
   inside a RADIUS document.  In addition, the service being provisioned
   SHOULD NOT be defined in a RADIUS specification.  RADIUS attributes
   are intended to

      * authenticate users
      * authorize users (i.e. service provisioning or changes to
        provisioning)
      * account for user activity (i.e. logging of session activity)

   RADIUS also SHOULD NOT be extended to new commands via attributes.
   New commands (i.e. the Code field in the packet header) are allocated
   only through "IETF Consensus" as noted in [RFC3575] Section 2.1.
   Specifications SHOULD NOT use new attributes to modify the
   interpretation of existing RADIUS commands.

   For new services using RADIUS, the service SHOULD be defined
   elsewhere, and provisioned 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.

  See long quote above.

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