rfc2830.txt

很多RFC的中文文档

中的给定类型的身份超过一个（例如，多于一个的dNSName名字），在（身份名字）集合中任
何一个被考虑是可接受的。

   	如果在上面每一个检查规格中主机名没有匹配基于dNSName （dNSName-based）的身份，
面向用户的客户程序应该或者通知用户（不管怎么样程序可以（MAY）提供给用户一个机会是
否继续连接）或者决定连接并且指示服务程序的身份是受怀疑的。自动化的客户程序应该
（SHOULD）关闭连接，返回和/或错误日志表明服务程序的身份是受怀疑的。

   	超出这部分关于服务程序身份检查的描述，客户程序应该（SHOULD）准备进一步进行检
查以确保服务程序对它提供的服务是被授权的。客户程序可以（MAY）（需要）使用本地策略
信息。

3.7.  服务程序能力信息的刷新
   	客户程序必须（MUST）在TLS会话建立之上刷新任何缓存的服务程序能力的信息（例如，
来自服务程序根DSE；参见[LDAPv3]部分3.4）。这是避免主动中间攻击（active-intermediary 
attacks）必要的，主动中间攻击可以在早于TLS建立之前已经改变任何被检索的服务程序能
力信息。服务程序可以在TLS建立之后公告（advertise）不同的能力（信息）。

4.  关闭TLS连接
4.1.  舒缓关闭（Graceful Closure）
   	或者客户程序或者服务程序可以（MAY）通过发送一TLS关闭警告结束关于LDAP关联的
TLS连接。这将完整的离开LDAP关联。

   	在关闭TLS连接之前，客户程序必须（MUST）或者等待任何未完成的LDAP操作直到完成，
或者明示地（explicitly）放弃它们[LDAPv3]。

   	当关闭的启动程序（initiator of a close）已经发送一关闭警告之后，它必须（MUST）
丢弃（discard）任何TLS报文直到它已经接收到从另一方来的警告。它将停止发送TLS记录
协议（TLS Record Protocol）PDUs，和随着收到警告，可以（MAY）发送和接收LDAP PDUs。

   	另一方，如果接收到关闭警告，必须（MUST）立即发送一TLS关闭警告。它将随后停止
发送TLS记录协议PDUs，和可以（MAY）发送和接收LDAPPDUs。

4.2.  突然停止（Abrupt Closure）
   	或者客户程序或者服务程序可以（MAY）突然地关闭整个LDAP关联和任何建立其上的TLS
连接，通过撤销TCP连接。服务程序在这种情况可以（MAY）预先准备好发送给客户程序一断
开连接通知（Notice of Disconnection）[LDAPv3]。

5.  关于客户程序的授权身份的TLS效应
（Effects）
   	这部分描述关于通过在LDAP关联之上建立TLS所带来的客户程序的授权身份的效应。首
先描述缺省效应，接下来客户程序的授权身份的断言被讨论，包括错误状况。最后，关闭TLS
连接的效应被描述。

   	授权身份和相关概念定义在[AuthMeth]。

5.1.  TLS连接建立效应
5.1.1.  缺省效应
   	针对LDAP关联的TLS连接建立之上，任何建立之前的验证和授权身份必须（MUST）有效
遗留（remain in force），包括匿名状况。这甚至在服务程序请求客户程序通过TLS验证请
求情况中保持——例如，请求客户程序在TLS协商期间提供它的证书（参见[TLS]）。

5.1.2.  授权身份的客户断言
   	客户程序可以（MAY）或者隐含来自它的已授权的TLS证明（authenticated TLS 
credentials）的LDAP授权身份，或者它可以（MAY）显示地提供一授权身份并且它被用在与
它的已授权的TLS证明的结合。前者称为隐式断言，后者称为显式断言。

5.1.2.1.  隐式断言（Implicit Assertion）
   	隐式授权身份断言在通过调用SASL形式的绑定请求的TLS建立之后完成，SASL形式的
