Content for TR 33.823 Word version: 12.2.0

3.1 Definitions 3.2 Abbreviations 4.1 Introduction 4.2 Objectives
...

0 Introduction p. 4

The most used authentication method in the Internet today is HTML FORM based authentication. It is used with web browsers where a login page is downloaded over HTTPS and which contains an HTML FORM with at least 'username' and 'password' fields. Sometime, this takes place over plain HTTP, which poses a security risk. The current mechanism how GBA could be used from web browser is to use GBA with HTTP Digest as specified in clause 5.3 of TS 33.222.

In current implementations, once a web browser has started to use HTTP Digest with a particular web server, it continues to use it until the browser instance is terminated. This is common behaviour in web browsers today. This means that there is no way of doing a logout as the browser keeps on sending the HTTP Authorization headers back to the web server.

Another drawback is that using HTTP Digest in parallel to HTML FORM based authentication is not straight forward as the authentication happens in different layers of protocols. Also, the usage of HTTP Digest and HTML FORM based Authentication from the same browser is investigated.

In order to simplify the usage of GBA in web browsers this document describes how to enable access to GBA in HTML layer, namely using Javascript. The usage of Javascript together with GBA raises also some security concerns with regard to protection of GBA credentials, hence the best common practices for this kind of interworking are outlined in this document.

1 Scope p. 5

This work in this Technical Report has the following scope:

Study the potential threats for different GBA credentials use scenarios via a web browser. These new use scenarios (e.g. using HTML forms, using Javascript, using widgets) are not covered by current specifications.

The scope of this Technical Report will cover the following:

Study, identify and specify any protection mechanism that maybe additionally required for the GBA credentials;
Study, identify and potentially specify usage control for GBA credentials;
Study, identify and potentially specify access control mechanism for GBA module;
Study, identify and potentially specify the usage of web based GBA as an extension on the current protocol mechanisms used on Ua reference point (e.g. new Ua protocol identifier);
Identify and outline how GBA can be used with HTML Forms and Javascript securely (e.g. describing GBA - web specific common practices and examples).

This Technical Report will collect the potential specification improvements, which are then at a later stage of work transferred to the appropriate Technical Specifications. The potential improvements for access control to GBA credentials and potential Ua protocol impacts will then be documented in TS 33.220. The threat analysis, common security implementation practices and examples may build a new chapter 5 in TS 33.222.

Relation to GBA variants defined in other documents: Web based GBA aims at defining web enhancements for the use of HTML forms with GBA. It is a new variant for the Ua interface and does not affect the Ub interface, as opposed to the GBA variants defined in TS 33.220. Web based GBA is orthogonal to these other GBA variants and can be used with any of them.

2 References p. 5

The following documents contain provisions which, through reference in this text, constitute provisions of the present document.

References are either specific (identified by date of publication, edition number, version number, etc.) or non-specific.
For a specific reference, subsequent revisions do not apply.
For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document.

[1]

TR 21.905: "Vocabulary for 3GPP Specifications".

[2]

TS 33.220: "Generic Authentication Architecture (GAA); Generic Bootstrapping Architecture".

[3]

TS 33.222: "Generic Authentication Architecture (GAA); Access to network application functions using Hypertext Transfer Protocol over Transport Layer Security (HTTPS)".

[4]

RFC 5705 (2010): "Keying Material Exporters for Transport Layer Security (TLS)".

[5]

W3C Recommendation (Jul 30, 2013): "Web Storage", http://www.w3.org/TR/webstorage/

[6]

W3C Last Call Working Draft (Sep 12, 2013): "File API", work in progress, http://www.w3.org/TR/FileAPI/

[7]

RFC 5929 (2010): "Channel Bindings for TLS".

[8]

W3C Working Draft (Oct 1, 2013): "HTML5.1 Nightly - A vocabulary and associated APIs for HTML and XHTML", work in progress, http://dev.w3.org/html5/spec/

[9]

TS 33.203: "3G security; Access security for IP-based services".

3 Definitions and abbreviations p. 6

3.1 Definitions p. 6

For the purposes of the present document, the terms and definitions given in TR 21.905 and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in TR 21.905.

HTML FORM:

A HTML form is a clause of a HTML document containing normal content, markup, special element called controls (checkboxes, radio buttons, text fields, password fields, etc.) and labels on those controls. End users generally "complete" a form on a web page by modifying its controls (entering text, selecting radio buttons, etc.), before submitting the form to an agent for processing (e.g. to a web server).

