[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: 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.
Yes, I don't see this either. Unless this document is attempting to
modify existing RADIUS proxy behavior, a proxy will automatically forward
an Access-Request containing a User-Name attribute with an NAI as it would
any other Access-Request. So if the User-Name contains
"email@example.com" and that proxy is set up with a route to cisco.com
then it will forward the Access-Request to the indicated RADIUS server.
> [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.
Yes, I agree this appears possible.
> [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.
In fact, these attacks have already been carried out by Web servers and
have been used to compromise credentials via offline dictionary attacks.
So they are quite real.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.