最新支持SIP協議的認證籤權機制-RFC8898中文詳解

SIP協議或者IP網絡技術中,SIP協議的處理包括認證和服務器端的籤權處理都使用的是RFC3261中的HTTP的 Basic處理框架。隨著新技術不斷髮展,特別是基於容器和APP端的發展,一些認證籤權機制在存儲處理方面存在的問題也不斷湧現,例如SIP的認證問題。具體關於HTTP和Bearer的討論讀者可以參考網絡資料和參考鏈接或者查看RFC6750關於Bearer的使用規範。為了更好滿足SIP端和各種服務器端部署形式,在最近關於SIP認證框架的處理機制方面,一些RFC成員提出了使用Bearer令牌機制來對SIP驗證和SIP註冊籤權的處理框架-RFC8898.此協議給出了SIP在認證和籤權使用的Bearer令牌做了一個比較基本的定義規範。


RFC 8898-Third-Party Token-Based Authentication and Authorization for Session Initiation Protocol (SIP)

因為此規範的發佈可能會影響到SIP協議的支持和一些技術方面的演進,雖然,目前的規範內容仍然不是非常具體,框架仍然比較寬泛,但是,筆者認為有必要針對此指導規範做一個概要說明,以便在SIP網絡的未來技術部署時可以作為一個有價值的參考,一些SIP解決方案廠家可以通過此規範重新設計自己的解決方案。

最新支持SIP協議的認證籤權機制-RFC8898中文詳解

思科基於OAuth設計的融合通信平臺


在RFC8898中,規範主要介紹了關於Bearer 令牌的機制要和基於第三方的針對SIP用戶認證和註冊籤權處理說明(使用OAuth 2.0 framework和 OpenID Connect Core 1.0)。


介紹

RFC8898中,SIP協議使用OAuth 2.0框架作為認證機制對SIP用戶進行認證處理,對SIP註冊進行籤權進行處理。OAuth 2.0使用基於令牌的框架支持OAuth客戶端對用戶的資源訪問。OpenID Connect Core規範在OAuth協議基礎上規定了一個簡單的身份確認層,它支持OAuth/OpenID客戶端對基於認證機制的用戶身份確認。驗證機制是專門的第三方授權服務器來(authorization server,簡稱AS)執行,例如OpenID 提供方(OP),同時可獲得用戶的基本信息內容。

在本規範中,用戶籤權的處理可以支持單個用戶登錄,一旦用戶通過認證,它可以訪問SIP和非SIP服務資源。


此規範同時更新了RFC3261中的一些流程,通過定義UAC流程實現了更新。當UAC通過multiple WWW-Authenticate/Proxy-Authenticate 頭文件獲得401/407響應時,同時對同樣的realm會使用不同的認證機制進行查詢處理。

在RFC8898中,令牌有不同的類型和格式。在第三方的授權服務器中使用的令牌類型取決於授權服務器的類型。OAuth AS可以對一個成功授權的UAC提供以下令牌:

  • Access Token: UAC將使用此令牌(此令牌由SIP服務器提供)訪問SIP服務器資源。
  • Refresh Token:UAC防止使用此令牌對授權服務器刷新過時令牌。


RFC8898中支持兩種令牌,兩種格式分別為:

  • Structured Token:結構化的令牌由一些具體對象構成,包括其和聲明關聯的令牌,例如JSON格式,具體定義在RFC7519。
  • Reference Token:此令牌有一個非透明的字符串構成,它用來獲得令牌的細節,和其聲明關聯。具體規範在RFC6749中定義。


在RFC8898中的關於SIP註冊的流程中,認證機制可以通過授權服務器(AS/OP)對註冊請求進行籤權處理。在響應消息中401或者407中的頭消息文件使用Bearer機制。SIP通過AS/OP進行註冊處理的具體的示例如下:

最新支持SIP協議的認證籤權機制-RFC8898中文詳解

UAC通過AS/OP實現註冊流程示例

