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

[Jari Arkko <jari.arkko@piuha.net>]

Alan,

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

Sounds good.

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

This is OK, I think (but it is up to you if you want to add the mitigation
feature -- I think at least suggesting Message-Authenticator
for every request is a good idea, unless you can see some backwards
compatibility issues).

Jari


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