Generic Bootstrapping Architecture (GBA) Push Function

3GPP TS 33.223 V9.2.0 (2015-06)
Technical Specification
3rd Generation Partnership Project;
Technical Specification Group Services and System Aspects;
Generic Authentication Architecture (GAA);
Generic Bootstrapping Architecture (GBA) Push function 
(Release 9)
 

	 EMBED Word.Picture.8  

The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP.	
The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented.	
This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification.
Specifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices.



Keywords
LTE, GSM, UMTS, security

3GPP
Postal address

3GPP support office address
650 Route des Lucioles - Sophia Antipolis
Valbonne - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Internet
http://www.3gpp.org

Copyright Notification
No part may be reproduced except as authorized by written permission.
The copyright and the foregoing restriction extend to reproduction in all media.

© 2015, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC).
All rights reserved.

UMTS™ is a Trade Mark of ETSI registered for the benefit of its members
3GPP™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners
LTE™ is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners
GSM® and the GSM logo are registered and owned by the GSM Association

Contents
 TOC \o "1-9" Foreword	 PAGEREF _Toc257758421 \h 4
Introduction	 PAGEREF _Toc257758422 \h 4
1	Scope	 PAGEREF _Toc257758423 \h 5
2	References	 PAGEREF _Toc257758424 \h 5
3	Definitions, symbols and abbreviations	 PAGEREF _Toc257758425 \h 6
3.1	Definitions	 PAGEREF _Toc257758426 \h 6
3.2	Abbreviations	 PAGEREF _Toc257758427 \h 6
4	GBA Push Architecture	 PAGEREF _Toc257758428 \h 7
4.1	Introduction	 PAGEREF _Toc257758429 \h 7
4.1.1	General	 PAGEREF _Toc257758430 \h 7
4.1.2 	GBA-Push system overview	 PAGEREF _Toc257758431 \h 7
4.2	GBA Push Architecture	 PAGEREF _Toc257758432 \h 8
4.2.1	Description and Rationale	 PAGEREF _Toc257758433 \h 8
4.2.2	GBA-Push keying model	 PAGEREF _Toc257758434 \h 9
4.3	GBA Push Requirements	 PAGEREF _Toc257758435 \h 9
4.3.1	General GBA Push Requirements	 PAGEREF _Toc257758436 \h 9
4.3.2	Requirements on HSS and HLR	 PAGEREF _Toc257758437 \h 10
4.3.3	Requirements on BSF	 PAGEREF _Toc257758438 \h 10
4.3.4	Requirements on UE	 PAGEREF _Toc257758439 \h 10
4.3.5	Requirements on Reference Point Upa	 PAGEREF _Toc257758440 \h 10
4.3.6	Requirements on Reference Point Zh	 PAGEREF _Toc257758441 \h 10
4.3.7	Requirements on Reference Point Zpn and Zpn'	 PAGEREF _Toc257758442 \h 10
4.3.8	Requirements on Zn-Proxy	 PAGEREF _Toc257758443 \h 12
4.3.9	Requirements on Reference Point Ua	 PAGEREF _Toc257758444 \h 12
4.3.10	Requirements on NAF SA identifiers	 PAGEREF _Toc257758445 \h 12
4.3.11	Requirements on Reference Point Dz	 PAGEREF _Toc257758446 \h 12
5	GBA Push Function	 PAGEREF _Toc257758447 \h 12
5.1	GBA Push Message Flow and Processing	 PAGEREF _Toc257758448 \h 12
5.1.1	GBA Push Message Flow	 PAGEREF _Toc257758449 \h 12
5.1.2	NAF processing before issuing GPI request	 PAGEREF _Toc257758450 \h 14
5.1.3	BSF processing of NAF GPI request	 PAGEREF _Toc257758451 \h 14
5.1.4	UE processing of GPI	 PAGEREF _Toc257758452 \h 15
5.2	Data objects	 PAGEREF _Toc257758453 \h 17
5.2.1	GBA Push Information (GPI)	 PAGEREF _Toc257758454 \h 17
5.2.2	NAF SA identities	 PAGEREF _Toc257758455 \h 17
5.2.3	NAF SA	 PAGEREF _Toc257758456 \h 17
5.3	GPI Integrity and Confidentiality Protection	 PAGEREF _Toc257758457 \h 18
5.3.1	General considerations	 PAGEREF _Toc257758458 \h 18
5.3.2	Key material generation	 PAGEREF _Toc257758459 \h 18
5.3.3	GPI Integrity protection	 PAGEREF _Toc257758460 \h 19
5.3.4	GPI Confidentiality protection	 PAGEREF _Toc257758461 \h 19
5.3.5	GPI message format and coding	 PAGEREF _Toc257758462 \h 19
5.4	Procedures using the NAF SA	 PAGEREF _Toc257758463 \h 20
Annex A (informative):	Rationale behind choice of the Disposable-Ks model	 PAGEREF _Toc257758464 \h 21
Annex B (normative):	GBA-Push UE registration procedure	 PAGEREF _Toc257758465 \h 22
Annex Z (informative):	Change history	 PAGEREF _Toc257758466 \h 23

