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

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

    由圖1可以看出,，改進的摘要認證機制并沒有更改原有的信令流程，而是通過擴充SIP頭域來解決摘要認證機制存在的主要缺陷,。
    UAC認證UAS/PROXY的流程為：
    (1)UAC向服務(wù)器發(fā)起請求,，若需要認證服務(wù)器，則在請求的UAC-Authenticate頭域中包含挑戰(zhàn)參數(shù),，向服務(wù)器發(fā)起挑戰(zhàn)；
    (2)服務(wù)器在收到含有挑戰(zhàn)信息的請求后,，如果是針對自己的挑戰(zhàn),，則獲取UAC的帳號密碼，連同挑戰(zhàn)參數(shù),，生成憑證,，并在401/407響應(yīng)的UAC-Authorization頭域中包含此憑證；
    (3)UAC在收到401/407響應(yīng)后,，驗證響應(yīng)中包含的憑證,，如果有效則證明服務(wù)器知道自己的用戶名和密碼，可以進行后續(xù)處理,。
    密鑰協(xié)商流程為：
    (1)服務(wù)器收到客戶端的請求后,，若配置了密鑰協(xié)商策略，則在401/407響應(yīng)的Encryption-Info頭域中提供自己的公鑰加密算法,、公鑰,、支持的對稱加密算法等信息；
    (2)UAC收到包含Encryption-Info頭域的401/407響應(yīng)時,，根據(jù)自己的安全策略,，若支持改進的摘要認證機制，則通過ACK請求返回自己的對稱加密密鑰(用服務(wù)器提供的公鑰加密)和選擇的加密算法,；
    (3)在上述兩步中雙方建立了加密上下文,，UAC在再次發(fā)起的請求中可以對某些頭域進行加密。
    值得說明的是,，一般SIP系統(tǒng)中服務(wù)器作為操作的主導(dǎo),，因此改進的認證機制在加密協(xié)商時，只能由服務(wù)器主動發(fā)起協(xié)商,，同時為了能夠協(xié)商加密密鑰,，服務(wù)器需要有公鑰加密機制。
2.2 客戶端和服務(wù)器端操作規(guī)范
    類似IETF的RFC3261[1]文檔,，對于改進的摘要認證機制需要給出客戶端和服務(wù)器端的操作規(guī)范,，在此以INVITE請求為例，對客戶端和服務(wù)器端的操作規(guī)范進行描述,。
      客戶端操作規(guī)范：
      (1)根據(jù)安全策略配置,，如果需要對服務(wù)器端進行認證,，則在發(fā)送的INVITE消息中攜帶UAC-Authenticate頭域，包含要認證的服務(wù)器端的URL(包含在digest-uri參數(shù)中),、username,、qop、nonce等參數(shù),。
      (2)在接收到服務(wù)器端返回的401/407(UAS返回401,，Proxy返回407)響應(yīng)后：
      ①如果響應(yīng)包含UAC-Authorization頭域，則計算憑證,，如果與服務(wù)器端返回的憑證相同,，則表明服務(wù)器端知道UAC的密碼，這樣就完成了對服務(wù)器端的認證,。如果驗證不通過,，則發(fā)送ACK對401/407響應(yīng)進行確認后，UAC不再發(fā)起新的請求,；
    ②如果響應(yīng)包含WWW-Authenticate/Proxy-Authenticate頭域,，則表明服務(wù)器端要求認證UAC，緩存挑戰(zhàn)參數(shù)以在重新發(fā)起的請求中計算憑證,；
    ③如果響應(yīng)包含Encryption-Info頭域,，則表明服務(wù)器端發(fā)起加密協(xié)商請求，該頭域中包含服務(wù)器端的公鑰及其支持的加密算法等信息,。
    (3)UAC對401/407響應(yīng)發(fā)送ACK進行確認,，如果401/407響應(yīng)中包含Encryption-Info頭域，且UAC也配置為支持加密協(xié)商,，則ACK請求中應(yīng)包含Encryption-Info頭域,，告知UAC隨機生成的加密私鑰(經(jīng)過服務(wù)器端的公鑰加密)和采用的加密算法。
    (4)UAC重新發(fā)起請求,，如果服務(wù)器端要求認證UAC,，則在新的請求中包含Authorization或者Proxy-Authorization頭域，向服務(wù)器提供憑證,。如果之前成功地進行了密鑰協(xié)商,，則對需要加密的頭域可以用私密密鑰進行加密。
    服務(wù)器端操作規(guī)范：
    (1)若客戶端需要驗證服務(wù)器端,，則服務(wù)器端在收到的第一個INVITE請求中包含UAC-Authenticate頭域,，提供digest-uri、username,、nonce,、qop等挑戰(zhàn)參數(shù)；
    (2)根據(jù)認證策略的配置,，服務(wù)器端在收到請求時做如下處理：
    ①如果請求包含UAC-Authenticate頭域,，且頭域中的digest-uri參數(shù)的指示是自身,，表明UAC要認證自己，所以要計算憑證,，返回401/407響應(yīng)(憑證包含在UAC-Authorization頭域中),；
    ②如果請求中沒有包含UAC-Authenticate頭域，則表明UAC并不想認證自己,，如果服務(wù)器端不需要認證UAC,，繼續(xù)處理INVITE請求；
    ③如果服務(wù)器端需要認證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ù)器端要求相互認證，且服務(wù)器端配置了加密協(xié)商策略,，則在對客戶端請求的401/407響應(yīng)中就會同時包含UAC-Authorization,、Encryption-Info、WWW-Authenticate/Proxy-Authenticate頭域,。
    (3)接收到UAC對401/407響應(yīng)的ACK確認消息后：
    ①如果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ù)消息的部分頭域在整個會話期間可能做了加密處理,，服務(wù)器端應(yīng)該先對加密的頭域進行解密，然后驗證UAC提供的憑證,。
2.3 擴展頭域規(guī)范
    改進的摘要認證機制對SIP協(xié)議進行了擴展,，新增UAC-Authenticate、UAC-Authorization,、Encryption-Info,、Enc-
rypted-Header四個頭域,。
    其中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]>進行加密，假設(shè)加密后該頭域成為：Encrypted-Header:8f831abf39815iodhe83d20acA2B,，當對端收到有加密頭域的SIP消息時,，首先對Encrypted-Header頭域進行解密處理，還原出原有頭域,，然后進行后續(xù)處理,。
    針對基于HTTP摘要認證的SIP安全機制不能實現(xiàn)客戶端主動認證服務(wù)器端、可能受到偽裝服務(wù)器的安全威脅,，同時不能在客戶端和服務(wù)器端進行密鑰協(xié)商來對部分頭域進行必要的加密處理,，本文提出了一種改進的HTTP摘要認證機制，基于此機制的SIP安全方案不但能夠增加SIP系統(tǒng)的安全保護強度,，而且可以針對不同的安全級別靈活部署,。
參考文獻
[1] ROSENBERG J，SCHULZRINNE H,，CAMARILLO G,，et al. SIP：session initiation protocol，IETF RFC3261[S].August 2002.
[2] 婁穎.SIP協(xié)議安全機制研究[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.