---

---

SIP 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

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.

---

Posted by sagitraz

A User Agent presents credentials to the Proxy Server. The Proxy Server may turn to a third party to verify that the User Agent is who they say they are. This often uses the method of Certificates of Authentication common on the World Wide Web.
• Requires the User Agent and verifier to have a shared secret
• Keys are regenerated on time and address so to prevent third parties from attacking with cached credentials
• SIP signals a requirement for TLS by responding to an invite with 401 Authentication Required or 407 Proxy Authorization Required

---

Posted by yogendra