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と、この文書(http://trustee.ietf.org/license-info)の発行日に有効なIETFドキュメントに関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。
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-バインディング仕様[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-バインディング文書に指定されているが、それは最初から、一般的なされている必要があり、その一部を一般化します。
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].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "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]はチャネル結合のための施設を提供します。それOCTET STRINGとしてモデルチャネルバインディングとGSS-APIのバージョン2にそれを残し、チャネルバインディングOCTET文字列の内容の構造を指定する1 C-バインディング仕様を更新します。 C-バインディング仕様[RFC2744]は、チャネルバインディングのための一般的な構造となっているべきか、Cの点で、定義しています。そうでない場合、機構のチャネル結合機能を他の言語バインディングと共に使用可能ではないであろう - ケルベロス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).
以下に示すように下の図は、実際に、有効なASN.1 [CCITT.X680]タイプですが、私たちは、RFC 2743で使用されているのと同じ疑似ASN.1を使用して、それを一般化、我々は完全な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チャネルバインディングのアプリケーション・データ・フィールドにのみ対応するオクテットストリング(または言語の等価物)としてGSS-APIモデルチャネルバインディングのバインディング言語を想定しなければならない場合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チャネルバインディング構造の符号化を説明し、その符号化をハッシュ。その他の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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.
[RFC2743]リン、J.、 "ジェネリックセキュリティーサービス適用業務プログラムインタフェースバージョン2、アップデート1"、RFC 2743、2000年1月。
[RFC2744] Wray, J., "Generic Security Service API Version 2 : C-bindings", RFC 2744, January 2000.
[RFC2744]レイ、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]朱、L.、Jaganathan、K.、およびS.ハートマン、 "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
ニコラス・ウィリアムズSun Microsystemsの5300 RiataトレースのCtオースティン、TX 78727米国
EMail: Nicolas.Williams@sun.com
メールアドレス:Nicolas.Williams@sun.com