[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: FW: Review of draft-ietf-radext-status-server
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
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
> 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
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.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.