SIP User Authentication

There are two forms of authentication in SIP – authentication of a user agent (UA) by a proxy, redirect, or registration server and authentication of one UA by another. With Transport Layer Security (TLS), mutual authentication of proxies or a proxy and UA is accomplished using certificates. Authentication is used to allow only authorized access to a service or feature and prevent malicious or unauthorized use by other applications.

Digest Authentication

Digest authentication is a simple challenge/response method based on HTTP. For RFC 2069, it employs a MD5 hash algorithm to encode the username, realm, password, digest URI, and server generated nonce as follows:

H1 = MD5(username : realm : password)
H2 = MD5(method : digestURI)
Response = MD5(H1 : nonce : H2)

RFC 2617 added a client generated nonce and quality of protection (QoP) to improve security as follows:

Response = MD5(H1 : nonce : nonceCount : nonceClient : QoP : H2)

SIP Proxy and User Authentication

As depicted in the figure, the message flow for both proxy and user agent authentication is illustrated. The initial INVITE is challenged with a 407 Proxy authorization required. The UA responds with an ACK and then reissues the INVITE containing the authentication credentials. The next proxy server or end UA responds with a 401 Unauthorized message back to the source UA to again reissue the INVITE with the proper authentication credentials and complete the authentication process.

说明：

sip的认证算法真的是采用的这个算法：

H1 = MD5(username : realm : password)
H2 = MD5(method : digestURI)
Response = MD5(H1 : nonce : H2)

其中，

realm 为事先就确定好的，realm及nonce 为服务器在告诉UA需要认证时给UA的;

method 为服务器给UA一些Digest算法选项，然后由UA选一种。

digestURI 为UA需要到达的目的地；示例如下（这是设备192.168.23.113上的2004拨打2007的invite信令）：

Via: SIP/2.0/UDP 192.168.23.113:5060;branch=z9hG4bK.rxkOqoU6K;rport
From: "sabresd" <sip:2004@192.168.23.100>;tag=i-ljgBYGN
To: sip:2007@192.168.23.100
CSeq: 21 INVITE
Call-ID: c2kQFPZtPJ
Max-Forwards: 70
Supported: replaces, outbound
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, UPDATE
Content-Type: application/sdp
Content-Length: 615
Contact: <sip:2004@192.168.23.113;transport=udp>;+sip.instance="<urn:uuid:b13bc5f4-aefc-412f-b586-7a409b46e058>"
User-Agent: LinphoneAndroid/3100 (belle-sip/1.5.0)
Authorization:  Digest realm="asterisk", nonce="1007a06b", algorithm=MD5, username="2004",  uri="sip:2007@192.168.23.100", response="45316d80ffca2b4094333af2631d0c9f"

v=0
o=2004 590 2383 IN IP4 192.168.23.113
s=Talk
c=IN IP4 192.168.23.113
b=AS:512
t=0 0
a=rtcp-xr:rcvr-rtt=all:10000 stat-summary=loss,dup,jitt,TTL voip-metrics
m=audio 7076 RTP/AVP 96 97 98 99 0 8 101 100 102
a=rtpmap:96 opus/48000/2
a=fmtp:96 useinbandfec=1
a=rtpmap:97 SILK/16000
a=rtpmap:98 speex/16000
a=fmtp:98 vbr=on
a=rtpmap:99 speex/8000
a=fmtp:99 vbr=on
a=rtpmap:101 telephone-event/48000
a=rtpmap:100 telephone-event/16000
a=rtpmap:102 telephone-event/8000
m=video 9078 RTP/AVP 96
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42801F
a=rtcp-fb:96 nack pli
a=rtcp-fb:96 ccm fir

从上可以看出，此处的invite信令是要邀请sip:2007@192.168.23.100，因此digestURI即为"sip:2007@192.168.23.100"。

其中，Via的结构是 sip协议/sip版本/UDP，Via里的 192.168.23.113:5060 表示此信息从哪里发送的，此信息的responce应该带上此信息，服务器回复此信息的时候其Via里也需要带其收到的该信息，不需要改动，由此来表明此信息的目的地，因此非目的地设备收到此信息时可以忽略该信息。