My Suggestions regarding the RADIUS Design Guidelines Document

["Hannes Tschofenig" <Hannes.Tschofenig@gmx.net>]

-- I believe this mail never made it to the list (and I hope I got the right
version)

Hi all, 

I was asked what specifically has to be changed in the document in order to
address my comments. Here is a short summary: 

1) Shorten Section 2 and Section 3 considerably. I believe that readability
can be improved by shortening the text. Funny enough the right text is
already in the draft, namely in the appendix. I am proposing a new structure
at the bottom of this mail. 

2) Be precise what you mean by "basic" vs. "complex" attribute

Section 2 is quite fuzzy in it's description. I would instead re-use the
text you have in the appendix. 

Ciao
Hannes

-----------------------

2.  RADIUS Data Model

The Remote Authentication Dial In User Service (RADIUS) defined in [RFC2865]
and [RFC2866] uses elements known as attributes in order to represent
authentication, authorization and accounting data.

Unlike SNMP, first defined in [RFC1157] and [RFC1155], RADIUS does not
define a formal data definition language.  The data type of RADIUS
attributes is not transported on the wire.  Rather, the data type of a
RADIUS attribute is fixed when an attribute is defined.

To explain the implications of this early RADIUS design decision we
distinguish two types of attributes, namely 'basic' and 'complex'. Basic
attributes are those encapsulated in a [RFC2865] format RADIUS attribute, or
in a [RFC2865] format RADIUS VSA that uses one of the existing RADIUS data
types:

 * << Copy the text from Section A.1.1 in here. >> 

All other attributes are referred as complex attributes. 

When designing new RADIUS attributes a protocol designer has to ask himself
/ herself the following two questions: 

 (a) Will this attribute require code changes at the RADIUS server when sent
from the RADIUS server to the RADIUS client? Typically, data than can be
encoded using basic data types will not require code changes to a RADIUS
server. 

 (b) Will this attribute require code changes at the RADIUS server when
received by the RADIUS server?  

Note: It is assumed that code changes to the RADIUS client are always
necessary to implement the additional functionality offered by the newly
defined RADIUS attribute(s).
 
Many RADIUS server implementations utilize a data dictionary to recognize
data types and also offer a simple policy language that only provides
limited operations (such as comparisons or arithmetic operations) on these
basic data types. Many existing RADIUS policy languages typically are not
capable of parsing sub-elements, or providing sophisticated matching
functionality.

Ideally, a protocol designer might want to write a specification that does
not require code changes to most exist RADIUS servers. Sometimes, however,
code changes will be unavoidable and they lead to additional implementation
efforts, more testing overhead and additional security vulernabilities as
more lines of code lead to more potential vulnerabilities. It is RECOMMENDED
that protocol designers briefly describe their expected processing model and
in particular if they expect RADIUS server changes (for example due to the
need for the RADIUS server to analyse incoming RADIUS attributes and to
return responses based on the presence of a more sophisticated policy
language). 

>>> I wouldn't actually say too much more here in this section. I don't have
a good suggestion for placing the text about the polymorphic attributes. <<<


3. Standard vs. Vendor-specific Attribute Space

>>> discussion about standard vs. vendor-specific attribute space. 


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