RE: Issue 79; digest-auth realm validation

[Bernard Aboba <aboba@internaut.com>]

> [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
"jsalowey@cisco.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 radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>