關於認證，基本認證和摘要認證（翻譯tr069 3.4.4 和3.4.5）

3.4.4  認證

    如果CPE沒有用TLS認證，ACS必須用HTTP來認證CPE。如果TLS用來加密，ACS應該用基本認證。如果TLS沒有用來做加密，ACS必須使用摘要認證。

  CPE必須支持HTTP的基本和摘要認證。CPE通過提供的基本認證和摘要認證的有點來確定認證方案。如果使用TLS加密，CPE應該主動發送基本認證身份。

   注意：身份驗證需要發送一個初始消息（通常是一個Inform包，該包中包含RPC方法請求）；當用TLS做加密時，主動發起一個基本認證可以避免額外的請求。

   如果CPE已經接收到了來自於ACS的認證（基本或摘要），爲了維持TCP連接，CPE必須發送在接下來的所有HTTP請求中發送認證頭。無論CPE會不會這樣做，ACS需要在會話的任意階段在一個或多個TCP連接中發送認證。

  如果任何形式的HTTP認證用來認證CPE，CPE需要用用戶名/用戶標識符，用戶標識符是所有CPE製造商唯一的標誌。

   特別是，CPE的用戶名/用戶標識符應該是以下兩種格式的其中一種：

   <OUI>"_"<ProductClass>"_"<SerialNumber>

    <OUI>"_"<SerialNumber>

    If a username/userid of the above format is used, the <OUI>, <ProductClass>, and
<SerialNumber> fields MUST match exactly the corresponding Parameters included in
the DeviceIdStruct in the Inform message, as defined in Annex A, except that, in order to
guarantee that the Parameter values can be extracted from the username/userid, any
character in the <ProductClass> and <SerialNumber> that is not 0-9, A-Z, a-z, or an
underscore (“_”) MUST be escaped using URI percent-encoding, as defined in RFC 3986 （不懂，以後翻譯）。

Percent-encoding MUST be performed by converting each character to UTF-8 and then
percent-encoding each octet. For example, the character é (LATIN SMALL LETTER E
WITH ACUTE) is represented in UTF-8 as the two octets 0xC3 0xA9 and so would be
percent-encoded as “%C3%A9”.
Note – prior to the clarification that conversion to UTF-8 occurs before percent-encoding, the
escaped username/userid was ambiguous. For example, an implementation might have treated the
character é as the ISO Latin-1 octet 0xE9, which would have been percent-encoded as “%E9”. （好像是格式之類的，以後翻譯）

如果用到以上格式中的其中之一，只有當參數ProductClass的值爲空時，才能用第二種形式。

例如：

012345-0123456789
012345-STB-0123456789
012345-Set%2DTop%2DBox-0123456789
用於HTTP認證的密碼對於CPE來說應該是一個唯一的值。也就是說，多個CPE不應該共享同一個密碼。這個密碼是個共享的祕密，並且必須被CPE和ACS所知。CPE和ACS都應該採用恰當的方式來防止在ACS端出現未經授權的訪問密碼或密碼列表。

3.4.5 摘要認證

  本節概述了在廣域網管理協議中使用摘要認證的必要項。這些必要項應用於因RPC信息交換和文件傳輸而建立的連接的認證。注意，在不同類型的連接中，ACS和CPE扮演的角色是HTTP客戶端和服務器。當發起連接請求的時候，ACS扮演HTTP客戶端的角色，當與ACS發起連接時，CPE扮演HTTP客戶端的角色。CPE和ACS必須支持RFC2617的“qop”選項，並且包括該選項的值“auth”。根據RFC2617，this means that the HTTP client MUST use a new style digest mechanism when this option is provided to it by the HTTP server. （不理解哦）。

 當使用摘要認證時，打開一個新的TCP連接，ACS應該使用一個新的nonce值並且CPE也應該用一個新的cnone值。

  注意：如果會話中沒有用TLS，ACS重複利用HTTP認證的nonce值會嚴重影響會話的安全性，尤其是，當ACS在多個TCP連接的過程中用已經使用過的nonce值進行認證時，面對attacks，ACS就會很脆弱，但是，如果在會話中使用了TLS,風險就會降低。CPE和ACS必須支持MD5摘要認證算法，CPE必須額外支持MD5-sess摘要認證算法。