绑定请求使用不应该（SHALL NOT）包括可选证明的八位组（octet）字符串（在绑定请求的
SaslCredentials序列中发现）的"EXTERNAL"机制名字[SASL, LDAPv3]。服务程序将从符合
本地策略的客户程序证明（典型的公钥证书）中提供的验证标识（authentication identity）
导出客户程序的授权身份。如何实现（上述断言）由特定的工具做到。

5.1.2.2.  显式断言（Explicit Assertion）
   	显式授权身份断言在通过调用SASL形式的绑定请求的TLS建立之后完成，SASL形式的
绑定请求使用应该（SHALL）包括证明八位组（octet）字符串的"EXTERNAL"机制名字[SASL, 
LDAPv3]。字符串必须（MUST）作为[AuthMeth]部分9中的文档的组成部分。

5.1.2.3.  错误状况（Error Conditions）
   	不管断言的形式如何，服务程序必须（MUST）核实客户程序的授权身份作为提供在它的
TLS证明中是允许映射到断言授权身份的。服务程序必须（MUST）拒绝在绑定回答中以
invalidCredentials resultCode（回答）的绑定操作，如果客户程序没有被这样授权。

   	作为断言形式的补充，如果TLS会话还没有在制作SASL EXTERNAL 绑定请求之前在客户
程序和服务程序之间建立，并且没有其他的外来证明（例如IP-level security [IPSEC]），
或者如果在TLS会话建立处理期间，服务程序没有请求客户程序的证明，SASL EXTERNAL 绑
定必须（MUST）以结果码inappropriateAuthentication 失败。

   	在上述绑定操作失败后，任何客户程序的证明和LDAP关联的授权状态丢失，所以失败之
后LDAP关联是匿名状态。TLS连接状态不受影响，服务程序可以（MAY）在绑定失败的基础
上通过TLS关闭通知（close_notify）报文结束TLS连接（可以（MAY）在任何时候）。

5.2.  TLS连接关闭效应
   	TLS连接的关闭必须（MUST）引发（cause）LDAP关联移向匿名证明和授权状态，而不管
基于TLS之上建立的状态以及不管TLS连接建立之前证明和授权的状态如何。

6.  安全考虑
   	关于LDAP使用TLS协议的目的是确保连接的机密性（confidentiality）和完整性
（integrity），以及可选择提供的（身份）证明。TLS专门提供的这些能力在[TLS]中描述。

   	所有通过启动TLS操作的使用获得的安全通过TLS自身的使用得到改善。启动TLS操作，
作为它自己，没有提供任何额外的安全。

   	TLS的使用没有提供或者确保通过基于LDAP（LDAP-based）目录服务数据入住（the data 
housed）的机密性和/或不可否认性（non-repudiation）。也没有保护数据免于服务管理者的
审查（inspection）。一旦建立（完成），TLS仅提供和确保在LDAP关联之上传输中的操作和
数据的机密性和完整性，并且仅当客户程序和服务程序都支持和协商（建立）。

   安全级（The level of security）通过直接依赖于TLS工具（implementation）使用的
质量（quality）和使用方式（style）的TLS的使用提供。另外，主动中间攻击者
（active-intermediary attacker）能够从根DSE（the root DSE）的supportedExtension
属性中除去（remove）启动TLS扩展操作。 因此，双方应该（SHOULD）独立地查明和同意
TLS建立后取得的安全级，以及在TLS连接使用开始之前。例如，TLS连接的安全级可以已经
协商到明文（plaintext）。

   	客户程序应该（SHOULD）或者警告用户，当取得的安全级没有提供机密性和/或完整性保
护，或者被配置为在没有可接受的安全级时拒绝继续执行。

   	客户和服务实现程序应该（SHOULD）采取措施确保恰当的（身份）证明保护和其它没有
