[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Issue 79; digest-auth realm validation
> -----Original Message-----
> From: Beck01, Wolfgang [mailto:BeckW@t-systems.com]
> Sent: Wednesday, March 30, 2005 12:55 AM
> To: Salowey, Joe
> Cc: firstname.lastname@example.org
> Subject: AW: Issue 79; digest-auth realm validation
> > [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 email@example.com with
the word 'unsubscribe' in a single line as the message text body.