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

From: "Elwell, John" <[email-masked]>
Date: Wed, 01 Nov 2006 08:28:45 +0000

Dean,

I think your proposal is moving in the right direction, but I have a couple
of concerns. See below.

John 

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]] 
> Sent: 31 October 2006 18:21
> 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...
> 
> 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).
[JRE] Whilst I agree with the above, I am concerned that the UAs involved
will not know whether best effort has resulting in a signalling path that is
secure on all hops. Why do I want to know? Suppose I have feature X that
somehow relies on all hops being secure. If I want the request to fail if I
can't use feature X, then I use SIPS. However, if I want the request to
succeed even if I can't use feature X (because some hops are insecure), then
I need some indication of whether all hops are secure or not, and then I can
decide whether to use feature X. Giving an example of a feature X is not so
easy, but one possibility could be identity. I might anonymise the From
header in a SIP request, and then, if it results in a dialog that is secure,
I might use connected-identity to change the From header field URI
mid-dialog. As another example of a feature X, maybe I am prepared to use
media security using SDescriptions if the dialog is secured, without using
S/MIME. Therefore I find the dialog is secure I re-negotiate the session,
this time with SDescriptions.

> 
> 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.
[JRE] As I stated in one of the related threads, I think SIPS should govern
hops as far as the PSTN gateway, and the potential insecurity of whatever is
beyond that gateway should be signalled by other means. Achieving a SIPS
connection as far as the gateway might allow me to use SDescriptions to
achieve media security to that gateway. I can't do much about what is beyond
the gateway, but a separate indicator that says that it might not be secure
would allow me, for example, to suppress the security padlock.

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

_______________________________________________
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 14:31:34 -0600

> I think your proposal is moving in the right direction, but I have  

In summarization, I think your concerns all involve some variation of  
knowing "what happened downstream". Specifically, you want to know if:

1) A sip: URI scheme actually produced a dialog with encryption on  
all hops. You may want to know more about it than "encryption", for  
example you may want to know what sort of encryption, or what  
mechanism was used to authenticate the intermediary or terminus. By  
knowing you had succeeded in getting a secure channel, you could  
decide to engage other mechanisms (like key exchange) or activities  
dependent on that security.

2) The security of a sip: or sips: request is degraded (or  
potentially degraded) by a gateway threshold, beyond which the  
reporting mechanism has no visibility and which we would generally  
assume has fully denigrated our cryptographic protections. By knowing  
the security of sips: is not really end-to-end, you could moderate  
the invocation of other mechanisms or activities as appropriate for  
an unsecured channel.

I think these are great things to know. I think they go substantially  
beyond anything we can describe as a BCP for using sip: and sips:. I  
think this requires new mechanism, perhaps something like a mutant  
cross between history-info and Samir's cipher-suites draft.

--
Dean