sips must die, die, die - about tls usage in the sip protocol
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 - 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
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.