Foreword
This Technical Specification has been produced by the 3rd 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 defined the Generic Authentication Architecture (GAA). The adoption of GAA by other standardization bodies showed that some services can not make the assumption that the User Equipment (UE) has always the possibility to connect to the Bootstrapping Server Function (BSF) or that the UE for different reasons has not performed a bootstrapping procedure directly with the BSF. Hence, this specification introduces and specifies a GBA Push Function. 
1	Scope
The present document specifies a Push Function as a functional add-on for the Generic Authentication Architecture (GAA) [1]. 
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 TS 33.220: "Generic Authentication Architecture (GAA); Generic bootstrapping architecture".
[2]	3GPP TR 21.905: "Vocabulary for 3GPP Specifications".
[3]	3GPP TS 33.210: "3G Security; Network Domain Security; IP network layer security".
[4]	IETF RFC 2246 (1999): "The TLS Protocol Version 1".
[5]	Void.
[6]	3GPP TS 33.102: "3G Security; Security architecture".
[7]	FIPS PUB 180-2 (2002): "Secure Hash Standard".
[8]	IETF RFC 2104 (1997): "HMAC: Keyed-Hashing for Message Authentication".
[9]	ISO/IEC 10118-3:2004: "Information Technology – Security techniques – Hash-functions – Part 3: Dedicated hash-functions".
[10]	NIST Special Publication 800-38A: "Recommendation for Block Cipher Modes of Operation"
[11]	FIPS PUB 197: "Advanced Encryption Standard"
[12]	Void
[13]	3GPP TS 33.222 "Access to network application functions using Hypertext Transfer Protocol over Transport Layer Security (HTTPS)".
[14]	3GPP TS 29.109 "Generic Authentication Architecture (GAA); Zh and Zn Interfaces based on the Diameter protocol; Stage 3".
[15]	3GPP TS 33.224 "Generic Authentication Architecture (GAA); Generic Bootstrapping Architecture (GBA) Push Layer".
[15]	3GPP TS 31.101 "UICC-terminal interface; Physical and logical characteristics".
[16]		IETF RFC 4330: "Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI".
3	Definitions, symbols and abbreviations
3.1	Definitions
For the purposes of the present document, the terms and definitions given in TR 21.905 [2], TS 33.220 [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 [2].
AUTN(*): In GBA context, GBA_ME relies on AUTN value to verify that the authentication vector is from an authorised network, while GBA_U relies on AUTN* to perform network authentication as described in [1]. AUTN(*) is used to refer both to AUTN and AUTN*.
Disposable-Ks model: The keying model used in GBA-push. Only one NAF-key is generated per Ks and the Ks cannot be reused. 
GBA_U aware UICC: A UICC which supports GBA_U which means that the Ks will never leave the UICC. 
GBA-Push-Info: GBA-Push-Info contains data relevant for key derivation in GBA Push. GBA-Push_Info is sent via the Upa-reference point from the NAF to the UE.
NAF_Id: The FQDN of the NAF, concatenated with the Ua security protocol identifier,
NAF-key: A NAF-key derived from Ks. It can be used to refer to Ks_(int/ext)_NAF or Ks_NAF.
NAF SA: A security association between a NAF and a UE based on a NAF-key.
Push-message: This is a message that is sent on a Ua-reference point from the NAF to the UE and has applied GBA keys that were bootstrapped via the Upa-reference point.
Push-NAF: A NAF authorized for using GBA-Push.
UE_Trp: The transport address used for delivery of GPI to the UE.
3.2	Abbreviations
For the purposes of the present document, the abbreviations given in TR 21.905 [2] 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 [2].
BSF	Bootstrapping Server Function
B-TID	Bootstrapping Transaction Identifier
FQDN	Fully Qualified Domain Name
GAA	Generic Authentication Architecture
GBA	Generic Bootstrapping Architecture 
GBA_ME	ME-based GBA
GBA_U	GBA with UICC-based enhancements
GPI	GBA Push Info
GUSS	GBA User Security Settings
HLR	Home Location Register
HSS	Home Subscriber Server
Ks_NAF	NAF-key in GBA_ME mode
Ks_int_NAF	UICC internal NAF-key in GBA_U
Ks_ext_NAF	UICC external NAF-key in GBA_U
ME	Mobile Equipment
NAF	Network Application Function
P-TID	Push Temporary Identifier
SA	Security Association
UE	User Equipment
USS	User Security Setting
4	GBA Push Architecture
4.1	Introduction
4.1.1	General
GBA-push is a mechanism to bootstrap the security between a NAF and a UE, without forcing the UE to contact the BSF to initiate the bootstrapping. GBA-Push is closely related to and builds upon GBA as specified in TS 33.220 [1]. GBA-Push is aimed for both GBA_U and GBA_ME environments. 
4.1.2 	GBA-Push system overview
The system overview in this clause gives a high level description of the general ideas behind the GBA-Push system solution and the features it offers.
The generic use case considered is that a NAF initiate's establishment of a shared Security Association (SA), a NAF SA, between itself and a UE. This is done by the NAF pushing all information, the so called GBA-Push-Info (GPI), needed for the UE to set-up the SA. The key in this SA is a NAF-key and the GPI is requested from the BSF. The NAF-key is generated as defined in GBA, TS 33.220 [1]. 
After the NAF SA establishment, the NAF can send protected Push-messages to the UE. If a return channel exists and if defined by the Ua application, the UE can also use the established SA to protect response messages to the initiating NAF How the NAF SA is used is out of scope for this specification. The NAF SA is identified by downlink and uplink SA identifiers. 
GBA-Push is aimed for both GBA_U and GBA_ME environments. To only establish an external NAF-key with GBA-Push, the ME-based functionality, GBA_ME, should be used. GBA-Push based on GBA_U will establish both an internal and external NAF-key.
GBA-Push utilizes a so called Disposable-Ks model. In the Disposable-Ks model, a Ks is only used once to derive a single set of NAF-keys (and other keying material used to protect the GPI during transport). After the NAF-key derivation, the Ks is erased or its further usage is denied. A new GBA-Push operation will be needed whenever a new set of NAF-keys for the same or another NAF is needed. 
NOTE 1: 	A generated NAF-key can be used to protect multiple Push-messages from the NAF to the UE. NAF-keys from different NAFs can coexist.
With the Disposable-Ks model, existing NAF-keys established as specified in TS 33.220 [1] or by GBA-Push will be unaffected. GBA_ME based GBA-Push will not interact with GBA_U but a GBA_U based GBA Push will invalidate an existing Ks on the UICC.
NOTE 2:	TS 33.220 [1] specifies that an existing Ks on the UICC will be overwritten when a new GBA_U Ks-generation procedure is executed. The ME may of course trigger a new bootstrap procedure immediately after the GBA-Push operation to avoid delays and certain synch problems when the UE operates GBA according to TS33.220 [1].
The transport method of GPI from a NAF to a UE is not standardized.
NOTE 3: 	Examples of possible transport methods are SMS, MMS, SIP MESSAGE, UDP or broadcast. For the transport of GPI to UEs, a NAF needs to know the message transport addresses to use for the chosen transport method. For SMS and MMS the transport address is the MSISDN, for SIP MESSAGE it is an IMPU and for UDP an UDP port - IP-address pair. For broadcast delivery the UE transport addresses could be any public identity associated with a UE or an identity agreed between the NAF and the UE. 
Resending of messages is a standard method to get "reliability" for delivery over unreliable channels like e.g. SMS or broadcast. Hence the GBA-Push shall allow that GPI is retransmitted several times including cases when it is sent every time a payload is pushed to the UE. Thus the system shall handle retransmissions of GPI efficiently.
The NAF SA defined by the GPI, is based on the use of a particular UICC (USIM/ISIM) application. Sometimes the transport method / address indicate to the UE which UICC application to use but in other cases it has to be explicitly signaled. If MSISDN is used as delivery address, then the USIM associated with that MSISDN should be used. This is so because a SMS will only reach the UE when the USIM corresponding to the MSISDN is active in the UE. When an IMPU is used as destination address, the corresponding ISIM should be used. For UDP and broadcast the USIM/ISIM application to use has to be indicated in the GPI or be agreed upon out of band.
To protect user privacy, parts of the GPI shall be confidentiality protected, in particular the identity of the initiating NAF when broadcast transport is used. For unlinkability between NAF to UE and UE to NAF messages, a separate SA identity for UE to NAF security shall be assigned by the NAF and be included in the confidentiality protected part of the GPI. To help prevent serious effects of DoS attacks and thwart some NAF misuse of GBA-Push, the GPI also needs to be integrity protected. The integrity protection of GPI will also prevent that incorrect GBA Push security associations are accepted by the UE as it will detect transmission errors. The keys for confidentiality and integrity protection are derived from the Ks defined by the GPI.
4.2	GBA Push Architecture 
4.2.1	Description and Rationale
The GBA Push functionality builds on the architecture and functionality provided by TS 33.220 [1]. The main difference from TS 33.220 [1] is the definition of new reference points between the BSF and the NAF and between the NAF and the UE, as indicated in figure 4.2-1, which is a modified version of figure 4.1 in TS 33.220 [1].
 EMBED Word.Document.8 \s 
Figure 4.2-1: Simple network model for pushed bootstrapping via NAF
The GBA Push architecture outlined in figure 4.2-1 is based on the following rationales:
-	The Ua reference point protection shall be unaffected i.e. it should not make any difference for Ua-protocols whether the GBA-keys used for protection are UE-initiated or push-initiated. 
-	In viewpoint of the BSF, the NAF is still the initiating entity of a key retrieval, but now in situations where the NAF has no B-TID (but the UE may have a valid GBA session). A Zpn reference point is introduced, based on the Zn-reference point protocols defined by TS 33.220 [1].
-	A new reference point Upa is introduced between the NAF and the UE. All messages over Upa are network initiated. Upa defines the GBA-Push-Info. 
- 	The NAF receives the GBA-Push-Info intended for the UE from the BSF over the Zpn reference point and forwards it over Upa. 
4.2.2	GBA-Push keying model
The Disposable-Ks model is the keying model used in GBA-Push. In the Disposable-Ks model, a Ks is only used once to derive a single set of NAF-keys (and other keying material used to protect the GPI during transport, see clause 5.3). After the NAF-key derivation, the Ks is erased or its further use is denied implicitly, which means that there will be no generally usable Ks established. 
To only establish an external NAF-key with GBA-Push, GBA_ME can and should always be used. This functionality does not require a GBA_U aware UICC. GBA-Push based on GBA_U will establish both an internal and an external NAF-key. NAF-keys are derived as specified in TS 33.220 [1].
In GBA_ME based GBA-Push bootstrapping, a Ks, generated by a bootstrapping according to TS 33.220 [1], will be unaffected. 
In GBA_U based GBA Push bootstrapping, a GBA_U Ks generated by bootstrapping according to TS 33.220 [1] will be invalidated. A new GBA_U Ks needs to be established using normal GBA if an application requires GBA_U NAF-keys after GBA_U based GBA-Push bootstrapping. Applications can continue using NAF-keys derived from such an invalidated Ks, i.e. applications already using NAF-keys are unaffected of the GBA-Push bootstrapping run. 
GBA-Push only supports generation of so called NAF SAs, shared by a UE and a NAF. A NAF SA contains a NAF-key, key life-time and other information as defined in clause 5.2.3. 
4.3	GBA Push Requirements
4.3.1	General GBA Push Requirements
The following general requirements are applicable to enable GBA Push:
-	A network entity, a so called Push NAF, shall be able to securely trigger the generation of a NAF SA between itself and a UE.
-	A Push-NAF shall be able to use channels with deferred delivery of messages when triggering the generation of a NAF SA.
- 	A Push-NAF shall be able to use public identities when referencing a UE in a request towards the BSF.
-	When a public identifier is used for GBA push it shall correspond uniquely to a single private identity.
-	ME based GBA Push shall be used when only ME based NAF keys are needed, i.e. Ks is established in the ME. UICC based GBA Push shall be used only when UE contains a GBA aware UICC (GBA_U), and when UICC and ME based NAF keys are needed or when only UICC based NAF keys are needed, i.e. Ks is established in the UICC.
-	The generation of the NAF SA in the UE is triggered by the reception of a message pushed to the UE from the Push-NAF.
-	The UE should not have to contact any network entity to be able to correctly generate the NAF SA.
-	The UE and the NAF shall be able to use bootstrapped NAF-keys on Ua reference point independent on whether the bootstrapping has been performed via Ub or Upa reference point.
NOTE:	When a GBA-push mechanism is used to create a NAF SA between the UE and the NAF, the NAF is not restricted to use the derived security association for network initiated protocols only. Analogously, the fact that UE initiated GBA was used does not restrict a NAF to use the derived security association for UE-initiated protocols only (Ua reference point). 
-	The mechanism to generate keys for confidentially and integrity protection of GPI shall be based on GBA- principles in order to avoid pre-configuration of keys.
-	The NAF shall be unable to obtain or generate the keys that protect GPI.
4.3.2	Requirements on HSS and HLR
The requirements for HSS and HLR are in TS 33.220 [1].
4.3.3	Requirements on BSF
In addition to the BSF requirements in clause 4.2.1 of TS 33.220 [1] following requirements apply: 
-	The BSF shall be able to find the private identity corresponding to a public identity.
-	The BSF shall index existing Ks's based on private user identity.
-	The BSF shall generate GPI based on a fresh Ks.
-	The BSF shall integrity protect the GPI.
-	The BSF shall confidentiality protect certain fields in the GPI. The fields that shall be confidentially protected are given in clause 5.2.1.
4.3.4	Requirements on UE
In addition to the UE requirements in clause 4.2.4 of TS 33.220 [1] the following requirements apply: 
-	The UE shall be able to store and handle NAF SAs.
-	An ME implementing this specification shall also implement GBA_U and GBA-ME as specified in TS 33.220 [1].
-	The UE may implement an authorization mechanism to authorize incoming GBA Push messages.
NOTE:	The GBA Push message authorization mechanism can be based on white or black lists of FQDN names of the Push-NAFs.
4.3.5	Requirements on Reference Point Upa
The requirements for reference point Upa are:
-	The UE shall be able to validate that the GPI comes from an authorized source (BSF) based on AKA 
NOTE 1:	The Push-NAF is indirectly authenticated by its knowledge of Ks(_ext/int)_NAF (i.e. BSF has authenticated the NAF).
-	The UE shall be able to determine the UICC (USIM/ISIM) application used for bootstrapping.
- 	The NAF and the UE shall be able to establish a shared NAF SA.
-	The NAF shall be able to send NAF SA identifier information.
-	the BSF shall be able to indicate to the UE the lifetime of the key material. The key lifetime sent by the BSF over Upa shall indicate the expiry time of the key. 
NOTE 2:	The requirements for the Upa reference point are based on the requirements of the Ub reference point c.f. TS 33.220 [1].
4.3.6	Requirements on Reference Point Zh
The requirements for reference point Zh are in TS 33.220 [1].
4.3.7	Requirements on Reference Point Zpn and Zpn'
The requirements for reference point Zpn are:
-	Mutual authentication, confidentiality and integrity shall be provided.
-	If the BSF and the NAF are located within the same operator's network, the DIAMETER based Zpn reference point shall be secured according to NDS/IP, TS 33.210 [3].
-	If the BSF and the NAF are located in different operators' networks, the DIAMETER based Zpn' reference point between the Zn-Proxy and the BSF shall be secured using TLS as specified in RFC 2246 [4].
NOTE 1:	Annex E of TS 33.220 [1] specifies the TLS profile that shall be applied.
-	A Web Services based Zpn/Zpn' reference point shall be secured using TLS as specified in RFC 2246 [4];
NOTE 2:		Annex E of TS 33.220 [1] specifies the TLS profile that shall be applied.
-	The BSF shall verify that the requesting NAF is authorised to obtain the key material or the key material and the requested USS.
-	The NAF shall be able to send a key material request to the BSF, containing NAF's public hostname corresponding to the use over Upa reference point. The BSF shall be able to verify that a NAF is authorized to use this hostname, i.e. the FQDN seen by UE on Upa reference point. 
NOTE 3:	This requirement is a modified requirement from [1] that has been adapted for the GBA Push purpose.
NOTE 3a:	Due to the fact that the UE may be unable to verify the pNAF FQDN, it is important to strictly check the pNAF FQDN-name in the network in the Zpn-proxy. A too loose checking of the pNAF FQDN name e.g. by verification of only part of the FQDN, may give rise to misuse by pNAFs.
-	The BSF shall be able to send the requested key material to the NAF.
-	The NAF shall be able to get a selected set of application-specific USSs from the BSF, depending on the policy of the BSF and the application indicated in the request from the NAF over Zpn.
-	The NAF shall be able to indicate to the BSF the single application or several applications it requires USSs for.
NOTE 4:	If some application needs only a subset of an application-specific USS, e.g. only one IMPU, the NAF selects this subset from the complete set of USS sent from BSF.
-	The BSF shall be able to be configured on a per NAF or per application basis. 
-	Whether private subscriber identity, i.e. IMPI, may be sent to the NAF.
-	Whether a particular USS may be sent to a NAF.
-	If a NAF requests USSs from the BSF and they are not present in subscriber's GUSS, it shall not cause an error, provided the conditions of the local policy of the BSF are fulfilled. The BSF shall then send only the requested and found USSs to the NAF.
-	It shall be possible to configure a local policy as follows: BSF may require one or more application-specific USS to be present in a particular subscriber's GUSS for a particular requesting NAF, and to reject the request from the NAF in case the conditions are not fulfilled. In order to satisfy this local policy, it is not required that the NAF requests the USSs over the Zpn reference point, which the BSF requires to be present in the GUSS, rather it is sufficient that the BSF checks the presence of the USSs locally. It shall also be possible to configure the BSF in such a way that no USS is required for the requesting NAF.
NOTE 5:	For more information on the local policy usage, see Annex J of TS 33.220 [1].
-	The NAF shall be able to request the life-time that a NAF SA should have. The key lifetime sent by the BSF over Zpn shall indicate the expiry time of the key.
NOTE 6:	This does not preclude a NAF to refresh the NAF SA before the expiry time according to the NAF's local policy.
NOTE 7:	If one or more of the USSs that have been delivered to the NAF has been updated in subscriber's GUSS in the HSS, this change is propagated to the NAF the next time it fetches the USS from the BSF over Zpn reference point (provided that the BSF has updated subscriber's GUSS from the HSS over Zh reference point).
-	NAF shall be able to indicate to BSF the protocol identifier of Ua security protocol for which it requires the key material (cf. Annex H of TS 33.220 [1]).
-	The NAF shall be able to indicate the user identity to the BSF. Both public and private identities shall be allowed.
NOTE 8:	The requirements for reference point Zpn are based on the Zn-reference point requirements as described in TS 33.220 [1].
-	The NAF shall be able to indicate whether GBA_ME or GBA_U shall be used.
4.3.8	Requirements on Zn-Proxy
In the case that push NAF is operated in a network other than the home network, this visited NAF shall use a Zn-proxy of the NAF's network to communicate with the subscriber's BSF (i.e. home BSF). The requirements for the Zn proxy are described in TS 33.220 [1].
4.3.9	Requirements on Reference Point Ua
The requirements for reference point Ua are as in TS 33.220 [1] with the following addition:
-	It shall be possible to use SA identifiers in the uplink that are unlinkable with the push message establishing the used NAF SA.
4.3.10	Requirements on NAF SA identifiers
-	The downlink NAF SA identifier shall be unique within the UE and uniquely identify that it references a NAF SA for a particular NAF_Id. 
-	The uplink NAF SA identifier shall be unique within the NAF and uniquely identify that it references a NAF SA for a particular UE and Ua security protocol identity.
4.3.11	Requirements on Reference Point Dz
This interface between BSF and SLF is used to retrieve the address of the HSS and the requirements are the same as described in TS 33.220 [1]. This interface is not required in a single HSS environment.
5	GBA Push Function
5.1	GBA Push Message Flow and Processing
5.1.1	GBA Push Message Flow
Figure 5.1-1 outlines the message flow for the case, where the NAF wants to send data to the UE, but has no valid NAF-key available i.e. no Ks(_int/ext)_NAF available The reason that the NAF has to initiate NAF SA establishment can be that the UE may be unable to perform a bootstrapping procedure directly with the BSF or that the UE should not perform a bootstrapping procedure directly with the BSF
NOTE 1:	An example use case when the UE is unable to perform a bootstrapping procedure is in a broadcast scenario.
If the subscriber is managed in an HLR instead of the HSS then GUSS functionality and SLF functionality are not available otherwise the functional flow is the same when substituting the word HSS by HLR in the text and the message flow below.
 SHAPE  \* MERGEFORMAT 
Figure 5.1-1: High level message flow description for bootstrapping through the NAF
A precondition for use of GBA-Push is that the UE is registered with the Push-NAF for the intended service. Annex B describes information that the Push-NAF must register to be able to deliver the push service and the information that has to be agreed between the UE and the Push-NAF.
Processing and message flow:
1.	A NAF needs to establish a shared NAF SA with a UE which is registered for Push services. It knows the identity of the subscriber. The Push-NAF performs the processing described in clause 5.1.2 and generates the GPI Request.
2.	The NAF sends the GPI Request to the BSF. 
3.	Upon receiving the request from the NAF, the BSF performs the processing steps 1 to 5 described in 
clause 5.1.3. 
4.	The BSF fetches a new AV and subscriber's GUSS from the HSS. The GUSS contains subscriber security related information e.g. UICC GBA awareness and USS elements. 
5	The HSS sends the AV and the GUSS to the BSF. 
6.	When the BSF receives the AV Response from the HSS, it performs the processing steps 6 to 9 described in clause 5.1.3. 
7.	The BSF sends the GPI Response to the NAF. 
8.	The NAF stores the received information together with other user information in a NAF SA, see clause 5.2.3. 
9.	The NAF then forwards the GPI to the UE over Upa using the selected transport mechanism and the given transport address.
10.	When the UE receives the message containing the GPI, it processes the GPI as defined in clause 5.1.4 and stores the corresponding NAF SA(s) 
The UE and NAF are now ready to use the established NAF SA. 
5.1.2	NAF processing before issuing GPI request
The NAF reads its available data associated with the user and the application for which the NAF SA shall be established. The NAF then determines the Ua security protocol identifier to use in the request to the BSF. It also determines the required life-time of the NAF SA. The NAF then generates the GPI request containing the parameters as given in table 5.1.2.1
Table 5.1.2.1: Parameters in NAF GPI request 
Parameter name
Description 
Notes
UE_Id
UE identifier
This may be a private or a public identifier. 

