Copy from:
http://blog.sina.com.cn/s/blog_4b839a1b01000bqq.html
理解SIP的认证
1. 认证和加密
认证(Authorization)的作用在于表明自己是谁,即向别人证明自己是谁。而相关的概念是MD5,用于认证安全。注意MD5仅仅是个hash函数而已,并不是用于加密。因为hash函数处理后的数据没法进行反向恢复,这样子的话别人没法盗取你认证身份的口令。
加密(Encryption)的作用在于对想传输的数据进行处理,在网络中即使被窃取也难以破解。加密的信息可以被破解,这需要一把钥匙——“密钥”。通过密钥,我们可以对数据进行加密和解密。最有名的专用密钥加密系统就是数据加密标准(DES), 这个标准现在由美国国家安全局和国家标准与技术局来管理。另一个系统是国际数据加密算法(IDEA), 它比DES的加密性好, 而且需要的计算机功能也不怎么强。
2. SIP认证方式
SIP的认证是继承了HTTP的认证方式。根据RFC2617,HTTP的认证方案主要有Basic Authentication Scheme和Digest Access Authentication Scheme两种。而Basic方法使用的口令原文验证的方式,易被盗取,所以SIP已经摒弃这种方式。
Digest认证方案可以对口令进行MD5包装。一般来说,获取口令有两种方式:1.字典攻击,即使用轮询进行口令猜测的方法,如果口令简单比较危险;另一个方法是攻击服务器来获得口令,如果服务器把密码存储起来那样的话就可能被盗取。所以方法是服务器端不再存储密码原文,而是使用MD5包装起来,这样的话当经过MD5包装的认证信息过来后,比较存储的MD5数据则可知道用户的身份了。
3. SIP认证过程
UA之间的认证
![理解SIP的认证 理解SIP的认证](https://i-blog.csdnimg.cn/blog_migrate/7dbd1febf231296331e4673007ecc07d.jpeg)
图1-1 UA之间的认证流程
UA和Proxy之间的认证
![理解SIP的认证 理解SIP的认证](https://i-blog.csdnimg.cn/blog_migrate/cd12ebe825f5edd8db3a1e5a6ce0887f.jpeg)
图1-2 UA和Proxy之间的认证流程
从以上两图看出,首先当UAC给UAS/Proxy发请求时;如果UAS/Proxy需要认证信息,则回复401/407;这时UAC通过回复信息来计算认证消息,然后重新发送 请求;如果认证不通过的话则会继续收到401/407或403,这时UAC必须不能再次使用刚才被拒绝的信任书进行尝试,需要重新生成请求直至UA/Proxy认证通过。注意也可以第一次请求时就已经带有认证信息。
当UAC在接收到401(Unauthorized)或者407(ProxyAuthenticationRequired)应答之后,重新用它的信任书来提交请求,它必须增加Cseq头域的值,就像发送一个正常的新请求一样。
如果认证通过的话,UA应当把这个给特定To头域和”realm”字段的信任书cache起来,以备给这个地址下一个请求时候使用。
我们建议使用下列步骤来cache一个proxy的信任书:如果UA在给特定Call-ID的请求的401/407应答中,接收到一个Proxy-Authenticate头域,它应当合并对这个realm的信任书,并且为以后具有相同Call-ID的请求发送这个信任书。这些信任书必须在对话中被cache住;不过如果UA配置的是它自己的本地外发proxy,那么如果出现要求认证的情况,那么UA应当cache住跨对话的信任书。注意,这个意味着在一个对话中的请求可以包含在Route头域中所经过proxy都不需要的信任书。
当服务器可以正确处理绝大部分SIP请求,有本文档约定了两类请求要求特别的认证处理:ACK和CANCEL。在某一个认证方案下,并且这个认证方案是使用应答来放置计算nonces(比如Digest),那么对于某些没有应答的情况,就会出现问题,比如ACK。所以,基于这个原因,一个服务器接受在INVITE请求中的信任书,也必须同样接收对应ACK的信任书。UAC通过赋值所有的INVITE请求中的Authorization和Proxy-Authorization头域值来创建一个相关的ACK消息。服务器必须接收这个ACK请求。
虽然CANCEL方法具有应答(2xx),服务器必须不能拒绝CANCEL请求,因为这些请求不能被重新提交。通常,如果CANCEL请求和被CANCEL的请求来自同一个节点(假设某种通讯协议,或者网络层有安全关系26.2.1节描述),服务器应当接收CANCEL请求。
可见SIP为认证系统提供了一个无状态的,试错机制,这个认证机制式基于HTTP的认证机制的。通过请求和回复来验证用户身份。
4. 认证消息解析
注:只讲述重要字段,细节查看RFC2617。
具体为401中的WWW-Authenticate应答头域,相对应的为请求的Authorization头域;407中的Proxy-Authenticate头域,相对应的是请求的Proxy-Authorization头域。
a) WWW-Authenticate/Proxy-Authenticate头域
这个头域值包含了至少一个表明认证方式和适用realm的参数的拒绝原因。
如:
WWW-Authenticate: Digest
realm="biloxi.com",
qop="auth,auth-int",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
i. Realm
realm字串单独定义被保护的区域。Realm字串必须是全局唯一的。我们强调这个realm字串必须包含一个主机名或者域名。Realm字串应当是一个可读的能够展示给用户的字串。
通常,SIP认证对于特定realm(一个保护区域)是有意义的。因此,对于Digest认证来说,每一个类似的保护区域都有自己的用户名和密码集合。
ii. Nonce
服务器端指定的数据字符,它应在每个401回应产生时,被唯一地创建。建议该字符以base64方式或16进制方式出现。另外,该字符在标题行中传递时是在引号内的,因此允许使用双引号字符。
iii. Stale
一个标志,用来指示客户端先前的请求因其nonce值过期而被拒绝。如果stale是TRUE(大小写敏感),客户端可能希望用新的加密回应重新进行请求,而不用麻烦用户提供新的用户名和口令。服务器端只有在收到的请求nonce值不合法,而该nonce对应的摘要(digest)是合法的情况下(即客户端知道正确的用户名/口令),才能将stale置成TRUE值。如果stale是FALSE或其它非TRUE值,或者其stale域不存在,说明用户名、口令非法,要求输入新的值。
iv. Algorithm
Algorithm是个字符串,用来指示用来产生摘要及校验和的算法对。如果该域没指定,则认为是“MD5“算法。如果该域指定的算法无法理解,该质询(challenge)将被忽略。
v. qop
“auth”表示鉴别方式;“auth-int”表示鉴别保护的完整性。
vi. opaque
由服务器指定的字符串,客户端不能改动它,如果并发请求的URI也指向同一个受保护区间,则该信息将被加在这些请求的授权标题域中返给服务器。建议采用base64或16进制的字符串。
b) Authorization/Proxy-Authorization头域
该头域包含了具有这个UA到请求的资源所在的realm(区域)的信任书和所需要的认证支持的参数和重现保护的参数。
例子:
Authorization: Digest username="bob",
realm="biloxi.com",
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",
uri="sip:bob@biloxi.com",
qop=auth,
nc=00000001,
cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
如果服务器对特定请求没有要求认证或对于特定realm没有对应的认证信息,那么使用缺省的用户名,”anonymous”,并且这个用户名没有密码(密码是””)。
根据RFC2617,合法的回应包含对用户名、口令、给定nonce值、SIP方法、请求URI的校验和(checksum,缺省是MD5的校验和)。
i. Response
是个字符串,由32个经过计算的16进制数字组成,用来证明用户是否知道口令。
ii. Cnonce
当qop指示发送了,该指示必须要指定,而当服务器端没有在WWW-鉴别(WWW- Authenticate)标题域中添加qop指示时,该指示一定不能指定。cnonce-value是客户端提供的字符串,它由客户端和服务器共同使用,用来避免选择纯文本攻击、提供共同鉴别、提供某些消息的完整性保护。