使用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.0
Authorization: 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-URI
2、 在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中定義的新機制