從多個應用環(huán)境和其部署優(yōu)勢來說，SBC是目前解決SIP安全問題最有效的手段。SBC作為一個網絡邊界安全控制手段，IPPBX部署在內網環(huán)境中，徹底將IPPBX的網絡拓撲隱藏在內網環(huán)境中。這樣就起到了安全的作用。因為SBC的部署，很多外網終端或者移動終端，如果需要呼叫內網的IPPBX時，SBC和下游的其他服務器就會對SIP用戶進行身份確認。通常情況下，SIP呼叫使用了 Authentication Digest 的方式來進行身份認證。
筆者在以前的文章中多次介紹了SBC的作用和其應用場景，和關于SBC部署協(xié)議的文章，讀者可以查閱。
目前使用SBC的場景很多，包括SIP trunk對接，遠端外網SIP終端注冊，呼叫，運營商之間的對接服務，IPPBX托管中心的SBC對接。因此，使用配置方式也有所不同，不同的配置需要不同的認證方式來實現。以下是幾個典型的示例：
運營商SIP trunk對接企業(yè)SBC
托管IPPBX通過SBC對接外網企業(yè)電話終端
運營商之間SBC對接
微軟365對接SBC
今天，我們針對外網呼叫環(huán)境中關于SBC和其他下游服務器的認證方式進行一個比較詳細的分析，希望幫助讀者能夠徹底了解SBC配合IPPBX進行身份認證的流程機制，以便能夠在SBC部署時能夠及時排查問題。
在下面的示例中，我們可以看到外網遠端用戶呼叫SBC，然后呼叫到企業(yè)內網IPPBX的典型示例（用戶可以下載免費FreeSBC在阿里云部署，并且配合IPPBX或者免費開源的freepbx實現外網注冊功能）：
在以上示例中，SBC部署在企業(yè)網絡的邊界處，內網IPPBX實現應用功能。但是，還有一些企業(yè)內網的部署環(huán)境，因為業(yè)務控制復雜的原因，可能增加了代理服務器的處理，然后下掛多個IPPBX。
簡單來說，在這種典型的外網呼叫的場景中，外網的SIP賬號首先需要對SBC發(fā)起一個INVITE，然后雙方通過Authentication Digest 認證確認。如果SBC通過了外網用戶Alice的呼叫認證，則SBC繼續(xù)對內網Proxy發(fā)送P-Asserted-Identity，然后IPPBX確認其身份以后，雙方SIP分機創(chuàng)建呼叫流程。為了說明以上示例的流程，我們會分步介紹每個階段使用的認證方式和SIP信令的處理。
1、Digest Authentication相關概念
在介紹整個SIP user authentication的處理機制之前，我們首先介紹幾個和認證相關的概念。這些概念可以幫助讀者能夠快速了解認證的基礎知識。SIP認證的方式場景有兩種，一種是代理，轉發(fā)服務或者注冊服務器對UA的認證；另外一種是UA之間的互相認證。
我們文章中使用的是Digest Authentication的認證機制，這種機制相對比較簡單，它基于HTTP的一種質疑/響應的模式。一方會對另一方發(fā)送質疑詢問，另外一方則通過響應的方式來應答核實其身份。
研究人員QiQiu的研究生文章Digest Authentication Report有關于認證流程和SIP學習的文章的介紹，讀者可以下載閱讀：
Digest Authentication Report
https://www.site.uottawa.ca/~bob/gradstudents/DigestAuthenticationReport.pdf
Digest Authentication使用了MD5 hash算法對用戶名稱，密碼，realm和Digest URL計算出一個哈希值，服務器端生成一個一次性的nonce，雙方對比最終的reponse值確認其身份。因為篇幅和內容重點不同，我們這里僅簡單介紹其背景基礎知識，RFC2069給出了非常完整的示例，讀者可以對其流程細節(jié)做進一步的了解。
關于如何計算這些哈希值，讀者可以通過很多網絡工具做計算，發(fā)布讀者在實際場景中能夠完整了解response的生成。示例是如何計算reponse值：
根據以上工具，在實際的SIP注冊消息中也同樣生成了和工具計算相同的值：
具體雙方生成生成響應的處理流程，讀者可以參考以下示例：
在Linux環(huán)境下，用戶可以使用MD5的命令來生成響應消息內容，工具也非常簡單易用：
在RFC2617中，為了增加安全認證的可靠性，支持了客戶端生成的nonce和QoP。具體的實現方式如下：
Response = MD5（H1 : nonce : nonceCount : nonceClient : QoP : H2）
筆者不是安全方面的專家，如果讀者想進一步學習關于SIP安全認證的相關話題，網絡上有很多關于SIP Digest 認證的討論和MD5安全分析，讀者可以參考相關鏈接來進一步學習。
2、SIP呼叫/SBC/Proxy/IPPBX流程
通過上一個章節(jié)對SIP認證的基本介紹和其認證機制的討論，讀者應該可以理解基本的認證原理。接下來，我們會比較詳細地結合實際的示例來進一步分析其細節(jié)過程。
這里提醒讀者，以上示例僅說明了身份認證機制的流程，并沒有包括我們具體討論的具體的其他部署的服務，例如SBC，代理和IPPBX等SIP服務器。具體的環(huán)境中，我們將涉及SBC，代理和IPPBX，也可能僅包括SBC和IPPBX本身。
在以上的示例中，首先外網SIP終端需要對SBC發(fā)起一個INVITE請求，SBC回復407或者401對其終端進行核實認證。外網SIP呼叫通過SBC認證后，SBC對Proxy發(fā)送認證P-Asserted-Identity，如果通過則繼續(xù)其他的流程，包括代理對終端的再次雙方確認和IPPBX對分機的身份確認等流程。這里，因為篇幅的關系，我們重點介紹外網SIP呼叫中SBC的身份認證過程，SBC對代理或IPPBX的P-Asserted-Identity身份確認，代理對SIP分機的認證機制。其他步驟基本上重復了代理對分機的認證流程，所以不再做過多討論。
接下來，我們就指定具體的關于外網SIP終端如何通過SBC呼叫內網IPPBX分機做一個詳細介紹。大家知道，SBC是對呼叫方身份認證的第一道防線。首先呼叫方對SBC發(fā)送INVITE，SBC返回407 帶nonce，僅支持本呼叫方，僅使用一次的驗證nonce。呼叫方收到以后，返回ACK。緊接著，使用這個nonce結合用戶名稱和密碼計算出response，SBC也同時計算出這個response。如果雙方的resposne一致，說明呼叫方可以通過SBC的身份驗證。下面的章節(jié)中，我們重點對外網呼叫SBC時的認證過程做一個討論。
3、外網SIP呼叫SBC端身份認證
在上面的介紹中，我們知道外網SIP分機如果呼叫企業(yè)邊界的SBC時，首先需要SBC對其身份進行核實認證。通過其身份認證機制，才能保證外網呼叫SBC是一個安全的呼叫，否則SBC不會允許外網的任何SIP終端呼叫內網的IPPBX，解決了內網的IPPBX的安全問題�，F在，讓我們看看外網SIP是如何一步步進行呼叫驗證，最終完成外網SIP分機和SBC之間的身份確認流程的。
首先，外網SIP分機呼叫SBC，SBC返回一個407 響應。這里的響應消息中攜帶了SBC生成的nonce值，結合外網SIP的realm等參數計算的結果。讀者一定要注意Proxy-Authenticate Digest中所包括對計算參數。
其次，外網SIP分機收到401或者407響應后，緊接著對SBC發(fā)送一個ACK，確認收到407響應。然后，SIP分機馬上對SBC再次發(fā)送一個新的INVITE請求（注意下面示例中的Call-ID是完全不同的ID），這次的請求中攜帶了SIP分機所生成的所有驗證的相關消息。這里，最重要的步驟是外網SIP分機根據SBC返回的nonce結合本地SIP賬號信息，使用MD5計算出的response。在INVITE中發(fā)送了生成的response結果。
最后，筆者在下圖中給出了SBC計算response的計算流程。在SBC邊界控制器中，SBC根據407的生成的nonce, 結合上次收到的用戶賬號消息，計算出SBC本地生成的response（42ceXXXX），然后對比SIP分機INVITE中包含的response（42ceXXXXX）結果，如果兩個結果是一樣的，說明外網SIP終端的呼叫身份是安全的，可以認為是成功的驗證，SBC則允許SIP呼叫通過SBC服務器端。
通過雙方response的結果對比，SBC確認了這個外網SIP呼叫的安全性，因此，SBC可以允許這個INVITE呼叫繼續(xù)進入到Proxy的節(jié)點上。
4、SBC到Proxy使用P-Asserted-Identity
根據上一節(jié)點介紹，SBC通過response的結果對比，確認了這個呼叫的身份，所以，SBC就會把這個請求繼續(xù)轉發(fā)到Proxy的處理中。這里筆者提醒讀者，一般來說，SBC的下游服務器可能直接面對的是IPPBX或其他SIP服務器，因為業(yè)務的關系，這里的示例中增加了Proxy的處理，事實上，SBC也可以直接面對IPPBX應用服務器。
盡管大部分情況下，內網的Proxy對SBC的身份是信任的。但是，因為SBC是一個網絡邊界設備，所以，Proxy很多情況下也需要對SBC發(fā)送過來的呼叫進行二次確認。在SBC對Proxy的身份確認中，通常SBC會對Proxy發(fā)送一個P-Asserted-Identity header參數，表示其SIP呼叫是從SBC過來的，對這個呼叫攜帶一個新的數值，SBC已經對其進行了身份確認，其用戶是可信任的，請求Proxy通過這個SIP呼叫的身份確認。Proxy看到是SBC過來的可信任的SIP呼叫，對比Proxy自己保存的AOR值，Proxy就會通過這個認證。
注意，這里的認證僅是Proxy對SBC的確認過程，并不能確認Proxy是絕對信任這個呼叫的，不是Proxy對外網SIP呼叫的認證。Proxy或者IPPBX還會繼續(xù)對SIP呼叫進行認證。在后續(xù)的內容中，我們繼續(xù)介紹Proxy對SIP呼叫的身份確認。
在前面的討論中，我們涉及了P-Asserted-Identity，一般的SBC都支持通過P-Asserted-Identity認證的方式。具體的官方定義如下（RFC3255-9.1）：
The P-Asserted-Identity header field is used among trusted SIP entities （typically intermediaries） to carry the identity of the user sending a SIP message as it was verified by authentication.
https://www.ietf.org/rfc/rfc3325.txt
P-Asserted-Identity不是一個標準的SIP core規(guī)范，它是一個私有的RFC3325。但是大部分的SBC設備軟件使用這個參數來確認SIP用戶的安全認證。另外，在很多配置場景中，我們可能會看到另外一個配置參數p-preferred-identity，它和P-Asserted-Identity有一些區(qū)別，很多讀者可能非常迷惑。關于兩者之間的區(qū)別，讀者可以查閱此鏈接：
http://www.sharetechnote.com/html/Handbook_IMS_SIP_Param_P_Prefered_Identity.html
以上兩種headers其實都來自于IMS規(guī)范中的P-CSCF SIP headers， SBC為了獲得很好的兼容性，當然也需要支持這些headers:
- P-Called-Party-ID Header
- P-Orig-CA Header
- P-Charging-Vector Header
- P-Charging-Function-Addresses Header
- P-Associated-URI Header
- P-Visited-Network-ID Header
- P-Access-Network-Info Header
- P-Preferred-Identity and P-Asserted-Identity Header
- P-Charge-Info Header
- P-Sig-Info Header
另外，關于P-Asserted-Identity的使用可以成為一個比較大的話題，很多技術論文專門對其使用場景有非常深入的討論，筆者水平有限，不能非常完整地給出這方面權威的結論。如果讀者有興趣做深入研究，可以查閱此論文：
Updates to Asserted Identity in the Session Initiation Protocol （SIP）
https://tools.ietf.org/id/draft-ietf-sipping-update-pai-08.html#rfc.section.3.1
5、Proxy對SIP呼叫地址的再次驗證
在以上的討論中，SBC通過了Proxy的認證，確認其呼叫是可信任的。但是，很多情況下，因為SBC和外網SIP呼叫都處于外網的邊界處，Proxy對外網進入到呼叫地址重新驗證。Proxy再次對SIP終端回復407，重新驗證。這次驗證的流程和SBC對SIP驗證的流程是一樣的，需要根據雙方生成的response來判斷SIP呼叫身份。
6、IPPBX對外網SIP呼叫的身份認證
根據以上幾個步驟的驗證，現在身份驗證流程可以繼續(xù)進行到IPPBX的節(jié)點上了。在上面的介紹中，Proxy需要再次確認外網的地址身份，再次對外網的呼叫重新經過407認證以后，SIP終端通過了認證。接下來，Proxy才會繼續(xù)對下游IPPBX發(fā)送INVITE請求，IPPBX可能根據自己本身的認證設置，再次對SIP呼叫進行407認證。所以，IPPBX需要重新對SIP終端結合本次呼叫，此用戶通過生成的nonce，再次進行雙方的response結果對比流程，重新執(zhí)行一次在Proxy認證時的流程。
其邏輯流程和上面的基本一樣，所以這里不再列出。以上示例僅簡單說明最后一步流程的處理方式。雙方通過了IPPBX端的認證。然后，IPPBX對雙方終端創(chuàng)建呼叫連接，雙方成功通話，到此，外網的SIP終端就可以和內網的SIP終端進行通話。一個完整的外網SIP呼叫通過SBC認證，IPPBX的認證的呼叫流程正式形成。
7、總結
在本次討論中，筆者專門針對外網SIP呼叫SBC和內網IPPBX的呼叫流程做了比較詳細地分析。首先，筆者介紹了SBC對SIP的407的認證機制和關于nonce和response，MD5的核實流程。然后，筆者再次介紹了SBC對內網Proxy通過P-Asserted-Identity頭聲明其用戶身份的機制，并且簡單介紹了關于P-CSCF SIP的幾個核心概念。接下來，筆者介紹了Proxy和IPPBX對SIP分機呼叫的407認證流程，最后，筆者介紹了IPPBX到內網終端的呼叫創(chuàng)建。
讀者可以看到，整個呼叫流程中，SBC扮演著核心身份認證的作用，它是SIP網絡環(huán)境中第一道安全機制，因此需要用戶特別注意。此外，因為環(huán)境配置的復雜性和外網用戶的身份和地址等問題，需要經過多次驗證才能完全保證外網呼叫的安全。
最后，SBC的配置場景很多，需要根據不同的場景做針對性的測試，因此，筆者僅說明了外網SIP呼叫的認證機制，其他方面的內容沒有過多涉及，希望讀者自己根據基本的機制做補充學習。當然，讀者也可以下載我們合作伙伴FreeSBC的免費SBC系統(tǒng)，在阿里云部署，并且結合自己的IPPBX直接對接測試。
參考資料：
https://www.vocal.com/sip-2/sip-user-authentication/
https://arxiv.org/ftp/arxiv/papers/1209/1209.1075.pdf
https://en.wikipedia.org/wiki/Challenge%E2%80%93response_authentication
https://github.com/miconda/md5ha1
https://allenluker.wordpress.com/2014/07/16/sip-digest-authentication-part-1-sip-registration-method/
https://www.sipsorcery.com/mainsite/Help/SIPPasswordSecurity
https://docs.telcobridges.com/tbwiki/FreeSBC:Remote_Workers
作者簡介
朱利中（james.zhu）先生供職于深圳星昊通科技有限公司，從事技術市場推廣工作。在Asterisk開源領域服務10年，在國外學習工作9年。先后任職于Digium亞太合作伙伴公司，OpenVOX，深圳鼎信通達有限公司。在2010年，朱利中和合作伙伴聯(lián)合發(fā)起舉辦了第一屆Asterisk中國官方大會，負責VOIP88 開源技術社區(qū)維護，并聯(lián)合發(fā)布了Elastix中文版本，個人翻譯發(fā)布了第一本FreePBX使用指南。 目前負責Sangoma 亞太地區(qū)的銷售和市場推廣工作。
作者簡介
朱利中（james.zhu）先生供職于深圳星昊通科技有限公司，從事技術市場推廣工作。在Asterisk開源領域服務10年，在國外學習工作9年。先后任職于Digium亞太合作伙伴公司，OpenVOX，深圳鼎信通達有限公司。在2010年，朱利中和合作伙伴聯(lián)合發(fā)起舉辦了第一屆Asterisk中國官方大會，負責VOIP88 開源技術社區(qū)維護，并聯(lián)合發(fā)布了Elastix中文版本，個人翻譯發(fā)布了第一本FreePBX使用指南。 目前負責Sangoma 亞太地區(qū)的銷售和市場推廣工作。
關注微信公眾號：asterisk-cn，獲得有價值的Asterisk行業(yè)分享
Asterisk freepbx 中文官方論壇：http://bbs.freepbx.cn/forum.php
Asterisk freepbx技術文檔： www.freepbx.org.cn
融合通信商業(yè)解決方案，協(xié)同解決方案首選產品：www.hiastar.com
Asterisk/FreePBX中國合作伙伴，官方qq技術分享群（3000千人）：589995817
Asterisk freepbx 中文官方論壇：http://bbs.freepbx.cn/forum.php
Asterisk freepbx技術文檔： www.freepbx.org.cn
融合通信商業(yè)解決方案，協(xié)同解決方案首選產品：www.hiastar.com
Asterisk/FreePBX中國合作伙伴，官方qq技術分享群（3000千人）：589995817
