Subject: Re: [Sip] The Problem with PRACK

From: Dean Willis <[email-masked]>
Date: Wed, 15 Mar 2006 16:39:09 -0600

On Mar 15, 2006, at 11:38 AM, Brian Stucker wrote:

> I don't know that I follow you suggestion in the specific case I am  
> talking about.
>
> Take for instance Call Forward No Answer. In this case, A never  
> says that it's done with the call before it is retargeted to B by  
> the network. A and B have no idea that the service even exists in  
> the middle.

That's called a "badly designed service", from a security  
perspective. If the service can squat on the call, whats to prevent  
some other MITM?

--
Dean

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Brian Stucker" <[email-masked]>
Date: Wed, 15 Mar 2006 11:38:27 -0600

I don't know that I follow you suggestion in the specific case I am talking about.

Take for instance Call Forward No Answer. In this case, A never says that it's done with the call before it is retargeted to B by the network. A and B have no idea that the service even exists in the middle.

Regards,
Brian

-----Original Message-----
From: Michael Hammer (mhammer) [mailto:[email-masked]]
Sent: Wednesday, March 15, 2006 8:42 AM
To: Stucker, Brian [RICH1:B620:EXCH]; Dean Willis; Cullen Jennings
(fluffy)
Cc: [email-masked]; Audet, Francois [SC100:3055:EXCH]; Paul Kyzivat
(pkyzivat)
Subject: RE: [Sip] The Problem with PRACK

> -----Original Message-----
> From: Brian Stucker [mailto:[email-masked]] 
> Sent: Tuesday, March 14, 2006 11:55 AM
> To: Dean Willis; Cullen Jennings (fluffy)
> Cc: [email-masked]; Francois Audet; Paul Kyzivat (pkyzivat)
> Subject: RE: [Sip] The Problem with PRACK
> 
> Based on your proposals below, cryptographically transparent 
> versus redirection:
> 
> How would you go about addressing applications like CPL that 
> need to run timers for service logic and thus need to have 
> some level of control over the session (not necessarily 
> what's in the body of the messages, just where they're going) 
> if a redirection model is used?
> 
> For example, without mucking about with what's inside the 
> request, triggering off of the request URI of an INVITE to 
> forward to destination A for X seconds and then to 
> destination B. In this example the next hop changes over time 
> for the same request and does not seem possible using 
> redirection. This seems to preclude redirection as a general 
> solution and drive towards requiring a proxy to be 
> cryptographically transparent.

Is there a reason the redirect server couldn't send you to A, 
which then redirects or Refers you to B when A is done with 
it's part of the service?

It seems the proxy is best at directing traffic, while the UAS
could contain distributed feature logic.  Think of an assembly
line of robots, each which knows its part of the process, but 
not necessarily the whole.

Mike

> 
> If the proxy is transparent, then how do you go about not 
> precluding deep-packet inspection issues raised by 
> applications such as QoS enforcement, network enforced 
> identity or other services? It seems to me that HTTPS may 
> make a bad model in that I'm unaware of any HTTPS-based 
> application that has a box in the middle that needs to 
> inspect and enforce certain characteristics of the request 
> before it is handled by the final consumer of that request.
> 
> This seems to preclude cryptographic transparency as a 
> general solution. 
> 
> I'm sure either can be used effectively in many application 
> spaces, but it does not seem that either can be used as a 
> general solution in the protocol itself.
> 
> Regards,
> Brian
> 
> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: Tuesday, March 14, 2006 1:08 AM
> To: Cullen Jennings
> Cc: [email-masked]; Audet, Francois [SC100:3055:EXCH]; Paul H Kyzivat
> Subject: Re: [Sip] The Problem with PRACK
> 
> 
> 
> On Mar 14, 2006, at 12:24 AM, Cullen Jennings wrote:
> 
> > On 3/13/06 10:27 AM, "Dean Willis" 
> <[email-masked]> wrote:
> >
> >> Right. But, SIPS is only required as far as the proxy serving the 
> >> AOR. The AOR to Contact vector could be UDP/IPSEC, or even 
> just plain 
> >> unsecured UDP.
> >
> > I think we have a gathering amount of evidence that we want 
> to update 
> > this regardless of UDP or PRACK.
> 
> 
> It's true that SIP proxies just don't work "right" with SIPS as it is.
> 
> When people first look at the "SIPS is only valid to the 
> serving proxy" model they assume that simply changing the 
> requirement to say that the proxy-to-UA leg must also be SIPS 
> protected would provide a satisfactory answer. It doesn't, 
> and this requires some careful thinking.
> 
> What security do you mandate on the serving-proxy to UA link? TLS?  
> TLS supports many different ciphersuites. What keeps the 
> crypto on the SP-UA link from being watered-down? Would other 
> protections like IPSEC suffice? How would you end-to-end 
> negotiate the cryptography so that the originating UA could 
> believe that the entire chain was protected to some minimal 
> level? And how do you offer some level of security to an IMS 
> fashion-victim who is always going to be exposed to MITM 
> attacks from his own service provider by design?
> 
> Personally, I think the only way SIPS really gives us the 
> level of protection we have come to expect from HTTPS is if 
> it is used end-to- end, either by abandoning proxy-routing in 
> favor of a redirect model, or by causing the proxies to be 
> cryptographically transparent as is done with HTTPS proxies.
> 
> This is an important thing to note: HTTPS proxies do NOT "see 
> inside"  
> the HTTPS stream. All they do is pass it along, unchanged, to 
> the next hop. It could actually be some other protocol than 
> HTTP, and they don't care and can't tell. To-date, we haven't 
> treated SIPS proxies that way, and instead presume they have 
> access to the full stream, in many cases "write access" so 
> that they can munge various header fields about.
> 
> --
> Dean
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip