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

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

Wolfgang:

I think we need to look at a particular scenario, you emphasis on the >>>secure<<< communications is done on the wrong side of the call (on the callee's side), but RADIUS will be used in the other side, in the originating side.

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.

Do you see the scenario I am thinking?

/Miguel


Beck01, Wolfgang wrote:

Miguel,


First, I don't like the idea that a RADIUS draft (soon to be RFC) puts a normative statement to non-RADIUS protocols, namely
HTTP(RFC 2616/17) and SIP (RFC 3261). I am referring to the sentence
that reads
"... the RADIUS client MUST NOT accept secured connections (like https or sips) from its HTTP-style clients ...". 

Unfortunately, the SIP/HTTP RfCs do not mention AAA servers. Do
you propose a separate draft "https/sips usage with AAA protocols"?
Is there a better behaviour than refusing the sips/https?


The second thing is that you are (IMHO) wrongly overloading the semantics of at least the SIPS URI, which is clearly defined in RFC 3261:

   "A call
   made to a SIPS URI guarantees that secure, encrypted transport
   (namely TLS) is used to carry all SIP messages from the caller to the
   domain of the callee.  "


RfC 3261, section 19.1 tells us (emphasis by me):
"
   A SIPS URI specifies that the resource be contacted securely.  This
   means, in particular, that TLS is to be used between the UAC and the
   domain that owns the URI.  From there, >>>secure<<< communications are used
   to reach the user, where the specific security mechanism depends on
   the policy of the domain."

So, secure communications has to be used, but not necessarily TLS. If
I recall the SIP WG discussions correctly, the whole point of sips was
to guarantee secure hops along the path of a SIP request.


it is not even implementable, since it does not affect RADIUS 

The question is whether implementors will understand the desired
behaviour. Introducing the concept of RADIUS and SIP/HTTP subsystems
interacting with some internal protocol will not help.

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