Understanding SIP Authentication

SIP as both a protocol and an architecture has a number of places where security can be applied. You can secure SIP signaling with Transport Layer Security (TLS). This encrypts the metadata of a call – e.g. who called who. You can secure the media of a session with SRTP – audio, video, etc. Session Border Controllers are deployed to secure an enterprise’s network edge. SBCs act as SIP firewalls that allow the good guys to send and receive SIP messages while keeping the bad guys out.

As important as these three security techniques are, there is still one more aspect that must be addressed. How do you guarantee that the sender of a SIP message is who he or she claims to be? For instance, it’s easy to create an INVITE message that says “I am Andrew Prokop,” but how can the recipient be sure that it really came from Andrew Prokop?

This is where SIP authentication comes in. With SIP authentication, any SIP message can be challenged. This means that anyone receiving an INVITE message can force the sender to prove his or her identity before the message is processed.

I singled out INVITE, but SIP authentication is not limited to a single message type. Any SIP method (the proper name for a SIP message) can and should be challenged by the recipient. In fact, an Avaya system challenges every single SIP message every time one is sent.

So, how does all this work? The basic call flow is really quite simple.

  • A User Agent Client (UAC) sends a SIP message to a User Agent Server (UAS)
  • The UAS responds back with a 4xx challenge response
  • A UAC uses data in the 4xx challenge response to encrypt his or her identity credentials (e.g. telephone password)
  • The UAC resends the SIP message with the encrypted credentials

This four-step process ensures that only authenticated messages are sent to SIP applications for processing. Messages that don’t pass authentication are discarded.

There are two different forms of the 4xx challenge response and although they essentially perform the same task, they are sent from different entity types in response to different SIP messages. These responses are:

401 Unauthorized

407 Proxy Authentication Required

Let’s start with 407. I sat down at my PC, cranked up the Avaya traceSM utility, and took my telephone off-hook. If you read my previous article, Avaya Aura IMS Processing Once Again, you will know that off-hook is indicated by sending an INVITE. Here is the entire call flow:


Take a look at the first six messages and you will see authentication in action. In this case, my telephone is the UAC and Session Manager is acting as the UAS.

To kick things off, my telephone sends the following INVITE.


Upon receiving the INVITE, Session Manager responds with a 407 Proxy Authentication Required response.


As you may already know, SIP borrowed heavily from other Internet protocols and the Proxy-Authenticate header was lifted straight from HTTP.  This header contains the data that must be used by UAC to encrypt his or her credentials. In this case, the telephone will encrypt the user’s telephone password.

If you insist on learning more about Proxy-Authenticate, please see RFC 2617.

Take a look at the Proxy-Authenticate header and you will see a Nonce parameter. Nonce stands for Number Once and is an arbitrary number used only once in a cryptographic communication. The recipient of a Nonce will use it to encrypt his or her credentials. Number once refers to the fact that encryption with this Nonce can only be done one time. If someone were to sniff the LAN and obtain someone’s encrypted password, it wouldn’t do them any good because it can only be used in a single transaction. It becomes stale and useless immediately after its first use.

This particular header instructs the client to encrypt the user’s telephone password with MD5 and the given Nonce.

After the password has been encrypted, the UAC creates a new INVITE (not a re-INVITE) and places that encrypted password into the response parameter of a Proxy-Authentication header.

Here is the new INVITE as sent by my telephone. Notice how Proxy-Authentication repeats much of what was in Proxy-Authenticate.


A Slight Shift of Gears

I mentioned that there are two 4xx challenge responses. RFC 2617 states the following about the two headers:

The 401 (Unauthorized) response message is used by an origin server to challenge the authorization of a user agent. This response MUST include a WWW-Authenticate header field containing at least one challenge applicable to the requested resource. The 407 (Proxy Authentication Required) response message is used by a proxy to challenge the authorization of a client and MUST include a Proxy-Authenticate header field containing at least one challenge applicable to the proxy for the requested resource.

Generally, I see 407 responses for messages sent to SIP clients and 401 responses for messages sent to SIP servers. That means that messages like INVITE and BYE will receive 407 responses and REGISTER and SUBSCRIBE will receive 401 responses.

I captured the boot cycle of my phone to see the REGISTER and SUBSCRIBE messages it sends.


Here is a REGISTER message followed by a 401 response. Notice how the headers are different from a 407, but the end result is a challenge that solicits my telephone’s encrypted password.



Mischief Managed

At this point, I think I have said enough about SIP authentication. As you can see, it adds a layer of security that is not provided by either TLS or SRTP.



  1. Redone · · Reply

    Hey i have hosted 3xc sip sirver in localhost( now i have a user with username:401, password:1234. To avoid 407 error what will be the Proxy-Authentication parameters can you give some example please. Also my mobile ip is Thanks in advance

    1. You might try switching to TLS. That turns off authentication in some servers. Of course, you will need to install the correct certificates.

  2. How about the IK and CK keys in 401 response? In our lab we use these parameter to decode the encrypted packets.We never take into account the nonce parameter.

    1. You may use those but the example which andrew gave was for example and it was from Avaya Session Manager.

  3. Hey, what happens if a BYE is challenge by a 407? will the 407 be followed by a ACK? Thanks! Luis

    1. Nope. ACK is only used for session initiation. It’s never used for BYE.

  4. What is the use of Sending Auth header in Sip invite message

    1. INVITE messages can be challenged. If so, the sender needs to prove it is who it says it is.

  5. Why Ack and Cancel cannot be challenged?Only reason that both have authentication information similar to Invite and it was cached by Proxy??

  6. Thanks Andrew.. 🙂

  7. Hi Andrew, thanks for this blog. It is very useful. I have a question regarding secure SIP with TLS and SIP re-INVITE. I am wondering if SIP re-INVITE will work if a client reconnect after it lost the underlying connection. The scenario I am imagining is, if the client lost the physical connection, eg. move from a WiFi environment to a 4G connection, its IP can change and need to reestablish the TLS connection again. In this case, will the SIP client being able to reestablish the original SIP session by a re-INVITE? or will it because of a totally new TLS connection, so it is not possible? Thanks

  8. Surya Teja · · Reply

    Hi Andrew,

    Could you please explain in detail about parameters like realm, QOP, stale e.t.c


  9. Surya Teja · · Reply

    Hi Andrew,

    Can you explain in detail about stale, QOP. Cnonce, QOP, realm

  10. Bhavna Bathla · · Reply

    Hi Andrew,
    Upon receiving 407 to the first INVITE, does the subsequent request with credentials has empty to-tag or to-tag is taken from the 407 response ?


    1. It’s a brand new to-tag.

  11. Deeps Rawat · · Reply

    Hi Andrew,
    Upon capturing traceSBC, i see that Service Provider responds with 401 and SBC sends INVITE with ‘Authorization’ Header containing Challenge and response. Now Service Provider again responds with 401, and this time SBC adds one more Authorization header (thus containing 2 Authorization header) in the INVITE. And now finally SP kills the call with ‘400’ error (Malformed packets). How to resolve such issues.

    1. I would try and figure out why the SBC is getting the second 401.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: