針對LDAP的驗證方法

備忘錄狀況
這份文檔為Inte.net社區指定為Internet標準（軌跡）協議，并且為進一步改進需要討論
和建議。這份協議的標準化狀態和狀況請參閱"Internet官方協議標準（InternetOfficialProtocol
Standards）"(STD1)的當前版。這份備忘錄的分發不受限制。

版權聲明
Copyright(C)TheInternetSociety(2000)。版權所有。

摘要
這篇文檔針對在LDAP[1]實現工具（implementations）中被需求和推薦的安全機制
（securitymechanisms）的特定結合。



目錄
0.譯者的話 2
1.引論 3
2.樣例展開腳本（Exampledeploymentscenarios） 4
3.認證和授權：定義和概念 5
3.1.存取控制策略Aclearcase/" target="_blank" >ccessControlPolicy 5
3.2.存取控制因素AccessControlFactors 5
3.3.認證（Authentication）、證明（Credentials）、身份標識（Identity） 5
3.4.授權身份標識（AuthorizationIdentity） 6
4.必須的安全機制 6
5.匿名認證 7
5.1.匿名認證過程 8
5.2.匿名認證和TLS 8
6.基于口令的認證 8
6.1.文摘認證 8
6.2.TLS加密下的簡單認證選擇（"simple"authenticationchoice） 9
6.3.隨TLS的其它認證選擇 9
7.基于證書的認證（Certificate-basedauthentication） 10
7.1.隨TLS基于證書的認證 10
8.其他機制 10
9.授權標識 11
10.TLS密碼適配組 12
11.對于LDAP的SASL服務名字 13
12.安全考慮 13
13.確認 13
14.文獻 13
15.作者的地址 14
16．完整版權聲明 15
確認 16

0.譯者的話
譯者在翻譯這份文檔的時候，采取直譯的方式，盡量保證原文的原意。同時也盡量考慮
了中文的語義順暢，便于中文讀者閱讀，譯者在譯文中加入了一些修飾語和譯注，修飾語一
般在括號中寫明，而譯注均有“譯者注”字樣。由于譯者翻譯本篇文擋時間有限，譯文中一
定會存在許多理解有誤、用詞不當之處，歡迎讀者來信指正，共同學習。

1.引論
LDAP版本3是針對目錄（服務）功能強大的訪問協議。

它提供了搜索（searching）、獲?。╢etching）和操作（manipulating）目錄內容的方
法，以及豐富的安全函數集合的訪問方法。

為了Internet運轉的更好，這些安全功能能夠很好的交互是至關重要的（vital）；因
此應該存在一個對所有需求LDAPv3一致性的工具（LDAPv3）通用的最小安全功能子集。

對LDAP目錄服務基本的威脅包括：

(1)通過數據獲?。╠ata-fetching）操作非特許存取數據，

(2)通過監聽（monitoring）其他的訪問（通道）非特許存取可再用的客戶（身份）
證明信息，

(3)通過監聽其他的訪問（通道）非特許存取數據，

(4)未經授權的數據修改，

(5)未經授權的配置修改，

(6)未經授權的或者過分的資源使用（拒絕服務），以及

(7)目錄的電子欺騙：欺騙客戶（client）相信信息來自目錄（directory）而實際
上沒有，或者在轉接中修改數據或者錯誤指引客戶的連接。

威脅(1),(4),(5)和(6)針對惡意的（hostile）客戶（clients）。威脅(2),(3)和(7)
針對惡意的在客戶端和服務端（傳輸）路徑上的代理，或者冒充服務端。

LDAP協議組（protocolsuite）能通過下面的安全機制得到保護：

(1)客戶（身份）證明利用SASL[2]機制設置，或者依靠（backedby）TLS證明擴
展機制，

(2)客戶授權利用依靠于請求者證明的身份（標識）存取控制，

(3)數據完整性保護（Dataintegrity）利用TLS協議或者數據完整（data-integrity）
SASL機制，

(4)避免窺探者（snooping）損害的保護利用TLS協議或者數據加密
（data-encrypting）SASL機制，

(5)資源限制利用基于服務控制（servicecontrols）的管理限制，以及

(6)服務（身份）證明利用TLS協議或者SASL機制。

