M.5 Requirements and principles for bootstrapping

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

M.5.1 General Requirements

The following requirements and principles are applicable to bootstrapping procedure:

– the GBA_Digest 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;

– If USIM, ISIM, or SIM are available and the BSF supports AKA-based GBA the UE shall not use GBA_Digest. Instead, the UE shall use the procedures as specified in clauses 4 and 5, and Annex I;

– GBA_Digest shall not impact the procedures for AKA-based GBA as specified in clauses 4 and 5, and Annex I;

– GBA_Digest shall not reduce security for users of AKA-based GBA;

– GBA_Digest shall be closely modelled after AKA-based GBA specified in clauses 4 and 5, and Annex I;

– GBA_Digest shall provide measures to mitigate known vulnerabilities of the re-use of SIP Digest credentials.

M.5.2 Access independence

The bootstrapping procedure for GBA_Digest is, in principle, access independent as it only requires IP connectivity from the UE. However, in order to ensure that GBA_ Digest is not used over access networks defined in 3GPP specifications operators may introduce some access dependence in their network configurations, e.g. by assigning different ports on the BSF to different access networks.

M.5.3 Authentication methods

Authentication between the UE and the BSF shall not be possible without a valid IMS subscription. Authentication shall be based on a combination of the HTTP Digest protocol using SIP Digest credentials and the TLS protocol, as defined in clause M.6.3. TLS shall be used with server certificates, but the TLS server shall not request client certificates.

M.5.4 Roaming

The requirements on roaming are:

– A subscriber located outside the home network shall be able to utilize the bootstrapping function in the home network. The subscriber shall be able to utilize a network application function that is outside the home network.

– The home network shall be able to control whether its subscriber is authorized to use the service outside the home network.

M.5.5 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 authenticate each other based on the methods specified in clasue M.5.3;

– the BSF shall send a bootstrapping transaction identifier to the UE;

– the UE and the BSF shall establish shared keys;

– the BSF shall 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.

M.5.6 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 send a bootstrapping information request concerning a subscriber;

– optionally the BSF may have the capability to send the timestamp of subscriber’s GBA user security settings to the HSS (timestamp option);

– the HSS shall send one SIP Digest authentication vector at a time to the BSF;

– the HSS shall 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 the HSS should be minimized.

M.5.7 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 in TS 33.210 [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;

– An HTTP based Zn/Zn’ reference point shall be secured using TLS as specified in Annex E;

– 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 send a key material request to the BSF, containing NAF’s public hostname used by the UE’s corresponding request. The BSF shall verify that a NAF is authorized to use this hostname, i.e. the FQDN used by UE when it contacts the NAF;

– The NAF shall indicate to the BSF for each Zn run whether it is willing to accept Ks_NAF based on GBA_Digest;

– The BSF shall 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 indicate to the BSF the single application or several applications it requires USSs for;

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

NOTE 4: 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).

– If the NAF indicated its willingness to accept Ks_NAF based on GBA_Digest in the Zn request and the B-TID sent by the NAF points to a Ks generated by GBA_Digest the BSF shall send information to the NAF that the subscriber is a subscriber who used SIP Digest credentials. If the B-TID points to a Ks established by another GBA method the BSF shall respond according to that method. Otherwise, the BSF shall not send key material to the NAF.

NOTE 5: This requirement enables a NAF to accept subscribers using SIP Digest credentials according to its local policy. The second sentence ensures backward compatibility with the procedures specified in clauses 4 and 5 and Annex I. Note also that inclusion of information on the GBA variant in the GUSS is not possible as one subscriber may have both AKA and SIP Digest credentials, leading to a depencence on the credentials actually used during the last Ub run.
A NAF that can understand a ‘GBA_Digest’ indication received from the BSF on Zn can understand which GBA variant was used on Ub to derive the Ks_NAF key and, hence, can always make its own judgment whether to accept the Ks_NAF based on its local policy. However, there is no technical reason why the NAF would not accept a Ks_NAF that was derived using an AKA-based GBA variant because such a Ks_NAF is stronger than a key that was derived using GBA_digest and there is no difference in using it for the NAF.

– The BSF may determine according to its local policy that the NAF shall not serve subscribers using SIP Digest credentials. If this is the case, the BSF shall not send keys generated by GBA_Digest to the NAF.

NOTE 6: This requirement allows an operator controlling the BSF to determine which applications shall use AKA-based GBA only.

– The NAF shall indicate to the BSF the protocol identifier of Ua security protocol for which it requires the key material by sending NAF-Id to BSF (cf. Annex H).

M.5.8 Requirements on Bootstrapping Transaction Identifier

The text from clause 4.4.7 applies also here.

M.5.9 Requirements on reference point Ua

The text from clause 4.4.9 applies also here.

M.5.10 Requirements on reference point Dz

The text from clause 4.4.10 applies also here.

M.5.11 Requirements on GBA keys and parameters handling

– The terminal 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 lifetime, and, if applicable, Ks_NAF lifetimes and lifetimes of the keys derived from a Ks_NAF, when the key lifetime of this specific Ks expires.