Digest Authentication 摘要认证

“摘要”式认证（ Digest authentication）是一个简单的认证机制，最初是为HTTP协议开发的，因而也常叫做HTTP摘要，在RFC2671中描述。其身份验证机制很简单，它采用杂凑式（hash）加密方法，以避免用明文传输用户的口令。 
    摘要认证就是要核实，参与通信的双方，都知道双方共享的一个秘密（即口令）。

    当服务器想要查证用户的身份，它产生一个摘要盘问（digest challenge），并发送给用户。典型的摘要盘问如下：

Digest realm="iptel.org", qop="auth,auth-int", 
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="", algorithm=MD5

    这里包括了一组参数，也要发送给用户。用户使用这些参数，来产生正确的摘要回答，并发送给服务器。摘要盘问中的各个参数，其意义如下：

    realm（领域）：领域参数是强制的，在所有的盘问中都必须有。它是目的是鉴别SIP消息中的机密。在SIP实际应用中，它通常设置为SIP代理服务器所负责的域名。

    在要求用户输入用户名和口令时，SIP用户代理则会显示这个参数的内容给用户，以便用户使用正确的用户名和口令（这个服务器的）。

    nonce （现时）：这是由服务器规定的数据字符串，在服务器每次产生一个摘要盘问时，这个参数都是不一样的（与前面所产生的不会雷同）。“现时”通常是由一些数据通过md5杂凑运算构造的。这样的数据通常包括时间标识和服务器的机密短语。这确保每个“现时”都有一个有限的生命期（也就是过了一些时间后会失效，并且以后再也不会使用），而且是独一无二的（即任何其它的服务器都不能产生一个相同的“现时”）。

    客户端使用这个“现时”来产生摘要响应（digest response），这样服务器也会在一个摘要响应中收到“现时”的内容。服务器先要检查了“现时”的有效性后，才会检查摘要响应的其它部分。

    因而，“现时”在本质上是一种标识符，确保收到的摘要机密，是从某个特定的摘要盘问产生的。还限制了摘要盘问的生命期，防止未来的重播攻击。

    opaque（不透明体）：这是一个不透明的（不让外人知道其意义）数据字符串，在盘问中发送给用户。

    在摘要响应中，用户会将这个数据字符串发送回给服务器。这使得服务器可以是无状态的。如果需要在盘问和响应之间维护一些状态，可以用这个参数传送状态给客户端，此后当摘要响应回来时，再读这个状态。

    algorithm（算法）：这是用来计算杂凑的算法。当前只支持MD5算法。

    qop（保护的质量）。这个参数规定服务器支持哪种保护方案。客户端可以从列表中选择一个。值

    “auth”表示只进行身份查验， “auth-int”表示进行查验外，还有一些完整性保护。需要看更详细的描述，请参阅RFC2617。

    在收到了摘要盘问后，如果没有预先配置，用户代理软件通常会提示用户输入用户名和口令，产生一个摘要响应，并将这个响应发送给服务器。例如，摘要响应可能如下：

Digest username="jan", realm="iptel.org", 
nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="sip:iptel.org", 
qop=auth, nc=00000001, cnonce="0a4f113b", 
response="6629fae49393a05397450978507c4ef1", opaque=""

    摘要响应类似于摘要盘问。相同的参数，则与摘要盘问有相同的意义。这里只描述新的参数：

    uri（统一资源指示符）：这个参数包含了客户端想要访问的URI。 
    qop：客户端选择的保护方式。 
    nc：“现时”计数器，这是一个16进制的数值，即客户端发送出请求的数量（包括当前这个请求），这些请求都使用了当前请求中这个“现时”值。例如，对一个给定的“现时”值，在响应的第一个请求中，客户端将发送“nc=00000001”。这个指示值的目的，是让服务器保持这个计数器的一个副本，以便检测重复的请求。如果这个相同的值看到了两次，则这个请求是重复的。

    cnonce：这也是一个不透明的字符串值，由客户端提供，并且客户端和服务器都会使用，以避免用明文文本。这使得双方都可以查验对方的身份，并对消息的完整性提供一些保护。

    response（响应）：这是由用户代理软件计算出的一个字符串，以证明用户知道口令。

    当服务器接收到摘要响应，也要重新计算响应中各参数的值，并利用客户端提供的参数值，和服务器上存储的口令，进行比对。如果计算结果与收到的客户响应值是相同的，则客户已证明它知道口令，因而客户的身份验证通过。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/imj060336/archive/2007/12/22/1959067.aspx

 

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",
              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是客户端提供的字符串，它由客户端和服务器共同使用，用来避免选择纯文本攻击、提供共同鉴别、提供某些消息的完整性保护。