譯者注：SASL：SimpleAuthenticationandSecurityLayer

同時，存取控制的強制（執行）（imposition）利用LDAP協議范圍以外的（機制）完成。

在本文中，術語"user"代表其是使用目錄獲取或者存儲信息的LDAP客戶的任何應用
（application）。

在本文中的關鍵字"MUST","MUSTNOT","REQUIRED","SHALL","SHALLNOT","SHOULD",
"SHOULDNOT","RECOMMENDED","MAY",和"OPTIONAL"在RFC2119[3]中的描述來作解釋。

2.樣例展開腳本（Exampledeployment
scenarios）
下面的腳本是在Internet上針對LDAP目錄服務的典型的有不同安全需求的樣例。(在下
面的樣例中，"sensitive"（敏感的）意味著數據如果暴露（revealed）將對擁有者帶來真正
的損害；也有受保護的數據但不是敏感的)。這里不是為了列舉廣泛的綜合的腳本為目的，其
他腳本是可能的，特別是在物理保護的網絡上。

(1)只讀目錄（服務），不包含敏感數據，對任何人（"anyone"）訪問公開，并且
TCP連接攔截或者IP欺騙不是問題。這個目錄不需要安全功能，除非管理服務
的限制。

(2)只讀目錄（服務）不包含敏感數據；讀訪問基于身份（標識）授權。TCP連接
攔截在當前不是問題。這個腳本需要安全認證（authentication）功能。

(3)只讀目錄（服務）不包含敏感數據；并且客戶（程序）需要確保目錄數據是經
過服務（程序）驗證的和在從服務（程序）返回中沒有修改。

(4)讀寫目錄（服務），不包含敏感數據；讀訪問對任何人（"anyone"）有效，更新
訪問只針對適當授權的人。TCP連接攔截當前不是問題。這個腳本需要安全認
證功能。

(5)目錄包含敏感數據。這個腳本需要會話（session）秘密性保護和（AND）安全
認證。

3.認證和授權：定義和概念
這部分定義基本的術語，概念，和認證（authentication）、授權（authorization）、證
明（credentials）及身份（標識）（identity）相關狀態（interrelationships）。這些概念
被使用在描述客戶（程序）認證和授權中利用的多少種不同的安全進路（approaches）。

3.1.存取控制策略AccessControlPolicy
存取控制策略是定義資源的保護、個人或者其他實體（entities）存取這些資源能力的
術語通常規則。存取控制策略的公用表達式（commonexpression）是存取控制表（access
controllist）。安全的對象和機制，就像這里描述的那些能夠存取控制策略表達和實施
（enforcement）。存取控制策略是在下文描述的存取控制屬性術語的典型表示。

3.2.存取控制因素AccessControlFactors
一個請求，當被服務（程序）處理過的時候，可以和各種各樣的安全相關
（security-related）因素關聯（參見[1]中部分4.2）。服務（程序）使用這些因素決定是
否或者如何處理請求。這些被稱作存取控制因素（ACFs）。他們將包括源IP地址、加密強度
（encryptionstrength）、被請求操作的類型、時間日期等等。一些因素可以針對請求自身
所有，其他可以是通過請求被傳送的連接關聯、另一些（例如，時間日期）可以是環境
（"environmental"）（相關的）。

存取控制策略是存取控制因素術語的表示。例如，請求有ACFs（存取控制因素）i,j,k
能夠執行在資源Z上的Y操作。這套術語其服務（程序）使這樣的表達可用（available）
是工具相關的（implementation-specific）。

3.3.認證（Authentication）、證明（Credentials）、身份
標識（Identity）
認證證明是通過一方提供給另一方的證據（evidence），斷言提供者一方（例如，一用戶）
的身份標識，其試圖與另一方（典型為一服務器）建立關聯。認證是產生（generating）、傳
遞（transmitting）和核實（verifying）這些證明的過程，這樣（它們）斷言了身份標識。
認證身份標識是存在于證明中的名字（name）。

存在許多認證證明的形式——使用的形式依賴于通過雙方協商的特定認證機制。例如：
X.509證書、Kerberostickets、簡單身份標識和口令對（passwordpairs）。注意認證機制
可以強制隨著它使用的認證身份標識的形式。

