SIP Authentication, 407, Proxy Authentication Required
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.
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
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
407, Proxy
Authentication Required.
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.
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.
Following is an example for this process.
Step 1 : REGISTER --------------------------------
REGISTER sip:test.3gpp.com
SIP/2.0
f:
<sip:+11234567890@test.3gpp.com>;tag=2722997041
t:
<sip:+11234567890@test.3gpp.com>
CSeq: 575513373 REGISTER
i:
2722997021_2363003016@2001::21f:29ff:fe7c:8f51
v: SIP/2.0/UDP
[2001::21f:29ff:fe7c:8f51]:5060;branch=z9hG4bK656994275
Max-Forwards: 70
m:
<sip:+11234567890@[2001::21f:29ff:fe7c:8f51]:5060>
P-Access-Network-Info:
3GPP-E-UTRAN-FDD; utran-cell-id-3gpp=3114800102FFFFFFF
l: 0
Authorization: Digest
uri="sip:test.3gpp.com",
username="001010123456789@test.3gpp.com",
response="",
realm="test.3gpp.com",
nonce=""
Expires:
7200
Note 1 : Make it sure the
'realm' parameter matches Authentication server domain name. If this does not
matches the authentication server, CSCF may send 'Error Code'.
Step 2 : 401 UNAUTHORIZED --------------------------------
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP
[2001::21f:29ff:fe7c:8f51]:5060;branch=z9hG4bK656994275
From:
<sip:+11234567890@test.3gpp.com>;tag=2722997041
To:
<sip:+11234567890@test.3gpp.com>;tag=T3E04A4B5
Call-ID:
2722997021_2363003016@2001::21f:29ff:fe7c:8f51
CSeq: 575513373 REGISTER
Content-Length: 0
WWW-Authenticate:
Digest realm="test.3gpp.com",
nonce="qlWqVapVqlWqVapVqlWqVUUQA5HEt9VVZ3t1TM221cg=",
qop="auth",
opaque="MTcyMjU3ODA2NDo=SU1TLVNJUCBTZXJ2ZXI=",
algorithm=AKAv1-MD5
P-Associated-URI:
<sip:+11234567890@TEST.3GPP.COM>
P-Associated-URI:
<tel:+11234567890>
Note 1 : 'realm'
parameter in this message should match the 'realm' parameter in Step 1.
Otherwise, UE may not proceed to next step.
Note 2 : 'algorithm'
specified here should be the one supported by UE. Otherwise, UE may not proceed
to next step.
Step 3 : REGISTER -----------------------------------
REGISTER sip:test.3gpp.com
SIP/2.0
f:
<sip:+11234567890@test.3gpp.com>;tag=2722997284
t:
<sip:+11234567890@test.3gpp.com>
CSeq: 575513374 REGISTER
i:
2722997021_2363003016@2001::21f:29ff:fe7c:8f51
v: SIP/2.0/UDP
[2001::21f:29ff:fe7c:8f51]:5060;branch=z9hG4bK843051065
Max-Forwards: 70
m:
<sip:+11234567890@[2001::21f:29ff:fe7c:8f51]:5060>
P-Access-Network-Info:
3GPP-E-UTRAN-FDD; utran-cell-id-3gpp=3114800102FFFFFFF
l: 0
Authorization: Digest
username="001010123456789@test.3gpp.com",
realm="test.3gpp.com",
uri="sip:test.3gpp.com",
qop=auth,
nonce="qlWqVapVqlWqVapVqlWqVUUQA5HEt9VVZ3t1TM221cg=",
nc=00000001,
cnonce="11259375",
algorithm=AKAv1-MD5,
response="a3f549b13f477562f4445b7277cd83c1",
opaque="MTcyMjU3ODA2NDo=SU1TLVNJUCBTZXJ2ZXI="
Expires: 7200
Note 1 : 'realm'
parameter in this message should match the 'realm' parameter in Step 2.
Note 2 : 'algorithm'
parameter in this message should match the 'algorithm' parameter in Step 2.
Note 3 : 'Expires : 7200'
means that the registration should be 'renewed' within 7200 seconds.
Step 4 : 200 OK -----------------------------------
SIP/2.0 200 OK
Via: SIP/2.0/UDP
[2001::21f:29ff:fe7c:8f51]:5060;branch=z9hG4bK843051065
From:
<sip:+11234567890@test.3gpp.com>;tag=2722997284
To:
<sip:+11234567890@test.3gpp.com>;tag=T44F6AE74
Call-ID:
2722997021_2363003016@2001::21f:29ff:fe7c:8f51
CSeq: 575513374 REGISTER
Contact:
<sip:+11234567890@[2001::21f:29ff:fe7c:8f51]:5060>;q=0.500;expires = 7200
Content-Length: 0
Date: Mon, 22 Apr 2013
15:43:15 GMT
Authentication-Info:
qop=auth,
rspauth="a3f549b13f477562f4445b7277cd83c1",
cnonce="11259375",
nc=00000001
P-Associated-URI:
<sip:+11234567890@TEST.3GPP.COM>
P-Associated-URI:
<tel:+11234567890>
P-Associated-URI:
<sip:+11234567890@TEST.3GPP.COM>
P-Associated-URI:
<tel:+11234567890>
