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

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

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