UE_Id_Type
Indicator if UE_Id is a public or private identity
This information is needed by the BSF to correctly trigger the Public to Private Id resolution towards a HSS/HLR
App_Lbl
Identifier for UICC application to use
This variable may be left empty if the UICC application to use is evident from context or agreement.
NAF_Id
Concatenation of NAF FQDN and Ua security protocol Id
Defined in TS 33.220 [1]
P-TID
NAF SA identifier
To be used by UE when responding to NAF. The identifier is included only to enable that it is confidentiality protected in the GPI. See also clause 5.2.1 and 5.2.2.
U/M
Indicator for use of GBA_ME or GBA_U

Key_LT
Requested NAF-Key life time

Priv_Id
Indicates request for private user identity
Private user identity is IMSI/IMPI for the selected UICC application (USIM/ISIM) 
GSID_List
GSIDs of USS request information


5.1.3	BSF processing of NAF GPI request
When the BSF receives the GPI request from the NAF it performs the following processing steps:
1.	The BSF checks that the NAF is authorized to use the NAF_Id provided in the GPI request. If it is not, an error message is generated and the processing is terminated.

The BSF checks that the requested Key_LT in the GPI request is less than the allowed max value in the system. If the value is greater than the max value an error message is generated and the processing is terminated. 
2.	If the UE_Id is a public identity, the BSF resolves the corresponding private identity (i.e. IMPI or IMSI) as specified in TS 29.109 [14].
3.	If needed, the BSF retrieves the HSS address for the given UE using the SLF.
4.	The BSF requests an AV, and subscriber's GUSS from the HSS. 
NOTE 1:	If the network utilizes an HLR, then no SLF is used.
NOTE 2:	If the network utilizes an HLR, then GUSS can be realized using an external database as defined in TS 33.220 [1].
5.	The BSF checks if GBA_ME or GBA_U is requested by the NAF. If GBA_U is requested the BSF checks that this is compatible with the GBA awareness of the UICC according to the GUSS information. If it is not, an error message is generated and the processing is terminated.
The BSF may use USS for policy management and key selection indication as described in TS 33.220 [1].
If GBA_U is requested the BSF queries its database to find out if the private UE_Id is registered and if a valid Ks already exists. If a valid Ks exists the BSF shall invalidate this Ks.
If the network utilizes an HLR instead of an HSS, then the BSF request only the AV from the HLR.
NOTE 3:	If the network utilizes an HLR, then GUSS can be realized using an external database as defined in TS 33.220 [1]
6.	The BSF generates the requested NAF-key(s) according to provided NAF_Id. 
7.	The BSF generates the GPI. The parameters of the GPI are defined in clause 5.2.1. The generation of the GPI includes calculation of the GPI MAC and performing confidentiality protection on parts of the GPI. GPI protection is described in clause 5.3.
8.	The BSF sends its response to the NAF, and deletes the Ks used. The GPI response is defined in table 5.1.3.1.
Table 5.1.3.1: Parameters in GPI response 
Parameter name
Description 
Notes
GPI
GPI 
GPI information is defined clause 5.2.1
Ks_NAF /
Ks_ext_NAF
External NAF-key
Ks_NAF is generated in GBA_ME based GBA-Push
Ks_ext_NAF is generated in GBA_U based GBA_Push
Ks_int_NAF
UICC internal NAF-key
Ks_int_NAF is generated in GBA_U based GBA_Push
Key_LT
NAF-Key life time

