RE: Issue 101: IEEE802 RFC (WG Last Call Review) Status Recap

["Nelson, David" <dnelson@enterasys.com>]

Mauricio Sanchez writes...

> The reason that section 2.2 exists at all is because we have a strong
> desire for the capability to have an acknowledgement from the NAS, in
> particular when it was incapable or unable to apply and attribute
(from
> this document).   From a security perspective, not knowing explicitly
> whether a given policy (i.e. attribute) has been applied is
undesirable
> to say the least.

I understand that it would be desirable for the RADIUS server to have
some assurance (acknowledgement is one form of assurance) that if the
filter policy cannot be applied that service is denied.  However, the
proposed text seems to be promoting what should be a design conformance
issue to a run-time check.  I don't think that's a good idea.  If the
NAS is compliant with the RFC, it will deny service when if can't apply
the filter.  If it's not compliant with the RFC, it won't send the
Accounting-Stop, whether or not it provides some service.  Therefore the
server doesn't know whether the absence of an Accounting-Stop means that
NAS supports the RFC and has applied the filter, or doesn't support the
RFC and has done something else (such as ignoring the attribute).  After
all, RADIUS Accounting is a separate and optional protocol.  Tying
Accounting into Authorization in this way is a new architectural concept
for RADIUS, even though some implementations may have already some this
sort of thing.
 
> While I do agree that we are setting a precedent that moves away from
> the legacy RADIUS behavior, this new behavior would be just applicable
> to the attributes described in this document. Perhaps a discussion
item
> for the RADIUS issues and fixes document is to look at the role
explicit
> acknowledgement could play for all attributes.

I'm not at all comfortable with the notion of introducing new normative
RADIUS behavior in the form of an Accounting-[Start|Stop] message as an
ACK or NAK of an Access-Accept message.  Especially a NAK.  While it
might be made to serve that purpose, IMHO, that's a subtle but
substantive change to the RADIUS protocol.  Accounting Servers don't
need to be co-resident with the Authentication/Authorization servers, so
making this a MUST, breaks that independence.  I understand that some
implementations use co-resident Accounting servers to implement such
things as concurrent session limitations for a single user.  That kind
of functionality is outside the scope of RADIUS as documented in RFC
2865/66, however.

I think this is starting down a slippery slope.


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