Subject: Re: [Sip] A sips: trial balloon for you to shoot down

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 01 Nov 2006 16:29:58 -0500

I'm all for #2 and #3. I'm still pondering whether #1 implies that #2 is 
useless.

On #4, I think this is going to far. Please let us not make the perfect 
the enemy of the good. I really don't understand why people are placing 
this absurdly high expectations on what sips can do. As Hadriel pointed 
out, https only guarantees security to the server; where it got its 
content from - who knows.

-Jonathan R.

Dean Willis wrote:

> 
> Ok, let me make a proposal, or perhaps remake one somebody else has  
> made. I've lost track of who said what...
> 
> I think we're now talking about a BCP for secure operations.
> 
> 1) Implementations of SIP SHOULD use TLS as described in RFC 3261 for  
> all SIP traffic, including traffic using a sip: URI scheme. Failure  to 
> use TLS may result in disclosure of sensitive signaling  information to 
> third parties. As a matter of local policy, some  deployments MAY use 
> IPSEC or physically protected infrastructure  instead of TLS on specific 
> links. Examples where this might be  appropriate include persistent 
> IPSEC relationships between proxies  within an operational domain and 
> physically protected "private  network" cables between a TLS 
> concentrator and the device it is  fronting for. Where TLS is not used, 
> the implementor MUST exercise a  high level of caution to provide 
> adequate security and MUST preserve  operationally equivalent protection 
> of message integrity, privacy,  and participant identity (authentication).
> 
> 2) When using the sips: URI scheme, implementations MUST NOT exercise  
> the "last hop exception" for sips: processing described in RFC 3261.  
> Most scenarios where this technique might have seemed appropriate can  
> be better satisfied using a client-initiated TLS connection as  
> described in draft-ietf-sip-outbound. User agents that do not  implement 
> both TLS and either terminate TLS connections or exercise  
> draft-ietf-sip-outbound with a US-originated TOS connection to an  
> outbound will therefore not be able to exercise the sips: URI scheme.  
> Failure to observe this requirement is likely to result in a  reduction 
> of operational security below that expected from the sips:  URI scheme.
> 
> 3) Since some user-agents will not be able to exercise the sips:  
> scheme, implementations MUST anticipate the failure of sips: requests  
> and in general SHOULD use sips: only when it is desired that the  
> request will not complete unless TLS will be used on each hop. Since  
> requests using the sip: URI scheme are (by requirement 1 above)  
> expected to be as securely processed as the implementation is able to  
> do, it is not suggested that one first try sips: and then back off to  
> sip:. In other words, if you're willing to settle for the best  security 
> that can actually be provided, simply originate the request  with a sip: 
> URI scheme.
> 
> 4) User agent servers that terminate a request using the sips: URI  
> scheme MUST create any dependent requests using the sips: URI scheme.  
> This preserves the commitments of the sips: scheme, and failure to  
> observe this constraint would give the appearance of sips: security  
> where no such security exists. For example, this requirement means  that 
> that back-to-back user agents bridging two sips: requests use  sips: on 
> both sides. Furthermore, gateways to other protocols not  offering 
> equally strong protections MUST NOT exercise the sips: URI  scheme. In 
> particular, PSTN gateways MUST NOT use sips:, since the  PSTN itself 
> does not offer equivalent protections and there is no  ability to 
> determine whether the PSTN segment might be converted back  to a sip: 
> request somewhere downstream.
> 
> 
> -- 
> 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
> 

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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: Dean Willis <[email-masked]>
Date: Wed, 1 Nov 2006 15:43:26 -0600

On Nov 1, 2006, at 3:29 PM, Jonathan Rosenberg wrote:

> I'm all for #2 and #3. I'm still pondering whether #1 implies that  
> #2 is useless.
>
> On #4, I think this is going to far. Please let us not make the  
> perfect the enemy of the good. I really don't understand why people  
> are placing this absurdly high expectations on what sips can do. As  
> Hadriel pointed out, https only guarantees security to the server;  
> where it got its content from - who knows.
>

#4 says:

>> 4) User agent servers that terminate a request using the sips:  
>> URI  scheme MUST create any dependent requests using the sips: URI  
>> scheme.  This preserves the commitments of the sips: scheme, and  
>> failure to  observe this constraint would give the appearance of  
>> sips: security  where no such security exists. For example, this  
>> requirement means  that that back-to-back user agents bridging two  
>> sips: requests use  sips: on both sides. Furthermore, gateways to  
>> other protocols not  offering equally strong protections MUST NOT  
>> exercise the sips: URI  scheme. In particular, PSTN gateways MUST  
>> NOT use sips:, since the  PSTN itself does not offer equivalent  
>> protections and there is no  ability to determine whether the PSTN  
>> segment might be converted back  to a sip: request somewhere  
>> downstream.

Without #4, then any SBC can use sips: on one side and sip: on the  
other and nobody will know that it's broken. In fact, we'd have  
documented doing so as being consistent with Best Current Practice.

Is that what you want?

The way I read it, #1 makes #4 acceptable. After all, you're going to  
get best possible security from sip: from #1 You only use sips: if  
you want the call to fail if it is not possible for EVERY hop to use  
TLS. So if you expect to gateway the call, use sip:, not sips:.

--
Dean