Login
Wiki HomeSIP provides a stateless, challenge-based mechanism for authentication that is based on authentication in HTTP. Any time that a proxy server or UA receives a request (with the exceptions given in Section 22.1), it MAY challenge the initiator of the request to provide assurance of its identity. Once the originator has been identified, the recipient of the request SHOULD ascertain whether or not this user is authorized to make the request in question. No authorization systems are recommended or discussed in this document.
The “Digest” authentication mechanism described in this section provides message authentication and replay protection only, without message integrity or confidentiality. Protective measures above and beyond those provided by Digest need to be taken to prevent active attackers from modifying SIP requests and responses.
Note that due to its weak security, the usage of “Basic” authentication has been deprecated. Servers MUST NOT accept credentials using the “Basic” authorization scheme, and servers also MUST NOT challenge with “Basic”. This is a change from RFC 2543.
What is a realm?
Generally, SIP authentication is meaningful for a specific realm, a protection domain. Thus, for Digest authentication, each such protection domain has its own set of usernames and passwords.
Quote from RFC2617:
REALM:
A string to be displayed to users so they know which username and password to use. This string should contain at least the name of the host performing the authentication and might additionally indicate the collection of users who might have access. An example might be "registered_users@gotham.news.com".
WWW or proxy-auth?
- When authenticating to the server that will deliver a service, a www-authentication header should be used.
- When authenticating to a server that will proxy the request to the endpoint, proxy-authentication should be used.
- In _one_ transaction, both www_authentication and proxy_authentication can be used
Failure to authenticate - 401 or 407?
If the origin server does not wish to accept the credentials sent with a request, it SHOULD return a 401 (Unauthorized) response. The response MUST include a WWW-Authenticate header field containing at least one (possibly new) challenge applicable to the requested resource. If a proxy does not accept the credentials sent with a request, it SHOULD return a 407 (Proxy Authentication Required). The response MUST include a Proxy-Authenticate header field containing a (possibly new) challenge applicable to the proxy for the requested resource.Authentication for ACK and CANCEL
Under an authentication scheme that uses responses to carry values used to compute nonces (such as Digest), some problems come up for any requests that take no response, including ACK. For this reason, any credentials in the INVITE that were accepted by a server MUST be accepted by that server for the ACK.
UACs creating an ACK message will duplicate all of the Authorization and Proxy-Authorization header field values that appeared in the INVITE to which the ACK corresponds. Servers MUST NOT attempt to challenge an ACK.
Although the CANCEL method does take a response (a 2xx), servers MUST NOT attempt to challenge CANCEL requests since these requests cannot be resubmitted. Generally, a CANCEL request SHOULD be accepted by a server if it comes from the same hop that sent the request being canceled (provided that some sort of transport or network layer security association, as described in Section 26.2.1, is in place).
So, to summarize:
- SIP Authentication is done with an authentication username and authentication realm.
- The server challenges the user with a realm and a "nonce"
- If the user has a username within this realm, it calculates a response based on a number of data, including a "secret"
- The authentication username doesn't have to be the same as the SIP user name
- The authentication realm doesn't have to be the same as the SIP domain
- Many SIP user agents have broken implementations where you can't set authentication username and realm
- The best solution would be for a user agent to have one setting for SIP username and domain, and then a set of settings for authentication to various realms. ''How do I authententicate within this realm?".
- Today many clients are bound to have the same username/password for all realms, which is not a very good way of handling security.
Comments
Page Changes