SECURITY AND IDENTITY MANAGEMENT ON WEBRTC

Agenda

1. Introduction into WebRTC security- VoIP attacks- WebRTC vulnerabilities- Protection- Identity Management

2.WebRTC, IMS, Security and Identities

Víctor Pascual@victorpascual

Antón Román@antonroman

Introduction into WebRTC security

WebRTC. Features

Open system, no proprietary implementations

¡No plugins!

Multi-platform...

WebRTC. Features.

Multidevice:

○ Desktop and laptops○ Tablets and notebooks○ Smartphones○ Set-Top-Boxes and WebTVs

WebRTC. Use cases.

More information about use cases available here:

Corporate:

○ Audio webclients for IMS, NGN, MS Lync, Cisco, etc. ○ Video webclients for conference bridges○ Click to call (click to video/chat) solutions○ Contact center solutions

Residential:

○ OTT services○ Audio webclients for residential users○ Webchats○ Vertical applications (e-health,...)○ Extended RCS/Joyn services○ Online videogames

WebRTC. Architecture.

New elements introduced in the UC networks requires new considerations in terms of security:

○ Web Server○ WebRTC gateway○ Laptop/desktop used as endpoint

Efforts in WebRTC security.

RFC Draft: Security considerations for RTC-Web

WebRTC inherits part of the potential VoIP attacks and adds new threads:

○ New network elements to be hijacked, etc. ○ Open communications (new open ports, etc.)○ Privacy issues through access to microphones and cams.

VoIP attacks

VoIP attacks. Introduction.

Types of VoIP attacks:

1. Denial of service2. Fraud3. Illegal interception4. Illegal control

A VoIP attack causes an immediate economic damage for the attacked entity and a direct economic profit to the attacker. This does not occur with other type of attacks.

VoIP security

VoIP attacks. Denial of service.

The aim of an attack of DoS is to degrade the quality of the service that perceives the user by means of the massive delivery of messages that require of the use of resources (CPU, BW or memory) in the attacked system.

Examples: flood of register requests or calls in a softswitch that can pretend:■ A simple failure of the service.■ Attack for telephone fraud.

Also other "non intentional" attacks should be taking into account:■ flood after a power blackout.■ Bugs in terminals.■ Viruses.

VoIP attacks. Fraud.

An attacker registers in the system with a valid user (discovers the password, alters an IP, etc.) with the aim to do calls to international numbers. CFCA estimates 40 Billions USD annually.

They are not only calls through the network. Sometimes the attacker obtains remote access to a SIP proxy or softswitch that can use to originate illegal calls by console.

● These attacks cause not only economic losses. Sometimes the legitimate user has to pay the bill!!

● In most cases, it's difficult to determine the responsibility (customer or operator) of the attacks.

VoIP attacks. Illegal interception.

Because of the IP nature is simpler to capture signalling and media traffic by potential attackers to obtain information (audio of the call, other information of the call exchanged, etc.)

As traditional VoIP SIP traffic is opened, this is more dangerous in Wi-Fi networks where traffic is not ciphered.

WebRTC uses ciphered traffic for signalling and media, so interception could only be done in the endpoints or media gateway.

VoIP attacks. Illegal control.

If an attacker achieves the credenciales of an user or an administrator, he has absolute control:

● Can be used to do calls with high costs: causing losses to the service provider and/or end customer.

● Hijacked lines can be used to finish calls of other customers to which the attacker sells services

● For illegal activities, makes more difficult the judicial follow-up of the calls.

WebRTC vulnerabilities

Access to devices. Threats

HTML and JS script are executed by the browser as a "sandbox" designed to be isolated from the rest of the computer. However bugs may exist.

WebRTC API needs to access physical devices which will provide real-time media information (and files):

THREAT: Web pages access to user's camera and microphone without permissions.

Access to devices. Threats

MaliciousWebSever

Users can potentially being recorded with Javascript code downloaded from a malicious Web Server.

Malicious Script

SRTP

Access to screen capture. Threats

MaliciousWebSever

SRTP

Malicious Script

Security in screen sharing is specially critical as very sensitive information can be stolen.

Websocket.

Websocket (RFC6445): provides a full-duplex socket between a browser and a server.

It is just a TCP socket upgraded from an HTTP handshake.

Standardized way for the server to send content to the browser without being solicited by the client.

Image from http://blog.kaazing.com Image from: http://stackoverflow.com

Websocket DoS. Threats

Browser N

Attacked Server

websocket

MaliciousWebSever

Websocket allows cross-origin connection. DDoS attacks can be implemented in a Web-oriented way.

Browser 1

websocket

httphttp

Malicious Script

