sips must die, die, die - about tls usage in the sip protocol

19
SIPS: must die. or at least we need to fix TLS usage without the SIPS: uri scheme. [email protected] - 2016-06-17 v 1.0

Upload: olle-e-johansson

Post on 15-Feb-2017

280 views

Category:

Technology


0 download

TRANSCRIPT

SIPS: must die.or at least we need to fix TLS usage without the SIPS: uri scheme.

[email protected] - 2016-06-17 v 1.0

Example overview

sollentuna.example.com paris.example.com

server toserver connection

(B)

KURT ALICE

UA connection(A)

UA connection(B)

Securing first hop Securing server 2 server connections Securing last hop

End to end security

The SIPS: uri scheme is an attempt to promise end2end

security.

The problem• SIPS: as a URI scheme implies end2end security,

something that can not be verified

• SIPS: promises something that can not really be delivered, especially complex in a world of b2buas and gateways to other protocols

• We need more TLS usage, but SIPS: has too many issues. For some developers, it seems to be the only solution. This makes TLS less deployed in code or in usage

History

• RFC 3261 talks about TLS usage and certificates

• RFC 5630 clarifies SIPS: URI usage and updates RFC 3261

• RFC 5922 defines Domain certificates in SIP

• SIPS: is required to implement to be SIP compatible

Client certificates

• Never properly discussed

• Needs to match the AOR?

• Needs to match the Contact?

• Needs to match something else?

RFC 5630

RFC 5630 - general• 3.1.1. Points to RFC 5626 (Outbound) for UAs in

order to avoid using client certificates (mutual TLS auth)

• Avoids defining SIP TLS client certificates

• 3.1.3 Discussed best effort TLS

• Points to RFC 3261 section 26.3.2.1 for connection reuse (and points to RFC 5626)

RFC 5630 about “;transport=tls”

• 3.1.4 :: “The reinstatement of the transport=tls parameter, or an alternative mechanism for indicating the use of the TLS on a single hop in a URI, is outside the scope of this specification.”

RFC 5630 about hop-by-hop security:

• 3.2 :: “The presence of a SIPS Request-URI does not necessarily indicate that the request was sent securely on each hop. So how does a UAS know if SIPS was used for the entire request path to secure the request end-to-end? Effectively, the UAS cannot know for sure.”

RFC 5630 modification to 3261:

• 4 :: “Because of all the problems described in Section 3.3, this specification deprecates the last-hop exception when forwarding a request to the last hop (see Section 5.3). This will ensure that TLS is used on all hops all the way up to the remote target.”

• Which means SIP outbound (RFC 5626) or client certs for the last hop.

RFC 5630 on padlock icons• Section 4 :: “Some have been tempted to believe

that the SIPS scheme was equivalent to an HTTPS scheme in the sense that one could provide a visual indication to a user (e.g., a padlock icon) to the effect that the session is secured. This is obviously not the case, and therefore the meaning of a SIPS URI is not to be oversold. There is currently no mechanism to provide an indication of end-to-end security for SIP. “

Service owner may control TLS usage in DNS

• By only presenting TLS in DNS Naptr/SRV the service owner may limit/enforce UAs to TLS only

• May also implement a policy where TLS is preferred but TCP/UDP is accepted

Where are we?

sollentuna.example.com paris.example.com

server toserver connection

(B)

KURT ALICE

UA connection(A)

UA connection(B)

Securing first hop Securing server 2 server connections Securing last hop

Using SIP outbound and TLS we can secure the first/last hop The user has no way to

affect what happens between servers or beyond gateways

What if we just remove the SIPS: uri scheme?

Remove SIPS:

• Implementations can be SIP compatible without SIPS:

• We only have control over the FIRST hop, to the edge server

• What happens beyond that server is no longer in control (if it ever was)

Client side control

• Clients (UAs) implement a “require TLS” option checkbox in the configuration page, which will force lookup of NAPTR records, the DNS SRV records

• If no DNS support, try TLS port 5061

• This only applies to the first hop

Requirements• A way to force clients to use TLS for inbound

connections

• A simple way to reuse that connection for outbound requests

• Maybe a way to get confidentiality for hops beyond the proxy

• If so a way to verify that confidentiality

Just a thought : S/MIME

• Can we wake up S/MIME again?

• If not, have we analysed the issues with it?

• Any experience?

• There’s some sort of end2end security promise in that platform.

Summary• In my view, SIPS: is too hard to implement and if

implemented, deliveres a false promise

• TLS edge connections needs to be made more simple - outbound doesn’t seem to be accepted as the solution

• We need to look deeper into end2end integrity, confidentiality and privacy