Aggregation Proxy and Bootstraping

There were three telco engineers.

One was confused.

Second one was unsure.

And the third one also worked with IMS.

The self-confidence is a key for a trainer. And honestly that’s what I lack with IMS. There are so many things, specifications, flows which I’m not sure about. I can read several different specs about one network functionality, each claiming something slightly different but all of them very vague about some particular feature I’m interested in. That’s why I like the wireshark. The problem is that even the traces can differ deployment to deployment, vendor to vendor. But at least that is something I can touch.

When I started with the RCS I’ve seen various callflows which contained some ‘AP’ or ‘AG’ box. This network function is an http or ws API (REST/SOAP/XCAP/any other) gateway into the IMS network. I was a bit confused, because always it was called by a different name and the function was not always the same. It took me some time to sort it out (at least partially ;)).

We’ve already seen one of those boxes – the Authentication Proxy. This time we will discuss the Aggregation and Cross-Network Proxies. The Authentication proxy is standardized by GSMA as VoLTE network function. In contrast to that the Aggregation Proxy is an RCS network element defined by OMA in XML Document Management specs.

Otherwise they are very similar and in practice they can be implemented within the same physical system as both of them are used to allow users to manipulate data over http without the need to go through the SBC.

 

Aggregation Proxy

 

And indeed, when we take a closer look, we can see (as stated in the specification) that for a 3GPP IMS or 3GPP2 MMD realisation, the XDM-3 and XDM-5 reference points correspond to the Ut reference point. In other words Aggregation and Authentication proxy are supposed to work in the same way from the UE perspective (e.g. we’ll use GAA or Http Digest for authentication). We can reuse the BSF and NAF functionality we have implemented for Authentication proxy. So if we know the Authentication Proxy we already know most of the stuff.

Aggregation Proxy

The Aggregation Proxy (we can understand it as NAF) is the entry point for the UE into the IMS network in order to access XML documents from XDMS. The Aggregation Proxy is responsible for:

• Authentication
• Routing of XCAP requests to a particular XDMS (including those in remote networks)
• Optionally supports charging or compression over the radio interface

The Aggregation Proxy acts as an HTTP Reverse Proxy. Upon the successful authentication, asserts the identity of the originator in the http message.

 

Aggregation Proxy – GBA

UE<->NAF

For XCAP requests, the UE must be preconfigured or provisioned by the home operator with the Network Identifier part of the APN for Home Operator Services to be used for these requests (see GSMA PRD IR.88 for more information).

During the GBA authentication we have to mutually authenticate all three elements UA with BSF (Ub reference point), NAF with BSF (Zn reference point) and UE with NAF (Ua reference point).

Ua reference point

UE always sends its request firstly to NAF. The UE has to indicate its capability to do bootstraping via User-Agent header with shall contain “3gpp-gba” or “3gpp-gba”tag. “3gpp-gba” in case the HTTP client application resides in the ME, the “3gpp-gba-uicc” if the HTTP client application resides directly in the UICC.

If NAF doesn’t have valid key materials for UE (new connection, session expired), it responds with bootstraping initiation message 401. This response in the www-authenticate header contains nonce and realm. 

Based on the realm UE knows that it is supposed to contact BSF because of the bootstraping procedure.

UE<->BSF<->HSS

UE sends a new request to BSF. The BSF discovery is described in the 3GPP 23.003. In general UE shall discover the BSF address from the identity information related to the UICC application that is used during the bootstrapping procedure i.e. IMSI for USIM, or IMPI for ISIM. Mind that BSF is located in the home network of the subscriber.

Example: If the IMPI in use is “user@ims.mnc012.mcc345.3gppnetwork.org”, the BSF address would be

bsf.ims.mnc012.mcc345.pub.3gppnetwork.org

Now the User-Agent header has value “Bootstraping Client Agent”. This message is kind of equivalent to initial registration over Gm interface.

Ub – Bootstraping

BSF is in the home network and provides the authentication. In order to retrieve the authentication vectors it sends Multimedia-Auth-Request MAR to HSS (yes, that what does the S-CSCF). The key here is the IMPI. In MAA response it will get the SIP-Auth-Data-Item AVP and GBA User Security Setting (GUSS).

The BSF generates the needed key material (Ks) from confidential key (CK) and integrity key (IK) as described in 3GPP TS 33.220 and stores temporarily the tuple <impi,ks,gba-usersecsettings> for further use in GAA applications.

Based on the information provided by HSS the BSF challenges the UE with 401.

UE will verify the identity of IMS network (AUTN) and generates key material (Ks). Then it sends a new http request to BSF which contains response. BSF compares the response (MD5 hash) with the expected response which got in SIP-Authorization AVP from HSS. If it does match the user is authorized and can access the IMS network.

3GPP AKA

In the final 200 OK response the BSF generates a unique Bootstrapping Transaction Identifier (B-TID) as defined in ETSI TS 33.220. The B-TID is used as a key for the user tuple.

UE<->NAF<->BSF

Once the UE knows the B-TID and key material (Ks) it can start with the GAA application procedure. So it generates a new http request. It is the same request as the first one sent to NAF. But this time it contains in the Authorization header the B-TID and response.

Ua and Zn reference points

The NAF needs firstly to verify that the UE is authorized by BSF. Therefore it sends Boostraping-Info-Request (BIR) to BSF. The request contains B-TID and NAF Identifier (NAF-Id). The BSF verifies the presence and validity of B-TID. In the successful case the BSF has a tuple <b-tid,impi,ks, key=”” lifetime,=”” bootstrapinfo=”” creation=”” time,=”” gbausersecsettings=””>.

The BSF shall check if this NAF-Id is allowed to be used for the NAF (Verify IP, FQDN, also the BSF may be configured so that a certain NAF is not authorized to use a certain GAA-Service-Identifier).

If the NAF is authorized, then the BSF derives the key material for the ME (i.e., Ks_NAF in the case of GBA_ME, and Ks_ext_NAF in the case of GBA_U) and possibly the key material for the UICC (i.e., Ks_int_NAF in the case of GBA_U) according to the B-TID and packs them into ME-Key-Material AVP and possible UICC-Key-Material AVP. The ME-Key-Material contains Ks_(ext)_NAF and the UICC-key-Material contains the Ks_int_NAF key. The BSF selects correct user’s Security Settings according the request’s GAA-Service-Identifier AVP to GBAUserSecSettings AVP.

The BSF responds with BIA to NAF with the Key Material, GUSS, Expiry Time and the response can also contain IMSI. The mandatory common key material with the ME (Ks_NAF or Ks_ext_NAF) is sent in the ME-Key-Material AVP. The common key material with the UICC (Ks_int_NAF) is optionally sent in the UICC-Key-Material AVP only if the “uiccType” tag in bsfInfo from the HSS is set to “GBA_U”.

Now the NAF can authenticate the UE. If the authentication was successful NAF will analyse the http URL and will provide a correct routing and any other necessary modification of the message content.

 

As you probably noticed there are several possible variants of the GBA. For further details please refer to spec (ETSI TS 29.109, ETSI TS 33.220 and others).

 

Cross-Network Proxy

The Cross-Network Proxy  (CNP) is a single contact point for the XDM enablers located in other networks to communicate over trusted connection. The purpose of the CNP is to perform authorization of trusted networks. The CNP acts as an HTTP Proxy and communicates with Cross-Network Proxies from remote networks. Upon receiving XCAP requests from the Aggregation Proxy acts as an HTTP Reverse Proxy.

The CNP shares the client authentication and its identity assertion with the Aggregation Proxy and verifies if the target from a remote domain is in a trusted domain.

 

XCAP

The protocol which we use for the data management is again  the XML Configuration Access Protocol (XCAP). We use it in the same way as we did it in case of Supplementary Services of Ut. In case of OMA we work mostly with the data related to the Presence Management or Converged Address Book.  The XCAP is defined in the RFC 4825 and you can find more details in the XCAP Protocol post.

 

XDMS Flow

 

Looking at the flows – is there any difference comparing to the Authentication proxy? Not really. The authentication proxy routes the requests to the AS (MMtel/TAS) and the AS then proxies the data to the database (HSS/CNTDB). In case of aggregation proxy we work directly with the XDMS databases.

Advertisement