<script src="http://pagead2.googlesyndication.com/pagead/show_ads.js" type="text/javascript"> </script><iframe name="google_ads_frame" marginwidth="0" marginheight="0" src="http://pagead2.googlesyndication.com/pagead/ads?client=ca-pub-4111920013853982&amp;dt=1177829700074&amp;lmt=1177829700&amp;format=300x250_as&amp;output=html&amp;channel=0395067506&amp;url=http%3A%2F%2Fwww.goalercn.com%2Fprogram%2Fview.php%3Fid%3D105&amp;color_bg=FFFFFF&amp;color_text=000000&amp;color_link=0000FF&amp;color_url=009900&amp;color_border=FFFFFF&amp;ad_type=text_image&amp;ref=http%3A%2F%2Fwww.google.cn%2Fsearch%3Fq%3D%2BProxy%2BAuthentication%2BRequired%25E8%25A7%25A3%25E5%2586%25B3%26complete%3D1%26hl%3Dzh-CN%26newwindow%3D1&amp;cc=100&amp;flash=9&amp;u_h=768&amp;u_w=1024&amp;u_ah=738&amp;u_aw=1024&amp;u_cd=32&amp;u_tz=480" frameborder="0" width="300" scrolling="no" height="250" allowtransparency="allowtransparency"></iframe>

注：請參照RFC3261

使用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:

[email protected] 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:[email protected]”, 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”引數放在後續的認證頭域中。