Content for TS 33.220 Word version: 18.3.0

4.4 Requirements and principles for bootstrapping 4.4.1 Access Independence 4.4.2 Authentication methods 4.4.3 Roaming 4.4.4 Requirements on reference point Ub 4.4.5 Requirements on reference point Zh 4.4.6 Requirements on reference point Zn 4.4.7 Requirements on Bootstrapping Transaction Identifier 4.4.8 Requirements on selection of UICC application and related keys 4.4.9 Requirements on reference point Ua 4.4.10 Requirements on reference point Dz 4.4.11 Requirements on GBA keys and parameters handling 4.4.12 Requirements on reference point Zh' 4.4.13 Requirements on TMPI handling
...

4.4 Requirements and principles for bootstrapping p. 19

The following requirements and principles are applicable to bootstrapping procedure:

the bootstrapping function shall not depend on the particular NAF;
the server implementing the bootstrapping function needs to be trusted by the home operator to handle authentication vectors;
the server implementing the NAF needs only to be trusted by the home operator to handle derived key material;
it shall be possible to support NAF in the operator's home network and in the visited network;
the architecture shall not preclude the support of network application function in a third network;
to the extent possible, existing protocols and infrastructure should be reused;
in order to ensure wide applicability, all involved protocols are preferred to run over IP;
it shall be prevented that a security breach in one NAF who is using the GBA, can be used by an attacker to mount successful attacks to the other NAFs using the GBA.
an attacker shall not be able to exploit a security breach in one security protocol over Ua in order to mount a successful attack against a different security protocol over Ua.

4.4.1 Access Independence p. 20

Bootstrapping procedure is access independent. Bootstrapping procedure requires IP connectivity from UE.

4.4.2 Authentication methods p. 20

Authentication between the UE and the BSF shall not be possible without a valid cellular subscription. Authentication shall be based on the 3GPP AKA protocol.

4.4.3 Roaming p. 20

The requirements on roaming are:

The roaming subscriber shall be able to utilize the bootstrapping function in the home network. The subscriber shall be able to utilize network application function that is in a visited network.
The home network shall be able to control whether its subscriber is authorized to use the service in the visited network.

4.4.4 Requirements on reference point Ub p. 20

The requirements for reference point Ub are:

the BSF shall be able to identify the UE;
the BSF and the UE shall be able to authenticate each other based on AKA;
the BSF shall be able to send a bootstrapping transaction identifier to the UE;
the UE and the BSF shall establish shared keys;
the BSF shall be able to indicate to the UE the lifetime of the key material. The key lifetime sent by the BSF over Ub shall indicate the expiry time of the key.

NOTE 1:
This does not preclude a UE to refresh the key before the expiry time according to the UE's local policy.
the BSF and the UE shall protect the permanent user identity IMPI against passive eavesdropping attacks by using a temporary identity. The support of the temporary identity by UE or BSF shall not preclude a successful bootstrapping procedure if the other entity conforms to an earlier release of this specification and does not support the use of a temporary identity.

NOTE 2:
User identity privacy can be achieved only when both, UE and BSF, support the use of a temporary identity.

NOTE 3:
The use of a temporary identity is not required for 2G GBA (cf. Annex I) as the IMPI is already protected by the mandatory TLS tunnel.

4.4.5 Requirements on reference point Zh p. 21

The requirements for reference point Zh are:

mutual authentication, confidentiality and integrity shall be provided;

NOTE 1:
This requirement may be fulfilled by physical or proprietary security measures since BSF and HSS are located within the same operator's network.
the BSF shall be able to send bootstrapping information request concerning a subscriber;
optionally the BSF may have the capability able to send the timestamp of subscriber's GBA user security settings to the HSS (timestamp option);
the HSS shall be able to send one 3GPP AKA vector at a time to the BSF;
the HSS shall be able to send the complete set of subscriber's GBA user security settings needed for security purposes to the BSF. Optionally the HSS may have the capability to indicate to the BSF whether the BSF already has the latest copy of the GUSS based on the GUSS timestamp (timestamp option);

