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

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



Wolfgang:

I sort of disagree with the conclusion. You are focusing on the fact that of whether there is TLS/Ipsec at the last mile, which is not my point of discussion.

My point of discussion is that if A calls B, I will not expect that B's network authenticates A, because typically there won't be any relationship between A and B's networks.

So if A calls B, it is only A's network that can authenticate and authorize A's call. If A uses a SIPS URI to address B, it just want to have secured signalling connection betweeen A and B, and does not care about the sortages of A's network and not protecting the RADIUS interface.

If A's proxy rejects a SIPS request because the RADIUS interface is not protected, applying the current semantics, it will give user A the idea that TLS is not supported in between proxies, or there isn't security (IPsec) at the last mile. This is not the case, so you can't hijack this type of error for this purpose. And in this case, I don't know how the lack of IPsec in RADIUS will have a negative effect in the encryption of signalling between A and B.

And then we come to the normative statements that you are placing for HTTP and SIP, I don't think it is valid for a RADIUS document to contain such statements. The WG that deal with those protocols should attack the problem and extend the protocol, if needed.

/Miguel


Beck01, Wolfgang wrote:

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







-- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland


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