I.4 Requirements and principles for bootstrapping

33.2203GPPGeneric Authentication Architecture (GAA)Generic Bootstrapping Architecture (GBA)TS

I.4.0 General requirements

The following requirements and principles are applicable to bootstrapping procedure:

– the 2G GBA 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.

– Existing SIM cards or SIMs on UICCs and their specifications shall not be impacted.

– If USIM or ISIM are available they shall be used as specified in sections 4 and 5, and 2G GBA shall not be used.

– 2G GBA shall not impact the USIM / ISIM based GBA as specified in sections 4 and 5.

– 2G GBA shall not reduce security for USIM / ISIM users.

– 2G GBA shall minimise the changes to the USIM / ISIM based GBA specified in section 4.

– 2G GBA shall provide measures to mitigate known vulnerabilities of GSM.

I.4.1 Access Independence

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

I.4.2 Authentication methods

Authentication between the UE and the BSF shall not be possible without a valid cellular subscription. Authentication shall be based on the GSM authentication (also called 2G AKA) protocol. BSF authentication shall in addition be based on TLS with server certificates.

I.4.3 Roaming

The text from section 4.4.3 applies also here.

I.4.4 Requirements on reference point Ub

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 the methods in I.4.2;

– 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: This does not preclude a UE to refresh the key before the expiry time according to the UE’s local policy.

I.4.5 Requirements on reference point Zh

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 2G 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.

I.4.6 Requirements on reference point Zn

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];

– 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 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 if private subscriber identity and which application-specific USSs 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 (but then there is no user anonymity). If the BSF does not send the IMPI 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 configure the BSF in such a way that no USS is required for the requesting NAF;

– 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 4: This does not preclude a NAF to refresh the key before the expiry time according to the NAF’s local policy.

NOTE 5: 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 send information to the NAF that the subscriber is a 2G subscriber. If no such information is sent the NAF shall assume that the subscriber is a 3G subscriber.

NOTE 6: This requirement enables a NAF to accept 2G subscribers according to its local policy. The second sentence ensures backward compatibility with the procedures specified in section 4 and 5 of this specification. Note also that inclusion of information on the type of subscription in the GUSS would not suffice to satisfy this requirement as a GUSS need not be present for every subscriber.

– The BSF may determine according to its local policy that the NAF shall not serve 2G subscribers. If this is the case, the BSF does not send keys to the NAF.

NOTE 7: This requirement allows an operator controlling the BSF to determine which applications shall use 3G security only. This requirement is also necessary for NAFs, which are not capable to evaluate the information about the subscription type sent by the BSF, e.g. pre-release 7 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).

I.4.7 Requirements on Bootstrapping Transaction Identifier

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 1: NAF can remove the security association based on deletion conditions after the key has become invalid.

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.

I.4.8 Requirements on selection of UICC application and SIM card

If a UICC is present in the UE, containing a USIM or an ISIM, then a USIM or ISIM shall be used as specified in section 4.4.8. Otherwise a SIM shall be used.

If no UICC, but a SIM card is present in the UE, the SIM card shall be used. The IMPI is obtained from the IMSI as specified in section 4.4.8.

I.4.9 Requirements on reference point Ua

The text from section 4.4.9 applies also here.

I.4.10 Requirements on reference point Dz

The text from section 4.4.10 applies also here.

I.4.11 Requirements on reference point Zh’

The requirements for reference point Zh’ are the same as in clause 4.4.12.