RE: Issue 79; digest-auth realm validation

["Salowey, Joe" <jsalowey@cisco.com>]

> -----Original Message-----
> From: Beck01, Wolfgang [mailto:BeckW@t-systems.com] 
> Sent: Wednesday, March 30, 2005 12:55 AM
> To: Salowey, Joe
> Cc: radiusext@ops.ietf.org
> Subject: AW: Issue 79; digest-auth realm validation
> 
> 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.
> 

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

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

[Joe] It seems that the compromised RADIUS client can pretend to be
providing service for a different realm which in turn allows it to
obtain the Digest-HA1 for users in another realm.  Both of these
exposures are different than the ones you mention. 

> "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] 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. 


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