RFC2617- HTTP Authentication自譯本-(3) (轉)

RFC2617- HTTP Authentication自譯本-(3) (轉)[@more@] 

 :namespace prefix = o ns = "urn:schemas--com::office" />

auth-param

    該指示用於未來擴充套件。任何無法識別的指示都必須被忽略。

 

3.2.2 授權請求標題（The Authorization Request Header）

 

  客戶端想重試傳送請求，並傳遞對應前面所定義的授權標題行，如下：

 

credentials  = "Digest" digest-response

digest-response  = 1#( username | realm | nonce | digest-uri

      |response | [ algorithm ] | [cnonce] |

[opaque] | [message-qop] |

[nonce-count]  | [auth-param] )

 

username    = "username" "=" username-value

username-value  = quoted-string

digest-uri    = "uri" "=" digest-uri-value

digest-uri-value   = request-uri  ; As specified by HTTP/1.1

message-qop    = "qop" "=" qop-value

cnonce    = "cnonce" "=" cnonce-value

cnonce-value    = nonce-value

nonce-count    = "nc" "=" nc-value

nc-value    = 8LHEX

response    = "response" "=" request-digest

request-digest   = 32LHEX

LHEX    =  "0" | "1" | "2" | "3" |

  "4" | "5" | "6" | "7" |

  "8" | "9" | "a" | "b" |

  "c" | "d" | "e" | "f"

 

  opaque域和演算法（algorithm）域的值必須在被請求實體的WWW-鑑別回應標題中給出。

 

response

  是個字串，由32個經過計算的16進位制數字組成，用來證明是否知道口令。

 

username

    使用者名稱，是指定的realm項。

 

 

 

 

 

 

 

Franks, et al.  Standards Track  [Page 11]

 

digest-uri

從請求佇列（Request-Line）中的請求URI得到的URI；這裡存在副本是因為（）在傳送時允許對請求佇列進行修改。

 

qop

指示客戶端對該訊息應用的保護等級（quality of protection）。如果不為空，其值必須是支援在WWW-鑑別標題中採用的幾種值之一。這些值會對請求-分類（request-digest）的計算造成影響。注意，這是個單獨的符號，而不是象WWW-鑑別（WWW- Authenticate）那樣，是帶引號的可選值列表。該指示是可選項，這是為了和2069[6]所規定的最小實現保持向後的相容性。但是，如果伺服器端透過在WWW-鑑別（WWW- Authenticate）標題域中新增qop指示，就表明該伺服器支援qop，因而，必須使用該項指示。

 

cnonce

當qop指示傳送了（見上面），該指示必須要指定，而當伺服器端沒有在WWW-鑑別（WWW- Authenticate）標題域中新增qop指示時，該指示一定不能指定。cnonce-value是客戶端提供的字串，它由客戶端和伺服器共同使用，用來避免選擇純文字、提供共同鑑別、提供某些訊息的完整性保護。詳情見下面的回應分類（response-digest）值和請求-分類（request-digest）值的計算。

 

nonce-count

當qop指示傳送了（見上面），該指示必須要指定，而當伺服器端沒有在WWW-鑑別（WWW- Authenticate）標題域中新增qop指示時，該指示一定不能指定。nc-value是16進製表示的計數值，用來統計客戶端傳送的帶nonce值的請求（包括當前請求）個數。例如，在第一個請求回應中給出了nonce的值，客戶端傳送”nc=00000001"，其目的是允許伺服器透過對此計算副本的維護來檢測請求重複（request replay），即當同樣的nc-value出現兩次，說明請求是可回放的。詳情見下面請求-分類（request-digest）值的構建。

 

auth-param

該指示用於未來擴充套件。任何無法識別的指示都應被忽略。

 

  如果指示或其值不正確，或者需要的指示沒有給出，都會得到400（請求）回應。如果請求-分類（request-digest）是非法的，登入失敗將會被記入日誌，因為在某個單獨的客戶端出現的重複登入失敗可能意味著攻擊者正試圖猜測口令。

 

 

 

 

 

 

 

 

