CN1716953A - 会话初始协议认证的方法 - Google Patents
会话初始协议认证的方法 Download PDFInfo
- Publication number
- CN1716953A CN1716953A CNA2004100695100A CN200410069510A CN1716953A CN 1716953 A CN1716953 A CN 1716953A CN A2004100695100 A CNA2004100695100 A CN A2004100695100A CN 200410069510 A CN200410069510 A CN 200410069510A CN 1716953 A CN1716953 A CN 1716953A
- Authority
- CN
- China
- Prior art keywords
- information
- client
- server end
- authentication
- server
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
- H04L63/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1101—Session protocols
- H04L65/1104—Session initiation protocol [SIP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0838—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these
- H04L9/0841—Key agreement, i.e. key establishment technique in which a shared key is derived by parties as a function of information contributed by, or associated with, each of these involving Diffie-Hellman or related key agreement protocols
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/76—Proxy, i.e. using intermediary entity to perform cryptographic operations
Abstract
本发明公开了一种会话初始协议认证的方法,该方法包括:客户端发送不带认证信息的请求消息到服务器端,请求接入;服务器端收到所述请求消息后回送带有服务器端的认证交换信息及服务器端DH认证响应信息的响应消息;客户端对收到的响应消息进行认证,认证通过后,发送带有客户端认证信息的请求消息到服务器端;服务器端根据收到的请求消息对用户进行认证,并回送包含服务器端认证信息的响应消息;用户根据收到的包含服务器端认证信息的响应消息验证服务器端的合法性。利用本发明,可以有效地提高SIP认证的安全性。
Description
技术领域
本发明涉及网络安全技术领域,具体涉及一种会话初始协议认证的方法。
背景技术
随着互联网及下一代网络的发展,其方便的接入、逐步提高的接入速度、易于扩展的特性、以及丰富的业务功能,受到了运营商及用户的欢迎,但与此同时其安全性方面也逐步受到人们的关注。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)头域,而得出初始密钥,容易导致字典攻击。
发明内容
本发明的目的是提供一种会话初始协议认证的方法,以提高网络接入的安全性。
本发明的目的是通过以下技术方案实现的:
一种会话初始协议认证的方法,包括:
A、客户端发送不带认证信息的请求消息到服务器端,请求接入;
B、所述服务器端收到所述请求消息后回送带有服务器端的认证交换信息及服务器端DH认证响应信息的响应消息;
C、所述客户端对收到的响应消息进行认证,认证通过后,发送带有客户端认证信息的请求消息到服务器端;
D、所述服务器端根据收到的请求消息对所述用户进行认证,并回送包含服务器端认证信息的响应消息;
E、所述用户根据收到的所述包含服务器端认证信息的响应消息验证所述服务器端的合法性。
所述步骤B包括:服务器端根据用户名和初始密码生成所述服务器端DH认证响应信息。
所述带有客户端认证信息的请求消息包括:可选的客户端的认证交换信息、客户端DH认证响应信息。
所述步骤C包括:
C1、所述客户端根据所述服务器端的认证交换信息及本端的认证交换信息获取共享密钥;
C2、根据所述共享密钥生成所述客户端DH认证响应信息。
所述步骤D包括:
当所述带有客户端认证信息的请求消息的头域中不包括所述用户的认证交换信息时,所述服务器端使用用户名和初始密码对收到的请求消息进行认证;
当所述带有客户端认证信息的请求消息的头域中包括所述用户的认证交换信息时,所述服务器端根据所述用户的认证交换信息以及本端的认证交换信息获取共享密钥,根据所述共享密钥对收到的请求消息进行认证。
所述步骤D还包括:
当所述带有客户端认证信息的请求消息的头域中不包括所述用户的认证交换信息时,根据所述用户名和初始密码生成所述服务器端DH认证响应信息;
当所述带有客户端认证信息的请求消息的头域中包括所述用户的认证交换信息时,所述服务器端根据所述用户的认证交换信息以及本端的认证交换信息获取共享密钥,根据所述共享密钥生成服务器端DH认证响应信息。
所述包含服务器端认证信息的响应消息包括:可选的DH认证信息头域。
所述DH认证信息头域包括:服务器端的验证信息。
所述方法还包括:在所述客户端和所述服务器端都获取共享密钥后,进行消息交互时,只使用所述共享密钥对所述消息进行加密。
所述服务器端包括:代理服务器、背靠背服务器、重定向服务器和注册服务器。
由以上本发明提供的技术方案可以看出,本发明在现有SIP基本认证基础上,引入DH(Diffie-Hellman)算法,并对SIP头域及字段进行扩展,使初始密钥只在第一次交互中使用,在其他的认证过程中使用共享密钥,使初始密钥得到了充分的保护,可以有效地防止字典攻击;同时,当任何一方重启后或者希望更换共享密码时,也可以重新启用校验初始密码的方式,通过使用认证次数计数器,有效地防止向UAS或者Proxy的replay(重发)攻击。利用本发明,可以大大提高网络的安全性。
附图说明
图1是现有技术中SIP的认证流程;
图2是本发明会话初始协议认证的方法的流程图;
图3是本发明方法中用户接入时的消息流程图。
具体实施方式
本发明的核心在于在现有SIP基本认证基础上,引入DH算法,并对SIP头域及字段进行扩展,不仅对用户的请求消息发起认证,而且对服务器端的响应消息也提供相应的认证机制,以便有效地防止对用户发起的Plain Text;同时,在本发明方法中,初始密码只在第一次交互中使用,后续的认证过程都通过共享密码来加密,以便有效地防止字典攻击,而且,当任何一方重启后或者希望更换共享密码时,也可以重新启用校验密码的方式,以便有效地防止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=<″><MD5(MD5(A1),unq(nonce-value)
″:″unq(qop-value)
″:″MD5(A2)
)<″>
其中,A1的算法如下:
如果″algorithm″指示″MD5″或没有带该参数,并且没有dh-b参数,则A 1=unq(username-value)″:″unq(realm-value)″:″shared-key
其中,shared-key=<shared key calculated by dh-a and dh-b>
如果″algorithm″指示″MD5″或没有带该参数,并且有dh-b参数,则A1=unq(username-value)″:″unq(realm-value)″:″passwd″:″unq(dh-b)
其中,passwd=<user′s password>
dh-b=<dh-b-value>
如果″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=<″><MD5(MD5(A1),unq(nonce-value)
″:″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=<shared key calculated by dh-a and dh-b>
如果″algorithm″指示″MD5″或没有带该参数,并且有dh-a参数,则A1=unq(username-value)″:″unq(realm-value)″:″passwd″:″dh-a
其中,passwd=<user′s password>
dh-a=<dh-a-value>
如果″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″
虽然通过实施例描绘了本发明,本领域普通技术人员知道,本发明有许多变形和变化而不脱离本发明的精神,希望所附的权利要求包括这些变形和变化而不脱离本发明的精神。
Claims (10)
1、一种会话初始协议认证的方法,其特征在于,所述方法包括:
A、客户端发送不带认证信息的请求消息到服务器端,请求接入;
B、所述服务器端收到所述请求消息后回送带有服务器端的认证交换信息及服务器端DH认证响应信息的响应消息;
C、所述客户端对收到的响应消息进行认证,认证通过后,发送带有客户端认证信息的请求消息到服务器端;
D、所述服务器端根据收到的请求消息对所述用户进行认证,并回送包含服务器端认证信息的响应消息;
E、所述用户根据收到的所述包含服务器端认证信息的响应消息验证所述服务器端的合法性。
2、根据权利要求1所述的会话初始协议认证的方法,其特征在于,所述步骤B包括:服务器端根据用户名和初始密码生成所述服务器端DH认证响应信息。
3、根据权利要求1所述的会话初始协议认证的方法,其特征在于,所述带有客户端认证信息的请求消息包括:可选的客户端的认证交换信息、客户端DH认证响应信息。
4、根据权利要求3所述的会话初始协议认证的方法,其特征在于,所述步骤C包括:
C1、所述客户端根据所述服务器端的认证交换信息及本端的认证交换信息获取共享密钥;
C2、根据所述共享密钥生成所述客户端DH认证响应信息。
5、根据权利要求3所述的会话初始协议认证的方法,其特征在于,所述步骤D包括:
当所述带有客户端认证信息的请求消息的头域中不包括所述客户端的认证交换信息时,所述服务器端使用用户名和初始密码对收到的请求消息进行认证;
当所述带有客户端认证信息的请求消息的头域中包括所述客户端的认证交换信息时,所述服务器端根据所述客户端的认证交换信息以及本端的认证交换信息获取共享密钥,根据所述共享密钥对收到的请求消息进行认证。
6、根据权利要求3所述的会话初始协议认证的方法,其特征在于,所述步骤D还包括:
当所述带有客户端认证信息的请求消息的头域中不包括所述客户端的认证交换信息时,根据所述用户名和初始密码生成所述服务器端DH认证响应信息;
当所述带有客户端认证信息的请求消息的头域中包括所述客户端的认证交换信息时,所述服务器端根据所述客户端的认证交换信息以及本端的认证交换信息获取共享密钥,根据所述共享密钥生成服务器端DH认证响应信息。
7、根据权利要求1或3所述的会话初始协议认证的方法,其特征在于,所述包含服务器端认证信息的响应消息包括:可选的DH认证信息头域。
8、根据权利要求7所述的会话初始协议认证的方法,其特征在于,所述DH认证信息头域包括:服务器端的认证信息。
9、根据权利要求6所述的会话初始协议认证的方法,其特征在于,所述方法还包括:在所述客户端和所述服务器端都获取共享密钥后,进行消息交互时,只使用所述共享密钥对所述消息进行加密。
10、根据权利要求1所述的会话初始协议认证的方法,其特征在于,所述服务器端包括:代理服务器、背靠背服务器、重定向服务器和注册服务器。
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2004100695100A CN1716953B (zh) | 2004-06-28 | 2004-06-28 | 会话初始协议认证的方法 |
EP05752252A EP1758324B1 (en) | 2004-06-28 | 2005-06-08 | The session initial protocol identification method |
PCT/CN2005/000806 WO2006000144A1 (fr) | 2004-06-28 | 2005-06-08 | Procede d'identification de protocole initial de session |
US11/578,611 US7992000B2 (en) | 2004-06-28 | 2005-06-08 | Session initial protocol identification method |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN2004100695100A CN1716953B (zh) | 2004-06-28 | 2004-06-28 | 会话初始协议认证的方法 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN1716953A true CN1716953A (zh) | 2006-01-04 |
CN1716953B CN1716953B (zh) | 2010-09-15 |
Family
ID=35781562
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN2004100695100A Active CN1716953B (zh) | 2004-06-28 | 2004-06-28 | 会话初始协议认证的方法 |
Country Status (4)
Country | Link |
---|---|
US (1) | US7992000B2 (zh) |
EP (1) | EP1758324B1 (zh) |
CN (1) | CN1716953B (zh) |
WO (1) | WO2006000144A1 (zh) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2008095444A1 (fr) * | 2007-02-01 | 2008-08-14 | Huawei Technologies Co., Ltd. | Procédé et système d'authentification d'utilisateur |
CN1913432B (zh) * | 2006-07-27 | 2010-10-06 | 华为技术有限公司 | 卡号业务使用sip鉴权的方法和系统 |
CN101155030B (zh) * | 2006-09-29 | 2010-10-06 | 维豪信息技术有限公司 | 基于注册鉴权的网络资源整合访问方法 |
CN101193089B (zh) * | 2006-11-20 | 2010-11-03 | 阿里巴巴集团控股有限公司 | 有状态会话系统及其实现方法 |
CN101471938B (zh) * | 2007-12-27 | 2012-06-20 | 华为技术有限公司 | 一种点对点p2p网络中的认证方法、系统和装置 |
CN101640669B (zh) * | 2008-07-29 | 2012-08-29 | 华为技术有限公司 | 一种sip策略控制认证的方法、系统和设备 |
Families Citing this family (15)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6735288B1 (en) * | 2000-01-07 | 2004-05-11 | Cisco Technology, Inc. | Voice over IP voice mail system configured for placing an outgoing call and returning subscriber to mailbox after call completion |
CN1716953B (zh) | 2004-06-28 | 2010-09-15 | 华为技术有限公司 | 会话初始协议认证的方法 |
US20070165582A1 (en) * | 2006-01-18 | 2007-07-19 | Puneet Batta | System and method for authenticating a wireless computing device |
US7596092B2 (en) * | 2006-02-02 | 2009-09-29 | Cisco Technology, Inc. | VoIP verifier |
US20090262724A1 (en) * | 2006-08-18 | 2009-10-22 | Nec Corporation | Proxy server, communication system, communication method and program |
EP2223460A4 (en) * | 2007-12-20 | 2011-12-28 | Bce Inc | NON-CONTACT LABEL WITH SIGNATURE AND ASSOCIATED APPLICATIONS |
US8689301B2 (en) * | 2008-09-30 | 2014-04-01 | Avaya Inc. | SIP signaling without constant re-authentication |
CA2747553C (en) | 2008-12-18 | 2016-06-07 | Sean Maclean Murray | Validation method and system for use in securing nomadic electronic transactions |
CA2729231C (en) * | 2008-12-18 | 2019-01-15 | Bce Inc. | Processing of communication device signatures for use in securing nomadic electronic transactions |
US8601591B2 (en) * | 2009-02-05 | 2013-12-03 | At&T Intellectual Property I, L.P. | Method and apparatus for providing web privacy |
CN102368728B (zh) * | 2011-09-20 | 2014-06-11 | 中国人民解放军国防科学技术大学 | 路由协议的自动配置方法及路由设备、授权服务器 |
US20150172324A1 (en) * | 2013-12-13 | 2015-06-18 | Alcatel-Lucent Usa Inc. | Authorized SIP Redirection |
US10771453B2 (en) * | 2017-01-04 | 2020-09-08 | Cisco Technology, Inc. | User-to-user information (UUI) carrying security token in pre-call authentication |
GB201809887D0 (en) * | 2018-06-15 | 2018-08-01 | Iothic Ltd | Decentralised authentication |
US11595375B2 (en) | 2020-04-14 | 2023-02-28 | Saudi Arabian Oil Company | Single sign-on for token-based and web-based applications |
Family Cites Families (12)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6512818B1 (en) * | 1999-11-17 | 2003-01-28 | Mci Worldcom, Inc. | Method and system for releasing a voice response unit from a protocol session |
US7024688B1 (en) * | 2000-08-01 | 2006-04-04 | Nokia Corporation | Techniques for performing UMTS (universal mobile telecommunications system) authentication using SIP (session initiation protocol) messages |
US6865681B2 (en) * | 2000-12-29 | 2005-03-08 | Nokia Mobile Phones Ltd. | VoIP terminal security module, SIP stack with security manager, system and security methods |
US7243370B2 (en) * | 2001-06-14 | 2007-07-10 | Microsoft Corporation | Method and system for integrating security mechanisms into session initiation protocol request messages for client-proxy authentication |
US7484240B2 (en) * | 2001-07-13 | 2009-01-27 | Nokia Corporation | Mechanism to allow authentication of terminated SIP calls |
US7269730B2 (en) * | 2002-04-18 | 2007-09-11 | Nokia Corporation | Method and apparatus for providing peer authentication for an internet key exchange |
US7246236B2 (en) * | 2002-04-18 | 2007-07-17 | Nokia Corporation | Method and apparatus for providing peer authentication for a transport layer session |
US6938090B2 (en) * | 2002-04-26 | 2005-08-30 | Nokia Corporation | Authentication and protection for IP application protocols based on 3GPP IMS procedures |
US7240366B2 (en) * | 2002-05-17 | 2007-07-03 | Microsoft Corporation | End-to-end authentication of session initiation protocol messages using certificates |
GB0219947D0 (en) * | 2002-08-28 | 2002-10-02 | Nokia Corp | Conferencing system |
US6788676B2 (en) * | 2002-10-30 | 2004-09-07 | Nokia Corporation | User equipment device enabled for SIP signalling to provide multimedia services with QoS |
CN1716953B (zh) | 2004-06-28 | 2010-09-15 | 华为技术有限公司 | 会话初始协议认证的方法 |
-
2004
- 2004-06-28 CN CN2004100695100A patent/CN1716953B/zh active Active
-
2005
- 2005-06-08 EP EP05752252A patent/EP1758324B1/en active Active
- 2005-06-08 US US11/578,611 patent/US7992000B2/en active Active
- 2005-06-08 WO PCT/CN2005/000806 patent/WO2006000144A1/zh not_active Application Discontinuation
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN1913432B (zh) * | 2006-07-27 | 2010-10-06 | 华为技术有限公司 | 卡号业务使用sip鉴权的方法和系统 |
CN101155030B (zh) * | 2006-09-29 | 2010-10-06 | 维豪信息技术有限公司 | 基于注册鉴权的网络资源整合访问方法 |
CN101193089B (zh) * | 2006-11-20 | 2010-11-03 | 阿里巴巴集团控股有限公司 | 有状态会话系统及其实现方法 |
WO2008095444A1 (fr) * | 2007-02-01 | 2008-08-14 | Huawei Technologies Co., Ltd. | Procédé et système d'authentification d'utilisateur |
US8276194B2 (en) | 2007-02-01 | 2012-09-25 | Huawei Technologies Co., Ltd. | Methods and systems for user authentication |
CN101471938B (zh) * | 2007-12-27 | 2012-06-20 | 华为技术有限公司 | 一种点对点p2p网络中的认证方法、系统和装置 |
CN101640669B (zh) * | 2008-07-29 | 2012-08-29 | 华为技术有限公司 | 一种sip策略控制认证的方法、系统和设备 |
Also Published As
Publication number | Publication date |
---|---|
EP1758324A4 (en) | 2007-07-18 |
EP1758324B1 (en) | 2012-12-19 |
CN1716953B (zh) | 2010-09-15 |
US7992000B2 (en) | 2011-08-02 |
WO2006000144A1 (fr) | 2006-01-05 |
EP1758324A1 (en) | 2007-02-28 |
US20070255952A1 (en) | 2007-11-01 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN1716953A (zh) | 会话初始协议认证的方法 | |
CN1701561A (zh) | 基于地址的验证系统及其装置和程序 | |
CN1751533A (zh) | 在移动无线电系统中形成和分配加密密钥的方法和移动无线电系统 | |
CN100338597C (zh) | 信息处理设备和方法 | |
CN101051898A (zh) | 无线网络端到端通信认证方法及其装置 | |
CN1748207A (zh) | 信息处理装置、信息处理方法和计算机程序 | |
CN1767435A (zh) | 数据通信方法和系统 | |
CN1457170A (zh) | 公钥证明书发行装置 | |
CN1969501A (zh) | 安全地产生共享密钥的系统和方法 | |
CN1901448A (zh) | 通信网络中接入认证的系统及实现方法 | |
CN1759564A (zh) | 访问控制处理方法 | |
CN1631000A (zh) | 因特网上用于安全内容递送的密钥管理协议与认证系统 | |
CN100337175C (zh) | 移动终端加入域和获取版权对象的方法、系统和相关设备 | |
CN1521978A (zh) | 与异类联合体环境中验证声明相关的拥有证明操作用方法和系统 | |
CN1268088C (zh) | 基于pki的vpn密钥交换的实现方法 | |
CN1859729A (zh) | 一种鉴权方法及相应的信息传递方法 | |
CN1832397A (zh) | 电子设备接口间基于公钥证书的认证密钥协商和更新方法 | |
CN1906883A (zh) | 实现基于无状态服务器的预共享私密 | |
CN1685306A (zh) | 打印系统、打印装置及打印指示方法 | |
CN1681238A (zh) | 用于加密通信的密钥分配方法及系统 | |
CN1859093A (zh) | 在ip多媒体子系统中认证用户终端的方法 | |
CN1452356A (zh) | 公开密钥证书提供装置 | |
CN1701573A (zh) | 远程访问虚拟专用网络中介方法和中介装置 | |
CN101064628A (zh) | 家庭网络设备安全管理系统及方法 | |
CN1689367A (zh) | 安全装置的安全和保密性增强 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C14 | Grant of patent or utility model | ||
GR01 | Patent grant | ||
TR01 | Transfer of patent right |
Effective date of registration: 20211222 Address after: 450046 Floor 9, building 1, Zhengshang Boya Plaza, Longzihu wisdom Island, Zhengdong New Area, Zhengzhou City, Henan Province Patentee after: Super fusion Digital Technology Co.,Ltd. Address before: 518129 intellectual property department, F1-18 building, research center of Bantian HUAWEI headquarters, Longgang District, Shenzhen, Guangdong Patentee before: HUAWEI TECHNOLOGIES Co.,Ltd. |
|
TR01 | Transfer of patent right |