1. User's Guide
  2. Registrar and Authentication
  3. Message Authentication for SIP Requests

Message Authentication for SIP Requests

You can configure the Oracle Enterprise Communications Broker (OECB) to authenticate REGISTER requests. The OECB offers a single Registrar for location services on user-specified listed domains. Registration may or may not include user authentication. If includes authentication, you can select a local, text-based resource called the Local Subscriber Table (LST) as an authentication source. You can also configure the OECB as an LDAP client, allowing it to perform LDAP-compliant processes and retrieve authentication information from an external resource, usually Active Directory. The OECB populates the registration cache with contacts for AORs upon successful authorization/authentication.

The OECB uses SIP digest authentication as a means of challenging an end point for applicable registration attempts. The following diagram shows the overall authentication and authorization sequence, including the OECB confirming the registration by way of an LST or an external LDAP server.

This diagram shows the overall authentication and authorization sequence, including the ECB confirming the registration by way of an LST or an external LDAP server.

Authentication

To authenticate the registering user, the Oracle Enterprise Communications Broker needs the hash of the end station's password. It requests these from the local LST of an LDAP server by sending it an LDAP query for the configured field.

The hash consists of an MD5 hash made up of the following components: 

MD5(username:digest-realm:password)

The transaction is conducted with the server defined in the Registrar configuration's credential retrieval method parameter. This parameter is populated with the name of the LDAP sever.

SIP Authentication Challenge

When the Oracle Enterprise Communications Broker receives a response from the HSS including the hash value for the user, it sends a SIP authentication challenge to the endpoint, if the endpoint did not provide any authentication headers in its initial contact the with Oracle Enterprise Communications Broker. If the endpoint is registering, the Oracle Enterprise Communications Broker replies with a 401 Unauthorized message with the following WWW-Authenticate header: 

WWW-Authenticate: Digest realm="atlanta.com", domain="sip:boxesbybob.com", qop="auth", nonce="f84f1cec41e6cbe5aea9c8e88d359", opaque="", stale=FALSE, algorithm=MD5

Authentication Header Elements

  • Domain—A quoted, space-separated list of URIs that defines the protection space. This is an optional parameter for the "WWW-Authenticate" header.
  • Nonce—A unique string generated each time a 401/407 response is sent.
  • Qop—A mandatory parameter that is populated with a value of "auth" indicating authentication.
  • Opaque—A string of data, specified by the Oracle Enterprise Communications Broker which should be returned by the client unchanged in the Authorization header of subsequent requests with URIs in the same protection space.
  • Stale—A flag indicating that the previous request from the client was rejected because the nonce value was stale. This is set to true by the SD when it receives an invalid nonce but a valid digest for that nonce.
  • Algorithm—The Oracle Enterprise Communications Broker always sends a value of "MD5"

SIP Authentication Response

After receiving the 401/407 message from the Oracle Enterprise Communications Broker, the UA resubmits its original request with an Authorization: header including its own internally generated MD5 hash.

Authentication Check

At this point, the Oracle Enterprise Communications Broker has received an MD5 hash from the HSS and an MD5 hash from the UA. The Oracle Enterprise Communications Broker compares the two values and if they are identical, the endpoint is successfully authenticated. Failure to match the two hash values results in a 403 or 503 sent to the authenticating endpoint.