Re: RADIUS Attribute Hiding and radext-digest-auth

[Bernard Aboba <aboba@internaut.com>]

> UA A -- TLS -- Proxy1 -- TLS -- Proxy2 -- TLS -- UA B
>                  |
>                 UDP
>                  |
>               RADIUS Server
>
> Even if all Proxies use TLS for the SIP messages, the RADIUS
> part is still unencrypted and exposes usernames, SIP-Methods
> and URIs. An attacker can see whether a user is reachable or
> is being called or sends an instant message.

Thanks for the explanation -- I'd suggest this go into the security
considerations section.

My take is that the problem as stated applies to both RADIUS
authentication and accounting and is best handled by encrypting the
entire RADIUS packet, rather than individual attributes.  For example, the
User-Name attribute is not currently encrypted and for backward
compatibility reasons, we do not want to create another attribute just for
SIP.

> We could set User-Name to 'anonymous@NAI' and define some
> Encrypted-User-Name attribute which carries the real User-Name.
> Personally, I would prefer the IPSec / VPN solution, even if
> RADIUS application can not determine whether their connection
> is secure.

If the above scenario is the only one we're concerned about, then I'd
agree.  My suggestion is to address the issue in the Security
Considerations section by providing the figure you enclosed in your
message and then saying "In order to address these vulnerabilities,
IPsec protection of RADIUS can be implemented, as described in
[RFC3579], Section 4.2."

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