XMPP 3920 最靠譜的中文翻譯文檔（四）

XMPP 3920 最靠譜的中文翻譯文檔（四）

2009-10-17 19:55

6．使用SASL
6．1 概述
       XMPP包含一個認證流的方法，此方法依靠一個簡單認證與安全層（SASL）協議[SASL]的XMPP-specific profile。SASL提供一個一般化方法，用於給基於連接的協議加認證支持，並且，XMPP使用一個一般化XML命名空間profile，用於SASL，遵從[SASL]的profiling需求。

       以下規則應用：
       1） 如果兩個服務器間發生SASL協商，直到由服務器宣稱的域名系統（DNS）主機名被解析了（參考服務器到服務器通信（14.4）），通信纔可處理。
       2） 如果實始實體能夠進行SASL協商，，它必須在初始流頭中包含值至少爲“1.0”的版本屬性。
       3） 如果接收實體能夠進行SASL協商，它必須在一個<mechanisms/>元素中廣告一個或多個認證機制，此元素靠'urn:ietf:params:xml:ns:xmpp-sasl'命名空間響應從初始實體（如果開放流標記包含所設值至少爲“1.0”的版本屬性）接收的開放流標記認證。
       4） 在SASL協商期間，實體不準在根流元素中發送任何空白字符（匹配[XML]內容，產品[3]）作爲元素間（任何在SASL例子中的空白字符都只是爲了便於閱讀）的分隔符；這種限制有助於確保合適的安全層字節精度。
       5） 任何包含在XML元素中的XML字符數據，在SASL協商期間使用，必須使用base64編碼，編碼在RFC3548第三節有定義。
       6） 如果所提供的一個“簡單用戶名”能夠被選定SASL機制（例：由DIGEST-MD5與CRAM-MD5機制所支持，但不靠EXTERNAL與GSSAPI機制所支持）所支持，在認證期間，初始實體應當作爲簡單用戶名提供它的發送域（IP地址或包含在域標識符中的全認證域名）在服務器對服務器的通信情況下，或是它的已註冊帳戶名（包含在XMPP結點標識符中的用戶或結點名）在客戶到服務器的通信情況下。
       7） 如果初始實體希望代表其它實體與支持授權身份傳輸的被選SASL機制來行動，初始實體在SASL協商期間必須提供一個授權身份。如果初始實體不希望代表另一個實體行動，它不準提供一個授權身份。正如[SASL]中指定的，初始實體不準提供一個授權身份，除非一個授權身份不同於缺省授權身份，此缺省授權身份派生於描述在[SASL]中的認證身份。如果提供了，授權身份值對服務器來說必須是<domain>值形式（例：只有一個域標識符），對客戶端來說，必須是<node@domain>值形式（例：結點標識符與域標識符）。
       8） 靠涉及到安全層協商的SASL協商的成功，接收實體必須拋棄來自本身沒有獲得SASL協商的初始實體的任何知識。
       9） 靠涉及到安全層協商的SASL協商的成功，初始實體必須拋棄來自本身沒有獲得SASL協商的接收實體的任何知識。
       10） 參考必須被支持的相關機制的強制實施技術（14.7）。

