Internet DRAFT - draft-cheng-rtcweb-teleauth
draft-cheng-rtcweb-teleauth
RTCWeb Working Group Z. Cheng
Internet Draft M. Qi
J. Zhu
Intended status: Informational China Mobile
Expires:August 8, 2014 Feb. 8, 2014
Security Authentication of WebRTC Communication Service
for Telephony Terminal
draft-cheng-rtcweb-teleauth-00
Abstract
The WebRTC use-cases and related requirements are defined in
[draft-ietf-rtcweb-use-cases-and-requirements] that contains browser to
browser use-cases and browser-GW/server use-cases (e.g., telephony
terminal). In the use-case of telephony terminal, it is necessary for
telephony terminal to be able to attest his identity to the telephony
operator. Unlike the current authentication specified in
[draft-ietf-rtcweb-security] such as PKI based authentication and web
based peer authentication WebRTC communication is directly controlled
by the telephony operator, which poses new authentication methods,
including re-using existence authentication mechanism of telephony
operator and authentication by using web credentials. This document
presents the security authentication of WebRTC communication for
telephony terminal.
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), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
Cheng, et al. Expires Auguet 8, 2014 [Page 1]
Internet-Draft Telephony Authentication Feb 2014
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This Internet-Draft will expire on August 8, 2014.
Copyright Notice
Copyright (c) 2013 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.
Table of Contents
1. Introduction .....................................................2
2. Conventions used in this document ................................3
2.1. Definitions.....................................................3
3. Problem Statement ................................................4
4. Requirement ......................................................6
5. Telephony Terminal Authentication Solution .......................6
5.1. Introduction ...................................................6
5.2. authentication solution for scenario 1..........................7
5.3. authentication solution for scenario 2..........................7
6. Security Considerations ..........................................9
7. IANA Considerations .............................................10
8. Conclusions .....................................................11
9. References ......................................................11
9.1. Normative References ..........................................11
9.2. Informative References ........................................11
1. Introduction
The WebRTC use-cases and related requirements are defined in
[draft-ietf-rtcweb-use-cases-and requirements] that contains a use-case
titled telephony terminal. As shown in Figure 1, a mobile telephony
operator allows its customers to use a web browser to access their
services, so that WebRTC service is provided by the telephony operator
Cheng, et al. Expires Auguet 8, 2014 [Page 2]
Internet-Draft Telephony Authentication Feb 2014
but not the web server. Therefore, the current authentication solutions
(i.e., PKI based authentication and web based peer authentication) are
only adaptive for service facilitated by web server, new authentication
solutions due to a new exploited entity as operator server should be
defined for the use case of telephony terminal, all telephony terminals
can be authenticated to access WebRTC communication service provided by
the telephony operator.
This document presents the security authentication of WebRTC
communication for telephony terminal.
+---------------------------------------------------------------------+
| |
| HTTP +------------+ |
| +-------------| Web Server | |
| | +------------+ |
| | |
| | |
| | |
| V |
| +------------+ Signal +------------+ |
| | Telephony |<--------------------------->| Operator | |
| | Terminal | Media | Server | |
| +------------+ +------------+ |
| |
+---------------------------------------------------------------------+
Figure 1. WebRTC system for telephony terminal
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].
In this document, these words will appear with that interpretation
only when in ALL CAPS. Lower case uses of these words are not to be
interpreted as carrying RFC-2119 significance.
2.1. Definitions
Cheng, et al. Expires Auguet 8, 2014 [Page 3]
Internet-Draft Telephony Authentication Feb 2014
Terminal: the terminal with browser that is equipped with a WebRTC JS
application capable of interconnection with the operator server.
WebRTC application: The WebRTC application is downloaded from the Web
server within the operator network or a third party network and provides
access to the communications service from the telephony operator.
Web server: The Web Server is the initial point to contact in the Web
that controls access WebRTC communications service for the terminal.
Operator server: The operator server is the point to verify any possible
authentications of terminals and provide the specific WebRTC communication
service for terminals.
3. Problem Statement
3.1 use cases
Nowadays, in current WebRTC use-cases (i.e., browser-to-browser use-cases),
the terminals with WebRTC enable browsers visit some Web server which
operates a calling service. The current authentication solution either
uses PKI-style certificate or Web-based identity (e.g., Brower ID) to
authenticate the terminals. In fact, not only the Web server but also the
telephony operator can provide a calling service for their terminals.
As depicted in [draft-ietf-rtcweb-use-cases-and-requirements], there exists
a specific use-case as follows:
Telephony terminal: A mobile telephony operator allows its customers to use
a web browser to access their services. After a simple log in the user can
place and receive calls in the same way as when using a normal mobile
phone. When a call is received or placed, the identity is shown in the same
manner as when a mobile phone is used.
The use-case of Telephony terminal supports two different solutions that
differ in authentication methods and ownership of the web server (i.e.,
operator or the third party). The two solutions are depicted as follows:
Solution 1: The user has a subscription with an identity belongs to the
telephony operator and uses an authentication method (e.g. SIP digest) to
validate itself with the operator server.
Cheng, et al. Expires Auguet 8, 2014 [Page 4]
Internet-Draft Telephony Authentication Feb 2014
Solution 2: The user has a subscription with an operator identity but
uses a web identity and authentication scheme to authenticate with the
Web server. The Web server assigns the user an operator credential in
terms of the user's web credential for making authentication with the
operator server. As aforementioned, the existing authentication solutions
are no longer appropriate in the use-case of telephony terminals. When a
telephony terminal requests for a calling service, it should prove its
identity belongs to the telephony operator in advance, so that the
operator permits it to access WebRTC service.
3.2 Current solutions analysis
In the browser-to-browser use-cases, each browser which attempt to
communicate with exposes standardized JavaScript calling APIs
(implemented as browser built-ins) which are used by the Web server
to set up a call. The Web server also serves as the signaling channel
to transport control messages between the browsers and service JS sets
up some media.
In such use-cases, the conventional solution to providing communications
identity usually uses third party identity system (e.g., PKI) to
authenticate the browsers.
Furthermore, a new solution using Web-based identity technologies (e.g.,
BrowserID, Federated Google Login, Facebook Connect, OAuth, OpenID,
WebFinger) has recently been developed to provide lightweight (from the
user's perspective) third-party Web-based peer authentication. It uses
systems of this type to authenticate WebRTC calls, linking them to
existing third identity (e.g., Facebook adjacencies). Specifically, the
third-party identity system is used to bind the user's identity to
cryptographic keying material which is then used to authenticate the
browsers.
3.3 problem statement
1. The current solution has the following problems:For PKI-based solution
(i.e., PKI-style certificate), it needs to use certificate which is preset
between the user and the server. But the certificate management is too
cumbersome, including certificate application, issuance, updating, and
dispose, it needs to setup the complicated certificate management module.
Cheng, et al. Expires Auguet 8, 2014 [Page 5]
Internet-Draft Telephony Authentication Feb 2014
When AKA procedures using certificate need to check the validity of
certificate, it costs extra complexity. However, for telephony user, it
owns pre-shared key with operator rather than certificate. Therefore, PKI
usage doesn't fit for telephony users.
2. For Web-based solution (i.e., Web-based peer authentication), it is
suitable for browser-to-browser use-cases, since the browser is able to
directly identify the other calling browser by connecting a Web-based
(i.e., HTTP/HTTPS) identity provider without trusting the Web server
which they are logged in. That means it is a general principle that the
party which is being authenticated is NOT the signaling site (i.e., Web
server) but rather the user with his browser. Refers to
[draft-ietf-rtcweb-security-arch] However, it is necessary for operator
server to authenticate its users with their browsers in the telephony
terminal use-case. Therefore, Web-based solution can't address this
requirements.
4. Requirement
In order to provide the secure WebRTC communication service from the
telephony operator to its users/terminals, it is need to design new
security authentication solutions for terminals to prove their
identities through WebRTC methods in the use-case of telephony terminal.
5. Telephony Terminal Authentication Solution
5.1. Introduction
The security authentication of the use-case so-called Telephony terminal
is the adaptive mechanism for the involved entities such as operator
server, web server and the terminal to make authentication for WebRTC
communication service.
There are two solutions for the authentication mechanisms:
Solution 1: The user has a subscription with an identity belongs to the
telephony operator and uses an authentication method (e.g. SIP digest) to
validate itself with the operator server.
Solution 2: The user has a subscription with an operator identity but
uses a web identity and authentication scheme to authenticate with the
Cheng, et al. Expires Auguet 8, 2014 [Page 6]
Internet-Draft Telephony Authentication Feb 2014
Web server. The Web server assigns the user a operator credential in
terms of the user's web credential for making authentication with the
operator server.
5.2. authentication solution 1
1. By using a WebRTC-enabled browser, the terminal accesses a URI to the
Web server facilitating an HTTPS connection. The TLS connection
provides one-way authentication of the server based on the server
certificate. The browser downloads and initializes the WebRTC
application from the Web server.
2. The WebRTC application opens a WSS connection to the operator server
using standard cross-origin resource sharing procedures to ensure that
the application originated from a Web server authorized to access this
operator server.
3. The WebRTC application launches a registration transaction with the
operator server by sending a REGISTER request via the WSS connection.
The REGISTER request includes authentication parameters
as needed for proper registration. This request is translated
in the operator core network as it is processed by the operator server.
This process leverage user credentials in HSS.
5.3. authentication solution 2
1. By using a WebRTC-enabled browser, the terminal accesses a URI to the
Web server facilitating an HTTPS connection. The TLS connection
provides one-way authentication of the server based on the server
certificate. The browser downloads and initializes the WebRTC
application from the Web server.
2. The Web server authenticates the terminal using a common web
authentication procedure, determines the identity registered with the
operator and assigned it to the terminal, issues a security token to
the terminal and returns the identity as claims within the security
token to the terminal's WebRTC application.
3. The WebRTC application opens a WSS connection to the operator server
using CORS procedures to ensure that the WebRTC application originated
from a Web server authorized to access the operator server.
4. The WebRTC application sends a REGISTER request to the operator server
via the WSS connection. The request includes the user identity
Cheng, et al. Expires Auguet 8, 2014 [Page 7]
Internet-Draft Telephony Authentication Feb 2014
extracted from the claims in the security token and the security token
received from the Web server.
5. The operator server validates the contents of the security token and
confirms that the identity being registered is authorized by the
security token.
6. The operator returns an OK response to the terminal to announce that
authenticates terminal successfully.
Cheng, et al. Expires Auguet 8, 2014 [Page 8]
Internet-Draft Telephony Authentication Feb 2014
6. Security Considerations
This memo considers the security authentication for providing WebRTC
service in use case of telephony terminal. So it would not introduce
any additional security problems.
Cheng, et al. Expires Auguet 8, 2014 [Page 9]
Internet-Draft Telephony Authentication Feb 2014
7. IANA Considerations
There are no IANA considerations associated to this memo.
Cheng, et al. Expires Auguet 8, 2014 [Page 10]
Internet-Draft Telephony Authentication Feb 2014
8. Conclusions
This memo describes the problem raised by conventional authentication
solutions for the use-case of telephony terminal. After that, the
telephony terminal authentication requirement is raised and related
security authentication solutions are proposed.
9. References
9.1. Normative References
9.2. Informative References
[I-D.ietf-rtcweb-use-cases-and-requirements]
C. Holmberg, et al., "Web Real-Time Communication Use-cases and
Requirements", draft-ietf-rtcweb-use-cases-and-requirements-13
(work in progress), February 2014
[I-D.ietf-rtcweb-security-arch]
E. Rescorla, "WebRTC Security Architecture", draft-ietf-rtcweb-
security-arch-07 (work in progress), July 2013
Authors' Addresses
Ziyao Cheng
China Mobile
Unit 2, 32 Xuanwumenxi Ave,
Xicheng District,
Beijing 100053, China
Email: chengziyao@chinamobile.com
Cheng, et al. Expires Auguet 8, 2014 [Page 11]
Internet-Draft Telephony Authentication Feb 2014
Minpeng Qi
China Mobile
Unit 2, 32 Xuanwumenxi Ave,
Xicheng District,
Beijing 100053, China
Email: qiminpeng@chinamobile.com
Judy Zhu
China Mobile
Unit 2, 32 Xuanwumenxi Ave,
Xicheng District,
Beijing 100053, China
Email: Zhuhongru@chinamobile.com
Cheng, et al. Expires Auguet 8, 2014 [Page 12]
