[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
AW: Issue 79; digest-auth realm validation
> [Joe] I agree that the case that is interesting is when the RADIUS
> server supports RADIUS clients that support different realms. I don't
> see how it is possible that a RADIUS client will never see HTTP-style
> requests from other realms, but perhaps I am missing something.
Note that Digest-Realm has nothing to do with the realm that is used
by RADIUS proxies to route a RADIUS message to the right server.
Digest-Realm is part of the challenge that is sent to the HTTP-style
client. This leads to a different attack scenario:
- the attacker sends a challenge to the HTTP-style client, using the
realm value he is interested in.
- The HTTP-style client constructs a digest response for this realm.
- The attacker obtains Digest-HA1 for the realm and impersonates the
responsible server for this realm.
>> "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."
> [Joe] I believe it helps to mitigate the exposures above. I am most
> concerned about the exposure of Digest-HA1 when the Digest-algorithm
> MD5 is used. There may be other issues, but that depends on what clients
> expect from a realm.
Note that MD5 is only allowed if you run IPsec between RADIUS client and server,
to avoid replay attacks. This does not help in your scenario, of course.
Would my text proposal resolve your issue? If not, can you propose
Next Generation IP Services and Systems
+49 6151 937 2863
Am Kavalleriesand 3
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.