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

[Ignacio Goyret <igoyret@alcatel-lucent.com>]

At 01:22 AM 1/23/2010 +0100, Alan DeKok wrote:
>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.

Exactly. So, why are we trying to add yet another attack vector?


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

Let's agree to disagree. IMO, the use of Access-Accept for a use
*other* than what it has always been intended for is opening
a can of worms with potentially unintended consequences.

A clean, simple design would call for specialized codes,
specially considering that there is plenty of unused code
points.

However, in the Security section, it should be mentioned that
both servers and clients can be attacked independently when
either one supports Server-Status, even if the other doesn't.


>> IMHO, people should be advised to NOT use this method of
>> checking the servers.
>
>  Hmm... even though this attack is already possible in RADIUS?

Yes, because it adds a new and different attack vector.


>  The only defense is to require that Access-Request (and Status-Server)
>packets be signed.

I disagree.

A much better defense (without altering the basic RADIUS paradigm)
would be to use another code for a response, one that cannot be
confused with any possible authentication.

Since the purpose of the Status-Server is to check whether
the server is ok, then the response should be such that 
cannot ever be confused *ever* with anything else.

Barring a solution where the server response cannot be confused,
my opinion against using this method stands.


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

Think of the case where one of the two parts has to support it
because *part* of your network supports it (say some clients
or some servers), just not all of it. The choice of using an
Access-Accept response opens new doors for attacks.

It would be enough that *part* of the network can't or doesn't
know how to deal with these new sets of Access-Accept and
the admin has a serious problem. Furthermore, in many cases,
servers or clients are usually not under the same admin SOC
which makes the mixed environment very likely.


But, like I mentioned in earlier emails, this is all academic
and it doesn't really matter much because this is just an
informational RFC. It would be a very different story if
it was intended for standards track.

Take care,
-Ignacio


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