Franks, et al.  Standards Track  [Page 12]
  前面定義的請求-分類（request-digest）指示了其編碼方式。下面的定義將表明這些值是如何參與計算的。

 

3.2.2.1 請求－分類（Request-Digest）

 

  如果”qop”值是"auth" 或"auth-int"：

 

request-digest  = < KD ( H(A1),  unq(nonce-value)

  ":" nc-value

  ":" unq(cnonce-value)

  ":" unq(qop-value)

  ":" H(A2)

  )

 

  如果”qop”指示沒有給出（與RFC2069保持相容性）：

 

request-digest  = < KD ( H(A1),   unq(nonce-value)

":" H(A2)

)

 

  A1及A2的定義在下面。

 

3.2.2.2 A1

 

  如果演算法（"algorithm"）值是”MD5”或沒有指定，則A1是：

 

A1  = unq(username-value) ":" unq(realm-value) ":" passwd

 

其中

 

passwd  = < user's pass >

 

  如果"algorithm"值是"MD5-sess"，則A1只要計算一次，即當客戶端發出第一個請求，並從伺服器收到WWW-鑑別（WWW-Authenticate）質詢（challenge）時計算。它使用該質詢中的伺服器的nonce，則用來構建A1的第一個客戶端nonce值應為：

 

A1    = H( unq(username-value) ":" unq(realm-value)

  ":" passwd )

  ":" unq(nonce-value) ":" unq(cnonce-value)

  上式為併發請求和回應的鑑別產生一個‘會話金鑰’（session key），該金鑰對於每個‘鑑別會話’（authentication session）都是不同的，這樣，就限制了使用任何一個金鑰進行雜湊處理的次數（注意：鑑別會話更深層次的探討見3.3節）。

 

 

Franks, et al.  Standards Track  [Page 13]

 

因為伺服器只需要使用使用者信任的雜湊值來產生A1值，因而該機制可允許第三方參與鑑別服務，這樣伺服器就不再需要實際的口令值了。該的規範已經超出了本規範的內容範圍。

 

3.2.2.3 A2

 

  如果”qop”值是”auth”或者沒給出，則A2：

 

A2  = Method ":" digest-uri-value

 

如果"qop"值是"auth-int", 則A2：

 

A2  = Method ":" digest-uri-value ":" H(entity-body)

 

3.2.2.4 指示值和帶引號的字串（Directive values and quoted-string）

 

  注意，許多指示的取值，如”username-value”等，被定義成帶引號的字串（quoted-string）。而實際上，”unq”註釋則表示在生成字串A1時，去掉其外部的引號。因而，如當授權標題包括該域，如：

 

username="Mufasa", realm=myhost@testrealm.com

  則表示使用者Mufasa的口令是"Circle Of Life"，這樣H（A1）就可表示成

H（Mufasa:myhost@testrealm.com:Circle Of Life），注意，在分類字串中沒有引號。

  注意，在分類H（）中的字串中不允許出現空格，除非空格出現在帶引號的字串內或者用以標記字串分類的實體主體中。例如，上面出現的字串A1必須是

 

Mufasa:myhost@testrealm.com:Circle Of Life

 

  在冒號的兩邊都不可以有空格，但是允許口令單詞之間出現空格（Circle+SP+Of+SP+Life）。同樣，其它由H（）分類的字串也不能在用於域間分隔的冒號兩邊加空格，除非空格在引號內或被分類的實體主體內。

 

  同樣要注意的是，如果應用了完整性保護（integrity protection），即qop=auth-int，則H（實體-主體）就是實體主體的雜湊值，而不是訊息主體的雜湊值，該值在傳送方進行任何傳輸編碼前計算，之後，被接收方刪除。

 

 

 

 

 

 

 

 

Franks, et al.  Standards Track  [Page 14]

 

  注意，它在任何多部分內容-型別（multipart content-type）中的每個部分都包括多部分的邊界和嵌入標題。

 

