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

From: Dean Willis <[email-masked]>
Date: Tue, 31 Oct 2006 12:21:05 -0600

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

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 31 Oct 2006 13:08:09 -0600

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]] 
> Sent: Tuesday, October 31, 2006 10:21 AM
> To: IETF SIP List
> Subject: [Sip] A sips: trial balloon for you to shoot down
> 
> 
> Ok, let me make a proposal, or perhaps remake one somebody 
> else has made. I've lost track of who said what...
> 
> 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).

That first recommendation seems to be completely independent from
SIPS, right? Seems reasonable to me. That sounds like BCP-material
for sure. Something for a new document.

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

I like the idea of deprecating the last-hop exception. My makes the
exact same case your are making here (but it falls
short of deprecating the last-hop exception, because, the chair has
instructed me to not make normative changes). I'm assuming that 
making a normative change to RFC 3261 for this would require a 
new document.

What is not clear from this is if there are any relationship with
your proposal (1).  Specifically, I believe that most people believe 
that sips does imply TLS (and does not allow for IPsec). Are you 
proposing to change this so that (1) applies to sips as well? 

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

That is already covered in my draft (and in RFC 3261). 
No need to do anything else about it.

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

I think this is likely to be somewhat controversial (the pstn 
gateway limitation in particular).

I can go either way. I guess this is also BCP material.

---

From: Dean Willis <[email-masked]>
Date: Tue, 31 Oct 2006 14:39:42 -0600

> making a normative change to RFC 3261 for this would require a

I'd argue that making a normative statement about how to best USE  
3261 is not the same as making a normative change to 3261. Thus, this  
sort of behavioral requirement can be made in a BCP, without it  
actually changing 3261 or being a standards-track document.

> proposing to change this so that (1) applies to sips as well?

Nope. 1 is all about sip:. It is there to make sure that you get the  
best possible security if you don't use sips:, thereby allowing you  
to use sips: only when you want to make the call to fail if TLS is  
not present on EVERY hop.
> No need to do anything else about it.

No, this really say "Don't use sips: as your default mechanism. Only  
use it when you REALLY REALLY want the call to fail if EVERY link,  
including the last hop, is not TLS." Again, it;s not a change the the  
specification of 3261 -- it's a guideline on how to best use it.  
Behaviour needs reinforcing from time to time.

> gateway limitation in particular).

See discussion elsewhere -- without this requirement, sips: is  
exactly the same wishful thinking that sip: is (ok, do your  
best . . .) and might as well be deprecated.

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 31 Oct 2006 15:12:19 -0600

I'm happy with your proposal, as per your clarification.

I guess it would mean a new BCP document (plus some changes
to my draft for some sips-related aspects).

> Sent: Tuesday, October 31, 2006 12:40 PM
> To: Audet, Francois (SC100:3055)
> Cc: IETF SIP List
> Subject: Re: [Sip] A sips: trial balloon for you to shoot down
> 
> 
> else has 
> >> 3261 for all SIP traffic, including traffic using a sip: 
> URI scheme. 
> >> Failure to use TLS may result in disclosure of sensitive signaling 
> >> 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).
> >
> > SIPS, right? Seems reasonable to me. That sounds like 
> BCP-material for 
> > sure. Something for a new document.
> >
> appropriate can 
> > exact same case your are making here (but it falls short of 
> > deprecating the last-hop exception, because, the chair has 
> instructed 
> > me to not make normative changes). I'm assuming that making a 
> > normative change to RFC 3261 for this would require a new document.
> 
> 3261 is not the same as making a normative change to 3261. 
> Thus, this sort of behavioral requirement can be made in a 
> BCP, without it actually changing 3261 or being a 
> standards-track document.
> 
> >
> > What is not clear from this is if there are any 
> relationship with your 
> > proposal (1).  Specifically, I believe that most people 
> believe that 
> > sips does imply TLS (and does not allow for IPsec). Are you 
> proposing 
> > to change this so that (1) applies to sips as well?
> 
> Nope. 1 is all about sip:. It is there to make sure that you 
> get the best possible security if you don't use sips:, 
> thereby allowing you to use sips: only when you want to make 
> the call to fail if TLS is not present on EVERY hop.
> >
> 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) 
> >> 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.
> >
> No, this really say "Don't use sips: as your default 
> mechanism. Only use it when you REALLY REALLY want the call 
> to fail if EVERY link, including the last hop, is not TLS." 
> Again, it;s not a change the the specification of 3261 -- 
> it's a guideline on how to best use it.  
> >> 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.
> >
> > I think this is likely to be somewhat controversial (the 
> pstn gateway 
> > limitation in particular).
> >
> 
> See discussion elsewhere -- without this requirement, sips: 
> is exactly the same wishful thinking that sip: is (ok, do 
> your best . . .) and might as well be deprecated.
> 
> --
> Dean
> 
> >
> 
>