Internet Engineering Task Force (IETF) L. Johansson
Request for Comments: 6880 SUNET
Category: Standards Track March 2013
ISSN: 2070-1721
Internet Engineering Task Force (IETF) L. Johansson
Request for Comments: 6880 SUNET
Category: Standards Track March 2013
ISSN: 2070-1721
An Information Model for Kerberos Version 5
Kerberos版本5的信息模型
Abstract
摘要
This document describes an information model for Kerberos version 5 from the point of view of an administrative service. There is no standard for administrating a Kerberos 5 Key Distribution Center (KDC). This document describes the services exposed by an administrative interface to a KDC.
本文档从管理服务的角度描述Kerberos版本5的信息模型。没有管理Kerberos 5密钥分发中心（KDC）的标准。本文档描述了管理接口向KDC公开的服务。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6880.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6880.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
本文件可能包含2008年11月10日之前发布或公开的IETF文件或IETF贡献中的材料。控制某些材料版权的人员可能未授予IETF信托允许在IETF标准流程之外修改此类材料的权利。在未从控制此类材料版权的人员处获得充分许可的情况下，不得在IETF标准流程之外修改本文件，也不得在IETF标准流程之外创建其衍生作品，除了将其格式化以RFC形式发布或将其翻译成英语以外的其他语言。
Table of Contents
目录
1. Introduction ....................................................3
2. Requirements Notation ...........................................4
3. Information Model Demarcation ...................................5
4. Information Model Specification .................................6
4.1. Principal ..................................................6
4.1.1. Principal: Attributes ...............................6
4.1.2. Principal: Associations .............................7
4.2. KeySet .....................................................8
4.2.1. KeySet: Attributes ..................................8
4.2.2. KeySet: Associations ................................8
4.3. Key ........................................................9
4.3.1. Key: Attributes .....................................9
4.3.2. Key: Associations ..................................10
4.3.3. Key: Remarks .......................................10
4.4. Policy ....................................................10
4.4.1. Policy: Attributes .................................10
4.4.2. Mandatory-to-Implement Policy ......................11
5. Implementation Scenarios .......................................11
5.1. LDAP Backend to KDC .......................................12
5.2. LDAP Frontend to KDC ......................................12
5.3. SOAP ......................................................12
5.4. NETCONF ...................................................12
6. Security Considerations ........................................12
7. Acknowledgments ................................................13
8. References .....................................................13
8.1. Normative References ......................................13
8.2. Informative References ....................................14
1. Introduction ....................................................3
2. Requirements Notation ...........................................4
3. Information Model Demarcation ...................................5
4. Information Model Specification .................................6
4.1. Principal ..................................................6
4.1.1. Principal: Attributes ...............................6
4.1.2. Principal: Associations .............................7
4.2. KeySet .....................................................8
4.2.1. KeySet: Attributes ..................................8
4.2.2. KeySet: Associations ................................8
4.3. Key ........................................................9
4.3.1. Key: Attributes .....................................9
4.3.2. Key: Associations ..................................10
4.3.3. Key: Remarks .......................................10
4.4. Policy ....................................................10
4.4.1. Policy: Attributes .................................10
4.4.2. Mandatory-to-Implement Policy ......................11
5. Implementation Scenarios .......................................11
5.1. LDAP Backend to KDC .......................................12
5.2. LDAP Frontend to KDC ......................................12
5.3. SOAP ......................................................12
5.4. NETCONF ...................................................12
6. Security Considerations ........................................12
7. Acknowledgments ................................................13
8. References .....................................................13
8.1. Normative References ......................................13
8.2. Informative References ....................................14
The Kerberos version 5 authentication service described in [RFC4120] describes how a Key Distribution Center (KDC) provides authentication to clients. RFC 4120 does not stipulate how a KDC is managed, and several "kadmin" servers have evolved since RFC 4120 was written. This document describes the services required to administer a KDC and the underlying information model assumed by a kadmin-type service.
[RFC4120]中描述的Kerberos版本5身份验证服务描述了密钥分发中心（KDC）如何向客户端提供身份验证。RFC4120没有规定如何管理KDC，自编写RFC4120以来，已经发展了几个“kadmin”服务器。本文档描述了管理KDC所需的服务以及kadmin类型服务假定的底层信息模型。
The information model is written in terms of "attributes" and either "services" or "interfaces", but the use of these particular words must not be taken to imply any particular modeling paradigm. Neither an object-oriented model nor a Lightweight Directory Access Protocol (LDAP) [RFC4510] schema is intended. The author has attempted to describe, in prose, the intended semantics and syntax of the components of the model. For instance, an LDAP schema based on this model will be more precise in the expression of the syntax while preserving the semantics of this model.
信息模型是根据“属性”和“服务”或“接口”编写的，但这些特定词语的使用不得被视为暗示任何特定的建模范式。既不是面向对象的模型，也不是轻量级目录访问协议（LDAP）[RFC4510]模式。作者试图用散文描述模型组件的预期语义和语法。例如，基于此模型的LDAP模式将在语法表达上更加精确，同时保留此模型的语义。
Implementations of this document MAY decide to change the names used (e.g., principalName). If so, an implementation MUST provide a name-to-name mapping to this document. In particular, schema languages may have different typographical conventions, e.g., the use of an uppercase letter (as seen in camelCase) versus the use of '_' and '-' to separate 'words' in a name. Implementations MUST call out such conventions explicitly.
本文件的实施可能决定更改使用的名称（例如principalName）。如果是这样，实现必须提供到此文档的名称到名称的映射。特别是，模式语言可能有不同的排版惯例，例如，使用大写字母（如camelCase中所示）与使用“u”和“-”来分隔名称中的“单词”。实现必须明确地调用这样的约定。
Implementations of this document MUST be able to support default values for attributes and have the ability to specify syntax for attribute values.
本文档的实现必须能够支持属性的默认值，并能够指定属性值的语法。
This document uses the standard key words ("MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL") that are defined in [RFC2119], but with modifications to those definitions as described below. The reason for this (which was discussed extensively in the Kerberos working group) is as follows:
本文件使用了[RFC2119]中定义的标准关键词（“必须”、“不得”、“必需”、“应”、“不得”、“应”、“不应”、“建议”、“可”和“可选”），但对这些定义进行了修改，如下所述。原因如下（Kerberos工作组对此进行了广泛讨论）：
This document describes an information model for Kerberos 5, but it does not directly describe any mapping onto a particular schema or modeling language. Hence, an implementation of this model consists of a mapping to such a language, e.g., an LDAP or SQL schema. Therefore, the standard normative key words require precise definition.
本文档描述了Kerberos 5的信息模型，但没有直接描述到特定模式或建模语言的任何映射。因此，该模型的实现包括到这种语言的映射，例如LDAP或SQL模式。因此，标准规范性关键词需要精确定义。
The terms "MUST" and "REQUIRED" mean that a schema implementing this model must have a way to represent a feature (i.e., that it is mandatory to implement it in the schema), but that, unless otherwise specified, the feature may represent an optional element in the chosen schema definition language.
术语“必须”和“必需”表示实现此模型的模式必须有一种表示功能的方式（即，必须在模式中实现该功能），但除非另有规定，否则该功能可以表示所选模式定义语言中的可选元素。
However, "MUST" also means that a KDC or administrative interface implementing this information model has to provide the feature and associated behavior consistent with the schema.
然而，“必须”还意味着实现此信息模型的KDC或管理接口必须提供与模式一致的特性和相关行为。
For instance, principalName (see Section 4.1.1.1) represents the name of a principal. In an LDAP schema (for instance), this may be represented as an optional attribute even though all KDCs implementing this specification must support this attribute.
例如，principalName（参见第4.1.1.1节）表示主体的名称。例如，在LDAP模式中，这可能表示为可选属性，即使实现此规范的所有KDC都必须支持此属性。
The terms "MAY" and "OPTIONAL" mean that it is optional for a KDC or administrative interface implementing this information model to implement this feature. These terms also mean that implementing the feature in the schema is optional.
术语“可能”和“可选”表示实现此信息模型的KDC或管理接口实现此功能是可选的。这些术语还意味着在模式中实现特性是可选的。
Implementers of the schema should be aware that, unless the schema definition can represent critical but optional elements, language confusion may arise when optional elements are used but not understood by all implementations in a particular deployment.
模式的实现者应该意识到，除非模式定义可以表示关键但可选的元素，否则在特定部署中使用可选元素但未被所有实现理解时，可能会出现语言混乱。
The expression "MUST NOT be OPTIONAL" means that it is mandatory that a feature be implemented ("MUST" per the definition in [RFC2119]) and additionally that it must not be marked as optional in the schema language. In particular, this expression means that the feature is both mandatory to implement and must be present in all representations of the object to which it applies.
表达式“不得为可选”表示必须实现功能（“必须”根据[RFC2119]中的定义），此外，不得在模式语言中将其标记为可选。特别是，该表达式意味着该功能是必须实现的，并且必须出现在其应用对象的所有表示中。
The terms "SHOULD" and "RECOMMENDED" mean that the consequences of not implementing the feature as if it were described with the "MUST" keyword must be carefully weighed before choosing a different course. In particular, these terms imply that interoperability concerns may arise from not following the recommended practice in schema that implement this model.
术语“应该”和“推荐”意味着，在选择不同的课程之前，必须仔细权衡不使用“必须”关键字描述功能的后果。特别是，这些术语意味着互操作性问题可能是由于不遵循实现此模型的模式中的推荐实践而引起的。
Context will determine whether the "SHOULD" key word applies to the schema, to the underlying behavior of the KDC, or both. For instance, when this document states that principalIsDisabled (see Section 4.1.1.4) SHOULD default to FALSE, this statement implies both a recommendation for the behavior of KDCs as well as a recommendation for the representation of that behavior in schema.
上下文将决定“应该”关键字是应用于模式，还是应用于KDC的底层行为，或者两者兼而有之。例如，当本文档规定principalIsDisabled（参见第4.1.1.4节）应默认为FALSE时，该语句暗示了对KDC行为的建议以及对在模式中表示该行为的建议。
The information model specified in Section 4 describes objects, their properties, and the relationships between the objects. These elements comprise an abstract view of the data represented in a KDC. It is important to understand that the information model is not a schema. In particular, the way objects are compared for equality beyond that which is implied by the specification of a syntax is not part of this specification, nor is the ordering specified between the elements of a particular syntax.
第4节中指定的信息模型描述了对象、对象的属性以及对象之间的关系。这些元素包含KDC中表示的数据的抽象视图。重要的是要理解信息模型不是模式。特别是，除了语法规范所暗示的相等性之外，比较对象是否相等的方式不是本规范的一部分，也不是在特定语法的元素之间指定的顺序。
Further work on Kerberos will undoubtedly prompt updates to this information model to reflect changes in the functions performed by the KDC. Such extensions to the information model should always use a normative reference to the relevant RFCs in detailing the change in KDC function.
对Kerberos的进一步研究无疑将促使对该信息模型进行更新，以反映KDC执行的功能的变化。信息模型的此类扩展应始终使用相关RFC的规范性参考来详细说明KDC功能的变化。
This model describes a number of elements related to password policy management. Not all of the elements in this model are unique to Kerberos. For example, an LDAP implementation of this model should incorporate existing LDAP schema where functional overlap exists, rather than defining additional Kerberos-specific elements.
此模型描述了与密码策略管理相关的许多元素。并非此模型中的所有元素都是Kerberos独有的。例如，此模型的LDAP实现应该在存在功能重叠的地方合并现有LDAP模式，而不是定义其他特定于Kerberos的元素。
The fundamental entity stored in a KDC is the principal. The principal is associated with keys and generalizes the "user" concept. The principal MUST be implemented in full and MUST NOT be OPTIONAL in an implementation
存储在KDC中的基本实体是主体。主体与键相关联，并概括了“用户”的概念。主体必须完全实现，并且在实现中不能是可选的
The principalName MUST uniquely identify the principal within the administrative context of the KDC. The principalName MUST be equivalent to the string representation of the principal name (see Section 2.1.1 of [RFC1964]), including, if applicable for the name type, the realm.
principalName必须在KDC的管理上下文中唯一标识主体。principalName必须等效于principalName的字符串表示形式（请参见[RFC1964]第2.1.1节），包括域（如果适用于名称类型）。
The attribute MAY be multivalued if the implementation supports aliases, enterprise names, or both. In this case, exactly one of the principalName values MAY be designated as the canonical principalName. If the implementation supports encryption types (enctypes) that require salt, exactly one of the values of principalName MAY be designated as the canonical salting principalName.
如果实现支持别名和/或企业名称，则该属性可能是多值的。在这种情况下，principalName值中正好有一个可以指定为规范principalName。如果实现支持需要salt的加密类型（enctypes），principalName的值中正好有一个可以指定为规范salt principalName。
Implementations (i.e., schema) that support enterprise names, aliases, or both, SHOULD provide for efficient lookup of principal objects based on the alias or enterprise name.
支持企业名称、别名或两者的实现（即模式）应提供基于别名或企业名称的主体对象的高效查找。
The principal MUST NOT be used before this date. The syntax of the attribute MUST be Internet date/time format from [RFC3339]. The attribute MUST be single-valued.
在此日期之前不得使用委托人。属性的语法必须是[RFC3339]中的Internet日期/时间格式。属性必须是单值的。
The principal MUST NOT be used after this date. The syntax of the attribute MUST be Internet date/time format from [RFC3339]. The attribute MUST be single-valued.
委托人不得在此日期之后使用。属性的语法必须是[RFC3339]中的Internet日期/时间格式。属性必须是单值的。
A boolean attribute used to disable a principal. The attribute SHOULD default to boolean FALSE.
用于禁用主体的布尔属性。该属性应默认为布尔值FALSE。
This single-valued attribute contains the time of the last successful change of credentials (e.g., password or private key) associated with this principal. The syntax of the attribute MUST be Internet date/time format from [RFC3339].
此单值属性包含上次成功更改与此主体关联的凭据（例如，密码或私钥）的时间。属性的语法必须是[RFC3339]中的Internet日期/时间格式。
This single-valued attribute contains the time and date when this principal was created. The syntax of the attribute MUST be Internet date/time format from [RFC3339].
此单值属性包含创建此主体的时间和日期。属性的语法必须是[RFC3339]中的Internet日期/时间格式。
This single-valued attribute contains the time and date when this principal was last modified, excluding changes to credentials. The syntax of the attribute MUST be Internet date/time format from [RFC3339].
此单值属性包含上次修改此主体的时间和日期，不包括对凭据的更改。属性的语法必须是[RFC3339]中的Internet日期/时间格式。
This single-valued attribute contains the time, in seconds, representing the maximum lifetime of a ticket issued for this principal.
此单值属性包含时间（以秒为单位），表示为此主体颁发的票证的最长生存期。
This single-valued attribute contains the delta time, in seconds, representing the maximum amount of time a ticket may be renewed for this principal.
此单值属性包含增量时间（以秒为单位），表示可为此主体续订票证的最长时间。
This OPTIONAL multivalued attribute lists the enctypes allowed for this principal. If empty or absent, any enctype supported by the implementation is allowed for this principal.
此可选多值属性列出此主体允许的加密类型。如果为空或不存在，则此主体允许实现支持的任何enctype。
This attribute is intended as a policy attribute and restricts all uses of enctypes, including server, client, and session keys. Data models MAY choose to use policy objects in order to represent more complex decision mechanisms.
此属性用作策略属性，并限制EncType的所有使用，包括服务器、客户端和会话密钥。数据模型可以选择使用策略对象来表示更复杂的决策机制。
Each principal MAY be associated with 0 or more KeySets and MAY be associated with 0 or more Policies. The KeySet is represented as an object in this model, because it has attributes associated with it
每个主体可以与0个或多个密钥集相关联，也可以与0个或多个策略相关联。关键帧集在该模型中表示为对象，因为它具有与其关联的属性
(the key version number). In typical situations, the principal is associated with exactly one KeySet, but implementations MUST NOT assume this case. That is, an implementation of this standard MUST be able to handle the general case of multiple KeySets associated with each principal. Multiple KeySets may, for instance, be useful when performing a key rollover for a principal.
（密钥版本号）。在典型情况下，主体仅与一个键集关联，但实现不能假设这种情况。也就是说，此标准的实现必须能够处理与每个主体关联的多个密钥集的一般情况。例如，在为主体执行键翻转时，多个键集可能很有用。
In Kerberos, principals are associated with zero or more symmetric secret keys, and each key has a key version number (kvno) and an enctype. In this model, we group keys by kvno into KeySet objects. A principal can have zero or more KeySet objects associated with it, each of which MUST have one or more keys. Each KeySet is associated with exactly one principal. A schema derived from this model MAY lack a direct analogue of KeySet, as described in this document.
在Kerberos中，主体与零个或多个对称密钥相关联，每个密钥都有一个密钥版本号（kvno）和一个enctype。在这个模型中，我们通过kvno将密钥分组到密钥集对象中。主体可以有零个或多个与其关联的键集对象，每个对象必须有一个或多个键。每个键集仅与一个主体关联。如本文档所述，从该模型派生的模式可能缺少与密钥集的直接模拟。
It is expected that most Kerberos implementations will use a special-purpose interface for setting and changing principal passwords and keys.
预计大多数Kerberos实现将使用专用接口来设置和更改主要密码和密钥。
If a server supports an enctype for a principal, that enctype must be present in at least one key for the principal in question. For any given enctype, a KeySet MUST NOT contain more than one key with that enctype.
如果服务器支持主体的enctype，则该enctype必须至少存在于相关主体的一个密钥中。对于任何给定的enctype，密钥集不得包含多个具有该enctype的密钥。
The security of Kerberos 5 depends absolutely on the confidentiality and integrity of the key objects stored in the KDC. Implementations of this standard MUST facilitate, to the extent possible, an administrator's ability to place more restrictive access controls on KeySets than on other principal data, and to arrange for more secure backup for KeySets.
Kerberos 5的安全性完全取决于存储在KDC中的关键对象的机密性和完整性。本标准的实施必须尽可能促进管理员对密钥集实施比其他主体数据更严格的访问控制，并为密钥集安排更安全的备份。
The key version number. This is a single-valued attribute containing a non-negative integer. This number is incremented by one each time a key in the KeySet is changed.
密钥版本号。这是一个包含非负整数的单值属性。每次更改钥匙集中的钥匙时，此数字将增加一。
Each KeySet MUST be associated with a set of one or more Keys.
每个键集必须与一组一个或多个键相关联。
Implementations of this model MUST NOT force keys to be represented. That is, a schema that REQUIRED a key to be present would not meet this constraint.
此模型的实现不能强制表示键。也就是说，要求存在键的模式将不满足此约束。
The enctype SHOULD be represented as an enumeration of the enctypes supported by the KDC using the string name ("encryption type") of the enctype from the IANA registry of Kerberos Encryption Type Numbers. One example is "aes128-cts-hmac-sha1-96".
enctype应表示为KDC支持的enctype的枚举，使用Kerberos加密类型号的IANA注册表中enctype的字符串名称（“加密类型”）。一个例子是“aes128-cts-hmac-sha1-96”。
The binary representation of the key data. This MUST be a single-valued octet string.
关键数据的二进制表示。这必须是单值八位字节字符串。
The binary representation of the key salt. This MUST be a single-valued octet string.
密钥salt的二进制表示形式。这必须是单值八位字节字符串。
This MUST be a single-valued octet string representing an opaque parameter associated with the enctype. This parameter is specified using the string-to-key method defined in Section 3 of [RFC3961].
这必须是表示与enctype关联的不透明参数的单值八位字节字符串。使用[RFC3961]第3节中定义的字符串到键方法指定此参数。
The key MUST NOT be used before this date. The syntax of the attribute MUST be semantically equivalent to the standard ISO date format ([RFC3339]). This attribute MUST be single-valued.
在此日期之前不得使用密钥。属性的语法必须在语义上等同于标准ISO日期格式（[RFC3339]）。此属性必须是单值的。
The key MUST NOT be used after this date. The syntax of the attribute MUST be semantically equivalent to the standard ISO date format ([RFC3339]). This attribute MUST be single-valued.
此日期后不得使用密钥。属性的语法必须在语义上等同于标准ISO日期格式（[RFC3339]）。此属性必须是单值的。
This is a boolean attribute that SHOULD be set to FALSE by default. If this attribute is TRUE, the key MUST NOT be used. The keyIsDisabled attributed is used to temporarily disable a key.
这是一个布尔属性，默认情况下应设置为FALSE。如果此属性为TRUE，则不得使用该键。keyIsDisabled属性用于临时禁用密钥。
None
没有一个
The security of the keys is an absolute requirement for the operation of Kerberos 5. If keys are implemented, adequate protection from unauthorized modification and disclosure MUST be available and is REQUIRED of the implementation.
密钥的安全性是Kerberos 5操作的绝对要求。如果实施了密钥，则必须提供足够的保护，防止未经授权的修改和泄露，这是实施所必需的。
Implementations SHOULD implement policies, but MAY allow them to be OPTIONAL. The policy should be thought of as a "typed hole", i.e., as an opaque binary value paired with an identifier of the type of data contained in the binary value. Both attributes (type and value) must be present.
实现应该实现策略，但可能允许策略是可选的。该策略应被视为“类型化漏洞”，即不透明的二进制值与二进制值中包含的数据类型的标识符配对。两个属性（类型和值）都必须存在。
The policyIdentifier MUST be globally unique. Possible types of identifiers include:
policyIdentifier必须是全局唯一的。标识符的可能类型包括：
o An Object Identifier (OID) [RFC4517]
o 对象标识符（OID）[RFC4517]
o A URI [RFC3986]
o 一个URI[RFC3986]
o A UUID [RFC4122]
o UUID[RFC4122]
Implementations of this specification are expected to assign globally unique identifiers to the list of the standard policy below in accordance with best practices for identifier management for the schema language used.
根据所用模式语言标识符管理的最佳实践，本规范的实现预期将为下面的标准策略列表分配全局唯一标识符。
This boolean attribute indicates that the KDC MUST be able to correctly interpret and apply the policy for the principal to be used.
此布尔属性表示KDC必须能够正确解释和应用要使用的主体的策略。
This optional single opaque binary value is used to store a representation of the policy. In general, a policy cannot be fully expressed using attribute-value pairs. The policyContent is OPTIONAL
此可选的单个不透明二进制值用于存储策略的表示形式。通常，不能使用属性-值对完全表示策略。策略内容是可选的
in the sense that an implementation MAY use it to store an opaque value for the policy types that are not directly representable in that implementation.
在某种意义上，实现可能会使用它来存储该实现中无法直接表示的策略类型的不透明值。
This optional single enumerated string value is used to describe the use of the policy. Implementations SHOULD provide this attribute and MUST (if the attribute is implemented) describe the enumerated set of possible values. The intent is that this attribute provide an initial context-based filtering.
此可选的单枚举字符串值用于描述策略的使用。实现应该提供此属性，并且必须（如果实现了该属性）描述枚举的可能值集。其目的是该属性提供初始的基于上下文的过滤。
All implementations that represent policy objects MUST be able to represent the policies listed in this section. Implementations are not required to use the same underlying data representation for the policyContent binary value, but SHOULD use the same OIDs as the policyIdentifier. In general, the expression of policy may require a Turing-complete language. This specification does not attempt to model policy-expression language.
所有表示策略对象的实现必须能够表示本节中列出的策略。实现不需要对policyContent二进制值使用相同的底层数据表示，但应该使用与policyIdentifier相同的OID。一般来说，策略的表达可能需要图灵完备语言。此规范不尝试为策略表达式语言建模。
Password quality policy controls the requirements placed by the KDC on new passwords.
密码质量策略控制KDC对新密码的要求。
Password management policy controls how passwords are changed.
密码管理策略控制如何更改密码。
A keying policy specifies the association of enctypes with new principals. For example, when a principal is created, one of the applicable keying policies is used to determine the set of keys to associate with the principal.
键控策略指定EncType与新主体的关联。例如，创建主体时，将使用一个适用的键控策略来确定要与主体关联的键集。
A ticket flag policy specifies the ticket flags allowed for tickets issued for a principal.
票证标志策略指定为主体颁发的票证所允许的票证标志。
There are several ways to implement an administrative service for Kerberos 5 based on this information model. In this section, we list a few of them.
有几种方法可以基于此信息模型实现Kerberos 5的管理服务。在本节中，我们将列出其中的一些。
Given an LDAP schema implementation of this information model, it would be possible to build an administrative service by backending the KDC to a directory server where principals and keys are stored. Using the security mechanisms available on the directory, server keys are protected from access by anyone apart from the KDC. Administration of the principals, policy, and other non-key data is done through the directory server, while the keys are modified using the set/change password protocol [PASSWORD].
给定此信息模型的LDAP模式实现，可以通过将KDC回溯到存储主体和密钥的目录服务器来构建管理服务。使用目录中可用的安全机制，服务器密钥受到保护，不被KDC之外的任何人访问。主体、策略和其他非密钥数据的管理通过目录服务器完成，而密钥则使用设置/更改密码协议[password]进行修改。
An alternative way to provide a directory interface to the KDC is to implement an LDAP frontend to the KDC that exposes all non-key objects as entries and attributes. As in the example above, all keys are modified using the set/change password protocol [PASSWORD]. In this scenario, the implementation would typically not use a traditional LDAP implementation, but would treat LDAP as a protocol to access data in the native KDC database.
为KDC提供目录接口的另一种方法是实现KDC的LDAP前端，该前端将所有非键对象公开为条目和属性。如上例所示，使用设置/更改密码协议[password]修改所有密钥。在这种情况下，实现通常不使用传统的LDAP实现，而是将LDAP视为访问本机KDC数据库中数据的协议。
Given an XML schema implementation of this information model, it would be possible to build a SOAP interface to the KDC. This situation demonstrates the value of creating an abstract information model that is mappable to multiple schema representations.
给定此信息模型的XML模式实现，就有可能构建到KDC的SOAP接口。这种情况说明了创建可映射到多个模式表示的抽象信息模型的价值。
Given a YAML (YAML Ain't Markup Language) implementation of this information model, it would be possible to create a NETCONF-based interface to the KDC, enabling management of the KDC from standard network management applications.
给定此信息模型的YAML（YAML不是标记语言）实现，可以创建基于NETCONF的KDC接口，从而从标准网络管理应用程序管理KDC。
This document describes an abstract information model for Kerberos 5. The Kerberos 5 protocol depends on the security of the keys stored in the KDC. The model described here assumes that keys MUST NOT be transported in the clear over the network and furthermore that keys be treated as write-only attributes that SHALL be modified (using the administrative interface) only by the change-password protocol [PASSWORD].
本文档描述了Kerberos 5的抽象信息模型。Kerberos 5协议取决于存储在KDC中的密钥的安全性。这里描述的模型假设密钥不能通过网络以明文形式传输，而且密钥被视为仅写属性，只能通过更改密码协议[password]修改（使用管理接口）。
Exposing the object model of a KDC typically implies that objects can be modified, deleted, or both. In a KDC, not all principals are created equal. For instance, deleting krbtgt/EXAMPLE.COM@EXAMPLE.COM
公开KDC的对象模型通常意味着可以修改、删除或同时修改和删除对象。在KDC中，并非所有主体都是平等创建的。例如，删除krbtgt/EXAMPLE。COM@EXAMPLE.COM
effectively disables the EXAMPLE.COM realm. Hence, access control is paramount to the security of any implementation. This document does not mandate access control. This situation implies only that access control is beyond the scope of the standard information model, i.e., that access control may not be accessible via any protocol based on this model. If access control objects are exposed via an extension to this model, the presence of access control may in itself provide points of attack by giving away information about principals that have elevated rights.
有效地禁用EXAMPLE.COM领域。因此，访问控制对于任何实现的安全性都是至关重要的。本文件不强制要求访问控制。这种情况仅意味着访问控制超出了标准信息模型的范围，即访问控制可能无法通过基于此模型的任何协议访问。如果访问控制对象是通过此模型的扩展公开的，那么访问控制的存在本身可能通过泄露具有提升权限的主体的信息而提供攻击点。
The author wishes to extend his thanks to Love Hoernquist-Aestrand and Sam Hartman for their important contributions to this document.
作者希望感谢Love Hoernquist Aestrand和Sam Hartman对本文件的重要贡献。
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.
[RFC1964]Linn，J.，“Kerberos版本5 GSS-API机制”，RFC19641996年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002.
[RFC3339]Klyne，G.，Ed.和C.Newman，“互联网上的日期和时间：时间戳”，RFC33392002年7月。
[RFC3961] Raeburn, K., "Encryption and Checksum Specifications for Kerberos 5", RFC 3961, February 2005.
[RFC3961]Raeburn，K.，“Kerberos 5的加密和校验和规范”，RFC 3961，2005年2月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[RFC4120]Neuman，C.，Yu，T.，Hartman，S.，和K.Raeburn，“Kerberos网络身份验证服务（V5）”，RFC41202005年7月。
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
[RFC4122]Leach，P.，Mealling，M.和R.Salz，“通用唯一标识符（UUID）URN名称空间”，RFC 4122，2005年7月。
[RFC4517] Legg, S., "Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules", RFC 4517, June 2006.
[RFC4517]Legg，S.，“轻量级目录访问协议（LDAP）：语法和匹配规则”，RFC4517，2006年6月。
[PASSWORD] Williams, N., "Kerberos Set/Change Key/Password Protocol Version 2", Work in Progress, November 2008.
[密码]Williams，N.，“Kerberos设置/更改密钥/密码协议版本2”，正在进行的工作，2008年11月。
[RFC4510] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Technical Specification Road Map", RFC 4510, June 2006.
[RFC4510]Zeilenga，K.，“轻量级目录访问协议（LDAP）：技术规范路线图”，RFC45102006年6月。
Author's Address
作者地址
Leif Johansson Swedish University Network Thulegatan 11 Stockholm Sweden
Leif Johansson瑞典大学网络Thulegatan 11瑞典斯德哥尔摩
EMail: leifj@sunet.se
URI: http://www.sunet.se
EMail: leifj@sunet.se
URI: http://www.sunet.se