3.2.2.5 多樣性考慮（Various consrations）

 

  "Method"（方法）值是指HTTP請求的方法，見[2]的5.1.1節。"request-uri"值請求佇列中指定的請求URI，見[2]的5.1.2節。可能還會有”*”號，即絕對URL（"absoluteURL" 或 "abs_path"），見[2]的5.1.2節，但必須與請求URI保持一致。特殊情況，當請求URI是絕對URL時，它也必須是絕對URL形式。"cnonce-value"是客戶端可選的值，用來防止純文字攻擊。

  進行鑑別的伺服器必須保證"uri"所指向的資源與請求佇列中指定的資源相同；如果不同，伺服器應當回應400（非法請求）訊息。注意，由於這可能是攻擊的前兆，服務端的實現可能要對此進行日誌記錄。

 

在該域的請求URL中包含重複資訊的目的是因為中間的代理伺服器可能會更改客戶端的請求佇列。已經更改的請求（儘管可以恢復原狀）將會導致由客戶端計算的分類發生變更。

 

  開發者應當注意己鑑別的事務是如何與共享快取進行互動的。HTTP/1.1協議規定，如果共享快取（見[2]的13.7）收到的請求中所包含的授權標題和回應是由請求中繼傳來的，此時一定不能將該回應做為對其它請求的回答，除非是回應中包括兩種快取-控制（Cache-Control）指示中的任何一種才可以。

 

如果原始伺服器回應中指明"must-revalidate"（必須重新授權）的快取控制指示，快取雖然可以在回應併發請求時使用該回應的實體，但必須先從原始伺服器處得到認可才行，認可的方法是用新請求的請求標題到原始伺服器處獲取授權。同樣，如果原始伺服器回應中包括”public”快取控制指示，則對任何併發請求都可應用此回應的實體。

 

3.2.3 鑑別資訊標題（The Authentication-Info Header）

 

  Authentication-Info標題被伺服器用做通訊區，以得到回應中鑑別成功的一些資訊。

 

 

 

 

 

 

 

 

 

 

 

 

 

Franks, et al.  Standards Track  [Page 15]

 

AuthenticationInfo   = "Authentication-Info" ":" auth-info

auth-info    = 1#(nextnonce | [ message-qop ]

  | [ response-auth ] | [ cnonce ]

  | [nonce-count] )

nextnonce    = "nextnonce" "=" nonce-value

response-auth      = "rspauth" "=" response-digest

response-digest    = *LHEX

 

nextnonce值是伺服器希望客戶端在未來鑑別回應中採用的nonce值。伺服器可能傳送帶有nextnonce域的Authentication-Info標題，以實現一次性或可變的鑑別方式。如果nextnonce域有值，客戶端應當在下次請求中使用該值來構建授權標題。如果有"stale=TRUE"存在，客戶端的失敗將導致伺服器端對請求進行重新鑑別。

伺服器的實現應當小心處理採用這種機制而引發的潛在問題；如果每個請求都包括由伺服器指定的、必須在下個請求時使用的nextnonce值，那麼管道式（pipelined）請求不可能實現。要想實現管理式請求，而且要顧及效能和性的平衡，可在一段有限時間內，　允許使用舊的nonce值。使用nonce-count可以在不危害管道的前提下，保留新伺服器nonce的大多數安全特性。

 

message-qop

 

表示用於伺服器回應的保護等級選項。"auth"值表示鑑別；而"auth-int"值則表示採用完整性保護的鑑別。伺服器在回應客戶端請求時，應當採用和message-qop相同的值。

 

  在"response-auth"中的可選回應分類支援相互鑑別，即伺服器可以證實它知道使用者的秘密，也可透過qop=auth-int對回應提供有限的完整性保護。"response-digest"值用於授權標題中的"request-digest"值的計算，除非指定請求的授權標題中包含"qop=auth"或沒指定，則A2是：

 

A2    = ":" digest-uri-value

 

若包含"qop=auth-int", 則A2 是：

 

A2    = ":" digest-uri-value ":" H(entity-body)

 

 

 

 

 

 

 

 

 

 

Franks, et al.  Standards Track  [Page 16]

 

  其中，"digest-uri-value"是請求中授權標題所指向的"uri"。而"cnonce-value"和"nc-  value"必須做為客戶端請求的回應訊息的組成部分。當指定了"qop=auth"或"qop=auth-int"時，"response-auth"、"cnonce"、和"nonce-count"必須給出。

 

  Authentication-Info標題允許對透過塊編碼（chunked traner-coding）傳輸的HTTP訊息進行追蹤。

 

