Proxy Authentication Required解決

 

癥狀

如果 Internet Security and Acceleration (ISA) Server 2000 是連結到上遊 Web Proxy伺服器, 網頁瀏覽器中可能會收到完整 HTML 頁和隨機身分識別驗證提示。

如果下遊 ISAServer 電腦配置需要整合驗證並且如果上遊 Web Proxy伺服器也配置需要代理驗證可能會發生這些癥狀。 此外, 下遊 ISAServer 電腦上路由規則配置為向上遊 Web Proxy伺服器提供基本驗證憑據。

如果下遊 ISAServer 電腦不配置為提供任何憑據或者被配置為向上遊 Web Proxy伺服器提供整合驗證憑據不會此行為不發生。

回到頂端

原因

在某些情況下, 網頁瀏覽器可能嘗實驗證與下遊 ISAServer 電腦已經被身分識別驗證， 通過使用整合身分識別驗證串連。 這可能導致下遊 ISAServer 電腦將這些憑據傳遞給上遊 Web Proxy伺服器。 因為憑據是不用於下遊 ISAServer 電腦和上遊 Web Proxy伺服器, 伺服器返回需要 " 407 代理驗證 " HTTP 響應。 下遊 ISAServer 電腦然後將此 HTTP 響應回 網頁瀏覽器, 導致身分識別驗證提示用戶端電腦上。 因為用戶端不能驗證此請求, 會 網頁用戶端瀏覽器上導致完整 HTML 頁。

回到頂端

解決方案

支援Hotfix現已推出來自 Microsoft。 但是, 此修複程式用於更正本文中描述問題只。 只對遇到此特定問題的系統應用此修複程式。 此修複程式可能會收到其他測試。 因此, 如果您受此問題, 的影響不嚴重我們建議您等待下服務包包含此修複程式。

要解決此問題, 向 Microsoft 聯機客戶服務提交申請以擷取此修複程式。 請以提交聯機請求以擷取此修複程式, 訪問以下 MicrosoftWeb 網站：

http://go.microsoft.com/?linkid=6294451 (http://go.microsoft.com/?linkid=6294451)

注意 如果出現其他問題或解決任何是必需, 可能需要建立單獨的服務要求。 通常支援成本將應用於其他支援問題以及執行不符合此特定Hotfix問題。 請來建立單獨的服務要求, 訪問以下 MicrosoftWeb 網站：

http://support.microsoft.com/contactus/?ws=support (http://support.microsoft.com/contactus/?ws=support) 警告 ： 如果登錄編輯程式使用不當, 可能會造成嚴重問題， 可能需要重新安裝作業系統。 Microsoft 無法保證您能解決因登錄編輯程式使用不當而導致問題。 需要您自擔風險使用登錄編輯程式。

以實現此Hotfix, 中功能建立以下註冊表值：

1.	停止 Web Proxy服務。
2.	啟動登錄編輯程式。
3.	找到並單擊以下登錄機碼： HKEY_LOCAL_MACHINE/SYSTEM/CurrentControlSet/Services/W3Proxy/Parameters
4.	建立命名 RemoveRedundantProxyAuthorization 新 DWORD 值。 此新值賦予資料值為 1。
5.	啟動 Web Proxy服務。

要恢複到原始配置, 請刪除 RemoveRedundantProxyAuthorization 註冊表值, 或將其資料值更改為 0 （零）。 在任一更改, 後重新啟動 Web Proxy服務。 // Create a new request to the mentioned URL.               
   WebRequest myWebRequest=WebRequest.Create("http://www.contoso.com");

   WebProxy myProxy=new WebProxy();
   // Obtain the Proxy Prperty of the  Default browser. 
   myProxy=(WebProxy)myWebRequest.Proxy;

   // Print myProxy address to the console.
   Console.WriteLine("/nThe actual default Proxy settings are {0}",myProxy.Address);
try
   {
       Console.WriteLine("/nPlease enter the new Proxy Address to be set ");
       Console.WriteLine("The format of the address should be http://proxyUriAddress:portaddress");
       Console.WriteLine("Example:http://proxyadress.com:8080");
       string proxyAddress;
       proxyAddress =Console.ReadLine();

       if(proxyAddress.Length==0)
       {
           myWebRequest.Proxy=myProxy;
       }
       else
       {
           Console.WriteLine("/nPlease enter the Credentials");
           Console.WriteLine("Username:");
           string username;
           username =Console.ReadLine();
           Console.WriteLine("/nPassword:");
           string password;
           password =Console.ReadLine();

           // Create a new Uri object.
           Uri newUri=new Uri(proxyAddress);

           // Associate the new Uri object to the myProxy object.
           myProxy.Address=newUri;

           // Create a NetworkCredential object and is assign to the Credentials property of the Proxy object.
           myProxy.Credentials=new NetworkCredential(username,password);
           myWebRequest.Proxy=myProxy;
       }
       Console.WriteLine("/nThe Address of the  new Proxy settings are {0}",myProxy.Address);
       WebResponse myWebResponse=myWebRequest.GetResponse();

       // Print the  HTML contents of the page to the console.
       Stream streamResponse=myWebResponse.GetResponseStream();
       StreamReader streamRead = new StreamReader( streamResponse );
       Char[] readBuff = new Char[256];
       int count = streamRead.Read( readBuff, 0, 256 );
       Console.WriteLine("/nThe contents of the Html pages are :");   
       while (count > 0)
       {
           String outputData = new String(readBuff, 0, count);
           Console.Write(outputData);
           count = streamRead.Read(readBuff, 0, 256);
       }

       // Close the Stream object.
       streamResponse.Close();
       streamRead.Close();

       // Release the HttpWebResponse Resource.
       myWebResponse.Close();
       Console.WriteLine("/nPress any key to continue.........");
       Console.Read();               
   }
   catch(UriFormatException e)
   {
       Console.WriteLine("/nUriFormatException is thrown.Message is {0}",e.Message);
       Console.WriteLine("/nThe format of the myProxy address you entered is invalid");
       Console.WriteLine("/nPress any key to continue.........");
       Console.Read();
   }＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊That cast is wrong. HttpWebRequest.Proxy is of type IWebProxy. There's
