[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RADIUS Attribute Hiding and radext-digest-auth

Bernard Aboba wrote:
> Wolfgang Beck wrote:
> > When authorizing sips or https connections, at least RADIUS 
> attributes 
> > revealing the identity must be encrypted. In 
> radext-digest-auth this 
> > applies to the following attributes:
> >  - User-Name
> >  - Digest-Username
> >  - Digest-URI
> >  - SIP-AOR [not yet in the draft]
> >  Digest-HA1 would profit from encryption, too.
..
> Can you summarize the reasons that each of the above 
> attributes need to be encrypted?
>
A bit of history: In SIP, proxies route message from an originating User Agent (UA)
towards the destination User Agent. Messages can be sent over UDP, TCP or TLS.
The old SIP RfC 2543 permitted the following scenario:

User Agent A -- TLS -- Proxy1 -- UDP -- Proxy2 -- TLS -- User Agent B

In 2002, a security design team came to the conclusion that such
a scenario gives the User Agents a false sense of security. As a result
the current SIP RfC 3261 is much stricter and introduced the 'sips' URI.
The 'sips' URI tells all Proxies on the way to use TLS. With RADIUS,
an example scenarion would look like this:

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.

As Avi pointed out, most operators already use some kind of VPN to
protect their RADIUS traffic. That's why I used formulations like
'encrypted or equally secure connections'.

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.

Wolfgang

--
T-Systems
Internet Platforms
+49 6151 937 2863
Am Kavalleriesand 3
64295 Darmstadt
Germany 

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