HTML5:

HTML5 is a W3C specification [8] that defines the fifth major revision of the Hypertext Markup Language (HTML), the standard language for describing the contents and appearance of Web pages.

JavaScript:

JavaScript is a prototype-based scripting language that was formalized in the ECMAScript language standard. JavaScript is primarily used in the form of client-side JavaScript, implemented as part of a Web browser in order to provide enhanced user interfaces and dynamic websites.

Same origin policy:

Some origin policy is a security mechanism in a client browser that permits webpage scripts to access their associated website's data and methods but restricts its access to scripts and data stored by other websites.

GBA web session:

A GBA web session is the duration where the NAF can identify that the messages relate to the same individual GBA enabled terminal and a particular browser instance running in that terminal and consist out of a sequence of related HTTP request/response transactions together with some associated server-side state. The lifetime of the session is the lifetime of the Ks_js_NAF which is equal or shorter than the Ks_NAF lifetime and it is also equal or shorter than the lifetime of the TLS session, which was used to derive the Ks_js_NAF.

3.2 Abbreviations p. 6

For the purposes of the present document, the abbreviations given in TR 21.905 and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TR 21.905 and TS 33.220.

API

Application Programming Interface

BSF

Bootstrapping Server Function

B-TID

Bootstrapping Transaction Identifier

Certification Authority

DNS

Domain Name System

FQDN

Fully Qualified Domain Name

GBA

Generic Bootstrapping Architecture

HTML

HyperText Markup Language

HTTP

HyperText Transfer Protocol

HTTPS

HTTP Over TLS

MBMS

Multimedia Broadcast Multicast Service

Mobile Equipment

NAF

Network Application Function

NAF_ID

NAF identifier

TLS

Transport Layer Security

User Equipment

URL

Uniform Resource Locator

4 Objectives for the Architecture using GBA from a UE web browser p. 7

4.1 Introduction p. 7

The most used authentication method in the Internet today is HTML FORM based authentication. It is commonly used with web browser where a login page is downloaded over HTTPS and which contains an HTML FORM with at least 'username' and 'password' fields.

The current mechanism how GBA could be used from web browser is to use GBA with HTTP Digest as specified in clause 5.3 of TS 33.222. In this case, the GBA enabled web server can detect whether the web browser is able to perform GBA with HTTP Digest by examining the "User-Agent" header. If "3gpp-gba" product token is present in this header, then the web server (NAF) is able to perform GBA with HTTP Digest with the web browser (UE). However, HTTP Digest has one general drawback. In current implementations, once web browser has started to use HTTP Digest with a particular web server, it continues to use it until the browser instance is terminated. This is common behavior in web browsers today.

This means that there is no way of doing a logout as browser keeps on sending the HTTP Digest headers back to the web server. Another drawback is that using HTTP Digest in parallel to HTML FORM based authentication is not straight forward as the authentication happens in different layers of protocols and with different input windows (as web browsers typically implement a dialog window to handle the query HTTP Digest authentication credentials from the end user compared to HTML FORM having query for the credentials implemented as part of the web page itself).

In order to simplify the usage of GBA in web browser this TR outlines the access to GBA in HTML layer, namely using Javascript.

4.2 Objectives p. 7

The document has the following objectives for the usage of GBA in web browsers:

There will be cryptographic separation between different applications using GBA (e.g. MBMS, Presence, browser banking application, browser e-mail application, etc). For non-browser based applications, this is already in use in generic GBA architecture with the usage of NAF specific keys Ks_(ext/int)_NAF with the usage of NAF_Ids and protocol identifiers.
The authentication token for the use of GBA in web browsers will be protected from man-in-the-middle attacks.
The GBA based authentication token will be bound to the existing GBA web session between the browser and the web server in such a way that the authentication tokens cannot be reused in another session or reused by another entity.
The access to NAF specific keys and authentication tokens by JavaScript will be restricted in such a way that a web page executing a Javascript in a web browser will have access to the NAF specific authentication tokens that it is authorized to have access to. For instance, same origin policy could be used so that a Javascript will have access to only that NAF specific authentication tokens that belongs to same origin (e.g. a web page loaded from http://www.3gpp.org/ will have access to only the NAF specific authentication tokens of www.3gpp.org and not be able to request keys or authentication tokens for another origin).