3.4.授權身份標識（AuthorizationIdentity）
授權身份標識是存取控制因素的一種。它是用戶或者其他實體的名字（name），其請求操
作被執行。存取控制策略經常表達在授權身份標識術語中；例如，實體X能夠在資源Z上執
行操作Y。

授權身份標識屬于一協會（boundtoanassociation），其經常與通過客戶提出的認證
身份標識完全地相同，但是它可以是不同的。SASL允許客戶具體指定在客戶證明中區別于認
證身份標識的授權身份標識。這個許可主體（permitsagents）正如使用它們自己的證明認
證的代理服務器（proxyservers），然而（要求）賦予它們的代理[2]請求身份標識的存取特
權（privileges）。另外，通過像TLS服務提供的認證身份標識的形式可以不相對于應用于明
確的服務存取控制協議的授權身份標識，需要服務特指映射（server-specificmapping）被
做。從客戶提供的認證證明中通過服務組成和生效的授權身份標識的方法是工具相關的
（implementation-specific）。

4.必須的安全機制
允許任何工具，面對上面的需求，在可以選擇的（安全機制）中選擇是不策略的
（strategy），很可能導致互操作性問題是很明顯的。在缺少授權（mandates）的情況下，客
戶（程序）將被記述（written）不支持任何服務（程序）支持的安全功能（function），或
者更壞，僅僅支持類似明文口令的機制其提供明顯不夠的（inadequate）安全。

主動中間攻擊（Activeintermediaryattacks）對攻擊者的（攻擊）執行是很困難的，
同時采用工具防止危害也是很困難的。在基于認識到（perceived）主動中間攻擊的危險下去
避免主動中間攻擊的危害所付出的代價的情況下，采取方法（Methods）僅僅避免敵對客戶
（hostileclient）和被動監聽攻擊（passiveeavesdroppingattacks）所帶來的危害是有
效的（useful）。

給定已存在的目錄，強烈要求看到獲得甄別名（DistinguishedName）的形式和能夠存
儲在目錄中的認證數據的身份（標識）機制；這意味著或者這個數據為了虛假的認證是無用
的（就像過去Unix使用的"/etc/passwd"文件格式），或者它的內容從來沒有通過無保護的線
路中——也就是說它或者更新（updated）協議的外面（outside）或者僅在會話中更新以很
好地避免了窺探者的危害。它也希望允許認證方法基于存在的用戶身份（標識）形式攜帶授
權身份標識，目的為了與non-LDAP-based認證服務向后兼容（backwardscompatibility）。

因此，下列工具的一致性需求（conformancerequirements）如下：

(1)對于只讀、公開目錄、匿名認證在部分5中描述，能被使用。

(2)工具提供基于口令（password-based）的認證訪問必須（MUST）支持使用
DIGEST-MD5SASL機制[4]的認證，在部分6.1中描述。這提供了客戶避免被動
監聽攻擊（passiveeavesdroppingattacks）的認證，但是沒有提供避免主動
中間攻擊。

(3)對于需要會話保護和認證的目錄，啟動TLS擴展操作[5]，和或者簡單認證選擇
或者SASLEXTERNAL機制，被一起使用。工具應該（SHOULD）支持在部分6.2
中描述的口令認證，和應該（SHOULD）支持在部分7.1中描述的證書認證。同
時，這些能提供完整性和傳輸數據的泄露保護，和客戶及服務的認證，包括避
免主動中間攻擊。

如果TLS是被協商的，客戶（程序）必須（MUST）丟棄所有先前TLS協商中獲得的關于
服務（程序）的信息。特別是，supportedSASLMechanisms的值可以（MAY）在TLS已經協商
之后不同（特別地，擴展（EXTERNAL）機制或者提出的明文（PLAIN）機制很可能僅在TLS
協商執行之后被列舉出來）。

