Network Working Group R. Copeland, Ed. Internet-Draft Institut Mines Telecom-Telecom Sud Paris Intended status: Informational K. Corre Expires: March 30, 2017 Orange Labs I. Friese Deutsche Telekom AG S. El Jaouhari Institut Mines Telecom-Telecom Bretagne September 26, 2016 Requirements for Trust and Privacy in WebRTC Peer-to-peer Authentication draft-copeland-rtcweb-p2p-idp-auth-00 Abstract This document studies the relationships of WebRTC communication users with their web Calling Services (CS) and their Identity Providers (IdPs), in order to identify requirements for IdP based peer-to-peer authentication. This study focuses in particular on issues of privacy, security and trust that are raised by the introduction of the IdP into the WebRTC call model, and by a different browser-based calling paradigm, compared with Mobile networks or traditional VoIP systems. The document lists privacy and trust scenarios for WebRTC authentication for individuals as well as organizations. This contribution is proposed to the RTCWEB working group. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 30, 2017. Copeland, et al. Expires March 30, 2017 [Page 1] Internet-Draft Requirements in WebRTC Authentication September 2016 Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Call Context Aspects . . . . . . . . . . . . . . . . . . . . 6 3.1. Existing Protocols and Drafts . . . . . . . . . . . . . . 6 3.2. WebRTC Architecture Components . . . . . . . . . . . . . 7 3.3. WebRTC Call Models . . . . . . . . . . . . . . . . . . . 7 3.3.1. Single-CS Call Model . . . . . . . . . . . . . . . . 7 3.3.2. Dual-CS Call Model . . . . . . . . . . . . . . . . . 7 3.4. Service Types and their Trust Models . . . . . . . . . . 9 3.5. Destination Categories . . . . . . . . . . . . . . . . . 10 4. Architecture Vulnerabilities . . . . . . . . . . . . . . . . 10 4.1. Untrusted Parties . . . . . . . . . . . . . . . . . . . . 10 4.2. Network Messages Across Multiple Parties . . . . . . . . 10 4.3. Confidentiality of Call Logs . . . . . . . . . . . . . . 11 4.4. Dependency of Identifiers . . . . . . . . . . . . . . . . 12 4.5. IdP Selection Issues . . . . . . . . . . . . . . . . . . 12 5. Identity Privacy . . . . . . . . . . . . . . . . . . . . . . 12 5.1. Desirable and Undesirable Identity Privacy . . . . . . . 13 5.2. Undetectable Calling . . . . . . . . . . . . . . . . . . 13 5.3. Pseudonymous Calling . . . . . . . . . . . . . . . . . . 13 5.4. Unlinkable Calling . . . . . . . . . . . . . . . . . . . 14 5.5. Potential Methods of Identity Protection . . . . . . . . 14 5.5.1. Sensitive User Information . . . . . . . . . . . . . 14 5.5.2. Proposed Surrogated identities with Pseudonyms . . . 14 6. Trust Relationships . . . . . . . . . . . . . . . . . . . . . 15 6.1. Three-Way Trust: User-CSP-IdP . . . . . . . . . . . . . . 15 6.2. Choice Indicates Trust . . . . . . . . . . . . . . . . . 16 6.3. User trust in Calling Services . . . . . . . . . . . . . 16 6.4. User trust in Identity Providers . . . . . . . . . . . . 17 6.5. Communication Service trust in Identity Providers . . . . 17 6.6. Trusted Identities for non-Browser Interworking . . . . . 18 Copeland, et al. Expires March 30, 2017 [Page 2] Internet-Draft Requirements in WebRTC Authentication September 2016 7. Use Cases for Privacy Requirements . . . . . . . . . . . . . 18 7.1. Anonymous Caller Connecting to Call-Centers . . . . . . . 18 7.2. Call Center Worker's Privacy . . . . . . . . . . . . . . 19 7.3. Online Gaming Calling by Pseudonyms . . . . . . . . . . . 19 7.4. Hosted Enterprise WebRTC Conferencing Service . . . . . . 20 7.5. Variable Trust modes for Employee's Calls . . . . . . . . 20 7.6. Employee using untrusted WebRTC service . . . . . . . . . 20 7.7. WebRTC service Interworking with SIP users . . . . . . . 21 8. Requirements Summary . . . . . . . . . . . . . . . . . . . . 21 8.1. Anonymity . . . . . . . . . . . . . . . . . . . . . . . . 21 8.2. Unlinkability . . . . . . . . . . . . . . . . . . . . . . 22 8.3. Independent IdP . . . . . . . . . . . . . . . . . . . . . 22 8.4. User Information Confidentiality . . . . . . . . . . . . 23 8.5. Calling Services . . . . . . . . . . . . . . . . . . . . 23 8.6. Usability and Notification . . . . . . . . . . . . . . . 23 9. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 24 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 24 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 12.1. Normative references . . . . . . . . . . . . . . . . . . 25 12.2. Informative references . . . . . . . . . . . . . . . . . 26 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 1. Introduction This study provides requirements for supporting identity privacy in peer-to-peer (P2P) WebRTC calling services. While the WebRTC specification aims to manage the media flow, it does not include procedures for call initiation and privacy setting. However, WebRTC architecture supports peer authentication that is performed separately from the calling service, decoupling user authentication from the granting of service resources. The authentication is performed by a third party Identity Provider (IdP), while service resources are granted by each Calling Services Provider (CSP). WebRTC calling creates a different paradigm from 'traditional' VoIP services or Telecom, because it is browser-based. All that is needed for a website to support WebRTC calling is to download a client to the device to access the user-agent JavaScript APIs. This simplicity will encourage many websites to add calling facilities to their 'shop-window'. In turn, such easy click-to-link services will entice occasional website visitors to initiate 'opportunistic' calls, often using unknown, maybe untrusted calling services, giving little thought to the risk of leaking personal information. Hence, this paradigm increases risks of abuse of user data, identity theft and commercial exploitation. This necessitates establishing appropriate privacy protection, even without user explicit input of preferences. It is possible to achieve this by attaching privacy rules to the Copeland, et al. Expires March 30, 2017 [Page 3] Internet-Draft Requirements in WebRTC Authentication September 2016 IdP's maintained user identity, so that the IdP will support anonymity where required. An independent identity should prevent the undesirable lock-in effect of 'service-bound' identities and allow for a single identity, with its linked pseudonyms identifiers (with same credentials), to be used instead of numerous identifiers and separate passwords. Users should be able to specify particular privacy rules that are applied during authentication across all services, or for a particular service type, since the privacy rules are attached to the identifier, not to the service. The current peer authentication procedure provides some flexibility for the choice of IdP, but does not allow users to determine privacy requirements for different circumstances. There are no means of evaluating trust models and required privacy between calling parties, their CSs and IdPs. The call model (single or dual CS model) affects the level of trust in the other parties. Users may trust their chosen IdPs and CS, but the same cannot be assumed for CS and IdPs of their communication partners. The service type and the means of activating it also influence the trust level, e.g. a social media contact may be more trusted than a call to an unknown website. Similarly, the type of destination (e.g. public organizations versus unfamiliar websites) also impacts the trust level. Such destinations have their own privacy requirements that need to be negotiated, e.g. callers' traceability may be mandated in order to avoid nuisance calls, but at the same time, unlinkability is required for employees when they respond to public enquiries. The accumulated record of calls is a precious commodity in the monetized web space, but many users wish to exercise better control of what is divulged. To solve this, it is argued that by using context-based privacy to obscure certain details or to present surrogate identities, the calling service logs will contain only filtered information, in accordance with users' wishes. Hence, this study proposes requirements for user-controlled, multi- purpose, identity, with service-independent authentication by IdPs, which is protected not only by preferences and negotiated privacy rules, but also by detected context-based privacy settings. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119] Copeland, et al. Expires March 30, 2017 [Page 4] Internet-Draft Requirements in WebRTC Authentication September 2016 Privacy and data minimization terms, such as Anonymity, Unlinkability, Undetectability, and Pseudonymity, follow the definitions by Pfitzmann et al. [TerminologyForPrivacy], but refer to inter-party interactions, not user-to-server, where the 'sender' (Caller) and the Destination (called party) are separate entities from their own services and endpoint clients. Table 1 contains further terms that convey a particular meaning or an extension meaning in this document. Terms Definitions +----------------+--------------------------------------------------+ | Term | Description | +----------------+--------------------------------------------------+ | Called-party, | A target destination, as nominated by the | | Destination or | caller, who is an individual called party, an | | Callee | organization representative or an intelligent | | | object, with a WebRTC valid identity. | | Caller or | An individual, an organization representative or | | Sender | an intelligent object with a valid identity who | | | is initiating a WebRTC call or session by using | | | a WebRTC-enabled browser. | | Calling | The WebRTC based service that is used to connect | | Service (CS) | calling parties. This service may provide | | | calling features and group calling management, | | | as well as users' preferences and group privacy | | | policies. A CS is assumed to be server-side | | | software from a CS Provider, with clients | | | downloaded to the users' endpoints. | | IdP (Identity | IdP (Identity Provider) creates, maintains, and | | provider) | manages identity information for entities | | | (users, services, or systems) and provides | | | authentication to other service providers. It | | | is a trusted third party that can be relied upon | | | by users and servers when they establish a | | | dialog that must be authenticated. | | IdP Proxy | A client (user agent) constructed by each IdP | | | for its own operation, and is downloaded to | | | users' endpoints when they wish to verify a | | | given 'assertion' for a user. | | Unlinkability | While the definition in [TerminologyForPrivacy] | | or | refers to unlinkability of subject to a message | | Untraceability | or a particular attribute, in this document it | | | is defined as the inability to link calling | | | parties to their routable address for calling | | | back. | | Privacy Rules | Rules containing parameters for service delivery | | | that are compiled from preferences of the | Copeland, et al. Expires March 30, 2017 [Page 5] Internet-Draft Requirements in WebRTC Authentication September 2016 | | involved individuals, groups, or institutions, | | | to determine when, how, and to what extent | | | information is divulged. | | Surrogated | Identities that identify a real person uniquely | | Identities | through their association with a universal | | | unique surrogate key (a database indexing key | | | that is system-generated as an artificial | | | primary key value, independent of any | | | attribute). Such identities need not have their | | | own credentials, and can use either meaningful | | | pseudonyms or meaningless (anonymous) | | | identifiers. | +----------------+--------------------------------------------------+ Table 1 3. Call Context Aspects This section describes the dependency of privacy settings on the call model (single/dual CS), service type and destination category, in the light of the P2P authentication procedure. 3.1. Existing Protocols and Drafts WebRTC calls connect two browsers that are exchanging media and data, as presented in the "WebRTC Overview" [I-D.ietf-rtcweb-overview]. Prior to the media connection, the calling parties may authenticate each other, in a possibly reciprocal peer-to-peer authentication process, as described in "WebRTC Security Architecture" [I-D.ietf-rtcweb-security-arch]. The RFC "Privacy Considerations for Internet Protocols" [RFC6973] offers guidance for privacy considerations in Internet protocols. This RFC identifies privacy threats and threat mitigation solutions which includes data minimization. The Internet draft "Security Considerations" [I-D.ietf-rtcweb-security] for WebRTC identifies two threats to privacy in WebRTC. These are the correlation of anonymous calls through persistent identifiers such as DTLS certificates, or the risk of browser fingerprinting through the WebRTC API itself. Examples of WebRTC binding to specific identity protocols are given in "WebRTC Security Architecture", such as OAuth 2.0 [RFC6749] (or OpenID Connect [OIDC] ). However, these protocols do not address privacy and identity management for peer-to-peer authentication. Copeland, et al. Expires March 30, 2017 [Page 6] Internet-Draft Requirements in WebRTC Authentication September 2016 3.2. WebRTC Architecture Components Current WebRTC communications rely on standard browser APIs (getUserMedia) that execute at both endpoints to enable media streaming, and WebRTC APIs (RTCPeerConnection and RTCDatachannel) that execute at the endpoints to manage the flow. The endpoints also execute a CS client, which drives the initial call setup. To enable decoupling of the CS from the identity authentication process, WebRTC security architecture [I-D.ietf-rtcweb-security-arch] proposes that the WebRTC PeerConnection component interacts directly with the IdP, to initiate and manage the authentication process. It negotiates Session Description Protocol (SDP) with the other party by sending an SDP offer and accepting, rejecting or offering a counter offer. Both parties set up their own PeerConnection instances and download an IdP proxy from their own IdP. Each IdP authenticates its user's and returns an identity assertion containing the identity and session key fingerprint as claims. When a party receives an SDP offer or answer containing an identity assertion, that party also downloads the IdP proxy from the other party's IdP. This proxy is then used to verify the received identity assertion. Each IdP Proxy only connects to its own IdP server. This architecture is presented in Figure 1. 3.3. WebRTC Call Models 3.3.1. Single-CS Call Model In a single-CS model, which is the dominant model in the current Internet Voice services, only one calling service is involved, where both the caller and the called party are registered to the same service. The service manages the subscribing users' privacy policy via a set of options, which are then reconciled for the call. These services utilize 'service-bound' identities, where users must log on with the service-specific credentials. By contrast, the WebRTC Single-CS call model permits users to select their own identities, and perform user-to-user mutual authentication, even though both users are logged on to the same service. 3.3.2. Dual-CS Call Model While early implementations of WebRTC calling between individuals go no further than the single-CS model, it is expected that the dual-CS model will become more common if WebRTC services are adopted in business, especially for small-to-medium enterprises. In dual-CS model, the calling parties log on to two different CSs, with their own sets of privacy rules and security policies, so CSs must discover Copeland, et al. Expires March 30, 2017 [Page 7] Internet-Draft Requirements in WebRTC Authentication September 2016 the respective privacy/security requirements and negotiate an acceptable set of rules for both parties per session. Figure 1 shows the calling parties (A and B) using different services (CS-A and CS-B) and different IdPs (IdP-1 and IdP-2). It shows the mutual P2P authentication that is performed by each side symmetrically. A gets its own identity assertion from IdP-1 and verifies B via a downloaded IdP-2 proxy. B gets its own assertion from IdP-2 and verifies A by the downloaded IdP-1 proxy. Each proxy runs in its own sandbox to protect it from interference. The mechanism for interaction between calling Services can be, for example, SIP or XMPP. +----------+ +----------+ | Caller's |Unspecified| Called | +----------+ | Service | Protocol | Service | +----------+ | IdP-1 | | CS-A |<--------->| CS-B | | IdP-2 | | | | (caller) |(SIP, | (callee) | | | +-v------^-+ +-----^----+ XMPP,...)+-------^--+ +--^-----v-+ | | / \ | | | | / \ | | | | / \ | | | +----|----------------+ +-----------------|---+ | | | | | Media | | | | | | | Browser A |<----------->| Browser B | | | | | +-------+ +-------+ | | +-------+ +-------+ | | | | | IdP-1 | | IdP-2 | | | | IdP-1 | | IdP-2 | | | | | | Proxy | | Proxy | | | | Proxy | | Proxy | | | | | |sandbox| |sandbox| | | |sandbox| |sandbox| | | | | +-------+ +---^---+ | | +----^--+ +-------+ | | | +---------------|-----+ +------|--------------+ | | | | | | | | | +-----------------|--------------------------+ | B verifies A | | +-------------------------------------------+ A Verifies B Figure 1: Dual CS Calling Model Calling parties may connect to unknown parties who are using unfamiliar services across the globe, and are authenticated by IdPs that the caller may not know or even be aware of. In such cases, many users would prefer to prevent unnecessary data disclosure. Copeland, et al. Expires March 30, 2017 [Page 8] Internet-Draft Requirements in WebRTC Authentication September 2016 3.4. Service Types and their Trust Models In order to understand the privacy requirements for WebRTC architecture, it is important to classify calling services by the manner of initiating the sessions, choosing destinations (called parties), and consulting the other party CS. The following is a classification of web calling service types that may have varying privacy requirements, due to different trust models: a. Contact-List-Service: The service enables users to maintain their contact list, and make or receive calls from them. This service type is used by social media, VoIP OTT, and internal enterprise call servers. b. Click-to-Link Service: Browsing users activate this service type when they click on a website link to talk to anyone at that destination, not to an individual person. The 'linked' party in the visited website uses its own CS in a single-CS call model. This service type is common for shopping websites and customers' enquiries, which today are mostly chat services only. The caller may not trust such services, and users often wish for anonymity to be preserved. On the other hand, unlinkability is often required for the responding individuals at the website. c. Negotiated Service: This type of service, which is common for business-to-business, allows both calling parties to have their own privacy rules. In a single-CS call model, the service reconciles the differences, but in a dual-CS call model, the calling services should conduct a dialogue resulting in negotiated privacy rules per call. d. Interworking Service: WebRTC calling services should enable connecting to other types of services, using temporary or 'interworking' special identities. This service type is used, for example, for interworking with SIP servers and telephony. Although users cannot authenticate each other, the interworking depends on one-sided IdP authentication. e. Conferencing Multi-Party Service: Services that connect several parties in one call need different mechanisms to mix the media, such as a bridge, router/mixer or a matrix, but they also need to reconcile privacy needs of several parties. This is often a single-CS service between subscribing participants, but it may also support multiple calling services, where each call leg is managed by the caller's own CS. Peer authentication could still be performed between the conferencing shared identity and each participant. Copeland, et al. Expires March 30, 2017 [Page 9] Internet-Draft Requirements in WebRTC Authentication September 2016 These service types influence the required privacy, since they are correlated to particular trust models, e.g. contact-List calling permits full information exchange, but Clink-to-Link sets the strictest privacy level. 3.5. Destination Categories The destination category influences the level of security and privacy that the calling parties require. The destination may be an untrusted web site in click-to-link service type that users prefer to connect while preserving anonymity and/or unlinkability, but such a destination may also be a completely trusted, often used website. Businesses often wish to apply different confidentiality rules for internal or external calls, i.e. distinguishing between classes of destinations. Hence, privacy rules should be determined per destination category, by: the addressing mode (click-to-link or contact list); the domain (government etc.); or previously logged calls. In the absence of explicit user preference, context-based privacy level can be set by the CS according to the destination category. The IdP can also perform such a service, based on the call log and the target domain names. 4. Architecture Vulnerabilities This section considers the new paradigm that webRTC creates, which gives rise to different trust models between the parties and other stakeholders. 4.1. Untrusted Parties The decoupling of the authentication from the service logic, both in networked functions and in business entities, increases vulnerability, but also the variety of trust models that are needed to support permissive and intuitive web calling patterns. This environment encourages users to take more risks and launch interactions without careful considerations of the information that may leak to various parties. In additions, not only a casually invoked service may receive user data, but also the IdP and the CS of the other party, who may not be trusted. 4.2. Network Messages Across Multiple Parties WebRTC architecture relies on the IdP to perform the authentication independently from the call initiation process. This entails further network based interactions and more parties gaining knowledge of them. The additional network messaging between more parties increase the risk of Man-in-the-Middle (MITM) attacks. The number of involved parties in person-to-person calls rises in peer authentication, Copeland, et al. Expires March 30, 2017 [Page 10] Internet-Draft Requirements in WebRTC Authentication September 2016 depending on the call model. A single-CS call model with service- bound identification involves only one CS with two parties. In the dual-CS call model with independent IdPs, there are two calling parties, two service providers and two IdPs, i.e. double the number of involved parties. This increases the risk of leaking information and abuse of call history, as well as MitM attacks. 4.3. Confidentiality of Call Logs Currently, both IdPs and calling services acquire user knowledge, which is a) contextual; b) historical; and c) subscription-based. This information can be static (user personal details, additional email identities) or dynamic (calling patterns, frequent destinations, preferred services/websites, and more). Every time a new call is set up, the exchanged information can provide means of tracking user activity or linking back to the parties. The accumulation of such information reveals trends, habits, preferences and behavior patterns that are highly valuable to traders and marketeers. Exploiting this data is often the only monetization methods available to web service providers, but it is a cause for concern for users who regard it as compromised privacy. The IdP gains knowledge of personal details (to enhance user profile), and associated identities (to enhance identity resilience), which users may be reluctant to share with numerous websites. In addition, the IdP can log authentication requests of every CS using its identity service, while the CS only has visibility of calls made to and from that service. Since users' calling activities are now spread over a number of web communications services, an IdP will have wider perspective on the user's intelligence. IdP is not able to know much about the involved CS, as the Peer- Connection method interfaces between the endpoint's client and the IdP Proxy directly, not via a CSP server. On the other hand, the CS has better understanding of the call context in the preamble before initiating a call request. As the IdP Proxies are deployed on both calling parties'devices, the IdPs can log identity verification requests for incoming as well as outgoing calls. It may be possible for an IdP to track call history for a particular destination user who is using another IdP, even if an pseudonymous identity is given, and perhaps eventually link the records with the real identity. However, this risk only arises with habitual pseudonymous calling to the same destination. Copeland, et al. Expires March 30, 2017 [Page 11] Internet-Draft Requirements in WebRTC Authentication September 2016 4.4. Dependency of Identifiers The aim of providing completely independent and portable identities is not easy to achieve. While the IdP-generated identity (with an IdP domain) is not related to any specific calling service, i.e. portable between services, it is still dependent on the IdP. If users wish to keep their well-known published identifiers when moving to another IdP, they need identities that ensure both CS and IdP independence. This requires users to use a global user identifier, such as a Universally Unique Identifier (UUID) [RFC4122] that would acts as a unifying key for all identities. This globally unique identifier could link several identifiers, both IdP-generated and CS- generated. 4.5. IdP Selection Issues In WebRTC, each CS client in the device is responsible for setting up the authentication requests for its own party. The CS client decides what form of authentication to apply, i.e. peer authentication, server-side Single Sign-On, or service-specific authentication. This means that the CS controls the selection process, and may restrict the choices of IdP to choose from, or even prevent an IdP to be involved. Current WebRTC specifications define two options for the CS to select an IdP for an identity assertion request: o If the setIdentityProvider() method has been called by the CS, the provided IdP will be used. o If the setIdentityProvider() method has NOT been called, the browser may use a pre-configured IdP. Pre-configuring an IdP via the browser means that yet another party - the browser vendor - is a stakeholder in the WebRTC call initiation. It is argued that currently, users do not have sufficient control on the selection of the IdP with these facilities. 5. Identity Privacy This section sheds a new light on the privacy requirements for undetectable, pseudonymous, and unlinkable callers that arise from the webRTC peer calling. Although these terms do exist, the associated privacy requirements have not been previously identified. Copeland, et al. Expires March 30, 2017 [Page 12] Internet-Draft Requirements in WebRTC Authentication September 2016 5.1. Desirable and Undesirable Identity Privacy Many websites may be content to receive enquiries from anonymous callers, because this may generate impulse-buying, so they only request user details before completing a transaction. Such websites also require some privacy rules themselves, to protect specific personnel serving at a call center. Web calling encourages opportunistic calling by users who are merely visiting the websites, where users identities are 'incognito', i.e. their status is 'undetectable' or 'unobservable'. In certain circumstances, calls from undetectable identities should always be supported, e.g. calls to emergency services that are passed through without any authentication. While undetectable status is passive, in other cases callers may specifically wish to withhold their personal details for a variety of legitimate reasons, e.g. to avoid revealing interests in sensitive material or avoid personal embarrassment. In such cases, users can choose to use assumed names (pseudonyms). Similarly, there are good reasons to support the requirement of unlinkability that prevents tracing back previous calls, e.g. to avoid traders chasing business. The contrasting requirements to prevent anonymity should also be considered, in order to prevent abuse, e.g. for nuisance calls or malicious disruption of service. The solution to block all callers who are not on the personal contact list may suffice for individual users, but this is too restrictive for a business. Therefore, since privacy protection is both desirable and undesirable depending on context and point of view, privacy rules need finer granularity, so that they can be applied judiciously, according to context and circumstances. Hence, the requirements are for WebRTC authentication to support different states of user privacy and anonymity: Undetectable (undisclosed identity), Pseudonymous (false or fictitious identity) or unlinkable (untraceable address/path). 5.2. Undetectable Calling Undetectable calling may be initiated without logging to any CS, while the user is unknown. When a call is made without logging to the CS, a call request may be processed without any authentication. 5.3. Pseudonymous Calling Pseudonymous calling means that the username identifier is replaced with an assumed name that hides the user's identity. The authentication can be performed by an IdP who is aware of the pseudonym owner. Hence, the other parties can be reassured that the identity is verified. Such authentication may not be sufficient for Copeland, et al. Expires March 30, 2017 [Page 13] Internet-Draft Requirements in WebRTC Authentication September 2016 monetized transaction and non-repudiation, but is considered acceptable for web calling. 5.4. Unlinkable Calling Unlinkability prevents other parties from calling back, or from tracing the user's cyber activities, such as visited websites and calling patterns. Unlinkable callers seek to hide the originating website or redirected services. Unlinkability is also both desirable and undesirable, depending on the context. Preventing linkability is often needed to protect individual employees who respond to enquiries from the public. Conversely, linkability is highly desirable by emergency and health services, to locate incapacitated callers in distress. 5.5. Potential Methods of Identity Protection 5.5.1. Sensitive User Information User information that may be subject to privacy includes: o Forename and last names, which are often incorporated in the username part of the identifier. o Domain name of associated organization, which often incorporates the organization name in the @domain part. o Message path and IP address, which are revealed in the SDP (Session Description Protocol). 5.5.2. Proposed Surrogated identities with Pseudonyms Using pseudonyms avoids undesirable disclosure of the identity and/or incidental private information. However, pseudonyms should still be associated by a common key to the real user. This is achieved by a fully independent identifier that acts as a 'surrogate' key, i.e. an indexing key that is not based on any meaningful personal details, as described in [SurrogateKeys] for indexing data. Such surrogate keys provide stability, because they are not affected by users changing circumstances (e.g. married names) and personal attributes (e.g. changing employer domain name). The surrogate key for identities is a Global User ID (GUID) that uniquely identifies a particular user. GUIDs can be generated by a number of known algorithms. They may inject user-specific variable attributes as 'salt' to the otherwise random number generator, to ensure uniqueness. It is proposed that this GUID/surrogate key will link the IdP-based identity, service-bound identities and pseudonym Copeland, et al. Expires March 30, 2017 [Page 14] Internet-Draft Requirements in WebRTC Authentication September 2016 identities, at the discretion of the user. All the linked identities (i.e. the 'surrogate identities') can share the same credentials that the IdP has verified. Service-bound identities from a variety of calling services that do have their own credentials (usually just passwords) can also link to the surrogate key, thus benefiting from deeper user verification and from the SSO effect that such arrangement brings. 6. Trust Relationships This section analyzes discernible trust models which are proposed as the basis of setting up appropriate privacy levels. 6.1. Three-Way Trust: User-CSP-IdP The current WebRTC security architecture only assumes that users trust their CSP, or that an IdP is used in P2P authentication if the CS is untrusted. Trust in the IdP is only considered regarding its verified, https origin. In this model, the browser constitutes the trust anchor. However, this simple trust model does not describe trust in the privacy context, nor the difference between a user's own IdP and the other IdP. Users need to trust other involved actors, i.e. CSs and IdPs, to manage their privacy and provide solid identity claims. The CS in turn may need to trust both IdPs regarding user authentication and identity claims. However, IdPs do not require particular trust relations with the CS, as they merely provide a service, without risk to themselves. Figure 2 and subsequent sections details this trust model. +---------+ +-------------------> CSP | | +---------+ +---------+ | | Alice | | +---------+ +-------+ | | | | | | +-------v-+ +--v------+ | +------------> IdP A | | IdP B | | +---------+ +-^-------+ | | +------------------------------+ Figure 2: Trust relationships between communication setup actors Copeland, et al. Expires March 30, 2017 [Page 15] Internet-Draft Requirements in WebRTC Authentication September 2016 6.2. Choice Indicates Trust The purpose of establishing trust is to make a decision in situations where an action with an inherent risk depends on informed judgement. Explicit choice can be interpreted as a measure of trust. Users' chosen IdPs are more trusted than mandated IdPs imposed by the communication services, though enterprise mandated IdPs are trusted by virtue of the enterprise selection. Similarly, calling services that are casually invoked by click-to-Link in a visited website are less trustworthy than those which the user has registered to. Trust is also assumed towards a call-party that is known to the user, but there is no implied trust level for the calling services and IdPs of that party. Trust may be associated with the type of the call destination, which can be categorized as: o Fully trusted parties (government, public organization, known business) o Inner-circle of a social network or family members o Uncertain (not-in-contact-list, no information) o Untrusted (known as unreliable). 6.3. User trust in Calling Services Traditionally, CSP had access to full user profile information and accumulated call history, but user habits now favor using different services according to context, so the CS has only their own usage records. While some CS may enjoy greater trust, in other cases, users do not wish to share or even store their call history. These preferences are usually agreed when users register with the CS, but it is up to the CS to respect them. Since the CS manages the call signaling, it is well placed to intercept the peer-to-peer media stream that otherwise is deemed private. Even if the caller's CS can be trusted not to do so, the CS of the other party is not so well trusted. Trust in the CS also varies between single-CS and dual-CS Call Model. In a single-CS call model both parties use the same service to communicate, however this does not guarantee that they have the same trust models and the same privacy requirements. In a dual-CS call model, the other party's CS merits even less trust, as it may not even be known (depending on user-interface implementations). Hence, variable precautions and privacy negotiations are necessary according to the context and the involved parties. In cases where the CS is untrusted, enforcing authentication by an independent IdP ensures that the exchange of Copeland, et al. Expires March 30, 2017 [Page 16] Internet-Draft Requirements in WebRTC Authentication September 2016 media key is on a third-party path (the identity path) between the authenticated users. Therefore, the CS, who is not in control of this path, cannot mount a MitM attack. However, the CS, not the user, determines whether an IdP is to be used, and users have no means of ensuring that they are protected by the IdP authentication. 6.4. User trust in Identity Providers The IdP, more than the CS, is the custodian of user intelligence; hence it must have trust relationship with users that subscribe to its services. It is assumed that such services include storing and linking service-bound identities, to allow for flexible means of authentication of related identifiers. Using an IdP makes it easier for users to control privacy, since a single agreement with their chosen IdP is simpler than managing numerous web services, some of which are use only rarely. Users may have more than one IdP, perhaps different IdPs for special purposes, e.g. most commonly, a separate IdP from an employer. They may choose an IdP that they do not fully trust for private activities that they wish to keep separate. In such cases, the user can limit what personal details are disclosed to the IdP, but the IdP will still know of any authentication request to this identity. Trusting the IdP of the other party is a more difficult issue, since this IdP may not be even known. The P2P authentication procedure ensures that the IdP origin is not circumvented, but there are no ways of assessing the strength and veracity of the origin statement. Currently, called users have no way of controlling the downloading of an 'alien' IdP Proxy (of the other party) to their device, since this is performed automatically by the CS client at the behest of the caller. Hence, both IdP proxies are subject to the same sandbox restrictions, although they have different trust models. 6.5. Communication Service trust in Identity Providers The CS may rely on a third-party IdP to authenticate users when they log in, and link the given identity with its internal user account. In such cases, the CSP must trust the IdP regarding the authentication strength and the validity of the provided profile information. In most cases, the CSP provides a set of preferred IdPs for users to choose from, through SSO implementations on the website and usage of the setIdentityProvider function. However, users could also select an IdP, e.g. with OIDC discovery. In dual-CS call model, the CS could receive a SDP message containing an assertion from an unknown Copeland, et al. Expires March 30, 2017 [Page 17] Internet-Draft Requirements in WebRTC Authentication September 2016 IdP. The verification of the assertion could be performed using the browser's default IdP, with the CS only receiving a confirmation that the identity is authenticated. In these cases, the CS has only low trust level in the IdP, while IdPs that have been vetted by the CS are higly trusted. 6.6. Trusted Identities for non-Browser Interworking WebRTC browser-based calling services may need to communicate with users on non-browser services, including users of existing SIP servers. The interworking should not be only at the level of signaling and applications, but also at the authentication stage. For a mobile network, as specified in 3GPP TS 23.228, mutual authentication is not possible, but the WebRTC identities, which have been authenticated by an IdP or a CS, are linked to the allocated SIP identities. The 3GPP WebRTC-SIP Client at the device enables it to contact the local network proxy. 7. Use Cases for Privacy Requirements While [I-D.ietf-rtcweb-use-cases-and-requirements] provides use cases for webRTC media, in this study, use cases demonstrate the calling context scenarios that require different privacy settings, which enhance the examples in [I-D.cazeaux-rtcweb-oauth-identity]. 7.1. Anonymous Caller Connecting to Call-Centers Alice is surfing on websites of several insurance or healthcare companies and wants to discuss matters of some sensitivity. She clicks on links within these websites, in order to talk to their experts. Alice is concerned with her privacy and prefers to remain anonymous, especially towards her employer. Some websites treat her identity as undetectable, since she has not logged in to the service, but they allow such callers to visit. For websites that require authentication, she will use a pseudonym and authenticate to her personal IdP, to avoid her employer's IdP becoming aware of which websites she calls. This use case demonstrates a single-CS call model with the 'Link-to-Call' Service type. The privacy requirements demonstrates undetectability, pseudonymity and unlinkability for the caller. The alternative for Alice is to create unrelated identities for each website, but this is much more laborious. Using an independent IdP with surrogate pseudonyms, Alice can rely on the same credentials, while reassuring the destination websites that she is properly authenticated and is not making nuisance calls. Copeland, et al. Expires March 30, 2017 [Page 18] Internet-Draft Requirements in WebRTC Authentication September 2016 7.2. Call Center Worker's Privacy Bob is a member of a company's product support group, working in a customer support center. The company presents clickable icons on the website that connect visitors to the right expert. Bob answers Alice's call, but when Alice calls again, she cannot contact Bob directly, and her call is answered by another group member. This use case represents single-CS Click-to-Link service model from the called destination point of view. Once Alice indicates that she would like to talk, the called destination invokes its own calling service, so the roles are reversed: the destination is the caller and Alice becomes the called party. This enables the destination group members (Bob) to remain unlinkable vis-a-vis Alice. On the other hand, Alice is an undetectable identity, since she has not logged into the service, so her call request uses the browser default IdP to retrieve a surrogate pseudonym identity, but she is still traceable in terms of IP address and path. Hence, this example also shows that unlinkability is not necessarily attached to all other anonymity states, e.g. detectability. 7.3. Online Gaming Calling by Pseudonyms Alice is playing poker on a gaming website. Alice is a customer, with an account which the gaming business administrator has verified (e.g. via a credit card). Alice wishes to communicate with other players through a voice channel provided by the gaming facility. She is registered on the gaming site under her chosen pseudonym, which is all she wants to reveal to the other players. The calling service verifies the users and their accounts through a server-side IdP validation, so the identities with their pseudonyms are strictly service-bound. This use case demonstrates single-CS /Contact-List call model, where the calls are placed between two registered and logged-on users of the same service. The model is the same as traditional OTT VoIP, where the CS manages the users' identities. Callers and called-parties implicitly rely on the calling service to provide anonymity, where the anonymity set is determined by the number of players. It should be possible for the gaming CS to permit P2P authentication and independent IdPs, but the gaming host may still require authorization of user accounts (if money changes hands). The IdP authentication benefits the CS, since the IdP's identification is coupled with deeper user verification. Copeland, et al. Expires March 30, 2017 [Page 19] Internet-Draft Requirements in WebRTC Authentication September 2016 7.4. Hosted Enterprise WebRTC Conferencing Service Alice is working for a corporation that provides her with a comprehensive web-based communication suite of internal and external conferencing, which is hosted by a Service Provider. The conferencing Service Provider uses the mandatory corporate IdP to authenticate the employees. Alice calls Bob, who works for a partnering company, and is logged on to his own company's CS. Alice uses Bob's identity from his own CS, which is recorded in her contact list. Although Alice's company does not insist on confidentiality, Bob's company does, so Bob's calling service demands that all the conferencing participants use the security level that matches Bob's. This use case demonstrates dual-CS negotiated call model, where the parties have their own preferences determined by their respective organizations. The service providers need to agree on a common set of privacy rules. Although an IdP is mandated by Alice's organization, external calling parties may not have the same IdP, hence external callers should be authenticated in the mutual peer-to- peer authentication process. 7.5. Variable Trust modes for Employee's Calls Employees can have different requirements of privacy depending on type of calls and types of destinations. Alice is a Sales representative calling Bob (a potential customer), to conduct a consumer survey and she wishes to remain untraceable (unlinkable) and unrecognised (pseudonymous). However, when she calls her colleague, Charlie, to discuss invoices, she would like Charlie to call her back. Thus, Alice needs unlinkability when calling Bob, but full linkability when calling Charlie. This use case shows privacy decision by context, according to destination type. Rules may be defined per class of destinations (e.g. internal-colleague, external- corporate, or external-personal). The privacy rules may be executed by the IdP, but other rules may be executed by the CS, hence discrepancies may occur, for example, when the destination-based privacy rule conflicts with corporate policies for this customer. Hence, this example also shows the need for privacy policy negotiation and reconciliation. 7.6. Employee using untrusted WebRTC service Alice is an employee making use of a WebRTC service that she considers to be untrusted, in order to communicate some important messages to Bob, while she is out of the office. Alice registers to an untrusted CS with her corporate identity. Bob can 'discover' Alice's address when he logs into the same untrusted service, because her corporate identity was linked with the CS service-bound identity, when she registered. This use case is an example of single-CS call Copeland, et al. Expires March 30, 2017 [Page 20] Internet-Draft Requirements in WebRTC Authentication September 2016 model, using an untrusted calling service in combination with a trusted IdP. Mutual peer authentication can take place, with each party authenticating the CS based identity via surrogate or explicit corporate identities. Alice wants to be sure that her trusted corporate IdP is used, in order to minimize risks of an MitM attack by the CS, and ensure that the media flow is confidential. Currently, the decision to use an IdP, or a particular user-chosen IdP, is in the hands of the CS, so the possible attacker is responsible for setting the protection! Hence, it is very important that users gain the power to proactively protect their communication by opting to use IdP authentication. 7.7. WebRTC service Interworking with SIP users Alice uses a social media website to connect to her friends, and her contact list includes people with mobile numbers only. Alice can initiate and receive web calls from her mobile, to connect with mobile phones. Users receiving calls from Alice will see Alice's phone number displayed, or her IdP identity. Alice can also call Bob's mobile number from her laptop using a social media service. To connect to Bob, Alice is authenticated by her social media service provider (her CS), who also provides her with a SIP identity that is linked to her other identities. Her SIP identity [RFC3261] is authenticated by the mobile service provider, who had provided a pool of SIP identities to the social media calling service. This use case demonstrates dual-CS Call Model with the interworking service type, using server-side authentication. 8. Requirements Summary This section lists the new requirements, as discussed above. These requirements call for greater user's autonomy, greater transparency, and greater variety of trust models that affect the level of divulged information. 8.1. Anonymity 1. It should be possible to set different anonymity rules by standard service types, call models and destination categories. 2. Personal information must not leak via identity assertions. 3. IdP should facilitate pseudonimity via surrogate linked identities. Copeland, et al. Expires March 30, 2017 [Page 21] Internet-Draft Requirements in WebRTC Authentication September 2016 8.2. Unlinkability 1. It should be possible to set different unlinkability rules by standard service types, call models and destination categories. 2. Callers should be able to request and enforce unlinkability with respect of a called party, separately from other anonymity states. 3. Called destinations should be able to refuse unlinkability requests (e.g. to avoid nuisance calls), while respecting pseudonimity. 4. Unlinkability (e.g. via "origin" in the SDP) should be subject to pre-defined policy, whether that policy is CS-based or IdP-based. Currently, such policies are not transparent to users. 5. Non-disclosure of organization domains is a type of unlinkability, as well as anonymity. 8.3. Independent IdP 1. Users should be able to choose an IdP independently from any calling service, though some services will still mandate or restrict the choice of IdP. In particular, authentication by a trusted IdP must be an option for users who activate untrusted services. 2. IdPs must not lock-in users through non-portable identifiers. 3. Users should be able to create and link surrogate identities and pseudonyms to a globally unique identifier that is portable between IdPs. 4. Users should be able to associate service-bound identities with their independent identity (albeit with distinctive assertion tokens), thus achieving Single-Sign-On. 5. Browsers should allow users to set their chosen default IdPs and log in on browser start-up. Currently browsers select their own factory-set IdPs. 6. User-chosen IdPs should be able to prompt users to log in. Currently, IdP proxies cannot open a dialogue with the user. 7. Users should be able to set IdP-based privacy rules for untrusted CS. Copeland, et al. Expires March 30, 2017 [Page 22] Internet-Draft Requirements in WebRTC Authentication September 2016 8.4. User Information Confidentiality 1. Linked identifiers and supporting personal verification data must be subject to users' privacy preference. 2. Session setup messages, as well as identity assertions, should be protected to prevent tampering and eavesdropping. 3. Users' affiliations with organizations should be subject to privacy preferences. Currently, corporate requirements are not addressed. 8.5. Calling Services 1. Users should be able to set privacy rules for untrusted CS or destinations websites acting as calling services, regardless of the service own parameters. 2. CS should be able to determine privacy parameters per organizations, for data confidentiality and anonymity. 3. Despite users' choice of IdP, calling services should not be precluded from mandating their choice of IdPs, or offering a preferred IdP list. 4. There must be a transparent method of resolving conflicting privacy requirements arising from the respective CS options. 5. The original website that redirects to a calling service should not be named as 'origin', if users wish to avoid divulging it. 6. To distinguish between withheld identity and undetected identity, the "origin" field should only provide a status indicator. 8.6. Usability and Notification 1. Users should be informed how their privacy will be handled by the calling service, and which identity and IdP are used. 2. It should be possible to request unlinkability and pseudonimity for a shared group identity, but allow members to maintain separate identities with personal privacy preferences. 3. The IdP must notify users (or CS clients) if it is not possible to support undetectable, pseudonymous or unlinkable calling. Currently, there are no IdP notifications to the user. Copeland, et al. Expires March 30, 2017 [Page 23] Internet-Draft Requirements in WebRTC Authentication September 2016 4. Users should be notified if a default IdP is assigned, and if other than their chosen IdP is assigned. 9. Conclusions The web calling paradigm is transformed by browser-based calling facilities that are easily added to shop windows websites. However, this encourages opportunistic calling with increased risks from untrusted parties. The spread of such calling services means users have to maintain numerous identities/passwords, while established services lock-in users to the service-bound identity. Users need to manage their own structured identities, independently of any service. They also need to control their privacy preferences, and vary such preferences for high-risk connections. A solution is needed not only to allow users to control their privacy requirements according to web-calling context, but also to protect destination websites from abuse of anonymity. 10. Contributors This document is the result of a very fruitful work within the reThink project, with also the following contributors: I. Tariq Javed Institut Mines Telecom-Telecom Sud Paris 9 rue C.Fourier Evry 91011 France Email: ibrahim_tariq.javed@telecom-sudparis.eu N. Crespi Institut Mines Telecom-Telecom Sud Paris 9 rue C.Fourier Evry 91011 France Email: noel.crespi@mines-telecom.fr A. Bouabdallah Institut Mines Telecom-Telecom Bretagne 2 rue de la Chataigneraie Cesson Sevigne 35576 France Email: ahmed.bouabdallah@telecom-bretagne.eu S. Becot Orange Labs 4, rue du Clos Courtel Cesson Sevigne 35510 Copeland, et al. Expires March 30, 2017 [Page 24] Internet-Draft Requirements in WebRTC Authentication September 2016 France Email: simon.becot@orange.com J.-M. Crom Orange Labs 4, rue du Clos Courtel Cesson Sevigne 35510 France Email: jeanmichel.crom@orange.com 11. Acknowledgements This document was inspired by a draft authored by Victoria Beltran, Orange (Email: vicbelma@gmail.com); Emmanuel Bertin, Orange (Email: emmanuel.bertin@orange.com); Stephane Cazeaux, Orange (Email: stephane.cazeaux@orange.com). Thank you to Ricardo Chaves (INESC-ID) who provided us with his interesting feedback and comments. This work has received funding from the European Union's Horizon 2020 research and innovation program under grant agreement No 645342, project reTHINK. 12. References 12.1. Normative references [I-D.ietf-rtcweb-overview] Alvestrand, H., "Overview: Real Time Protocols for Browser-based Applications", draft-ietf-rtcweb-overview-15 (work in progress), January 2016. [I-D.ietf-rtcweb-security-arch] Rescorla, E., "WebRTC Security Architecture", draft-ietf- rtcweb-security-arch-12 (work in progress), June 2016. [I-D.ietf-rtcweb-use-cases-and-requirements] Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- Time Communication Use-cases and Requirements", draft- ietf-rtcweb-use-cases-and-requirements-16 (work in progress), January 2015. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Copeland, et al. Expires March 30, 2017 [Page 25] Internet-Draft Requirements in WebRTC Authentication September 2016 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, DOI 10.17487/RFC3261, June 2002, . [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, . [RFC4949] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, DOI 10.17487/RFC4949, August 2007, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, . 12.2. Informative references [I-D.cazeaux-rtcweb-oauth-identity] Beltran, V., Bertin, E., and S. Cazeaux, "Additional Use- cases and Requirements for WebRTC Identity Architecture", draft-cazeaux-rtcweb-oauth-identity-00 (work in progress), March 2015. [I-D.ietf-rtcweb-security] Rescorla, E., "Security Considerations for WebRTC", draft- ietf-rtcweb-security-08 (work in progress), February 2015. [JeffSayreHenryStory] Sayre, J. and H. Story, "The WebID Protocol & Browsers", May 2011, . [OIDC] "OpenID Connect Core 1.0 incorporating errata set 1", . Copeland, et al. Expires March 30, 2017 [Page 26] Internet-Draft Requirements in WebRTC Authentication September 2016 [SurrogateKeys] Carter, B., "Intelligent Versus Surrogate Keys", 1997, . [TerminologyForPrivacy] Pfitzmann, A., Hansen, M., and H. Tschofenig , "A terminology for privacy by data minimization: Anonymity, Unlinkability, Undetectability, Unobservability,Pseudonymity, and Identity Management - V0.34", August 2010. [WebRTC] Bergkvist, A., Burnett, D., Jennings, C., and A. Narayanan, "WebRTC 1.0: Real-time Communication Between Browsers. World Wide Web Consortium WD WD-webrtc- 20120821.", August 2012. Authors' Addresses Rebecca Copeland (editor) Institut Mines Telecom-Telecom Sud Paris 9 rue C.Fourier Evry 91011 France Email: rebecca.copeland@coreviewpoint.com Kevin Corre Orange Labs 4, rue du Clos Courtel Cesson Sevigne 35510 France Email: kevin1.corre@orange.com Ingo Friese Deutsche Telekom AG Winterfeldtstr. 21 Berlin 10781 Germany Email: Ingo.Friese@telekom.de Copeland, et al. Expires March 30, 2017 [Page 27] Internet-Draft Requirements in WebRTC Authentication September 2016 Saad El Jaouhari Institut Mines Telecom-Telecom Bretagne 2 rue de la Chataigneraie Cesson Sevigne 35576 France Email: saad.eljaouhari@telecom-bretagne.eu Copeland, et al. Expires March 30, 2017 [Page 28]