Issue 62: Service-Type Issues

[Bernard Aboba <aboba@internaut.com>]

Issue 62: Service-Type Issues
Submitter name: David Nelson
Submitter email address: dnelson@enterasys.com
Date first submitted: August 5, 2004
Reference:
http://www.ietf.org/proceedings/04aug/slides/radextt-1/index.html
Document: Issues and Fixes
Comment type: T
Priority: S
Section: Various
Rationale/Explanation of issue:

RADIUS does not have any explicit attribute tagging as to optional or
mandatory

RFC2865 does say (text "A"):

"A RADIUS server MAY ignore Attributes with an unknown Type."
"A RADIUS client MAY ignore Attributes with an unknown Type."
"Servers not equipped to interpret the vendor-specific information sent by
a client MUST ignore it (although it may be reported). Clients which do not receive
desired vendor-specific information SHOULD make an attempt to operate
without it, although they may do so (and report they are doing so) in a degraded mode."

RFC2586 also says (text "B"):

"This Attribute indicates the type of service the user has requested,
or the type of service to be provided. It MAY be used in both
Access-Request  and Access-Accept packets. A NAS is not required to
implement all of these service types, and MUST treat unknown or
unsupported Service-Types as though an Access-Reject had been received instead."

This text applies only to the Service-Type attribute.

However, RFC2865 also says (text "C"):

"A NAS that does not implement a given service MUST NOT implement the
RADIUS attributes for that service. For example, a NAS that is unable to
offer ARAP service MUST NOT implement the RADIUS attributes for ARAP. A NAS MUST
treat a RADIUS access-accept authorizing an unavailable service as an
access-reject instead."

In this case it is more clear that the "treat as a reject" action applies
to any collection of attributes that constitute a service definition.

It is apparent, therefore, that RADIUS has a general category of optional
attributes (i.e. ones that MAY be ignored)

RADIUS also has a general category of attributes that are mandatory
(i.e. ones that MUST not be ignored)

There seems to be an internal inconsistency between the text of (A) and
the text of (B) and (C).

The text of (A) and (B) dates back to RFC2058.

The text of (C) appears in RFC2865.

It would seem that the "MAY ignore" text applies to any attributes that
the NAS does not recognize except for those defining services.

Attributes defining services are implicitly mandatory attributes.
This clarification should probably be added to a RADIUS Issues and Fixes
draft.

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