6．2敘述
       當初始實體使用SASL認證接收實體時，步驟如下：
       1） 初始實體請求SASL認證，通過在開放XML流頭中包含版本屬性，並將其發送給接收實體，屬性值設爲“1.0”。
       2） 發送一個XML流頭作爲迴應後，接收實體廣告一個可利用的SASL認證機制列表；列表中每一項都是一個<mechanism/>元素，作爲<mechanism/>容器元素的子元素，由'urn:ietf:params:xml:ns:xmpp-sasl'命名空間認證，在流命名空間中，依次是<features/>元素的子元素。如果使用TLS（5）需要在一個特別認證機制可能使用之間建立，接收實體不準提供在TLS協商之前的可利用SASL認證機制列表中的機制。如果初始實體在TLS協商之前出示了有效證書，接收實體應當在SASL協商（參考[SASL]）之間，提供SASL EXTERNAL機制給初始實體，雖然EXTERNAL機制可能在其它環境下被提供了。
       3） 初始實體選擇一個機制，靠發送一個已被'urn:ietf:params:xml:ns:xmpp-sasl'命名空間認定爲合格的<auth/>元素給接收實體，併爲‘mechanism’屬性包含一個合適的值。如果此機制需要XML字符數據，此元素可能包含XML字符數據（在SASL術語中，“初始響應”）；如果初始實體需要發送一個0長度的初始響應，它必須按一個單等號符號（“=”）傳輸此響應，意味着響應出現，但不包含數據。
       4） 如果需要，接收實體靠發送一個<chanllenge/>元素來挑戰實始實體，此元素由給初始實體的'urn:ietf:params:xml:ns:xmpp-sasl'命名空間來限定；此元素可能包含XML字符數據（必須根據由初始實體選擇的SASL機制的定義一致的來計算）。
       5） 初始實體響應此挑戰，靠發送由'urn:ietf:params:xml:ns:xmpp-sasl'命名空間限定的<response/>元素給接收實體；此元素可能包含XML字符數據（必須根據由初始實體選擇的SASL機制的定義一致的來計算）。
       6） 如果需要，接收實體發送更多的挑戰，初始實體發送更多的響應。

       Challenge/response序列對繼續，直到以下三種事情之一發生：
       1） 初始實體終止握手，靠發送一個由'urn:ietf:params:xml:ns:xmpp-sasl'命名空間限定的<abort/>元素給接收實體。根據接收一個<abort/>元素，接收實體應當允許一個可配置的但合理的重試號（至少2），之後，必須終止TCP連接；這使初始實體（例：一個終端用戶客戶端）能夠忍受已提供的不正確的信任（例：一個錯誤類型的password）而不用被迫重連。
       2） 接收實體報告握手失敗，靠發送一個由'urn:ietf:params:xml:ns:xmpp-sasl'命名空間限定的<failure/>元素給初始實體（失敗的特殊原因應當以<failure/>元素的子元素進行通信，<failure/>元素定義在SASL錯誤中（6.4））。如果錯誤情況發生，接收實體應當允許一個可配置的，但合理的重試號（至少2），之後，它必須終止TCP連接；這使初始實體（例：一個終端用戶客戶端）能夠忍受已提供的不正確的信任（例：一個錯誤類型的password）而不用被迫重連。
       3） 接收實體報告握手成功，靠發送一個由'urn:ietf:params:xml:ns:xmpp-sasl'命名空間限定的<success/>元素給初始實體；此元素可能包含XML字符數據（在SASL術語中，“additional data with success”），如果需要靠選定的SASL機制。根據接收的<success/>元素，初始實體必須靠發送一個開放的XML流頭去初始化一個新流給接收實體（它不必事先發送一個關閉</stream>標記，因爲接收實體與初始實體必須考慮源流根據發送或接收<success/>元素而將被關閉）。根據從初始實體接收的新流頭，接收實體必須發送一個新XML流頭給初始實體作爲響應，並帶有任何可利用的特徵（但並不包含STARTTLS與SASL特徵）或一個空<features/>元素（重要表示沒有其它特徵可利用）；任何那種其它在此未定義的特徵必須由XMPP的相關擴展來定義。