如果SASL安全層（securitylayer）被協商，客戶（程序）必須（MUST）丟棄所有先前
SASL中獲得的關于服務（程序）的信息。特別是，如果客戶（程序）被配置為支持多（multiple）
SASL機制，它應該（SHOULD）在SASL安全層被協商之前和之后獲得supportedSASLMechanisms
并且驗證其值在SASL安全層協商之后沒有改變。這個探測從supportedSASLMechanisms列表
中移去支持的SASL機制的主動攻擊，并且允許客戶確保它使用的由客戶和服務都支持的最好
的機制（另外，這個應該（SHOULD）允許支持SASL機制列表的環境對客戶提供通過不同的信
任源（trustedsource），例如，數字簽名對象（digitallysignedobject）的一部分）。

5.匿名認證
其修改實體或者存取受保護的屬性或實體通常需要客戶的認證。沒有打算執行任何這些
操作的客戶典型的使用匿名認證。

LDAP工具必須（MUST）支持匿名認證，在部分5.1中定義。

LDAP工具可以（MAY）支持同TLS的匿名認證，在部分5.2中定義。

當可能（MAY）有存取控制限制（accesscontrolrestrictions）阻礙目錄實體的存取
時，LDAP服務應該（SHOULD）允許匿名綁定（anonymously-bound）的客戶檢索（retrieve）
根（root）DSE的supportedSASLMechanisms屬性。

LDAP服務可以（MAY）使用關于客戶通過低層（lowerlayers）（網絡協議）或者擴展的
授權（grant）或拒絕（deny）存取完全（控制）給匿名認證的客戶的其他信息。

5.1.匿名認證過程
一LDAP客戶其還沒有成功完成在連接之上的綁定操作是匿名地認證。

一LDAP客戶也可以（MAY）具體通過使用簡單的認證選擇的零長度（zero-length）OCTET
STRING綁定需求中指定匿名認證。

5.2.匿名認證和TLS
LDAP客戶（程序）可以（MAY）使用啟動TLS操作[5]去協商TLS安全的使用[6]。如果
客戶還沒有預先綁定，那么直到客戶使用EXTERNALSASL機制去協商客戶證書的識別
（recognition），客戶是匿名地認證。

推薦的TLS密碼組在部分10中給出。

LDAP服務在TLS協商過程中要求客戶提供它們的證書，如果客戶還沒有一個有效證書時，
可以（MAY）使用本地安全策略去決定是否成功地完成TLS協商。

6.基于口令的認證
LDAP工具必須（MUST）支持使用文摘MD5（DIGEST-MD5）SASL機制（保護口令）的口令
認證，在部分6.1中定義。

當使用TLS保護連接防止被監聽時，LDAP工具應該（SHOULD）支持"simple"口令選擇認
證，在部分6.2中定義。

6.1.文摘認證
LDAP客戶可以通過在根DSE之上執行搜索請求、請求supportedSASLMechanisms屬性、
以及檢查是否字符串"DIGEST-MD5"作為值存在于這個屬性中來判定是否服務支持這個機制。

在認證的第一階段，當客戶正在執行在[4]部分2.1中定義的"initialauthentication"
（初始化認證）時，客戶發送請求綁定，其版本數字是3、認證選擇（authenticationchoice）
是sasl、sasl機制名字是"DIGEST-MD5"、以及證明（credentials）不在場?？蛻羧缓蟮却?BR>服務對這個請求做出的回答。

服務將以resultCode是saslBindInProgress、以及serverSaslCreds字段存在的綁定
回答做出回答。這個字段的內容是在[4]部分2.1.1中定義的字符串。服務應該（SHOULD）包
括域指示（MUST）和必須指明支持UTF-8。

客戶將發送有區別報文id（distinctmessageid）的綁定請求，其版本數字是3、認證
選擇是sasl、sasl機制名字是"DIGEST-MD5"，以及證明包含在[4]部分2.1.2中
"digest-response"定義的字符串。serv-type是"ldap"。

服務將回答其resultCode或者是成功，或者是錯誤指示（errorindication）的回答
綁定。如果認證是成功的和服務不支持隨后的（subsequent）認證，那么證明字段中包含[4]
部分2.1.3中"response-auth"定義的字符串。在客戶和服務之間支持隨后的認證是可選的
（OPTIONAL）。

6.2.TLS加密下的簡單認證選擇（"simple"authentication
choice）
一個擁有包含用戶口令（userPassword）屬性的目錄實體可以（MAY）通過執行簡單口令
綁定序列驗證到目錄，其隨著TLS密碼適配組（ciphersuite）提供的機密連接[6]的協商進
行。

