Network Working Group S. Hartman
Request for Comments: 4768 MIT
Category: Informational December 2006
Network Working Group S. Hartman
Request for Comments: 4768 MIT
Category: Informational December 2006
Desired Enhancements to Generic Security Services Application Program Interface (GSS-API) Version 3 Naming
通用安全服务应用程序接口（GSS-API）第3版命名的预期增强功能
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
Abstract
摘要
The Generic Security Services API (GSS-API) provides a naming architecture that supports name-based authorization. GSS-API authenticates two named parties to each other. Names can be stored on access control lists (ACLs) to make authorization decisions. Advances in security mechanisms and the way implementers wish to use GSS-API require this model to be extended for the next version of GSS-API. As people move within an organization or change their names, the name authenticated by GSS-API may change. Using some sort of constant identifier would make ACLs more stable. Some mechanisms, such as public-key mechanisms, do not have a single name to be used across all environments. Other mechanisms, such as Kerberos, may include group membership or role information as part of authentication. This document motivates extensions to GSS-API naming and describes the extensions under discussion.
通用安全服务API（GSS-API）提供了支持基于名称的授权的命名体系结构。GSS-API相互验证两个指定方。名称可以存储在访问控制列表（ACL）上，以做出授权决策。安全机制的进步和实现者希望使用GSS-API的方式要求在下一版本的GSS-API中扩展此模型。当人们在组织内移动或更改姓名时，GSS-API认证的姓名可能会更改。使用某种常量标识符将使ACL更加稳定。某些机制（如公钥机制）没有一个可在所有环境中使用的名称。其他机制（如Kerberos）可能包括组成员身份或角色信息作为身份验证的一部分。本文档鼓励对GSS-API命名进行扩展，并描述了讨论中的扩展。
Table of Contents
目录
1. Introduction ....................................................2
2. Kerberos Naming .................................................3
3. X.509 Names .....................................................4
4. Composite Names .................................................5
4.1. Usage of Name Attributes ...................................6
4.2. Open Issues ................................................6
4.3. Handling gss_export_name ...................................7
5. Credential Extensions ...........................................7
6. Mechanisms for Export Name ......................................8
7. Selection of Source Identity ....................................8
8. Compatibility with GSS-API V2 ...................................9
9. Security Considerations .........................................9
10. Acknowledgements ..............................................10
11. Informative References ........................................10
1. Introduction ....................................................2
2. Kerberos Naming .................................................3
3. X.509 Names .....................................................4
4. Composite Names .................................................5
4.1. Usage of Name Attributes ...................................6
4.2. Open Issues ................................................6
4.3. Handling gss_export_name ...................................7
5. Credential Extensions ...........................................7
6. Mechanisms for Export Name ......................................8
7. Selection of Source Identity ....................................8
8. Compatibility with GSS-API V2 ...................................9
9. Security Considerations .........................................9
10. Acknowledgements ..............................................10
11. Informative References ........................................10
The Generic Security Services API [2] authenticates two named parties to each other. GSS names can be imported in a variety of formats through the gss_import_name call. Several mechanism-independent name formats are provided, including GSS_C_NT_HOSTBASED_SERVICE for services running on an Internet host, and GSS_C_NT_USER_NAME for the names of users. Other mechanism-specific name types are also provided. By the time a name is used in acquiring a mechanism-specific credential or establishing a security context, it has been transformed into one of these mechanism-specific name types. In addition, the GSS-API provides a function called gss_export_name that will transform a GSS-API name into a binary blob suitable for comparisons. This binary blob can be stored on ACLs and then authorization decisions can be made simply by comparing the name exported from a newly accepted context to the name on the ACL.
通用安全服务API[2]对两个指定方进行相互身份验证。GSS名称可以通过GSS_import_name调用以多种格式导入。提供了几种与机制无关的名称格式，包括用于在Internet主机上运行的服务的GSS_C_NT_HOSTBASED_服务，以及用于用户名称的GSS_C_NT_USER_名称。还提供了其他特定于机制的名称类型。当名称用于获取特定于机制的凭据或建立安全上下文时，它已转换为这些特定于机制的名称类型之一。此外，GSS-API提供了一个名为GSS_export_name的函数，该函数将GSS-API名称转换为适合比较的二进制blob。这个二进制blob可以存储在ACL上，然后只需将从新接受的上下文导出的名称与ACL上的名称进行比较，就可以做出授权决策。
Storing names on ACLs can be problematic because names tend to change over time. If the name contains organizational information, such as a domain part or an indication of what department someone works for, this changes as the person moves around the organization. Even if no organizational information is included in the name, the name will change as people change their names. Updating ACLs to reflect name changes is difficult. Another significant problem is that names can be reused to apply to an entity other than the entity to which they originally applied. For example, if a Unix user ID is placed on an ACL, the account deleted and then a new user assigned the old ID, then that new user may gain privileges intended for the old user.
在ACL上存储名称可能会有问题，因为名称往往会随着时间的推移而改变。如果名称包含组织信息，例如域部分或某人工作所在部门的指示，则随着该人员在组织中的移动而改变。即使名称中不包含任何组织信息，名称也会随着人们更改名称而更改。更新ACL以反映名称更改很困难。另一个重要的问题是，名称可以重复使用以应用于它们最初应用到的实体以外的实体。例如，如果将Unix用户ID放在ACL上，删除帐户，然后新用户分配旧ID，则该新用户可能会获得旧用户的特权。
Inherent in the GSS naming model is the idea that mechanism names need to be able to be represented in a single canonical form. Anyone importing that name needs to be able to retrieve the canonical form of that name.
GSS命名模型固有的思想是，机制名称需要能够以单一规范形式表示。任何导入该名称的人都需要能够检索该名称的规范形式。
Several security mechanisms have been proposed for which this naming architecture is too restrictive. In some cases, it is not always possible to canonicalize any name that is imported. In other cases, there is no single canonical name.
已经提出了几种安全机制，这种命名体系结构对这些机制的限制太大。在某些情况下，并不总是能够规范化导入的任何名称。在其他情况下，没有单一的规范名称。
Also, as GSS-API is used in more complex environments, there is a desire to use attribute certificates [6], Kerberos authorization data [3], or other non-name-based authorization models. GSS-API needs to be enhanced in order to support these uses in a mechanism-independent manner.
此外，由于GSS-API用于更复杂的环境，因此需要使用属性证书[6]、Kerberos授权数据[3]或其他非基于名称的授权模型。GSS-API需要增强，以便以独立于机制的方式支持这些用途。
This document discusses the particular naming problems with two important classes of GSS-API mechanisms. It also discusses the set of proposed solutions and their associated open issues. This document limits discussion to these solutions and provides a description of the problem against which the solutions can be judged. These solutions are targeted for incorporation into GSS-API Version 3.
本文档讨论两类重要的GSS-API机制的特定命名问题。它还讨论了一组建议的解决方案及其相关的未决问题。本文件仅对这些解决方案进行讨论，并提供了对问题的描述，可根据这些问题判断解决方案。这些解决方案旨在并入GSS-API第3版。
The Kerberos mechanism demonstrates both the naming stability problem and the authorization extension problem.
Kerberos机制演示了命名稳定性问题和授权扩展问题。
The Kerberos Referrals document [4] proposes a new type of Kerberos name called an enterprise name. The intent is that the enterprise name is an alias that the user knows for themselves and can use to log in. The Kerberos Key Distribution Center (KDC) translates this name into a normal Kerberos principal and gives the user tickets for this principal. This normal principal is used for authorization. The intent is that the enterprise name tracks the user as they moves throughout the organization, even if they move to parts of the organization that have different naming policies. The name they type at login remains constant, but the Kerberos principal used to authenticate them to services changes.
Kerberos Referrals文档[4]提出了一种新类型的Kerberos名称，称为企业名称。其目的是，企业名称是用户自己知道的别名，可以用于登录。Kerberos密钥分发中心（KDC）将此名称转换为正常的Kerberos主体，并提供此主体的用户票证。此正常主体用于授权。这样做的目的是，企业名称在用户在整个组织中移动时跟踪用户，即使他们移动到组织中具有不同命名策略的部分。他们在登录时键入的名称保持不变，但用于向服务验证他们的Kerberos主体发生了更改。
Unauthenticated services cannot generally perform a mapping from enterprise name to principal name. Even authenticated services may not be authorized to map names other than the name of the authenticated service. Also, Kerberos does not (and does not plan to) provide a mechanism for mapping enterprise names to principals besides authentication as the enterprise name. Thus, any such mapping would be vendor-specific. With this feature in Kerberos, it
未经验证的服务通常无法执行从企业名称到主体名称的映射。即使是经过身份验证的服务也可能无权映射经过身份验证的服务名称以外的名称。此外，除了作为企业名称进行身份验证之外，Kerberos没有（也不打算）提供将企业名称映射到主体的机制。因此，任何此类映射都是特定于供应商的。通过Kerberos中的此功能，它
is not possible to implement gss_canonicalize_name for enterprise name types. Of course, other name types such as traditional principal names could be used for GSS-API applications. Naturally, this loses the benefits of enterprise names.
无法为企业名称类型实现gss_规范化_名称。当然，GSS-API应用程序也可以使用其他名称类型，如传统的主体名称。自然，这就失去了企业名称的好处。
Another issue arises with enterprise names. In some cases, it would be desirable to put the enterprise name on the ACL instead of a principal name for greater ACL stability. At first glance, this could be accomplished by including the enterprise name in the name exported by gss_export_name. Unfortunately, if this were done, the exported name would change whenever the mapping changed, invalidating any ACL entries based off the old exported name and defeating the purpose of including the enterprise name in the exported name. In some cases, it would be desirable to have the exported name be based on the enterprise name and, in others, based on the principal name, but this is not permitted by the current GSS-API.
另一个问题是企业名称。在某些情况下，最好将企业名称放在ACL上，而不是主体名称，以提高ACL的稳定性。乍一看，这可以通过在gss_export_name导出的名称中包含企业名称来实现。不幸的是，如果这样做，则无论映射何时更改，导出的名称都会更改，从而使基于旧导出名称的任何ACL条目无效，并且无法实现将企业名称包含在导出名称中的目的。在某些情况下，希望导出名称基于企业名称，在其他情况下基于主体名称，但当前GSS-API不允许这样做。
Another development also complicates GSS-API naming for Kerberos. Several vendors have been looking at mechanisms to include group membership information in Kerberos authorization data. It is desirable to put these group names on ACLs. Again, GSS-API currently has no mechanism to use this information.
另一个发展也使Kerberos的GSS-API命名复杂化。一些供应商一直在研究在Kerberos授权数据中包含组成员信息的机制。最好将这些组名放在ACL上。同样，GSS-API目前没有使用此信息的机制。
X.509 names are more complicated than Kerberos names. In the Kerberos case, there is a single principal carried in all Kerberos messages. X.509 certificates have multiple options. It seems the subject name might be the appropriate name to use as the name to be exported in a GSS-API mechanism. However, RFC 3280 [5] allows the subject name to be an empty sequence in end-entity certificates. Therefore, the subjectAltName extension might be the only portion of the certificate that identifies the subject. As in the case of Kerberos group memberships, there may be many subjectAltName extensions available in a certificate. Different applications will care about different name forms. One possible candidate for an exported name would be all the names from the subject field, and the subjectAltName extension from a certificate. However, as new names are added, existing ACL entries would be invalidated; this is undesirable. Thus, there is no single value that can be defined as the exported GSS-API name that will be useful in all environments.
X.509名称比Kerberos名称更复杂。在Kerberos的情况下，所有Kerberos消息中都包含一个主体。X.509证书有多个选项。似乎主题名称可能是在GSS-API机制中用作要导出的名称的合适名称。但是，RFC 3280[5]允许使用者名称在最终实体证书中为空序列。因此，subjectAltName扩展可能是证书中唯一标识主题的部分。与Kerberos组成员身份一样，证书中可能有许多subjectAltName扩展。不同的应用程序将关注不同的名称形式。导出名称的一个可能候选项是subject字段中的所有名称，以及证书中的subjectAltName扩展名。但是，随着新名称的添加，现有ACL条目将失效；这是不可取的。因此，没有一个值可以定义为导出的GSS-API名称，该名称在所有环境中都很有用。
A profile of a particular X.509 GSS-API mechanism could require that a specific name be used. However, this would limit that mechanism to require a particular type of certificate. There is interest in being able to use arbitrary X.509 certificates with GSS-API for some applications.
特定X.509 GSS-API机制的配置文件可能需要使用特定名称。但是，这将限制该机制需要特定类型的证书。对于某些应用程序，可以将任意X.509证书与GSS-API一起使用，这是一个有趣的问题。
Experience so far has not led to sufficient interoperability with GSS-API X.509 mechanisms. Even if the subject name is used, there is ambiguity in how to handle sorting of name components. Martin Rex said that he was aware of several SPKM [1] implementations, but that no two were fully interoperable on names.
迄今为止的经验还没有导致与GSS-API X.509机制的充分互操作性。即使使用了主题名称，如何处理名称组件的排序也存在歧义。Martin Rex说，他知道有几种SPKM[1]实现，但没有两种实现在名称上完全可互操作。
Also, as discussed in the introduction, it is desirable to support X.509 attribute certificates.
此外，如引言中所述，支持X.509属性证书是可取的。
One proposal to solve these problems is to extend the concept of a GSS-API name to include a set of name attributes. Each attribute would be an octet-string labeled by an OID. Examples of attributes would include Kerberos enterprise names, group memberships in an authorization infrastructure, and Kerberos authorization data attributes and subjectAltName attributes in a certificate. Several new operations would be needed:
解决这些问题的一个建议是扩展GSS-API名称的概念，以包括一组名称属性。每个属性都是由OID标记的八位字节字符串。属性的示例包括Kerberos企业名称、授权基础结构中的组成员身份，以及证书中的Kerberos授权数据属性和subjectAltName属性。将需要几项新的行动：
1. Add an attribute to name.
1. 将属性添加到名称。
2. Query attributes of name.
2. 查询名称的属性。
3. Query values of an attribute.
3. 查询属性的值。
4. Delete an attribute from a name.
4. 从名称中删除属性。
5. Export a complete composite name and all its attributes for transport between processes.
5. 导出完整的复合名称及其所有属性，以便在进程之间传输。
Note that an exported composite name would not generally be suitable for binary comparison. Avoiding confusion between this operation and the existing gss_export_name operation will require careful work. However, many attributes of composite names will be appropriate for binary comparisons. Such attributes can be used on ACLs, just as exported names are used on ACLs today. For example, if a particular SubjectAltName extension contains the appropriate identity for an application, then the name attribute for this SubjectAltName can be placed on the ACL. This is only true if the name attribute is stored in some canonical form.
请注意，导出的复合名称通常不适合进行二进制比较。要避免将此操作与现有gss_导出_名称操作混淆，需要仔细操作。但是，复合名称的许多属性都适用于二进制比较。这些属性可以在ACL上使用，就像导出的名称现在在ACL上使用一样。例如，如果特定SubjectAltName扩展包含应用程序的适当标识，则此SubjectAltName的name属性可以放置在ACL上。只有当name属性以某种规范形式存储时，才会出现这种情况。
Additional utility operations will probably be needed depending on the implementation of name attributes.
根据名称属性的实现，可能需要额外的实用程序操作。
Since attributes are part of GSS-API names, the acceptor can retrieve the attributes of the initiator's and acceptor's name from the context. These attributes can then be used for authorization.
由于属性是GSS-API名称的一部分，因此接受者可以从上下文中检索启动器和接受者名称的属性。然后，这些属性可用于授权。
Most name attributes will probably not come from explicit operations to add attributes to a name. Instead, name attributes will probably come from mechanism-specific credentials. Components of these mechanism-specific credentials may come from platform or environment-specific names. Mechanism-specific naming and group membership can be mapped into name attributes by the mechanism implementation. The specific form of this mapping will generally require protocol specification for each mechanism.
大多数名称属性可能不会来自向名称添加属性的显式操作。相反，名称属性可能来自特定于机制的凭据。这些特定于机制的凭据的组件可能来自特定于平台或环境的名称。机制实现可以将特定于机制的命名和组成员身份映射到名称属性中。这种映射的具体形式通常需要每个机制的协议规范。
This section describes parts of the proposal to add attributes to names that will need to be explored before the proposal can become a protocol specification.
本节描述了提案的部分内容，以向名称添加属性，在提案成为协议规范之前，需要对这些属性进行研究。
Are mechanisms expected to be able to carry arbitrary name attributes as part of a context establishment? At first, it seems like this would be desirable. However, the purpose of GSS-API is to establish an authenticated context between two peers. In particular, a context authenticates two named entities to each other. The names of these entities and attributes associated with these names will be used for authorization decisions. If an initiator or acceptor is allowed to assert name attributes, and the authenticity of these assertions is not validated by the mechanisms, then security problems will result. On the other hand, requiring that name attributes be mechanism-specific and only be carried by mechanisms that understand the name attributes and can validate them compromises GSS-API's place as a generic API. Application authors would be forced to understand mechanism-specific attributes to make authorization decisions. In addition, if mechanisms are not required to transport arbitrary attributes, then application authors will need to deal with different implementations of the same mechanism that support different sets of name attributes. One possible solution is to carry a source along with each name attribute; this source could indicate whether the attribute comes from a mechanism data structure or from the other party in the authentication.
作为上下文建立的一部分，是否期望机制能够携带任意名称属性？起初，这似乎是可取的。然而，GSS-API的目的是在两个对等方之间建立经过身份验证的上下文。特别是，上下文相互验证两个命名实体。这些实体的名称以及与这些名称关联的属性将用于授权决策。如果允许发起者或接受者断言名称属性，而这些断言的真实性未通过机制验证，则会导致安全问题。另一方面，要求名称属性是特定于机制的，并且只能由理解名称属性并能够验证它们的机制携带，这会损害GSS-API作为通用API的地位。应用程序作者将被迫理解特定于机制的属性，以做出授权决策。此外，如果不需要机制来传输任意属性，那么应用程序作者将需要处理支持不同名称属性集的同一机制的不同实现。一种可能的解决方案是将源与每个名称属性一起携带；该源可以指示该属性是来自机制数据结构还是来自身份验证中的另一方。
Another related question is how name attributes will be mapped into their mechanism-specific forms. For example, it would be desirable to map many Kerberos authorization data elements into name attributes. In the case of the Microsoft PAC (privilege attribute certificate), it would be desirable for some applications to get the
另一个相关的问题是如何将名称属性映射到其特定于机制的形式中。例如，需要将许多Kerberos授权数据元素映射到名称属性中。对于Microsoft PAC（特权属性证书），某些应用程序需要获得
entire PAC. However, in many cases, the specific lists of security IDs contained in the PAC would be more directly useful to an application. So there may not be a good one-to-one mapping between the mechanism-specific elements and the representation desirable at the GSS-API layer.
整个PAC。但是，在许多情况下，PAC中包含的特定安全ID列表对应用程序更直接有用。因此，机制特定元素与GSS-API层所需的表示之间可能没有良好的一对一映射。
Specific name matching rules need to be developed. How do names with attributes compare? What is the effect of a name attribute on a target name in gss_accept_sec_context?
需要制定具体的名称匹配规则。名称与属性如何比较？名称属性对gss_accept_sec_上下文中的目标名称有什么影响？
For many mechanisms, there will be an obvious choice to use for the name exported by gss_export_name. For example, in the case of Kerberos, the principal name can continue to be used as the exported name. This will allow applications that depend on existing GSS-API name-based authorization to continue to work. However, it is probably desirable to allow GSS-API mechanisms for which gss_export_name cannot meaningfully be defined. In such cases, the behavior of gss_export_name should probably be to return some error. Such mechanisms may not work with existing applications and cannot conform to the current version of the GSS-API.
对于许多机制，gss_export_name导出的名称有一个明显的选择。例如，在Kerberos的情况下，主体名称可以继续用作导出名称。这将允许依赖现有GSS-API基于名称的授权的应用程序继续工作。然而，可能需要允许GSS-API机制，因为GSS_导出_名称无法有意义地定义。在这种情况下，gss_export_name的行为可能会返回一些错误。此类机制可能无法与现有应用程序配合使用，并且无法符合GSS-API的当前版本。
An alternative to the name attributes proposal is to extend GSS-API credentials with extensions labeled by OIDs. Interfaces would be needed to manipulate these credential extensions and to retrieve the credential extensions for credentials used to establish a context. Even if name attributes are used, credential extensions may be useful for other unrelated purposes.
名称属性建议的替代方案是使用OID标记的扩展扩展扩展GSS-API凭据。需要接口来操作这些凭证扩展，并检索用于建立上下文的凭证的凭证扩展。即使使用了名称属性，凭证扩展也可能对其他不相关的用途有用。
It is possible to solve problems discussed in this document using some credential extension mechanism. Doing so will have many of the same open issues as discussed in the composite names proposal. The main advantage of a credential extensions proposal is that it avoids specifying how name attributes interact with name comparison or target names.
使用一些凭证扩展机制可以解决本文档中讨论的问题。这样做将有许多与复合名称提案中讨论的相同的未决问题。凭证扩展方案的主要优点是，它避免指定名称属性如何与名称比较或目标名称交互。
The primary advantage of the name attributes proposal over credential extensions is that name attributes seem to fit better into the GSS-API authorization model. Names are already available at all points when authorization decisions are made. In addition, for many mechanisms, the sort of information carried as name attributes will also be carried as part of the name in the mechanism.
与凭证扩展相比，名称属性方案的主要优势在于名称属性似乎更适合GSS-API授权模型。在做出授权决策时，所有点上的名称都已可用。此外，对于许多机制，作为名称属性携带的信息种类也将作为机制中名称的一部分携带。
Another proposal is to define some GSS-API mechanisms whose only purpose is to have an exportable name form that is useful. For example, you might be able to export a name as a local machine user ID with such a mechanism.
另一个建议是定义一些GSS-API机制，其唯一目的是拥有一个有用的可导出名称表单。例如，您可以使用这种机制将名称导出为本地计算机用户ID。
This solution works well for name information that can be looked up in a directory. It was unclear whether this solution would allow mechanism-specific name information to be extracted from a context. If so, then this solution would meet many of the goals of this document.
此解决方案适用于可以在目录中查找的名称信息。目前尚不清楚该解决方案是否允许从上下文中提取特定于机制的名称信息。如果是这样，那么该解决方案将满足本文档的许多目标。
One advantage of this solution is that it requires few, if any, changes to GSS-API semantics. It is not as flexible as other solutions. Also, it is not clear how to handle mechanisms that do not have a well-defined name to export with this solution.
此解决方案的一个优点是，它几乎不需要对GSS-API语义进行任何更改。它不像其他解决方案那样灵活。此外，还不清楚如何处理没有定义好的名称的机制，以便使用此解决方案导出。
Today, applications such as e-mail clients and Web browsers require connections to multiple targets. For each target, there may be one or more source identities that is appropriate for the connection. Currently each application must choose the source name to use when acquiring credentials or initiating a security context. However, the rules that applications use can be generalized to a large extent. GSS-API could simplify application design and implementation by taking a larger role in selection of source identity to use when connecting to a particular target.
如今，电子邮件客户端和Web浏览器等应用程序需要连接到多个目标。对于每个目标，可能有一个或多个适用于连接的源标识。当前，每个应用程序必须选择在获取凭据或启动安全上下文时使用的源名称。然而，应用程序使用的规则在很大程度上可以通用化。GSS-API可以在选择连接到特定目标时使用的源标识方面发挥更大的作用，从而简化应用程序的设计和实现。
Currently, GSS-API credentials represent a single mechanism name. That is, by the time credentials are acquired, they must act as if a particular single identity is chosen for each mechanism in the credential. All these identities must correspond to a single mechanism independent name.
目前，GSS-API凭据表示单个机制名称。也就是说，在获取凭据时，它们必须像为凭据中的每个机制选择了特定的单个标识一样工作。所有这些标识必须对应于一个独立于机制的名称。
Two possibilities have been proposed for involving GSS-API in the selection of source identities. First, the restriction that a mechanism name must be chosen when credentials are acquired could be relaxed. Some name form would need to be used, but this name form could represent a set of possibilities. The particular identity would be chosen when context establishment happened. This could involve information received from the target in identity selection.
已经提出了两种可能性，即GSS-API参与源标识的选择。首先，可以放宽获取凭据时必须选择机制名称的限制。需要使用一些名称形式，但此名称形式可以表示一组可能性。当上下文建立时，将选择特定的身份。这可能涉及在身份选择中从目标接收到的信息。
Another possibility is to provide a mechanism to acquire credentials and to provide information about the target when credentials are acquired. This would be much less of a change to GSS-API, but would not allow information received from the target to choose identity selection.
另一种可能性是提供一种获取凭据的机制，并在获取凭据时提供有关目标的信息。这对GSS-API的更改要小得多，但不允许从目标接收到的信息选择身份。
With both approaches, information to communicate the needs of the application to the GSS-API mechanism will be required. For example, hinting about whether information can be cached and about the scope of cache entries is required.
对于这两种方法，都需要将应用程序的需求传达给GSS-API机制的信息。例如，需要提示是否可以缓存信息以及缓存项的范围。
Another possibility can be implemented in GSS-API V2 today: Do not bind the credentials to a mechanism name until either the credentials are queried or they are used to set up a context. This is undesirable because if an application uses the credential inquiry interface, then it will get different behavior than cases where this interface is not used. For this reason, the working group favors an extension to GSS-API V3.
今天，GSS-APIv2中可以实现另一种可能性：在查询凭据或使用凭据设置上下文之前，不要将凭据绑定到机制名称。这是不可取的，因为如果应用程序使用凭证查询接口，那么它将获得与不使用此接口的情况不同的行为。因此，工作组赞成对GSS-API V3进行扩展。
In order to avoid breaking existing applications or mechanisms, the following backward compatibility requirements need to be met:
为了避免破坏现有的应用程序或机制，需要满足以下向后兼容性要求：
1. Existing APIs must continue to behave as they do in GSS-API V2.
1. 现有API必须继续像在GSS-API V2中那样运行。
2. GSS-API V2 mechanisms must produce the same exported name forms; composite names cannot change the existing exported name forms.
2. GSS-API V2机制必须生成相同的导出名称表单；复合名称无法更改现有的导出名称表单。
3. Extensions add new optional behavior.
3. 扩展添加了新的可选行为。
If GSS-API V3 mechanisms are more permissive than GSS-API V2 mechanisms, then care must be taken so that GSS-API V2 applications do not select these mechanisms.
如果GSS-API V3机制比GSS-API V2机制更为宽松，则必须小心，以免GSS-API V2应用程序选择这些机制。
GSS-API sets up a security context between two named parties. The GSS-API names are security assertions that are authenticated by the context establishment process. As such, the GSS naming architecture is critical to the security of GSS-API.
GSS-API在两个命名方之间设置安全上下文。GSS-API名称是由上下文建立过程验证的安全断言。因此，GSS命名体系结构对GSS-API的安全性至关重要。
Currently, GSS-API uses a simplistic naming model for authorization. Names can be compared against a set of names on an access control list. This architecture is relatively simple, and its security properties are well understood. However, it does not provide the flexibility and feature set for future deployments of GSS-API.
目前，GSS-API使用简单的命名模型进行授权。可以将名称与访问控制列表上的一组名称进行比较。这种体系结构相对简单，其安全属性也很容易理解。但是，它没有为GSS-API的未来部署提供灵活性和功能集。
This proposal will significantly increase the complexity of the GSS naming architecture. As this proposal is fleshed out, we need to consider ways of managing security exposures created by this increased complexity.
该提案将显著增加GSS命名体系结构的复杂性。由于这项建议是充实的，我们需要考虑如何管理由这种复杂性增加造成的安全风险。
One area where the complexity may lead to security problems is composite names with attributes from different sources. This may be desirable so that name attributes can carry their own authentication. However, the design of any solutions needs to make sure that applications can assign appropriate trust to name components.
复杂性可能导致安全问题的一个方面是具有不同来源属性的组合名称。这可能是可取的，以便名称属性可以携带自己的身份验证。但是，任何解决方案的设计都需要确保应用程序可以为名称组件分配适当的信任。
John Brezak, Paul Leach, and Nicolas Williams all participated in discussions that led to a desire to enhance GSS naming. Martin Rex provided descriptions of the current naming architecture and pointed out many ways in which proposed enhancements would create interoperability problems or increase complexity. Martin also provided excellent information on what aspects of GSS naming have tended to be implemented badly or have not met the needs of some customers.
John Brezak、Paul Leach和Nicolas Williams都参与了讨论，希望加强GSS命名。Martin Rex提供了当前命名体系结构的描述，并指出了建议的增强可能会产生互操作性问题或增加复杂性的许多方式。Martin还提供了关于GSS命名的哪些方面往往实施得不好或未满足某些客户需求的优秀信息。
Nicolas Williams helped describe the possible approaches for enhancing naming.
Nicolas Williams帮助描述了增强命名的可能方法。
[1] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC 2025, October 1996.
[1] Adams，C.，“简单公钥GSS-API机制（SPKM）”，RFC 20251996年10月。
[2] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[2] 林恩，J.，“通用安全服务应用程序接口版本2，更新1”，RFC 2743，2000年1月。
[3] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005.
[3] Neuman，C.，Yu，T.，Hartman，S.，和K.Raeburn，“Kerberos网络身份验证服务（V5）”，RFC41202005年7月。
[4] Zhu, L., "Generating KDC Referrals to Locate Kerberos Realms", Work in Progress, June 2006.
[4] Zhu，L.，“生成KDC推荐以定位Kerberos领域”，正在进行的工作，2006年6月。
[5] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[5] Housley，R.，Polk，W.，Ford，W.，和D.Solo，“Internet X.509公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 32802002年4月。
[6] Farrell, S. and R. Housley, "An Internet Attribute Certificate Profile for Authorization", RFC 3281, April 2002.
[6] Farrell，S.和R.Housley，“用于授权的互联网属性证书配置文件”，RFC 3281，2002年4月。
Author's Address
作者地址
Sam Hartman MIT
麻省理工学院萨姆·哈特曼
EMail: hartmans-ietf@mit.edu
EMail: hartmans-ietf@mit.edu
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2006).
版权所有（C）IETF信托基金（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。