UE_Priv_Id
Private user identity (IMSI/IMPI) for used UE_Id
Only returned if requested and public user identity was used in GPI request and the NAF is authorized by the BSF to receive the private user identity.
USS
USS information
If available

5.1.4	UE processing of GPI
When the UE receives a GPI it performs the following steps.
1.	UE receives GPI. The parameters of the GPI are defined in clauses 5.2.1 and 5.3.5.
2. If the App_Lbl in the GPI is included, then if the App_Lbl:
a. indicates a USIM or ISIM application which is already active then the UE continues processing from step 4.
b.  indicates a USIM application different from the currently active USIM application, then the ME shall reject the request, as there at most, only can be one USIM active at one time.
c.  indicates a ISIM application different from the currently active ISIM application(s), then the ME shall not terminate the currently active ISIM application(s), but instead the ME shall activate the ISIM application as defined in TS 31.101 [15], as the UE is allowed to have several ISIM applications active simultaneously.
3.	If the App_Lbl in the GPI is undefined, the UE determines the UICC application to use from used delivery channel of the GPI (e.g. SMS, MMS, SIP Message, etc) or from other context information.
4.	UE checks if it has received the same GPI earlier.
a.	If the GPI corresponds to an already existing NAF SA, then the GPI is silently dropped and the GPI processing terminated.
b.	If the GPI corresponds to an incomplete NAF SA, the Ks indicated by GPI is activated and processing continues from step 7 (step 8 describes how an incomplete SA may appear).
NOTE 1:	To handle retransmissions efficiently the UE benefits from only invoking a UICC application after checking that the GPI does not correspond to an already existing NAF SA. The check can be done by comparing the received (RAND, AUTN(*), App_Lbl) triplet with the corresponding triplets associated with existing NAF SAs.
5.	The UE reads the GPI version number and selects the corresponding GPI integrity and ciphering algorithms. If the UE does not support this GPI version, the GPI is silently dropped and the GPI processing is terminated.
6.	If the UICC application is active or can be activated the UE initiates derivation of the Ks by issuing an Authenticate command to the UICC. The type of Authenticate command is determined by the indicated U/M-mode in the GPI, i.e. if GBA_ME or GBA_U should be used. If the authenticate command returns a failure the GPI processing ends.

