Security in Real-Time Comms.

Security is important for communication, and in the wake of XXXX (pick your favorite) revelations, the IETF RTCWEB working group and other standard committees alike had decided to up their game. With respect to webrtc, that’s for example when the decision was made to mandate the more secure DTLS-SRTP over SDES-SRTP. The entire Security architecture is documented within a corresponding documents and some dependencies:
https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-14

Encryption is only really useful if it is end-to-end and if you are sure who you are talking to.

End-To-End Encryption

In the default p2p case, Webrtc is end-to-end encrypted, but when there is a media server in the loop, it is not. Upon reception of a stream by the media server the encryption is dropped (the DTLS is “terminated”), and later on another encrypted connection is made between the media server and the remote peer. The IETF PERC working group has been working on this problem for some time now, and this is not the subject of this blog post. People interested can look at the ongoing work there, or read some articles on a slightly different approach, with implementations in Janus, Jitsi and Meedoze webrtc media servers are online.

This blog post is about the latter problem of identity.

Identity Verification

Multiple Identity Verification Services

Arriving at the conclusion that there would be no serious security model without an identity verification mechanism, the W3C WebRTC working group decided to add a mechanism to support identity providers. Yes, providers with an ‘s’, as not a single mechanism would emerge as the global standard. OAuth is a very well supported mechanism used by many identity providers, usable with facebook, google, and other identity providers, but there are other mechanisms that will be used, and the working group couldn’t find a compelling reason to restrict WebRTC to using only one.

More details to be found in Webrtc identity JS APIs in the browsers, in section 5.6 and section 6.4 of the RTCWEB security architecture document and Illustrated in Cisco’s cullen’s slides.

No WebRTC Identity Service yet!

Practically, and surprisingly, only a few browsers have implemented these APIs (actually, only Firefox), and there is no in-production implementation of an Identity Provider the way it was defined in the standard document that exist today (as far as the author knows). A few mockups of such service were implemented by Firefox for testing services, but there were far from complete, their goal being to just exert the APIs and not really to use them in a production environment against a real identity service.

First WebRTC Identity Verification Service Challenge

A small group of enthusiasts (including yours truly) decided to use the IETF’101 meeting hackathon time to try to make the first implementation of a viable identity provider and test corresponding implementation and APIs in Firefox, the only browser which implements them today. By doing so, they surrendered otherwise tremendously enjoyable sightseeing time under the blistering cold weather of London in March, only to suffer being provided with free, unexpectedly great food and beverages from Hilton hotel services. One has to recognize their selfless contribution to IETF community here.

First WebRTC Identity Verification Implementation

All the code generated during the hackathon is public.

The CoSMo example and google’s example are both functionnal. The google example is self contained in that repository, and should be the starting point. Happy hacking !

What’s next.

As expected the Hackathon revealed a couple of bugs in the Firefox implementation. These are being worked on already, see bug 1446880. Lots of discussions are right now happening in the IETF-RTCWEB mailing list to increase the security of the mechanism.

Participants in alphabetical order

H. Alvestrand (1), A. Gouaillard (2),T. Hollebeek (3), C. Jennings (4), S. Murillo (2), N. Ohlmeier (5), M. Thompson (5),
(1) Google (hackathon champion), (2) CoSMo Software, (3) DigiCert, (4) Cisco, (5) Mozilla