
正文
sip user Authentication and 401
提示:扫一扫查出行【扫一扫了解最新限行尾号】
复制提示
https://www.vocal.com/sip-2/sip-user-authentication/
https://tools.ietf.org/html/rfc3261
SIP User AuthenticationThere 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.
- SIP and WebRTC
- Voip Design
- VoIP Software
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.
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.
- SIP and WebRTC
- Voip Design
- VoIP Software
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里也需要带其收到的该信息,不需要改动,由此来表明此信息的目的地,因此非目的地设备收到此信息时可以忽略该信息。