If U/M indicates use of GBA_U, the generated Ks will effectively be generated on the UICC and not deleted until next GBA_U Ks is established using Authenticate command. The ME shall restrict NAF-key generation procedures using the generated Ks on the UICC to only be allowed for the NAF SA generation associated with the ongoing GBA-Push procedure. 
7.	The ME initiates the derivation of the GPI protection keys and other parameters needed for GPI integrity checking and deciphering of the confidentiality protected parts. This processing is defined in clause 5.3
8.	The ME checks the integrity of the GPI message. If the integrity check fails, the following procedure is followed:
a.	With GBA_ME, the derived Ks is stored and marked as incomplete and the GPI processing ends. 
b.	With GBA_U, the Ks was stored by the authenticate command. The Ks identity, which normally would be B-TID (see TS 33.220 [1]) is set to RAND@'undefined'. The GPI processing ends. 
9.	The ME deciphers the confidentiality protected parts of the GPI using the algorithms defined by the GPI version number and the GPI confidentiality protection keys.
10.	The UE initiates the derivation of the NAF-Key (s), Ks(_int/ext)_NAF, using the NAF_Id received in the GPI. The key derivation is defined as specified in TS 33.220 [1]. 
11.	The NAF SA consisting of the NAF-key(s) and associated parameters is stored. 
NOTE 2:	When GBA_U is used, two NAF-keys will be generated i.e. a Ks_ext_NAF will be stored in the ME and a Ks_int_NAF will be stored on the UICC. Both keys will be part of the NAF SA.
5.2	Data objects
5.2.1	GBA Push Information (GPI) 
The definition of GPI information is given in table 5.2.1.1 Note that GPI does not contain any user identity or transport address as these entities are not needed by the GBA processing in the UE. They are only relevant for the transport of the GPI.
Table 5.2.1.1: GPI information
Parameter name
Description 
Notes
Ver
Version of GPI
The version number is introduced to allow changes of GPI format and protection algorithms.
RAND
RAND in UMTS AKA
Defined in TS 33.102 [6]
AUTN(*)
AUTN or AUTN*
Defined in TS 33.220 [1]
App_Lbl
Identifier for UICC application to use
This variable may be left empty if the UICC application to use is evident from context or agreement. The Application Label is defined in TS 31.101 [15]
U/M
Indicator for use of GBA_ME or GBA_U

NAF_Id
Concatenation of NAF FQDN and Ua security protocol Id
Defined in TS 33.220 [1]; 
Confidentiality protected
Key_LT
Requested NAF-Key life time
Confidentiality protected
P-TID
NAF SA Identifier
To be used by UE when responding to NAF. The identifier is included only to enable that it is confidentiality protected in the GPI. See also clause 5.2.2. Confidentiality protected
MAC
Message authentication code over GPI
The integrity protection covers the complete GPI

This specification only defines a single version of GPI, i.e. version 1. In version 1, the MAC field is 32 bits.
5.2.2	NAF SA identities
A NAF SA holds NAF-key(s) and can have unique identities for uplink and downlink references, this to support unlinkability between uplink and downlink protection measures.
P-TID is assigned by the NAF and should be unique within the NAF.
NAF SA identifiers are:
RAND@'naf': 		Identifies NAF SA in the UE (used by NAF).
Value of P-TID:		Identifies NAF SA in the NAF (used by UE).
NOTE:	'naf' indicates a string of the characters naf.
5.2.3	NAF SA
The NAF needs to keep some additional information in its NAF SA compared with the UE. The UE identity used in the BSF request for GPI must be stored to allow the NAF to determine from which UE a response is coming and also to link sequences of SA's for the same UE. The NAF also needs to store the transport address to which the GPI should be directed. If the NAF uses retransmission to achieve better delivery reliability, it also needs to store the encrypted version of the part of the GPI, which is confidentiality protected. It also has to store the GPI MAC.
Table 5.2.3-1: NAF SA definition
Parameter nameNAFUEDescription NotesUE_ Id
m
o
The user identity used in NAF request.

UE_Priv_Id
o
-
Private user identity (IMSI/IMPI) for used UE_Id

UE_Trp
m
-
Transport address to which GPI should be delivered
The transport address used by the NAF when pushing GPI to the UE
RAND
m
m
RAND in UMTS AKA
From GPI
AUTN(*)
m
m
AUTN or AUTN*
From GPI
App_Lbl
m
m
UICC application identifier
From GPI or other implicit agreement or information.
NAF_Id
m
m
Concatenation of NAF FQDN and Ua security protocol Id

Enc_GPI
m
-
Encrypted part of GPI plus MAC

Mac_GPI
m
-
BSF generated MAC over GPI

UL_SA_Id
m
m
Uplink NAF SA identity

DL_SA_Id
m
m
Downlink NAF SA identity

Ks_NAF /
Ks_ext_NAF
m
m
External NAF-key
Ks_NAF is generated in GBA_ME based GBA-Push
Ks_ext_NAF is generated in GBA_U based GBA_Push
Ks_int_NAF
o
o
UICC internal NAF-key
Ks_int_NAF is generated in GBA_U based GBA_Push
Key_LT
m
m
Received NAF-Key life time