NOTE 2:
If subscriber's GUSS is updated in HSS, this is not propagated to the BSF. The GUSS in the BSF is updated when the BSF next time fetches the authentication vectors and GUSS from the HSS over Zh reference point as part of the bootstrapping procedure.
no state information concerning bootstrapping shall be required in the HSS;
all procedures over reference point Zh shall be initiated by the BSF;
the number of different interfaces to HSS should be minimized.

4.4.6 Requirements on reference point Zn p. 21

The requirements for reference point Zn 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 Zn reference point shall be secured according to NDS/IP [13] or may be secured using TLS as specified in Annex E of the present document;
If the BSF and the NAF are located in different operators' networks, the DIAMETER based Zn' reference point between the Zn-Proxy and the BSF shall be secured using TLS as specified in Annex E of the present document;
An HTTP based Zn/Zn' reference point shall be secured using TLS as specified in Annex E of the present document;
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 used by the UE's corresponding request. The BSF shall be able to verify that a NAF is authorized to use this hostname, i.e. the FQDN used by UE when it contacts the NAF;
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 Zn;
The NAF shall be able to indicate to the BSF the single application or several applications it requires USSs for;

NOTE 2:
If some application needs only a subset of an application-specific USS, e.g. only one IMPU or MSISDN, 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;

NOTE 3:
Privacy issues need be considered when determining which user identifier is sent to the NAF. If service continuity is desired, then the BSF can be configured to send the IMPI. If HLR is utilized instead of HSS, BSF can be configured to send MSISDN over Zn (but then there is no user anonymity). If the BSF does not send the IMPI, MSISDN or IMPU / pseudonym in the USS, then the user remains anonymous towards the NAF; or more precisely, the B-TID functions as a temporary user identifier. This can cause that the NAF cannot provide a continuous service, since a user identity is needed in the NAF to ensure that the NAF is able to update keys for a Ua session when the UE has bootstrapped and contacts the NAF with a new B-TID. If user privacy is desired, the NAF can requests a USS and the BSF is configured to send a user pseudonym in the USS, but not the IMPI.
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 Zn 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 4:
For more information on the local policy usage, see Annex J.
The BSF shall be able to indicate to the NAF the bootstrapping time and the lifetime of the key material. The key lifetime sent by the BSF over Zn shall indicate the expiry time of the key, and shall be identical to the key lifetime sent by the BSF to the UE over Ub.

NOTE 5:
This does not preclude a NAF to refresh the key before the expiry time according to the NAF's local policy.

