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

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

1 授權鑑別（Access Authentication）

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

1.1對HTTP/1.1規範的依賴（Reliance on the HTTP/1.1 Specification）

 

  本規範和HTTP/1.1規範[2]一起使用，它使用HTTP/1.1文件2.1節的補充反饋方式（Augmented BNF），並依賴於該文件對非終端（non-tenals）的定義及對其它方面的描述。

 

1.2 訪問鑑別（Access Authentication ）

 

  HTTP提供了簡單的挑戰－回應鑑別機制，它可能被用來質詢客戶端請求，也可能被客戶端用來提供鑑別資訊。授權方案用可擴充套件的、大小寫敏感的符號來標識，後跟獲取證明所需要的以逗號分隔的‘屬性－值’對。

 

auth-scheme  = token

auth-param  = token "=" ( token | quoted-string )

 

  401（未授權）回應訊息被原始伺服器端用來質詢的授權。該回應必須包括含有至少一個被請求資源質詢（challenge）的WWW－鑑別標題域。407（需要鑑別代理）回應訊息被代理用來質詢客戶端的授權，它的代理鑑別標題域（-Authenticate header field）必須包括至少一個代理方（proxy）對被請求資源的質詢。

 

challenge  = auth-scheme 1*SP 1#auth-param

 

  注意：使用者代理（agent）解析WWW-鑑別（WWW-Authenticate）或代理-鑑別（Proxy-Authenticate）的標題域，在碰到含有多個質詢（）或多個WWW-鑑別標題域時，要特別小心，因為這些質詢本身可能就包含了以逗號分隔的鑑別引數對。

 

  鑑別引數realm的定義在所有的鑑別方案中使用：

 

realm  = "realm" "=" realm-value

realm-value   = quoted-string

 

 

 

 

 

 

 

 

Franks, et al.  Standards Track  [Page 3]

 

  Realm指示（大小寫敏感）在所有涉及質詢（challenge）的鑑別方案中都要用到。Realm值（大小寫敏感）要與被訪問伺服器的‘根’URL的規範用法（即絕對路徑為空的伺服器的絕對URI－absoluteURI，見5.1.2節[2]）聯合使用，以定義受保護的區間。這些realm引數允許將伺服器上受保護資源分成若干個區間，每個區間都有其自己的鑑別方案和（或）授權。Realm值是字串，通常由原始伺服器分配，針對某些鑑別方案可能還有附加的語法問題。注意，可能存在多個質詢（challenge），auth-scheme相同，而realm不同的情況。

 

通常，使用者代理（agent）在收到401（未授權）回應時，可能（也可能不會）希望伺服器對其授權。如果希望授權，使用者代理將在請求中加入授權請求標題（Authorization request-header）域。授權域值由信任證書組成，其中有對使用者代理所請求資源領域的授權資訊。客戶端在收到407（需要代理鑑別）回應時，如希望透過代理進行自身的鑑別，可在請求中加入代理授權請求標題域（Proxy-Authorization request-header）。授權域值和代理授權域值都是由信任組成，這些信任包括被請求資源的客戶端鑑別資訊realm的值。使用者代理（user agent）必須選用它所能理解的最強的auth-scheme及使用者回應質詢（challenge）的請求信任。

 

credentials = auth-scheme #auth-param

 

  注意，許多隻支援基本方案，要求它在auth-scheme中排在第一位。如果提供最低程度的滿意度，伺服器端應只支援基本方案。

 

  受保護區間定義了將要自動使用信任的區域。如果早先的請求已經透過，在由授權方案，引數和（或）使用者選擇等所指定的時間間隔內，其它的請求可透過相同的信任來訪問該保護區域。除非鑑別方案有特別指定，否則單個保護區域不能擴充套件到該伺服器以外的範圍。

 

  如果原始伺服器不希望透過傳送的請求來接受信任，它應當返回401（未授權）回應。該回應必須包括一個WWW-鑑別標題域，而該域要包含至少一個（可能是新的）對被請求資源的質詢（challenge）。如果代理（proxy）不接受用請求方式傳送信任，它應當返回407（需要代理鑑別）回應。該回應必須包括一個代理鑑別（Proxy-Authenticate）標題域，而該域要包含至少一個（可能是新的），代理可用的，對被請求資源的質詢。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Franks, et al.  Standards Track  [Page 4]

 

的訪問鑑別並不限於這種簡單的質詢回應（challenge-response）機制，還可以使用其它的方法，比如傳輸級或訊息封裝及透過附加標題域來指定鑑別資訊等等。但是，這些方法不在本文件的討論範圍。

 

  代理（proxy）必須完全透明地處理原始伺服器對使用者代理（user agent）的鑑別，也就是說，它們必須在不做任何改動的前提下將WWW-鑑別和授權標題向前推送，這方面的規定見[2]的14.8節。代理-鑑別（WWW-Authenticate）和代理-授權（Proxy-Authorization）標題域都是hop-by-hop標題（見[2]的13.5.1節）。

 

 

2 基本鑑別方案（Basic Authentication Scheme）

 

使用者代理必須對於每個領域（realm）透過使用者標識（user-ID）及口令來對自身進行授權，這是基本授權方案的工作。Realm值應當被看作不透明的字串，該值將用於同伺服器端其它的realm值相比較。只有使用者標識及口令透過受保護資源的認證，伺服器才會給請求授權。授權引數沒有可選項。

 

  對於基本方案，上面所述框架的應用形式如下：

 

challenge  = "Basic" realm

credentials   = "Basic" basic-credentials

 

在接收到對受保護區域的未經認證的資源請求時，伺服器應當回應一個質詢（challenge），如下：

 

WWW-Authenticate: Basic realm="WallyWorld"

 

  “WallyWorld”是由伺服器分配的字串，用於對請求URI所指定的受保護資源進行標識。代理也應使用使用Proxy-Authenticate標題域來回應同樣的質詢。

 

  為了接收授權，客戶端需要在基於64位（base64 [5]）的證書中傳送使用者標識及口令，中間用冒號’:’分隔。

 

basic-credentials   = base64-user-pass

base64-user-pass  =

      except not limited to 76 char/line>

 

 

 

 

 

 

 

Franks, et al.  Standards Track  [Page 5]

user-pass  = userid ":" pass

userid  = *

password  = *TEXT

 

  Userids可能是大小寫敏感的。

 

如果使用者代理希望傳送使用者標識”Aladdin”和口令“open sesame”，應當遵循下面的標題域形式：

 

  Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

 

  客戶端應當假定請求URI中所涉及的所有其它路徑都在由當前質詢的基本realm值所指定的保護空間中。客戶端在未收到伺服器的其它質詢時，可能會優先傳送對應於該空間資源的授權標題。同樣，當客戶向代理（proxy）傳送請求，它也可能在未收到代理伺服器的其它質詢之前，在代理授權（Proxy-Authorization）標題域中還使用原來的uerid和password。詳情參見[考慮]的第4節中與基本鑑別相關的內容。

 

3 分類訪問鑑別方案（Digest Access Authentication Scheme）

 

3.1 介紹（Introduction）

 

3.1.1 目的（Purpose）

 

 

  “HTTP/1.0”中包括基本訪問鑑別方案（Basic Access Authentication scheme[1]）。該方案不是安全的使用者鑑別方法，因為其使用者名稱和口令在上是以明文方式傳送的。本節提供不以明文方式傳送口令的方案規範，參見”分類訪問鑑別”。

 

  分類訪問鑑別（Digest Access Authentication）方案不是WWW安全問題的最終解決方案。該方案不提供訊息內容的加密，其目的只是建立一個簡單的鑑別方法，以彌補基本鑑別方案中存在的大部分嚴重。

 

3.1.2 操作概述（Overall Operation）

 

  和基本訪問鑑別相似，分類方案基於簡單的挑戰－回應範例。分類方案使用nonce值來質詢（challenge）。合法的回應包含對使用者名稱、口令、給定nonce值、HTTP方法、請求URI的校驗和（checksum，預設是MD5的校驗和），因此，口令不會以明文方式傳送。有些基本方案要求將使用者名稱及口令預先排成一定的格式（不在本文範圍）後再行使用。

 

 

 

 

 

Franks, et al.  Standards Track  [Page 6]

 

3.1.3 分類值的表示（Representation of digest values）

 

  可選的標題，允許伺服器指定用來建立校驗和或分類的演算法。MD5是預設的方法，而且也是本文唯一提及的演算法。

 

  在本文中，128位的MD5分類由32個可列印的ASCII碼字元表示。128位分類中的位按其重要性由高到低轉換，在某個時刻每4位可用下面的ASCII表示。每4位都可用16進位制字元‘0123456789abcdef’表示，也就是說，二進位制0000由字元‘0’表示；0001由字元‘1’表示，以後如此類推，1111用‘f’表示。

 

3.1.4 侷限性（Limitations）

 

  本文中描述的分類鑑別方案存在許多已知的侷限性，它只是對基本鑑別方案的替代，除此外，別無他用。它是基於口令認證的，在伺服器端也要面對任何其它口令系統同樣存在的問題。本協議並沒有為最初使用者和伺服器間的口令建立提供安全做法。

 

  使用者和開發者都應注意，該協議並不象Kerberos或任何客戶端的私鑰方案那樣安全。但是，即便它一無是處，總還比在、用的機制好一些，當然，也比基本方案安全。

 

3.2 分類標題的規範（Specification of Digest Headers）

 

  分類訪問鑑別方案在概念上與基本方案相似。更改的WWW-鑑別標題行和授權標題行的格式在下面給出。另外，還有個新的標題，即Authentication-Info，也在下面指定。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Franks, et al.  Standards Track  [Page 7]

 

3.2.1 WWW-鑑別回應標題（The WWW-Authenticate Response Header）

 

  伺服器在收到對受保護未經認證的訪問請求時，會回應401（未授權）狀態碼。在分類方案中，WWW-鑑別標題應遵循如下寫法：

 

challenge    =  "Digest" digest-challenge

 

digest-challenge = 1#( realm | [ ain ] | nonce |

  [ opaque ] |[ stale ] | [ algorithm ] |

  [ qop-options ] | [auth-param] )

 

 

domain    = "domain" "=" URI ( 1*SP URI )

URI     = absoluteURI | abs_path

Nonce    = "nonce" "=" nonce-value

nonce-value    = quoted-string

opaque    = "opaque" "=" quoted-string

stale     = "stale" "=" ( "true" | "false" )

algorithm    = "algorithm" "=" ( "MD5" | "MD5-sess" |

   token )

qop-options    = "qop" "=" 1#qop-value

qop-value    = "auth" | "auth-int" | token

 

  上面表示值的意思如下：

 

realm

顯示給使用者看的字串，這樣他們就知道使用哪個使用者名稱和口令了。該字串應當包括至少一個鑑別的主機名和對可能訪問使用者群體的附加指示。例如：

 

to:registered_users@gotham.news.com">registered_users@gotham.news.com

 

domain

指在引號中用空格分隔的URI列表（見 XURI[7]中定義的保護區間）。如果URI是採用絕對路徑，它是相對於被訪問伺服器‘根’的URL（見上面1.2節）。該列表中的絕對URI被用來訪問另外一個不同的伺服器。客戶端可傳送同樣的鑑別資訊來訪問由此列表確定的URI集合：任何URI，只要其做為字首出現在列表中，就可以認為它指向同樣的受保護區域。如果表示被忽略或是空值，客戶端應這樣理解，即，該保護區域由回應伺服器的全部URI組成。

 

 

 

 

 

Franks, et al.  Standards Track  [Page 8]

 

該表示對代理-鑑別（Proxy-Authenticate）標題沒有意義，因為對它們來說，受保護區域總是整個代理（proxy），如果出現，也會被忽略。

 

nonce

伺服器端指定的資料字元，它應在每個401回應產生時，被唯一地建立。建議該字元以base64方式或16進位制方式出現。另外，該字元在標題行中傳遞時是在引號內的，因此允許使用雙引號字元。

其內容與實現無關，而其實現的質量取決於良好的選擇。例如，nonce可能以基於64位編碼來構造，如下例：

 

time-stamp H(time-stamp ":" ETag ":" private-key)

 

如上，時間戳（time-stamp）是由伺服器產生的時間值或其它非重複值；Etag是HTTP 與請求實體相關的ETag標題的值；private-key是隻有伺服器才知道的值。在碰到這種形式的nonce時，伺服器在收到客戶鑑別標題後，會對雜湊部分進行重新計算，並在nonce值與標題不符或其time-stamp值不夠新時拒絕該請求。透過這種方式，伺服器端可以限制nonce合法的時間範圍。Etag中的內容將防止對資源的版本進行重複請求。（注意：在nonce中包括客戶端的將向伺服器提出要求，即不要再重用同樣客戶發出的nonce值。實際上，單個使用者發出的請求會穿越多個代理，這樣做可能導致該過程的中斷。另外，IP地址也是可以假冒的）

 

有的實現可能會選擇不接受先前先用的nonce或先前使用的分類，以防止回放式（replay attack）。或者，實現在回應POST｜PUT請求時，也可以選擇以前的nonce或分類（digest）和GET請求的time-stamp。更詳細的資訊，見本文第4節。

 

nonce是客戶端的opaque。

 

opaque

由伺服器指定的字串，客戶端不能改動它，如果併發請求的URI也指向同一個受保護區間，則該資訊將被加在這些請求的授權標題域中返給伺服器。建議採用base64或16進位制的字串。

 

 

 

 

 

 

 

 

 

 

 

 

Franks, et al.  Standards Track  [Page 9]

 

stale

一個標誌，用來指示客戶端先前的請求因其nonce值過期而被拒絕。如果stale是TRUE（大小寫敏感），客戶端可能希望用新的加密回應重新進行請求，而不用麻煩使用者提供新的使用者名稱和口令。伺服器端只有在收到的請求nonce值不合法，而該nonce對應的分類（digest）是合法的情況下（即客戶端知道正確的使用者名稱/口令），才能將stale置成TRUE值。如果stale是FALSE或其它非TRUE值，或者其stale域不存在，說明使用者名稱、口令，要求輸入新的值。

 

algorithm

是個字串，用來指示用來產生分類及校驗和的演算法對。如果該域沒指定，則認為是“MD5“演算法。如果該域指定的演算法無法理解，該質詢（challenge）將被忽略。

 

在本文中，用KD（secret,data）來表示分類演算法，其中data指資料，secret表示採用的方法.如果表示校驗和演算法時，data要寫成H（data）；而unq（X）表示將帶引號字串的引號去掉。

 

  對於"MD5" 和"MD5-sess" 演算法：

 

H(data) = MD5(data)

和

 

KD(secret, data) = H(concat(secret, ":", data))

也就是說，分類（digest）就是對secret與data透過冒號連線一起的結果進行MD5運算。而"MD5-sess"演算法則允許其它第三方伺服器參與鑑別。具體用法的區別，參見3.2.2.2節的描述。

 

qop-options

該表示是可選的，用於RFC2069[6]的向後相容。它應當被與該分類方案版本相容的任何實現所使用。如果存在，它是帶引號的一個或多個字元組成的字串，用來指示伺服器支援的保護水平（quality of protection）值。”auth”值表示鑑別方式；”auth-int”表示鑑別保護的完整性；見後面為有該項選擇的應用重新計算回應指示值。不能識別的選項必須被忽略。

 

 

 

 

 

 

 

 

 

 

 

Franks, et al.  Standards Track   [Page 10]