Re: FW: Review of draft-ietf-radext-status-server

[Alan DeKok <aland@deployingradius.com>]

Ignacio Goyret wrote:
> A client has *no* reliable way to find out if an incoming
> Access-Accept is for an Access-Request it sent or from an
> Status-Server sent by an attacker (with a possibly problematic
> server).

  But this attack is possible in RADIUS without Status-Server.

  We can presume that the attacker possesses at least one "known good"
user password.  (i.e. via signing up for a temporary account).  Then
this attack can be performed at will: sniff an Access-Request, and
quickly replace it with a "fake" one containing the same Id && Request
authenticator, but with the "fake" CHAP-Password and CHAP-Challenge.

  The server will respond with Access-Accept, and authorize the other
session.

> See why this is a slippery slope?

  Oh, yes.  But the problem is mostly due to un-authenticated request
packets, and less so to the use of Access-Accept.

> IMHO, people should be advised to NOT use this method of
> checking the servers.

  Hmm... even though this attack is already possible in RADIUS?

  The only defense is to require that Access-Request (and Status-Server)
packets be signed.  RFC 5080 Section 2.2.2 makes this recommendation for
Access-Requests.  This document makes the same recommendation for
Status-Server.

  We can also presume that the RADIUS client && server will be
configured by people who communicate.  i.e. the "client" is also
partially the admin, who knows that the server supports signed
Status-Server, and therefore can safely enable it on the client.

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