[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: AW: AW: Digest Authentication: Security issue with https/sips
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.
Beck01, Wolfgang wrote:
Let A call B, so that A sends an INVITE request to B, assume that the
REquest-URI is sip:firstname.lastname@example.org
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:email@example.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.
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.
T-Systems International GmbH
Engineering Networks, Products & Services
Next Generation IP Services & Systems
Am Kavalleriesand 3
Tel +49 6151 937 2863
Miguel A. Garcia tel:+358-50-4804586
Nokia Research Center Helsinki, Finland
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.