6．3 SASL定義
       [SASL]的profiling需求要求協議定義提供以下信息：
       服務名：“xmpp”
       初始序列：初始實體提供一個開放XML流頭後，並且接收實體按此響應後，接收實體提供一個可接收的認證方法列表。初始實體從列表中選擇一個方法並作爲‘machanism’屬性值發送給接收實體，此屬性被<auth/>元素擁有，隨意的包括一個初始響應以避免環路。
       交換序列：挑戰與響應通過由接收實體到初始實體<challenge/>元素的交換與由初始實體到接收實體的<response/>元素的交換而執行。接收實體靠發送一個<failure/>元素報告錯誤，發送一個<success/>元素報告成功；初始實體靠發送<abort/>元素終止交換。根據成功協商，兩端都認爲源XML流將被關並且新流頭由兩端實體發送。
       安全層協商：安全層在爲接收實體發送<success/>元素的關閉“>”字符後立即有效，安全層在爲初始實體發送<success/>元素的關閉“>”字符後立即有效。層順序爲：首先是[TCP]，然後是[TLS]，然後是[SASL]，然後是XMPP。
       使用授權身份：授權身份可以被XMPP用於指示客戶端非缺省<node@domain>或服務器發送<domain>。

6．4 SASL錯誤
       以下是SASL相關錯誤條件的定義：（略）
1）<aborted/>--
2）<incorrect-encoding/>--
3）<invalid-authzid/>--
4）<invalid-mechanism/>--
5）<mechanism-too-weak/>--
6）<not-authorized/>--
7）<temporary-auth-failure/>--

6．5 客戶端到服務器的例子
       以下例子顯示了使用SASL授權的客戶端與服務器端的數據流，正常情況下，是在TLS協商（注：顯示在下面的替換步驟用於顯示錯誤情況的協議；他們並不詳盡也不是必要的由本例中數據發送而觸發。）成功之後。

步1：客戶端初始流給服務器：
   <stream:stream
       xmlns='jabber:client'
       xmlns:stream='http://etherx.jabber.org/streams'
       to='example.com'
       version='1.0'>
步2：服務器使用一個流標記作爲響應發送給客戶端：
   <stream:stream
       xmlns='jabber:client'
       xmlns:stream='http://etherx.jabber.org/streams'
       id='c2s_234'
       from='example.com'
       version='1.0'>
步3：服務器通知客戶端可利用的認證機制：
   <stream:features>
     <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
       <mechanism>DIGEST-MD5</mechanism>
       <mechanism>PLAIN</mechanism>
     </mechanisms>
   </stream:features>
步4：客戶端選擇一個認證機制：
   <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
         mechanism='DIGEST-MD5'/>
步5：服務器發送一個[BASE64]編碼挑戰給客戶端：
   <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>   cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg==
   </challenge>
解碼挑戰是：
   realm="somerealm",nonce="OA6MG9tEQGm2hh",/
   qop="auth",charset=utf-8,algorithm=md5-sess
步5（替換）：服務器返回錯誤給客戶端：
   <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
     <incorrect-encoding/>
   </failure>
   </stream:stream>
步6：客戶端發送一個[BASE64]編碼響應挑戰：
   <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i
T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw
MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i   LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNoYXJzZXQ9dXRmLTgK
   </response>
步7：服務器發送另一個[BASE64]編碼挑戰給客戶端：
   <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
   cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo=
   </challenge>
解碼挑戰是：
   rspauth=ea40f60335c427b5527b84dbabcdfffd
步7（替換）：服務器返回錯誤給客戶端：
   <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
     <temporary-auth-failure/>
   </failure>
   </stream:stream>
步8：客戶端響應挑戰：
   <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
步9：服務器通知客戶端認證成功：
   <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
步9（替換）：服務器通知客戶端認證失敗：
   <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
     <temporary-auth-failure/>
   </failure>
   </stream:stream>
步10：客戶端初始化一個新流給服務器：
   <stream:stream
       xmlns='jabber:client'
       xmlns:stream='http://etherx.jabber.org/streams'
       to='example.com'
       version='1.0'>
步11：服務器通過發送流頭來響應客戶端，伴隨有任意另外的特徵（或空特徵元素）：
   <stream:stream
       xmlns='jabber:client'
       xmlns:stream='http://etherx.jabber.org/streams'
       id='c2s_345'
       from='example.com'
       version='1.0'>
   <stream:features>
     <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
     <session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>
   </stream:features>

