A.2 Specific use cases
33.2243GPPGeneric Authentication Architecture (GAA)Generic Bootstrapping Architecture (GBA) push layerRelease 17TS
A.2.1 Network initiated NAF-key refesh and distribution of keys
This use case is related to key distribution to terminals that receive broadcasted content and need a key be able to render the content and to key refresh for an existing security association. Keys could be pushed to the terminal at regular intervals to avoid having long-lived keys in the system. As the push message could be sent out over the broadcast system a back channel cannot be assumed to be available in all cases.
Services that have not their own inbuilt key refresh mechanism (e.g. like MBMS) may want to push a new security association to a user. The reasons for that might be continuous user service experience (e.g. keys expire during some critical time period), to spread load evenly on the network side or there is some maintenance in the network at the time of expiry (e.g. on the Push-NAF to BSF connection which causes reduced bandwidth). The maximum Ks lifetime is known by the BSF and the Push-NAF, if the Push-NAF desires a fresh key (because it expires or for Push-NAF policy reasons) it can proactively push a new security association to the UE.
Characteristics:
- Some UE’s require the security association to be established at a predefined time before the old key expires
- There exists already a Ua security association, for the case where the keys are refreshed.
- The service consumption may occur much later then the security provisioning.
- The old NAF-keys might be NAF-keys generated in a GBA run according to TS 33.220 or in a GBA Push run.
- GBA_ME must be supported and GBA_U support might be needed, but not for OMA BCAST and MBMS, since those have their own inbuild refresh solution. Nevertheless, GBA Push might be useful for MBMS.
A.2.2 Distribution of tokens
This use case is very similar to the key distribution case except for one important difference and that is that the token should be presented to the service provider over an IP connection. Thus, it can be assumed that a back-channel exists and that this back channel could be used to report the success of a GBA Push. On the other hand, the usefulness of the solution would be diminished if delivery of the tokens only was allowed to take place to terminals that are on-line, which would be required to get a timely success report and exclude use of deferred delivery channels.
A.2.3 MBMS GBA_U use case
GBA Push could be useful for MBMS.
GBA was created to secure MBMS and to allow UICC-based solution by means of GBA_U. In case of use of GBA Push for MBMS, it should be possible to send GBA Push messages protected by means of keys stored on the UICC, i.e. Ks_int_NAF-related keys. GBA Push solution shall support GBA_U.
A.2.4 OMA related use cases
OMA BCAST provided use-cases for GBA Push. One of this use-case is OMA BCAST smart card profile, which requires GBA Push solution with endpoint in the UICC. Consequently, GBA Push solution shall support GBA_U. In particular, OMA provided the following information:
"The smart card based service protection profile uses MBMS GBA mechanisms for registration and long term key delivery. It would be advantageous to also for this profile have network initiated registration and delivery of long term keys. A secure GBA Push mechanism would enable such a solution. "
Others OMA use-cases could rely on GBA_U-based GBA Push solution. E.g. OMA SEC group identified GBA Push-based key management as a good enhancement for future device management and client provisioning releases. This GBA Push solution could rely on Ks_ext_NAF/Ks_int_NAF keys to reinforce the security. But, for those use-cases, there is no OMA requirement mandating that GBA Push solution shall address the case of endpoint in the UICC.
A.2.5 Network initiated services
There are quite a number of services that are initiated from the network, which require that the terminal connects to a server in the network. Examples of OMA defined enablers having this modus operandi are e.g. Device Management (DM), Download DRM (DLDRM), DRM, and Secure User Plane Location (SUPL). In all these cases it is assumed that the triggering push message can be sent over SMS.
Having an efficient secure push system would allow greater flexibility as trusted parameters and keys could be sent in the trigger and provisioned parameters like server and sender white-lists could be avoided. Furthermore, a secure push would also allow protection against replay and DoS attacks.
As the services require that the terminal connects to the network there is a back-channel in these use cases. When the terminal connects to the server, the initiating Push-NAF will implicitly receive a confirmation that a GBA Push has succeeded. The success could then be reported by the server to the BSF via the Push-NAF.
A special case of a network initiated service is the case, where the operator may want to update securely information on the terminal e.g. device management or client provisioning. The UE has not contacted the operator before and hence can not be securely triggered to bootstrap (i.e. usage of SMS or WAP Push). The device management information should be pushed in a secure manner to the UE and the pushing may occur at a fixed point of time or during a pre-defined period. It must be ensured that the originator of the management message is authorized and that only the correct terminal can utilize the data.
Characteristics:
- The usage of the transferred information (called management message) to the UE may occur directly after the provisioning.
- Source of the management message must be identifiable i.e. the Push-NAF
- Only authorized recipients of the management message should be able to utilize it.
- Security association establishment (Upa) and delivery of the management message (Ua) might not occur together. Operator may want to send several messages secured by the same SA.
- Management information is targeted for the terminal, hence Ks_NAF support is sufficient.
A.2.6 BSF and HSS load balancing for broadcast
GBA is used for MBMS and OMA BCAST. The main advantage of broadcast is that many devices can be served with content at the same time. Typical broadcast scenarios include soccer games, olympics, eurovision contest and other events of general interest. If a majority of the UEs make the GBA bootstrapping run just before the event starts, then the BSF server and the HSS have to deal with a large load. Therefore it seems desirable, that the network can trigger the registration and delivery of the long term keys and many UEs can be provisioned with GBA credentials (NAF-keys) at times, where the BSF is having a low load e.g. the night before the event. The receiving terminal also supports GBA and in case, that it receives a broadcast message, for which no security association is available, then it start a GBA run according to TS 33.220.
Characteristics:
– Many UE’s that require a security association at a specific time for service consumption.
– If GBA Push and GBA sessions according to TS 33.220 are managed together, then BSF can re-use Ks that was created for GBA Push for the GBA run according to TS 33.220. This also may work the other way around, that the Ks that has been established according to TS 33.220 could be used for GBA Push. If there is no uplink channel then this re-usage can not take place.
– It may be possible that there in no uplink channel available or it is undesired (due to network load) that many UE’s make an uplink access at almost the same time (in the same area).
– The service consumption may occur much later then the security provisioning.
– Terminal should also support GBA according to TS 33.220 to allow service usage for the case that the SA via GBA Push did not arrive.
– GBA according to TS 33.220 is used (if supported) only for the case that no SA was received.
– The service that needs load balancing may require GBA (TS 33.220) or GBA_U support from the UE.
A.2.7 Download of vouchers / tickets
One use that has been discussed is to distribute vouchers/tickets for different types of public events or collection of physical goods by pushing a corresponding vouchers/ticket to the customers’ mobile phone. The distribution could be scheduled to take place close in time to when the event starts to minimize the risk that the voucher/ticket is erased, lost in some other way or duplicated or it could be distributed well in advance to distribute the load on the network.
Vouchers/tickets need to be securely delivered to the legitimate receiver as they usually are not personalized.
If the distribution mechanism is reliable there is no need to report the reception of the voucher back to the issuer. Even with unreliable delivery channels reporting back is probably not needed as the user would note that the ticket has not been delivered and the user could then contact the issuer and ask for a retransmission.
The consumption of the voucher/ticket can not be used as a reliable means for reporting the success of the download. There are two reasons for this. The first one is that the vouchers may be consumed via off-line devices. The second reason is that the consumption may take place a long time after delivery.
Note also that this type of use case should work with deferred delivery of the message containing the voucher/ticket. If the receiver has turned off his phone, he should receive the message a soon as he turns the phone on again.
A.2.8 Distribution of news / information / commands
Distribution of news/information/commands, like stock prices or work orders, to employees need protection, especially integrity protection and source authentication, but in many cases also confidentiality protection. Such information should preferably be distributed over a system supporting deferred delivery to relieve the service provider of having to keep track of the user status and to make the information available as soon as the user switches on his terminal.
A.2.9 Set-top box use-case
It also exists the use-case of set-top box equipped with UICC reader and without return channel to the network. This use case implies that the GBA Push messages would be protected by means of the UICC.
A.2.10 Summary
The use cases and their characteristics above give rise to the following requirements:
(1) There are use cases, where the Ua protocol may terminate in the UICC and use cases, where it terminates in ME.
(2) GBA Push should support both GBA_ME and GBA_U.
(3) Separate delivery of Ua and Upa messages should be supported.
(4) The Upa bootstrapping should be able to support unidirectional message delivery (e.g. Upa over broadcast).
Annex B (informative):
Change history
|
Change history |
|||||||
|
Date |
TSG # |
TSG Doc. |
CR |
Rev |
Subject/Comment |
Old |
New |
|
Mar 2009 |
SA-43 |
SP-090135 |
— |
— |
Presentation to SA for information |
— |
1.0.0 |
|
Sep 2009 |
SA-45 |
SP-090528 |
— |
— |
Presentation to SA for approval |
2.0.0 |
9.0.0 |
|
Dec 2009 |
SA-46 |
SP-090820 |
001 |
2 |
Description of GPL_U solution |
9.0.0 |
9.1.0 |
|
Mar 2010 |
SA-47 |
SP-100098 |
002 |
1 |
General corrections |
9.1.0 |
9.2.0 |
|
2011-03 |
– |
– |
– |
– |
Update to Rel-10 version (MCC) |
9.2.0 |
10.0.0 |
|
2012-09 |
SA-57 |
SP-120605 |
003 |
1 |
Addition of missing cipher suites with NULL encryption for GPL |
10.0.0 |
11.0.0 |
|
2013-03 |
SA-59 |
SP-130039 |
005 |
1 |
Update S3-130020 corrections to TS 33 224 |
11.0.0 |
11.1.0 |
|
2014-09 |
– |
– |
– |
– |
Update to Rel-12 version (MCC) |
11.1.0 |
12.0.0 |
|
2016-01 |
– |
– |
– |
– |
Update to Rel-13 version (MCC) |
12.0.0 |
13.0.0 |
|
Change history |
|||||||
|
Date |
Meeting |
TDoc |
CR |
Rev |
Cat |
Subject/Comment |
New version |
|
06-2016 |
SA#72 |
S3-160740 |
0007 |
1 |
F |
Re-assign the FC values in TS 33.224 to allow an additional one in TS 33.303 |
13.1.0 |
|
2017-03 |
– |
– |
– |
– |
Promotion to Release 14 without technical change |
14.0.0 |
|
|
2018-10 |
– |
– |
– |
– |
– |
Update to Rel-15 version (MCC) |
15.0.0 |
|
2020-07 |
– |
– |
– |
– |
– |
Update to Rel-16 version (MCC) |
16.0.0 |
|
2022-03 |
– |
– |
– |
– |
– |
Update to Rel-17 version (MCC) |
17.0.0 |