SIP Authentication

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之间的认证

图1-1 UA之间的认证流程

UA和Proxy之间的认证

图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",