摘  要： SIP協(xié)議是當(dāng)前IP電話中的主流協(xié)議，HTTP摘要認(rèn)證機(jī)制被很多SIP系統(tǒng)作為安全機(jī)制,，但存在客戶端不能認(rèn)證服務(wù)器端,，且不支持密鑰協(xié)商的缺陷,。為解決這一不足，提出了一種基于改進(jìn)的HTTP摘要認(rèn)證的SIP安全機(jī)制,，使得SIP安全解決方案更加完善,，部署更加靈活。
關(guān)鍵詞： SIP,；HTTP摘要認(rèn)證,；安全機(jī)制

SIP協(xié)議即會(huì)話發(fā)起協(xié)議[1]，是NGN網(wǎng)絡(luò)和3G網(wǎng)絡(luò)的核心協(xié)議,，目前在電信網(wǎng)絡(luò)中有著廣泛的應(yīng)用,。由于SIP協(xié)議的消息以文本方式編碼，容易閱讀解析,，并且SIP消息在開放式的IP網(wǎng)絡(luò)中傳輸,，SIP消息容易被攻擊者模仿、纂改,，然后加以非法利用,，最終導(dǎo)致賬號(hào)被盜用、業(yè)務(wù)失敗或被干擾,。目前很多SIP系統(tǒng)采用基于HTTP摘要認(rèn)證機(jī)制作為系統(tǒng)的安全解決方案[2-3],，但該機(jī)制有兩個(gè)主要的缺陷，即不能滿足客戶端認(rèn)證服務(wù)器端,，也不具有密鑰協(xié)商機(jī)制,。為能夠?qū)IP消息中的頭域進(jìn)行端到端的加密，本文提出了一種改進(jìn)的HTTP摘要認(rèn)證機(jī)制,，解決了基于HTTP摘要認(rèn)證的SIP安全機(jī)制的缺陷,。
1 基于HTTP摘要認(rèn)證的SIP安全機(jī)制
    HTTP摘要認(rèn)證機(jī)制解決了基本認(rèn)證機(jī)制密碼明文傳輸?shù)膯栴}，但同樣基于用戶名密碼體系,，并沒有建立初始用戶名密碼體系的機(jī)制[4],，SIP系統(tǒng)可以基于HTTP摘要認(rèn)證建立自己的安全機(jī)制。
1.1 認(rèn)證流程
    在基于HTTP摘要認(rèn)證的SIP安全機(jī)制中,，摘要認(rèn)證的架構(gòu)與HTTP摘要認(rèn)證的架構(gòu)非常相似,，特別是認(rèn)證模式、認(rèn)證參數(shù),、挑戰(zhàn),、域、域值和憑證的BNF都是一樣的,。兩者都是基于挑戰(zhàn)-響應(yīng)模式,。如果客戶端(UAC)發(fā)起的請求沒有包含認(rèn)證信息，則服務(wù)器(UAS或者Proxy)會(huì)向客戶端發(fā)起挑戰(zhàn),，挑戰(zhàn)信息包含在401/407響應(yīng)中,，客戶端收到挑戰(zhàn)后,，用ACK請求確認(rèn)挑戰(zhàn)，然后重新構(gòu)建包含認(rèn)證信息的請求,，服務(wù)器認(rèn)證成功后,，則接受此請求。SIP認(rèn)證對特定域有意義,，每個(gè)保護(hù)域都有自己的用戶名和密碼,，服務(wù)器在其挑戰(zhàn)中應(yīng)該包含域信息，提示客戶端提供此域的用戶名和密碼信息,。
1.2 存在的缺陷
    摘要認(rèn)證是基于預(yù)分配用戶名密碼的一種認(rèn)證機(jī)制,，主要目的是替代基本認(rèn)證，避免密碼在網(wǎng)絡(luò)中明文傳輸,。摘要認(rèn)證機(jī)制可以解決注冊劫持,、請求欺騙、重放攻擊,、篡改消息等安全問題,，同時(shí)還能提供一定的完整性保護(hù)[5]。
    摘要認(rèn)證的缺陷主要有：(1)沒有提出完備的雙方認(rèn)證機(jī)制,，即UAC不能對PROXY和UAS進(jìn)行認(rèn)證,，容易遭受偽裝服務(wù)器攻擊；(2)沒有密鑰協(xié)商機(jī)制,，不能協(xié)商私密密鑰，然后對SIP指定頭域進(jìn)行加密,，避免信息泄漏,。
