RE: Guidelines suggested text for checklist:

["David B. Nelson" <d.b.nelson@comcast.net>]

Alan DeKok writes...

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

Excellent!

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

This looks good to me.




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