The documentation set for this product strives to use bias-free language. For the purposes of this documentation set, bias-free is defined as language that does not imply discrimination based on age, disability, gender, racial identity, ethnic identity, sexual orientation, socioeconomic status, and intersectionality. Exceptions may be present in the documentation due to language that is hardcoded in the user interfaces of the product software, language used based on RFP documentation, or language that is used by a referenced third-party product. Learn more about how Cisco is using Inclusive Language.
Cisco Unified Border Element (SP Edition) supports Session Initiation Protocol (SIP) authentication.
Note For Cisco IOS XE Release 2.4, this feature is supported in the unified model only.
Cisco Unified Border Element (SP Edition) was formerly known as Integrated Session Border Controller and may be commonly referred to in this document as the session border controller (SBC).
For a complete description of the commands used in this chapter, refer to the Cisco Unified Border Element (SP Edition) Command Reference: Unified Model at:
http://www.cisco.com/en/US/docs/ios/sbc/command/reference/sbcu_book.html.
For information about all Cisco IOS commands, use the Command Lookup Tool at http://tools.cisco.com/Support/CLILookup or a Cisco IOS master commands list.
Feature History for SIP Authentication
When network entities communicate using SIP, one entity often needs to challenge another one to determine if it is authorized to transmit SIP signaling into the challenger’s network. The SIP authentication model is based on the HTTP digest authentication, as described in the RFC 2617.
The use of basic authentication, where passwords are transmitted unencrypted, is not permitted in SIP.
This section contains the following subsections:
The following prerequisites are required to implement SIP outbound authentication:
Note Multiple realms can be configured per adjacency and there is no limit on the number of these realms aside from memory availability. Different realms may be configured with the same username and password. Also, each realm may be configured with different username and password on different adjacencies. However, any realm can be configured a maximum of one time per adjacency.
The following restrictions apply to SIP outbound authentication:
Note The current command line interface (CLI) prohibits the user from configuring two authentication-realms with the same domain for the same adjacency. If this is attempted, the CLI interprets the second authentication-realm configuration as an attempt to reconfigure the first authentication-realm, and updates the user’s credentials accordingly.
When a SIP adjacency is configured, the user may specify one or more authentication-realms. Each authentication-realm represents a remote domain, from which Cisco Unified Border Element (SP Edition) receives authentication challenges on the adjacency. When an authentication-realm is configured, the user must specify the correct user name and password that Cisco Unified Border Element (SP Edition) uses to authenticate itself in that realm. Cisco Unified Border Element (SP Edition) stores all valid authentication-realms for each adjacency.
Upon receipt of a SIP 401 or 407 response that can be correlated to a request it sent, Cisco Unified Border Element (SP Edition) examines the attached authentication challenge. Cisco Unified Border Element (SP Edition) responds to any authentication challenge received on a given adjacency that matches one of the configured authentication-realms for that adjacency. Any authentication challenge that does not match the configured authentication-realm is passed through unchanged to the SBC’s signaling peer for the adjacency, on which the original request was received.
To generate a response to an authentication challenge, Cisco Unified Border Element (SP Edition) does the following:
1. First, it looks up the realm parameter of the challenge in its list of configured authentication-realms for the outbound adjacency.
2. Second, it finds the password for that authentication-realm and generates an authentication response by combining the password with the nonce parameter from the challenge, and hashing the result.
3. If the challenger has requested auth-int quality of protection, Cisco Unified Border Element (SP Edition) also generates a hash of the entire message body and includes it in the response.
4. Cisco Unified Border Element (SP Edition) builds an Authorization (or Proxy-Authorization) header by including the following parameter values (following RFC 2617):
5. Finally, Cisco Unified Border Element (SP Edition) stores its calculated response and the received nonce with the other data for the authentication-realm. This allows Cisco Unified Border Element (SP Edition) to respond rapidly to the subsequent challenges from this realm with the same nonce. If Cisco Unified Border Element (SP Edition) lacks the resources to store its response, it carries on anyway. The next time an authorization challenge is received from this realm, Cisco Unified Border Element (SP Edition) has to recalculate its response. When Cisco Unified Border Element (SP Edition) re-uses a saved response, it updates the nonce count stored along with the nonce-response pair. This allows Cisco Unified Border Element (SP Edition) to correctly fill in the nonce-count field in Authorization responses.
This section contains the steps for configuring SIP outbound authentication, allowing the user to add/remove one or more authentication-realms to/from an adjacency.
4. adjacency sip adjacency-name
5. authentication-realm inbound domain | outbound domain username password
7. show sbc sbc-name sbe adjacency adjacency-name authentication-realms
Cisco Unified Border Element (SP Edition) supports two modes of Session Initiation Protocol (SIP) inbound authentication to challenge inbound SIP requests: local and remote. You must select the mode of authentication to configure Cisco Unified Border Element (SP Edition) according to the level of support present in the Remote Authentication Dial-In User Service (RADIUS) servers. If the RADIUS servers are compliant with only draft-sterman-aaa-sip-00 to 01, then select the local mode. If the RADIUS servers are compliant with only RFC 4590, then use the remote authentication mode.
Note This feature is optional and you can configure the Cisco Unified Border Element (SP Edition) not to challenge the inbound requests.
This section contains the following subsections:
The following prerequisites are required to implement SIP inbound authentication:
The following restrictions and limitations apply to implement SIP inbound authentication:
When configured to perform local inbound authentication, Cisco Unified Border Element (SP Edition) is responsible for challenging an unauthorized request from the remote peer first. Therefore, to be able to challenge the request from the remote peer, the adjacency must already be configured with an authentication realm. After the remote peer has validated the request, it is forwarded to the RADIUS server, which then decides whether to permit the call to pass through or not.
When configured to perform remote inbound authentication, Cisco Unified Border Element (SP Edition) relies on the RADIUS server to challenge an authorized request from the remote peer. Cisco Unified Border Element (SP Edition) forwards the challenge request generated by the RADIUS server to the remote peer, and also forwards the remote peer’s authentication request to the RADIUS server.
If an adjacency is configured for inbound authentication, then after it successfully authenticates an inbound request, the authorization headers matching the realm for that adjacency are stripped out and not propagated to the outbound signal. Authorization headers for other realms, however, are passed through to the outbound request.
When the inbound authentication is configured, the following failure modes may occur (in addition to the standard SIP signal failure modes):
If the endpoint or RADIUS server specifies a quality of protection parameter other than auth or auth-int, then the inbound request is rejected and a 403 response is generated. Similarly, Cisco Unified Border Element (SP Edition) generates a 403 response when algorithms other than MD5 and MD5-sess are used.
If the RADIUS server rejects the Access-Request signal with an Access-Reject response, Cisco Unified Border Element (SP Edition) sends a 403 response to the endpoint.
If Cisco Unified Border Element (SP Edition) does not have sufficient memory to process an inbound authentication request, it rejects the request and sends a 503 response.
If the peer does not return any authentication headers that specify the authentication realm contained in the adjacency’s configuration, then Cisco Unified Border Element (SP Edition) rechallenges the request with 401 response.
If the peer’s nonce does not match the one generated by Cisco Unified Border Element (SP Edition), then Cisco Unified Border Element (SP Edition) rejects the authentication request and sends a 403 response.
If the peer’s nonce has timed out, then Cisco Unified Border Element (SP Edition) challenges the nonce by sending a 401 response and a new nonce.
If there is no RADIUS server to support a mode configured on the adjacency, then Cisco Unified Border Element (SP Edition) rejects the authentication request with a 501 response and creates a log to alert the user of the inconsistent configuration.
This section contains the steps for configuring SIP local inbound authentication a RADIUS server.
4. radius [accounting client-name | authentication]
12. adjacency sip adjacency-name
13. authentication-realm inbound realm
Cisco Unified Border Element (SP Edition) supports interoperability between SIP devices and third-party soft switch equipments for SIP authentication of all SIP requests. The supported interoperability applies to dialog-creating INVITE requests and out-of-dialog REGISTER and SUBSCRIBE requests only.
Support for interoperability for SIP authentication of INVITE requests was introduced in Cisco IOS XE Release 2.5. Cisco Unified Border Element (SP Edition) uses a generation scheme that generates the Call-ID, From and To dialog tags, and CSeq sequence numbers on the outbound call leg using the inbound request message data which provides both uniqueness and retains the same values for subsequent requests resulting from any challenges.
Support for interoperability for SIP authentication of out-of-dialog requests was introduced in Cisco IOS XE Release 2.6. The same generation scheme used by INVITE requests (based on the inbound request message data) was implemented for out-of-dialog requests.
Cisco Unified Border Element (SP Edition) interoperates with third-party soft switch devices for processing SIP authentication of INVITE and out-of-dialog requests in the following way:
This section contains the following subsections:
The following restrictions apply to support for Interoperability for SIP Authentication on the Cisco Unified Border Element (SP Edition):
– The Call-ID of an authorized SIP request matches that of the initial request.
– The To and From headers of an authorized SIP request match those of the initial request, including the dialog tag (if any) in the From header.
– The CSeq sequence number of an authorized SIP request is one higher than the initial request.
– The local-id or signaling-address configuration under adjacency affects Call-ID and From-tag generation.
– Header rewriting configuration can apply to From and To headers. To meet the interoperability requirements, this rewriting must produce identical results on successive requests.
– Cisco Unified Border Element (SP Edition) does not issue warnings to the user before accepting such configuration changes.
This section provides information about interoperability for SIP authentication.
SIP requests refer to the messages within the scope of a single challenge or response sequence. There can be several sequences before a request is accepted, but the first sequence of any pair of consecutive requests is referred to as the initial request and the second one is referred to as the authorized request.
SIP requests are both dialog-creating INVITE requests and out-of-dialog requests.
The following SIP request terms are used in this chapter:
Initial request—A SIP request with insufficient authentication credentials, which is challenged with a “401–Unauthorized” or a “407–Proxy Authentication Required” response.
Authorized request—The corresponding subsequent request, sent on receipt of the 401/407 challenge response. This request contains an extra Authorization or Proxy-Authorization header.
Cisco Unified Border Element (SP Edition) generates Call-ID values for outbound dialog-creating INVITE requests and out-of-dialogue requests (such as REGISTERS and SUBSCRIBES), based on the Call-ID of the inbound request and on configuration.
The generated Call-ID values are composed of a 32-character hexadecimal MD5 hash of the received Call-ID, an ‘@’ character, and a local-id string representing the SBC itself.
Note The local-id string is the configuration from the outbound adjacency. If this configuration is absent, the canonical text representation of the signaling-address from the outbound adjacency is used.
Cisco Unified Border Element (SP Edition) generates From header dialog tag values for outbound dialog-creating INVITE requests and out-of-dialogue requests (such as REGISTERS and SUBSCRIBES), based on the From tag of the inbound request and on configuration.
The generated From tag values are composed of a local-id string representing the SBC itself, two eight-character hexadecimal MD5 hashes of the received From tag, and a numerical index identifying the internal component responsible for the dialog.
From: "Fred" <sip:2222222@sbc.home.net>;tag=sbc.home.net+1+a27d9765+b7f0f7e1
The local-id string is generated from configuration in the same way as for Call-IDs.
Cisco Unified Border Element (SP Edition) chooses the sequence number for use in the CSeq header of an outbound dialog-creating INVITE request and out-of-dialogue requests (such as REGISTERS and SUBSCRIBES) to be the same as the sequence number on the received inbound request.
Cisco Unified Border Element (SP Edition) continues to choose sequence numbers for subsequent outbound requests on the same dialog by storing the dialog’s current sequence number, and incrementing it each time a new transaction is created.
SBC supports passing through authentication challenges and their responses. No configuration is required for this.