Network Working Group N. Williams
Request for Comments: 5554 Sun
Updates: 2743 May 2009
Category: Standards Track
Network Working Group N. Williams
Request for Comments: 5554 Sun
Updates: 2743 May 2009
Category: Standards Track
Clarifications and Extensions to the Generic Security Service Application Program Interface (GSS-API) for the Use of Channel Bindings
对使用通道绑定的通用安全服务应用程序接口（GSS-API）的澄清和扩展
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2009 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
本文件受BCP 78和IETF信托在本文件出版之日生效的与IETF文件有关的法律规定的约束(http://trustee.ietf.org/license-info). 请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。
Abstract
摘要
This document clarifies and generalizes the Generic Security Service Application Programming Interface (GSS-API) "channel bindings" facility, and imposes requirements on future GSS-API mechanisms and programming language bindings of the GSS-API.
本文档澄清并概括了通用安全服务应用程序编程接口（GSS-API）“通道绑定”功能，并对GSS-API的未来GSS-API机制和编程语言绑定提出了要求。
Table of Contents
目录
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
3. New Requirements for GSS-API Mechanisms .........................2
4. Generic Structure for GSS-API Channel Bindings ..................2
5. Security Considerations .........................................3
6. References ......................................................4
6.1. Normative References .......................................4
6.2. Informative References .....................................4
1. Introduction ....................................................2
2. Conventions Used in This Document ...............................2
3. New Requirements for GSS-API Mechanisms .........................2
4. Generic Structure for GSS-API Channel Bindings ..................2
5. Security Considerations .........................................3
6. References ......................................................4
6.1. Normative References .......................................4
6.2. Informative References .....................................4
The base GSS-API version 2, update 1 specification [RFC2743] provides a facility for channel binding (see also [RFC5056]), but its treatment is incomplete. The GSS-API C-bindings specification [RFC2744] expands somewhat on this facility in what should be a generic way, but is instead a C-specific way, thus leaving the treatment of this facility incomplete.
基本GSS-API版本2，更新1规范[RFC2743]提供了通道绑定功能（另请参见[RFC5056]），但其处理不完整。GSS-API C-bindings规范[RFC2744]在某种程度上以一种通用的方式对该设施进行了扩展，但实际上是一种特定于C的方式，因此对该设施的处理不完整。
This document clarifies the GSS-API's channel binding facility and generalizes the parts of it that are specified in the C-bindings document but that should have been generic from the start.
本文档阐明了GSS-API的通道绑定功能，并概括了C-bindings文档中指定但从一开始就应该是通用的部分。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Given the publication of RFC 5056, we now assert that all new GSS-API mechanisms that support channel binding MUST conform to [RFC5056].
鉴于RFC 5056的发布，我们现在断言所有支持通道绑定的新GSS-API机制必须符合[RFC5056]。
The base GSS-API version 2, update 1 specification [RFC2743] provides a facility for channel binding. It models channel bindings as an OCTET STRING and leaves it to the GSS-API version 2, update 1 C-bindings specification to specify the structure of the contents of the channel bindings OCTET STRINGs. The C-bindings specification [RFC2744] then defines, in terms of C, what should have been a generic structure for channel bindings. The Kerberos V GSS mechanism [RFC4121] also defines a method for encoding GSS channel bindings in a way that is independent of the C-bindings -- otherwise, the mechanism's channel binding facility would not be useable with other language bindings.
基本GSS-API版本2，更新1规范[RFC2743]提供了通道绑定功能。它将通道绑定建模为八位字节字符串，并将其留给GSS-API版本2，更新1 C-bindings规范来指定通道绑定八位字节字符串内容的结构。然后，C-bindings规范[RFC2744]用C定义了通道绑定的通用结构。Kerberos V GSS机制[RFC4121]还定义了一种方法，用于以独立于C绑定的方式对GSS通道绑定进行编码——否则，该机制的通道绑定功能将无法用于其他语言绑定。
In other words, the structure of GSS channel bindings given in [RFC2744] is actually generic in spite of being specified in terms of C concepts and syntax.
换句话说，[RFC2744]中给出的GSS通道绑定的结构实际上是通用的，尽管是根据C概念和语法指定的。
We generalize it as shown below, using the same pseudo-ASN.1 as is used in RFC 2743. Although the figure below is, indeed, a valid ASN.1 [CCITT.X680] type, we do not provide a full ASN.1 module as none is needed because no standard encoding of this structure is needed -- the definition below is part of an abstract API, not part
我们使用RFC2743中使用的相同伪ASN.1对其进行了如下概括。尽管下图确实是有效的ASN.1[CCITT.X680]类型，但我们不提供完整的ASN.1模块，因为不需要任何模块，因为不需要此结构的标准编码——下面的定义是抽象API的一部分，而不是抽象API的一部分
of a protocol defining bits on the wire. GSS-API mechanisms do need to encode the contents of this structure, but that encoding will be mechanism specific (see below).
在线路上定义位的协议。GSS-API机制确实需要对该结构的内容进行编码，但该编码将是特定于机制的（见下文）。
GSS-CHANNEL-BINDINGS ::= SEQUENCE {
initiator-address-type INTEGER, -- See RFC2744
initiator-address OCTET STRING, -- See RFC2744
acceptor-address-type INTEGER, -- See RFC2744
acceptor-address OCTET STRING, -- See RFC2744
application-data OCTET STRING -- See RFC5056
}
GSS-CHANNEL-BINDINGS ::= SEQUENCE {
initiator-address-type INTEGER, -- See RFC2744
initiator-address OCTET STRING, -- See RFC2744
acceptor-address-type INTEGER, -- See RFC2744
acceptor-address OCTET STRING, -- See RFC2744
application-data OCTET STRING -- See RFC5056
}
Abstract GSS-API Channel Bindings Structure
抽象GSS-API通道绑定结构
The values for the address fields are described in [RFC2744].
[RFC2744]中描述了地址字段的值。
New language-specific bindings of the GSS-API SHOULD specify a language-specific formulation of this structure.
GSS-API的新的特定于语言的绑定应该指定此结构的特定于语言的公式。
Where a language binding of the GSS-API models channel bindings as OCTET STRINGs (or the language's equivalent), then the implementation MUST assume that the given bindings correspond only to the application-data field of GSS-CHANNEL-BINDINGS as shown above, rather than some encoding of GSS-CHANNEL-BINDINGS.
如果GSS-API的语言绑定将通道绑定建模为八位字节字符串（或该语言的等效项），则实现必须假定给定绑定仅对应于GSS-channel-bindings的应用程序数据字段，如上图所示，而不是GSS-channel-bindings的某些编码。
As mentioned above, [RFC4121] describes an encoding of the above GSS-CHANNEL-BINDINGS structure and then hashes that encoding. Other GSS-API mechanisms are free to use that encoding.
如上所述，[RFC4121]描述了上述GSS-CHANNEL-BINDINGS结构的编码，然后对该编码进行散列。其他GSS-API机制可以自由使用该编码。
For general security considerations relating to channel bindings, see [RFC5056].
有关通道绑定的一般安全注意事项，请参阅[RFC5056]。
Language bindings that use OCTET STRING (or equivalent) for channel bindings will not support the use of network addresses as channel bindings. This should not cause any security problems, as the use of network addresses as channel bindings is not generally secure. However, it is important that "end-point channel bindings" not be modeled as network addresses; otherwise, such channel bindings may not be useable with all language bindings of the GSS-API.
使用八位字节字符串（或等效字符串）进行通道绑定的语言绑定不支持将网络地址用作通道绑定。这不会导致任何安全问题，因为使用网络地址作为通道绑定通常不安全。然而，重要的是“端点通道绑定”不能建模为网络地址；否则，此类通道绑定可能无法用于GSS-API的所有语言绑定。
[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月。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2743]Linn，J.，“通用安全服务应用程序接口版本2，更新1”，RFC 2743，2000年1月。
[RFC2744] Wray, J., "Generic Security Service API Version 2 : C-bindings", RFC 2744, January 2000.
[RFC2744]Wray，J.，“通用安全服务API第2版：C-绑定”，RFC 2744，2000年1月。
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2", RFC 4121, July 2005.
[RFC4121]Zhu，L.，Jaganathan，K.，和S.Hartman，“Kerberos版本5通用安全服务应用程序接口（GSS-API）机制：版本2”，RFC 41212005年7月。
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007.
[RFC5056]Williams，N.，“关于使用通道绑定保护通道”，RFC 5056，2007年11月。
[CCITT.X680] International Telephone and Telegraph Consultative Committee, "Abstract Syntax Notation One (ASN.1): Specification of basic notation", CCITT Recommendation X.680, July 2002.
[CCITT.X680]国际电话电报咨询委员会，“抽象语法符号一（ASN.1）：基本符号规范”，CCITT建议X.680，2002年7月。
Author's Address
作者地址
Nicolas Williams Sun Microsystems 5300 Riata Trace Ct Austin, TX 78727 US
Nicolas Williams Sun Microsystems 5300 Riata Trace Ct德克萨斯州奥斯汀78727美国
EMail: Nicolas.Williams@sun.com
EMail: Nicolas.Williams@sun.com