6．6服務器到服務器的例子
       以下例子顯示服務器與服務器使用SASL認證的數據流，正常情況下，是在TLS協商之後（注：以下可替換步驟是由失敗情況提供的；他們不是詳盡的也不是必要的由數據發送而觸發）。

步1：Server1初始化流給Server2：
   <stream:stream
       xmlns='jabber:server'
       xmlns:stream='http://etherx.jabber.org/streams'
       to='example.com'
       version='1.0'>
步2：Server2發送一個流標記響應Server1：
   <stream:stream
       xmlns='jabber:server'
       xmlns:stream='http://etherx.jabber.org/streams'
       from='example.com'
       id='s2s_234'
       version='1.0'>
步3：Server2通知Server1可利用的認證機制：
   <stream:features>
     <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
       <mechanism>DIGEST-MD5</mechanism>
       <mechanism>KERBEROS_V4</mechanism>
     </mechanisms>
   </stream:features>
步4：Server1選擇一個認證機制：
   <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
         mechanism='DIGEST-MD5'/>
步5：Server2發送一個[BASE64]編碼挑戰給Server1：
   <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9
   ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz
   </challenge>
編碼挑戰是：
   realm="somerealm",nonce="OA6MG9tEQGm2hh",/
   qop="auth",charset=utf-8,algorithm=md5-sess
步5（替換）：Server2返回錯誤給Server1
   <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
     <incorrect-encoding/>
   </failure>
   </stream:stream>
步6：Server1發送[BASE64]編碼響應挑戰：
   <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
   dXNlcm5hbWU9ImV4YW1wbGUub3JnIixyZWFsbT0ic29tZXJlYWxtIixub25j
   ZT0iT0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5j
PTAwMDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5vcmciLHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNoYXJzZXQ9dXRmLTgK
   </response>
解碼響應是：
   username="example.org",realm="somerealm",/
   nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",/
   nc=00000001,qop=auth,digest-uri="xmpp/example.org",/
   response=d388dad90d4bbd760a152321f2143af7,charset=utf-8
步7：Server2發送另一個[BASE64]編碼挑戰給Server1：
   <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
   cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo=
   </challenge>
解碼挑戰是：
   rspauth=ea40f60335c427b5527b84dbabcdfffd
步7（替換）：Server2返回錯誤給Server1：
   <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
     <invalid-authzid/>
   </failure>
   </stream:stream>
步8：Server1響應挑戰：
   <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
步8（替換）：Server1終止協商：
   <abort xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
步9：Server2通知Server1成功認證：
   <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
步9（替換）：Server2通知Server1認證失敗：
   <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
     <aborted/>
   </failure>
   </stream:stream>
步10：Server1初始化一個新流給Server2：
   <stream:stream
       xmlns='jabber:server'
       xmlns:stream='http://etherx.jabber.org/streams'
       to='example.com'
       version='1.0'>
步11：Server2通過發送一個流頭響應Server1，並伴隨着其它特徵（或空特徵元素）：
   <stream:stream
       xmlns='jabber:client'
       xmlns:stream='http://etherx.jabber.org/streams'
       from='example.com'
       id='s2s_345'
       version='1.0'>
   <stream:features/>

7．資源綁定
         接收實體SASL協商（6）之後，初始實體可能想要或是需要綁定一個特殊資源至那個流。普通的，這僅用於客戶端：爲了遵從在此指定的尋址格式（3）與節傳送規則（10），必須有一個資源標識符聯合客戶端的<node@domain>（即可以由服務器產生也可以由客戶應用提供）；這確保基於流使用的地址是“全JID”形式<node@domain/resource>。

         根據在SASL協商中接收的一個成功指示，客戶端必須發送一個新流頭給服務器，服務器必須用可利用流特徵列表中的內容來響應。特別的，如果服務器需要客戶端在SASL成功協商後，將資源綁定到流上，它必須包括一個由在流特徵列表中的'urn:ietf:params:xml:ns:xmpp-bind'命名空間限定的空<bind/>元素。成功SASL協商後（不是前），它通過發送響應流的頭表示給客戶端：

服務器廣告資源綁定特徵給客戶端：
   <stream:stream
       xmlns='jabber:client'
       xmlns:stream='http://etherx.jabber.org/streams'
       id='c2s_345'
       from='example.com'
       version='1.0'>
   <stream:features>
     <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
   </stream:features>

         根據這樣的通知，資源綁定是需要的，客戶端必須靠送給服務器一個包含由'urn:ietf:params:xml:ns:xmpp-bind' 命名空間限定的，類型“set”（參考IQ語義（9.2.3））的IQ節，將資源綁定到流上。

         如果客戶端希望允許服務器代表自己產生資源標識符，它發送一個類型“set”的IQ節，包含一個空<bind/>元素：

         客戶端請求服務器綁定資源：
   <iq type='set' id='bind_1'>
     <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
   </iq>

         支持資源綁定的服務器必須能代表一個客戶端產生一個資源標識符。由服務器產生的資源標識符必須對<node@domain>是唯一的。如果客戶端希望指定資源標識符，它發送一個類型爲“set”的IQ節，包含所需資源的標識符，作爲<bind/>元素子元素<resource/>的XML字符數據。

         客戶端綁定一個資源：
   <iq type='set' id='bind_2'>
     <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
       <resource>someresource</resource>
     </bind>
   </iq>

         一旦服務器爲客戶端產生了一個資源標識符或是接受了由客戶端提供的資源標識符，它必須返回一個類型爲“result”的IQ節給客戶端，必須包含一個<jid>子元素，來爲服務器決定的已連接資源指定全JID：

         服務器通知客戶端成功資源綁定：
   <iq type='result' id='bind_2'>
     <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
       <jid>[email protected]/someresource</jid>
     </bind>
   </iq>

         服務器應當接受由客戶端提供的資源標識符，但可能用一個服務器產生的資源標識符覆蓋它；在這種情況，服務器不應當返回一個節錯誤（例：<forbidden/>）給客戶端，取而代之，應當以以上顯示的IQ結果，傳達產生的資源標識符給客戶端。

         當客戶端提供一個資源標識符，以下節錯誤條件是可能的（參考節錯誤（9.3））：
1） 提供的資源標識符不能被與Resourceprep（附錄B）一致的服務器處理。
2） 客戶端不允許綁定資源到流上（例：因爲結點或用戶已經達到了在被允許的連接的資源的數目）。
3） 已提供資源標識符已經使用，但服務器並不允許用同樣的標識符綁定多連接資源。

         用於這些錯誤條件的協議顯示如下。

         資源標識符不能被處理：
   <iq type='error' id='bind_2'>
     <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
       <resource>someresource</resource>
     </bind>
     <error type='modify'>
       <bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
     </error>
   </iq>

         客戶端不允許綁定資源：
   <iq type='error' id='bind_2'>
     <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
       <resource>someresource</resource>
     </bind>
     <error type='cancel'>
       <not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
     </error>
   </iq>

         資源標識符在使用：
     <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
       <resource>someresource</resource>
     </bind>
     <error type='cancel'>
       <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
     </error>
   </iq>

         如果，完成資源綁定步驟之前，客戶端嘗試發送一個XML節，而不只是一個帶有由'urn:ietf:params:xml:ns:xmpp-bind'命名空間限定的<bind/>子元素的IQ節，服務器不準處理此節，並且，應當返回一個<not-authorized/>節錯誤給客戶端。

http://hi.baidu.com/xboxsky/blog/item/1255ce1b18b1a3f0ae513308.html