Malicious Script

Websocket cross-protocol attack. Threats

ebsocket

A malicious script could potentially inject code which is valid in HTTP poisoning HTTP intermediaries (i.e. HTTP proxy). This is avoided natively by WS RFC.

http://tools.ietf.org/agenda/80/slides/hybi-2.pdf

Signaling sent over not TLS connection.

By default it implements digest authentication, however it has a number of disadvantages:

● Several security options (like 'qop' for integrity) are optional.

● Vulnerable to man-in-the-middle attacks.

Sending the messages in plain-text is not a good idea, it can be authenticated but not privacy and integrity.

Signaling traffic can be sent over Websocket: data is sent over a TCP socket without any encryption. Equivalent to SIP over UDP/TCP.

Sending all the signaling over TLS is a must!

Security of TURN server.

TURN is necessary in many WebRTC scenarios to establish bi-directional flows.

Media relaying is an expensive resource so it is protected with credentials.

Those credentials can be long-term, if these credentials are stolen the TURN server can be abused.

Security in Click-to-call solutions

● Click to call solutions are potentially easy to be attacked.

● The WebRTC Click2Call solution server must implement mechanism to make sure the user is calling from a trusted site and limit the amount of calls from one location.

● Controlling the total amount of calls also will help to minimize DDoS.

Web Visitor

Contact Center

Protection

Signaling over TLS.

SIP traffic can be sent over Secure Websocket: data is sent over a TLS socket. Equivalent to SIP over TLS.

TLS provides privacy, integrity and authentication.

It also provides server authentication, and client authentication if a client certificate is provided. If the client certificate is signed by a Trusted Certification Authority (CA) the real-time communication can have legal value. Using, HTTPS and WSS is necessary when working with WebRTC. For example: Screen sharing only works from HTTPS sites!

Access to devices.

WebRTC standard requires that access to device to be notified to the user.

Browser notifies the user that a tab is currently accessing media devices. With a blinking red spot In Chrome.

Access to devices.

Showing own video to the user helps to be aware that the browser is accessing cam and micro.

The browser stores the permissions settings for HTTPS sites which valid certificates.

Access to devices.

Screen capture requires to type of permissions:

2. Always active user content

1. Elevated permissions (in practice means installing a plugin once)

Websocket poisoning.

websocket

http://tools.ietf.org/agenda/80/slides/hybi-2.pdf

Browser Server<Websocket opening handshake string>

