会话初始协议认证的方法转让专利
申请号 : CN200410069510.0
文献号 : CN1716953B
文献日 : 2010-09-15
发明人 : 周思义
申请人 : 华为技术有限公司
摘要 :
本发明公开了一种会话初始协议认证的方法，该方法包括：客户端发送不带认证信息的请求消息到服务器端，请求接入；服务器端收到所述请求消息后回送带有服务器端的认证交换信息及服务器端DH认证响应信息的响应消息；客户端对收到的响应消息进行认证，认证通过后，发送带有客户端认证信息的请求消息到服务器端；服务器端根据收到的请求消息对用户进行认证，并回送包含服务器端认证信息的响应消息；用户根据收到的包含服务器端认证信息的响应消息验证服务器端的合法性。利用本发明，可以有效地提高SIP认证的安全性。
权利要求 :
1.一种会话初始协议认证的方法，其特征在于，所述方法包括：
A、客户端发送不带认证信息的请求消息到服务器端，请求接入；
B、所述服务器端收到所述请求消息后回送带有服务器端的认证交换信息及服务器端Diffie-Hellman认证响应信息的响应消息；
C、所述客户端根据收到的响应消息对所述服务器端进行认证，当所述服务器端的认证通过后，发送带有客户端认证信息的请求消息到服务器端；
D、所述服务器端根据收到的带有客户端认证信息的请求消息对所述客户端进行认证，并回送包含服务器端认证信息的响应消息；
E、所述客户端根据收到的所述包含服务器端认证信息的响应消息验证所述服务器端的合法性。
2.根据权利要求1所述的会话初始协议认证的方法，其特征在于，所述步骤B之前，还包括：服务器端根据用户名和初始密码生成所述服务器端Diffie-Hellman认证响应信息。
3.根据权利要求1所述的会话初始协议认证的方法，其特征在于，所述步骤C发送的请求消息中的客户端认证信息包括：客户端Diffie-Hellman认证响应信息；或者，客户端的认证交换信息和客户端Diffie-Hellman认证响应信息。
4.根据权利要求3所述的会话初始协议认证的方法，其特征在于，所述步骤C中发送带有客户端认证信息的请求消息到服务器端之前，还包括：C1、所述客户端根据所述服务器端的认证交换信息及本端的认证交换信息获取共享密钥；
C2、根据所述共享密钥生成所述客户端Diffie-Hellman认证响应信息。
5.根据权利要求3所述的会话初始协议认证的方法，其特征在于，所述步骤D中所述服务器端根据收到的带有客户端认证信息的请求消息对所述客户端进行认证包括：当所述带有客户端认证信息的请求消息的头域中不包括所述客户端的认证交换信息时，所述服务器端使用用户名和初始密码对收到的请求消息进行认证；
当所述带有客户端认证信息的请求消息的头域中包括所述客户端的认证交换信息时，所述服务器端根据所述客户端的认证交换信息以及本端的认证交换信息获取共享密钥，根据所述共享密钥对收到的请求消息进行认证。
6.根据权利要求3所述的会话初始协议认证的方法，其特征在于，所述步骤D中回送包含服务器端认证信息的响应消息之前，还包括：当所述带有客户端认证信息的请求消息的头域中不包括所述客户端的认证交换信息时，根据所述用户名和初始密码生成所述服务器端Diffie-Hellman认证响应信息；
当所述带有客户端认证信息的请求消息的头域中包括所述客户端的认证交换信息时，所述服务器端根据所述客户端的认证交换信息以及本端的认证交换信息获取共享密钥，根据所述共享密钥生成服务器端Diffie-Hellman认证响应信息。
7.根据权利要求1或3所述的会话初始协议认证的方法，其特征在于，所述包含服务器端认证信息的响应消息包括：可选的Diffie-Hellman认证信息头域。
8.根据权利要求7所述的会话初始协议认证的方法，其特征在于，所述Diffie-Hellman认证信息头域包括：服务器端的认证信息。
9.根据权利要求6所述的会话初始协议认证的方法，其特征在于，所述方法还包括：在所述客户端和所述服务器端都获取共享密钥后，进行消息交互时，只使用所述共享密钥对交互的消息进行加密。
10.根据权利要求1所述的会话初始协议认证的方法，其特征在于，所述服务器端包括：代理服务器、背靠背服务器、重定向服务器和注册服务器。
说明书 :
技术领域
本发明涉及网络安全技术领域，具体涉及一种会话初始协议认证的方法。
背景技术
随着互联网及下一代网络的发展，其方便的接入、逐步提高的接入速度、易于扩展的特性、以及丰富的业务功能，受到了运营商及用户的欢迎，但与此同时其安全性方面也逐步受到人们的关注。SIP(会话初始协议)协议作为下一代网络的核心协议在安全性方面也面临着同样的问题，接入认证是解决这一问题的方式之一，已有的SIP协议(RFC3261)提供了基本的接入认证方式，即所谓的degist(摘要)认证。
SIP协议具有简单、扩展性好及与Internet应用紧密结合的特点，仅用3条消息(INVITE、BYE和ACK)和4个头域(To、From、Call-ID和Cseq)就能实现简单的Internet电话。SIP中有客户机和服务器之分。客户机是指为了向服务器发送请求而与服务器建立连接的应用程序。B2B用户代理(Back to Back User Agent)和代理(Proxy)中含有客户机。服务器是用于向客户机发出的请求提供服务并回送应答的应用程序。共有四类基本服务器：
1.B2B用户代理服务器：当接到SIP请求时它联系用户，并代表用户返回响应。
2.代理服务器：代表其它客户机发起请求，既充当服务器又充当客户机的媒介程序。在转发请求之前，它可以改写原请求消息中的内容。
3.重定向服务器：它接收SIP请求，并把请求中的原地址映射成零个或多个新地址，返回给客户机。
4.注册服务器：它接收客户机的注册请求，完成用户地址的注册。用户终端程序往往需要包括用户代理客户机和用户代理服务器。
SIP的认证过程是一个类似于HTTP(HyperText Transfer Protocol)的无状态的基于Challenge(问询)的机制(RFC2617)，基本思路是认证的双方共享用户名和初始密码。在认证的过程中，认证方向被认证方发送Challenge，被认证方在收到Challenge后，将用户名和初始密码经过加密，形成一个字符串，传递给认证方；认证方将自己知道的用户名和密码通过同样的方式进行加密，得到一个字符串，通过比较该字符串和被认证方传递的字符串是否一致来判断用户的密码是否正确。
在SIP中采用Digest Scheme(摘要机制)的认证方式，具体流程如图1所示。
对于UAS(服务器端)，如果需要认证UAC(客户端)，则必须发送401 Unauthorized响应，401 Unauthorized响应表示客户试图未经授权访问受密码保护的资源或者客户。401响应中必须携带WWW-Authenticate头域，UAC据此显示用户名字/密码对话框，然后在填写合适的Authorization头后再次发出请求，在Authorization头域中携带认证信息。注册服务器和重定向服务器也可以使用401响应来进行认证UAC。
对于Proxy(代理服务器)而言，如果要认证UAC，则必须采用407Proxy Authentication Required响应，407 Proxy Authentication Required类似于401，表示客户必须先经过代理服务器的授权，并必须在其中携带Proxy-Authenticate头域。UAC可以再次发起请求，在Proxy-Authorization头域中携带认证信息。
当UAC因为收到401或者407响应而重新发起请求时，一般应该使用和上一个请示求相同的Call-ID，From头域和To头域，但是Cseq头域中的序数必须加一，即有相同Call-ID的请求必须拥有递增的Cseq号。
该认证方式只提供最基本的接入认证功能，在网络安全方面存在以下缺陷：
1、RFC3261中的基本Digest认证机制只能对UAC的Request消息发起认证，对401或者407响应则没有相应的认证机制，所以很容易导致对UAC发起Plain Text(明文)攻击。
2、由于在RFC3261 Digest所有的认证(只有对UAC的Request消息发起的认证)过程中都使用了初始密钥，所以容易被监听，分析(Authorization和Proxy-Authorization)头域，而得出初始密钥，容易导致字典攻击。
SIP协议具有简单、扩展性好及与Internet应用紧密结合的特点，仅用3条消息(INVITE、BYE和ACK)和4个头域(To、From、Call-ID和Cseq)就能实现简单的Internet电话。SIP中有客户机和服务器之分。客户机是指为了向服务器发送请求而与服务器建立连接的应用程序。B2B用户代理(Back to Back User Agent)和代理(Proxy)中含有客户机。服务器是用于向客户机发出的请求提供服务并回送应答的应用程序。共有四类基本服务器：
1.B2B用户代理服务器：当接到SIP请求时它联系用户，并代表用户返回响应。
2.代理服务器：代表其它客户机发起请求，既充当服务器又充当客户机的媒介程序。在转发请求之前，它可以改写原请求消息中的内容。
3.重定向服务器：它接收SIP请求，并把请求中的原地址映射成零个或多个新地址，返回给客户机。
4.注册服务器：它接收客户机的注册请求，完成用户地址的注册。用户终端程序往往需要包括用户代理客户机和用户代理服务器。
SIP的认证过程是一个类似于HTTP(HyperText Transfer Protocol)的无状态的基于Challenge(问询)的机制(RFC2617)，基本思路是认证的双方共享用户名和初始密码。在认证的过程中，认证方向被认证方发送Challenge，被认证方在收到Challenge后，将用户名和初始密码经过加密，形成一个字符串，传递给认证方；认证方将自己知道的用户名和密码通过同样的方式进行加密，得到一个字符串，通过比较该字符串和被认证方传递的字符串是否一致来判断用户的密码是否正确。
在SIP中采用Digest Scheme(摘要机制)的认证方式，具体流程如图1所示。
对于UAS(服务器端)，如果需要认证UAC(客户端)，则必须发送401 Unauthorized响应，401 Unauthorized响应表示客户试图未经授权访问受密码保护的资源或者客户。401响应中必须携带WWW-Authenticate头域，UAC据此显示用户名字/密码对话框，然后在填写合适的Authorization头后再次发出请求，在Authorization头域中携带认证信息。注册服务器和重定向服务器也可以使用401响应来进行认证UAC。
对于Proxy(代理服务器)而言，如果要认证UAC，则必须采用407Proxy Authentication Required响应，407 Proxy Authentication Required类似于401，表示客户必须先经过代理服务器的授权，并必须在其中携带Proxy-Authenticate头域。UAC可以再次发起请求，在Proxy-Authorization头域中携带认证信息。
当UAC因为收到401或者407响应而重新发起请求时，一般应该使用和上一个请示求相同的Call-ID，From头域和To头域，但是Cseq头域中的序数必须加一，即有相同Call-ID的请求必须拥有递增的Cseq号。
该认证方式只提供最基本的接入认证功能，在网络安全方面存在以下缺陷：
1、RFC3261中的基本Digest认证机制只能对UAC的Request消息发起认证，对401或者407响应则没有相应的认证机制，所以很容易导致对UAC发起Plain Text(明文)攻击。
2、由于在RFC3261 Digest所有的认证(只有对UAC的Request消息发起的认证)过程中都使用了初始密钥，所以容易被监听，分析(Authorization和Proxy-Authorization)头域，而得出初始密钥，容易导致字典攻击。
发明内容
本发明的目的是提供一种会话初始协议认证的方法，以提高网络接入的安全性。
本发明的目的是通过以下技术方案实现的：
一种会话初始协议认证的方法，包括：
A、客户端发送不带认证信息的请求消息到服务器端，请求接入；
B、所述服务器端收到所述请求消息后回送带有服务器端的认证交换信息及服务器端Diffie-Hellman DH认证响应信息的响应消息；
C、所述客户端根据收到的响应消息对所述服务器端进行认证，当所述服务器端的认证通过后，发送带有客户端认证信息的请求消息到服务器端；
D、所述服务器端根据收到的带有客户端认证信息的请求消息对所述客户端进行认证，并回送包含服务器端认证信息的响应消息；
E、所述客户端根据收到的所述包含服务器端认证信息的响应消息验证所述服务器端的合法性。
所述步骤B之前，还包括：服务器端根据用户名和初始密码生成所述服务器端DH认证响应信息。
所述步骤C发送的请求消息中的客户端认证信息包括：客户端DH认证响应信息；或者，客户端的认证交换信息和客户端DH认证响应信息。
所述步骤C中发送带有客户端认证信息的请求消息到服务器端之前，还包括：
C1、所述客户端根据所述服务器端的认证交换信息及本端的认证交换信息获取共享密钥；
C2、根据所述共享密钥生成所述客户端DH认证响应信息，其中所述客户端DH认证响应信息为所述客户端认证信息。
所述步骤D中所述服务器端根据收到的带有客户端认证信息的请求消息对所述客户端进行认证包括：
当所述带有客户端认证信息的请求消息的头域中不包括所述用户的认证交换信息时，所述服务器端使用用户名和初始密码对收到的请求消息进行认证；
当所述带有客户端认证信息的请求消息的头域中包括所述用户的认证交换信息时，所述服务器端根据所述用户的认证交换信息以及本端的认证交换信息获取共享密钥，根据所述共享密钥对收到的请求消息进行认证。
所述步骤D中回送包含服务器端认证信息的响应消息之前，还包括：
当所述带有客户端认证信息的请求消息的头域中不包括所述用户的认证交换信息时，根据所述用户名和初始密码生成所述服务器端DH认证响应信息；
当所述带有客户端认证信息的请求消息的头域中包括所述用户的认证交换信息时，所述服务器端根据所述用户的认证交换信息以及本端的认证交换信息获取共享密钥，根据所述共享密钥生成服务器端DH认证响应信息。
所述包含服务器端认证信息的响应消息包括：可选的DH认证信息头域。
所述DH认证信息头域包括：服务器端的验证信息。
所述方法还包括：在所述客户端和所述服务器端都获取共享密钥后，进行消息交互时，只使用所述共享密钥对交互的消息进行加密。
所述服务器端包括：代理服务器、背靠背服务器、重定向服务器和注册服务器。
由以上本发明提供的技术方案可以看出，本发明在现有SIP基本认证基础上，引入DH(Diffie-Hellman)算法，并对SIP头域及字段进行扩展，使初始密钥只在第一次交互中使用，在其他的认证过程中使用共享密钥，使初始密钥得到了充分的保护，可以有效地防止字典攻击；同时，当任何一方重启后或者希望更换共享密码时，也可以重新启用校验初始密码的方式，通过使用认证次数计数器，有效地防止向UAS或者Proxy的replay(重发)攻击。利用本发明，可以大大提高网络的安全性。
本发明的目的是通过以下技术方案实现的：
一种会话初始协议认证的方法，包括：
A、客户端发送不带认证信息的请求消息到服务器端，请求接入；
B、所述服务器端收到所述请求消息后回送带有服务器端的认证交换信息及服务器端Diffie-Hellman DH认证响应信息的响应消息；
C、所述客户端根据收到的响应消息对所述服务器端进行认证，当所述服务器端的认证通过后，发送带有客户端认证信息的请求消息到服务器端；
D、所述服务器端根据收到的带有客户端认证信息的请求消息对所述客户端进行认证，并回送包含服务器端认证信息的响应消息；
E、所述客户端根据收到的所述包含服务器端认证信息的响应消息验证所述服务器端的合法性。
所述步骤B之前，还包括：服务器端根据用户名和初始密码生成所述服务器端DH认证响应信息。
所述步骤C发送的请求消息中的客户端认证信息包括：客户端DH认证响应信息；或者，客户端的认证交换信息和客户端DH认证响应信息。
所述步骤C中发送带有客户端认证信息的请求消息到服务器端之前，还包括：
C1、所述客户端根据所述服务器端的认证交换信息及本端的认证交换信息获取共享密钥；
C2、根据所述共享密钥生成所述客户端DH认证响应信息，其中所述客户端DH认证响应信息为所述客户端认证信息。
所述步骤D中所述服务器端根据收到的带有客户端认证信息的请求消息对所述客户端进行认证包括：
当所述带有客户端认证信息的请求消息的头域中不包括所述用户的认证交换信息时，所述服务器端使用用户名和初始密码对收到的请求消息进行认证；
当所述带有客户端认证信息的请求消息的头域中包括所述用户的认证交换信息时，所述服务器端根据所述用户的认证交换信息以及本端的认证交换信息获取共享密钥，根据所述共享密钥对收到的请求消息进行认证。
所述步骤D中回送包含服务器端认证信息的响应消息之前，还包括：
当所述带有客户端认证信息的请求消息的头域中不包括所述用户的认证交换信息时，根据所述用户名和初始密码生成所述服务器端DH认证响应信息；
当所述带有客户端认证信息的请求消息的头域中包括所述用户的认证交换信息时，所述服务器端根据所述用户的认证交换信息以及本端的认证交换信息获取共享密钥，根据所述共享密钥生成服务器端DH认证响应信息。
所述包含服务器端认证信息的响应消息包括：可选的DH认证信息头域。
所述DH认证信息头域包括：服务器端的验证信息。
所述方法还包括：在所述客户端和所述服务器端都获取共享密钥后，进行消息交互时，只使用所述共享密钥对交互的消息进行加密。
所述服务器端包括：代理服务器、背靠背服务器、重定向服务器和注册服务器。
由以上本发明提供的技术方案可以看出，本发明在现有SIP基本认证基础上，引入DH(Diffie-Hellman)算法，并对SIP头域及字段进行扩展，使初始密钥只在第一次交互中使用，在其他的认证过程中使用共享密钥，使初始密钥得到了充分的保护，可以有效地防止字典攻击；同时，当任何一方重启后或者希望更换共享密码时，也可以重新启用校验初始密码的方式，通过使用认证次数计数器，有效地防止向UAS或者Proxy的replay(重发)攻击。利用本发明，可以大大提高网络的安全性。
附图说明
图1是现有技术中SIP的认证流程；
图2是本发明会话初始协议认证的方法的流程图；
图3是本发明方法中用户接入时的消息流程图。
图2是本发明会话初始协议认证的方法的流程图；
图3是本发明方法中用户接入时的消息流程图。
具体实施方式
本发明的核心在于在现有SIP基本认证基础上，引入DH算法，并对SIP头域及字段进行扩展，不仅对用户的请求消息发起认证，而且对服务器端的响应消息也提供相应的认证机制，以便有效地防止对用户发起的PlainText；同时，在本发明方法中，初始密码只在第一次交互中使用，后续的认证过程都通过共享密码来加密，以便有效地防止字典攻击，而且，当任何一方重启后或者希望更换共享密码时，也可以重新启用校验密码的方式，以便有效地防止replay攻击和兼容异常情况。
为了使本技术领域的人员更好地理解本发明，下面结合附图和实施方式对本发明作进一步的详细说明。
参照图2，图2是本发明方法的详细流程，包括以下步骤：
步骤201：客户端发送不带认证信息的请求消息到服务器端，请求接入。所述服务器端包括：代理服务器、背靠背服务器、重定向服务器和注册服务器。
步骤202：服务器端收到所述请求消息后根据用户名和初始密码生成服务器端DH认证响应信息。
步骤203：向客户端回送带有服务器端的认证交换信息及服务器端DH认证响应信息的响应消息。
步骤204：客户端根据服务器端的认证交换信息及本端的认证交换信息获取共享密钥。
步骤205：根据所述共享密钥生成客户端DH认证响应信息。
步骤206：客户端对收到的响应消息进行认证，认证通过后，发送带有客户端认证信息的请求消息到服务器端。所述带有客户端认证信息的请求消息包括：可选的客户端的认证交换信息、客户端DH认证响应信息。
步骤207：服务器端根据收到的请求消息对用户进行认证，并回送包含服务器端认证信息的响应消息。所述包含服务器端认证信息的响应消息包括：可选的DH认证信息头域。所述DH认证信息头域包括：服务器端的认证信息。
服务器端收到的请求消息有两种情况：该消息的头域中不包括客户端的认证交换信息；该消息的头域中包括客户端的认证交换信息。
当该消息的头域中不包括客户端的认证交换信息时，服务器端使用用户名和初始密码对收到的请求消息进行认证并根据所述用户名和初始密码生成所述服务器端DH认证响应信息。
当该消息的头域中不包括客户端的认证交换信息时，服务器端根据用户的认证交换信息以及本端的认证交换信息获取共享密钥，根据所述共享密钥对收到的请求消息进行认证，并根据所述共享密钥生成服务器端DH认证响应信息。
步骤208：用户根据收到的包含服务器端认证信息的响应消息验证所述服务器端的合法性。
上述过程结束后，也就是说在客户端和服务器端都获取共享密钥后，进行消息交互时，只使用所述共享密钥对所述消息进行加密。
参照图3，图3示出了本发明方法中用户接入时的消息流程：
对于UAS(服务器端)，如果需要认证UAC(客户端)，则必须发送401响应，并必须在其中携带WWW-Authenticate头域，在该头域中包含UAS的认证，以防止Middle-In-Man攻击。UAC可以再次发起请求，在Authorization头域中携带认证信息。Registrars(注册服务器)和Redirectserver(重定向服务器)也可以使用401响应来进行认证UAC。
对于Proxy(代理服务器)，如果需要认证UAC，则必须发送407响应，并必须在其中携带Proxy-Authenticate头域，在该头域中包含Proxy的认证，以防止Middle-In-Man攻击。UAC可以再次发起请求，在Proxy-Authorization头域中携带认证信息。
当UAC因为收到401或者407响应而重新发起请求时，一般应该使用相同的Call-ID，From头域和To头域，但是CSeq头域中的序数必须加一。
但是一个Server(UAS或者Proxy)不能向ACK(确认客户端已经接收到对INVITE的最终响应)请求和CANCEL请求发起认证。对于UAC而言，比较好的方式是在ACK消息中包含一个通过认证的认证信息，该认证信息包括Authorization和Proxy-Authorization头域，它是在和ACK对应的INVITE消息中携带的并已经通过UAS或Proxy认证。
为了防止Plain Text攻击，UAS或者Proxy应在认证的成功响应(200)中包含新增头域DH-Authentication-Info，在该新增头域中包含UAS或者Proxy的验证信息，UAC通过该信息验证UAS或者Proxy的合法性。
这可以是一个可选的特性，如果UAC和UAS或者Proxy间配置了必须包含DH-Authentication-Info，则可以实现UAC验证其接入的服务器的合法性。如果在200响应中没有包含DH-Authentication-Info或者验证失败，且在UAC和UAS或者Proxy间配置了必须要包含DH-Authentication-Info，则UAC可以认为这是某个恶意的服务器接收了消息，可以选择拒绝服务器。
在上述认证过程中，只在初始的认证过程中使用初始密钥Ki，而在以后的认证过程中都使用共享密钥Ks，对于图2中的消息而言，F2-F4所使用的密钥是Ki，而F6-F8使用的密钥是Ks。由于Ki只出现一次，所以可以有效地防止Plain Text和字典攻击。
下面详细说明本发明中的SIP头域中的扩展参数及新增的SIP头域：
本技术领域人员知道，在RFC3261中定义了四个头域，分别为：WWW-Authenticate，Proxy-Authenticate，Authorization，Proxy-Authorization，本发明即是在此基础上，通过对这四个头域中参数的扩展实现DH-Digest认证。
本发明中定义的头域如下：
1.WWW-Authenticate＝″WWW-Authenticate″HCOLON challenge
2.Proxy-Authenticate＝″Proxy-Authenticate″HCOLON challenge
其中，challenge＝(″Digest″|LWS digest-cln*(COMMA digest-cln))
/dh-challenge/other-challenge
dh-challenge＝(″DH-Digest″｜LWS digest-cln*(COMMA digest-cln))
other-challenge＝auth-scheme LWS auth-param*(COMMA auth-param)
digest-cln＝realm/domain/nonce/opaque/stale/algorithm
/qop-options/dh-b/dh-response-auth/auth-param
realm＝″realm″EQUAL realm-value
realm-value＝quoted-string
domain＝″domain″EQUAL LDQUOT URI*(1*SP URI)RDQUOT
URI＝absoluteURI/abs-path
nonce＝″nonce″EQUAL nonce-value
nonce-value＝quoted-string
opaque＝″opaque″EQUAL quoted-string
stale＝″stale″EQUAL(″true″/″false″)
algorithm＝″algorithm″EQUAL(″MD5″/″MD5-sess″/token)
qop-options＝″qop″EQUAL LDQUOT qop-value
*(″，″qop-value)RDQUOT
qop-value＝″auth″/″auth-int″/token
dh-b＝″DH-B″EQUAL dh-b-value
dh-b-value＝quoted-string
dh-response-auth＝″DH-Rspauth″EQUAL dh-response-digest
dh-response-digest＝LDQUOT 32LHEX RDQUOT
其中，带下划线部分为头域中新增的参数。
对上述WWW-Authenticate和Proxy-Authenticate头域中的参数说明如下：
realm：realm-value必须是一个全局唯一的字符串，并且全部由可显示的字符组成，用来呈现给用户，指示用户输入用户名及密码。
Domain：由双引号包含的一个或多个URI列表，表明在这些domain域中，可以使用同样的认证信息。该参数对Proxy-Authenticate头域无意义。
Nonce：nonce是由server提供的一串以16进制或base64表示的随机字符串。
Opaque：opaque是由server提供的一串以16进制或base64表示的随机字符串，客户端应不作任何改变，返回给server。
Stale：该参数是一个标志，有TRUE和FALSE两个值，用来指示前一个请求，由于nonce过期而导致的认证失败。当客户端收到的401/407中，该参数值为TRUE时，只需使用新的nonce，重新计算一次摘要即可，不需再要求用户输入用户名及密码。只有当server收到的request中nonce是过期的，但是该过期的nonce对应的摘要正确时(也就是说用户名和密码是正确的)，才可将该参数设置为TRUE。
Algorithm：用于指示两边计算摘要的算法，当没有该参数时，缺省为MD5算法。
qop-options：为了兼容RFC2069而引入的任选参数，用于指示server所能支持的″quality of protection″，可以带多个值，目前有两个取值：″auth″、″auth-int″(取值不同在加密算法上稍有不同)。具体使用方法参见后面的摘要计算方法。
dh-b：为了实现DH Digest而特别引入的一个参数，代表了UAS或者Proxy的DH交换数；通过此参数，UAC可以用来计算出共享密钥。
当scheme为DH-Digest，而且WWW-Authentication和Proxy-Authentication中不包含此dh-b时，则意味着UAS或者Proxy已经将db-b在以前的消息中发送给UAC了，当前的这次认证可以直接采用共享密钥，而不需要采用初始密钥(如果UAC不记得共享密钥，如重启后，也可以使用初始密钥进行认证)。当其中包含dh-b时，则表示UAS或者Proxy希望重新发起一次共享密钥的协商。
dh-response-auth：为了防止恶意服务器发起的401或者407响应，UAC需要对UAS或者Proxy发起的401或者407响应进行认证。UAS或者Proxy在发送401或者407响应时，必须采用初始密钥(当dh-b参数存在时)或者采用共享密钥(当不存在dh-b参数时)进行认证。
auth-param：该参数是为了将来扩展引入的。
3.Proxy-Authorization＝″Proxy-Authorization″HCOLON credentials
4.Authorization＝″Authorization″HCOLON credentials
其中，credentials＝(″Digest″LWS digest-response)
/dh-digest-response/other-response
digest-response＝dig-resp*(COMMA dig-resp)
dh-digest-response＝dig-resp*(COMMA dig-resp)
dig-resp＝username/realm/nonce/digest-uri
/dresponse/algorithm/cnonce
/opaque/message-qop
/nonce-count/dh-a/auth-param
username＝″username″EQUAL username-value
username-value＝quoted-string
digest-uri＝″uri″EQUAL LDQUOT digest-uri-value RDQUOT
digest-uri-value＝rquest-uri；Equal to request-uri as specified
by HTTP/1.1
message-qop＝″qop″EQUAL qop-value
cnonce＝″cnonce″EQUAL cnonce-value
cnonce-value＝nonce-value
nonce-count＝″nc″EQUAL nc-value
nc-value＝8LHEX
dresponse＝″response″EQUAL request-digest
request-digest＝LDQUOT 32LHEX RDQUOT
dh-a＝″DH-A″EQUAL dh-a-value
dh-a-value＝quoted-string
auth-param＝auth-param-name EQUAL(token/quoted-string)
auth-param-name＝token
other-response＝auth-scheme LWS auth-param*(COMMA auth-param)
auth-scheme＝token
其中，带下划线部分为头域中新增的参数。
对上述Authorization和Proxy-Authorization头域中的参数说明如下：
response：一个128比特的，由32个16进制数表示的字符串，它是由后面的公式计算而来的。
username：在指定的realm范围内的用户名。
digest-uri：与最初的Request-Line的Request-URI相同，之所以不直接使用请求消息中的Request-URI，是因为中间的proxy可能会修改Request-URI。
message-qop：为了兼容RFC2069而引入的任选参数，用于指示客户端所能支持的“quality of protection(保护质量)”，只能带一个值，且只能是server过来的qop中的一个值。它将影响对摘要的计算。WWW-Authenticate或Proxy-Authenticate头域中如果包含了qop参数，那么在Authorization或Proxy-Authorization头域中必须带此参数。
cnonce：如果WWW-Authenticate或Proxy-Authenticate头域中带了qop参数，那么在Authorization或Proxy-Authorization头域中必须带此参数，否则不需要带此参数。该参数由客户端给出，用于避免plain text攻击、提供message integrity protection、以及提供相互的认证。
cnonce-count：如果WWW-Authenticate或Proxy-Authenticate头域中带了qop参数，那么在Authorization或Proxy-Authorization头域中必须带此参数，否则不需要带此参数。该参数是一个16进制的计算器，用于计数客户端发出的包含nonce的请求消息个数。例如，对于server给定的一个nonce，客户端发出的第一个请求消息，该参数为“nc＝00000001”，server会保存自己的一份nc拷贝，这样server能对客户端发过来的该参数的值与自己保存的值进行比较，这样就可以判断是否受到了replay攻击。
dh-a：为了实现DH Digest而特别引入的一个参数，代表了UAC的DH交换数；通过此参数，UAS或者Proxy可以用来计算出共享密钥。
当Authorization和Proxy-Authorization头域中的scheme为“DH-Digest”，此时如果头域中包含了dh-a参数，则当前的这次认证是使用初始密钥进行加密的，此时不管Challenge(WWW-Authentication和Proxy-Authentication)中是否包含了dh-b参数，都应该使用初始密钥和dh-a的算法进行验证(这种情况可能发生在UAC重启后，发送新的请求，但是UAS或者Proxy并不知道UAC重启了，而仍然希望UAC使用共享密钥来进行验证，此时UAC可以忽略UAS或者Proxy希望通过共享密钥来加密的请求，而通过初始密钥来实现验证)；如果不包含dh-a参数，则意味着在以前的消息中UAC已经将dh-a发送给UAS或者Proxy了，当前的这次认证是使用共享密钥加密的。
根据Authentication-Info的ABNF定义不能扩展参数，所以在本发明中还新增加了一个头域DH-Authentication-Info。
5.DH-Authentication-Info＝″DH-Authentication-Info″HCOLON dh-ainfo*(COMMA dh-ainfo)
其中，
dh-ainfo＝nextnonce/message-qop/response-auth
/cnonce/nonce-count/dh-a
nextnonce＝″nextnonce″EQUAL nonce-value
response-auth＝″rspauth″EQUAL response-digest
response-digest＝LDQUOT*LHEX RDQUOT
对上述新增头域DH-Authentication-Info中的参数说明如下：
UAS或者Proxy可以利用该头域：
A、改变nonce，客户端收到带nextnonce参数的该头域后，如果要发送下一个请求，则应使用新的nonce进行计算，否则如果客户端仍使用老的nonce计算摘要，server会要求重新认证，并且带指示TRUE的stale参数。此时不需要包含dh-a参数。
B、UAS或Proxy向UAC认证自己，需要携带response-digest参数；此时如果包含了dh-a参数，则此response-digest是采用初始密钥进行加密的；如果没有携带dh-a参数，则此response-digest是采用的共享密钥进行加密的。
Nextnonce：该参数是server给出的客户端下一次发送请求消息时用的新nonce。
message-qop：该参数应与客户端发来的qop参数取相同的值，指示server计算response摘要时的″quality of protection″。
为了防止replay攻击，本发明方法规定在上述头域WWW-Authenticate，Proxy-Authenticate，Authorization，Proxy-Authorization使用中必须携带qop参数。
上述参数中涉及的加密算法如下：
1、dh-response-digest(DH响应摘要)的算法如下：
因为在WWW-Authenticate和Proxy-Authenticate中的qop是一个选项，可以包含auth或者auth-int等多种选择。所以在此强制规定，qop-value为只使用auth。
dh-response-digest＝<″> ″：″unq(qop-value)
″：″MD5(A2)
)<″>
其中，A1的算法如下：
如果″algorithm″指示″MD5″或没有带该参数，并且没有dh-b参数，则A 1＝unq(username-value)″：″unq(realm-value)″：″shared-key
其中，shared-key＝
如果″algorithm″指示″MD5″或没有带该参数，并且有dh-b参数，则A1＝unq(username-value)″：″unq(realm-value)″：″passwd″：″unq(dh-b)
其中，passwd＝
dh-b＝
如果″algorithm″指示″MD5-sess″，并且没有dh-b参数，则
A 1＝MD5(unq(username-value)″：″unq(realm-value)″：″shared-key)″：″unq(nonce-value))
如果″algorithm″指示″MD5″或没有带该参数，并且有dh-b参数，则A1＝MD5(unq(username-value)″：″unq(realm-value)″：″passwd″：″unq(dh-b))
A2的算法如下：
A2＝Method ″：″digest-uri-value
2、request-digest(请求摘要)的算法如下：
如果″qop″值为″auth″或″auth-int″，则
request-digest＝<″> ″：″nc-value
″：″unq(cnonce-value)
″：″unq(qop-value)
″：″MD5(A2)
)<″>
其中，A1的算法如下：
如果″algorithm″指示″MD5″或没有带该参数，并且没有dh-a参数，则A1＝unq(username-value)″：″unq(realm-value)″：″shared-key
其中，shared-key＝
如果″algorithm″指示″MD5″或没有带该参数，并且有dh-a参数，则A1＝unq(username-value)″：″unq(realm-value)″：″passwd″：″dh-a
其中，passwd＝
dh-a＝
如果″algorithm″指示″MD5-sess″，并且没有dh-a参数，则
A1＝MD5(unq(username-value)″：″unq(realm-value)
″：″shared-key)″：″unq(nonce-value)″：″unq(cnonce-value)
如果″algorithm″指示″MD5″或没有带该参数，并且有dh-a参数，则
A1＝MD5(unq(username-value)″：″unq(realm-value)
″：″passwd″：″dh-a)″：″unq(nonce-value)″：″unq(cnonce-value)
A2的算法如下：
如果″qop″指示″auth″，则A2＝Method″：″digest-uri-value
如果″qop″指示″auth-int″，则A2＝Method ″：″digest-uri-value ″：″MD5(entity-body)
如果SIP的消息体为空，则在RFC2617中定义的A2中使用的H(entity-body)采用如下的定义：
H(entity-body)＝MD5(″″)＝″d41d8cd98f00b204e9800998ecf8427e″
3、response-digest(响应摘要)的算法：
response-digest的算法与前面的request-digest算法相似，区别在于A2的计算：
如果Authorization和Proxy-Authorization头域中的″qop″指示″auth″，则A2＝″：″digest-uri-value
如果Authorization和Proxy-Authorization头域中的″qop″指示″auth-int″，则A2＝″：″digest-uri-value″：″MD5(entity-body)
如果SIP的消息体为空，则在RFC2617中定义的A2中使用的H(entity-body)采用如下的定义：
H(entity-body)＝MD5(″″)＝″d41d8cd98f00b204e9800998ecf8427e″
虽然通过实施例描绘了本发明，本领域普通技术人员知道，本发明有许多变形和变化而不脱离本发明的精神，希望所附的权利要求包括这些变形和变化而不脱离本发明的精神。
为了使本技术领域的人员更好地理解本发明，下面结合附图和实施方式对本发明作进一步的详细说明。
参照图2，图2是本发明方法的详细流程，包括以下步骤：
步骤201：客户端发送不带认证信息的请求消息到服务器端，请求接入。所述服务器端包括：代理服务器、背靠背服务器、重定向服务器和注册服务器。
步骤202：服务器端收到所述请求消息后根据用户名和初始密码生成服务器端DH认证响应信息。
步骤203：向客户端回送带有服务器端的认证交换信息及服务器端DH认证响应信息的响应消息。
步骤204：客户端根据服务器端的认证交换信息及本端的认证交换信息获取共享密钥。
步骤205：根据所述共享密钥生成客户端DH认证响应信息。
步骤206：客户端对收到的响应消息进行认证，认证通过后，发送带有客户端认证信息的请求消息到服务器端。所述带有客户端认证信息的请求消息包括：可选的客户端的认证交换信息、客户端DH认证响应信息。
步骤207：服务器端根据收到的请求消息对用户进行认证，并回送包含服务器端认证信息的响应消息。所述包含服务器端认证信息的响应消息包括：可选的DH认证信息头域。所述DH认证信息头域包括：服务器端的认证信息。
服务器端收到的请求消息有两种情况：该消息的头域中不包括客户端的认证交换信息；该消息的头域中包括客户端的认证交换信息。
当该消息的头域中不包括客户端的认证交换信息时，服务器端使用用户名和初始密码对收到的请求消息进行认证并根据所述用户名和初始密码生成所述服务器端DH认证响应信息。
当该消息的头域中不包括客户端的认证交换信息时，服务器端根据用户的认证交换信息以及本端的认证交换信息获取共享密钥，根据所述共享密钥对收到的请求消息进行认证，并根据所述共享密钥生成服务器端DH认证响应信息。
步骤208：用户根据收到的包含服务器端认证信息的响应消息验证所述服务器端的合法性。
上述过程结束后，也就是说在客户端和服务器端都获取共享密钥后，进行消息交互时，只使用所述共享密钥对所述消息进行加密。
参照图3，图3示出了本发明方法中用户接入时的消息流程：
对于UAS(服务器端)，如果需要认证UAC(客户端)，则必须发送401响应，并必须在其中携带WWW-Authenticate头域，在该头域中包含UAS的认证，以防止Middle-In-Man攻击。UAC可以再次发起请求，在Authorization头域中携带认证信息。Registrars(注册服务器)和Redirectserver(重定向服务器)也可以使用401响应来进行认证UAC。
对于Proxy(代理服务器)，如果需要认证UAC，则必须发送407响应，并必须在其中携带Proxy-Authenticate头域，在该头域中包含Proxy的认证，以防止Middle-In-Man攻击。UAC可以再次发起请求，在Proxy-Authorization头域中携带认证信息。
当UAC因为收到401或者407响应而重新发起请求时，一般应该使用相同的Call-ID，From头域和To头域，但是CSeq头域中的序数必须加一。
但是一个Server(UAS或者Proxy)不能向ACK(确认客户端已经接收到对INVITE的最终响应)请求和CANCEL请求发起认证。对于UAC而言，比较好的方式是在ACK消息中包含一个通过认证的认证信息，该认证信息包括Authorization和Proxy-Authorization头域，它是在和ACK对应的INVITE消息中携带的并已经通过UAS或Proxy认证。
为了防止Plain Text攻击，UAS或者Proxy应在认证的成功响应(200)中包含新增头域DH-Authentication-Info，在该新增头域中包含UAS或者Proxy的验证信息，UAC通过该信息验证UAS或者Proxy的合法性。
这可以是一个可选的特性，如果UAC和UAS或者Proxy间配置了必须包含DH-Authentication-Info，则可以实现UAC验证其接入的服务器的合法性。如果在200响应中没有包含DH-Authentication-Info或者验证失败，且在UAC和UAS或者Proxy间配置了必须要包含DH-Authentication-Info，则UAC可以认为这是某个恶意的服务器接收了消息，可以选择拒绝服务器。
在上述认证过程中，只在初始的认证过程中使用初始密钥Ki，而在以后的认证过程中都使用共享密钥Ks，对于图2中的消息而言，F2-F4所使用的密钥是Ki，而F6-F8使用的密钥是Ks。由于Ki只出现一次，所以可以有效地防止Plain Text和字典攻击。
下面详细说明本发明中的SIP头域中的扩展参数及新增的SIP头域：
本技术领域人员知道，在RFC3261中定义了四个头域，分别为：WWW-Authenticate，Proxy-Authenticate，Authorization，Proxy-Authorization，本发明即是在此基础上，通过对这四个头域中参数的扩展实现DH-Digest认证。
本发明中定义的头域如下：
1.WWW-Authenticate＝″WWW-Authenticate″HCOLON challenge
2.Proxy-Authenticate＝″Proxy-Authenticate″HCOLON challenge
其中，challenge＝(″Digest″|LWS digest-cln*(COMMA digest-cln))
/dh-challenge/other-challenge
dh-challenge＝(″DH-Digest″｜LWS digest-cln*(COMMA digest-cln))
other-challenge＝auth-scheme LWS auth-param*(COMMA auth-param)
digest-cln＝realm/domain/nonce/opaque/stale/algorithm
/qop-options/dh-b/dh-response-auth/auth-param
realm＝″realm″EQUAL realm-value
realm-value＝quoted-string
domain＝″domain″EQUAL LDQUOT URI*(1*SP URI)RDQUOT
URI＝absoluteURI/abs-path
nonce＝″nonce″EQUAL nonce-value
nonce-value＝quoted-string
opaque＝″opaque″EQUAL quoted-string
stale＝″stale″EQUAL(″true″/″false″)
algorithm＝″algorithm″EQUAL(″MD5″/″MD5-sess″/token)
qop-options＝″qop″EQUAL LDQUOT qop-value
*(″，″qop-value)RDQUOT
qop-value＝″auth″/″auth-int″/token
dh-b＝″DH-B″EQUAL dh-b-value
dh-b-value＝quoted-string
dh-response-auth＝″DH-Rspauth″EQUAL dh-response-digest
dh-response-digest＝LDQUOT 32LHEX RDQUOT
其中，带下划线部分为头域中新增的参数。
对上述WWW-Authenticate和Proxy-Authenticate头域中的参数说明如下：
realm：realm-value必须是一个全局唯一的字符串，并且全部由可显示的字符组成，用来呈现给用户，指示用户输入用户名及密码。
Domain：由双引号包含的一个或多个URI列表，表明在这些domain域中，可以使用同样的认证信息。该参数对Proxy-Authenticate头域无意义。
Nonce：nonce是由server提供的一串以16进制或base64表示的随机字符串。
Opaque：opaque是由server提供的一串以16进制或base64表示的随机字符串，客户端应不作任何改变，返回给server。
Stale：该参数是一个标志，有TRUE和FALSE两个值，用来指示前一个请求，由于nonce过期而导致的认证失败。当客户端收到的401/407中，该参数值为TRUE时，只需使用新的nonce，重新计算一次摘要即可，不需再要求用户输入用户名及密码。只有当server收到的request中nonce是过期的，但是该过期的nonce对应的摘要正确时(也就是说用户名和密码是正确的)，才可将该参数设置为TRUE。
Algorithm：用于指示两边计算摘要的算法，当没有该参数时，缺省为MD5算法。
qop-options：为了兼容RFC2069而引入的任选参数，用于指示server所能支持的″quality of protection″，可以带多个值，目前有两个取值：″auth″、″auth-int″(取值不同在加密算法上稍有不同)。具体使用方法参见后面的摘要计算方法。
dh-b：为了实现DH Digest而特别引入的一个参数，代表了UAS或者Proxy的DH交换数；通过此参数，UAC可以用来计算出共享密钥。
当scheme为DH-Digest，而且WWW-Authentication和Proxy-Authentication中不包含此dh-b时，则意味着UAS或者Proxy已经将db-b在以前的消息中发送给UAC了，当前的这次认证可以直接采用共享密钥，而不需要采用初始密钥(如果UAC不记得共享密钥，如重启后，也可以使用初始密钥进行认证)。当其中包含dh-b时，则表示UAS或者Proxy希望重新发起一次共享密钥的协商。
dh-response-auth：为了防止恶意服务器发起的401或者407响应，UAC需要对UAS或者Proxy发起的401或者407响应进行认证。UAS或者Proxy在发送401或者407响应时，必须采用初始密钥(当dh-b参数存在时)或者采用共享密钥(当不存在dh-b参数时)进行认证。
auth-param：该参数是为了将来扩展引入的。
3.Proxy-Authorization＝″Proxy-Authorization″HCOLON credentials
4.Authorization＝″Authorization″HCOLON credentials
其中，credentials＝(″Digest″LWS digest-response)
/dh-digest-response/other-response
digest-response＝dig-resp*(COMMA dig-resp)
dh-digest-response＝dig-resp*(COMMA dig-resp)
dig-resp＝username/realm/nonce/digest-uri
/dresponse/algorithm/cnonce
/opaque/message-qop
/nonce-count/dh-a/auth-param
username＝″username″EQUAL username-value
username-value＝quoted-string
digest-uri＝″uri″EQUAL LDQUOT digest-uri-value RDQUOT
digest-uri-value＝rquest-uri；Equal to request-uri as specified
by HTTP/1.1
message-qop＝″qop″EQUAL qop-value
cnonce＝″cnonce″EQUAL cnonce-value
cnonce-value＝nonce-value
nonce-count＝″nc″EQUAL nc-value
nc-value＝8LHEX
dresponse＝″response″EQUAL request-digest
request-digest＝LDQUOT 32LHEX RDQUOT
dh-a＝″DH-A″EQUAL dh-a-value
dh-a-value＝quoted-string
auth-param＝auth-param-name EQUAL(token/quoted-string)
auth-param-name＝token
other-response＝auth-scheme LWS auth-param*(COMMA auth-param)
auth-scheme＝token
其中，带下划线部分为头域中新增的参数。
对上述Authorization和Proxy-Authorization头域中的参数说明如下：
response：一个128比特的，由32个16进制数表示的字符串，它是由后面的公式计算而来的。
username：在指定的realm范围内的用户名。
digest-uri：与最初的Request-Line的Request-URI相同，之所以不直接使用请求消息中的Request-URI，是因为中间的proxy可能会修改Request-URI。
message-qop：为了兼容RFC2069而引入的任选参数，用于指示客户端所能支持的“quality of protection(保护质量)”，只能带一个值，且只能是server过来的qop中的一个值。它将影响对摘要的计算。WWW-Authenticate或Proxy-Authenticate头域中如果包含了qop参数，那么在Authorization或Proxy-Authorization头域中必须带此参数。
cnonce：如果WWW-Authenticate或Proxy-Authenticate头域中带了qop参数，那么在Authorization或Proxy-Authorization头域中必须带此参数，否则不需要带此参数。该参数由客户端给出，用于避免plain text攻击、提供message integrity protection、以及提供相互的认证。
cnonce-count：如果WWW-Authenticate或Proxy-Authenticate头域中带了qop参数，那么在Authorization或Proxy-Authorization头域中必须带此参数，否则不需要带此参数。该参数是一个16进制的计算器，用于计数客户端发出的包含nonce的请求消息个数。例如，对于server给定的一个nonce，客户端发出的第一个请求消息，该参数为“nc＝00000001”，server会保存自己的一份nc拷贝，这样server能对客户端发过来的该参数的值与自己保存的值进行比较，这样就可以判断是否受到了replay攻击。
dh-a：为了实现DH Digest而特别引入的一个参数，代表了UAC的DH交换数；通过此参数，UAS或者Proxy可以用来计算出共享密钥。
当Authorization和Proxy-Authorization头域中的scheme为“DH-Digest”，此时如果头域中包含了dh-a参数，则当前的这次认证是使用初始密钥进行加密的，此时不管Challenge(WWW-Authentication和Proxy-Authentication)中是否包含了dh-b参数，都应该使用初始密钥和dh-a的算法进行验证(这种情况可能发生在UAC重启后，发送新的请求，但是UAS或者Proxy并不知道UAC重启了，而仍然希望UAC使用共享密钥来进行验证，此时UAC可以忽略UAS或者Proxy希望通过共享密钥来加密的请求，而通过初始密钥来实现验证)；如果不包含dh-a参数，则意味着在以前的消息中UAC已经将dh-a发送给UAS或者Proxy了，当前的这次认证是使用共享密钥加密的。
根据Authentication-Info的ABNF定义不能扩展参数，所以在本发明中还新增加了一个头域DH-Authentication-Info。
5.DH-Authentication-Info＝″DH-Authentication-Info″HCOLON dh-ainfo*(COMMA dh-ainfo)
其中，
dh-ainfo＝nextnonce/message-qop/response-auth
/cnonce/nonce-count/dh-a
nextnonce＝″nextnonce″EQUAL nonce-value
response-auth＝″rspauth″EQUAL response-digest
response-digest＝LDQUOT*LHEX RDQUOT
对上述新增头域DH-Authentication-Info中的参数说明如下：
UAS或者Proxy可以利用该头域：
A、改变nonce，客户端收到带nextnonce参数的该头域后，如果要发送下一个请求，则应使用新的nonce进行计算，否则如果客户端仍使用老的nonce计算摘要，server会要求重新认证，并且带指示TRUE的stale参数。此时不需要包含dh-a参数。
B、UAS或Proxy向UAC认证自己，需要携带response-digest参数；此时如果包含了dh-a参数，则此response-digest是采用初始密钥进行加密的；如果没有携带dh-a参数，则此response-digest是采用的共享密钥进行加密的。
Nextnonce：该参数是server给出的客户端下一次发送请求消息时用的新nonce。
message-qop：该参数应与客户端发来的qop参数取相同的值，指示server计算response摘要时的″quality of protection″。
为了防止replay攻击，本发明方法规定在上述头域WWW-Authenticate，Proxy-Authenticate，Authorization，Proxy-Authorization使用中必须携带qop参数。
上述参数中涉及的加密算法如下：
1、dh-response-digest(DH响应摘要)的算法如下：
因为在WWW-Authenticate和Proxy-Authenticate中的qop是一个选项，可以包含auth或者auth-int等多种选择。所以在此强制规定，qop-value为只使用auth。
dh-response-digest＝<″>
″：″MD5(A2)
)<″>
其中，A1的算法如下：
如果″algorithm″指示″MD5″或没有带该参数，并且没有dh-b参数，则A 1＝unq(username-value)″：″unq(realm-value)″：″shared-key
其中，shared-key＝
如果″algorithm″指示″MD5″或没有带该参数，并且有dh-b参数，则A1＝unq(username-value)″：″unq(realm-value)″：″passwd″：″unq(dh-b)
其中，passwd＝
dh-b＝
如果″algorithm″指示″MD5-sess″，并且没有dh-b参数，则
A 1＝MD5(unq(username-value)″：″unq(realm-value)″：″shared-key)″：″unq(nonce-value))
如果″algorithm″指示″MD5″或没有带该参数，并且有dh-b参数，则A1＝MD5(unq(username-value)″：″unq(realm-value)″：″passwd″：″unq(dh-b))
A2的算法如下：
A2＝Method ″：″digest-uri-value
2、request-digest(请求摘要)的算法如下：
如果″qop″值为″auth″或″auth-int″，则
request-digest＝<″>
″：″unq(cnonce-value)
″：″unq(qop-value)
″：″MD5(A2)
)<″>
其中，A1的算法如下：
如果″algorithm″指示″MD5″或没有带该参数，并且没有dh-a参数，则A1＝unq(username-value)″：″unq(realm-value)″：″shared-key
其中，shared-key＝
如果″algorithm″指示″MD5″或没有带该参数，并且有dh-a参数，则A1＝unq(username-value)″：″unq(realm-value)″：″passwd″：″dh-a
其中，passwd＝
dh-a＝
如果″algorithm″指示″MD5-sess″，并且没有dh-a参数，则
A1＝MD5(unq(username-value)″：″unq(realm-value)
″：″shared-key)″：″unq(nonce-value)″：″unq(cnonce-value)
如果″algorithm″指示″MD5″或没有带该参数，并且有dh-a参数，则
A1＝MD5(unq(username-value)″：″unq(realm-value)
″：″passwd″：″dh-a)″：″unq(nonce-value)″：″unq(cnonce-value)
A2的算法如下：
如果″qop″指示″auth″，则A2＝Method″：″digest-uri-value
如果″qop″指示″auth-int″，则A2＝Method ″：″digest-uri-value ″：″MD5(entity-body)
如果SIP的消息体为空，则在RFC2617中定义的A2中使用的H(entity-body)采用如下的定义：
H(entity-body)＝MD5(″″)＝″d41d8cd98f00b204e9800998ecf8427e″
3、response-digest(响应摘要)的算法：
response-digest的算法与前面的request-digest算法相似，区别在于A2的计算：
如果Authorization和Proxy-Authorization头域中的″qop″指示″auth″，则A2＝″：″digest-uri-value
如果Authorization和Proxy-Authorization头域中的″qop″指示″auth-int″，则A2＝″：″digest-uri-value″：″MD5(entity-body)
如果SIP的消息体为空，则在RFC2617中定义的A2中使用的H(entity-body)采用如下的定义：
H(entity-body)＝MD5(″″)＝″d41d8cd98f00b204e9800998ecf8427e″
虽然通过实施例描绘了本发明，本领域普通技术人员知道，本发明有许多变形和变化而不脱离本发明的精神，希望所附的权利要求包括这些变形和变化而不脱离本发明的精神。