From: "David B. Nelson" <d.b.nelson@comcast.net>
To: "'radext mailing list'" <radiusext@ops.ietf.org>
Subject: RE: Guidelines suggested text for checklist:
Date: Tue, 16 Oct 2007 09:01:34 -0400
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/>