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