2 基于改進(jìn)的HTTP摘要認(rèn)證的SIP安全機(jī)制
    針對摘要認(rèn)證機(jī)制的兩點(diǎn)主要缺陷，經(jīng)過對摘要認(rèn)證機(jī)制的深入研究和實(shí)踐總結(jié),，論文提出了一種基于改進(jìn)的HTTP摘要認(rèn)證的SIP安全機(jī)制,。
2.1 改進(jìn)后的認(rèn)證流程
    呼叫建立的效率與信令的數(shù)量有關(guān)，在SIP協(xié)議上應(yīng)用認(rèn)證方案時(shí),，不能過多地引入信令流程,，從而較大程度地影響呼叫效率。因此改進(jìn)的認(rèn)證方案充分利用原有的認(rèn)證信令流程,，擴(kuò)充了4個(gè)SIP頭域：UAC-Authenticate,、UAC-Authorization、Encryption-Info,、Encrypted-Header,，實(shí)現(xiàn)了客戶端與服務(wù)器的雙向認(rèn)證和加密密鑰協(xié)商機(jī)制，而無需擴(kuò)充新的信令流程,。以INVITE請求為例,，改進(jìn)后的認(rèn)證流程如圖1所示,。

    由圖1可以看出，改進(jìn)的摘要認(rèn)證機(jī)制并沒有更改原有的信令流程,，而是通過擴(kuò)充SIP頭域來解決摘要認(rèn)證機(jī)制存在的主要缺陷,。
    UAC認(rèn)證UAS/PROXY的流程為：
    (1)UAC向服務(wù)器發(fā)起請求，若需要認(rèn)證服務(wù)器,，則在請求的UAC-Authenticate頭域中包含挑戰(zhàn)參數(shù),，向服務(wù)器發(fā)起挑戰(zhàn)；
    (2)服務(wù)器在收到含有挑戰(zhàn)信息的請求后,，如果是針對自己的挑戰(zhàn),，則獲取UAC的帳號(hào)密碼，連同挑戰(zhàn)參數(shù),，生成憑證,，并在401/407響應(yīng)的UAC-Authorization頭域中包含此憑證；
    (3)UAC在收到401/407響應(yīng)后,，驗(yàn)證響應(yīng)中包含的憑證,，如果有效則證明服務(wù)器知道自己的用戶名和密碼，可以進(jìn)行后續(xù)處理,。
    密鑰協(xié)商流程為：
    (1)服務(wù)器收到客戶端的請求后,，若配置了密鑰協(xié)商策略，則在401/407響應(yīng)的Encryption-Info頭域中提供自己的公鑰加密算法,、公鑰,、支持的對稱加密算法等信息；
    (2)UAC收到包含Encryption-Info頭域的401/407響應(yīng)時(shí),，根據(jù)自己的安全策略,，若支持改進(jìn)的摘要認(rèn)證機(jī)制，則通過ACK請求返回自己的對稱加密密鑰(用服務(wù)器提供的公鑰加密)和選擇的加密算法,；
    (3)在上述兩步中雙方建立了加密上下文,，UAC在再次發(fā)起的請求中可以對某些頭域進(jìn)行加密。
    值得說明的是,，一般SIP系統(tǒng)中服務(wù)器作為操作的主導(dǎo),，因此改進(jìn)的認(rèn)證機(jī)制在加密協(xié)商時(shí)，只能由服務(wù)器主動(dòng)發(fā)起協(xié)商,，同時(shí)為了能夠協(xié)商加密密鑰,，服務(wù)器需要有公鑰加密機(jī)制。
