Professional Documents
Culture Documents
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)
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
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.
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.
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.
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.