The filter performs the role of the NAF, authenticating the requests using GAA procedures. If successful, the authenticated requests and credentials are passed on to the XCAP or Authentication Proxy servlet.
- NAF Authentication Filter operation
- 1. UE makes a request
- 2. NAF filter rejects with challenge
- 3. UE sends challenge response using bootstrapped security association
- 4. NAF filter retrieves bootstrap information
- 5. NAF filter validates the bootstrapped user information
- 6. Filter passes request and credentials to XCAP servlet
- 7a. XCAP servlet requests user data over Sh
- 8. Servlet returns response to filter
- 9. Response sent back to UE
- Authentication Proxy operation
To illustrate how the filter works, we can walk through how the NAF Authentication Filter handles a typical request to the Sentinel VoLTE XCAP server.
An overview of the authentication process, from the filter’s point of view, is shown below.
The steps shown in the diagram are explained in the following sections.
The UE needs to retrieve an XCAP resource, for example to discover configuration settings for an MMTEL service.
The UE selects the authentication mechanism to use through addition of a product token to the
if the UE wishes to use the
GBA_Digestmechanism, then it must include the product token
User-Agentheader (not shown in this example).
if the UE wishes to use the
GBA_MEmechanism, then it must include the product token
if the UE includes neither, then the NAF rejects the request without a challenge
Here we assume the UE knows its XCAP server’s address,
This address may be preconfigured in the UE, or the UE may derive it from the subscriber’s private identity as per 3GPP TS 23.003 §13.9.
The UE constructs the XCAP selector for the resource and sends an HTTP GET request to the XCAP server.
In this example, the UE wants to retrieve the communication diversion (CDIV) configuration for their public identity
GET /rem/sentinel/xcap/simservs.ngn.etsi.org/users/sip:email@example.com/simservs/~~/communication-diversion HTTP/1.1 Host: xcap.home1.net User-Agent: vendorstring/2.0 3gbb-gba
The XCAP server will need to confirm that the request is being made by a device associated with the public identity
The web container (such as Apache Tomcat) sees that the URL is for a resource protected by the filter, so passes the request to the filter.
The filter sees that the request has not been authenticated, because there is no
The filter generates a 401 unauthorized response, containing a challenge.
HTTP/1.1 401 Unauthorized WWW-Authenticate: Digest algorithm=MD5 realm="3GPPfirstname.lastname@example.org" qop="auth-int", nonce="8982ac96f06922330de40902183fa099", opaque="00fffde7845cc67534bdc78f3a9e233"
3GPPemail@example.com tells the UE that bootstrapping is required, and that
GBA_ME is to be used.
At this point the UE must perform the GBA bootstrapping procedure with the BSF. This process is covered separately in the BSF Server section.
Assuming bootstrapping is successful, the authentication process carries on.
WWW-Authenticate header includes the
The same applies to subsequent requests sent by the UE.
After completing bootstrapping, the UE can retry the request using its bootstrapped security association.
The UE should now know the Bootstrapping Transaction Identifier (B-TID), which is used as the username for the HTTP Digest authentication scheme.
The password used is derived from shared secrets generated in the bootstrapping process, and information about the connection to the NAF. This password is known as the NAF-specific shared key, or Ks_NAF.
The UE generates a challenge response using the standard HTTP Digest (RFC 2617) scheme. The username, password, nonce, opaque, and other values from the challenge are combined to calculate the response value:
GET /rem/sentinel/xcap/simservs.ngn.etsi.org/users/sip:firstname.lastname@example.org/simservs/~~/communication-diversion HTTP/1.1 Host: xcap.home1.net Authorization: Digest username="CH8Bm4AA/38BADV/f4DBAQemail@example.com", realm="3GPPfirstname.lastname@example.org", algorithm=MD5, qop=auth-int, uri="/rem/sentinel/xcap/simservs.ngn.etsi.org/users/sip:email@example.com/simservs/~~/communication-diversion" nonce="8982ac96f06922330de40902183fa099", opaque="00fffde7845cc67534bdc78f3a9e233", nc=00000001, cnonce="9856f65d8925a" response="43ef1da9e534fb321476a1679ff8256"
The filter receives the challenge response over HTTP, and must now verify that it is correct.
To do this, the filter queries the
bootstrap_info Cassandra table to find an entry for the username (B-TID).
If an entry exists, it will contain the user’s private identity (IMPI) and also the shared secrets that will be used to calculate Ks_NAF, the password.
The filter also looks up the user’s GBA User Security Settings (GUSS) in the GUSS cache, populated by the BSF. If no bootstrap information or GUSS is found, the filter must reject the request as it does not have enough information to continue.
Now the filter calculates Ks_NAF, and uses this value as the password in its HTTP Digest calculation. If everything is correct, the filter will calculate the same value that the UE sent in the challenge response. This means the request has been successfully authenticated — the filter can now pass the request to the XCAP servlet.
Before doing so, the filter must also determine which IMS public identities (IMPUs) are associated with the request.
This is determined by the
ussList element from the user’s GUSS, and also the filter’s settings for service ID, service type and NAF group.
See GUSS usage in the NAF Authentication Filter for details.
The user is now authenticated, and the filter knows the public identities associated with the request.
The filter adds the
X-3GPP-Asserted-Identity header to the request, with the known public identities.
The servlet container knows that the request should to be routed to the XCAP servlet, based on the
The request header seen by the XCAP servlet looks like this:
GET /rem/sentinel/xcap/simservs.ngn.etsi.org/users/sip:firstname.lastname@example.org/simservs/~~/communication-diversion HTTP/1.1 Host: xcap.home1.net X-3GPP-Asserted-Identity: "tel:358504836551", "sip:email@example.com" Authorization: Digest username="CH8Bm4AA/38BADV/f4DBAQfirstname.lastname@example.org", realm="3GPPemail@example.com", algorithm=MD5, qop=auth-int, uri="/rem/sentinel/xcap/simservs.ngn.etsi.org/users/sip:firstname.lastname@example.org/simservs/~~/communication-diversion" nonce="8982ac96f06922330de40902183fa099", opaque="00fffde7845cc67534bdc78f3a9e233", nc=00000001, cnonce="9856f65d8925a" response="43ef1da9e534fb321476a1679ff8256"
The XCAP servlet sees that one of the asserted identities ("sip:email@example.com") matches the XCAP User Identity (XUI) in the Request-URI, so allows the request to proceed. If the XUI did not match an asserted identity, the request would be rejected immediately.
The XCAP servlet uses the Sh Cache Microservice to retrieve the supplementary services transparent data for this identity from the HSS.
Assuming the data is found, it applies the XCAP selector to extract the requested portion of the XML document, in this case the
The XCAP servlet generates a 200 OK response with the
communication-diversion element, and returns from its
At this point control returns to the filter.
If the requested
qop (Quality of Protection) parameter was
auth-int, the filter must calculate a response digest so that the UE can verify the integrity of the response.
The filter calculates the digest over the response body, and adds the
Authentication-Info header to the response.
Finally the HTTP response is transmitted back to the UE. The response seen at the UE will be something like this:
HTTP/1.1 200 OK Authentication-Info: qop=auth-int, cnonce="9856f65d8925a", nc=00000001 rspauth="a8478cea0d1f23ba975af498954c62d" Content-Type: application/vnd.etsi.simservs+xml Content-Length: 123 <communication-diversion> ... </communication-diversion>
The NAF Authentication Filter also applies authentication processing to requests to the Authentication Proxy, which are intended
to be passed to other web applications, rather than XCAP. This is signalled by the URL path starting with
In this case, the processing is almost identical to the XCAP case described above, except that the request is now routed to the Proxy Servlet, and step 7a is replaced by the following.
DNS "A" records have been set up for new externally-visible hostnames of the back-end web servers which will serve the request, resolving to the externally-visible IP address of the NAF Authentication Filter. This causes requests to those web servers to arrive at the NAF Authentication Filter.
The Proxy Servlet inspects the
Host: HTTP header on the incoming request, to determine the service that the
request was intended for. It looks up that hostname in its configuration, to see which back-end server
it needs to proxy the request to. At this point, if the Proxy Servlet does not recognise the hostname, then
it returns a
404 Not found response.
The servlet strips the leading
/rem/authproxy from the URL path, and combines it with the mapped
hostname to calculate the final URL that will be requested. It strips the
X-3GPP-Intended-Identity headers from the request, if present, then makes the request.
When the response comes back, the Proxy Servlet passes it back to the filter, and processing continues with step 8 as above.
Ordinarily the Proxy Servlet will use the status code from the back end server in its own response to the filter
layer, but if an error occurs sending the request, then the Proxy Servlet may return a