2.2 客戶端和服務(wù)器端操作規(guī)范
    類似IETF的RFC3261[1]文檔,，對于改進(jìn)的摘要認(rèn)證機(jī)制需要給出客戶端和服務(wù)器端的操作規(guī)范,，在此以INVITE請求為例，對客戶端和服務(wù)器端的操作規(guī)范進(jìn)行描述。
      客戶端操作規(guī)范：
      (1)根據(jù)安全策略配置,，如果需要對服務(wù)器端進(jìn)行認(rèn)證,，則在發(fā)送的INVITE消息中攜帶UAC-Authenticate頭域，包含要認(rèn)證的服務(wù)器端的URL(包含在digest-uri參數(shù)中),、username,、qop、nonce等參數(shù),。
      (2)在接收到服務(wù)器端返回的401/407(UAS返回401,，Proxy返回407)響應(yīng)后：
      ①如果響應(yīng)包含UAC-Authorization頭域，則計(jì)算憑證,，如果與服務(wù)器端返回的憑證相同,，則表明服務(wù)器端知道UAC的密碼，這樣就完成了對服務(wù)器端的認(rèn)證,。如果驗(yàn)證不通過,，則發(fā)送ACK對401/407響應(yīng)進(jìn)行確認(rèn)后，UAC不再發(fā)起新的請求,；
    ②如果響應(yīng)包含WWW-Authenticate/Proxy-Authenticate頭域,，則表明服務(wù)器端要求認(rèn)證UAC，緩存挑戰(zhàn)參數(shù)以在重新發(fā)起的請求中計(jì)算憑證,；
    ③如果響應(yīng)包含Encryption-Info頭域,，則表明服務(wù)器端發(fā)起加密協(xié)商請求，該頭域中包含服務(wù)器端的公鑰及其支持的加密算法等信息,。
    (3)UAC對401/407響應(yīng)發(fā)送ACK進(jìn)行確認(rèn),，如果401/407響應(yīng)中包含Encryption-Info頭域，且UAC也配置為支持加密協(xié)商,，則ACK請求中應(yīng)包含Encryption-Info頭域,，告知UAC隨機(jī)生成的加密私鑰(經(jīng)過服務(wù)器端的公鑰加密)和采用的加密算法。
    (4)UAC重新發(fā)起請求,，如果服務(wù)器端要求認(rèn)證UAC，則在新的請求中包含Authorization或者Proxy-Authorization頭域,，向服務(wù)器提供憑證,。如果之前成功地進(jìn)行了密鑰協(xié)商，則對需要加密的頭域可以用私密密鑰進(jìn)行加密,。
    服務(wù)器端操作規(guī)范：
    (1)若客戶端需要驗(yàn)證服務(wù)器端,，則服務(wù)器端在收到的第一個(gè)INVITE請求中包含UAC-Authenticate頭域，提供digest-uri,、username,、nonce、qop等挑戰(zhàn)參數(shù)；
    (2)根據(jù)認(rèn)證策略的配置,，服務(wù)器端在收到請求時(shí)做如下處理：
    ①如果請求包含UAC-Authenticate頭域,，且頭域中的digest-uri參數(shù)的指示是自身，表明UAC要認(rèn)證自己,，所以要計(jì)算憑證,，返回401/407響應(yīng)(憑證包含在UAC-Authorization頭域中)；
    ②如果請求中沒有包含UAC-Authenticate頭域,，則表明UAC并不想認(rèn)證自己,，如果服務(wù)器端不需要認(rèn)證UAC，繼續(xù)處理INVITE請求,；
    ③如果服務(wù)器端需要認(rèn)證UAC,，則返回401/407響應(yīng)，并在響應(yīng)中包含WWW-Authenticate/Proxy-Authenticate頭域,，提供挑戰(zhàn)信息,；
    ④如果服務(wù)器端配置了加密協(xié)商策略，則在收到UAC的請求后,，返回401/407響應(yīng),，在Encryption-Info頭域中包含自己的公鑰加密算法、公鑰和支持的加密算法,，向UAC提起加密協(xié)商挑戰(zhàn),。
    若客戶端與服務(wù)器端要求相互認(rèn)證，且服務(wù)器端配置了加密協(xié)商策略,，則在對客戶端請求的401/407響應(yīng)中就會(huì)同時(shí)包含UAC-Authorization,、Encryption-Info、WWW-Authenticate/Proxy-Authenticate頭域,。
    (3)接收到UAC對401/407響應(yīng)的ACK確認(rèn)消息后：
    ①如果ACK消息中包含Encryption-Info頭域,，則表明UAC支持加密協(xié)商，其中Encryption-Info頭域中包含UAC給定的加密私鑰(用服務(wù)器端的公鑰加密),、加密算法等信息,。服務(wù)器端應(yīng)該緩存Encryption-Info頭域的內(nèi)容，以用來處理后續(xù)的請求,；
    ②如果ACK消息中沒有包含Encryption-Info頭域,，則表明UAC不支持加密協(xié)商。
    (4)經(jīng)過密鑰協(xié)商后,，則后續(xù)消息的部分頭域在整個(gè)會(huì)話期間可能做了加密處理,，服務(wù)器端應(yīng)該先對加密的頭域進(jìn)行解密，然后驗(yàn)證UAC提供的憑證,。
