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

[Paul Kyzivat <[e-mail]>]

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:[e-mail]]
>> 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:[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
> 
> 
> _______________________________________________
> 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
> 


_______________________________________________
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