RFC2829针对LDAP的验证方法.docx
《RFC2829针对LDAP的验证方法.docx》由会员分享，可在线阅读，更多相关《RFC2829针对LDAP的验证方法.docx（20页珍藏版）》请在冰豆网上搜索。
RFC2829针对LDAP的验证方法
组织：
中国互动出版网（http:
//www.china-
RFC文档中文翻译计划（http:
//www.china-
E-mail：
ouyang@china-
译者：
张海斌（netdebuginternetdebug@）
译文发布时间：
2001-12-14
版权：
本中文翻译文档版权归中国互动出版网所有。
可以用于非商业用途自由转载，但必须保留本文档的翻译及版权信息。
NetworkWorkingGroupM.Wahl
RequestforComments:
2829SunMicrosystems,Inc.
Category:
StandardsTrackH.Alvestrand
EDBMaxware
J.Hodges
Oblix,Inc.
R.Morgan
UniversityofWashington
May2000
针对LDAP的验证方法
（RFC2829——AuthenticationMethodsforLDAP）
备忘录状况
这份文档为Internet社区指定为Internet标准（轨迹）协议，并且为进一步改进需要讨论和建议。
这份协议的标准化状态和状况请参阅"Internet官方协议标准（InternetOfficialProtocolStandards）"（STD1）的当前版。
这份备忘录的分发不受限制。
版权声明
Copyright（C）TheInternetSociety（2000）。
版权所有。
摘要
这篇文档针对在LDAP[1]实现工具（implementations）中被需求和推荐的安全机制（securitymechanisms）的特定结合。
目录
0.译者的话2
1.引论3
2.样例展开脚本（Exampledeploymentscenarios）4
3.认证和授权：
定义和概念5
3.1.存取控制策略AccessControlPolicy5
3.2.存取控制因素AccessControlFactors5
3.3.认证（Authentication）、证明（Credentials）、身份标识（Identity）5
3.4.授权身份标识（AuthorizationIdentity）6
4.必须的安全机制6
5.匿名认证7
5.1.匿名认证过程8
5.2.匿名认证和TLS8
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）、获取（fetching）和操作（manipulating）目录内容的方法，以及丰富的安全函数集合的访问方法。
为了Internet运转的更好，这些安全功能能够很好的交互是至关重要的（vital）；因此应该存在一个对所有需求LDAPv3一致性的工具（LDAPv3）通用的最小安全功能子集。
对LDAP目录服务基本的威胁包括：
（1）通过数据获取（data-fetching）操作非特许存取数据，
（2）通过监听（monitoring）其他的访问（通道）非特许存取可再用的客户（身份）证明信息，
（3）通过监听其他的访问（通道）非特许存取数据，
（4）XX的数据修改，
（5）XX的配置修改，
（6）XX的或者过分的资源使用（拒绝服务），以及
（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.样例展开脚本（Exampledeploymentscenarios）
下面的脚本是在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）是存取控制表（accesscontrollist）。
安全的对象和机制，就像这里描述的那些能够存取控制策略表达和实施（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）OCTETSTRING绑定需求中指定匿名认证。
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）不在场。
客户然后等待服务对这个请求做出的回答。
服务将以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"authenticationchoice）
一个拥有包含用户口令（userPassword）属性的目录实体可以（MAY）通过执行简单口令绑定序列验证到目录，其随着TLS密码适配组（ciphersuite）提供的机密连接[6]的协商进行。
客户将使用启动TLS操作[5]去协商在连接到LDAP服务之上的TLS安全[6]的使用。
客户不需要事先已绑定到目录。
对于这个认证过程的成功进行，客户和服务必须（MUST）协商其包含大量适当强度的加密算法的密码适配组。
在部分10中描述推荐的密码适配组。
随着TLS协商的成功的完成，客户必须（MUST）发送其版本数字是3、名字字段包含用户的实体名字，和简单（"simple"）认证选择、包含口令的LDAP绑定的请求。
服务将对每一个在用户的实体命名中的用户口令（userPassword）属性的值和客户提出的口令按照大小写敏感相等比较。
如果比配，那么服务将发送resultCode为成功的回答，否则服务将发送resultCode为invalidCredentials的回答。
6.3.随TLS的其它认证选择
随着TLS的协商，执行其没有涉及明文可再用口令的交换的SASL认证也是可能的。
在这种情况下，客户和服务不需要协商其提供机密性的密码适配组，如果仅当服务必需是数据完整性的。
7.基于证书的认证（Certificate-basedauthentication）
LDAP工具应该（SHOULD）支持在TLS中通过客户证书的认证，在部分7.1中定义。
7.1.随TLS基于证书的认证
一个拥有公/私密钥对的用户，其公钥已经被证书认证中心（CertificationAuthority）签发，可以使用这个密钥对验证到目录服务，如果用户的证书被服务需求。
用户的证书的主题字段应该（SHOULD）是用户的目录实体的名字，并且证书认证中心必须被目录服务充分信任以便（目录）服务能够处理被签发的证书（译者注：
目录服务通过证书认证中心验证证书的有效性）。
关于服务（验证）有效证书路径的方法不在本文档讨论范围之内。
服务可以（MAY）支持其主题字段名不同于用户的目录实体名的证书映射。
支持名字映射的服务必须（MUST）有能力被配置为支持无映射证书。
在连接LDAP服务之上的客户将使用启动TLS操作[5]去协商TLS安全的使用。
在这之前客户不需要已经绑定到目录。
在TLS协商中，服务必须（MUST）请求证书。
客户将提供它的证书给服务，并且必须（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）请求之前
升级会员 