在以上的處理流程中,UAC實現註冊需要經過七個步驟

  1. UAC對註冊服務發送一個註冊請求,無任何安全設置信息。
  2. 註冊服務對UAC返回一個響應消息401,並且攜帶Bearer處理機制所要求的驗證消息和AS服務器地址等。
  3. UAC直接通過AS/OP直接和授權服務器進行通信,它們雙方通過約定的機制進行處理,例如使用OAuth Aative App機制(在RFC8252定義)。AS服務器對UAC進行認證處理,然後對UAC提供一個令牌,UAC可使用此令牌訪問SIP服務資源。
  4. UAC提供AS獲得的令牌消息,然後和註冊服務器進行提醒註冊請求。註冊請求中包含從AS獲得的令牌信息。
  5. 註冊服務通過UAC的令牌對AS要求進行驗證處理。如果此令牌是一個參考令牌,授權服務器可能對令牌執行自檢處理,這個自檢處理由RFC7662定義。
  6. 自檢處理成功以後,AS對註冊服務返回一個200 OK。
  7. 最後註冊服務對UAC返回一個 200 OK。


如果UAC已經預設了AS服務器端的信息的話。處理流程相對比較簡單,UAC獲得訪問令牌即可。

最新支持SIP協議的認證籤權機制-RFC8898中文詳解


SIP UA中Bearer機制的處理

和RFC3261中關於Digest認證的處理流程一樣,使用Bearer機制時,SIP UAC,UAS和代理也需要經過多種處理流程。下面筆者分別介紹關於在UAC,UAS和代理的處理流程中關於Bearer框架的使用方式。

UAC端的處理包括:獲得令牌和對查詢的響應處理,保護令牌訪問,註冊請求和非註冊請求的處理。


根據UAC通過AS/OP實現註冊流程示例,在獲得令牌和對查詢的響應處理過程中,當UAC在無安全信息對服務器發送請求時,UAC可能收到一個401(Unauthorized)或者407(Proxy Authentication Required)未授權訪問的響應。在其響應消息中,401會攜帶WWW-Authenticate 頭,407會攜帶一個Proxy-Authenticate 頭。在頭中會指示認證機制使用Bearer,並且包含機制的詳細消息,例如AS服務器地址。通過前面所說的第二步和第三步獲得令牌的信息。為了獲取到令牌信息,UAC必須檢查在401或者407響應中獲得的AS的地址,通過對照檢查一組可信任的AS地址獲得令牌訪問的安全有效地址,這樣的檢查也是為了防止UAC盲目綁定其他AS資源時的針對AS地址的安全漏洞,防止訪問一些過期的或非安全保護的AS地址。關於OAuth2的處理流程不在本規範說明的範圍,讀者可以查閱RFC8552和其他相關的規範來進一步學習。


獲取到令牌以後,令牌就會返回到UAC端。返回UAC的令牌的類型取決於授權服務器AS的類型。OAuth AS提供訪問令牌和刷新令牌(可選)。其中,刷新令牌主要應用於UAC和AS之間。如果AS對UAC端提供了刷新令牌的話,UAC可使用此刷新令牌在當前訪問令牌到期之前對AS請求一個新的訪問令牌。如果AS沒有提供刷新令牌的話,在當前訪問令牌到期之前,UAC需要重新對此用戶執行認證機制。OP返回一個額外的ID令牌,此ID令牌包含一個關於此用戶認證的聲明信息,此聲明信息是有授權服務器提供。ID令牌也可以包括其他關於此用戶的聲明信息,例如SIP URL,UAC可以使用此URL進行註冊流程處理。


如果UAC收到一個401或者407,此響應中包含多個WWW- Authenticate/Proxy-Authenticate頭的話,這些頭針對同一realm提供了不同的認證機制的話,UAC基於本地策略對其中一種機制提供安全信息。注意,在RFC8898發佈時,UAC收到多個認證頭的處理規範還沒有發佈,在未來的規範規定中可能會增加具體的處理機制。


令牌的安全是一個非常重要的問題。RFC6749強制規定了訪問令牌的安全策略,訪問令牌需要通過TLS進行加密處理。但是,一些讀者可能知道,如果SIP網絡使用了中間SIP代理服務器的話,當需要保護SIP信令時,TLS只能保證hop-to-hop之間的加密,簡單來說,就是保證兩個網絡跳轉的加密設置。因此,訪問令牌必須通過一種方式對其進行安全保護,以便實現僅授權的SIP服務器可訪問令牌。另外,當訪問令牌包含在SIP請求中時,除非有其他的加密方式可以保護訪問令牌,允許授權的服務器訪問令牌。否則的話,在支持RFC8898規範的SIP終端必須使用加密的JWTs方式對其進行編碼和保護。TLS也可以對SIP終端和AS之間的數據交換進行保護。


