SIP Authentication Procedure - Part I

SIP provides a stateless, challenge based mechanism for authentication that is based on authentication in HTTP. Any time that a proxy server or UA receive a request, it may challenge the originator to provide assurance of its identity. 

The framework for SIP authentication closely parallels the HTTP (RFC 2617) In particular, the BNF form for auth-scheme, auth-param, challenge, realm, realm-value, and credential is identical  (although the use of “Basic” as a scheme is not permitted) . In SIP, a UAS uses the 401 response to challenge the identify of a UAC. Additionally, registrars and redirect servers may make use of 401. The proxies must make use of 407 response code for the same. The requirements for inclusion of Proxy-Authenticate, Proxy-Authorisation, WWW-Authenticate, and Authorization in various messages are identical to those described in RFC 2617. 

Below are the rules for creating realm string for the operators of user agents or proxy servers. 

1. Realm string must be globally unique. It is recommended to have hostname or domain name. 

2. Realm string should present a human- readable identifier that can be rendered to a user. 

For e.g. 

INVITE sip: bob@biloxi.com SIP/2.0 

Authorisation : Digest realm=“biloxi.com”, <…>

generally SIP authentication is meaningful for a specific realm, a protection domain. Thus for a digest authentication, each such protection domain has its own username and password. If a server does not require authentication or password if may accept a default user name “anonymous”, which has no password (password of “”). Similarly UAC representing many users such as PSTN gateways may have their own device specific user name and password, rather than accounts for a particular users, for their realm. 

ACK and CANCEL are special request that does require special handling. 

UAC creating an ACK message will duplicate all of the authorisation and Proxy-Authorization header field value that appeared in the INVITE to which the ACK corresponds. Servers must not attempt to challenge ACK. 

When UAC receives a challenge, it SHOULD render it to the user the contents of the “realm” parameter in the challenge which appears either in the WWW-Authenticate or Proxy-Authenticate header header field. This is needed if the UAC does not already know the credential for the realm. 

References:

https://www.ietf.org/rfc/rfc3261.txt Section 22