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

Re: [Sip] Ready for WGLC on SIPS draft? Any last thoughts ontransport=tls?

Jumping in. I just happened to pick Gilad's message to respond to.

I've only been loosely following this discussion. But it seems to me that this transport=tls issue is a distraction from finishing the sips draft. Why does the sips draft have any responsibility for addressing this issue?

I think it would be better to let the sips draft be finished and then move on to addressing all of the (many) important security issues that sips doesn't solve, as a separate effort.

	Paul

Gilad Shaham wrote: 
I can add even more complications (even though it seems complicated
enough, but what the heck).
What if we want to specify the encryption level (e.g. 40 bits or 128
bits)? What if we want to specify IPSec?

It seems to me that transport=tls in the request URI causes a lot of
historical issues. Maybe there is a need for a feature tag/header that
defines the allowed secure methods for examples:
Unencrypted, tls, ipsec
The proxy would then be free to do whatever lookup method it wants (via
DNS, according to outbound or any policy) and it will forward the
request only if there is an option within one of the possible values it
received on the request.

Just a thought, I hope it helps.


-----Original Message-----
From: Robert Sparks [mailto:rjsparks at nostrum.com]
Sent: Tuesday, June 05, 2007 4:49 PM
To: Francois Audet
Cc: SIP IETF; Dean Willis
Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last thoughts
ontransport=tls?


On Jun 4, 2007, at 7:14 PM, Francois Audet wrote:

Hi Robert,

I understand what you are saying. And you are right: my point about
Third
party registration was a red herring: it's really the Contact being
different than the source of the REGISTER that is a problem).

But frankly, the transport parameter in general IMHO is a problem.
The 
fact that SIP isn't layered properly on top of TCP (or UDP) is the
issue frankly.

In a world where there are no NATs, no FW and every Joe has it's own
user certificate, we could make the transport parameter work.

If we re-introduce transport=tls, then we'll have to explain when it
will
work. We will have to write big caveats that it won't work unless
you 
have no NAT, no Firewall, and you are using Mutual-TLS with User
certificates for the UAs. In general, it won't work.

So I understand your position on how this affects devices we expect to
be behind transport-destroying elements and that we don't expect to
generally have certificates.

What about the proxy->proxy (or some stable network server) hop, where
we expect there _isn't_ a transport-destroying intermediary (hah) and
that
we expect they _do_ have certificates? This is the case where I think
we 
have a real constituency (with real applications) that we're harming.

Consider the routing decision that P1 needs to make. The tools we have
allow P1 to choose among the protocols it knows how to use by
administrative
configuration. They let P2 express policy about which protocols P1
should use
(through DNS). What they don't do is let P1 choose between protocols
based
on a user's (or application's) input.

We've got this concept of a location service that you access using
REGISTER.
The spec talks about running it separately from a proxy - so consider
the case
where  a proxy either does query REGISTERs or sends a request to a
redirect
server to figure out where it's supposed to go. What it gets back is
URIs in
Contact header fields. How can the location service tell the proxy
that's asking
for a routing decision that "for this input URI, goto this output URI
and use TLS"?

RjS

In my mind, we would be doing a disservice to the industry by
writing
protocol to do something that almost never works. The "But I can do
it
today in the field (but just for TCP)" doesn't hold water, because
TLS 
is not TCP.

Furthermore, this "transport=tls" stuff is not documented anywhere
in 
any RFC. So we would be writing from scratch broken procedures to
"document" broken practices in the field. Seems insane to me.

The clear and compelling reason to not use "transport=tls" is that
it 
won't generally work, except for very contrived scenarios.

PS: "Transport=tls" was "deprecated" in RFC 3261, but it didn't
exist 
     either in its predecessor RFC 2543. It was only defined in the
     the draft-ietf-sip-rfc2543bis-00. So the implementations that
use 
     it today do not conform to any RCF, obsolete or otherwise.



-----Original Message-----
From: Robert Sparks [mailto:rjsparks at nostrum.com]
Sent: Monday, June 04, 2007 15:52
To: Audet, Francois (SC100:3055)
Cc: Dean Willis; SIP IETF
Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last
thoughts on transport=tls?


On Jun 4, 2007, at 5:34 PM, Francois Audet wrote:

Ok, so it has nothing to do with Request-URI then (which is what I
tought we were talking about).

Well, we're still not connecting quite yet.

It has _EVERYTHING_ to do with Request-URI.

It is coincidence that I'm populating what the RURI will be
after retargetting with a REGISTER. It could have been any
other mechanism. The important part is what comes out into
the Request-URI of the P1->P2 link.

I don't believe that using transport=tls in Contact for
Registration
will generally work. 
(as you read my inline responses below, ask yourself what
  =tls has to do with what you wrote - I think I can substitute
=tcp, 
    which we _do_ allow, and everything but the comments about
    mutual or server auth still stand)

There are 2 cases:

From == To in REGISTER (First Party Registration)
-------------------------------------------------

	In this case, if we use SIP-Outbound, we DO already
	have a solution.

Surely you're not suggesting proxies do outbound between them.
You're latching onto the endpoint case. I'm talking about a
server to server case.

	With SIP-outbound, the connection used by the registration
	process is kept alive and reused for both incoming and
	outgoing requests.

	It has the advantage that it will support environments
	where server-provided certificates are used since
	the TLS connection will only be establishable by the
 	client.

	A a bonus, SIP-outbound also solves NAT and FW traversal, if
	there happens to be one.

	Their proposed solution of using a transport parameter
	will not work for server-provided certificates as the
	server will not be able to establish a connection with
	the client. Since server-provided certificates is by far
	the most commone deployment scenario (as opposed to
	Mutual TLS) for UAs, this is a big problem.

	Their proposed solution wouldn't work either if there is
	a NAT or Firewall. Again, big problem.

	Their proposed solution would therefore ONLY be
	suitable for environments where Mutual TLS is used, and
	where there are no NATs or Firewall.

	The SIP-outbound mechanism also works with Mutual TLS.

	Therefore, for this case, I do not believe that their
	mechanism is general enough to be standardized.

	This is described at lenght in the draft.


