使用HTTP認證SIP為認證系統提供了一個無狀態的，試錯機制，這個認證機制式基於HTTP的認證機制的。任何時候proxy伺服器或者UA接收到一個請求 （22.1節例外），它嘗試檢查請求發起者提供的身份確認。當發起方身份確認了，請求的接受方應當確認這個使用者是否式通過認證的。在本文檔中，沒有建議或 者討論認證系統。 本節描述的“Digest”認證機制，只提供了訊息認證和複查保護，沒有提供訊息完整性或者機密性的保證。上述的保護層級和基於這些Digest提供的保護，可以防止SIP攻擊者改變SIP請求和應答。 注意由於這個脆弱的安全性，我們不贊成”Basic”（基本的）認證方法。伺服器必須不能接收驗證方法式”Basic”類型的信任書，並且伺服器必須拒絕”Basic”。這是和RFC2543的改變。 架構SIP認證的架構和HTTP非常接近(RFC2617[17])。特別式，auth-scheme的BNF範式，auth-param, challenge,realm,realm-value,以及信任書都是一樣的（雖然對”Basic”認證方案是不允許的）。在SIP，UAS使用 401(Unauthorized)應答來拒絕UAC的身份（或者講是考驗UAC的身份，如果不通過，就是401）。另外，註冊伺服器，轉寄伺服器可以使 用401（Unauthorized）來應答身份認證，但是proxy必須不能用401，只能用407（Proxy Authentication Required）應答。對於Proxy-Authenticate的包含要求，Proxy-Authroization,WWW- Authenticate,Authorization在不同的訊息中是相同的，如同在RFC2617[17]中講述的一樣。 由於SIP並沒有一個規範的root URL的概念，所以，需要保護的空間的概念在SIP中的解釋也不一樣。realm字串單獨定義被保護的地區。這個是和RFC2543的改變，在2543中Request-URI和realm一起定義了被保護的地區。 這個先前定義的被保護的地區回導致一定程度的混亂，因為Request-URI是UAC發送的，並且接收到Request-URI的證明伺服器 可能是不同的，並且真正的最終的Request-URI的格式可能對UAC並不知道。同樣，早先的定義依賴於一個Request-URI中的SIP URI，並且看起來不允許其他的URI 方案（比如tel URL） 需要鑒別接收到的請求的UA使用者或者proxy伺服器，必鬚根據下邊的指導來為他們的伺服器建立一個realm字串。 o Realm字串必須是全域唯一的。我們強調這個realm字串必須包含一個主機名稱或者網域名稱，遵循3.2.1節或者RFC2617[17]的推薦 o Realm字串應當是一個可讀的能夠展示給使用者的字串。例如：INVITE sip:bob@biloxi.com SIP/2.0Authorization: Digest realm=”biloxi.com”,<…>通常，SIP認證對於特定realm（一個保護地區）是有意義的。因此，對於Digest認證來說，每一個類似的保護地區都有自己的使用者名稱和密 碼集合。如果伺服器對特定請求沒有要求認證，那麼它可以接收預設的使用者名稱,”anonymous”,並且這個使用者名稱沒有密碼（密碼是””）。類似的,代表 多個使用者的UAC，比如PSTN網關，可以有他們自己的裝置相關的使用者名稱和密碼，而不是每一個使用者名稱一個使用者名稱密碼（這就是說，比如網關，有一個網關的用 戶和密碼，而不是說通過網關的每一個實際使用者和密碼）。 當伺服器可以正確處理絕大部分SIP請求，有本文檔約定了兩類請求要求特別的認證處理：ACK和CANCEL。在某一個認證方案下，並且這個認 證方案是使用應答來放置計算nonces（比如Digest），那麼對於某些沒有應答的情況，就會出現問題，比如ACK。所以，基於這個原因，一個伺服器 接受在INVITE請求中的信任書，也必須同樣接收對應ACK的信任書。UAC通過賦值所有的INVITE請求中的Authorization和 Proxy-Authorization頭域值來建立一個相關的ACK訊息。伺服器必須接收這個ACK請求。 雖然CANCEL方法具有應答（2xx），伺服器必須不能拒絕CANCEL請求，因為這些請求不能被重新提交。通常，如果CANCEL請求和被 CANCEL的請求來自同一個節點（假設某種通訊協議，或者網路層有安全關係26.2.1節描述），伺服器應當接收CANCEL請求。 當UAC接收到驗證拒絕，並且UAC裝置並不知道realm驗證失敗的具體原因，它必須展示給使用者，驗證失敗的”realm”參數內容（既可以 在WWW-Authenticate頭域或者Proxy-Authenticate頭域）。對於給自己的realm預先配置信任狀的UA服務提供者來說， 應當注意到這樣一點：當被一個預先配置信任狀的裝置拒絕的時候，使用者不會有機會在這個realm中展示他們自己的信任狀。 最後，注意即使一個UAC能夠定位與相關realm匹配的信任書，也有可能存在這個信任書可能不在有效，或者某個伺服器會用什麼原因不接受這個 信任書（特別是當提供的是沒有口令的”anonymous”使用者時）。在這種情況下，伺服器可能會繼續拒絕，或者返回一個403 Forbidden。UAC必須不能再次使用剛才被拒絕的信任書進行嘗試（如果當前環境沒有改變，那麼請求可以再次嘗試）。 使用者到使用者的認證。當UAS收到一個UAC發起的請求，UAS在請求被處理之前進行身份認證。如果請求中沒有信任書（在Authorization頭域），UAS可以使用401(Unauthorized)拒絕認證，並且讓用戶端提供一個認認證。 WWW-Authenticate應答頭域必須在401（Unauthorized）應答訊息中出現。這個頭域值包含了至少一個表明認證方式和適用realm的參數的拒絕原因。 在401中的WWW-Authenticate頭域例子：WWW-Authenticate:Digest,realm=”biloxi.com”,qop=”auth,auth-int”,nonce=”dcd98b7102dd2f0e8b11d0f600bfb0c093",opaque="5ccc069c403ebaf9f0171e9517f40e41" 當原始請求的UAC接收到這個401(Unauthorized)應答的時候，如果可能的話，他應當重新組織這個請求，並且填寫正確的信任書。 在繼續處理之前，UAC可以要求原始使用者輸入信任書。一旦信任書（不管是使用者輸入的，還是內部密鑰）提供了，UA應當把這個給特定To頭域和” realm”欄位的信任書cache起來，以備給這個地址下一個請求時候使用。UA可以用任何方式來cache這個信任書。 如果沒有找到對應realm的信任書，UAC應當嘗試用使用者”anonymous”和空口令來重新嘗試這個請求。 一旦找到了一個信任書，那麼UA應當要求在UAS或者註冊伺服器上認證自己，這是通常的情況，但是並非一定要求的，在接收到一個401 （Unauthorized）應答後－可以在請求中增加一個Authorization頭域然後再認證。Authorization頭域包含了具有這個 UA到請求的資源所在的realm（地區）的信任書和所需要的認證支援的參數和重現保護的參數。 Authorization頭域例子：Authorization: Digest username=”bob”, realm=”biloxi.com”, nonce=”dcd98b7102dd2f0e8b11d0f600bfb0c093", uri=”sip:bob@biloxi.com”,qop=auth,nc=00000001, cnonce=”0a4f113b”, response=”6629fae49393a05397450978507c4ef1", opaque=”5ccc069c403ebaf9f0171e9517f40e41" 當UAC在接收到401（Unauthorized）或者407（ProxyAuthenticationRequired）應答之後，重新用它的信任書來提交請求，它必須增加Cseq頭域的值，就像發送一個正常的新請求一樣。 Proxy到使用者的認證類似的，當UAC發送一個請求到proxy伺服器，proxy伺服器可以在處理請求之前，驗證原始請求的認證。如果請求中沒有信任書（在 Proxy-Authorization頭域），proxy可以用407（Proxy Authentication Required）拒絕這個原始請求，並且要求用戶端提供適當的信任書。proxy必須在407 （ProxyAuthenticationRequired）應答中增加一個Proxy-Authenticate頭域，並且在這個頭域中給出適用於本 proxy的認證資源。 對於Proxy-Authenticate和Proxy-Authorization一起在[17]中描述，兩者有一個不同。Proxy不能在 Proxy-Authorization頭域中增加值。所有的407（ProxyAuthenticationRequired）應答必須轉寄到上行隊 列，遵循發送應答的步驟發送到UAC。UAC負責在Proxy-Authorization頭域值增加適用於這個proxy要求認證的這個proxy的 realm的信任書。 如果proxy要求UAC在請求中增加Proxy-Authorization頭域並且重新提交請求，那麼UAC應當增加Cseq頭域的值，就像一個新請求一樣。不過，這樣就導致提交原始請求的UAC需要忽略UAS的應答，因為Cseq的值可能是不一樣的。 當原始請求的UAC接收到一個407(Proxy Authentication Required)的時候，如果可能，它應當使用正確的信任書重新組織請求。它應當和對前邊講述的401應答的處理步驟一樣顯示和處理”realm”參數。 如果沒有找到對應realm的信任書，那麼UAC應當嘗試用使用者”anonymous”和空口令重新嘗試請求。 UAC也應當cache這個在重新發送請求中的信任書。 我們建議使用下列步驟來cache一個proxy的信任書： 如果UA在給特定Call-ID的請求的401/407應答中，接收到一個Proxy-Authenticate頭域，它應當合并對這個 realm的信任書，並且為以後具有相同Call-ID的請求發送這個信任書。這些信任書必須在對話中被cache住；不過如果UA配置的是它自己的本地 外發proxy，那麼如果出現要求認證的情況，那麼UA應當cache住跨對話的信任書。注意，這個意味著在一個對話中的請求可以包含在Route頭域中 所經過proxy都不需要的信任書。 任何希望在proxy伺服器上認證的UA――通常，但是並非必須，在接收到407（Proxy Authentication Required）應答之後――可以在請求中增加一個Proxy-Authorization頭域然後再次嘗試。Proxy-Authorization 要求標頭域允許用戶端像proxy來證明自己（或者使用者）的身份。Proxy-Authorization頭域包含了UA提供給proxy和/或者請求資 源所在的realm的身份認證資訊的信任書。 一個Proxy-Authorization頭域值只提供給指定proxy驗證的，這個proxy的realm是在”realm”參數中指明的 （這個proxy可以事先通過Proxy-Authenticat頭域提出認證要求）。當多個proxy組成一個鏈路的時候，如果proxy的realm 和請求中的Proxy-Authorization頭域的”realm”參數不匹配，那麼這個proxy就不能使用本Proxy- Authorization頭域值來驗證。 注意，如果一個認證機制不支援Proxy-Authorization頭域的realm，porxy伺服器必須嘗試分析所有的Proxy- Authorization頭域值來決定是否其中之一有這個proxy認為合適的信任書。因為這個方法在大型網路上很耗時間，proxy伺服器應當使用一 個一個支援Proxy-Authorization頭域的realm的認證方案。 如果一個請求被分支（參見16.7節），可能對同一個UAC有不同的proxy伺服器和/或者UA希望要求認證。在這種情況下，分支的 proxy伺服器有責任把這些被拒絕的認證合并成為一個應答。每一個分支請求的應答中接收到WWW-Authenticate和Proxy- Authenticate頭域值必須由這個分支proxy放置在同一個應答中發送給UA；這些頭域值的順序並沒有影響。 當proxy伺服器給一個請求發出拒絕認證的應答，在UAC用正確的信任書重新發請求過來之前，不會轉寄這個請求。分支proxy可以同時向多 個要求認證的proxy伺服器轉寄請求。每一個proxy在沒有接收到UAC在他們各自的realm的認證之前，都不會轉寄這個請求。如果UAC沒有給這 些失敗的驗證提供信任書，那些發出拒絕通過認證的proxy是不會把請求轉寄給UA的目標使用者的，因此，分支的優點就少了很多。 當針對包含多個拒絕認證的401（Unauthorized）或者407（Proxy Authentication Required）應答重新提交請求時，UAC應當對每一個WWW-Authenticate和Proxy-Authorization頭域值提供一個信 任書。根據上邊的說明，一個請求的多個認認證應當用”realm”參數分開。 不過，在同一個401（Unauthorized）或者407（Proxy Authentication Required）應答中，可能包含對同一個realm的多個驗證拒絕。例如，當在相同域的多個proxy，使用共同的realm，接收到了一個分支請 求，並且認證拒絕了的時候，就會有這樣的情況。當UAC重新嘗試這個請求的時候，UAC因此會提供多個Authorization或者Proxy- Authorization頭域，包含相同的”realm”參數。並且對於同一個realm，應當有相同的信任書。 Digest 認證方案奔進誒描述了對HTTP Digest 認證方案的SIP修改和簡化。SIP使用了和HTTP[17]幾乎完全一樣的方案。 由於RFC 2543是基於RFC2069[39]定義的HTTP Digest的，支援RFC2617的SIP伺服器也必須確保他們和RFC2069相容。RFC2617定義了保證相容性的步驟。注意，SIP伺服器必須不能接收或者發出Basic認證請求。 Digest認證的規則在[17]中定義，只是使用”SIP/2.0”替換”HTTP/1.1”，並且有如下的不同： 1、 URI有著如下的BNF：URI=SIP-URI/SIPS-URI2、 在RFC 2617定義中，有一個HTTP Digest認證的Authorization頭域”uri”參數的錯誤，是沒有括弧配對的錯誤。（在RFC2617的3.5節的例子是正確的）。對於SIP來說，’uri’參數必須在引號中引起來。3、 digest-uri-value的BNF是：digest-uri-value=Request-URI; 在25節定義。4、 對SIP來說，產生基於Etag的nonce的步驟例子不適用。5、 對SIP來說，RFC2617[17]關於chache操作不適用。6、 RFC2617[17]要求伺服器檢查請求行的URI，並且在Authorization頭域的URI要指向相同的資源。在SIP中，這兩個URI可以指 向不同的使用者，因為是同一個proxy轉寄的。因此，在SIP，一個伺服器應當檢查在Authorization頭域值的Request-URI和伺服器 希望接收請求的使用者是否一致，但是如果兩者不一致，並無必要展示成為錯誤。7、 在Digest認證方案中，關於計算訊息完整性保證的A2值的一個澄清，實現著應當假定，當包體是空的（也就是說，當SIP訊息沒有包體）應當對包體的hash值產生一個M5hash空串，或者：H(entity-body)=MD5(“”)="d41d8cd98f00b204e9800998ecf8427e"8、 RFC2617指出了在Authorization（以及擴充的Proxy-Authorization）頭域中，如果沒有qop指示參數，就不能出現 cnonce值。因此，任何基於cnonce（包括”MD5-Sess”）的運算都要求qop指數先發送。在RFC2617中的”qop”參數是可選的， 這是為了向後相容RFC2069；由於RFC2543是基於RFC2069的，”qop”參數必須被客戶和伺服器依舊是當作選擇性參數存在。不過，伺服器必 須始終在WWW-Authentication和Proxy-Authenticate頭域值中傳送”qop”參數。如果一個用戶端在一個拒絕認證的應答 中收到一個”qop”參數，他必須把這個”qop”參數放在後續的認證頭域中。
RFC 2543不允許使用Authentication-Info頭域（在RFC2069中使用）。不過我們現在允許使用這個頭域，因為他提供了對包體的完整性 檢測以及提供了相互認證。RFC2617[17]定義了在請求中使用qop屬性的向後相容機制。這些機制必須在伺服器使用，用來檢測是否客戶支援 RFC2617的，沒有在RFC2069中定義的新機制