這裡,我們先討論一下注冊請求的處理流程。前面內容中我們已經簡單介紹瞭如何發送註冊請求的流程。UAC會根據收到的訪問令牌等消息對註冊服務器發送註冊請求。這裡要注意,如果收到了多個認證機制支持的話,UAC可能會通過一個非Bearer機制的方式,使用安全信息重新嘗試註冊。一般情況下,對於一個新的綁定關係來說,UAC會獲得一個新的訪問令牌。但是,因為可能支持本地策略設置,UAC可能會包含一個訪問令牌,此訪問令牌用來支持請求中同一AOR的其他的綁定關聯。如果包含在註冊請求中的訪問令牌沒有被接受,UAC收到了401或者407響應的話,UAC需要重新執行獲取令牌的流程。


前面我們討論了註冊請求的處理流程。如果是一個非註冊請求的話,UAC發送請求時必須包含一個Authorization 頭,在此頭中必須聲明Bearer機制。Bearer機制中包含一個有效的訪問令牌,此令牌是通過AS查詢請求中AS標識的訪問令牌。基於本地策略,如果新請求的目的地是同樣的,UAC可以包含一個訪問令牌,這個訪問令牌已在其他dialog或者其他獨立的請求中使用過的。如果包含在註冊請求中的訪問令牌沒有被接受,UAC收到了401或者407響應的話,UAC需要重新執行獲取令牌的流程。


討論了UAC端的處理以後,我們繼續討論UAS的處理。根據前面的註冊流程步驟的示例,當UAS或者註冊服務收到註冊請求,UAC沒有包含認證所需的安全信息以後,UAS/註冊服務應該回復UAC一個401響應。如果UAS/註冊服務驗證此請求,並且接受以訪問令牌的方式作為安全措施進行驗證的話,UAS或者註冊服務必須在返回的響應消息中包含一個WWW-Authenticate 頭,在此頭中標識出Bearer機制聲明,並且包含一個AS地址,此地址解析方式根據RFC7230規範解析。UAC將來會從此AS地址獲得訪問令牌。


當UAS或者註冊服務收到一個SIP請求,請求中包含Authorization頭,攜帶了訪問令牌的話,UAS或者註冊服務必須驗證訪問令牌,訪問令牌的驗證流程根據訪問令牌的類型進行不同的處理。具體關於訪問令牌的處理流程查閱RFC7519。如果請求中提供的令牌是一個過期的訪問令牌,UAS或者註冊服務必須對UAC回覆一個401響應。如果訪問令牌驗證成功通過對話,UAS或者註冊服務可以繼續執行其他接下來正常的SIP流程。如果訪問令牌驗證失敗,UAS或者註冊服務必須返回一個401響應。


前面,我們討論了UAC端和UAS端關於訪問令牌的處理流程。接下來,我們繼續討論關於SIP代理的處理流程。當SIP代理收到一個SIP請求,沒有攜帶任何安全信息時,SIP代理服務器應該返回一個407的響應消息(Proxy Authentication Required)。如果SIP代理服務器提供驗證服務,並且接受以訪問令牌的方式作為安全設置的話,SIP代理服務器應該在407的返回消息中包含一個Proxy-Authenticate頭,並且標識出Bearer機制和AS的訪問地址。此地址解析方式根據RFC7230規範解析。UAC將來會從此AS地址獲得訪問令牌。當SIP代理希望驗證收到的請求時,SIP代理服務器會查詢Proxy-Authorization中realm參數值來匹配其realm地址。代理服務器必須至少成功匹配一個Proxy-Authorization中的安全地址。當驗證機制是Bearer時,SIP代理服務器必須驗證訪問令牌,驗證訪問令牌的流程根據訪問令牌的類型來決定(structured 或者 reference 令牌)。


訪問Token Claims

讀者應該知道,訪問令牌是用來訪問不同的資源的。訪問令牌可以訪問的服務類型是根據不同的方式來決定。這些訪問方式是由令牌基於本地策略提供的,本地策略則是由AS和註冊服務共同協商同意的結果。具體的協商內容需要授權服務器和註冊服務器雙方進行核實驗證。


如果訪問令牌被解碼為JWT格式,它會包含一個聲明列表(claim),其中包含已註冊狀態信息的和應用級的聲明。註冊服務授權聲明中對象訪問授權的服務。如果訪問令牌是一個參考令牌的話,註冊服務會被允許基於其他的機制來進行訪問。其他的機制包括自檢機制和用戶屬性查詢等。


響應頭-WWW-Authenticate