被TLS工具提供（这样）措施（保护）的机密数据（的保护）。

   	服务实现程序应该（SHOULD）允许服务管理者选择（elect）当连接机密和/或完整性被
需求时的任何一个，还可以选择当客户程序通过TLS授权被需求时的任何一个。

7.  确认
   作者感谢为这篇文章做出贡献的Tim Howes, Paul Hoffman, John Kristian, Shirish   
Rai, Jonathan Trostle, Harald Alvestrand, 和Marcus Leech。

8.  参考
   [AuthMeth]     Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan,
                  "Authentication Methods for LDAP", RFC 2829, May 2000.

   [IPSEC]        Kent, S. and R. Atkinson, "Security Architecture for
                  the Internet Protocol", RFC 2401, November 1998.

   [LDAPv3]       Wahl, M., Kille S. and T. Howes, "Lightweight
                  Directory Access Protocol (v3)", RFC 2251, December
                  1997.

   [ReqsKeywords] Bradner, S., "Key Words for use in RFCs to Indicate
                  Requirement Levels", BCP 14, RFC 2119, March 1997.

   [SASL]         Myers, J., "Simple Authentication and Security Layer
                  (SASL)", RFC 2222, October 1997.

   [TLS]          Dierks, T. and C. Allen. "The TLS Protocol Version
                  1.0", RFC 2246, January 1999.

9.  作者地址
   Jeff Hodges
   Oblix, Inc.
   18922 Forge Drive
   Cupertino, CA 95014
   USA

   Phone: [phone]
   EMail: [e-mail]

   RL "Bob" Morgan
   Computing and Communications
   University of Washington
   Seattle, WA
   USA

   Phone: [phone]
   EMail: [e-mail]

   Mark Wahl
   Sun Microsystems, Inc.
   8911 Capital of Texas Hwy #4140
   Austin TX 78759
   USA

   EMail: [e-mail]

10. 知识产权声明
   	IETF没有担任关于任何知识产权或者其他版权（rights）正当或者范围的（职位），这
里所说的版权是指在本文中可以声明属于实现工具（implementation）或者技术的使用，或
者在这样版权之下的任何可以或者不可以有效的许可（license）的扩展；也没有做出任何努
力去识别（identify）这样的版权。关于在标准轨迹（standards-track）和标准相关
（standards-related）的文档中的IETF的流程（procedures）信息能在BCP-11中找到。版
权声明的拷贝对出版有效以及任何许可保证将有效，或者尝试获得通用许可，或者通过实现
工具或者这个规格说明书的用户允许使用这样的知识产权的使用能从IETF秘书处得到。

   	IETF邀请任何参与的各方（interested party）带来他们的任何版权（copyrights）的
考虑（attention），专利或者专利应用，或者其他知识产权其可以实践这些标准替代技术的
将被需求的（版权）。请将信息发送给IETF执行主管（IETF Executive Director）。 

11.  完整版权声明
   	版权（C）因特网协会（2001）。版权所有。

   	这个文档和它的翻译可以拷贝和分配给其他人，以及有关评论或者别样的解释或者其应
用的帮助等派生工作可以被准备、拷贝、发表和发布，其整体或者部分没有受到任何限制，
提供上述版权通知以及本段落应被包含在所有这样的拷贝和派生工作中。然而，这个文档本
身不可以以任何方式修改，例如移走版权通知或者Internet协会或其他Internet组织的参考，
除非为了发展Internet标准（其版权程序定义在Internet Standards进程如下），或者需要翻译
成除英语以外的其他语言。

   上述限制允许授权是持久的并且将不被Internet协会或者它的继承人隐藏或者转让。

译者注：对于本文档的完整版权声明原文如下：

Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

确认
   	为RFC编辑功能资助现在由因特网协会（Internet Society）提供。

RFC2830——Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security
简单目录访问协议（v3）：传输层安全扩展


13
RFC文档中文翻译计划