5. 摘要的计算方法
128位的MD5摘要由32个可打印的ASCII码字符表示。128位摘要中的位按其重要性由高到低转换，在某个时刻每4位可用下面的ASCII表示。每4位都可用16进制字符‘0123456789abcdef’表示，也就是说，二进制0000由字符‘0’表示；0001由字符‘1’表示，以后如此类推，1111用‘f’表示。
在本文中，用KD（secret,data）来表示摘要算法，其中data指数据，secret表示采用的方法.如果表示校验和算法时，data要写成H（data）；而unq（X）表示将带引号字符串的引号去掉。
简单来说,response =
H(H(username:realm:password)：nonce：cnonce：H(requestMothod:request-URI))
以下为详细的计算规则.
对于"MD5" 和"MD5-sess" 算法：
H()：hash函数
H(data) = MD5(data)
和
KD(secret, data) = H(concat(secret, ":", data))
也就是说，摘要（digest）就是对secret与data通过冒号连接一起的结果进行MD5运算。而"MD5-sess"算法则允许其它第三方服务器参与鉴别。
a) 请求－摘要（Request-Digest）
　　 如果”qop”值是"auth" 或"auth-int"：
　　request-digest = <"> < KD ( H(A1), unq(nonce-value)
　　 ":" nc-value
　　 ":" unq(cnonce-value)
　　 ":" unq(qop-value)
　　 ":" H(A2)
　　 ) <">
　　 如果”qop”指示没有给出（与RFC2069保持兼容性）：
　　request-digest =<"> < KD ( H(A1), unq(nonce-value)
　　":" H(A2)
　　) <">
　　 A1及A2的定义在下面。
b) A1
　　 如果算法（"algorithm"）值是”MD5”或没有指定，则A1是：
　　A1 = unq(username-value) ":" unq(realm-value) ":" passwd
　　其中
　　passwd = < user's password >
　　如果"algorithm"值是"MD5-sess"，则A1只要计算一次，即当客户端发出第一个请求，并从服务器收到WWW-鉴别（WWW-Authenticate）质询（challenge）时计算。它使用该质询中的服务器的nonce，则用来构建A1的第一个客户端nonce值应为：
　　A1 = H( unq(username-value) ":" unq(realm-value)
　　 ":" passwd )
　　 ":" unq(nonce-value) ":" unq(cnonce-value)
　　 上式为并发请求和回应的鉴别产生一个‘会话密钥’（session key），该密钥对于每个‘鉴别会话’（authentication session）都是不同的，这样，就限制了使用任何一个密钥进行哈希处理的次数。
c) A2
如果”qop”值是”auth”或者没给出，则A2：
A2 = Method ":" digest-uri-value　
如果"qop"值是"auth-int", 则A2：
A2 = Method ":" digest-uri-value ":" H(entity-body)
d) 指示值和带引号的字符串（Directive values and quoted-string）
注意，许多指示的取值，如”username-value”等，被定义成带引号的字符串（quoted-string）。而实际上，”unq”注释则表示在生成字符串A1时，去掉其外部的引号。因而，如当授权标题包括该域，如：
　　username="Mufasa", realm=myhost@testrealm.com
则表示用户Mufasa的口令是"Circle Of Life"，这样H（A1）就可表示成
　　H（Mufasa:myhost@testrealm.com:Circle Of Life），注意，在摘要字符串中没有引号。
　　注意，在摘要函数H（）中的字符串中不允许出现空格，除非空格出现在带引号的字符串内或者用以标记字符串摘要的实体主体中。例如，上面出现的字符串A1必须是
　　Mufasa:myhost@testrealm.com:Circle Of Life
在冒号的两边都不可以有空格，但是允许口令单词之间出现空格（Circle+SP+Of+SP+Life）。同样，其它由H（）摘要的字符串也不能在用于域间分隔的冒号两边加空格，除非空格在引号内或被摘要的实体主体内。
　　 同样要注意的是，如果应用了完整性保护（integrity protection），即qop=auth-int，则H（实体-主体）就是实体主体的哈希值，而不是消息主体的哈希值，该值在发送方进行任何传输编码前计算，之后，被接收方删除。