|
TECHNICAL REPORT
Universal Mobile Telelecommunications System ( (UMTS);
LTE;
Study on Secucurity aspects of integration on of
Single Siigng -On (SSO) frameworks
with 3GPP operator-cocontrolled resources and mecechanisms
(3GPP TR 33.9.995 version 13.0.0 Release 13 13)
---------------------- Page: 1 ----------------------
3GPP TR 33.995 version 13.0.0 Release 13 1 ETSI TR 133 995 V13.0.0 (2016-03)
Reference
RTR/TSGS-0333995vd00
Keywords
LTE, 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
http://portal.etsi.org/tb/status/status.asp
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.
© European Telecommunications Standards Institute 2016.
All rights reserved.
TM TM TM
DECT , PLUGTESTS , UMTS and the ETSI logo are Trade Marks of ETSI registered for the benefit of its Members.
TM
3GPP and LTE™ are Trade Marks of ETSI registered for the benefit of its Members and
of the 3GPP Organizational Partners.
GSM® and the GSM logo are Trade Marks registered and owned by the GSM Association.
ETSI
---------------------- Page: 2 ----------------------
3GPP TR 33.995 version 13.0.0 Release 13 2 ETSI TR 133 995 V13.0.0 (2016-03)
Intellectual Property Rights
IPRs essential or potentially essential to the present document 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.
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 "shall", "shall not", "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.995 version 13.0.0 Release 13 3 ETSI TR 133 995 V13.0.0 (2016-03)
Contents
Intellectual Property Rights . 2
Foreword . 2
Modal verbs terminology . 2
Foreword . 4
1 Scope . 5
2 References . 5
3 Definitions and abbreviations . 6
3.1 Definitions . 6
3.2 Abbreviations . 6
4 Relation of the present study to other related work in 3GPP . 6
5 Potential requirements identified in the present study . 7
6 Solutions for Liberty Alliance/SAML – 3GPP interworking . 7
6.1 General . 7
7 Solutions for OpenID – 3GPP interworking . 7
7.1 General . 7
7.2 GBA Lite . 7
7.2.1 Rationale for solution. 7
7.2.2 Solution description . 8
7.2.2.1 Architecture . 8
7.2.2.2 BSF Implementation optimizations . 8
7.2.2.3 Message Flow . 9
7.2.3 Evaluation against SA1 requirements . 10
7.3 Third Party IdP binding for two-factor authentication . 10
7.3.1 Rationale for solution. 10
7.3.3 Solution 1 description . 12
7.3.3.1 General . 12
7.3.3.2 Example solutions for two factor authentication . 14
7.3.4 Solution 2 description . 18
7.3.4.1 Solution based on OpenID-GBA interworking where OTT performs username/password
authentication . 18
7.3.4.2 Solution based on OpenID-GBA interworking where MNO performs both GBA and
username/password authentication . 19
7.3.5 Evaluation against SA1 requirements . 21
7.4 Using user consent for GBA and SSO. 23
7.4.1 Rationale for solution. 23
7.4.2 Solution description . 23
7.4.2.1 General . 23
7.4.2.2 GBA_ME-based solution . 24
7.4.2.3 GBA_U-based solution . 26
7.4.3 Functional Architecture . 28
7.4.4 Evaluation against SA1 requirements . 29
7.5 3rd party SSO identity mapping . 32
7.5.1 Rationale for solution. 32
7.5.2 Solution description . 32
7.5.3 Evaluation against SA1 requirements . 34
8 Conclusions . 36
Annex A: Change history . 37
History . 38
ETSI
---------------------- Page: 4 ----------------------
3GPP TR 33.995 version 13.0.0 Release 13 4 ETSI TR 133 995 V13.0.0 (2016-03)
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.
ETSI
---------------------- Page: 5 ----------------------
3GPP TR 33.995 version 13.0.0 Release 13 5 ETSI TR 133 995 V13.0.0 (2016-03)
1 Scope
The present study investigates the security aspects of the service requirements specified by SA1 in TS 22.101 [11]
clause 26, on the integration of SSO frameworks with 3GPP networks for various operator authentication configurations
(e.g. configurations using GBA or not using GBA).
In particular, this study evaluates existing interworking solutions between SSO frameworks and 3GPP authentication
mechanisms against the SA1 service requirements. The study is not limited to evaluation of existing interworking
solutions and new interworking solutions may be developed as appropriate.
The study covers the security requirements to enable the operator to become the preferred SSO Identity Provider by
allowing the usage of credentials on the UE for SSO services, as well as ways for the 3GPP operator to leverage its trust
framework and its reliable and robust secure credential handling infra-structure to provide SSO service based on
operator-controlled credentials.
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 TR 22.895: "Study on Service aspects of integration of Single Sign-On (SSO) frameworks
with 3GPP operator-controlled resources and mechanisms".
[3] 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)".
[4] 3GPP TR 33.924: "Identity management and 3GPP security interworking; Identity management
and Generic Authentication Architecture (GAA) interworking".
[5] 3GPP TR 33.804: "Single Sign On Application Security for Common IMS – based on SIP Digest".
[6] 3GPP TS 33.220: "Generic Authentication Architecture (GAA); Generic Bootstrapping
Architecture".
[7] 3GPP TS 24.109: "Bootstrapping interface (Ub) and network application function interface (Ua);
Protocol details".
[8] 3GPP TS 29.109: "Generic Authentication Architecture (GAA); Zh and Zn Interfaces based on the
Diameter protocol; Stage 3".
[9] OpenID Foundation "OpenID Authentication 2.0", http://openid.net/.
[10] 3GPP TS 33.222, 'Access to network application functions using Hypertext Transfer Protocol over
Transport Layer Security (HTTPS)'
[11] 3GPP TS 22.101, 'Service aspects; Service principles'.
[12] 3GPP TR 33.905, "Recommendations for trusted open platforms".
ETSI
---------------------- Page: 6 ----------------------
3GPP TR 33.995 version 13.0.0 Release 13 6 ETSI TR 133 995 V13.0.0 (2016-03)
[13] OpenID Foundation "OpenID Provider Authentication Policy Extension 1.0", http://openid.net/.
3 Definitions and abbreviations
3.1 Definitions
For the purposes of the present document, the terms and definitions given in TR 21.905 [1], TS 22.101 [11] 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].
example: text used to clarify abstract rules by applying them literally.
Authorization: a mechanism or process which determines what a particular user or a group of users can access or do.
Multi-factor authentication: a method of logon verification where at least two different factors of proof are provided,
and jointly verified. There are three generally recognized types of authentication factors:
Type 1 - Something You Know. Type 1 includes, but is not limited to, passwords, PINs, combinations, code
words, or secret handshakes. Anything that a user can remember and then type, say, do, perform, or otherwise
recall when needed falls into this category.
Type 2 - Something You Have. Type 2 includes all items that are physical objects, such as, but not limited to,
keys, smart phones, smart cards, USB drives, and token devices. (A token device produces a time-based PIN or
can compute a response from a challenge number issued by the server.)
Type 3 - Something You Are. Type 3 includes any part of the human body that can be offered for verification,
such as, but not limited to, fingerprints, palm scanning, facial recognition, retina scans, iris scans, and voice
verification.
Multi-step authentication: a method of logon verification where the authentication can take several steps or phases to
complete. Multi-step authentication differs from multi-factor authentication in that it does not strictly require that each
authentication factor be different, or that multiple factors are evaluated in conjunction.
3.2 Abbreviations
For the purposes of the present document, the abbreviations given in TR 21.905 [1], TS 22.101 [11] 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].
IdP Identity Provider
RP Relaying Party
SSO Single Sign-On
4 Relation of the present study to other related work in
3GPP
Other SSO related work in 3GPP
Completed SA1 work
- SSO requirements, TS 22.101 [11] clause 26;
- Study on integration of SSO frameworks with 3GPP, TR 22.895[2].
Completed SA3 work
ETSI
---------------------- Page: 7 ----------------------
3GPP TR 33.995 version 13.0.0 Release 13 7 ETSI TR 133 995 V13.0.0 (2016-03)
- Liberty - GBA interworking, TR 33.980 [3];
- OpenID – GBA interworking, TR 33.924 [4].
- SSO with SIP Digest, TR 33.804 [5].
What is the relation of this study to other work in 3GPP
This study evaluates the completed and ongoing SA3 SSO work against the service requirements identified bySA1 in
TS 22.101 [11] clause 26.
All input in this study is intended to have a clear relation to the SA1 service requirements. This study is not intended
duplicate functionality supporting SA1 service requirements, when such functionality can be offered by existing SSO
mechanisms. In particular existing solutions in other SA3 specifications are evaluated and new ones can be proposed
only if the existing solutions would not meet the SA1 service requirements.
5 Potential requirements identified in the present study
The purpose of this clause is to identify potential security requirements in the present study, if any. The requirements
may be general or specific to identified SSO frameworks as seen appropriate.
NOTE: No potential requirements were identified in the present study.
6 Solutions for Liberty Alliance/SAML – 3GPP
interworking
6.1 General
The purpose of this clause is to investigate the existing (and possible new) solutions for interworking of Liberty
Alliance/SAML and 3GPP authentication mechanisms and evaluate the solutions against the SA1 requirements.
NOTE: No solutions were investigated under this clause.
7 Solutions for OpenID – 3GPP interworking
7.1 General
The purpose of this clause is to investigate the existing (and possible new) solutions for interworking of OpenID and
3GPP authentication mechanisms and evaluate the solutions against the SA1 requirements.
7.2 GBA Lite
7.2.1 Rationale for solution
SSO has been identified as one of the most promising applications of GBA. Clearly, the value of this use-case for an
external service provider depends on the number of supporting users. This number in turn depends on the availability of
GBA-capable phones and the number of operators which have deployed the necessary GBA infrastructure
ETSI
---------------------- Page: 8 ----------------------
3GPP TR 33.995 version 13.0.0 Release 13 8 ETSI TR 133 995 V13.0.0 (2016-03)
One way to overcome the initial threshold of supporting users is to simplify the deployment process. This is
accomplished using an SSO specific implementation option of GBA called– GBA Lite. Later on, if an operator finds a
need to support other applications as well, the SSO specific version can be extended to full GBA.
The solution presented here closely follows the GBA and OpenID interworking described in 3GPP TR 33.924 [4]. The
difference is that the BSF and OP are co-located and hence the Zn interface is a matter of internal implementation. This
results in a simpler implementation and deployment. All other nodes and interfaces remain unchanged.
The design goals for GBA Lite were the following:
- A simple migration path to use of full GBA
- The Client/UE and RP (Relying Party) follow TR 33.924 [4] without impact
- Aim for simplicity: keep only the core BSF functionality, remove the rest.
7.2.2 Solution description
7.2.2.1 Architecture
The architecture is identical to 3GPP TR 33.924 [4] Figure 4.3-1 except for the co-location of BSF and OP and the
consequent internalization of the Zn interface.
HSS
Zh
HTTP & DH
OP
RP
BSF
(NAF)
Ub Ua HTTPS
UE
Figure 7.2.2.2-1 GBA Lite Network Architecture
7.2.2.2 BSF Implementation optimizations
No GUSS handling
In ordinary GBA the BSF has to support a wide range of applications with varying options and permissions. In GBA
Lite, however, there is only one application: OpenID. This allows us to simplify both the handling of keys and of GBA
user security settings (GUSS).
Key handling can be simplified since we only need to deal with OpenID specific keys. For example, the NAF identifier
used in the key derivation can be static instead of dynamically determined at the run of the Zn protocol.
The information contained in the GUSS (key lifetime, UICC type, MSISDN etc) can either be statically encoded (key
lifetime) or stored as part of the OpenID user account (UICC type, MSISDN). Typically, the OP will maintain a user
account for each of its users where the OpenID identifier, attributes, and settings are stored.
The Zh interface can be utilized with minimal effort i.e. no support of GBA User Security Settings (GUSS) is required.
ETSI
---------------------- Page: 9 ----------------------
3GPP TR 33.995 version 13.0.0 Release 13 9 ETSI TR 133 995 V13.0.0 (2016-03)
Zn implementation options
Since the Zn interface is internal the vendor or operator is free to choose whatever modifications and optimizations it
sees fit. For example, the BSF can be made stateless if the bootstrapping information (B-TID, keys, etc) is pushed over
Zn and stored in the OP database. Another option is to use a common database backend and replace Zn with two
database calls. Of course, one could also choose not to make any changes and implement the standard Zn interface. The
latter approach makes it easier to migrate to full GBA in the future.
7.2.2.3 Message Flow
The following message flow is identical to the Direct Interworking Scenario in TS 33.924 [4] except for the B-TID
lookup (step 8 below) and a slightly different wording.
Figure 7.2.2.3-1 Interworking message flow for GBA / OpenID
1) The user initiates authentication by presenting a User-Supplied Identifier to the Relying Party via their User-
Agent
2) After normalizing the User-Supplied Identifier, the Relying Party performs discovery on it and establishes the
OP Endpoint URL that the end user uses for authentication.
3) (optional) The Relying Party and the OP establish an association – a shared secret established using Diffie-
Hellman Key Exchange. The OP uses an association to sign subsequent messages and the Relying Party to verify
those messages; this removes the need for subsequent direct requests to verify the signature after each
authentication request/response.
4) The Relying Party redirects the end user's User-Agent to the OP with an OpenID Authentication request
(Requesting Authentication).
5) The OP (NAF) initiates the UE authentication and responds with a HTTPS response code 401 'Unauthorized',
which contains a WWW Authenticate header carrying a challenge requesting the UE to use Digest
Authentication with GBA as specified in TS 33.222 [10] with server side certificates.
ETSI
---------------------- Page: 10 ----------------------
3GPP TR 33.995 version 13.0.0 Release 13 10 ETSI TR 133 995 V13.0.0 (2016-03)
6) If no valid Ks is available, then the UE bootstraps with the BSF as described in TS 33.220, which results in the
possession of the UE of a valid Ks. From this the UE can derive the application specific (OpenID specific)
Ks_(ext/int)_NAF key(s).
7) The UE generates a HTTP GET request to the NAF. The HTTP request carries an authorization header
containing the B-TID received from the BSF and a response digest.
8) Using the B-TID the NAF retrieves the shared application specific NAF key and validates the response digest.
NOTE: Since BSF–OP/NAF interface is internal, several implementation options are possible. E.g. the standard Zn
interface could be implemented.
9) Possibly further interaction where e.g. the user is made aware that he is logging in to RP with OpenID.
10) The OP redirects the end user's User-Agent back to the Relying Party with either an assertion that authentication
is approved or a message that authentication failed.
11) The Relying Party validates the assertion received from the by using either the shared key established during the
association or by sending a direct request to the OP. If the validation is successful, then the user is logged in to
the service of the RP.
7.2.3 Evaluation against SA1 requirements
The collocated GBA architecture shows an easy entry solution for an operator that has not yet deployed GBA, but
would like to have an extensible system.
7.3 Third Party IdP binding for two-factor authentication
7.3.1 Rationale for solution
Enterprises and 'Over-The-Top' application services providers (OTT) need a means of asserting users" identities for
their subsequent authorization. Current use of user ID/password credentials is considered as inadequate security for
value added applications such as mobile payments and access to enterprise applications.
The most widespread two-factor authentication is based on the user"s ID/password as a first authentication factor (for
user"s presence authentication) as well as a hardware-based token as a second authentication factor (confirming a user"s
possession of a physical entity such as a token or device on which such token functionality resides).
When a smartphone containing UICC mutually authenticates with its MNO, reuse of the user"s UICC as a second
authentication factor allows MNOs to become ID Providers (IDP) and inherently provide more security than the sole
use of user ID/password credentials. Existing 3GPP SSO solutions do not provide a means to confirm the presence of a
registered user of a data application, nor do they provide a means for binding (e.g. cryptographically) the results of two
discrete authentication mechanisms.
Traditionally, 3GPP was focusing on the developing the means to authenticate subscriptions, rather than subscribers
(i.e., presence of registered users). Existing SSO solutions do not provide adequate mechanisms to confirm presence of
a registered user, since it is the subscription credentials (vs. User credentials) that are being authenticated by existing
SSO solutions.
Some of the existing solutions might be deemed capable of providing means for two-factor authentication. Their
analysis is presented below.
GBA – Liberty interworking via using GBATwoFactor authentication as described in TS 29.109
TR 33.980 [3] describes 3GPP framework for GBA-Liberty Alliance interworking while not having specific provisions
for multi-factor authentication. TS 29.109 [8] in its informative Annex E defines the following information elements
and with Associated 3GPP URIs and Class schemas for invoking two-factor authentication using interworking with
Liberty Alliance:
GBATwoFactorUnregistered
GBATwoFactorContract
ETSI
---------------------- Page: 11 ----------------------
3GPP TR 33.995 version 13.0.0 Release 13 11 ETSI TR 133 995 V13.0.0 (2016-03)
It is, however, unclear how such authentication proceeds, what entity is the Master IDP, and how the binding of
authentication factors is being achieved. It is presumed that such binding is possible to accomplish.
GBA – OpenID interworking via using PAPE extensions
PAPE (Provider Authentication Policy Extension) [13] defines a mechanism which allows an OpenID Relying Party to
achieve the following:
- request identity providers to use specific authentication policies when authenticating a user.
- require an identity provider to inform the relying party of the authentication policies used during aut
...