5.3	GPI Integrity and Confidentiality Protection
5.3.1	General considerations
Integrity and confidentiality protection of the GPI is between the BSF and the UE. The keying material used for the protection must not leave the BSF and the UE, which implies that the NAF in particular and all other parties different from the UE and the BSF will not be able to modify the GPI (due to the integrity protection) or read its confidentiality protected parts. 
NOTE: 	Transferring the NAF_Id in the clear together with a long term user identity/transport address may give rise to a privacy problem in a broadcast network or in an access network that does not apply confidentiality protection
5.3.2	Key material generation
The key material for confidentiality and integrity protection of GPI is derived from the Ks, which the GPI defines. The key derivations in version 1 of the GPI use the KDF defined in Annex B3 of TS 33.220 [1] with the below defined modifications of the NAF_ID (variable P3). The used NAF_ID as defined below shall be UTF- 8 encoded. All keys are 128 bits. The 128 least significant bits of the KDF output are used as key bits. The following keys are defined:
GPI_INT_Key:	The NAF_ID shall equal 'GPI_integrity'.
GPI_ENC_Key:	The NAF_ID shall equal 'GPI_confidentiality'
GPI_IV:			The NAF_ID shall equal 'GPI_IV'
NOTE: 	It is appropriate to generate the IV this way as the keys will only be used to protect a single message.
5.3.3	GPI Integrity protection
GPI integrity protection is mandatory. The integrity protection is calculated after GPI has been confidentiality protected as defined in clause 5.3.4. 
The GPI integrity protection in version 1 of the GPI uses algorithm HMAC-SHA256-32  with a 128-bit key as defined in [7], [8] and [9]. The MAC is computed over the complete GPI as defined in clause 5.2.1, During the computation of the MAC, the MAC field shall be treated as containing all zeros.
5.3.4	GPI Confidentiality protection
GPI confidentiality protection is mandatory. 
The confidentiality protection shall be applied onGPI elements as indicated in table 5.2.1.1. 
The GPI confidentiality algorithm in version 1 of the GPI is CTR-AES128 [10], [11]. The key to be used is GPI_ENC_Key and the start value T1 for the counter is GPI_IV. The standard incrementing function is used with m=16, according to appendix B in [10], i.e. the 16 least significant bits in T behave like a counter while the 112 most significant bits are static and equal the 112 most significant bits of the GPI_IV.
5.3.5	GPI message format and coding
The GPI message is laid out as shown in Figure 5.3.5-1.  Each field is encoded in network byte order (i.e., big endian) and with the most significant bit being bit number zero. The fields of the message are the following.
Ver (4 bits): The version of the GPI message encoded as a 4 bit binary number. The version of any message conforming to this specification shall use the value 1, i.e., the first nibble of the message is 0x1.
Reserved (3 bits): These bits are reserved for future versions of this specification. Implementations conforming to this specification shall set these bits to zero before transmitting a message, and the receiver of the message shall ignore these bits. 
U/M (1 bit):  0 = GBA_ME, 1 = GBA_U
RAND: 16 octets.
AUTN: 16 octets.
Length App_Lbl: 1 octet containing length of App_Lbl in number of octets.
App_Lbl (variable length): UTF-8 encoded character string.
Length NAF_Id: 1 octet containing length of NAF_Id  in number of octets.
NAF_Id (variable length): UTF-8 encoded FQDN of NAF concatenated with the 5 octets of the Ua security protocol identifier.
Key_LT: 4 octets.  Key expiry time in the same format as the first four bytes in the NTP timestamp format [16]. This represents the number of seconds since 0h on 1 January 1900. On 7 February 2036 the time value will overflow. In [16] a procedure is described to extend the time to 2104. This procedure shall be supported.
Length PTID: 1 octet containing length of PTID in number of octets.
PTID (variable length): UTF-8 encoded character strings
MAC: 4 octets.
                            


 EMBED Visio.Drawing.11  