客戶將使用啟動TLS操作[5]去協商在連接到LDAP服務之上的TLS安全[6]的使用?？蛻?BR>不需要事先已綁定到目錄。

對于這個認證過程的成功進行，客戶和服務必須（MUST）協商其包含大量適當強度的加
密算法的密碼適配組。在部分10中描述推薦的密碼適配組。

隨著TLS協商的成功的完成，客戶必須（MUST）發送其版本數字是3、名字字段包含用
戶的實體名字，和簡單（"simple"）認證選擇、包含口令的LDAP綁定的請求。

服務將對每一個在用戶的實體命名中的用戶口令（userPassword）屬性的值和客戶提出
的口令按照大小寫敏感相等比較。如果比配，那么服務將發送resultCode為成功的回答，
否則服務將發送resultCode為invalidCredentials的回答。

6.3.隨TLS的其它認證選擇
隨著TLS的協商，執行其沒有涉及明文可再用口令的交換的SASL認證也是可能的。在這
種情況下，客戶和服務不需要協商其提供機密性的密碼適配組，如果僅當服務必需是數據完
整性的。

7.基于證書的認證（Certificate-based
authentication）
LDAP工具應該（SHOULD）支持在TLS中通過客戶證書的認證，在部分7.1中定義。

7.1.隨TLS基于證書的認證
一個擁有公/私密鑰對的用戶，其公鑰已經被證書認證中心（CertificationAuthority）
簽發，可以使用這個密鑰對驗證到目錄服務，如果用戶的證書被服務需求。用戶的證書的主
題字段應該（SHOULD）是用戶的目錄實體的名字，并且證書認證中心必須被目錄服務充分信
任以便（目錄）服務能夠處理被簽發的證書（譯者注：目錄服務通過證書認證中心驗證證書
的有效性）。關于服務（驗證）有效證書路徑的方法不在本文檔討論范圍之內。

服務可以（MAY）支持其主題字段名不同于用戶的目錄實體名的證書映射。支持名字映射
的服務必須（MUST）有能力被配置為支持無映射證書。

在連接LDAP服務之上的客戶將使用啟動TLS操作[5]去協商TLS安全的使用。在這之前
客戶不需要已經綁定到目錄。

在TLS協商中，服務必須（MUST）請求證書?？蛻魧⑻峁┧淖C書給服務，并且必須（MUST）
執行與提供證書相關的私有密鑰的加密。

作為（上述身份驗證的）展開將需求在傳輸中敏感數據的保護，客戶和服務必須協商其
包含大量適當強度的加密算法的密碼適配組。推薦的密碼適配組在部分10中給出。

服務必須（MUST）驗證客戶的證書是有效的。服務將通常檢查證書是被已知的CA簽發的，
以及在客戶的證書鏈中沒有哪個證書是無效的（invalid）和被撤銷（revoked）。服務做這些
檢查存在幾個過程。

隨著TLS協商的成功完成，客戶將發送SASL"EXTERNAL"機制的LDAP綁定請求。

8.其他機制
LDAP簡單（"simple"）認證選擇不適合沒有網絡或者傳輸層機密性（安全）的Internet
認證。

當LDAP包括本機匿名（nativeanonymous）和明文認證機制，"ANONYMOUS"和"PLAIN"
SASL機制不能同LDAP使用。如果不同于DN的形式的授權標識被客戶需求，在傳輸中保護口
令的機制應該（SHOULD）被使用。

在本文檔中下列基于SASL（SASL-based）的機制沒有被考慮：
KERBEROS_V4,GSSAPI和SKEY.

擴展（"EXTERNAL"）SASL機制能夠通過低層（lowerlayer）安全證明交換的使用用于
請求LDAP服務。如果TLS會話在制造（making）SASL擴展綁定（SASLEXTERNALBind）請
求之前還沒有在客戶和服務之間建立以及沒有其他外部認證證明源（例如，IP-level
security[8]），或者如果TLS會話建立處理期間，服務沒有請求客戶的認證證明，那么SASL
擴展綁定必須（MUST）以inappropriateAuthentication結果碼失敗。任何客戶的認證和LDAP
關聯的授權狀態將丟失，所以LDAP關聯在失敗之后是在匿名狀態。

