|
TECHNICAL REPORT
Digital cellular telecommunications system (Phase 2+) (GSM);
Universal Mobile Telecommunications System (UMTS);
LTE;
Identity management and 3GPP security interworking;
Identity management and
Generic Authentication Architecture (GAA) interworking
(3GPP TR 33.924 version 15.0.0 Release 15)
---------------------- Page: 1 ----------------------
3GPP TR 33.924 version 15.0.0 Release 15 1 ETSI TR 133 924 V15.0.0 (2018-07)
Reference
RTR/TSGS-0333924vf00
Keywords
GSM,LTE,SECURITY,UMTS
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
The present document can be downloaded from:
The present document may be made available in electronic versions and/or in print. The content of any electronic and/or
print versions of the present document shall not be modified without the prior written authorization of ETSI. In case of any
existing or perceived difference in contents between such versions and/or in print, the only prevailing document is the
print of the Portable Document Format (PDF) version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at
If you find errors in the present document, please send your comment to one of the following services:
Copyright Notification
No part may be reproduced or utilized in any form or by any means, electronic or mechanical, including photocopying
and microfilm except as authorized by written permission of ETSI.
The content of the PDF version shall not be modified without the written authorization of ETSI.
The copyright and the foregoing restriction extend to reproduction in all media.
© ETSI 2018.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are trademarks of ETSI registered for the benefit of its Members.
TM TM
3GPP and LTE are trademarks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
oneM2M logo is protected for the benefit of its Members.
GSM and the GSM logo are trademarks registered and owned by the GSM Association.
ETSI
---------------------- Page: 2 ----------------------
3GPP TR 33.924 version 15.0.0 Release 15 2 ETSI TR 133 924 V15.0.0 (2018-07)
Intellectual Property Rights
Essential patents
IPRs essential or potentially essential to normative deliverables may have been declared to ETSI. The information
pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found
in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in
respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web
server (https://ipr.etsi.org/).
Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee
can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web
server) which are, or may be, or may become, essential to the present document.
Trademarks
The present document may include trademarks and/or tradenames which are asserted and/or registered by their owners.
ETSI claims no ownership of these except for any which are indicated as being the property of ETSI, and conveys no
right to use or reproduce any trademark and/or tradename. Mention of those trademarks in the present document does
not constitute an endorsement by ETSI of products, services or organizations associated with those trademarks.
Foreword
This Technical Report (TR) has been produced by ETSI 3rd Generation Partnership Project (3GPP).
The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or
GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables.
The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under
.
Modal verbs terminology
In the present document "should", "should not", "may", "need not", "will", "will not", "can" and "cannot" are to be
interpreted as described in clause 3.2 of the ETSI Drafting Rules (Verbal forms for the expression of provisions).
"must" and "must not" are NOT allowed in ETSI deliverables except when used in direct citation.
ETSI
---------------------- Page: 3 ----------------------
3GPP TR 33.924 version 15.0.0 Release 15 3 ETSI TR 133 924 V15.0.0 (2018-07)
Contents
Intellectual Property Rights . 2
Foreword . 2
Modal verbs terminology . 2
Foreword . 4
Introduction . 4
1 Scope . 5
2 References . 5
3 Definitions, symbols and abbreviations . 6
3.1 Definitions . 6
3.2 Abbreviations . 6
4 Interworking of OpenID and GAA . 7
4.1 Introduction . 7
4.2 Architectural Descriptions . 7
4.2.1 Generic Bootstrapping Architecture . 7
4.2.2 OpenID Architecture. 8
4.3 NAF and OpenID-IdP Co-location . 10
4.4 Message Flow for Interworking Scenario . 11
4.4.1 Message Flow for direct GBA Interworking Scenario. 11
4.4.2 Message Flow for Split Terminal GBA Interworking Scenario . 13
4.4.2.1 General . 13
4.4.2.2 Differentiating between Scenarios . 14
4.4.2.3 Scenarios not using cryptographic binding . 14
4.4.2.4 Scenarios using cryptographic binding . 23
4.5 Mapping of Concepts . 33
4.5.1 Identifiers in OpenID and GBA . 33
4.5.2 Asociation Session Concept . 35
4.5.3 Assertions . 35
4.5.3.1 Positive Assertions . 35
4.5.3.2 Negative Assertions . 35
4.6 Use of GUSS and USS for OpenID . 35
Annex A (informative): Example for Charging via IdP . 37
Annex B: Change history . 40
History . 41
ETSI
---------------------- Page: 4 ----------------------
3GPP TR 33.924 version 15.0.0 Release 15 4 ETSI TR 133 924 V15.0.0 (2018-07)
Foreword
rd
This Technical Report has been produced by the 3 Generation Partnership Project (3GPP).
The contents of the present document are subject to continuing work within the TSG and may change following formal
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an
identifying change of release date and an increase in version number as follows:
Version x.y.z
where:
x the first digit:
1 presented to TSG for information;
2 presented to TSG for approval;
3 or greater indicates TSG approved document under change control.
y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections,
updates, etc.
z the third digit is incremented when editorial only changes have been incorporated in the document.
Introduction
3GPP SA3 outlined the interworking of the operator controlled GBA with the Liberty Alliance Identity Management.
This was sufficient for the time of writing, but now new additional systems are deployed and used. If we want to enable
interworking of operator centric identity management, then smooth interworking with those new systems need to be
outlined. If this is not done, then a seamless interworking is not possible on global scale and it would be difficult to
leverage the existing customer base and security level that operators have.
ETSI
---------------------- Page: 5 ----------------------
3GPP TR 33.924 version 15.0.0 Release 15 5 ETSI TR 133 924 V15.0.0 (2018-07)
1 Scope
The objective is to extend the current identity management as outlined in TS 33.220, TS 33.222, TS 29.109 and TR
33.980 with the latest developments on identity management outside of the 3GPP sphere. This will allow a better
integration and usage of identity management for services in 3GPP and seamless integration with existing services that
are not standardized in 3GPP. This report outlines the interworking of GBA and OpenID.
2 References
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] 3GPP TR 21.905: "Vocabulary for 3GPP Specifications".
[2] 3GPP TS 33.220: "Generic Authentication Architecture (GAA); Generic Bootstrapping
Architecture".
[3] 3GPP TS 24.109: "Bootstrapping Interface (Ub) and Network Application Function Interface (Ua);
Protocol Details".
[4] 3GPP TR 33.980: "Interworking of Liberty Alliance Identity Federation Framework (ID-FF),
Identity Web Service Framework (ID-WSF) and the Generic Authentication Architecture (GAA)".
[5] 3GPP TS 33.222: "Generic Authentication Architecture (GAA); Access to network application
functions using Hypertext Transfer Protocol over Transport Layer Security (HTTPS)".
[6] 3GPP TS 33.223: "Generic Bootstrapping Architecture (GBA) Push Function".
[7] 3GPP TS 29.109: "Generic Authentication Architecture (GAA); Zh and Zn Interfaces based on the
Diameter Protocol; Stage 3".
[8] OpenID Foundation "OpenID Authentication 2.0", http://openid.net/.
[9] OpenID Foundation "OpenID Attribute Exchange 1.0", http://openid.net/.
[10] OpenID Foundation "OpenID Provider Authentication Policy Extension 1.0", http://openid.net/.
[11] OASIS Reed, D.; McAlpin, D.: "Extensible Resource Identifier (XRI) Syntax v2.0";
http://www.oasis-open.org/
[12] OpenID Foundation, http://openid.net/foundation/
[13] OpenID Site Directory, http://openiddirectory.com/
[14] 3GPP TS 33.259: "Key Establishment between a UICC hosting device and a remote device".
[15] IETF RFC 4006, "Diameter Credit Control", http://tools.ietf.org/html/rfc4006
[16] W3C, "HTML 4.01 Specification", http://www.w3.org/TR/html401/
[17] IETF RFC 2617 (1999): "HTTP Authentication: Basic and Digest Access Authentication".
[18] IETF RFC 3761 (2004): "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation
Discovery System (DDDS) Application (ENUM)".
ETSI
---------------------- Page: 6 ----------------------
3GPP TR 33.924 version 15.0.0 Release 15 6 ETSI TR 133 924 V15.0.0 (2018-07)
3 Definitions, symbols and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in TR 21.905 [1] 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 [1].
The GAA / GBA specific definitions are originated from [2] and the OpenID definitions are originated from [8]. In case
of conflict [2] and [8] take precedence.
Attribute: An attribute is used in the OpenID Attribute Exchange service extension [9]. This extension provides a
mechanism for moving identity related information between sites. An attribute is associated with a Subject Identifier.
An attribute has a type identifier and a value. An attribute type identifier is a URI. An attribute value can be any kind of
data.
Bootstrapping Server Function (BSF): A Bootstrapping Server Function (BSF) is hosted in a network element under
the control of an MNO. BSF, HSS/HLR, and UEs participate in GBA in which a shared secret is established between
the network and a UE by running a bootstrapping procedure. The shared secret can be used between NAFs and UEs, for
example, for authentication purposes.
GBA User Security Settings: GUSS contains the BSF specific information element and the set of all application-
specific USSs.
Identifier: An Identifier in OpenID is either an "http" or "https" URL, or an XRI [11]. OpenID [8] defines various
kinds of identifiers depending on the context.
Network Application Function (NAF): A NAF is hosted in a network element. GBA may be used between NAFs and
UEs for authentication purposes, and for securing the communication path between the UE and the NAF.
OpenID Provider (OP): An OpenID Provider (OP) is an OpenID Authentication Server on which a Relying Party
relies for an assertion that the end user controls an Identifier.
OpenID Provider driven identifier selection: OpenID Provider driven identifier selection is the ability for a user to
enter the URL of their OpenID Provider into an OpenID field rather than their personal OpenID URL. This allows the
web site (RP) to start the OpenID authentication flow and send the user over to the correct OpenID provider. The user
can then authenticate to the OpenID provider, select a particular OpenID URL and persona if they have multiple, This
will result in an actual user OpenID URL or an anonymous OpenID URL being returned to the RP.
OP Endpoint URL: The URL which accepts OpenID Authentication protocol messages, obtained by performing
discovery on the User-Supplied identifier. This value must be an absolute HTTP or HTTPS URL.
Relying Party (RP): A Relying Party is a web application that wants a proof that the end user controls an Identifier.
User Supplied Identifier: An Identifier that was presented by the end user to the RP, or selected by the user at the
OpenID Provider. During the initiation phase of the protocol, an end user may enter either their own Identifier or an OP
Identifier. If an OP Identifier is used, the OP may then assist the end user in selecting an Identifier to share with the RP.
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in TR 21.905 [1] 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 [1].
AKA Authentication and Key Agreement Protocol
AV Authentication Vector
BSF Bootstrapping Server Function
IdP Identity Provider
GAA Generic Authentication Architecture
GBA Generic Bootstrapping Architecture
GPI GBA Push Information
GUSS GBA User Security Settings
HLR Home Location Register
HSS Home Subscriber Server
ETSI
---------------------- Page: 7 ----------------------
3GPP TR 33.924 version 15.0.0 Release 15 7 ETSI TR 133 924 V15.0.0 (2018-07)
ME Mobile Equipment
MNO Mobile Network Operator
NAF Network Application Function
OP OpenID Provider
PAPE Provider Authentication Policy Extension
RP Relying Party
SLF Subscriber Locator Function
SP Service Provider
UE User Equipment
USS User Security Settings
4 Interworking of OpenID and GAA
4.1 Introduction
In this chapter we outline how the Generic Authentication Architecture, in particular, the Generic Bootstrapping
Architecture (GBA) as specified in [2] can be utilized by the OpenID protocol as specified by [8]. The focus will lie on
the impact to the network nodes of the Mobile Network Operator (MNO) and the service providers, the supported
protocols and the message flows.
The general setting for the GBA – OpenID interworking is quite similar to the GBA – Liberty Alliance Interworking as
outlined in [4]. The major difference is that OpenID as currently specified is more lightweight than the Liberty Alliance
Web Service and Identity Federation Framework and therefore many well-known service providers have chosen
OpenID for their identity management solution.
4.2 Architectural Descriptions
4.2.1 Generic Bootstrapping Architecture
In this section, we give a brief overview of the Generic Bootstrapping Architecture as described in TS 33.220 [2]. GBA
enables automatic provisioning of shared keys between a User Equipment (UE) and an application server (Network
Application Function (NAF)). The Home Subscriber Server (HSS) contains the long-term subscriber key. The
Bootstrapping Server Function (BSF) is a GBA specific network function that resides in the home MNO of the user. It
facilitates the use of AKA to bootstrap a new GBA master session key named Ks. The Subscriber Locator Function
(SLF) is queried by the BSF in conjunction with the Zh interface operation to get the name of the HSS containing the
required subscriber specific data.
HSS
Dz
Zh Zn
SLF BSF
NAF
Ub Ua
UE
Figure 4.2.1 Simple Network Architecture for GBA
ETSI
---------------------- Page: 8 ----------------------
3GPP TR 33.924 version 15.0.0 Release 15 8 ETSI TR 133 924 V15.0.0 (2018-07)
The basic message flow is as follows (for all details, parameter, formats, key derivation and error cases see [2] TS
33.220 section 4.5.2, which takes also precedence in case of conflict).
1. The UE sends a bootstrapping HTTP request towards the BSF over Ub reference point. The User-Supplied Identifier
may be an OP Identifier, which allows the use of OpenID Provider driven identifier selection.
2. The BSF determines the IMPI based on the request. If there are several HSS the BSF may consult the SLF to
determine the name of the correct HSS for this user.
The BSF retrieves the complete set of GBA user security settings (GUSS) and one Authentication Vector AV over
the reference point Zh from the HSS. The BSF might use a local copy of the GUSS (for details see [2]).
The GUSS is optional to support in [2], but if GBA_U is intended to be used by the NAF, then the GUSS must be used.
In the case that no HSS with Zh reference point is deployed, the BSF retrieves the Authentication Vector over the
reference point Zh' from either an HLR or an HSS with Zh' reference point support.
3. Then BSF forwards the RAND and AUTN to the UE in the 401 message. This is to demand the UE to authenticate
itself.
4. The UE checks AUTN to verify that the challenge is from an authorised network; the UE also calculates CK, IK and
RES. This will result in session keys IK and CK in UE.
5. The UE sends another HTTP request, containing the Digest AKA response (calculated using RES), to the BSF.
6. The BSF authenticates the UE by verifying the Digest AKA response.
7. The BSF generates the master key material Ks by concatenating CK and IK. The BSF generates also the application
specific keys Ks_(ext/int)_NAF. The bootstrapping transaction identifier B-TID value shall be also generated.
8. The BSF shall send a 200 OK message, including a B-TID, to the UE to indicate the success of the authentication. In
addition, in the 200 OK message, the BSF shall supply the lifetime of the key Ks. The key material Ks is generated in
UE.
9. Both the UE and the BSF shall use the Ks to derive the application specific key material Ks_NAF during the
procedures as specified in clause 4.5.3 of [2]. Ks_NAF shall be used for securing the reference point Ua, in our case the
authentication to the OP. If GBA_U is used, then the Ks_ext_NAF should be used for securing the Ua reference point.
The UE and the BSF shall store the key Ks with the associated B-TID for further use, until the lifetime of Ks has
expired, or until the key Ks is updated or until the deletion conditions are satisfied (see 4.4.11 in [2]).
GBA is used by many services like MBMS (Multimedia Broadcast Multicast Service), Enhanced MBMS, Access
Network Discovery and Service Function (ANDSF), Open Mobile Alliance (OMA) XML Document Management,
Presence Security etc. GBA can use USIM with GBA_U aware UICC application, ISIM or SIM cards. GBA and
OpenID are independent of each other and the message flow above is given to introduce how GBA works and to ease
the understanding for the interworking.
4.2.2 OpenID Architecture
The OpenID protocol [9] is specified by the OpenID Foundation [12]. It utilizes URL based Identifier.
ETSI
---------------------- Page: 9 ----------------------
3GPP TR 33.924 version 15.0.0 Release 15 9 ETSI TR 133 924 V15.0.0 (2018-07)
OpenID Relying
Provider Party
OP RP
HTTP-based
Diffie-Hellmann
Key Exchange
(optional)
HTTP / S
HTTP / S
UE
Figure 4.2.2 Simple OpenID Network Architecture
OpenID is HTTP POST and REPLY based. The basic message flow is as follows (for details and message parameters
see OpenID Authentication 2.0 [8], which also takes precedence in case of conflict):
To initiate OpenID Authentication, the Relying Party should present the end user with a form that has a field for
entering a User-Supplied Identifier. The form field's "name" attribute should have the value "openid_identifier".
1. The browser in the UE sends a User-Supplied Identifier to the Relying Party.
2. The User-Supplied Identifier is normalized as described in Appendix A1 of [8]. The RP retrieves the address
of the OP and performs a discovery of the OP Endpoint URL (based on the User-Supplied Identifier) that the end
user wishes to use for authentication.
3. The RP and the OP may then establish a shared secret (called association) using the Diffie-Hellman Key
Exchange Protocol [8]. The purpose of this shared secret is that the OP may sign subsequent messages and the
RP can verify those messages.
NOTE1: This association is an optional feature in [8] and not required for interworking purposes.
4. The RP redirects the UE’s browser to the OP with an OpenID Authentication Request as defined in [8].
5. The OP establishes whether the end user is authorized to perform OpenID Authentication and wishes to do so.
NOTE2: [8] does not specify the manner and protocol used for authentication. In clause 4.4 we will outline how
GBA based authentication using TS 33.222 [5] fits in here.
6. The OP redirects the UE’s browser back to the RP with either an assertion that authentication is approved or a
message that authentication failed.
7. The RP verifies the information received from the OP. The user is now authenticated.
NOTE3: This Technical Report describes the interworking with OpenID version 2.0. If OpenID Authentication
version 1.0 is used, then it should be noted that this specification was quickly replaced by OpenID
Authentication version 1.1. OpenID version 1.1 made it clearer what was mandatory and what was
optional to support. OpenID Authentication version 2.0 was a larger step forward. It allows usage of XRI
to discover the OP, which was not possible in OpenID Authentication version 1.1. It has been reported
that some OpenID Authentication version 1.1 implementations support XRIs. OpenID Authentication
version 2.0 mandates the usage of the opened.ns field in the HTTP requests. If the value is absent or set
to "http//openid.net/signon/1.1" or "http//openid.net/signon/1.0" instead of
"http//specs.openid.net/auth/2.0", then the message should be interpreted using OpenID Authentication
1.1 Compatibility mode.
ETSI
---------------------- Page: 10 ----------------------
3GPP TR 33.924 version 15.0.0 Release 15 10 ETSI TR 133 924 V15.0.0 (2018-07)
4.3 NAF and OpenID-IdP Co-location
The straightforward approach to combine the GBA and the OpenID Architectures is to co-locate the NAF functionality
with the OP. The NAF functionality may be added in form of a library to the OpenID server.
NOTE: Other co-location approaches may require that the OP server has to support Diameter based reference
point. The OPs as today are not telecommunication network nodes and hence it can not be assumed that
they support the Diameter and underlying protocols just for the purpose of interworking with GBA.
HSS
HTTP &
Dz
Zh Zn
DH Protocol
SLF BSF
NAF OP
RP
Ua
HTTPS
HTTPS
Ub
UE
Figure 4.3-1 Simple OpenID Network Architecture
The dashed lines indicate the interfaces which originate from the OpenID architecture and the full lines are from the
GBA Architecture. The UE utilizes the browser to communicate with the OP. The Ua protocol should be based on TS
24.109 [3] and TS 33.222 [5] section 5.3 and be supported by OP/NAF and UE. The OP/NAF and UE may support the
variants of [5] clause 5.4 and 5.5. Even if the figure above shows two interfaces between the NAF/OP and the UE, there
is actually only one, since the Ua is the application protocol, which in this case is the OpenID HTTPS protocol.
TS 33.222 [5] only allows the use of HTTPS (i.e. HTTP over TLS). The terminal uses one connection to the NAF/OP
server i.e. Ua and the connection to the OP share the same TLS session. Hence only HTTPS shall be used on the
connection from the UE to the OP. Due to re-directs this implies that the connection to the RP should also be HTTPS
based.
ETSI
---------------------- Page: 11 ----------------------
3GPP TR 33.924 version 15.0.0 Release 15 11 ETSI TR 133 924 V15.0.0 (2018-07)
HSS
HTTP &
Dz
Zh Zn
DH Protocol
SLF BSF
NAF OP
RP
HTTPS
Ua / Upa
HTTPS
Ub
BA
Local interface
AA
Figure 4.3-2 OpenID Network Architecture in split terminal scenario
In the split terminal scenario, the browser and the entity performing the authentication do not reside in the same
physical instance. The former UE is here split into a Browsing Agent (BA) that for example may reside in a PC and an
Authenticating Agent (AA) that resides in the ME. In the split terminal scenario, the BA and AA do not share the same
connection to the OP/NAF. The connections from the BA to the OP and RP should use HTTPS if the BA has HTTPS
capabilities.
As above, the dashed lines indicate the interfaces which originate from the OpenID architecture and the full lines are
from the GBA Architecture. The BA utilizes the browser to communicate with the OP. Depending on the scenario the
BA and the AA may communicate by a local int
...