WebRTC paves the road to decentralized social
networks
Filippos Vasilakis
KTH Royal Institute of Technology
Network Services and Systems
Stockholm, Sweden
fvas@kth.se
With the rise of Internet, things started to change..
- Codecs and implementation take place at the end points
- Network is considered only as a medium
Enormous possibilities for research and innovation
Network architecture powering telephony had always been centralized
- functionality takes place in SAIs (fixed)
- codecs, multiplexing, processing
- common standards and protocols
20 years later..
- Voip has replaced telephony with very small (fixed) cost for all parties
- End users receive equal QoS if not better (with video enabled)
- End user got enormous amount of different options and providers
BUT
- No compatibility in most popular Voip providers :/
- Providers try to lock the users => more engagement => stable income
- Worsens user experience
WebRTC might change this
- runs in the browser
- IETF/W3C have standardized it
- the developer API
- the underlying protocols (SRTP, SDP, ICE, TURN, STUN etc)
What do we want to solve ?
- Allow users to authenticate to other parties using their favorite social service
- Use the most common user interface: browsers
- leverage WebRTC
Break silos in a standard way
How ?
Any related work ?
- Decentralied Social Networks
- Voip apps
Our Model
- Users can access a trusted browser
- Users trust/own their signaling server
- Not necessary if https://tools.ietf.org/html/draft-ietf-rtcweb-security-arch-13 gets published
- User's identity is decoupled from signaling process
- Users have relationship IdP
Other Entities
- Calling Services
- Ideally users should own/run one
- Can be authenticated through TLS
- Identity Providers
- can be authenticated though TLS
-
Other users
- Authenticated through IdPs
Solution Overview
Our solution is divided in 3 parts:
- The steps required for Alice to communicate with Per when both have a trusted browser open
- The steps required for each Identity Provider to confirm a user’s identity
- The steps required when Alice tries to communicate with Per when he is not in front of a trusted browser
Signaling Server
Signaling Server
SIP
Browser
JS API
Alice
- Media channel information
- ICE candidates
- A fingerprint attribute binding the communication to a key pair
- User's identity IdP fingerprint
- Per’s calling site domain or IP
Per
HTTPS
Signaling Server
Signaling Server
SIP
HTTPS
Browser
Browser
JS API
JS API
Alice
Per
- Media channel information
- ICE candidates
- A fingerprint attribute binding the communication to a key pair
- User's identity IdP fingerprint
- Alice’s calling site domain or IP
HTTPS
Signaling Server
Signaling Server
SIP
HTTPS
Browser
Browser
JS API
JS API
Alice
Per
- Media channel information
- ICE candidates
- A fingerprint attribute binding the communication to a key pair
- User's identity IdP fingerprint
- Alice’s calling site domain or IP
- TLS + IdP fingerprints make communication secure
- secure enough
HTTPS
User identity confirmation by IdPs
Based in RFC 5785
- Defines a framework for well-known URIs
-
URIs are located in /.well-known/{service}
- Solves discoverability issues
-
- IdPs domain name
- IdP's protocol to be used (like OAuth2)
- https://example.com/.well-known/oauth2?foo=bar
Each identity provider is associated with two values:
URI scheme
HTTPS only
IdP domain name
Authentication protocol
Signaling Server
Signaling Server
SIP
HTTPS
HTTPS
Browser
Browser
IdP1
IdP2
JS API
JS API
Alice
Per
Media
DTLS+SRTP
Get identity fingerprint
Verify identity based on fingerprint
- A user's browser authenticates other parties by accessing the well-known URI
- Her browser runs IdP's JS in a different security context (like a constrained iframe)
- feeds it with the parties claimed identity fingerprint
- IdP provides all the permitted user's information
- the authenticating party can setup privacy policies
- the other entities can decide whether the exposed information is enough to derive the identity
Authenticate another user using RFC 5785
The same endpoint is used for generating the fingerprint by the authenticating party
Call notifications
Not everyone is in front of her computer/browser :)
We need a way to notify the callee that someone wants to establish a call with her
SRV domain record ?
_service._proto.name. TTL class SRV priority weight port target.
Very powerful
hostname IN A ip-address time-to-live
for reference, an A record signature:
Call notifications
Unfortunately SRV is great for machines
problematic for humans
Privacy issues !
Security issues as well
The callee should expose her IP only when she is ready to answer the call.
Signaling Server
Signaling Server
SIP
Browser
Alice
Per's phone
Push Notifications
HTTP
TCP
Call notifications
Filtering service
Contacts (identities/ips) whitelist/blacklist
Block based on Per's preferences or status (busy)
Thank you!
Questions ?