NOTE 6:
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 Zn reference point (provided that the BSF has updated subscriber's GUSS from the HSS over Zh reference point).
The BSF shall remove any existing attribute indicating NAF Grouping from the USSs sent to NAFs.
NAF shall be able to indicate to BSF the protocol identifier of Ua security protocol it requires the key material by sending NAF-Id to BSF (cf. Annex H).

4.4.7 Requirements on Bootstrapping Transaction Identifier p. 22

Bootstrapping transaction identifier (B-TID) shall be used to bind the subscriber identity to the keying material in reference points Ua, Ub and Zn.

Requirements for B-TID are:

B-TID shall be globally unique;
B-TID shall be usable as a key identifier in protocols used in the reference point Ua;
NAF shall be able to detect the home network and the BSF of the UE from the B-TID.

NOTE 2:

Care has to be taken that the parallel use of GBA and non-GBA authentication between UE and NAF does not lead to conflicts, e.g. in the name space. This potential conflict cannot be resolved in a generic way as it is dependent on specific protocol and authentication mechanism used between UE and application server. It is therefore out of scope of this specification.

For the example of HTTP Digest authentication used between UE and NAF, parallel use is possible as the following applies: <username,password>-pairs must be unique to one realm only. As the NAF controls the realm names, it has to ensure that only the GBA based realm is named with the reserved 3GPP realm name. In the special case that the NAF wants to allow non GBA based authentication in the GBA realm also, it has to ensure that no usernames in the format of a B-TID are used outside GBA based authentication.

4.4.8 Requirements on selection of UICC application and related keys p. 23

When several applications are present on the UICC, which are capable of running AKA, then the ME shall choose one of these UICC applications for performing the GBA procedures specified in this document in the following order of preference:

The UE determines which UICC application is to be involved:
1. the application on the ME that needs Ks_NAF (Ua application) may indicate to the GBA support function (GBA function) the type or the name of the UICC application: no preference, USIM, ISIM, or the "Label" (see definition in TS 31.101) of the UICC application.
  
  NOTE 1:
  A Ua application specification may require the use of only a USIM (e.g. in MBMS) or only an ISIM.
  
  NOTE 2:
  A user or operator may want to use a Ua application with a specific UICC application indicated by the "Label". This could be configured in the Ua application in the ME by the user or the operator.
  
  A Ua application may require to use the same UICC application in the first and all consecutive runs of Ub protocol for a Ua application instance to ensure that IMPI is not changed during a Ua application session which lasts over several runs of Ub protocol. In this case the Ua application shall request the GBA function to run the Ub protocol with the UICC application that is indicated by the corresponding "Label" or IMPI, depending on which one is available. If both are available, then IMPI shall be used to indicate which UICC application is to be used by the GBA function.
  If the application on the ME indicated a "Label" of the UICC application, step b below shall be executed.
  If the application on the ME indicated that the UICC application type should be:
  - the USIM; step b below is skipped and in steps c and d only USIM applications are considered.
  - the ISIM; step b below is skipped and in steps c and d only ISIM applications are considered.
    if the application on the ME did not indicate a preference, step b below is skipped and the selection process is executed as described below, starting with step c;
2. if a "Label" was indicated in step a:
  At most, there can be only one USIM active at one time. Therefore, if the USIM indicated in the "Label" by the Ua application is different to the currently active USIM application, then the ME shall reject this request.
  If a different ISIM to the currently active ISIM application(s) is indicated to the GBA support function by the Ua application, then the ME shall not terminate the currently active ISIM application(s) but the ME shall follow the procedure in chapter 4.4.8.1 when activating the ISIM application indicated by the "Label", as the UE is allowed to have several ISIM's active simultaneously.
3. if no "Label" was indicated in step a and there are UICC applications active:
  If a preferred UICC application type was indicated but no UICC application of this type is active then step d shall be followed.
  If a preferred UICC application type was indicated and there are active UICC applications of this preferred type, then the GBA function shall choose:
  - if the preferred UICC application type is USIM then the active USIM is selected
  - if the preferred UICC application type is ISIM and only one ISIM is active then this is selected
  - if the preferred UICC application type is ISIM and more than one ISIM is active then the GBA function may show a UICC application choosing dialogue to the end user (the list contains the "Labels" from the application list of all active ISIM applications on the UICC), from which the end user chooses the UICC application to be selected; if no dialogue is shown the GBA function shall select an active ISIM.
  If no preference was given and there is more than one active UICC application, the GBA function may show a UICC application choosing dialogue to the end user (the list contains the "Labels" from the application list of all active UICC applications), from which the end user chooses the UICC application to be selected; if no dialogue is shown the GBA function shall select the active USIM application, if an active USIM application exists, otherwise any active ISIM application.
  If no preference was given and there is only one active UICC application, then the GBA function selects this active UICC application;
4. if no "Label" was indicated in step a and if there are no UICC applications active active or if there is no UICC application of the preferred UICC application type active:
  - if there is only one UICC application on the UICC, the GBA function selects it, if possible;
  - if there is more than one UICC application on the UICC, the GBA function may show a UICC application choosing dialogue to the end user (the list contains the "Labels" from the application list of the UICC), from which the end user chooses the UICC application to be selected. If a preferred UICC application type was indicated and there are UICC applications of this type on the UICC, then the list shown contains only UICC applications of this type, otherwise the list contains all UICC applications on the UICC. If no dialogue is shown the GBA function shall select the "last selected" UICC application of the preferred type (i.e. either the "last selected" USIM or the "last selected" ISIM depending on the given preference), if possible. In case the Ua application indicated "no preference" and both USIM and ISIM are present on the UICC, then the "last selected" USIM is selected.
  The procedure in clause 4.4.8.1 shall be followed.
5. if the UICC application type indicated in step a and used in step c and/or d was ISIM, but there was no ISIM to select, then step c and/or d is repeated with UICC application type USIM; otherwise the selection process fails.
  
  NOTE 3:
  Step e is required for the case that an ISIM as defined in TS 33.203 may be realised using a USIM application on the UICC.
If there already is a key Ks derived from the chosen UICC application, the UE takes this key to derive Ks_NAF.
If there is no such key Ks, the UE first runs the Ub protocol involving the selected UICC application and then goes to step 2.

If a USIM is chosen, the IMPI obtained from the IMSI stored on the USIM as specified in clause 13.3 of TS 23.003, is used in the protocol run over Ub.

If an ISIM is selected, the IMPI stored on the ISIM is used in the protocol run over Ub.

Whenever a UICC application is successfully selected or terminated, the rules in this clause for choosing the UICC application are re-applied and, consequently, the UICC application chosen for GBA may change.

4.4.8.1 UICC application activation procedure in GBA p. 24

UICC application activation is defined in TS 31.101.

If activation of a new UICC application fails then the GBA function shall indicate this to the Ua application.

4.4.9 Requirements on reference point Ua p. 25

The generic requirements for reference point Ua are:

the UE and the NAF shall be able to secure the reference point Ua using the GBA-based shared secret;

NOTE:
The exact method of securing the reference point Ua depends on the application protocol used over reference point Ua.
in the case of GBA_U, the UE and the NAF shall be able to agree which key (i.e, Ks_ext_NAF or Ks_int_NAF or both) is used as the GBA-based shared secret if both keys may be used;
There are two ways to have an agreement between the UE and the NAF which key shall be used Ks_(ext)_NAF or Ks_int_NAF or both:
1. In a generic case, where the protocol used over reference point Ua can be used for different applications (e.g., HTTPS), the protocol should be able to indicate which key should be used.
2. In a specific case, where the protocol is application specific (e.g., MIKEY in MBMS), the agreement can be based on implicit knowledge.
any security protocol over Ua shall be associated with a Ua security protocol identifier. This identifier shall be specified in Annex H of this specification.
the NAF shall be able to indicate to the UE that GBA-based shared secret should be used;
the NAF shall be able to indicate to the UE that the current shared secret has expired and the UE should use newer shared secret with the NAF.
The default lifetime of the NAF specific key material Ks_(ext/int)_NAF shall be equal to the lifetime of Ks when not specified within the Ua-application specification. The lifetime of the Ks_(ext/int)_NAF shall not exceed the lifetime of corresponding Ks. If a lifetime for the Ks_(ext/int)_NAF (or further adapted key material) is available in the NAF, due to a Ua application specification having its own lifetime value or due to NAF having it's own policy for the adapted key material, then if this lifetime is different from the Ks lifetime received from the BSF, then the NAF shall always select the minimum value for the lifetime out of these two.
The UE and NAF may adapt the key material Ks_(ext/int)_NAF to the specific needs of the reference point Ua. This adaptation is outside the scope of this specification. The default lifetime of the adapted key material shall be equal to the lifetime of Ks_(ext/int)_NAF when not specified within the Ua-application specification. The lifetime of the adapted key material shall not exceed the lifetime of corresponding Ks_(ext/int)_NAF. If a lifetime for the Ks_(ext/int)_NAF (or further adapted key material) is available in the NAF, due to a Ua application specification having its own lifetime value or due to NAF having it's own policy for the adapted key material, then if this lifetime is different from the Ks lifetime received from the BSF, then the NAF shall always select the minimum value for the lifetime out of these two.

4.4.10 Requirements on reference point Dz p. 25

This interface between BSF and SLF is used to retrieve the address of the HSS which holds the subscription for a given user. This interface is not required in a single HSS environment.

4.4.11 Requirements on GBA keys and parameters handling p. 25

When referring to GBA keys, the following keys are intended: Ks and NAF specific keys derived from the Ks. When referring to NAF specific keys, the following keys are intended: Ks_ext/int_NAF (in GBA_U context) and Ks_NAF (in GBA_ME context), and any keys derived from these keys. The notation Ks_(ext/int)_NAF refers to Ks_ext/int_NAF in GBA_U context and Ks_NAF in GBA_ME context. The notation Ks_(ext)_NAF refers to Ks_ext_NAF in GBA_U context, and Ks_NAF in GBA_ME context.

The ME shall delete all GBA keys (i.e., Ks, and NAF specific keys) and the corresponding NAF_IDs, B-TID, Ks_(int/ext)_NAF lifetimes, Ks lifetime, and lifetime (of the keys derived from Ks_(ext)_NAF) when at least one of the conditions below is met:

the UICC is removed from the ME when the ME is in power on state;
the ME is powered up and the ME discovers that another UICC has been inserted to the ME. For this, the ME needs to store in non-volatile memory the last inserted UICC-identity to be able to compare that with the used UICC-identity at UICC insertion and power up; or
the ME is powered up and the ME discovers that no UICC has been inserted to the ME.

The ME shall delete all GBA keys related to a certain Ks (i.e., Ks itself, and NAF specific keys derived from this specific Ks) and the corresponding NAF_IDs, B-TID, Ks_(ext/int)_NAF lifetimes, Ks lifetime, and lifetime (of the keys derived from Ks_(ext)_NAF) when the key lifetime of this specific Ks expires.

In the case of GBA_ME, the key Ks shall be deleted from the ME when the ME is powered down. The NAF specific keys (i.e. Ks_(ext)_NAF and keys derived therefrom, if any) may be deleted from the ME when the ME is powered down. If the ME does not delete these NAF specific keys at power down then the NAF specific keys (i.e. Ks_(ext)_NAF and keys derived therefrom, if any) together with the NAF_IDs, B-TID, Ks_(ext)_NAF lifetime and lifetimes (of the keys derived from Ks_(ext)_NAF) shall be stored in non-volatile memory.

If the NAF specific keys are stored in non-volatile memory, then when the ME is powered up again, the ME may need to ensure that the same UICC application is selected for the Ua application, in order to allow the re-use of the NAF specific keys (i.e. Ks_(ext)_NAF and keys derived therefrom, if any), cf. clause 4.4.8. For this, the ME shall store also the IMPI in non-volatile memory. If the same UICC application can not be selected for a Ua application at UE power up, then the ME shall delete the NAF specific keys related to that IMPI stored in non-volatile memory.

Whenever a UICC application is terminated (see clause 4.4.8) the shared key Ks established from it in the protocol over the Ub reference point (according to clauses 4.5.2 and 5.3.2) shall be deleted.

4.4.12 Requirements on reference point Zh' |R7| p. 26

This reference point is optional for the BSF to support. The requirements for reference point Zh' are:

mutual authentication, confidentiality and integrity shall be provided;

NOTE 1:
This requirement may be fulfilled by physical or proprietary security measures, since BSF and HLR are located within the same operator's network.
the BSF shall be able to send an authentication vector request concerning a subscriber;
the HLR shall be able to send one authentication vector, as described in TS 29.109 at a time to the BSF;
no other GBA functionality than conveying authentication vectors shall be required on Zh';
no state information concerning bootstrapping shall be required in the HLR;
all procedures over reference point Zh' shall be initiated by the BSF;
the number of different interfaces to HLR should be minimized.

NOTE 2:
If support of GBA User Security Settings (GUSS) is desired in combination with HLR or HSS with Zh' reference point support, then this can be achieved, for instance by storing the GUSS information in a BSF database (external and/or external to the node itself), or in any other network database which is deemed as appropriate for a specific deployment. GUSS information is not sent over Zh' reference point.

4.4.13 Requirements on TMPI handling |R8| p. 27

The BSF shall store a TMPI together with the IMPI, from which it was derived (cf. Annex B.4), until the next bootstrapping procedure is executed using this TMPI.

The BSF may have a local policy for deleting stored (TMPI, IMPI)-pairs before the next bootstrapping procedure is executed using this TMPI, e.g. for storage or performance reasons.

The ME shall store a TMPI together with the IMPI, from which it was derived (cf. Annex B.4), in non-volatile memory.

The ME shall delete all stored (TMPI, IMPI)-pairs when at least one of the conditions below is met:

the UICC is removed from the ME when the ME is in power on state; or
the ME is powered up and the ME discovers that another UICC has been inserted to the ME. For this, the ME needs to store in non-volatile memory the last inserted UICC-identity to be able to compare that with the used UICC-identity at UICC insertion and power up; or
the ME is powered up and the ME discovers that no UICC has been inserted to the ME.