[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



At 09:35 PM 1/22/2010 +0100, Alan DeKok wrote:
>Ignacio Goyret wrote:
>> That assumes that the client was the one actually sending
>> the Status-Server. It could have been an attacker.
>> 
>> A client has very little to use to validate an incoming Access-Request
>> that was generated as a response to an Status-Server.
>
>  Hmm... OK.
>
>> IOW, a server responding to a Status-Server sent to its auth port
>> may unintentionally authenticate a bogus session.
>
>  This requires that the attacker obtain the Request Authenticator from
>the Access-Request, put it into a Status-Server, and send that to the
>server before it receives the Access-Request.
>
>  It's possible, but hard.
>
>> That's why I say that using Access-Accept as a response to
>> anything other than an Access-* is dangerous.
>
>  The use of Message-Authenticator means that the attacker won't be able
>to sign the Status-Server, meaning the server won't respond.

Which means that the client MUST trust that the server was
properly written and/or configured and will not respond to
bogus Status-Server -- even if the client never generates
them.

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

See why this is a slippery slope?

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

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