Internet DRAFT - draft-cazeaux-rtcweb-oauth-identity
draft-cazeaux-rtcweb-oauth-identity
Network Working Group V. Beltran
Internet-Draft E. Bertin
Intended status: Informational S. Cazeaux
Expires: September 10, 2015 Orange
March 9, 2015
Additional Use-cases and Requirements for WebRTC Identity Architecture
draft-cazeaux-rtcweb-oauth-identity-00
Abstract
This document discusses additional use-cases and requirements for the
WebRTC identity architecture proposed by 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 September 10, 2015.
Copyright Notice
Copyright (c) 2015 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.
Beltran, et al. Expires September 10, 2015 [Page 1]
Internet-Draft Additional Use-cases for WebRTC Identity March 2015
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions used in this document . . . . . . . . . . . . . . 5
3. Some limitations of the current security architecture . . . . 5
3.1. Relationship between user and calling site . . . . . . . 5
3.2. Relationship between user and IdP . . . . . . . . . . . . 6
3.3. Derived from the underlying identity protocol . . . . . . 6
4. Use cases for the security architecture . . . . . . . . . . . 7
4.1. Call-center communication . . . . . . . . . . . . . . . . 7
4.2. Online game with voice communication . . . . . . . . . . 7
4.3. Enterprise video communication service . . . . . . . . . 8
4.4. Wifi-based operator WebRTC service . . . . . . . . . . . 8
4.5. Free Internet WebRTC service . . . . . . . . . . . . . . 9
5. Requirements for WebRTC identity provision . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
9.1. Normative references . . . . . . . . . . . . . . . . . . 12
9.2. Informative references . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction
The Real-Time Communications on the Web (RTCWEB) working group
standardizes protocols for real-time communications between Web
browsers. The major use cases for WebRTC technology are real-time
audio and/or video calls, Web conferencing, and direct data transfer.
Unlike most conventional real-time systems, (e.g., SIP-based
[RFC3261] soft phones) WebRTC communications are directly controlled
by some Web server, via a JavaScript (JS) API as shown in Figure 1.
Beltran, et al. Expires September 10, 2015 [Page 2]
Internet-Draft Additional Use-cases for WebRTC Identity March 2015
+----------------+
| |
| Web Server |
| |
+----------------+
^ ^
/ \
HTTP / \ HTTP
/ \
/ \
v v
JS API JS API
+-----------+ +-----------+
| | Media | |
| Browser |<---------->| Browser |
| | | |
+-----------+ +-----------+
Figure 1: A simple WebRTC system
The WebRTC security architecture proposes a trust model
[I-D.ietf-rtcweb-security-arch] to allow end users to identify each
other (and hence to trustworthy decide to continue their
communication, or not). In this model, users can directly identify
each other without trusting the signaling service to which they are
connected. For user authentication, Web-based identity technologies
(OAuth, BrowserID, Facebook Connect) are used to provide browsers
with user identities. All these technologies rely on a Web-based
(i.e., HTTP/HTTPS) Identity Provider (IdP) that authenticates the
user and generates his or her identity assertion. Whatever the
underlying technology, the general principle is that the party which
is being authenticated is the user (i.e; Alice)through his/her
browser, rather than the calling service. The remote user (i.e.
Bob) only needs to trust the identity assertion generated by Alices's
IdP.
The WebRTC security architecture proposes that the WebRTC
PeerConnection component interacts directly with the IdP, as shown in
Figure 2. The general idea is that the PeerConnection component
downloads JS from a specific location on the IdP dictated by the IdP
domain name. The IdP can be selected by the calling service or set
up in the browser. The IdP JS "endpoint", which is called IdP proxy,
is used to both generate and verify user identity assertions.
Beltran, et al. Expires September 10, 2015 [Page 3]
Internet-Draft Additional Use-cases for WebRTC Identity March 2015
+--------------------------------------+
| Browser |
| |
| +----------------------------------+ |
| | https://calling-site.example.com | |
| | | |
| | Calling JS Code | |
| | ^ | |
| +---------------|------------------+ |
| | API Calls |
| v |
| PeerConnection |
| ^ |
| | MessageChannel |
| +-----------|-------------+ | +---------------+
| | v | | | |
| | IdP Proxy |<-------->| Identity |
| | | | | Provider |
| | https://idp.example.org | | | |
| +-------------------------+ | +---------------+
| |
+--------------------------------------+
Figure 2: Web-Based Peer Authentication
When Alice wishes to call Bob, Alice's PeerConnection component
instantiates the IdP Proxy of Alice's IdP. This IdP Proxy interacts
with the IdP to authenticate Alice and, as a result, receive an her
identity assertion from the IdP. Once the IdP Proxy replies back to
the PeerConnection component with Alice's identity assertion, this
component attaches the assertion to the call request to Bob. On Bob's
side, when his browser receives the call request, the PeerConnection
component instantiates the IdP Proxy of the IdP that generated the
assertion and pass this assertion to it. This IdP Proxy communicates
to the IdP to verify that the assertion was correctly generated by
the IdP. The same procedure happens on the other way round. In the
Bob's response to Alice, his browser attaches his identity assertion
and Alice will verify this assertion against his IdP.
To associate Alice (Bob)'s identity assertion to the call that is
being negotiated with Bob (Alice), her (his) assertion is bound to
the call's DTLS-SRTP fingerprint. How this binding is actually done
depends on the underlying SSO protocol. Two protocols are
illustrated in [I-D.ietf-rtcweb-security-arch], namely, BrowserId and
OAuth2.0.
In this draft, we discuss some shortcomings of this model (section
3). We introduce then different uses cases that should be covered by
Beltran, et al. Expires September 10, 2015 [Page 4]
Internet-Draft Additional Use-cases for WebRTC Identity March 2015
the WebRTC identity architecture, along with the corresponding
requirements (section 4). We finally discuss whether these
requirements are fulfilled by the current WebRTC Security
Architecture [I-D.ietf-rtcweb-security-arch] (section 5).
2. Conventions used in this document
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].
3. Some limitations of the current security architecture
3.1. Relationship between user and calling site
First, the calling service can see the user's fingerprint and
identity assertions over the signaling path. When a user is going to
make a call, he or she attaches his fingerprint and identity
assertion to the call request. The callee in turn also attaches his
or her fingerprint and identity assertion to the response to the
request. Since the signaling path is not end-to-end encrypted, the
calling service can see the users' identity assertions and
fingerprints, which compromises the user privacy. On one hand, the
calling service can see all the information contained in the identity
assertions. On the other hand, the service can use either the
fingerprint or the identity assertion to track the user's calls, as
long as they are permanent across calls.
Moreover, the identity assertion is sent in clear before the end
parties verify that there is not any man-in-the-middle attack (i.e.,
the DTLS handshake has not yet taken place). Thus, any successful
man-in-the-middle attacker could get the users' identity assertions.
Authorization-oriented protocols such as OAuth2.0 can exchange
authorization codes instead of identity assertions between the end
points. This case also compromises user privacy since the calling
service or a man-in-the-middle attacker can get the authorization
code and use it against the IdP.
To avoid the calling service linking communication calls by
fingerprints, the browser might be instructed to generate a separate
DTLS key for each call. However, the CP is always able to link calls
by identity assertions since there is no confidentiality for identity
assertions.
Due to this lack of user privacy, the WebRTC security architecture
assumes a non-malicious calling service (i.e., Section 6.1 in
[I-D.ietf-rtcweb-security-arch]). This assumption is not however in
Beltran, et al. Expires September 10, 2015 [Page 5]
Internet-Draft Additional Use-cases for WebRTC Identity March 2015
line with the proposed model for identity provision, which assumes
that end users do not trust the calling service. If a user does not
trust the calling service, this implies that this service cannot
break the security or privacy of the user without his/her cooperation
and knowledge. Since in the proposed model, the calling service can
break the user privacy at will (by analyzing and linking identity
assertions), either the model assumes that users trust the calling
service or new mechanisms should be provided to protect user privacy.
3.2. Relationship between user and IdP
The WebRTC security architecture assumes that users trust their IdPs.
Users should nonetheless be aware that such trust means that their
IdPs can compromise their privacy. Any request that is sent to the
IdP Proxy of the user's IdP contains an "origin" field that
identifies the JS sending the request (i.e. the URL of the calling
site). This field can be used by the IdP to identify the calling
service and apply authorization policies. Thus, the user's IdP can
trace the calling sites that the user visits. In addition, the
called party (the party to which the user's identity assertion is
sent) will communicate with the user's IdP in order to verify the
user's identity assertion. Thus, the user IdP will be able to trace
the sites that the user is visiting, the times at which he or she is
placing a call and the called party's IP address (if the called party
does not apply any mechanism for IP confidentiality). This is
notably the case for calls to corporations, whose public IP address
range can be easily retrieved.
3.3. Derived from the underlying identity protocol
Although the proposed identity model is aimed to be protocol-
independent, the underlying identity protocol can impact user
privacy. Developers and users should therefore be aware of the
limitations imposed by the underlying identity protocol. We mention
the main limitations of the two protocols addressed in
[I-D.ietf-rtcweb-security-arch], namely BrowserID and OAuth2.0.The
main limitation of BrowserID stems from its user identification
scheme. It relies on public email address, and hence neither user
anonymity, nor identity unlinkability are possible.
Regarding OAuth2.0, the main security limitation is the fact that the
IdP has no actual way to verify who has been authorized by a user to
get the user's identity assertion. This binding breaks OAuth2.0
authorization-oriented nature in several aspects. First, the IdP
cannot show the user (i.e. Alice) information about who is going to
receive the identity assertion (e.g., Bob). Indeed, the assertion is
generated by the IdP to its own Id Proxy, instead of Bob. Second, the
IdP cannot ensure that the user has authorized Bob. In fact, the IdP
Beltran, et al. Expires September 10, 2015 [Page 6]
Internet-Draft Additional Use-cases for WebRTC Identity March 2015
does not perform any authorization policy when an authorization token
to get Alice's identity is presented. Thus, the calling service (or
a man in the middle attacker) may use the authorization code captured
on the signaling path to get the user's identity assertion from the
IdP.
4. Use cases for the security architecture
This uses cases are partly derivated from
[I-D.ietf-rtcweb-use-cases-and-requirements]. In addition,
motivating use cases for the enterprise market are provided, as this
is one forecasted important usage of WebRTC applications.
4.1. Call-center communication
Alice is surfing the websites of several insurance or healthcare
companies for information. She wishes to communicate through an
WebRTC-based in-content communication tools provided by a partner of
the websites (CP). Alice is concerned with her privacy. She prefers
to remain anonymous if possible by avoiding any authentication
system. For the websites that permit no authentication, she will not
use any IdP. For the website that require authentication, she will
authenticate to her IdP but she will require neither the CP, nor the
IdP to be aware of the insurance or healthcare sites that she is
visiting.
The requirements in this use case are:
o Anonymity by no authentication (no IdP)
o Site unlinkability by the IdP
o Caller unlinkability by the IdP
4.2. Online game with voice communication
Alice is playing poker on a gaming web site. She wishes to
communicate with the other players through a voice channel. She is
not registered on the gaming site as Alice but under a pseudonym:
"PokerGirl". She prefers to present herself as PokerGirl to other
players, instead of using her real identity at her IdP.
In this use case, she wishes to use her identity at the calling site
rather than other external identity. Thus, the requirement is:
o Identity provision by the calling site
Beltran, et al. Expires September 10, 2015 [Page 7]
Internet-Draft Additional Use-cases for WebRTC Identity March 2015
4.3. Enterprise video communication service
Alice is working for Acme Corporation. Her enterprise provides her
with a comprehensive communication suite relying on a SaaS provider
named "Comsforce". The Comsforce servers are thus located outside of
the enterprise. Acme Corporation requires Comsforce to use the
corporate IdP (based on the corporation's Active Directory server) to
authenticate its employees. To this end, Comsforce obtained an API
key and public key from Acme corporations. These credentials will be
used by Comsforce to authenticate to Acme corporation (e.g., by
creating a signature that contains the API key with the public key).
Thus, when Comesforce requests the Acme corporation's IdP to
authenticate a user, it needs to attach its credentials to the
request.
Acme corporation's employees will have conversations of a very
different nature. If the employee is a sales representative, he or
she would prefer to place anonymous calls to customers while
asserting that he or she is a sale representative of Acme
Corporation. If the employee is a business manager contacting a
colleague in the same corporation, he or she will need to present his
or her corporate identity (i.e., indicating his or her name,
department, etc.).
In this use case, we can see that different requirements coexist:
o Pre-determined IdP by the calling site
o Calling site authentication through credentials against IdP
o Anonymity by the IdP
o User identification
4.4. Wifi-based operator WebRTC service
A telecom operator offers a call-out communication service based on
WebRTC over a Wifi network deployed by the operator. This offer is
notably provided to companies that subscribe it for their employees
to avoid roaming fees when traveling.
A business user is on a professional trip and is using his or her
company's IdP to call colleagues and business partners. When the
user authenticates, the operator's service reads the user's identity
assertion to check out if the user's company has any offer subscribed
for the WebRTC service. In this case, the company could have even
agreed to include the payment method in the user's identity
assertion. To improve the user experience, the operator WebRTC
Beltran, et al. Expires September 10, 2015 [Page 8]
Internet-Draft Additional Use-cases for WebRTC Identity March 2015
service will detect the type of user device and it will request the
IdP the most appropriate login type (e.g., simple form-based login
for limited devices).
This use case is based on the trust that users give to the operator
service and its network. We see the requirements:
o Site linkability
o Selection of IdP by the user
o Identity assertion analysis by the calling site
o User identification
o Selection of user login type by the calling site
4.5. Free Internet WebRTC service
Like the use case 4.4, this use case focuses on an employee that is
traveling abroad for work. Conversely, this user does not find any
trustworthy WebRTC service. He or she connects to a public wifi and
finds a WebRTC provider on the Web. Although the employee does not
trust this Web service that is new to him or her, he or she needs to
communicate through it. The employee uses his or her company's IdP
and requests this IdP to provide identity confidentiality.
Logically, the user wishes to avoid the Web service from knowing his
or her corporate identity and/or tracking his or her calls.
In this use case, user privacy against the calling site is necessary:
o Selection of IdP by the user
o Identity confidentiality
5. Requirements for WebRTC identity provision
From the section above, we can see that the WebRTC security
architecture will have very different requirements based on the use
case. A same use case may even require two features that are
opposite as for example user identification and anonymity. The
WebRTC security architecture should therefore be flexible enough to
allow a dynamic configuration of features.
We outline below how the requirements are provided by the existing
architecture, or not.
Beltran, et al. Expires September 10, 2015 [Page 9]
Internet-Draft Additional Use-cases for WebRTC Identity March 2015
REQ-1 No Idp: The WebRTC API needs to be configurable for not using
any IdP (i.e., sending call requests without identity
assertions). This feature will provide users with anonymity
by the lack of user authentication or it will allow the
calling site to handle identity provision by itself.
REQ-2 Selection of IdP by the user: Users need to be able to select
their IdPs. This feature is already given by default in
WebRTC, as soon as the calling site does not choose a pre-
determined IdP.
REQ-3 Site unlinkability requested by the user: Users need to be
able to request that the IdP be not capable to know the
calling sites that they visit.
REQ-4 Caller unlinkability by the IdP: Users need to be able to
request that the IdP be not capable to know the IP address of
the person they are communicating with.
REQ-5 Pre-determined IdP by the calling site: The calling site
needs to be able to configure the IdP (or set of IdPs) that
users can authenticate to. WebRTC already provides a method
to do so (i.e., setIdentityProvider())
REQ-6 Calling site authentication through credentials: The calling
site needs to be able to authenticate to the IdP by passing
its credentials to the IdP Proxy. This can be done by
including the credentials in the "origin" field of the
messages sent to the IdP Proxy, as part of the calling site
identifier.
REQ-7 Customization of IdP functionality by the calling site: The
calling site needs to be able to pass the IdP parameters in
order to customize the IdP functionality as for example the
GUI for user login. This can be done by including these
parameters in the "origin" field of the messages sent to the
IdP Proxy. If the IdP Proxy does not support a feature
required by the calling site an error message must be
returned by the IdP Proxy.
Beltran, et al. Expires September 10, 2015 [Page 10]
Internet-Draft Additional Use-cases for WebRTC Identity March 2015
REQ-8 User anonymity by the IdP: The user needs to be able to
request the IdP to generate anonymous user identity
assertions. Identity assertions must not include any
personal identifiable information or permanent user
identifier. If the IdP is not capable to generate anonymous
assertions, the user should be notified. This feature is not
a requirement of the WebRTC security architecture, but it is
determined by the identity protocol implemented between the
IdP and IdP Proxy. For example, since BrowserID relies on
public email addresses, this protocol is not recommended to
uses cases that require user anonymity from the IdP.
REQ-9 User identification by the calling site: The user needs to be
able to request the IdP to generate identity assertions that
uniquely identify his or her (i.e., no anonymous). This
feature is already given by default in WebRTC.
REQ-10 Site linkability by the IdP: The IdP needs to be able to
trace the calling sites that the user visits (for
authorization, billing, or auditing purposes). This feature
is already given by default in WebRTC, through the "origin"
field of the messages sent to the IdP Proxy.
REQ-11 Identity assertion analysis by the calling site: The calling
site needs to be able to analyze the content of user identity
assertions. This is already allowed by the security
architecture, since assertions are transmitted in clear.
REQ-12 Identity confidentiality requested by the user: Users need to
be able to request the IdP to provide identity
confidentiality against the calling site or any other entity
different from the called party. The security architecture
does not support identity confidentiality, and new methods
need to be defined for these use cases.
REQ-13 Information displayed to the user: The user needs to be
informed how the privacy will be handled for a specific
WebRTC call that will take place with a given calling site
using a given IdP: site linkabiliy or unlikability, is
anonymity applied, is identity confidentiality applied.
Beltran, et al. Expires September 10, 2015 [Page 11]
Internet-Draft Additional Use-cases for WebRTC Identity March 2015
6. Security Considerations
7. IANA Considerations
None.
8. Acknowledgements
Thanks to Xavier Marjou and Stephane Tuffin for their review.
9. References
9.1. Normative references
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
9.2. Informative references
[I-D.ietf-rtcweb-overview]
Alvestrand, H., "Overview: Real Time Protocols for
Browser-based Applications", draft-ietf-rtcweb-overview-13
(work in progress), November 2014.
[I-D.ietf-rtcweb-security-arch]
Rescorla, E., "WebRTC Security Architecture", draft-ietf-
rtcweb-security-arch-10 (work in progress), July 2014.
[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.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
Authors' Addresses
Victoria Beltran
Orange
Email: vicbelma@gmail.com
Beltran, et al. Expires September 10, 2015 [Page 12]
Internet-Draft Additional Use-cases for WebRTC Identity March 2015
Emmanuel Bertin
Orange
Email: emmanuel.bertin@orange.com
Stephane Cazeaux
Orange
Email: stephane.cazeaux@orange.com
Beltran, et al. Expires September 10, 2015 [Page 13]