9.授權標識
授權標識作為在LDAP綁定請求和回答中SASL證明字段的一部分被攜帶。

當擴展（"EXTERNAL"）機制被協商時，如果證明字段存在，它包含的authzId形式的授
權標識在下面描述。

其他機制定義在證明字段中的授權標識的單元（location）。

授權標識是一個UTF-8字符集的字符串，相當于下面的ABNF[7]：

;特有的預先定義授權（Specificpredefinedauthorization）(authz)id模式定義
;如下——新的模式在將來可能被定義。

authzId=dnAuthzId/uAuthzId

;distinguished-name-basedauthzid.
dnAuthzId="dn:"dn
dn=utf8string;句法在RFC2253中定義

;unspecifieduserid,UTF-8encoded.
uAuthzId="u:"userid
userid=utf8string;非特指的句法（syntaxunspecified）

utf8string被定義為一個或者多個ISO10646字符的UTF-8編碼。

所有支持認真證明存儲的服務，例如口令或者證書，在目錄中必須（MUST）支持dnAuthzId
選擇。

uAuthzId選擇允許兼容客戶應用程序希望認證本地目錄，但是不知道它們自己的甄別名
（DistinguishedName）或者有一個目錄實體。字符串的格式被定義僅作為UTF-8編碼的ISO
10646字符集的序列，進一步的解釋需要在客戶和服務之間優先協定的。

例如，userid（用戶ID）能標識目錄服務的明確的用戶，或者是一個登錄名或者RFC822
電子郵件地址的local-part。通常uAuthzId必須不能（MUSTNOT）被假定為全局唯一。

附加的授權標識方案可以（MAY）定義在本文檔的將來版本中。

10.TLS密碼適配組
下面定義在[6]中的密碼適配組一定不能（MUSTNOT）用于口令或者數據的機密性保護:

TLS_NULL_WITH_NULL_NULL
TLS_RSA_WITH_NULL_MD5
TLS_RSA_WITH_NULL_SHA

下面定義在[6]中的密碼適配組能被輕易破解（在1997年標準CPU上少于一周的CPU（計
算）時間）?？蛻艉头諔摚⊿HOULD）在使用這些密碼適配組保護的口令或者數據的值之前
小心考慮：

TLS_RSA_EXPORT_WITH_RC4_40_MD5
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA

下面的密碼適配組易受手動之間攻擊（man-in-the-middleattacks）,而且不應該
（SHOULDNOT）用于保護口令或者敏感數據，除非網絡配置上對這樣的手動中間攻擊的危險
是可容忍的：

TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
TLS_DH_anon_WITH_RC4_128_MD5
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
TLS_DH_anon_WITH_DES_CBC_SHA
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA

支持TLS的客戶或者服務必須（MUST）至少支持TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA。

11.對于LDAP的SASL服務名字
對于SASL[2]的使用，協議必須制定各種不同SASL機制使用的服務名字，例如GSSAPI。
對于LDAP，服務名字是"ldap"，其已經在IANA注冊作為GSSAPI服務名字。

12.安全考慮
安全問題在這份備忘錄（memo）中全篇被討論；結論（令人驚奇的）是強制（mandatory）
安全是重要的，并且當窺探是一個問題的時候會話加密是需要的。

服務（程序）被促進去防止被匿名用戶修改。服務（程序）也可以通過超時無效連接希
望最小化服務否定攻擊，并且返回unwillingToPerform結果代碼而不執行被未授權客戶（程
序）請求的昂貴計算操作。

在客戶（程序）還沒有執行啟動TLS操作或者為連接完整性和加密服務協商一套SASL
機制之上的連接是在傳輸中手動之間攻擊（man-in-the-middleattacks）查看和修改信息方
面的主題。

相關于協商TLS擴展（EXTERNAL）機制的安全考慮能在[2]，[5]和[6]中找到。

13.確認
這篇文檔是IETF的LDAPEXTWorkingGroup的產物。其成員的貢獻是非常值得欣賞的。

14.文獻

[1]Wahl,M.,Howes,T.andS.Kille,"LightweightDirectoryAccess
Protocol(v3)",RFC2251,December1997.

