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

["Francois Audet" <[e-mail]>]

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.

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:[e-mail]] 
> 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@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@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@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@P1
> in both to: and from: and still point it at application@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:[e-mail]]
> >> 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@P1
> >>
> >> The authority for something@P1 (the person that might send a
> >> register request with that in the To: header) wants 
> requests to go to
> >> sip:someapplication@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@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@p2;transport=tls.
> >>>
> >>> The transport parameter indicates that the resource in the
> >> request URI
> >>> (uas@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@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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip