Re: DISCUSS and COMMENT: draft-ietf-radext-fixes

[Alan DeKok <aland@nitros9.org>]

Jari Arkko wrote:
> Discuss:
> This is an overall great document, long overdue, and I will
> move to a Yes vote once the below issues have been properly
> handled.

  Thanks.

> Section 2.2.2 states:
> 
...
> This got me thinking about the way that duplicates are
> detected and the cache entries managed. I re-read RFC 2865 and
> the draft under consideration, but I did not find clear
> guidance on this issue.  Specifically, what exactly are the
> requirements for such purging?  Do you check for validity of
> the packet before purging? Check the User-Password attribute
> which contains the message authentication?

  The packet MUST be validated.  The proposed change is:

<-
Cache entries MUST also be purged if the server receives a valid Access-
Request packet that matches a cached Access-Request packet in source
address, source port, RADIUS Identifier, and receiving socket, but
where the Request Authenticator field is different from the one in
the cached packet.  If the request contains a Message-Authenticator
attribute, the request MUST be processed as described in [RFC3580]
Section 3.2.  Packets with invalid Message-Authenticators MUST NOT
affect the cache in any way.
->

  We could probably also make a suggestion to mitigate a possible attack:

<-
However, Access-Request packets not containing a Message-Authenticator
attribute always affect the cache, even though they may be trivially
forged.  To avoid this issue, server implementations may be configured
to require the presence of a Message-Authenticator attribute in
Access-Request packets.  Requests not containing a Message-Authenticator
attribute MAY then be silently discarded.

Client implementations SHOULD include a Message-Authenticator attribute
in every Access-Request, to further help mitigate this issue.
->

  It's probably worth adding a note to the Security section:

<-
The cache mechanism described in Section 2.2.2 is vulnerable to attacks
when Access-Requests do not contain a Message-Authenticator attribute.
If the server accepts requests without a Message-Authenticator, then
RADIUS packets can be trivially forged by an attacker.  Cache entries
can then be forcibly expired, negating the utility of the cache.  This
attack can be mitigated by following the suggestions in [RFC3579]
Section 4, or by requiring the presence of Message-Authenticator, as
described in Section 2.2.2.
-->

>> In general, it is best for RADIUS clients to err on the side of
>> caution.  On receiving an Access-Accept including an attribute of
>> unknown Type, a RADIUS client SHOULD assume that it is a potential
>> service definition, and treat it as an Access-Reject.  Unknown VSAs
>> SHOULD be ignored by RADIUS clients.
> 
> This is a major change and can have significant
> negative effects to interoperability. Has this
> been discussed in the WG and have you found
> convincing arguments that taking on this rule
> will not lead to major problems?

  [RFC 2865] Section 1.1 already states:

   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.

  The WG has discussed this, and related issues a fair bit.  The problem
is that RADIUS doesn't have capability negotiations or signaling.  This
makes it very difficult for servers to know client capabilities.  There
is no real good solution.  The text was place there to warn people of
possible issues, and to suggest the safest behavior.

  Administrators are generally aware of the need to fight with
implementations to get client and server to agree on a set of attributes
that they both accept.  Given that, and the existing recommendations in
RFC 2865, I do not see this text as being a major change, or having
significant affects on interoperability.

  Note also that the recommendation is a SHOULD, not a MUST.

> Comment:
>> This suggests that the User-Name attribute may be ommitted if it is
> 
> s/ommitted/omitted/

  Fixed, thanks.

> Time To Live is called Hop Limit in IPv6, and since this is
> an IPv6 specific Section, perhaps this is the name that you
> should use.

  Thanks.

  Alan DeKok.

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