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

[Miguel Garcia <Miguel.An.Garcia@nokia.com>]

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