*u0!GDDD&GIO[[[ONx<[&BM#>;:$MMGGDDDF4xOFDA@E6XU7$&UU<'U<!4U6UY&0OY X$%CIOCBM#HNXDWBK69E

SIP/2.0 200 OKVia: SIP/2.0/WS NO72tU858jVE.invalid;branch=z9hG4bKFhlN824OuTkQrgQl7FD8t1ejvP080E;rport=48095;received=46.25.57.69

Browser-To-ServerServer-To-Browser

DDoS.

DoS and DDoS protections are pretty similar to the implemented in Web Servers. Attacks can be potentially be launched from thousands of browsers.

Signaling is going to be received via TCP/TLS: WS, WSS, REST APIs, etc

Typical attack vectors (SYN flood, RESET attack etc) must be stopped as soon as possible to limit resources exhaustion which causes a denial of service.

WebRTC Gateways/servers normally will be exposed in Internet listening on well-known ports (443 and 80).

DTLS-SRTP for media encryption

DTLS-SRTP manage the SRTP key exchange within the RTP flow before starting media. This is done using DTLS, a version of TLS based on datagrams.

Keys are not exchanged in the SDP protocol. It protects the RTP flow even if signaling is not encrypted.

It is mandatory for A fingerprint is included in the SDP to create a security relationship between the SDP and the DTLS-SRTP flows.

ICE.

ICE(RFC5245) allows RTP flows to traverse NAT routers. It finds the best path for RTP/RTCP traffic.

STUN is used to find out the paths to send the RTP flow.

ICE, includes a handshake designed to verify that the receiving element wishes to receive traffic from the sender.

This identifier/password are created by the browser and used during the ICE negotiation.

Monitoring.

It is important monitor all the traffic the same way it is done with SIP traffic.

It is possible to gather even more information for WebRTC sessions:

● IP geolocation.● Host URL.● Browser info.● Contextual info.

ID management

Identity management.

WebRTC does not force any authentication method.

WebRTC API exposes an authentication API based on Identity Providers which can be:

● Ad-hoc solutions

● Social networks

● Certification Authorities (private or public)

● Telco authentication

IdP protocols: OpenID or BrowserID, Federated Google Login, Facebook Connect, OAuth, WebFinger

Identity management. OpenID

Makes possible to be sure of the identity using a thirdparty

New opportunity for operators as Identity Providers: Mobile number as Trusted Identity

Identity management.

+----------------+ | | | Signaling | | Server | | | +----------------+ ^ ^ / \ HTTPS / \ HTTPS / \ / \ v v JS API JS API +-----------+ +-----------+ | | Media | | Alice | Browser |<---------->| Browser | Bob | | (DTLS+SRTP)| | +-----------+ +-----------+ ^ ^--+ +--^ ^ | | | | v | | v +-----------+ | | +-----------+ | |<--------+ | | | IdP1 | | | IdP2 | | | +------->| | +-----------+ +-----------+

WebRTC API defined by W3C

Alice and Bob have relationships with some Identity Provider (IdP) that supports a protocol such as OpenID or BrowserID, Federated Google Login, Facebook Connect, OAuth, WebFinger) that can be used to demonstrate their identity to other parties.

Identity management.

+--------------------------------------+ | Browser | | | | +----------------------------------+ | | | https://calling-site.example.com | | | | | | | | Calling JS Code | | | | ^ | | | +---------------|------------------+ | | | API Calls | | v | | PeerConnection | | ^ | | | MessageChannel | | +-----------|-------------+ | +---------------+ | | v | | | | | | IdP Proxy |<-------->| Identity | | | | | | Provider | | | https://idp.example.org | | | | | +-------------------------+ | +---------------+ | | +--------------------------------------+

v=0o=- 1181923068 1181923196 IN IP4 ua1.example.coms=example1c=IN IP4 ua1.example.coma=setup:actpassa=fingerprint: SHA-1 \4A:AD:B9:B1:3F:82:18:3B:54:02:12:DF:3E:5D:49:6B:19:E5:7C:ABa=identity: \ImlkcCI6eyJkb21haW4iOiAiZXhhbXBsZS5vcmciLCAicHJvdG9jb2wiOiAiYm9n \dXMifSwiYXNzZXJ0aW9uIjpcIntcImlkZW50aXR5XCI6XCJib2JAZXhhbXBsZS5v \cmdcIixcImNvbnRlbnRzXCI6XCJhYmNkZWZnaGlqa2xtbm9wcXJzdHV2d3l6XCIs \XCJzaWduYXR1cmVcIjpcIjAxMDIwMzA0MDUwNlwifSJ9Cg==t=0 0m=audio 6056 RTP/SAVP 0a=sendrecv

WebRTC API defined by W3C

Identity management.

Adds a second factor of authentications because we validate the device (smartphone or PC) and the credentials are introduced ciphered in a SIP signalling packet.

Certification Authority

Certificate verification

Example of Identity Management

WebRTC, IMS, Security and Identities

WebRTC access to IMS

WebRTC access to IMS

Reference Model

WebRTC IMS Client (WIC)P-CSCF enhanced for WebRTC (eP-CSCF)IMS-AGW enhanced for WebRTC (eIMS-AGW)WebRTC Web Server Function (WWSF)WebRTC Authorization Function (WAF)

Registration and authentication

SIP/IMS vs Web Authentication

WebRTC is signaling agnostic, SIPoWS is just one option

SIP can be used with Web Authentication

IMS can be used with Web Authentication

Authentication of WebRTC IMS Client with IMS subscription using web credentials

Control plane security

Media plane security

Media security for RTP

Media Security for WebRTC DataChannels

NAT traversal

In order to traverse restrictive-firewalls one could also use TCP/TLS transport. Some, are even multiplexing that over HTTP-based connections

Firewall and HTTP proxy traversal

Additional Considerations

Specs perspective

How is it really deployed in the real world?

other existing systems

Experience from 100+ field trials/POCs

Customer Use Case: Service Provider in CALA

Customer Use Case: Service Provider in EMEA

Customer Use Case: Service Provider in APAC

Summary

What we have learned today

● Legacy VoIP attacks could also be important in WebRTC.

● WebRTC provides security by default (mandatory encryption, access permissions, etc).

● Care should be paid to Authentication and Identity Management

Planning to be in Barcelona during MWC15?

Quobis' booth (#CS60, Spanish Pavilion) will showcase "Sippo WebRTC Application Controller" to service providers and network equipment vendors, showing them how to introduce new value-added WebRTC services to their residential and corporate customers, hiding the complexity behind the different implementation of the standards by web browsers and gateway vendors and providing a complete set of APIs to manage AAA, user provisioning, contact management, policy control and other features.

mwc@quobis.com

Planning to be in Barcelona during MWC15?

Register today for this free event at http://www.meetup.com/WebRTC-Barcelona