RE: Request for Review: "Issues and Fixes" changes

["David B. Nelson" <dnelson@elbrysnetworks.com>]

Alan DeKok writes...

>   The Call-Check MAY need to be tied to a previous authentication
> request.  This can be done via the State attribute being sent in an
> Access-Accept, and used in a later Access-Request with Call Check.

Can you suggest a specific use case where this may happen?   My
understanding of the use of Call-Check is that it always precedes a formal
authentication.

>    We extend this definition to say that Access-Requests which are part
>    of an ongoing authentication process MAY contain a State attribute.

So, this sentence really confuses me.  Maybe I'm taking it out of context,
but my understanding is that an Access-Request that is part of an ongoing
authentication process MUST contain a State Attribute.  This has been the
case since the State attribute was defined.  Why are we changing it to MAY?

>    Access-Request packets that contain a Service-Type attribute with
>    value Call Check (10) or Authorize Only (17) MUST contain a State
>    attribute.

I would suggest MUST for Authorize-Only and MAY for Call-Check.

>    Any Access-Request that does not contain an authentication 
>    attribute MUST contain a State attribute.  This list of 
>    authorization parameters is not exhaustive, and may be extended
>    in future specifications.

In the second sentence, did you mean "authentication" rather than
"authorization"?

As I indicated in a separate message, I think we need to include a formal
definition (e.g. by list) of those attributes we consider to be
authentication attributes.
 
>   I would simply say that the algorithms apply to any client originating
> RADIUS packets, including Disconnect-Requests.  This covers the Dynamic
> Authorization Client, without adding a dependency on RFC 3576bis.
> Suggested text:
> 
>    The following algorithms apply to any client that originates RADIUS
>    packets, including but not limited to Access-Request,
>    Accounting-Request, Disconnect-Request, and CoA-Request [RFC3576].
> 
>   This also adds an informative reference to RFC 3576.

That seems reasonable.

>   Sure.  It's RECOMMENDED.  We can simply say "... the RECOMMENDED
> retransmission algorithm below is..."
> 
> [ MRD and MRC]
> > This could have some unforeseen (and potentially adverse) impacts on
> > RADIUS accounting.  Today, some RADIUS accounting clients continue to
> > retransmit for long periods of time, intentionally, in order to improve
> > reliability.  If there is an upper bound on the number of times a sender
> > may retransmit an accounting message, then accounting messages could be
> > lost in situations where today they would be delivered.  So I think this
> > needs to be changed.
> 
>   We can add a note:
> 
>    For Accounting-Request packets, the default values for MRC, MRD,
>    and MRT SHOULD be zero.  These settings will enable a RADIUS client
>    to continue sending accounting requests to a RADIUS server until
>    the request is acknowledged.  If any of MRC, MRD, or MRT are non-
>    zero, then the accounting information could potentially be
>    discarded without being recorded.

That also seems reasonable.

> > Section 2.5
> >
> > The issue that this section is attempting to address is the 
> > seeming contradiction between [RFC2865] Section 1.1 which states:
> ...
> > and [RFC2865] Section 5 which states:
> ...
> > As I recall, the conclusion was that the advice of Section 1.1 
> > applies to known attributes, so that if a NAS receives an attribute
> > that is known and represents a service, but is not implemented, 
> > it is treated as an Access-Reject.  Whereas if the attribute is not
> > known, then it MAY be ignored.
> 
>   It's difficult to know if a new attribute defines a new server.

I think you meant "new service".  I agree.

We have previously agreed that unknown values of the Service-Type attribute
MUST be treated as an Access-Reject.  That much is clear.

We are debating whether unknown values of other attributes, or unknown
attribute types, ought to be treated similarly.  The suggestion is that a
NAS MAY choose to treat them similarly, i.e. treat unknown attribute types,
or unknown values of known attribute types as an Access-Reject based on
locally configured policy, with the default being to silently ignore them,
for backwards compatibility.  NASes MAY implement this local policy feature,
and it is RECOMMENDED for any new implementations or significant revisions.
We ought not to deprecate any existing implementations that don't have this
local policy feature, however.

> > The question was then what the behavior is for a NAS encountering
> > an unknown attribute.  Given the MAY in Section 5, behavior can 
> > only be recommended, not mandated, because of backward 
> > compatibility.

Agreed.

> > [BA] My recommendation would be to add a clarification of the 
> > meaning of Section 1.1:
> >...  On receiving an Access-Accept including an attribute of 
> > known Type for an unimplemented service, a RADIUS client MUST 
> > treat it as an Access-Reject, as directed in [RFC2865] Section
> > 1.1.
> 
>   It's difficult to know that an unknown type is for an 
> unimplemented service.  But I think I know what you mean.

We know that an unknown value of the Service-Type attribute is an
unimplemented service, by definition.

For unknown attribute types, or unknown value of known attribute types, the
discussion above applies.

> > I think what we are trying to say here is that existing 
> > implementations that ignore unknown attributes should probably 
> > not change to treating them as an Access-Reject by default, or 
> > else on upgrading the NAS, the users could see an unexpected 
> > change in behavior.

Not by default, anyway.  I think it is a good idea to add the capability of
treating unknown attribute type codes or unknown values of known attributes
as Access-Reject as an administrator manageable option.  The default is to
ignore them, for backwards compatibility and maximum interoperability with
RADIUS extensions.  The ability to treat these "unknown" attributes as
Access-Reject for maximum security should be a non-default,
administrator-selectable option.

> > In order to avoid introducing changes in default behavior, 
> > existing implementations that do not obey this recommendation 
> > should make the behavior configurable, with the legacy behavior
> > being enabled by default. A configuration flag such as "treat 
> > unknown attributes as reject" can be exposed to the system 
> > administrator.  If the flag is set to true, then Access-Accepts 
> > containing unknown attributes are treated as Access-Rejects.  If 
> > the flag is set to false, then unknown attributes in Access-
> > Accepts are be silently ignored.

Agreed.



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