no guarantee that the class implementing this Interface is really a
WebProxy object.

There's really no point in reading the default proxy from the
HttpWebRequest if you want to use another one. Simply create a new
WebProxy object with the desired proxy URL, set the required
credentials and assign this object to the HttpWebRequest's Proxy
property.
＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊＊如果當上遊 Web Proxy伺服器沒有任何存取控制 （使用匿名訪問）, 代替安裝此修複程式, 然後運行您看到同一癥狀實現以下 MicrosoftKnowledgeBase 文章中介紹修複： 317822 (http://support.microsoft.com/kb/317822/EN-US/) FIX： 問題瀏覽如果 ISA Server 2000 是連結到上遊 Web Proxy伺服器 具體情況如下：在外網的伺服器上部署了一個Web Service，由於公司網路原因，僅能通過內網穿過Proxy 伺服器來訪問外網的Web Service。在添加外網的Web Service時，出現了提示視窗，如：
    提示輸入公司內網域的使用者名稱和密碼。我輸入了自己的使用者名稱和密碼，正常添加引用。然後在調用時出現了問題，報錯資訊為：請求因 HTTP 狀態 407 失敗：Proxy Authentication Required ( The ISA Server requires authorization to fulfill the request. Access to the Web Proxy service is denied. )。需要Proxy 伺服器認證，上網查了好多的文章，發現給出的解決方案有誤，原內容為：首先引用命名空間using System.Net; 定義一個代理類WebProxy myProxy = new WebProxy("192.168.0.3:8080",true);然後又定義了一個用於身分識別驗證的類myService.Credentials = new NetworkCredential("username","password","domainname");其中的myService變數為一個執行個體化的Web Service對象。 個人理解其實這是不對的，這個Credentials在注釋中為“擷取或設定XML Web services 用戶端驗證的安全憑據”。我們要設定的應該是通過代理時我們使用的安全憑據，所以這個設定是不對的。在上面定義的myProxy代理對象中，也有一個Credentials屬性，它才是真正的“擷取或設定提交給Proxy 伺服器進行身分識別驗證的憑據”。所以我們將代碼作如下修改：設定代理對象的Credentials屬性myProxy.Credentials = new NetworkCredential("username "," password "," domainname ");然後將定義的代理對象賦給Web Service對象的Proxy代理屬性即可myService.Proxy = myProxy;作完這些設定就可以調用Web Service提供的介面了。測試訪問代理成功。

 

 

Update via ISA

在公司裡面，網路訪問都是通過ISA Server的（Microsoft Internet Security and Acceleration Server），在使用Windows的時候不會出現任何問題，可是前兩天裝了Ubuntu Linux，遇到了些問題。

我使用firefox訪問網路沒有問題，只需要設好Proxy 伺服器地址，瀏覽網站時輸入相應的使用者名稱和密碼即可，但在console下面使用apt-get更新系統時有問題。

開始我覺得應該這樣設定代理：
export http_proxy=http://domaindomainuser:password@proxy.corpnet.com:8080

可是總會出現這個錯誤：
407 Proxy Authentication Required ( The ISA Server requires authorization to fulfill the request. Access to the Web Proxy service is denied. )

後來在網上搜尋了一下，找到方法解決這個問題了：

Download ntlmaps-0.9.9.0.1 from here

$ tar -zxvf ntlmaps-0.9.9.0.1

$ vim ntlmaps-0.9.9.0.1/server.cfg

Edit PARENT_PROXY,PARENT_PROXY_PORT,USER,PASSWORD to match your preferences, then run main.py

$ ./ntlmaps-0.9.9.0.1/main.py &

$ export http_proxy="http://127.0.0.1:5865"

$ sudo apt-get update

Now, everything is OK.

參考：
http://www.faqs.org/docs/Linux-H ... A-Server-HOWTO.html
http://www.ubuntuforums.org/showthread.php?t=20310
http://www.linuxquestions.org/questions/showthread.php?t=448387
http://kubuntuforums.net/forums/index.php?topic=7683.0

SIP協議中的認證方式

作者：未知 , 來源：未知 , 點擊：122

註：請參照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: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”參數放在後續的認證頭域中。