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

["Francois Audet" <audet at nortel.com>]

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

I don't believe that using transport=tls in Contact for
Registration will generally work.

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.

	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.


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