Re: [sipcore] SIP Federation, authentication and interoperability with WebRTC

["Olle E. Johansson" <[e-mail]>]

> On 5 May 2020, at 10:45, Filippos Vasilakis <[e-mail]> wrote:
> 
> Hello everyone,
> 
> I first sent this email to sip-implementers mailing list as I was pointed out by @sobomax and @oej, but that mailing list told me that the things I ask are more related to this group, so here I am.
> 
> I started looking into SIP over the past months because I find it quite interesting protocol. I have went through various RFCs and technical documents and I have some questions that might be naive, but due to lack of experience I need some guidance and clarifications. Also, I hope I am in the right place asking those questions.
> 
> 1) What's the status of SIP Federation? It seems like there is no official standard in there, but do we need it in order to achieve it ? The Secure Telephone Identity Revisited IETF group [0] has done some amazing work over the past years regarding SIP authentication (especially from the callee side). Is that enough for having secure SIP Federation, or are there missing pieces in the puzzle?
There’s no official definition of “Federation” in the world of SIP. The protocol was designed for open internet calls like email, based on DNS. The question is how we can open up
for that and stiil trust each other - as well as being able to have black lists. We want no spam/spit problem. I have enough calls trying to sell me mobile phone services as it is ;-)

> 
> 2) The WebRTC seems like it's taking a completely different road regarding federation [1]. There, it seems like the signaling protocol (which is not defined yet, but SIP is a major candidate), is used only for passing over the user identities, and then the actual federation checks take place inside the browser. I guess that's needed in case you don't trust the site you are sitting on, like a poker site, but still need to communicate with your friends, and verify that these are your friends, whose identity might belong to a completely different server/domain from yours and different from the poker site you are sitting on. Actually that scenario is explained by [1]. But still, that's quite different with SIP, so how is SIP interoperability is going to work with that? Has anyone give a thought? Feels super important to me that these 2 don't divert.
WebRTC doesn’t really take other roads, but the signalling behind webrtc may have different approaches. XMPP has a federation much like SIP, but from start separated server2server connections from client2server connections,
which may make life easier. Most of the WebRTC islands seems to build their own signalling, so there’s no much hope unless they can use an open protocol like SIP or XMPP for federation.
If you want federation with WebRTC, for me XMPP is the choice right now (even though there’s a huge spam problem there).

> 
> 3) Olle Johannson, in a talk in Kamailio conference, said that SIP still hasn't solved the end-to-end encryption and integrity, mostly because, at some point the route might go through a non TLS connection. Well that's not an easy problem to solve, but I think that [0] has solved most of that (the integrity part), or am I wrong ? I mean, sure the SIP request might be come with the headers stripped off, but that's something that the callee SIP server shouldn't trust much. If it has the necessary headers though (the passport), then the caller should be who says it is. Of course the encryption is still remaining open, but is this solvable at all? Anyone working on that that ?
STIR is handling one problem - securing the identity and making it trustworthy between domains. It aimed to solve the problem with phone number spoofing, but I’m pretty sure we can use the PassPort in other creative ways if we stir up some interest for it :-) If so, we need to find out the underlying trust infrastructure for something STIR-like on the internet.

We still need to solve the TLS end to end dilemma to protect metadata in the call - like the SDP, the DTLS fingerprint, the target of the call and much more. 
> 
> 4) How people do authentication mostly in SIP, when some kind of federation is needed? Is RFCs from [0] a common practice now? Is DANE (which from what I understand depends on DNSSEC) something that is used at all ? Something else ?
I think one needs to separate the SIP client authentication to a service from how different domains trust each other. SIP identity (which STIR got inspiration from) was focused on domain to domain trust. 
The SIP client authentication is changing quickly, as we add stronger hash algorithms and hopefully soon Oauth2/OpenID connect.  

To summarize: My view is that a missing bit is how “edvina.net <http://edvina.net/>” trustfully can call you in your domain. How will your domain trust that the call really originates in “edvina.net <http://edvina.net/>” and
how can you trust my identity when I call you? How can I trust that you are the right person to answer my call? I think - if I remember correctly - that was left as out of scope in “SIP Identity”.

I have recently done a lot of tests of TLS in a range of SIP desktop phones and so far I have found no phone that can give me a decent level of security,
or a working implementation that is up to date with the TLS standards.Unless customers stop sending them money, the vendors won’t change and make
it better, but there seems to be little demand for security in the enterprise market. 

Thank you for starting this discussion. 

/O

> 
> I guess I fired too many questions, but I would love to get back some clarifications.
> 
> [0] https://datatracker.ietf.org/wg/stir/documents/ <https://datatracker.ietf.org/wg/stir/documents/>
> [1] https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-20 <https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-20>
> [2] https://www.youtube.com/watch?v=FO1N6gEjxUo <https://www.youtube.com/watch?v=FO1N6gEjxUo>
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore