AW: AW: Digest Authentication: Security issue with https/sips

["Beck01, Wolfgang" <BeckW@t-systems.com>]

Miguel,

> Let A call B, so that A sends an INVITE request to B, assume that the 
> REquest-URI is sip:b@somedomain.com
> 
> According to the draft, A's network may want to authenticate the request 
> to make sure it comes from A and to verify that A is authorized to send 
> this SIP request.
> 
> So a SIP proxy in A's network challenges user A and the draft applies.
> 
> Now assume the same INVITE whereby A wants an encrypted end-to-end 
> secure communication. So A sends an INVITE request whose Request-URI is 
> a SIPS URI, like sips:b@somedomain.com. The only problem is that, if the 
> RADIUS interface between SIP server (at domain A) and the RADIUS 
> server (at domain A) is not secured, the request is rejected, giving the 
> user the sense that it is not possible to have a secure encrypted 
> signalling connection between A and B. This is not related to the 
> problem that the RADIUS interface is not secure at A's domain, the user 
> shouldn't be paying a penalty for this, and the A user shouldn't be 
> given the false sense that it is not possible to have end-to-end secured 
> communication at the SIP level.
RADIUS exposes parts of the request -- like username and URI -- which are
not exposed in a TLS session. If all SIP hops are encrypted with TLS and B's
domain uses locally specified security mechanims, your proxy would send username
and URI unencrypted to the RADIUS server.

If some intermediary rejects a sips call as it would have to send unencrypted
information to the RADIUS server, the client has the chance to tell the user
about this. It could display a message, like "Encryption not supported. Retry unencrypted?"

As far as I remember, the sentence about "locally specified security mechanisms"
in the callee's domain was added on request of 3GPP as IPsec is used instead of TLS.

To summarize:
Miguel's opinion: The information exposed by unencrypted RADIUS is not important
enough to justify sips call/https request rejection.
[correct me if I got it wrong]

Wolfgang's opinion: sips + unencrypted RADIUS results in partial encryption, which
is not what users expect.


Wolfgang

--
T-Systems International GmbH
Systems Integration
Technologiezentrum
Engineering Networks, Products & Services
Next Generation IP Services & Systems
Am Kavalleriesand 3
64295 Darmstadt
Tel +49 6151 937 2863







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