[要約] RFC 5554は、GSS-APIのチャネルバインディングの使用に関する要約と拡張を提供しています。目的は、セキュリティアプリケーションプログラムインターフェース（GSS-API）のセキュリティ強化と相互運用性の向上です。
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.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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およびこのドキュメントの公開日（http://trustee.ietf.org/license-info）に有効なIETFドキュメントに関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
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
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「optional」は、[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 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).
以下に示すように、RFC 2743で使用されているのと同じpseudo-asn.1を使用して、以下に一般化します。以下の図は、実際、有効なASN.1 [ccitt.x680]タイプですが、完全なASNを提供しません。この構造の標準エンコードが必要ないため、1つのモジュールは必要ありません。以下の定義は、ワイヤー上のビットを定義するプロトコルの一部ではなく、抽象APIの一部です。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
}
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チャネルバインディングのアプリケーションデータフィールドにのみ対応することを想定する必要があります。GSSチャネルバインディングの一部のエンコーディングよりも。
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チャネルバインディング構造のエンコーディングを説明し、そのエンコードをハッシュします。他の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.
チャネルバインディングにOctet String（または同等）を使用する言語バインディングは、チャネルバインディングとしてのネットワークアドレスの使用をサポートしません。チャネルバインディングとしてのネットワークアドレスの使用は一般に安全ではないため、これはセキュリティの問題を引き起こすべきではありません。ただし、「エンドポイントチャネルバインディング」をネットワークアドレスとしてモデル化しないことが重要です。それ以外の場合、このようなチャネルバインディングは、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。、「Generic Security Service Application Program Interfaceバージョン2、Update 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-Bindings」、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 4121、2005年7月。
[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007.
[RFC5056]ウィリアムズ、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]国際電話および電信協議委員会、「抽象的構文表記1（ASN.1）：基本表記の仕様」、CCITT推奨X.680、2002年7月。
Author's Address
著者の連絡先
Nicolas Williams Sun Microsystems 5300 Riata Trace Ct Austin, TX 78727 US
ニコラス・ウィリアムズサンマイクロシステムズ5300リアタトレースCTオースティン、テキサス78727 US
EMail: Nicolas.Williams@sun.com