3.3 分類操作（Digest Operation）

 

  在接收授權標題前，伺服器可能要先檢查對應使用者名稱、口令的合法性。這時，伺服器必須和客戶端相同的分類操作（如，MD5），並將結果與給定請求-分類（request-digest）相比較。

 

  注意，HTTP伺服器只要支援H（A1），就不必知道使用者的口令明文，而授權標題的合法性照樣可以鑑別。

 

  客戶端在回應對受保護區間的WWW-鑑別（WWW-Authenticate）質詢時，啟動同該受保護區間之間的鑑別會話。鑑別會話在客戶端收到受保護區中的任何伺服器發出的WWW-鑑別（WWW-Authenticate）質詢時終止。客戶端應當記住與鑑別會話相關的username、password、nonce、nonce count及opaque值，從而能構建將來對指定保護區請求的授權標題。授權標題要被優先包括，這樣做會提高伺服器，並避免鑑別質詢可能發生的額外迴圈。伺服器可能選擇接受舊的授權標題資訊，即使其中包含的nonce值已過期。同樣，伺服器可能回應401，其中包括了新的nonce值，這樣會引起客戶端重試該請求；透過在回應中指定stale=TRUE，伺服器通知客戶端用新的nonce來重試請求，但是不會再要求輸入新的使用者名稱及口令。

 

  因為客戶端在會話期間要把伺服器傳給它的opaque值返回給伺服器，opaque值可用來傳遞鑑別會話的狀態資訊。（注意，其實可透過在nonce中包括狀態的方法來實現，這樣更安全、簡單。）例如，伺服器要為已經位於其它伺服器的鑑別內容負責，其實現是，在第一個401回應中包括ain指示（包括第二個伺服器上的URI）和opaque指示（包括狀態資訊）

 

 

 

 

 

 

 

 

 

 

 

 

Franks, et al.  Standards Track   [Page 17]

 

 

  客戶端會在伺服器回應301或302（重定向，即，指向第二個伺服器上的URI）時重試該請求。客戶端會根據重定向資訊，傳送授權標題，包括 資料。

 

  在基本方案中，代理（proxy）必須完全透明地處理分類訪問鑑別方案（Digest access authentication scheme.）。他們必須將WWW-Authenticate、Authentication-Info、和Authorization header向前推送，而不做任何修改。如果代理希望在請求推送到伺服器之前對客戶進行鑑別，它可以使用代理-鑑別（Proxy-Authenticate）和代理-授權（Proxy-Authorization）標題，見下面3.6節。

 

3.4 安全協議討論（Security Protocol Negotiation）

 

  對伺服器來說，瞭解客戶端有能力處理的哪種安全方案是很有用的。

 

  可能存在這種情況，伺服器端直接獲取分類做為其鑑別方法，而不管客戶端是否支援它。如果發生這種情況，伺服器指定的鑑別方案恰好是客戶端所不支援的，客戶端應當明確回應失敗。

 

3.5 例子（Example）

 

  下面的例子假定透過GET請求來獲取伺服器上一個帶有訪問保護的文件。文件的URI是""，客戶端和伺服器都知道該文件的使用者名稱是"Mufasa"，口令是"Circle Of Life"（三個單詞間用一個空格分隔）。

 

  客戶端在第一次請求該文件時，沒有傳送授權標題，於是伺服器回應：

HTTP/1.1 401 Unauthorized

WWW-Authenticate: Digest

realm="testrealm@host.com",

qop="auth,auth-int",

nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",

opaque="5ccc069c403ebaf9f0171e9517f40e41"

 

  客戶端可能會在新的請求中提供使用者名稱和口令，包括下面的授權標題：

 

 

 

 

 

 

 

 

 

Franks, et al.  Standards Track  [Page 18]

 

Authorization: Digest username="Mufasa",

realm="testrealm@host.com",

nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",

uri="/dir/index.html",

qop=auth,

nc=00000001,

cnonce="0a4f113b",