2.3 擴(kuò)展頭域規(guī)范
    改進(jìn)的摘要認(rèn)證機(jī)制對SIP協(xié)議進(jìn)行了擴(kuò)展,，新增UAC-Authenticate,、UAC-Authorization、Encryption-Info,、Enc-
rypted-Header四個(gè)頭域,。
    其中UAC-Authenticate頭域的規(guī)范類似于WWW-Authenticate，而UAC-Authorization頭域規(guī)范類似于WWW-Authorization,，僅有部分區(qū)別,。
    Encryption-Info頭域攜帶了密鑰協(xié)商信息，服務(wù)器在401/407響應(yīng)中用此頭域告知客戶端服務(wù)器側(cè)使用的公鑰加密算法,、加密公鑰,，支持的對稱加密算法；客戶端在對401/407響應(yīng)的ACK請求中用此頭域告知服務(wù)器使用的對稱加密的私鑰以及選擇的加密算法,。該頭域規(guī)范如下：
    Encryption-Info="Encryption-Info"":" Encrypt-Info
    Encrypt-Info=1#(public-key| public-encrypt-algorithm|
encrypt-private-key | algorithm | [encrypt-param])
    public-key="public-key " "= " key-value
    key-value?= quoted-string
    public-encrypt-algorithm=" public-encrypt-algorithm "
"=" key-value
    encrypt-private-key="encrypt-private-key " "=" key-value
    algorithm="algorithm" "=" <"> 1# algorithm-value <">
    algorithm-value="DES" | "DEA" | token
    public-key參數(shù)由服務(wù)器端指定,，告知客戶端自己的公鑰。
    public-encrypt-algorithm參數(shù)由服務(wù)器給出,，指定了服務(wù)器使用的公鑰加密算法,。
    encrypt-private-key參數(shù)給出客戶端指定的對稱加密私鑰，用public-key參數(shù)中指定的公鑰加密后傳給服務(wù)器端,。
    algorithm參數(shù)列出了服務(wù)器端支持的對稱加密算法,；客戶端發(fā)送至服務(wù)器端的ACK消息中此參數(shù)應(yīng)為客戶端選定的加密算法，且此算法應(yīng)包含在服務(wù)器端支持的加密算法列表中,。
    Encrypted-Header頭域表示加密后的頭域,，其BNF范式如下：
    Encrypted-Header="Encrypted-Header"":" Encrypt-Value
    Encrypt-Value=quoted-string
    例如對頭域From:B<SIP:[email protected]>進(jìn)行加密，假設(shè)加密后該頭域成為：Encrypted-Header:8f831abf39815iodhe83d20acA2B,，當(dāng)對端收到有加密頭域的SIP消息時(shí),，首先對Encrypted-Header頭域進(jìn)行解密處理，還原出原有頭域,，然后進(jìn)行后續(xù)處理,。
    針對基于HTTP摘要認(rèn)證的SIP安全機(jī)制不能實(shí)現(xiàn)客戶端主動(dòng)認(rèn)證服務(wù)器端、可能受到偽裝服務(wù)器的安全威脅,，同時(shí)不能在客戶端和服務(wù)器端進(jìn)行密鑰協(xié)商來對部分頭域進(jìn)行必要的加密處理,，本文提出了一種改進(jìn)的HTTP摘要認(rèn)證機(jī)制，基于此機(jī)制的SIP安全方案不但能夠增加SIP系統(tǒng)的安全保護(hù)強(qiáng)度,，而且可以針對不同的安全級別靈活部署,。
參考文獻(xiàn)
[1] ROSENBERG J，SCHULZRINNE H,，CAMARILLO G,，et al. SIP：session initiation protocol,，IETF RFC3261[S].August 2002.
[2] 婁穎.SIP協(xié)議安全機(jī)制研究[J].廣東通信技術(shù),，2005，24(4)：5-8.
[3] 麋正琨.軟交換組網(wǎng)與業(yè)務(wù)[M].北京：人民郵電出版社，2005：473-510.
[4] FRANKS J,，BAKER P H,，HOSTETLER J，et al.HTTP  authentication：basic and digest access authentication,，IETF RFC2617[S].June 1999.
[5] QIU Q.Study of digest authentication for session initiation  protocol(SIP)[D].University of Ottawa,，December 2003.