M.3 Network elements

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

M.3.1 Bootstrapping server function (BSF)

A generic Bootstrapping Server Function (BSF) and the UE shall mutually authenticate using a combination of the HTTP Digest protocol and the TLS protocol, and agree on session keys that are afterwards applied between UE and a Network Application Function (NAF). The BSF shall restrict the applicability of the key material to a specific NAF by using the key derivation procedure as specified in Annex B. The key derivation procedure may be used with multiple NAFs during the lifetime of the key material. The lifetime of the key material is set according to the local policy of the BSF. The generation of key material is specified in clause M.6.3.

The BSF shall be able to acquire the GBA user security settings (GUSS) from the HSS.

The BSF shall discover from the request received from the UE over the Ub interface whether the UE intends to run GBA_Digest. The BSF shall then request a SIP Digest authentication vector from the HSS or abort the Ub run with a suitable failure message, according to its local policy.

The BSF shall be able to keep a list, which assigns NAFs to NAF Groups. This list is used to select if any and which application-specific USS within GUSS is valid for a certain NAF.

NOTE 1: The operator does the assignment of NAFs to NAF Groups. NAF Group definitions in HSS and all connected BSFs belonging to the same operator’s network shall be equal (cf., clause I.2.3). As these network elements belong to the same operator’s network, standardisation of the NAF Group definitions themselves is not necessary in 3GPP.

NOTE 2: The NAF grouping may be e.g. "home" and "visited". It allows the BSF to send USSs for the same application with e.g. different authorization flags to different NAFs, e.g., in home network and visited networks. The NAF e.g. in visited network indicates only the requested application, but it is unaware of the grouping in home network of the subscriber.

The BSF shall allow the operator to configure a BSF policy whether to accept subscribers using SIP Digest credentials or not for a certain NAF.

M.3.2 Network application function (NAF)

After the bootstrapping has been completed, the UE and a NAF can run some application specific protocol where the authentication of messages will be based on those session keys generated during the mutual authentication between UE and BSF.

General assumptions for the functionality of a NAF are:

– there need not be a previous security association between the UE and the NAF;

– NAF shall locate and communicate securely with the subscriber’s BSF;

– NAF shall acquire a shared key material established between UE and the BSF during the run of the application-specific protocol;

– NAF shall be able to acquire zero or more application-specific USSs from the HSS via the BSF;

– NAF shall be able to set the local validity condition of the shared key material according to the local policy;

– NAF shall be able to check lifetime and local validity condition of the shared key material;

– NAF shall have a policy whether to accept subscribers using SIP Digest credentials. However, whether GBA_Digest is allowed to be used with a specific Ua application or not, is dependent on the relevant Ua application. If there is a specific TS for an application using a particular Ua protocol, and unless this TS explicitly prohibits the use of GBA_Digest, the NAF may allow usage of SIP Digest credentials for this application,

– the NAF shall be able to indicate to the UE that the SIP Digest-based GBA bootstrapping security association is acceptable.

NOTE: Without additional measures, GBA, as defined throughout the present document, does not guarantee the freshness of the key, Ks_NAF, in the sense that it does not guarantee that the key was not used in a previous run of the Ua protocol. The additional measures which may be taken by the UE and the NAF to ensure key freshness in GBA are:

1) enforce a new run of the Ub protocol (thus generating a new Ks) before deriving a new Ks_NAF;

2) store previously used keys Ks_NAF, or the corresponding key identifiers B-TID, until the end of their lifetime.

A UE and a NAF that support a Ua protocol that does not provide replay protection over unconnected runs of the protocol, will need to take corresponding action to avoid replay attacks if desired.

M.3.3 Zn-Proxy

The text from clause 4.2.2a applies also here.

M.3.4 HSS

The set of all user security settings (USSs), i.e. GUSS, is stored in the HSS.

The requirements on the HSS are:

– HSS shall provide the only persistent storage for GUSSs;

– GUSS shall be defined in such a way that interworking of different operators for standardised application profiles is possible;

– GUSS shall be defined in such a way that profiles for operator specific applications and extensions to existing application profiles are supported without need for standardisation of these elements.

– GUSS shall be able to contain application-specific USSs that contain parameters that are related to identification or authorization information of one or more applications hosted by one ore more NAFs. Any other types of parameters are not allowed in the application-specific USS.

NOTE 1: The necessary subscriber profile data may be fetched by the NAF from its local database.

NOTE 2: One possibility to revoke temporarily an application specific USS from the GUSS is that the HSS may temporarily remove an application-specific USS from the GUSS if the service is temporarily revoked from the subscriber. The GUSS in the BSF is not changed by this operation and only updated when the existing bootstrapping session times out, or is overwritten by a new bootstrapping session during which the new modified GUSS is fetched from HSS along with the AV.

– GUSS shall be able to contain parameters intended for the BSF usage:

– subscriber specific key lifetime;

– optionally the timestamp indicating the time when the GUSS has been last modified by the HSS.

NOTE 3: These parameters are optional and if they are missing from subscriber’s GUSS or subscriber does not have GUSS then the BSF will use the default values in the BSF local policy defined by the particular MNO.

– HSS shall be able to assign application-specific USSs to a NAF Group. This shall be defined in such a way that different USSs for the same application, but for different groups of NAFs, are possible. The restrictions on the number of USSs per GUSS are dependent on the usage of NAF Groups by the operator:

– if no NAF Groups are defined for this application then at most one USS per application is stored in GUSS;

– if NAF Groups are defined for this application then at most one USS per application and NAF Group is stored in GUSS.

– NAF Group definitions in the HSS and all connected BSFs belonging to the same operator’s network shall be equal.

– Information on UICC type and on key choice are not required for subscribers using SIP Digest credentials. GBA_Digest is regarded as ME-based.

M.3.5 UE

The required functionalities from the UE are:

– the support of HTTP Digest protocol according to RFC 7235 [61] and RFC 7616 [62] with the additional profiling specified in this Annex;

– the support of TLS;

– the capability to use SIP Digest credentials in bootstrapping;

– the capability for a Ua application on the terminal to indicate to the GBA Function on the terminal whether SIP Digest credentials are allowed for use in bootstrapping;

– the capability to derive new key material to be used with the protocol over the Ua interface as defined in clause M.6.3;

– support of at least one Ua application protocol (For an example see TS 33.221 [5]);

– the capability to send an indication to the BSF over the Ub interface that the UE intends to run GBA_Digest.

M.3.6 SLF

The text from clause 4.2.5 applies also here.