response="6629fae49393a05397450978507c4ef1",

opaque="5ccc069c403ebaf9f0171e9517f40e41"

 

3.6 代理鑑別和代理授權（Proxy-Authentication and Proxy-Authorization）

 

  透過使用Proxy-Authenticate和Proxy-Authorization標題，分類鑑別方案也可實現在代理、代理間、代理與原始伺服器間進行使用者鑑別。這些標題是Proxy-Authenticate和Proxy-Authorization標題的例項（見HTTP/1.1規範[2]，10.33和10.34節，其行為的限制描述）。代理鑑別事務與已經描述的十分相似。在接收需要鑑別的請求之前，代理/伺服器必須發出407（需要代理鑑別）回應，其中包含了"Proxy-Authenticate"標題。Proxy-Authenticate標題中使用的分類質詢（digest-challenge）與在前面3.2.1節中定義的WWW- Authenticate標題一樣。

 

  客戶端/代理必須重新發出帶有代理授權（Proxy-Authorization）標題的請求，其寫法見上面的3.2.2節的授權標題。

 

  在併發回應時，伺服器將傳送代理鑑別資訊（Proxy-Authentication-Info），其寫法與Authentication-Info標題域是一樣的。

 

  注意，原理上，可要求客戶端提供對代理和最終伺服器的自身鑑別，但不能在同一個回應當中。

 

4 安全考慮（Security Considerations）

 

4.1 用基本鑑別的客戶端鑑別（Authentication of Clients using Basic Authentication）

 

  基本鑑別方案不是安全的使用者鑑別方式，也不會對以明文方式在物理中傳輸的實體進行任何形式的保護。HTTP允許使用另外的鑑別方案或機制來增強基本協議的安全效能（比如，一次性口令方案）。

 

 

 

 

 

 

 

Franks, et al.  Standards Track  [Page 19]

 

  基本鑑別方式最嚴重的在於它將使用者口令以明文方式在物理網路中傳輸，而這正是分類鑑別（Digest Authentication）方式試圖去解決的。

 

  因為基本鑑別使用了口令的明文傳輸方式，因此，如果沒有使用增強方式，一定不能用來保護敏感或有價值的資訊。

 

  基本鑑別方式通常用於識別目的――要求使用者提供使用者名稱及口令做為身份標識，例如，用於伺服器精確統計使用狀況。這種情況看似沒有危險，對受保護的違法訪問不是主要問題。然而，除非由伺服器向使用者傳送使用者名稱、口令，而且不允許使用者選擇自己的口令時，這種方式才可能安全。否則危險會成倍增加，因為有些天真的使用者為避免維護多個口令，而老是使用單個的口令。

 

  如果伺服器允許使用者自由選擇口令，那帶來的危險不僅僅是對伺服器檔案的未授權訪問，而且還會引起對使用者用同樣口令保護的其它資源的未授權訪問。此外，在伺服器口令中，許多口令同樣是使用者訪問其它站點的口令。因而，如果此類資訊不受到安全保護，那麼系統的所有者或管理員將會承擔因未授權訪問而造成的系統使用者資訊暴露的風險。

 

  基本鑑別也容易受到假冒伺服器欺騙的攻擊。當使用者堅信他正與一臺受基本鑑別方案保護的主機相連時，他也許不會想到，此時他可能正與懷有敵意的伺服器或閘道器相連。攻擊者可截獲口令，並將其儲存起來備用，同時假裝返回一個錯誤。這種型別的攻擊在分類鑑別方案下是不可能成功的。伺服器端的開發者應當實現對假冒閘道器或偽裝script的防護。在特殊情況下，象伺服器開啟與某個閘道器的連線之類看起來很簡單的事都有可能產生嚴重後果，因為這樣以後，閘道器就可扮演成原始伺服器，用持久連線的機制同客戶建立多種事務互動，而客戶可能對此一無所知。

 

4.2 用分類鑑別的客戶端鑑別（Authentication of Clients using Digest Authentication）

 

  與其它一些安全機制相比，如基於公鑰技術的機制，分類鑑別機制要顯得脆弱一些。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Franks, et al.  Standards Track  [Page 20]