From != To in REGISTER (Third Party Registration)
-------------------------------------------------

	Third party registration is problematic for both their
	proposed solution, as well as for SIP-outbound.

	For SIP-outbound, well, it plainly doesn't work.

	For their proposed solution, it is a security problem
	since it effectively allows a non-secure user (the "authority"
	as you call it), to request that session be delivered securily.
	Dr, Evil person could hijack the "authority" role and redirects
	all sessions to wherever it wants, and the sessions would be
	"secured" with Dr. Evil.

	Furthermore, their proposed solution would not work in this
	case either with server-provided certificates, or if there
	is a NAT or Firewall. Again, big problem.

	To me, it means that Third Party Registration is just plain
	bad in a secure environment.

	In fact, I don't like the idea of allowing third party
	registration to allow a UAC with AOR in p1 domain to
	register a contact in a different domain (p2 in this case).
	That contact is effectively an AOR.

	How would I solve the problem?

	I would expect the other UA (sip:someapplication at P2) to do it's
	own registration in it's own domain P2, according to the rules
of it's
	own domain. If P2 is using server-provided certificates, it
would
	work (with Outbound). If a NAT is present, it would works as
well.

      Then, I would allow user "something at P1" to log in securily
	on the Proxy (with HTTPS for example), and request routing to
	be done to another address (in this case,
sip:someapplication at P@).
	To ensure that P1 would use TLS to P2 (as they want), I'd just
put
	a "User TLS" checkbox.

	That seems to me to be a lot less broken that trying to squeeze
it
	into third-party REGISTER.
This is getting closer to the P1->P2 hop, but its a bit of a
herring 
that
you've separated 1st and 3rd party registration. I could have
something at P1
in both to: and from: and still point it at application at P2.

I understand where you are going with "make that a checkbox on
somebody's GUI" and
that's exactly what I'm saying isn't good enough. The preference
needs to be reflected in the URI.

For the registration case, binding things between P1 and P2, let me
try yet another way to say this.

It's in the field.
People are USING it.
We are trying to say "Don't do that" without giving an alternative
that works in that scenario.
We will be ignored unless we can present a clear and compelling
reason why someone
is putting life or limb at risk to do this (and I suspect we'll be
ignored even then).

I'm not sure I can make any such argument around just this
transport 
parameter. If we're
going to allow someone to say "udp" or "tcp" in this case,
its rather
pointless to not let them
say tls (with the appropriate caveats around not having the
anchor in
DNS to verify who
you're talking to).

I _can_ make an argument around the notion of putting state in that
doesn't point directly to you,
but that goes way way beyond just the transport parameter, and if
we're going to go there, we
need to start an entirely different conversation that will take the
transport parameter completely
off the table for _any_ transport.

RjS


-----Original Message-----
From: Robert Sparks [mailto:rjsparks at nostrum.com]
Sent: Monday, June 04, 2007 14:55
To: Audet, Francois (SC100:3055)
Cc: Dean Willis; SIP IETF
Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last
thoughts on transport=tls?

Ok - we're closer, but not quite together yet.

Lets start with a different message from the UAC where the
RURI is simply
sip:something at P1

The authority for something at P1 (the person that might send a
register request with that in the To: header) wants
requests to go to 
sip:someapplication at P2
and they want it to go over TLS. What they'd _like_ to do is
send a register request with a contact that says to use TLS,
or at most, send a single URI to the operators of P1 that
describes where to send requests that show up for something at P1.

What tools do we give them to make the statement they want to
make? 
RjS



On Jun 4, 2007, at 4:30 PM, Francois Audet wrote:

This is exactly where we are disagreeing.

How do you _tell_ P1 that you want to reach P2 using TLS
in the first 
place.
As I said elsewhere in the thread, I don't think leaving this
unspecified ("you just do this with the configuration of the
proxy") is the right answer. If you have DNS, you tell
P1 about P2
using DNS. If you don't have DNS, using the transport
parameter in
the URI you hand it seems pretty natural. That's how
you're going to
tell it to use udp or tcp... 

I think I finally understand what you are saying...

Say UAC sends request to Request-URI uas at p2;transport=tls.

The transport parameter indicates that the resource in the
request URI
(uas at p2) is the one that needs to be contacted with TLS.
Therefore, it
would be the P1 -> P2 link that would use TLS in this case
(since P2 
owns that domain). And P2 could use whatever it wants for P2 ->
uas at uaspc.p2. And similarly, uac -> P1 (or P1 to any other proxy
between P1 and P2) could use whatever they want.

The use case would be where the UAC "trust" it own domain
and does not 
feel it necessary to use TLS, and/or the UAC "trusts" the target
domain for being responsible of that happens inside the
target domain.
And finally, the UAC does not really care if there are
other types of
proxies in the middle (not responsible for a specific
domain), that 
may not use TLS.

While I understand that this is in theory something that could
be
solvable, I'm not sure why it is such an interesting case.
Seems to me
it is only of value if the only "vulnerable" hop is the
one between 
the source and target domains, and if there are no other proxies
between them (e.g., no "Service provider").

In fact, it pretty much describes to me why you should be
using SIPS 
in the first place.

Do we *really* want to reintroduce transport=tls for this case?

Side note: I just want to point out that RFC 2543 did NOT
allow the
presence of the transport parameter at all in a Request-URI
and 2543
servers would ignore it or remove it. 




_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip