AW: Issue 79; digest-auth realm validation

["Beck01, Wolfgang" <BeckW@t-systems.com>]

Joe,

> [Joe] There is also a need to authorize the application server (radius
> client) to prevent a RADIUS client from obtaining digest hashes (HA1
> attribute) for another realm and from advertising a realm 
> that is not authorized to service.

Your issue is valid in a single case:

An HTTP-style request passes through the HTTP-style proxies
RADIUS client A (realm A) and RADIUS client B (realm B). Both
clients demand digest authentication and both clients use the
same RADIUS server as back-end.

In all other cases, the compromised RADIUS client will never
see HTTP-style requests from other realms.

An attacker gains control over client A. The attacker can
now pretend to be RADIUS client B.

If an attacker controls the RADIUS client, the worst case has already
happened. The attacker can provide service to unauthorized users.
The attacker can reject the HTTP-style request without inserting
a response-auth directive (btw RADIUS does not allow to put the
necessary attributes into Access-Reject messages). The attacker can
choose not to send a response-auth directive at all. The attacker
can replace QoP 'auth-int' with 'auth' and modify the HTTP-style
content coming from client B. So adding a paragraph like

"A RADIUS server MUST check if the RADIUS client is authorized to use
the value it has put into the Digest-Realm attribute. If the RADIUS
client is not authorized to use this realm value, the RADIUS server
sends an Access-Reject. The RADIUS server considers this client as
compromised. It notifies the operator and rejects all future requests
from this client, until some management action tells it to do so again."

would not add much security.


Joe wrote:
> I'm not sure if it makes any sense to check the SIP-AOR 
> attribute.  If the SIP-AOR attribute is not part of the 
> Digest calculation done by the server then I do not think it 
> makes sense to check it.
> 
There are many other message components in SIP that should be covered
by a digest calculation. That's why RfC3261 proposes TLS and S/MIME. 
However, there don't seem to be any SIP vendors supporting S/MIME, even
three years after RfC 3261 has been published.

Wolfgang

--
T-Systems
Next Generation IP Services and Systems
+49 6151 937 2863
Am Kavalleriesand 3
64295 Darmstadt
Germany 

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