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:;branch=z9hG4bK.rxkOqoU6K;rport

From: "sabresd" <sip:@192.168.23.100>;tag=i-ljgBYGN

To: sip:@192.168.23.100

CSeq:  INVITE

Call-ID: c2kQFPZtPJ

Max-Forwards:

Supported: replaces, outbound

Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO, UPDATE

Content-Type: application/sdp

Content-Length:

Contact: <sip:@192.168.23.113;transport=udp>;+sip.instance="<urn:uuid:b13bc5f4-aefc-412f-b586-7a409b46e058>"

User-Agent: LinphoneAndroid/ (belle-sip/1.5.)

Authorization:  Digest realm="asterisk", nonce="1007a06b", algorithm=MD5, username="",  uri="sip:2007@192.168.23.100", response="45316d80ffca2b4094333af2631d0c9f"

v=

o=   IN IP4 192.168.23.113

s=Talk

c=IN IP4 192.168.23.113

b=AS:

t=

a=rtcp-xr:rcvr-rtt=all: stat-summary=loss,dup,jitt,TTL voip-metrics

m=audio  RTP/AVP

a=rtpmap: opus//

a=fmtp: useinbandfec=

a=rtpmap: SILK/

a=rtpmap: speex/

a=fmtp: vbr=on

a=rtpmap: speex/

a=fmtp: vbr=on

a=rtpmap: telephone-event/

a=rtpmap: telephone-event/

a=rtpmap: telephone-event/

m=video  RTP/AVP

a=rtpmap: H264/

a=fmtp: profile-level-id=42801F

a=rtcp-fb: nack pli

a=rtcp-fb: 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里也需要带其收到的该信息，不需要改动，由此来表明此信息的目的地，因此非目的地设备收到此信息时可以忽略该信息。