在401或者407的響應中,Bearer機制的標識是通過認證頭來進行傳輸的。具體的用法格式和HTTP的類似。如果基於Bearer認證機制支持的話,UAC收到的Bearer消息頭用法應該和以下語法相似:

<code>challenge  =/  ("Bearer" LWS bearer-cln *(COMMA bearer-cln))bearer-cln = realm / scope-param / authz-server-param / error-param /             auth-paramrealm = scope-param = "scope" EQUAL DQUOTE scope DQUOTEscope = authz-server-param = "authz_server" EQUAL DQUOTE authz-server DQUOTEauthz-server = https-URIhttps-URI = error-param = "error" EQUAL DQUOTE error DQUOTEerror = auth-param = /<code>

其中比較重要的包括:authz_server parameter,authz_server和error消息。讀者可以根據RFC規範做進一步瞭解,這裡不再累述。


Bearer機制的安全考慮

安全問題是一個非常重要的因素。如果協議或者規範設計不當會給系統帶來很多的安全隱患和技術漏洞。安全問題存在很多討論的空間。在前面的章節中筆者已經說明了使用TLS加密的傳輸方式。這裡不再過多討論。其他方面的安全設置都通過不同的規範來規定,其中OAuth在RFC6749做了規定,Bearer的令牌的安全規範在RFC6750有細節說明,JWT的安全規範通過RFC7519做了規定。這些規範都支持了SIP協議中通過訪問令牌實現的安全機制。


Single Sign-On (SSO),單點登錄的驗證方式是SIP終端使用的一個比較常用的場景。SSO可以支持用戶一次登錄驗證,使用訪問令牌來獲取SIP和其非SIP的服務。這裡,SSO就會存在一個比較寬泛的訪問範圍,如果SSO模式存在潛在風險的話,SIP和其他非SIP服務就會存在比較大的安全風險。因為SSO的中國問題,所以,規範必須規定一個針對SSO非常嚴格的安全設置方式,例如包括一個比較長的passphrase替代密碼,支持多要素的認證機制和使用原生瀏覽器的安全設置。


在應用層級方面,如果UAC註冊時,在註冊請求中,註冊服務器可以提供不同層級的服務級別。RFC8898推薦在響應消息中包含一個服務的級別scope來表示其訪問的層級。當然,通過scope的修改,AS也可以提供更高級別的訪問權限。對於SIP用戶和應用級程序是一個非常好的安全保護,管理員也可以通過scope授權的方式允許某些SIP 用戶訪問某些特定的應用服務。


網絡漏洞是經常發生的。攻擊者可能會專門製造出一些非法的AS服務器地址來引誘UAC進行訪問。因此,UAC必須檢查AS的有效性,保證UAC訪問正確的AS服務器,避免網絡漏洞帶來的安全隱患。



總結

本文章重點介紹SIP新的認證機制Bearer的使用和其和AS/OP進行交互的詳解流程。通過OAuth的方式進行用戶驗證是目前互聯網技術中常用的技術手段,如果今後使用在SIP協議的用戶認證流程將會影響SIP業務的處理也會幫助其他應用級產品的權限訪問和服務控制。


筆者完整介紹了其核心概念和針對UAC,UAS和代理服務器的處理流程,並且特別針對401和407響應處理做了說明。最後,針對部署bearer機制帶來的安全問題進行了討論。目前,RFC8898規範是一個非常新的規範,很多處理細節和SIP業務廠家需要進行升級才能滿足RFC8898的要求,因此,我們還要繼續等待SIP服務提供商和服務器開發平臺首先支持此規範,以後我們才能把令牌訪問等技術應用在具體的SIP網絡場景中。


參考資料:

https://www.rfc-editor.org/rfc/rfc8898

https://www.rfc-editor.org/rfc/rfc6750.txt

https://www.rfc-editor.org/rfc/rfc7662.txt

https://blog.restcase.com/4-most-used-rest-api-authentication-methods/

https://www.cisco.com/c/dam/en/us/td/docs/voice_ip_comm/jabber/11_9/Unified-CM-OAuth-Whitepaper-v17-FINAL.pdf


融合通信/IPPBX/FreePBX商業解決方案:www.hiastar.com

最新Asterisk完整中文用戶手冊詳解:www.asterisk.org.cn

Freepbx/FreeSBC技術文檔: www.freepbx.org.cn

如何使用FreeSBC,qq技術分享群:334023047

關注微信公眾號:asterisk-cn,獲得有價值的通信行業技術分享


分享到:


相關文章: