GUSS stands for "GBA (Generic Bootstrapping Architecture) User Security Settings."

These settings are provisioned for each subscriber in the HSS. This section covers how the Sentinel Authentication Gateway components access and use the GUSS.

What is the GUSS?

The GUSS for a particular subscriber determines what applications (NAFs) they can access, and may also define custom network- or application-specific parameters. It also specifies the lifetime of a bootstrapped security association, sometimes referred to as the "key lifetime."

The authoritative source for GUSS is the HSS. Consult your HSS documentation for details on provisioning GUSS.

The external representation of the GUSS is an XML document using the schema defined in 3GPP TS 29.109 Annex A. Here is an example:

Example GUSS XML
<guss id="358500004836551@home1.net" xmlns="urn:3gpp:gba:GBAGUSSSchema-R9:2010-02">
  <bsfInfo>
    <lifeTime>86400</lifeTime>                   1
  </bsfInfo>
  <Extension>
    <timestamp>2008-09-10T11:12:13Z</timestamp>  2
  </Extension>
  <ussList>
    <uss id="0" type="0" nafGroup="A">           3
      <uids>
        <uid>tel:+358504836551</uid>
        <uid>sip:user@home1.net</uid>
      </uids>
    </uss>
    <uss id="1" type="1" nafGroup="B">           4
      <uids>
        <uid>sip:other@home1.net</uid>
      </uids>
      <flags>
        <flag>1</flag>                           5
      </flags>
    </uss>
  </ussList>
</guss>
1 The lifetime of a security association created for this subscriber, in seconds.
2 The timestamp showing when the GUSS was last updated.
3 A USS entry containing two public identities.
4 A USS entry containing another public identity.
5 Flags that apply to the service type.

The GUSS cache

The BSF Server maintains a cache of GUSS documents for subscribers that it has authenticated. This cache is implemented as a Cassandra table, by default called guss_by_impi [1]. As the name implies, this table is indexed by the IMPI, the subscriber’s IMS private identity.

The GUSS cache serves two purposes:

  1. When querying the HSS over Zh, the BSF can use the GUSS timestamp mechanism so that the HSS only returns the GUSS if it has changed since the last timestamp. Otherwise the cached GUSS can be used.

  2. When any NAF Authentication Filter node needs the GUSS, it can be obtained from the replicated Cassandra database without the involvement of the BSF or HSS.

GUSS usage in the BSF Server

Tip Refer to the listing above to see the elements discussed here.

The BSF Server uses these parts of the GUSS:

Lifetime

The /guss/bsfInfo/lifeTime element specifies how long a bootstrapped security association is valid for, in seconds. If a UE attempts to authenticate with a NAF, using a security association that has expired, the NAF must instruct the UE to repeat the bootstrapping process over the Ub interface. While the security association is valid, the UE can authenticate with NAFs without needing to contact the BSF again.

Timestamp

The optional /guss/Extension/timestamp element specifies when the HSS last updated the GUSS. This is used to implement the simple caching mechanism specified in 3GPP TS 29.109 §4.2. If present, the BSF sends the last timestamp to the HSS in the GUSS-Timestamp AVP in the Diameter Zh request. If the HSS supports this mechanism, and the GUSS has not been modified since the timestamp, then the Zh response just includes a flag to say the cached GUSS is still valid. Otherwise the Zh response will include the latest GUSS from the HSS.

If the cached GUSS does not have the timestamp element, the BSF omits the GUSS-Timestamp AVP from the Diameter Zh request. This forces the HSS to return the current GUSS in the Zh response. Upon receiving the GUSS in the Zh response, the BSF will store it in the GUSS cache table.

If the GUSS for a subscriber cannot be found, or the lifeTime element is missing, the BSF uses a default lifetime of 86400s (24 hours).

GUSS usage in the NAF Authentication Filter

Tip Refer to the listing above to see the elements discussed here.

The NAF Authentication Filter retrieves the GUSS from the GUSS cache table, and looks at the /guss/ussList element. This may contain zero or more uss element for different types of service or NAF groups.

The filter selects the uss element(s) that match its configured service ID, type and NAF group. The uid elements inside the uss element specify the public identities for the subscriber that apply to the particular NAF.

If no matching uss elements were selected, then the filter cannot determine a public identity for its NAF (XCAP in our case), so it must reject the request. If one or more uss elements matched, all of the public identities are added to the X-3GPP-Asserted-Identity header, which will be used by XCAP to authorize the request.

If the filter could not retrieve the GUSS for this subscriber, then it rejects the request. The GUSS is essential because it specifies the public identities that are accessing the NAF.

1 See Cassandra Storage for details.
Previous page Next page