Figure 5.3.5-1. GPI message layout
5.4	Procedures using the NAF SA
The established NAF SA can be used by the terminal to set up communication over Ua. 
If the terminal want to initiate a Ua connection as specified by TS 33.222 [13] based on a NAF SA established via TS 33.223 then the procedures for the terminal shall follow the principles defined in clause 4.5.3 in TS 33.220 [1] and clauses 5.3 and 5.4 in TS 33.222 [13] with the following change:
-	Instead of referencing the SA (NAF-Key) to be used by a B-TID as described in TS 33.220, clause 4.5.3,.the UE uses P-TID. P-TID was sent in the GPI coming from NAF and it will uniquely identify the SA and the user identity to the NAF 
-	Instead of supplying the B-TID as user name as described in TS 33.222, clause 5.3, the UE uses P-TID. The NAF will then know the user identity and can retrieve the key from the NAF SA.
-	Instead of using the B-TID as PSK identity as described in TS 33.222 clause 5.4  the UE uses P-TID. The NAF will then know the user identity and can retrieve the key from the NAF SA.
Annex A (informative):
Rationale behind choice of the Disposable-Ks model
GBA-Push utilizes the Disposable-Ks model in which a Ks is only used once to derive a single set of NAF-keys. This means that after a NAF-key derivation, the used Ks is erased or its further usage is blocked. Furthermore, a Single Ks model is adopted for GBA_U based GBA-Push. This means that only a single GBA_U Ks can exist at a given time. The rationale behind the Single-Ks model for GBA_U based GBA-Push is to make it possible to reuse Rel-6 UICC's supporting GBA_U for GBA_U based GBA-Push.
For GBA_ME based GBA-Push the specification assumes that the ME can perform the necessary operations without having to erase a Ks generated by a normal GBA_ME bootstrapping.
The rationale behind the adoption of the Disposable-Ks model is to avoid synchronization problems as the GBA-Push may be over unreliable channels with non-delivery or undefined delay in delivery time, which may render the UE and the BSF unsynchronized with respect to the existence of a single valid GBA-Push Ks. Another situation when the UE and the BSF may become unsynchronized is when the BSF  performs a normal bootstrapping and a NAF initiates a GBA-Push more or less  simultaneously with the NAF requesting GPI before the UE  performs the bootstrap and the GBA-Push message is delivered after the normal bootstrap. The Disposable-Ks model solves most of these out-of synch problems.  
One situation when an out-of-synch problem will appear even with the adoption of the Disposable-Ks model is when the BSF may erase a valid Ks while the UE keeps it due to that the GBA-Push message can not be validated at the UE. This will lead to an error situation if the UE tries to use such a Ks. However, the error situation will easily be corrected as the NAF will get an error message from the BSF telling that the Ks (indicated by B-TID) is not available. The NAF would then return this error message and the terminal would perform a new bootstrap.
Alternatives to the chosen key handling model discussed were all based on allowing one or more GBA-Push generated Ks's and thus keeping a set of security contexts in the UE or on the UICC. Keeping one or more GBA-Push generated Ks's may make the out-of-synch problem go away or at least become much smaller. The downside is of course that as GBA_U based GBA-Push is essential from a security point of view, adoption of those models would have required new functionality on the UICC which was deemed making the introduction and adoption of GBA-Push more difficult. When also taking the minor functional drawbacks of the chosen key handling model into account the extra cost and complexity introduced by the other models were not judged to be a sufficient motivation to introduce new UICCs.
Annex B (normative):
GBA-Push UE registration procedure
To be able to use GBA Push based services the user and the service provider need to share information. This is done in a registration procedure. The registration procedure could be explicit and involve the user or it could be automatic relying on user information provided by the user's operator. If the registration is initiated by the operator, the operator will have access to all needed registration information. 
NOTE:	When a user registers with a public identity this might not be the case, especially if the NAF is a third party service provider. One way of alleviating the problem would be to have users perform the registration over an authenticated/secured connection established with normal GBA. Then the BSF could provide the NAF with all needed information. Note however that this functionality is not standardized and that all needed information might not be available over the currently standardized interfaces.
At the registration the Push NAF shall record the user identity (UE_Id), a push delivery method and the associated transport address (UE_Trp). The user identity may be either a public identity or a private identity. 
A public IMS user identity (IMPU) may only be used if it maps to a unique private identity (IMPI). This shall be checked in the registration procedure as the service will fail if the condition is not fulfilled.
When the UE identity is an MSISDN this public identity will map uniquely to an IMSI but with number portability, being active information about the associated operator will be needed in any case to identify to which BSF the user belongs (i.e. to which operator the user has a contract). Knowing the operator will enable the NAF to derive the FQDN of the BSF in the operator’s network.
If the UE to be registered is equipped with a UICC holding more than one UICC application capable of running AKA, the registration process should, if the UICC application to use is not uniquely determined by the UE transport method and/or UE_Id, determine which UICC application to use and how the NAF contacts the corresponding the BSF (needs to know the FQDN of the BSF). If explicit signalling is needed to identify the used USIM / ISIM, the App_Lbl to use should be agreed and recorded.
At registration, a Push NAF intending to use GPL [15] shall record whether the ME is capable of GPL or not. If the the Push NAF intends to use GPL_U, then it shall also record the delivery channels to the UICC that the ME supports.
Annex Z (informative):
Change history
Change history
DateTSG #TSG Doc.CRRevSubject/CommentOldNew2006-05Creation of document on the basis of SA3#43 discussion0.0.00.0.12006-08Integration of S3-060498, addition of editors' notes (SA3#44 meeting) and editorials.0.0.10.1.02006-11Integration of S3-060630, S3-060631, S3-060634, and S3-060676.0.1.00.2.02007-02Integration of S3-070041, S3-070049, S3-070051 and S3-070068 and their modifications as discussed in the meeting0.2.00.3.02007-05Integration of S3-070332, S3-070360, S3-070361 and S3-070372 and their modifications as discussed in the SA3#47 meeting0.3.00.4.02007-07Integration of S3-070510, S3-070538, S3-070557, S3-070652 and S3-070563 and their modifications as discussed in SA3#48 meeting0.4.00.5.02007-10Integration of S3-070710, S3-070711, S3-070773 and related decisions, presentation of TS 33.223 to SA Plenary for information0.5.00.6.02007-1138SP-070834Clean-up from MCC for presentation for information to TSG#380.6.01.0.02008-02This version is against the proposed split of TS 33.223 v1.0.0. as proposed in S3-080070. Integration of S3-080051 and S3-080117 and their modifications as discussed in SA3#50 meeting1.0.01.1.02008-03Integration of S3-080133 and comments from email review1.1.01.202008-05Integration of GBA-Push principles agreed at S3#51 and relevant parts of pCR's S3-080304, S3-080305 and S3-0803851.2.01.3.02008-05SA3 agreement and clean up for presentation to SA#401.3.02.0.02008-06SP-40SP-080259Approval at SA#402.0.08.0.02008-09SP-41SP-08048300041CR 33.223: UE registration at Push NAF8.0.08.1.02008-09SP-41SP-08048300021CR 33.223: GPI Protection8.0.08.1.02008-12SP-42SP-08074100051GBA-Push resolution of editors notes and corrections8.1.08.2.02008-12SP-42SP-0807410006-Introduction of UE-Id type indicator8.1.08.2.02008-12SP-42SP-0807410007-Push NAF authorization8.1.08.2.02009-03SP-43SP-0901410008-Editorial corrections on 33.2238.2.08.3.02009-03SP-43SP-0901410009-Alignment of TS 33.223 with TS 33.2208.2.08.3.02009-06SP-44SP-0902770012-Editorial corrections on 33.2238.3.08.4.02009-06SP-44SP-09027700101Clarification of GUSS usage in case of HLR8.3.08.4.02009-09SP-45SP-0905230013-Remove replay window8.4.08.5.02009-09SP-45SP-0905230014-Clarifications to GBApush8.4.08.5.02009-09SP-45SP-0905230016-Changing GBA push registration annex to be normative8.4.08.5.02009-12SP-46SP-0908200017-Registration of GPL capabilities8.5.09.0.02010-03SP-47SP-1001000021-Correction of incorrect requirement for mandatory support of GBA Push for GBA aware MEs9.0.09.1.02010-03SP-47SP-10021800192Correction of private identity exposure and delivery of GPI to USIM/ISIM9.0.09.1.02015-06SP-68SP-1503010027-Change to AUTN length9.1.09.2.0








 STYLEREF ZA 3GPP TS 33.223 V9.2.0 (2015-06)
 PAGE 23
 STYLEREF ZGSM (Release 9)



3GPP


Push message

10. NAF SA Storage 

9. GPI Push

8. NAF SA Storage 

7. GPI Response: GPI, ...

6. GPI generation.
(See steps 6 – 9 in 5.1.3 )

5. AV Response: AV, USS,…

4. AV Request: IMPI,…

3. Initial processing of GPI 
Request. 
(See steps 1 –  5 in 5.1.3)

1. Generate GPI Request 
(See 5.1.2)

2. GPI request: UE_Id,…

HSS

BSF

UE

NAF