[2]Myers,J.,"SimpleAuthenticationandSecurityLayer(SASL)",RFC
2222,October1997.

[3]Bradner,S.,"KeywordsforuseinRFCstoIndicateRequirement
Levels",BCP14,RFC2119,March1997.

[4]Leach,P.andC.Newman,"UsingDigestAuthenticationasaSASL
Mechanism",RFC2831,May2000.

[5]Hodges,J.,Morgan,R.andM.Wahl,"LightweightDirectoryAccess
Protocol(v3):ExtensionforTransportLayerSecurity",RFC2830,
May2000.

[6]Dierks,T.andC.Allen,"TheTLSProtocolVersion1.0",RFC
2246,January1999.

[7]Crocker,D.,Ed.andP.Overell,"AugmentedBNFforSyntax
Specifications:ABNF",RFC2234,November1997.

[8]Kent,S.andR.Atkinson,"SecurityArchitecturefortheInternet
Protocol",RFC2401,November1998.

15.作者的地址
MarkWahl
SunMicrosystems,Inc.
8911CapitalofTexasHwy#4140
AustinTX78759
USA

EMail:M.Wahl@innosoft.com


HaraldTveitAlvestrand
EDBMaxware
Pirsenteret
N-7462Trondheim,Norway

Phone:+4773545797
EMail:Harald@Alvestrand.no


JeffHodges
Oblix,Inc.
18922ForgeDrive
Cupertino,CA95014
USA

Phone:+1-408-861-6656
EMail:JHodges@oblix.com


RL"Bob"Morgan
ComputingandCommunications
UniversityofWashington
Seattle,WA98105
USA

Phone:+1-206-221-3307
EMail:rlmorgan@washington.edu

16．完整版權聲明
版權（C）因特網協會（2001）。版權所有。

這個文檔和它的翻譯可以拷貝和分配給其他人，以及有關評論或者別樣的解釋或者其應
用的幫助等派生工作可以被準備、拷貝、發表和發布，其整體或者部分沒有受到任何限制，
提供上述版權通知以及本段落應被包含在所有這樣的拷貝和派生工作中。然而，這個文檔本
身不可以以任何方式修改，例如移走版權通知或者Internet協會或其他Internet組織的參考，
除非為了發展Internet標準（其版權程序定義在InternetStandards進程如下），或者需要翻譯
成除英語以外的其他語言。

上述限制允許授權是持久的并且將不被Internet協會或者它的繼承人隱藏或者轉讓。

譯者注：對于本文檔的完整版權聲明原文如下：

16.FullCopyrightStatement

Copyright(C)TheInternetSociety(2000).AllRightsReserved.

Thisdocumentandtranslationsofitmaybecopiedandfurnishedto
others,andderivativeworksthatcommentonorotherwiseexplainit
orassistinitsimplementationmaybeprepared,copied,published
anddistributed,inwholeorinpart,withoutrestrictionofany
kind,providedthattheabovecopyrightnoticeandthisparagraphare
includedonallsuchcopiesandderivativeworks.However,this
documentitselfmaynotbemodifiedinanyway,suchasbyremoving
thecopyrightnoticeorreferencestotheInternetSocietyorother
Internetorganizations,exceptasneededforthepurposeof
developingInternetstandardsinwhichcasetheproceduresfor
copyrightsdefinedintheInternetStandardsprocessmustbe
followed,orasrequiredtotranslateitintolanguagesotherthan
English.

Thelimitedpermissionsgrantedaboveareperpetualandwillnotbe
revokedbytheInternetSocietyoritssuccessorsorassigns.

Thisdocumentandtheinformationcontainedhereinisprovidedonan
"ASIS"basisandTHEINTERNETSOCIETYANDTHEINTERNETENGINEERING
TASKFORCEDISCLAIMSALLWARRANTIES,EXPRESSORIMPLIED,INCLUDING
BUTNOTLIMITEDTOANYWARRANTYTHATTHEUSEOFTHEINFORMATION
HEREINWILLNOTINFRINGEANYRIGHTSORANYIMPLIEDWARRANTIESOF
MERCHANTABILITYORFITNESSFORAPARTICULARPURPOSE.