RFC 5801 - Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family 日本語訳

URL : https://tools.ietf.org/html/rfc5801
タイトル : RFC 5801 - GS2メカニズムファミリー：簡易認証セキュリティー層（SASL）で一般的なセキュリティサービスアプリケーションプログラムインタフェース（GSS-API）メカニズムを使用して
翻訳編集 : 自動生成

Internet Engineering Task Force (IETF)                      S. Josefsson
Request for Comments: 5801                                        SJD AB
Category: Standards Track                                    N. Williams
ISSN: 2070-1721                                                   Oracle
                                                               July 2010

Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family

GS2メカニズムファミリー：簡易認証セキュリティー層（SASL）で一般的なセキュリティサービスアプリケーションプログラムインタフェース（GSS-API）メカニズムを使用して

Abstract

抽象

This document describes how to use a Generic Security Service Application Program Interface (GSS-API) mechanism in the Simple Authentication and Security Layer (SASL) framework. This is done by defining a new SASL mechanism family, called GS2. This mechanism family offers a number of improvements over the previous "SASL/ GSSAPI" mechanism: it is more general, uses fewer messages for the authentication phase in some cases, and supports negotiable use of channel binding. Only GSS-API mechanisms that support channel binding and mutual authentication are supported.

この文書では、簡易認証セキュリティー層（SASL）枠組みの中で一般的なセキュリティサービスアプリケーションプログラムインタフェース（GSS-API）メカニズムを使用する方法について説明します。これは、GS2と呼ばれる新しいSASLメカニズムファミリを定義することによって行われます。このメカニズムファミリは、前の「SASL / GSSAPI」メカニズムの上に多くの改良を提供しています：それはより一般的で、いくつかのケースでは認証フェーズのためのより少ないメッセージを使用し、チャネルバインディングの交渉使用をサポートしています。結合チャネルと相互認証をサポートする唯一のGSS-APIメカニズムがサポートされています。

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/rfc5801.

このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc5801で取得することができます。

著作権表示

著作権（C）2010 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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.

この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版RFCとして、英語以外の言語に翻訳します。

Table of Contents

   1. Introduction ....................................................4
   2. Conventions Used in This Document ...............................5
   3. Mechanism Name ..................................................5
      3.1. Generating SASL Mechanism Names from GSS-API OIDs ..........5
      3.2. Computing Mechanism Names Manually .........................6
      3.3. Examples ...................................................6
      3.4. Grandfathered Mechanism Names ..............................7
   4. SASL Authentication Exchange Message Format .....................8
   5. Channel Bindings ...............................................10
      5.1. Content of GSS-CHANNEL-BINDINGS Structure .................11
      5.2. Default Channel Binding ...................................12
   6. Examples .......................................................12
   7. Authentication Conditions ......................................14
   8. GSS-API Parameters .............................................15
   9. Naming .........................................................15
   10. GSS_Inquire_SASLname_for_mech Call ............................15
      10.1. gss_inquire_saslname_for_mech ............................16
   11. GSS_Inquire_mech_for_SASLname Call ............................18
      11.1. gss_inquire_mech_for_saslname ............................19
   12. Security Layers ...............................................20
   13. Interoperability with the SASL GSSAPI Mechanism ...............20
      13.1. The Interoperability Problem .............................20
      13.2. Resolving the Problem ....................................20
      13.3. Additional Recommendations ...............................20
   14. GSS-API Mechanisms That Negotiate Other Mechanisms ............21
      14.1. The Interoperability Problem .............................21
      14.2. Security Problem .........................................21
      14.3. Resolving the Problems ...................................21
   15. IANA Considerations ...........................................22
   16. Security Considerations .......................................22
   17. Acknowledgements ..............................................24
   18. References ....................................................24
      18.1. Normative References .....................................24
      18.2. Informative References ...................................25

1. Introduction

1. はじめに

Generic Security Service Application Program Interface (GSS-API) [RFC2743] is a framework that provides security services to applications using a variety of authentication mechanisms. Simple Authentication and Security Layer (SASL) [RFC4422] is a framework to provide authentication and security layers for connection-based protocols, also using a variety of mechanisms. This document describes how to use a GSS-API mechanism as though it were a SASL mechanism. This facility is called GS2 -- a moniker that indicates that this is the second GSS-API->SASL mechanism bridge. The original GSS-API->SASL mechanism bridge was specified by [RFC2222], now [RFC4752]; we shall sometimes refer to the original bridge as GS1 in this document.

一般的なセキュリティサービスアプリケーションプログラムインタフェース（GSS-API）[RFC2743]は認証機構のさまざまな方法を使ってアプリケーションにセキュリティサービスを提供するフレームワークです。簡易認証およびセキュリティ層（SASL）[RFC4422]はまた、種々の機構を用いて、接続ベースのプロトコルの認証とセキュリティ層を提供するためのフレームワークです。この文書では、SASLメカニズムであるかのようにGSS-APIメカニズムを使用する方法について説明します。この第GSS-API-> SASL機構ブリッジであることを示しているモニカ - この機能は、GS2と呼ばれています。元のGSS-API-> SASL機構ブリッジは今[RFC2222]、[RFC4752]で指定されました。私たちは時々、この文書でGS1として元ブリッジを指すものとします。

All GSS-API mechanisms are implicitly registered for use within SASL by this specification. The SASL mechanisms defined in this document are known as the GS2 family of mechanisms.

すべてのGSS-APIメカニズムは、暗黙的にこの仕様によってSASL内で使用するために登録されています。この文書で定義されたSASLメカニズムは、メカニズムのGS2ファミリーとして知られています。

The GS1 bridge failed to gain wide deployment for any GSS-API mechanism other than "The Kerberos Version 5 GSS-API Mechanism" [RFC1964] [RFC4121], and has a number of problems that led us to desire a new bridge. Specifically, a) GS1 was not round-trip optimized and b) GS1 did not support channel binding [RFC5056]. These problems and the opportunity to create the next SASL password-based mechanism, "Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms" [RFC5802], as a GSS-API mechanism used by SASL applications via GS2, provide the motivation for GS2.

GS1ブリッジは、「Kerberosバージョン5 GSS-APIメカニズム」以外のGSS-APIメカニズム[RFC1964] [RFC4121]のための幅広い展開を得るために失敗し、新しい橋を望むために私たちを導いた多くの問題があります。具体的には、A）GS1は、最適化されたラウンドトリップではなかったと、b）GS1は、チャネルバインディング[RFC5056]をサポートしていませんでした。これらの問題は、次のSASLパスワードベースのメカニズムを作成する機会、「塩漬けチャレンジレスポンス認証メカニズム（SCRAM）SASLとGSS-APIメカニズム」[RFC5802]、GS2を経由してSASLアプリケーションで使用されるGSS-APIメカニズムとして、提供GS2の動機。

In particular, the current consensus of the SASL community appears to be that SASL "security layers" (i.e., confidentiality and integrity protection of application data after authentication) are too complex and redundant because SASL applications tend to have an option to run over a Transport Layer Security (TLS) [RFC5246] channel. Use of SASL security layers is best replaced with channel binding to a TLS channel.

特に、SASLコミュニティの現在のコンセンサスがあるように思われることSASL「セキュリティ層」（すなわち、機密性と認証後のアプリケーションデータの整合性の保護は）SASLアプリケーションはトランスポートを介して実行するオプションを持っている傾向があるので、あまりにも複雑で、冗長ですセキュリティ（TLS）[RFC5246]チャネルレイヤ。 SASLのセキュリティ層の使用は最良のチャネルは、TLSチャネルへの結合に置き換えられています。

GS2 is designed to be as simple as possible. It adds to GSS-API security context token exchanges only the bare minimum to support SASL semantics and negotiation of use of channel binding. Specifically, GS2 adds a small header (a few bytes plus the length of the client-requested SASL authorization identity) to the initial GSS-API context token and to the application channel binding data. GS2 uses SASL mechanism negotiation to implement channel binding negotiation. Security-relevant GS2 plaintext is protected via the use of GSS-API channel binding. Additionally, to simplify the implementation of GS2 mechanisms for implementors who will not implement a GSS-API framework, we compress the initial security context token header required by [RFC2743], Section 3.1.

GS2は、できるだけ簡単になるように設計されています。これは、GSS-APIのセキュリティコンテキストトークンの交換にSASLのセマンティクスと結合チャネルの使用のネゴシエーションをサポートする唯一の最低限を追加します。具体的には、GS2は、トークン初期GSS-APIのコンテキストへとデータを製本アプリケーションチャネルに小さなヘッダ（数バイトプラスクライアント要求SASL認可同一の長さ）を加算します。 GS2は、チャネル結合交渉を実装するためにSASLメカニズムの交渉を使用しています。セキュリティ関連GS2の平文を結合GSS-APIチャネルの使用によって保護されています。また、GSS-APIフレームワークを実装しません実装のためのGS2メカニズムの実装を簡素化するために、我々は[RFC2743]で必要とされる初期のセキュリティコンテキストトークンヘッダを圧縮し、3.1節。

GS2 does not protect any plaintext exchanged outside GS2, such as SASL mechanism negotiation plaintext, or application messages following authentication. But using channel binding to a secure channel over which all SASL and application plaintext is sent will cause all that plaintext to be authenticated.

GS2は、認証、次のSASLメカニズムの交渉平文、またはアプリケーションメッセージとしてGS2、外で交換任意の平文を保護しません。しかし、すべてのSASLとアプリケーション平文が送信される安全なチャネルへの結合チャネルを使用すると、すべてのその平文が認証されることになります。

2. Conventions Used in This Document

この文書で使用される2.表記

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]に記載されているように解釈されます。

The document uses many terms and function names defined in [RFC2743], as updated by [RFC5554].

[RFC5554]で更新された文書は、[RFC2743]で定義された多くの用語や関数名を使用しています。

3. Mechanism Name

3.機構名

There are two SASL mechanism names for any GSS-API mechanism used through this facility. One denotes that the server supports channel binding. The other denotes that it does not.

この機能によって使用されるすべてのGSS-APIメカニズムのための2つのSASLメカニズム名があります。一つは、サーバーは、チャネル結合をサポートしていることを示しています。他はそうでないことを示しています。

The SASL mechanism name for a GSS-API mechanism is that which is provided by that mechanism when it was specified, if one was specified. This name denotes that the server does not support channel binding. Add the suffix "-PLUS" and the resulting name denotes that the server does support channel binding. SASL implementations can use the GSS_Inquire_SASLname_for_mech call (see below) to query for the SASL mechanism name of a GSS-API mechanism.

GSS-APIメカニズムのSASLメカニズム名は1が指定された場合には、指定されたとき、そのメカニズムによって提供されるものです。この名前は、サーバが結合チャネルをサポートしていないことを示しています。接尾辞に「-Plus」を追加し、そして得られた名前は、サーバーが結合チャネルをサポートしていることを示しています。 SASLの実装は、GSS-APIメカニズムのSASL機構名を照会するGSS_Inquire_SASLname_for_mechコール（下記参照）を使用することができます。

If the GSS_Inquire_SASLname_for_mech interface is not used, the GS2 implementation needs some other mechanism to map mechanism Object Identifiers (OIDs) to SASL names internally. In this case, the implementation can only support the mechanisms for which it knows the SASL name. If GSS_Inquire_SASLname_for_mech() fails and the GS2 implementation cannot map the OID to a SASL mechanism name via some other means, then the GS2 implementation MUST NOT use the given GSS-API mechanism.

GSS_Inquire_SASLname_for_mechインタフェースを使用しない場合は、GS2の実装は、内部でSASL名に機構オブジェクト識別子（OID）をマッピングするために、いくつかの他のメカニズムを必要とします。この場合、実装は、それがSASL名を知っているメカニズムをサポートすることができます。 GSS_Inquire_SASLname_for_mech（）が失敗し、GS2の実装はいくつかの他の手段を介してSASLメカニズム名にOIDをマップすることができない場合は、GS2の実装では、指定されたGSS-APIメカニズムを使用してはなりません。

3.1. Generating SASL Mechanism Names from GSS-API OIDs

3.1. GSS-APIのOIDからSASLメカニズム名を生成します

For GSS-API mechanisms whose SASL names are not defined together with the GSS-API mechanism or in this document, the SASL mechanism name is concatenation of the string "GS2-" and the Base32 encoding [RFC4648] (with an uppercase alphabet) of the first 55 bits of the binary SHA-1 hash [FIPS.180-1.1995] string computed over the ASN.1 DER encoding [CCITT.X690.2002], including the tag and length octets, of the GSS-API mechanism's Object Identifier. The Base32 rules on padding characters and characters outside of the Base32 alphabet are not relevant to this use of Base32. If any padding or non-alphabet characters are encountered, the name is not a GS2 family mechanism name. This name denotes that the server does not support channel binding. Add the suffix "-PLUS" and the resulting name denotes that the server does support channel binding.

そのSASL名GSS-API機構または本書で一緒に定義されていない、SASL機構名は、文字列の連結「GS2-」とBase32エンコーディング[RFC4648]（大文字のアルファベットを有する）のあるGSS-API機構のGSS-API機構のオブジェクト識別子のタグと長さオクテットを含むASN.1 DERエンコーディング[CCITT.X690.2002]にわたって計算バイナリSHA-1ハッシュ[FIPS.180-1.1995]列の最初の55ビット。 Base32アルファベットの外側のパディング文字と文字のBase32ルールは、Base32のこの使用には関係がありません。任意のパディングまたは非アルファベット文字が発生した場合、名前はGS2ファミリー・メカニズム名ではありません。この名前は、サーバが結合チャネルをサポートしていないことを示しています。接尾辞に「-Plus」を追加し、そして得られた名前は、サーバーが結合チャネルをサポートしていることを示しています。

A GS2 mechanism that has a non-OID-derived SASL mechanism name is said to have a "user-friendly SASL mechanism name".

非OID由来SASLメカニズムの名前を持つGS2メカニズムは、「ユーザーフレンドリーなSASLメカニズム名」を持つと言われています。

3.2. Computing Mechanism Names Manually

3.2. コンピューティング・メカニズムの名前を手動で

The hash-derived GS2 SASL mechanism name may be computed manually. This is useful when the set of supported GSS-API mechanisms is known in advance. This eliminates the need to implement Base32, SHA-1, and DER in the SASL mechanism. The computed mechanism name can be used directly in the implementation, and the implementation need not be concerned if the mechanism is part of a mechanism family.

ハッシュ由来GS2 SASL機構名を手動で計算することができます。サポートGSS-APIメカニズムのセットが予め分かっている場合に便利です。これは、SASLメカニズムにBase32、SHA-1、およびDERを実装する必要がなくなります。計算されたメカニズム名は、実装に直接使用することができ、機構は、機構ファミリの一部である場合、実装は心配する必要はありません。

3.3. Examples

3.3. 例

The OID for the Simple Public-Key GSS-API Mechanism (SPKM-1) [RFC2025] is 1.3.6.1.5.5.1.1. The ASN.1 DER encoding of the OID, including the tag and length, is (in hex) 06 07 2b 06 01 05 05 01 01. The SHA-1 hash of the ASN.1 DER encoding is (in hex) 1c f8 f4 2b 5a 9f 80 fa e9 f8 31 22 6d 5d 9d 56 27 86 61 ad. Convert the first 7 octets to binary, drop the last bit, and re-group them in groups of 5, and convert them back to decimal, which results in these computations:

シンプルな公開鍵GSS-APIメカニズム（SPKM-1）[RFC2025]のためのOIDが1.3.6.1.5.5.1.1です。タグおよび長さを含むOIDのASN.1 DERエンコーディングは、（16進数）である06 07 2B 06 01 05 05 01 01 ASN.1 DERエンコーディングのSHA-1ハッシュは、（16進数）である1CのF8 F4部2b 5aは9F 80 FA E9 F8 31 22 6D 5D 9D 56 27 86 61広告。これらの計算では、その結果、第7オクテットは、バイナリに変換し、最後のビットを削除し、そして5のグループに再グループ化、及びバック小数に変換します：

hex: 1c f8 f4 2b 5a 9f 80

進：1C F8 F4 2bと5aは9F 80

binary: 00011100 11111000 11110100 00101011 01011010 10011111 1000000

バイナリ：00011100 11111000 11110100 00101011 01011010 10011111 1000000

binary in groups of 5: 00011 10011 11100 01111 01000 01010 11010 11010 10011 11110 00000

5のグループでバイナリ：00011 10011 11100 01111 01000 01010 11010 11010 10011 11110 00000

decimal of each group: 3 19 28 15 8 10 26 26 19 30 0 base32 encoding: D T 4 P I K 2 2 T 6 A

各グループの小数：3 19 28 15 8 10 26 26 19 30 0 base32エンコード：D T 4 P I K 2 2 T 6 A

The last step translates each decimal value using table 3 in Base32 [RFC4648]. Thus, the SASL mechanism name for the SPKM-1 GSSAPI mechanism is "GS2-DT4PIK22T6A".

最後のステップは、Base32 [RFC4648]の表3を使用して、各小数値を変換します。したがって、SPKM-1 GSSAPIメカニズムのSASL機構名は "GS2-DT4PIK22T6A" です。

The OID for the Kerberos V5 GSS-API mechanism [RFC1964] is 1.2.840.113554.1.2.2 and its DER encoding is (in hex) 06 09 2A 86 48 86 F7 12 01 02 02. The SHA-1 hash is 82 d2 73 25 76 6b d6 c8 45 aa 93 25 51 6a fc ff 04 b0 43 60. Convert the 7 octets to binary, drop the last bit, and re-group them in groups of 5, and convert them back to decimal, which results in these computations:

ケルベロスV5 GSS-APIメカニズム[RFC1964]のためのOIDは1.2.840.113554.1.2.2であり、そのDERエンコーディングはSHA-1ハッシュは、82 D2は06 09 2A 86 48 86 F7 12 01 02 02である（16進数）であります73 25 76 6B D6 C8 45 AA 93 25 51 6aはFC 04 B0 43 60 FF、その結果、バイナリ7つのオクテットを変換し、最後のビットを削除し、再度グループそれら5のグループに、バック小数に変換これらの計算で：

hex: 82 d2 73 25 76 6b d6

ヘキサン：D2 73 82 25 76 6B D6

binary: 10000010 11010010 01110011 00100101 01110110 01101011 1101011

バイナリ：10000010 11010010 01110011 00100101 01110110 01101011 1101011

binary in groups of 5: 10000 01011 01001 00111 00110 01001 01011 10110 01101 01111 01011

5のグループでバイナリ：10000 01011 01001 00111 00110 01001 01011 10110 01101 01111 01011

decimal of each group: 16 11 9 7 6 9 11 22 13 15 11

各グループの進：16 11 9 7 6 9 11 22 13 15 11

base32 encoding: Q L J H G J L W N P L

base32エンコード：Q L J H G J L W N P L

The last step translates each decimal value using table 3 in Base32 [RFC4648]. Thus, the SASL mechanism name for the Kerberos V5 GSS-API mechanism would be "GS2-QLJHGJLWNPL" and (because this mechanism supports channel binding) "GS2-QLJHGJLWNPL-PLUS". Instead, the next section assigns the Kerberos V5 mechanism a non-hash-derived mechanism name.

最後のステップは、Base32 [RFC4648]の表3を使用して、各小数値を変換します。「GS2-QLJHGJLWNPL-PLUSを」（このメカニズムがチャネルバインディングをサポートしているので）このように、ケルベロスV5 GSS-APIメカニズムのSASLメカニズム名は「GS2-QLJHGJLWNPL」こととなります。代わりに、次のセクションでは、Kerberos V5機構非ハッシュ由来機構名割り当てます。

3.4. Grandfathered Mechanism Names

3.4. 適用除外機構名

Some older GSS-API mechanisms were not specified with a SASL GS2 mechanism name. Using a shorter name can be useful, nonetheless. We specify the names "GS2-KRB5" and "GS2-KRB5-PLUS" for the Kerberos V5 mechanism, to be used as if the original specification documented it, see Section 15.

一部の古いGSS-API機構は、SASL GS2メカニズム名で指定されていませんでした。短い名前を使用すると、それにもかかわらず、便利です。元の仕様がそれを文書化した場合、セクション15を参照してくださいと私たちは、Kerberos V5メカニズムのための「GS2-KRB5」と「GS2-KRB5-PLUS」は、使用する名前を指定します。

4. SASL Authentication Exchange Message Format

4. SASL認証Exchangeメッセージのフォーマット

During the SASL authentication exchange for GS2, a number of messages following the following format are sent between the client and server. On success, this number is the same as the number of context tokens that the GSS-API mechanism would normally require in order to establish a security context. On failures, the exchange can be terminated early by any party.

GS2のためのSASL認証交換時には、次の形式を次のメッセージの数は、クライアントとサーバの間で送信されます。コンテキストの数は、GSS-APIメカニズムは、通常、セキュリティコンテキストを確立するために必要となることをトークンとして成功し、この数は同じです。故障では、交換は、当事者によって早期に終了させることができます。

When using a GS2 mechanism the SASL client is always a GSS-API initiator and the SASL server is always a GSS-API acceptor. The client calls GSS_Init_sec_context and the server calls GSS_Accept_sec_context.

GS2のメカニズムを使用する場合SASLクライアントは常にGSS-APIのイニシエータであるとSASLサーバーは常にGSS-APIアクセプターです。クライアントは、もしGSS_Init_sec_contextを呼び出し、サーバが場合gss_accept_sec_contextを呼び出します。

All the SASL authentication messages exchanged are exactly the same as the security context tokens of the GSS-API mechanism, except for the initial security context token.

交換され、すべてのSASL認証メッセージは、初期のセキュリティコンテキストトークンを除いて、GSS-API機構のセキュリティコンテキストトークンとまったく同じです。

The client and server MAY send GSS-API error tokens (tokens output by GSS_Init_sec_context() or GSS_Accept_sec_context() when the major status code is other than GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED). As this indicates an error condition, after sending the token, the sending side should fail the authentication.

（主要なステータスコードがGSS_S_COMPLETEまたはGSS_S_CONTINUE_NEEDED以外の場合もしGSS_Init_sec_context（）またはのgss_accept_sec_context（で出力トークン））、クライアントとサーバは、GSS-APIエラー・トークンを送信することができます。これはエラー状態を示しているように、トークンを送信した後、送信側は、認証に失敗しなければなりません。

The initial security context token is modified as follows:

次のように初期のセキュリティコンテキストトークンが変更されます。

o The initial context token header (see Section 3.1 of [RFC2743]) MUST be removed if present. If the header is not present, the client MUST send a "gs2-nonstd-flag" flag (see below). On the server side, this header MUST be recomputed and restored prior to passing the token to GSS_Accept_sec_context, except when the "gs2- nonstd-flag" is sent.

存在する場合oを初期コンテキストトークンヘッダは、（[RFC2743]のセクション3.1を参照）を除去しなければなりません。ヘッダが存在しない場合、クライアントは「GS2-NONSTDフラグ」フラグ（下記参照）を送信しなければなりません。サーバー側では、このヘッダが再計算および「gs2- NONSTDフラグ」が送信される場合を除いて、場合gss_accept_sec_contextにトークンを渡す前に復元しなければなりません。

o A GS2 header MUST be prefixed to the resulting initial context token. This header has the form "gs2-header" given below in ABNF [RFC5234].

O GS2ヘッダは、得られた初期コンテキストトークンの前に付けなければなりません。このヘッダは、ABNF [RFC5234]に下記の形態「GS2ヘッダ」を有します。

The figure below describes the permissible attributes, their use, and the format of their values. All attribute names are single US-ASCII letters and are case sensitive.

下の図は、許容属性、その使用、およびその値の形式について説明します。すべての属性名は、単一のUS-ASCII文字で、大文字と小文字が区別されます。

UTF8-1-safe = %x01-2B / %x2D-3C / %x3E-7F ;; As UTF8-1 in RFC 3629 except ;; NUL, "=", and ",". UTF8-2 = <as defined in RFC 3629 (STD 63)> UTF8-3 = <as defined in RFC 3629 (STD 63)> UTF8-4 = <as defined in RFC 3629 (STD 63)> UTF8-char-safe = UTF8-1-safe / UTF8-2 / UTF8-3 / UTF8-4

UTF8-1セーフ=％x01-2B /％x2D-3C /％Spark Proの-7F ;; UTF8-1としてRFC 3629を除いて;; NUL、 "="、および ""。 UTF8-2 = <RFC 3629で定義されている（STD 63）> UTF8-3 = <RFC 3629で定義されている（STD 63）> UTF8-4 = <RFC 3629で定義されている（STD 63）> UTF8-CHARセーフ= UTF8-1セーフ/ UTF8-2 / UTF8-3 / UTF8-4

saslname = 1*(UTF8-char-safe / "=2C" / "=3D") gs2-authzid = "a=" saslname ;; GS2 has to transport an authzid since ;; the GSS-API has no equivalent gs2-nonstd-flag = "F" ;; "F" means the mechanism is not a ;; standard GSS-API mechanism in that the ;; RFC 2743, Section 3.1 header was missing cb-name = 1*(ALPHA / DIGIT / "." / "-") ;; See RFC 5056, Section 7. gs2-cb-flag = ("p=" cb-name) / "n" / "y" ;; GS2 channel binding (CB) flag ;; "p" -> client supports and used CB ;; "n" -> client does not support CB ;; "y" -> client supports CB, thinks the server ;; does not gs2-header = [gs2-nonstd-flag ","] gs2-cb-flag "," [gs2-authzid] "," ;; The GS2 header is gs2-header.

saslname = 1 *（UTF8-CHARセーフ/ "= 2C" / "= 3D"）GS2-authzidは= "A =" saslname ;; GS2は、以来、authzidはを輸送する必要があります;; GSS-APIは同等GS2-NONSTDフラグ= "F" を有していない;; 「F」はメカニズムがないことを意味;; ;;という点で、標準のGSS-APIメカニズムRFC 2743、セクション3.1ヘッダ欠落したCB-NAME = 1 *（ALPHA / DIGIT / / "" " - "）;;参照RFC 5056、セクション7 GS2-CBフラグ=（ "P =" CB-名）/ "N" / "Y" ;; GS2チャネル結合（CB）フラグ;; "p" は - >クライアントがサポートしており、CBを使用;; "N" - >クライアントは、CBをサポートしていません;; "Y" - >クライアントがCBをサポートし、サーバーを考えて;;ないGS2ヘッダ= [GS2-NONSTDフラグ " "] GS2-CB-フラグ"、" [GS2-authzidは "" ;; GS2ヘッダはGS2ヘッダです。

When the "gs2-nonstd-flag" flag is present, the client did not find/ remove a token header ([RFC2743], Section 3.1) from the initial token returned by GSS_Init_sec_context. This signals to the server that it MUST NOT re-add the data that is normally removed by the client.

「GS2-NONSTDフラグ」フラグが存在する場合、クライアントは、もしGSS_Init_sec_contextによって返される最初のトークンからトークンヘッダ（[RFC2743]、セクション3.1）を削除/見つかりませんでした。これは、通常、クライアントによって削除されたデータを再度追加てはならないサーバに通知します。

The "gs2-cb-flag" signals the channel binding mode. One of "p", "n", or "y" is used. A "p" means the client supports and used a channel binding, and the name of the channel binding type is indicated. An "n" means that the client does not support channel binding. A "y" means the client supports channel binding, but believes the server does not support it, so it did not use a channel binding. See the next section for more details.

「GS2-CB-flagが」チャネルバインディングモードに信号を送ります。 "P"、 "N"、または "Y" のいずれかが使用されます。「p」は、クライアントがサポートしており、結合チャネルを使用し、チャネルバインディングタイプの名前が表示されることを意味します。「N」は、クライアントは結合チャネルをサポートしていないことを意味します。「Y」は、クライアントがチャネル結合をサポートしていますが、それが結合チャネルを使用していないので、サーバーは、それをサポートしていないと考えていることを意味します。詳細については、次のセクションを参照してください。

The "gs2-authzid" holds the SASL authorization identity. It is encoded using UTF-8 [RFC3629] with three exceptions:

「GS2-authzidはは、」SASL認証アイデンティティを保持しています。これは、3つの例外でUTF-8 [RFC3629]を使用してエンコードされます。

o The NUL character is forbidden as required by section 3.4.1 of [RFC4422].

[RFC4422]のセクション3.4.1で必要とされるO NUL文字は禁止されています。

o The server MUST replace any "," (comma) in the string with "=2C".

Oサーバはどのを交換しなければならない「」『= 2C』の文字列内の（カンマ）。

o The server MUST replace any "=" (equals) in the string with "=3D".

oをサーバが「= 3D」の文字列内の任意の「=」（等しい）を交換しなければなりません。

Upon receipt of this value, the server verifies its correctness according to the used SASL protocol profile. Failed verification results in a failed authentication exchange.

この値を受け取ると、サーバーは、使用SASLプロトコルプロファイルに従って、その正当性を検証します。失敗した認証交換に検証結果を失敗しました。

5. Channel Bindings

5.チャネルバインディング

GS2 supports channel binding to external secure channels, such as TLS. Clients and servers may or may not support channel binding; therefore, the use of channel binding is negotiable. However, GS2 does not provide security layers; therefore, it is imperative that GS2 provide integrity protection for the negotiation of channel binding.

GS2は、TLSなどの外部安全なチャンネルへの結合チャネルをサポートしています。クライアントとサーバーは、または結合チャネルをサポートしていない可能性があり、従って、結合チャネルの使用は交渉可能です。しかし、GS2は、セキュリティ層を提供していません。したがって、GS2が結合チャネルの交渉のための完全性の保護を提供することが不可欠です。

Use of channel binding is negotiated as follows:

次のように結合チャネルの使用が交渉されます。

o Servers that support the use of channel binding SHOULD advertise both the non-PLUS and PLUS-variant of each GS2 mechanism name. If the server cannot support channel binding, it SHOULD advertise only the non-PLUS-variant. If the server would never succeed in the authentication of the non-PLUS-variant due to policy reasons, it MUST advertise only the PLUS-variant.

O結合チャネルの使用をサポートするサーバーは、非PLUSおよび各GS2メカニズム名のPLUS-バリアントの両方を宣伝すべきです。サーバが結合チャネルをサポートできない場合は、それが唯一の非PLUS-バリアントを宣伝すべきです。サーバがポリシー上の理由による非PLUSバリアントの認証に成功したことがないならば、それだけPLUS-バリアントを宣伝しなければなりません。

o If the client supports channel binding and the server does not appear to (i.e., the client did not see the -PLUS name advertised by the server), then the client MUST NOT use an "n" gs2-cb-flag.

クライアントは、チャネル結合およびサーバーが表示されないサポートされている場合は、O（すなわち、クライアントがサーバによってアドバタイズ-Plus名を見ていない）、クライアントは「n」はGS2-CB-フラグを使用してはなりません。

o Clients that support mechanism negotiation and channel binding MUST use a "p" gs2-cb-flag when the server offers the PLUS-variant of the desired GS2 mechanism.

サーバが希望GS2機構のPLUS-バリアントを提供するとき、O結合機構交渉とチャネルをサポートするクライアントは、「P」GS2-CB-フラグを使用しなければなりません。

o If the client does not support channel binding, then it MUST use an "n" gs2-cb-flag. Conversely, if the client requires the use of channel binding then it MUST use a "p" gs2-cb-flag. Clients that do not support mechanism negotiation never use a "y" gs2-cb-flag, they use either "p" or "n" according to whether they require and support the use of channel binding or whether they do not, respectively.

クライアントは結合チャネルをサポートしていない場合は、O、それは「n」はGS2-CB-フラグを使用しなければなりません。逆に、クライアントはそれが「P」GS2-CB-フラグを使用しなければならない結合チャネルを使用する必要がある場合。メカニズム交渉は「Y」GS2-CB-フラグを使用することはありませんサポートしていないクライアントは、彼らが必要とし、彼らがいない、それぞれ行うかどうかの結合またはチャネルの使用をサポートしているかどうかに応じて、「P」または「N」のいずれかを使用します。

o The client generates the chan_bindings input parameter for GSS_Init_sec_context as described below.

以下に説明するようにOクライアントは、もしGSS_Init_sec_contextためchan_bindings入力パラメータを生成します。

o Upon receipt of the initial authentication message, the server checks the gs2-cb-flag in the GS2 header and constructs a chan_bindings parameter for GSS_Accept_sec_context as described below. If the client channel binding flag was "y" and the server did advertise support for channel bindings (by advertising the

O初期認証メッセージを受信すると、サーバは、GS2ヘッダ内GS2-CB-フラグをチェックし、以下に記載するように場合gss_accept_sec_contextためchan_bindingsパラメータを構成します。クライアントチャネルバインディングフラグが「Y」であったとした場合、サーバは、広告によって（チャネルバインディングをサポートすることを通知しました

PLUS-variant of the mechanism chosen by the client), then the server MUST fail authentication. If the client channel binding flag was "p" and the server does not support the indicated channel binding type, then the server MUST fail authentication.

クライアントによって選ばれたメカニズムのPLUS-バリアント）、サーバは、認証に失敗しなければなりません。クライアントチャネルバインディングフラグが「P」だったとサーバがバインディングタイプを示しチャンネルをサポートしていない場合、サーバーは認証が失敗しなければなりません。

o If the client used an "n" gs2-cb-flag and the server requires the use of channel binding, then the server MUST fail authentication.

クライアントは、「n」はGS2-CB-フラグを使用して、サーバが結合チャネルを使用する必要がある場合は、O、サーバは、認証に失敗しなければなりません。

     FLAG CLIENT CB SUPPORT   SERVER CB SUPPORT DISPOSITION
     ---- -----------------   ----------------- -----------

n no support N/A If server disallows non-channel-bound authentication, then fail

NはサポートしないN / Aサーバーに障害が発生し、その後、非チャネル結合認証を許可しない場合

y Yes, not required No Authentication may succeed; CB not used

Yはい、いいえ認証が成功しないことが必須ではありません。 CB使用されていません

y Yes, not required Yes Authentication must fail

Yはい、はい、認証が失敗しなければならない必要はありません

p Yes Yes Authentication may succeed, with CB used

Pはいはい認証が使用CBと、成功することができます

p Yes No Authentication will fail

Pはいいいえ認証が失敗します

N/A Yes, required No Client does not even try

N / Aはい、いいえクライアントを必要としないでもしようとしていません

For more discussion of channel bindings, and the syntax of the channel binding data for various security protocols, see [RFC5056].

より多くのチャネルバインディングの議論、およびさまざまなセキュリティプロトコルのためのデータを結合チャネルの構文については、[RFC5056]を参照してください。

5.1. Content of GSS-CHANNEL-BINDINGS Structure

5.1. GSS-CHANNEL-BINDINGS構造の内容

The calls to GSS_Init_sec_context and GSS_Accept_sec_context take a chan_bindings parameter. The value is a GSS-CHANNEL-BINDINGS structure [RFC5554].

もしGSS_Init_sec_contextとのgss_accept_sec_contextの呼び出しはchan_bindingsパラメータを取ります。値はGSS-CHANNELバインディング構造[RFC5554]です。

The initiator-address-type and acceptor-address-type fields of the GSS-CHANNEL-BINDINGS structure MUST be set to 0. The initiator-address and acceptor-address fields MUST be the empty string.

イニシエータアドレス型およびGSSチャネルバインディング構造のアクセプタアドレス・タイプ・フィールドは、開始アドレスとアクセプタアドレスフィールドが空の文字列である必要があり、0に設定しなければなりません。

The application-data field MUST be set to the gs2-header, excluding the initial [gs2-nonstd-flag ","] part, concatenated with, when a gs2-cb-flag of "p" is used, the application's channel binding data.

アプリケーション・データ・フィールドは、[「」GS2-NONSTDフラグ初期を除く、GS2ヘッダに設定しなければなりません『P』のGS2-CB-フラグが結合、アプリケーションのチャネルを使用されると連結部、データ。

5.2. Default Channel Binding

5.2. デフォルトのチャネルバインディング

A default channel binding type agreement process for all SASL application protocols that do not provide their own channel binding type agreement is provided as follows.

次のように自分のチャンネル結合型の契約を提供していないすべてのSASLのアプリケーションプロトコルのデフォルトチャネル結合型合意プロセスが提供されます。

'tls-unique' is the default channel binding type for any application that doesn't specify one.

「TLS-ユニーク」は1を指定していない任意のアプリケーションのデフォルトチャネルバインディングタイプです。

Servers MUST implement the "tls-unique" [RFC5929] channel binding type, if they implement any channel binding. Clients SHOULD implement the "tls-unique" channel binding type, if they implement any channel binding. Clients and servers SHOULD choose the highest-layer/innermost end-to-end TLS channel as the channel to which to bind.

彼らはバインディング任意のチャンネルを実装する場合、サーバーは、「TLS-ユニークな」[RFC5929]チャネル結合タイプを実装しなければなりません。彼らはバインディング任意のチャンネルを実装する場合、クライアントは、「TLS-ユニークな」チャネル結合タイプを実装する必要があります。クライアントとサーバーはバインドするためのチャネルとして最高層/最も内側のエンドツーエンドのTLSチャネルを選択する必要があります。

Servers MUST choose the channel binding type indicated by the client, or fail authentication if they don't support it.

サーバーは、クライアントによって示されたチャネルバインディングタイプを選択するか、彼らはそれをサポートしていない場合、認証に失敗しなければなりません。

6. Examples

6.例

Example #1: a one round-trip GSS-API context token exchange, no channel binding, optional authzid given.

例1：1往復GSS-APIコンテキストトークン交換、与えられていないチャネル結合、オプションauthzidは。

         C: Request authentication exchange
         S: Empty Challenge
         C: n,a=someuser,<initial context token with standard
                            header removed>
         S: Send reply context token as is
         C: Empty message
         S: Outcome of authentication exchange

Example #2: a one and one half round-trip GSS-API context token exchange, no channel binding.

例＃2：1と半分往復GSS-APIコンテキストトークン交換、ノーチャネル結合。

         C: Request authentication exchange
         S: Empty Challenge
         C: n,,<initial context token with standard
                            header removed>
         S: Send reply context token as is
         C: Send reply context token as is
         S: Outcome of authentication exchange

Example #3: a two round-trip GSS-API context token exchange, no channel binding, no standard token header.

例＃3：2往復GSS-APIのコンテキストトークン交換、結合無しチャンネル、標準的なトークンヘッダ。

         C: Request authentication exchange
         S: Empty Challenge
         C: F,n,,<initial context token without
                             standard header>
         S: Send reply context token as is
         C: Send reply context token as is
         S: Send reply context token as is
         C: Empty message
         S: Outcome of authentication exchange

Example #4: using channel binding, optional authzid given.

例4：結合チャネルを使用して、任意authzidは、与えられました。

         C: Request authentication exchange
         S: Empty Challenge
         C: p=tls-unique,a=someuser,<initial context token with standard
                                header removed>
         S: Send reply context token as is
         ...

Example #5: using channel binding.

例＃5：結合チャネルを使用。

         C: Request authentication exchange
         S: Empty Challenge
         C: p=tls-unique,,<initial context token with standard
                                header removed>
         S: Send reply context token as is
         ...

Example #6: using non-standard channel binding (requires out-of-band negotiation).

例＃6：結合非標準チャネルを使用しては、（アウトオブバンドネゴシエーションが必要）。

         C: Request authentication exchange
         S: Empty Challenge
         C: p=tls-server-end-point,,<initial context token with standard
                                header removed>
         S: Send reply context token as is
         ...

Example #7: client supports channel bindings but server does not, optional authzid given.

例＃7：クライアントは、チャネルバインディングをサポートしていますが、サーバーは、オプションのauthzidは、与えられたものではありません。

         C: Request authentication exchange
         S: Empty Challenge
         C: y,a=someuser,<initial
                           context token with standard header removed>
         S: Send reply context token as is
         ...

GSS-API authentication is always initiated by the client. The SASL framework allows either the client or the server to initiate authentication. In GS2, the server will send an initial empty challenge (zero-byte string) if it has not yet received a token from the client. See Section 3 of [RFC4422].

GSS-API認証は、常にクライアントによって開始されます。 SASLフレームワークは、クライアントまたはサーバが認証を開始することができます。それはまだ、クライアントからのトークンを受信していない場合GS2では、サーバーは、最初の空のチャレンジ（0バイトの文字列）を送信します。 [RFC4422]のセクション3を参照してください。

7. Authentication Conditions

7.認証条件

Authentication MUST NOT succeed if any one of the following conditions are true:

次の条件のいずれかに該当する場合、認証は成功しないでください。

o If GSS_Init/Accept_sec_context returns anything other than GSS_S_CONTINUE_NEEDED or GSS_S_COMPLETE.

O GSS_Init / Accept_sec_contextはGSS_S_CONTINUE_NEEDEDかGSS_S_COMPLETE以外のものを返した場合。

o If the client's initial GS2 header does not match the ABNF.

Oクライアントの初期GS2ヘッダーはABNFと一致しない場合。

o In particular, if the initial character of the client message is anything except "F", "p", "n", or "y".

O具体的には、クライアント・メッセージの最初の文字が「F」、「P」、「N」、または「Y」以外のものである場合。

o If the client's GS2 channel binding flag was "y" and the server supports channel bindings.

OクライアントのGS2チャネルバインディングフラグが「Y」であったとサーバがチャネルバインディングをサポートしている場合。

o If the client's GS2 channel binding flag was "p" and the server does not support the indicated channel binding.

OクライアントのGS2チャネルバインディングフラグが「P」であったとサーバがバインド示されたチャネルをサポートしていない場合。

o If the client requires use of channel binding and the server did not advertise support for channel binding.

Oクライアントは、結合チャネルを使用する必要があり、サーバがチャネルバインディングをサポートすることを通知しなかった場合。

o If authorization of client principal (i.e., src_name in GSS_Accept_sec_context) to requested authzid failed.

Oクライアント校長の許可が（すなわち、場合gss_accept_sec_contextでsrc_name）要求されたauthzidはするが失敗した場合。

o If the client is not authorized to the requested authzid or an authzid could not be derived from the client's initiator principal name.

クライアントが要求authzidはまたはauthzidはに許可されていない場合は、O、クライアントのイニシエータプリンシパル名から導出することができませんでした。

8. GSS-API Parameters

8. GSS-APIのパラメータ

GS2 does not use any GSS-API per-message tokens. Therefore, the per-message token ret_flags from GSS_Init_sec_context() and GSS_Accept_sec_context() are irrelevant; implementations SHOULD NOT set the per-message req_flags.

GS2は、任意のGSS-APIメッセージごとのトークンを使用しません。したがって、もしGSS_Init_sec_context（）及び場合gss_accept_sec_context（）のメッセージごとのトークンのret_flagsは無関係です。実装は、メッセージごとのreq_flagsを使用を設定しないでください。

The mutual_req_flag MUST be set. Clients MUST check that the corresponding ret_flag is set when the context is fully established, else authentication MUST fail.

mutual_req_flagを設定しなければなりません。クライアントは、対応するret_flagは、コンテキストが完全に確立されたときに、それ以外の認証が失敗しなければなりません設定されていることをチェックしなければなりません。

Use or non-use of deleg_req_flag and anon_req_flag is an implementation-specific detail. SASL and GS2 implementors are encouraged to provide programming interfaces by which clients may choose to delegate credentials and by which servers may receive them. SASL and GS2 implementors are encouraged to provide programming interfaces that provide a good mapping of GSS-API naming options.

使用するか、deleg_req_flagとanon_req_flagの不使用は、実装固有の詳細です。 SASLとGS2実装は、クライアントはサーバがそれらを受けることができる資格情報とによりを委任することを選択する可能性があることで、プログラミングインタフェースを提供することが奨励されています。 SASLとGS2実装は、GSS-APIの命名オプションの良いマッピングを提供するプログラミング・インターフェースを提供することが奨励されています。

9. Naming

9.命名

There is no requirement that any particular GSS-API name-types be used. However, typically, SASL servers will have host-based acceptor principal names (see [RFC2743], Section 4.1) and clients will typically have username initiator principal names (see [RFC2743], Section 4.2). When a host-based acceptor principal name is used ("service@hostname"), "service" is the service name specified in the protocol's profile and "hostname" is the fully qualified host name of the server.

いずれかの特定のGSS-API名-タイプは使用する必要はありません。しかし、一般的に、SASLサーバーは、ホストベースのアクセプタプリンシパル名を持つことになります（[RFC2743]セクション4.1を参照）、クライアントは通常、ユーザ名がプリンシパル名をイニシエータています（[RFC2743]のセクション4.2を参照してください）。ホストベースのアクセプタプリンシパル名が使用されている（「サービス@ホスト名」）、「サービス」は、プロトコルのプロファイルに指定されたサービス名で、「ホスト名は、」サーバーの完全修飾ホスト名です。

10. GSS_Inquire_SASLname_for_mech Call

10. GSS_Inquire_SASLname_for_mechコール

We specify a new GSS-API utility function to allow SASL implementations to more efficiently identify the GSS-API mechanism to which a particular SASL mechanism name refers.

私たちは、SASLの実装がより効率的に、特定のSASL機構名が参照するGSS-APIメカニズムを識別できるようにするために、新しいGSS-APIユーティリティ関数を指定します。

Inputs:

入力：

o desired_mech OBJECT IDENTIFIER

O desired_mechオブジェクト識別子

Outputs:

出力：

o major_status INTEGER

O major_status INTEGER

o minor_status INTEGER

minor_status INTEGER O

o sasl_mech_name UTF-8 STRING -- SASL name for this mechanism; caller must release with GSS_Release_buffer()

Oのsasl_mech_name UTF-8文字列 - このメカニズムのSASL名。呼び出し側は（GSS_Release_bufferを解放しなければなりません）

o mech_name UTF-8 STRING -- name of this mechanism, possibly localized; caller must release with GSS_Release_buffer()

O mech_name UTF-8文字列 - このメカニズムの名前は、おそらく局在します。呼び出し側は（GSS_Release_bufferを解放しなければなりません）

o mech_description UTF-8 STRING -- possibly localized description of this mechanism; caller must release with GSS_Release_buffer()

O mech_description UTF-8文字列 - このメカニズムの可能性のローカライズされた説明。呼び出し側は（GSS_Release_bufferを解放しなければなりません）

Return major_status codes:

major_status戻りコード：

o GSS_S_COMPLETE indicates successful completion, and that output parameters holds correct information.

O GSS_S_COMPLETEは正常に完了したことを示し、その出力パラメータは、正しい情報を保持します。

o GSS_S_BAD_MECH indicates that a desired_mech was unsupported by the GSS-API implementation.

O GSS_S_BAD_MECHはdesired_mechは、GSS-APIの実装によってサポートされていないことを示しました。

o GSS_S_FAILURE indicates that the operation failed for reasons unspecified at the GSS-API level.

O GSS_S_FAILUREは、操作がGSS-APIレベルで不特定の理由で失敗したことを示しています。

The GSS_Inquire_SASLname_for_mech call is used to get the SASL mechanism name for a GSS-API mechanism. It also returns a name and description of the mechanism in user-friendly form.

GSS_Inquire_SASLname_for_mechコールはGSS-APIメカニズムのSASLメカニズム名を取得するために使用されます。また、ユーザーフレンドリーな形でメカニズムの名前と説明を返します。

The output variable sasl_mech_name will hold the IANA registered mechanism name for the GSS-API mechanism, or if none is registered, a mechanism name computed from the OID as described in Section 3.1 of this document.

出力変数sasl_mech_nameはGSS-API機構のためにIANA登録された機構名を保持する、または何も登録されていない場合は、この文書のセクション3.1に記載されているように、機構名がOIDから計算します。

10.1. gss_inquire_saslname_for_mech

The C binding for the GSS_Inquire_SASLname_for_mech call is as follows.

次のようにGSS_Inquire_SASLname_for_mech呼び出しのバインディングCです。

As mentioned in [RFC2744], routines may return GSS_S_FAILURE, indicating an implementation-specific or mechanism-specific error condition, further details of which are reported via the minor_status parameter.

[RFC2744]で述べたように、ルーチンは、実装固有または機構固有のエラー状態を示す、GSS_S_FAILUREを返すことができる、のさらなる詳細は、minor_statusパラメータを介して報告されます。

OM_uint32 gss_inquire_saslname_for_mech( OM_uint32 *minor_status, const gss_OID desired_mech, gss_buffer_t sasl_mech_name, gss_buffer_t mech_name, gss_buffer_t mech_description );

OM_uint32と同じgss_inquire_saslname_for_mech（OM_uint32と同じ* minor_status、CONST次に、gss_OID desired_mech、gss_buffer_t sasl_mech_name、gss_buffer_t mech_name、gss_buffer_t mech_description）。

Purpose:

目的：

Output the SASL mechanism name of a GSS-API mechanism. It also returns a name and description of the mechanism in a user-friendly form.

出力GSS-APIメカニズムのSASL機構名。また、ユーザーフレンドリーな形でメカニズムの名前と説明を返します。

Parameters:

パラメーター：

minor_status Integer, modify Mechanism-specific status code.

minor_status整数は、機構固有のステータスコードを変更します。

desired_mech OID, read Identifies the GSS-API mechanism to query.

desired_mech OIDは、識別に照会するGSS-APIメカニズムをお読みください。

sasl_mech_name buffer, character-string, modify, optional Buffer to receive SASL mechanism name. The application must free storage associated with this name after use with a call to gss_release_buffer().

sasl_mech_nameバッファ、文字列、修正、SASLメカニズム名を受信するために、オプションのバッファー。アプリケーションはgss_release_bufferを呼び出して使用した後、この名前に関連付けられたストレージを解放しなければなりません（）。

mech_name buffer, character-string, modify, optional Buffer to receive human-readable mechanism name. The application must free storage associated with this name after use with a call to gss_release_buffer().

mech_nameバッファは、文字列、人間が読み取り可能なメカニズムの名前を受け取るために、オプションのバッファを変更します。アプリケーションはgss_release_bufferを呼び出して使用した後、この名前に関連付けられたストレージを解放しなければなりません（）。

mech_description buffer, character-string, modify, optional Buffer to receive description of mechanism. The application must free storage associated with this name after use with a call to gss_release_buffer().

mech_descriptionバッファ、文字列、変更し、任意のバッファ機構の記述を受信します。アプリケーションはgss_release_bufferを呼び出して使用した後、この名前に関連付けられたストレージを解放しなければなりません（）。

Function value: GSS status code:

関数値：GSSステータス・コード：

GSS_S_COMPLETE Successful completion.

GSS_S_COMPLETE成功した完了。

GSS_S_BAD_MECH The desired_mech OID is unsupported.

OIDがサポートされていないdesired_mechをGSS_S_BAD_MECH。

11. GSS_Inquire_mech_for_SASLname Call

11. GSS_Inquire_mech_for_SASLnameコール

To allow SASL clients to more efficiently identify to which GSS-API mechanism a particular SASL mechanism name refers, we specify a new GSS-API utility function for this purpose.

SASLクライアントがより効率的に、特定のSASL機構名が参照するGSS-APIメカニズムに識別できるようにするために、我々は、この目的のために新しいGSS-APIユーティリティ関数を指定します。

Inputs:

入力：

o sasl_mech_name UTF-8 STRING -- SASL name of mechanism.

O sasl_mech_name UTF-8文字列 - メカニズムのSASL名。

Outputs:

出力：

o major_status INTEGER

O major_status INTEGER

o minor_status INTEGER

minor_status INTEGER O

o mech_type OBJECT IDENTIFIER -- must be explicit mechanism, and not "default" specifier. Caller should treat as read-only and should not attempt to release.

Oたmech_typeオブジェクト識別子は - 明示的なメカニズムではなく、「デフォルト」指定子でなければなりません。発信者は、読み取り専用として扱うべきであると解放するために試みるべきではありません。

Return major_status codes:

major_status戻りコード：

o GSS_S_COMPLETE indicates successful completion, and that output parameters holds correct information.

O GSS_S_COMPLETEは正常に完了したことを示し、その出力パラメータは、正しい情報を保持します。

o GSS_S_BAD_MECH indicates that no supported GSS-API mechanism had the indicated sasl_mech_name.

O GSS_S_BAD_MECHには、サポートGSS-APIメカニズムは、指示されたsasl_mech_nameがなかったことを示しています。

o GSS_S_FAILURE indicates that the operation failed for reasons unspecified at the GSS-API level.

O GSS_S_FAILUREは、操作がGSS-APIレベルで不特定の理由で失敗したことを示しています。

The GSS_Inquire_mech_for_SASLname call is used to get the GSS-API mechanism OID associated with a SASL mechanism name.

GSS_Inquire_mech_for_SASLnameコールはSASLメカニズム名に関連付けられているGSS-API機構OIDを取得するために使用されます。

11.1. gss_inquire_mech_for_saslname

The C binding for the GSS_Inquire_mech_for_SASLname call is as follows.

次のようにGSS_Inquire_mech_for_SASLname呼び出しのバインディングCです。

OM_uint32 gss_inquire_mech_for_saslname( OM_uint32 *minor_status, const gss_buffer_t sasl_mech_name, gss_OID *mech_type );

OM_uint32と同じgss_inquire_mech_for_saslname（OM_uint32と同じ* minor_status、constのgss_buffer_tのsasl_mech_name、次に、gss_OID *のメカニズム種別）;

Purpose:

目的：

Output GSS-API mechanism OID of mechanism associated with given sasl_mech_name.

与えられたsasl_mech_nameに関連した機構の出力GSS-APIメカニズムOID。

Parameters:

パラメーター：

minor_status Integer, modify Mechanism-specific status code.

minor_status整数は、機構固有のステータスコードを変更します。

sasl_mech_name buffer, character-string, read Buffer with SASL mechanism name.

sasl_mech_nameバッファ、文字列は、SASLメカニズム名でバッファを読んで。

mech_type OID, modify, optional Actual mechanism used. The OID returned via this parameter will be a pointer to static storage that should be treated as read-only. In particular, the application should not attempt to free it. Specify NULL if not required.

たmech_type OIDは、使用されるオプションの実際のメカニズムを変更します。 OIDは、読み取り専用として扱われるべきであるスタティックストレージへのポインタになり、このパラメータを介して返されます。特に、アプリケーションがそれを解放するために試みるべきではありません。必要でない場合は、NULLを指定します。

Function value: GSS status code:

関数値：GSSステータス・コード：

GSS_S_COMPLETE Successful completion.

GSS_S_COMPLETE成功した完了。

GSS_S_BAD_MECH There is no GSS-API mechanism known as sasl_mech_name.

GSS_S_BAD_MECH sasl_mech_nameとして知られているいかなるGSS-APIメカニズムはありません。

12. Security Layers

12.セキュリティ層

GS2 does not support SASL security layers. Applications that need integrity or confidentiality protection can use either channel binding to a secure external channel or another SASL mechanism that does provide security layers.

GS2は、SASLのセキュリティレイヤをサポートしていません。整合性や機密性の保護を必要とするアプリケーションは、安全性の高い外部チャネルへの結合チャネルまたはセキュリティ層を提供し、別のSASLメカニズムのいずれかを使用することができます。

13. Interoperability with the SASL GSSAPI Mechanism

SASL GSSAPIメカニズムを持つ13の相互運用性

The Kerberos V5 GSS-API [RFC1964] mechanism is currently used in SASL under the name GSSAPI, see [RFC4752]. The Kerberos V5 mechanism may also be used with the GS2 family. This causes an interoperability problem, which is discussed and resolved below.

ケルベロスV5 GSSAPI [RFC1964]メカニズムは、現在の名前の下にGSSAPI SASLで使用され、[RFC4752]を参照。ケルベロスV5機構はまた、GS2の家族と一緒に使用することができます。これは議論され、以下の解決された相互運用性の問題を引き起こします。

13.1. The Interoperability Problem

13.1. 相互運用性の問題

The SASL "GSSAPI" mechanism is not wire compatible with the Kerberos V GSS-API mechanism used as a SASL GS2 mechanism.

SASL「GSSAPI」機構は、SASL GS2メカニズムとして使用ケルベロスV GSSAPIメカニズムと互換性のワイヤではありません。

If a client (or server) only support Kerberos V5 under the "GSSAPI" name, and the server (or client) only support Kerberos V5 under the GS2 family, the mechanism negotiation will fail.

クライアント（またはサーバ）のみだけGS2ファミリーの下にKerberos V5をサポートする「GSSAPI」名、およびサーバ（またはクライアント）の下でのKerberos V5をサポートしている場合、機構交渉は失敗します。

13.2. Resolving the Problem

13.2. 問題の解決

If the Kerberos V5 mechanism is supported under GS2 in a server, the server SHOULD also support Kerberos V5 through the "GSSAPI" mechanism, to avoid interoperability problems with older clients.

ケルベロスV5機構は、サーバーにGS2でサポートされている場合は、サーバーは、以前のバージョンのクライアントとの相互運用性の問題を回避するために、「GSSAPI」メカニズムを介してのKerberos V5をサポートする必要があります。

Reasons for violating this recommendation may include security considerations regarding the absent features in the GS2 mechanism. The SASL "GSSAPI" mechanism lacks support for channel bindings, which means that using an external secure channel may not be sufficient protection against active attackers (see [RFC5056] and [MITM]).

この勧告に違反する理由は、GS2のメカニズムには存在しない機能に関するセキュリティ上の考慮事項を含むことができます。 SASL「GSSAPI」機構は、外部セキュアチャネルを使用してアクティブ攻撃者に対して十分な保護ではないかもしれないことを意味し、チャネルバインディングのサポートを欠いている（[RFC5056]と[MITM]参照）。

13.3. Additional Recommendations

13.3. 追加の推奨事項

If the application requires SASL security layers, then it MUST use the SASL "GSSAPI" mechanism [RFC4752] instead of "GS2-KRB5" or "GS2- KRB5-PLUS".

アプリケーションがSASLセキュリティ層を必要とする場合、それは代わりに「GS2-KRB5」または「GS2- KRB5-PLUS」のSASL「GSSAPI」メカニズム[RFC4752]を使用しなければなりません。

If the application can use channel binding to an external channel, then it is RECOMMENDED that it select Kerberos V5 through the GS2 mechanism rather than the "GSSAPI" mechanism.

アプリケーションが外部チャネルへの結合チャネルを使用することができる場合、それがGS2機構よりもむしろ「GSSAPI」機構を介してケルベロスV5を選択することをお勧めします。

14. GSS-API Mechanisms That Negotiate Other Mechanisms

他のメカニズムをネゴシエート14. GSS-APIメカニズム

A GSS-API mechanism that negotiates other mechanisms will interact badly with the SASL mechanism negotiation. There are two problems. The first is an interoperability problem and the second is a security concern. The problems are described and resolved below.

他のメカニズムを交渉するGSS-APIメカニズムは、SASLメカニズムの交渉でひどく相互に作用します。 2つの問題があります。最初は、相互運用性の問題であり、第二には、セキュリティ上の問題です。問題は、以下に記載し、解決されます。

14.1. The Interoperability Problem

14.1. 相互運用性の問題

If a client implements GSS-API mechanism X, potentially negotiated through a GSS-API mechanism Y, and the server also implements GSS-API mechanism X negotiated through a GSS-API mechanism Z, the authentication negotiation will fail.

クライアントは、GSS-API機構Xを実装する場合、潜在的にGSS-APIメカニズムYを通じて交渉され、サーバはまた、Xは、GSS-API機構Zを通じて交渉さGSS-APIメカニズムを実装し、認証のネゴシエーションが失敗します。

14.2. Security Problem

14.2. セキュリティ問題

If a client's policy is to first prefer GSSAPI mechanism X, then non-GSSAPI mechanism Y, then GSSAPI mechanism Z, and if a server supports mechanisms Y and Z but not X, then if the client attempts to negotiate mechanism X by using a GSS-API mechanism that negotiates other mechanisms (such as Simple and Protected GSS-API Negotiation (SPNEGO) [RFC4178]), it may end up using mechanism Z when it ideally should have used mechanism Y. For this reason, the use of GSS-API mechanisms that negotiate other mechanisms is disallowed under GS2.

クライアントのポリシーでは、最初のGSSAPI機構Xを好むのであれば、その後、非GSSAPIメカニズムY、その後、GSSAPI機構Z、およびサーバがメカニズムYとZではなくXをサポートしている場合、クライアントはGSSを使用することにより、機構Xを交渉しようとした場合他の機構をネゴシエート-API機構（例えば単純で保護GSS-APIネゴシエーション（SPNEGO）として[RFC4178]）、それは理想的には、このためGSS-を使用する機構Yを使用していなければならない機構Zを使用して終了してもよいです他のメカニズムを交渉APIメカニズムは、GS2の下で許可されていません。

14.3. Resolving the Problems

14.3. 問題の解決

GSS-API mechanisms that negotiate other mechanisms MUST NOT be used with the GS2 SASL mechanism. Specifically, SPNEGO [RFC4178] MUST NOT be used as a GS2 mechanism. To make this easier for SASL implementations, we assign a symbolic SASL mechanism name to the SPNEGO GSS-API mechanism, "SPNEGO". SASL client implementations MUST NOT choose the SPNEGO mechanism under any circumstances.

他のメカニズムを交渉GSS-APIメカニズムは、GS2 SASL機構を使用してはいけません。具体的には、SPNEGO [RFC4178]はGS2機構として使用してはいけません。 SASLの実装のため、これは簡単にするために、我々は、SPNEGO GSS-API機構に「SPNEGO」を象徴SASLメカニズム名を割り当てます。 SASLクライアントの実装では、どのような状況の下でSPNEGOメカニズムを選択してはなりません。

The GSS_C_MA_MECH_NEGO attribute of GSS_Inquire_attrs_for_mech [RFC5587] can be used to identify such mechanisms.

GSS_Inquire_attrs_for_mech [RFC5587]のGSS_C_MA_MECH_NEGO属性は、そのようなメカニズムを同定するために用いることができます。

15. IANA Considerations

15. IANAの考慮事項

The IANA has registered a SASL mechanism family as per [RFC4422] using the following information.

IANAは、次の情報を使用して、[RFC4422]に従ってSASL機構ファミリーを登録しました。

Subject: Registration of SASL mechanism family GS2-* SASL mechanism prefix: GS2- Security considerations: RFC 5801 Published specification: RFC 5801 Person & email address to contact for further information: Simon Josefsson <simon@josefsson.org> Intended usage: COMMON Owner/Change controller: iesg@ietf.org Note: Compare with the GSSAPI and GSS-SPNEGO mechanisms.

件名：SASLメカニズムファミリGS2- * SASLメカニズムの接頭辞の登録：GS2-セキュリティに関する考慮事項：RFC 5801公開仕様：RFC 5801人とEメールアドレス詳細についての問い合わせ先：Simon Josefsson氏の<simon@josefsson.org>意図している用法：COMMON所有者/変更コントローラ：iesg@ietf.org注：GSSAPIとGSS-SPNEGOメカニズムと比較してください。

The IANA is advised that SASL mechanism names starting with "GS2-" are reserved for SASL mechanisms that conform to this document. The IANA has placed a statement to that effect in the SASL Mechanisms registry.

IANAは「GS2-」で始まるSASLメカニズムの名前は、この文書に準拠するSASLメカニズムのために予約されていることをお勧めします。 IANAはSASLメカニズムのレジストリにその旨の声明を置いています。

The IANA is further advised that GS2 SASL mechanism names MUST NOT end in "-PLUS" except as a version of another mechanism name simply suffixed with "-PLUS".

IANAはさらにGS2 SASLメカニズム名は単に「-Plus」接尾辞別のメカニズム名のバージョンなどを除き「-Plus」で終わっていなければならないことをお勧めします。

The SASL names for the Kerberos V5 GSS-API mechanism [RFC4121] [RFC1964] used via GS2 SHALL be "GS2-KRB5" and "GS2-KRB5-PLUS".

GS2を介して使用されるKerberos V5 GSS-APIメカニズム[RFC4121]、[RFC1964]のためのSASL名は "GS2-KRB5" と "GS2-KRB5-PLUS" でなければなりません。

The SASL names for the SPNEGO GSS-API mechanism used via GS2 SHALL be "SPNEGO" and "SPNEGO-PLUS". As described in Section 14, the SASL "SPNEGO" and "SPNEGO-PLUS" MUST NOT be used. These names are provided as a convenience for SASL library implementors.

GS2経由で使用SPNEGO GSS-APIメカニズムのSASL名は "SPNEGO" と "SPNEGO-PLUS" ものでなければなりません。第14章で説明したように、SASL「SPNEGO」と「SPNEGO-PLUSは、」使用してはいけません。これらの名前は、SASLライブラリの実装のための便宜のために提供されています。

16. Security Considerations

16.セキュリティの考慮事項

Security issues are also discussed throughout this memo.

セキュリティの問題も、このメモ中で議論されています。

The security provided by a GS2 mechanism depends on the security of the GSS-API mechanism. The GS2 mechanism family depends on channel binding support, so GSS-API mechanisms that do not support channel binding cannot be successfully used as SASL mechanisms via the GS2 bridge.

GS2メカニズムによって提供されるセキュリティは、GSS-API機構のセキュリティに依存します。結合チャネルをサポートしていないGSS-APIメカニズムが正常GS2橋を介してSASLメカニズムとして使用することはできませんので、GS2機構ファミリは、チャネルバインディングのサポートに依存します。

Because GS2 does not support security layers, it is strongly RECOMMENDED that channel binding to a secure external channel be used. Successful channel binding eliminates the possibility of man-in-the-middle (MITM) attacks, provided that the external channel and its channel binding data are secure and that the GSS-API mechanism used is secure. Authentication failure because of channel binding failure may indicate that an MITM attack was attempted, but note that a real MITM attacker would likely attempt to close the connection to the client or simulate network partition; thus, MITM attack detection is heuristic.

GS2がセキュリティレイヤをサポートしていないので、強く、安全な外部チャネルへの結合チャネルを使用することをお勧めします。成功したチャネル結合はのman-in-the-middle（MITM）攻撃の可能性を排除し、外部チャネルとそのチャネルバインディングデータが安全であると使用GSS-APIメカニズムが安全であることをことを提供します。なぜなら、チャネル結合の障害の認証失敗はMITM攻撃が試みられたことを示しているが、実際のMITM攻撃者の可能性が高いクライアントへの接続を閉じるか、ネットワークパーティションをシミュレートしようとするだろうと気づくかもしれません。このように、MITM攻撃の検出は、ヒューリスティックです。

Use of channel binding will also protect the SASL mechanism negotiation -- if there is no MITM, then the external secure channel will have protected the SASL mechanism negotiation.

結合チャネルの使用は、SASLメカニズムの交渉を保護します - 何MITMが存在しない場合は、外部のセキュリティ保護されたチャネルは、SASLメカニズムのネゴシエーションを保護しています。

The channel binding data MAY be sent (by the actual GSS-API mechanism used) without confidentiality protection and knowledge of it is assumed to provide no advantage to an MITM (who can, in any case, compute the channel binding data independently). If the external channel does not provide confidentiality protection and the GSS-API mechanism does not provide confidentiality protection for the channel binding data, then passive attackers (eavesdroppers) can recover the channel binding data, see [RFC5056].

結合データチャネルは、機密保護なし（使用される実際のGSS-API機構によって）送信されてもよく、それの知識は（いずれの場合も、チャネル結合データ独立を計算することができる）MITMに何の利点を提供しないものとします。外部チャネルが機密性保護を提供しないと、GSS-APIメカニズムがチャネルバインディングデータの機密保護を提供しない場合、受動的攻撃（盗聴者）は、チャネルバインディングデータを回復することができます[RFC5056]を参照してください。

When constructing the input_name_string for GSS_Import_name with the GSS_C_NT_HOSTBASED_SERVICE name type, the client SHOULD NOT canonicalize the server's fully qualified domain name using an insecure or untrusted directory service, such as the Domain Name System [RFC1034] without DNS Security (DNSSEC) [RFC4033].

GSS_C_NT_HOSTBASED_SERVICE名のタイプを持つGSS_Import_nameためinput_name_stringを構築する場合、クライアントは、DNSのセキュリティなしのドメインネームシステム[RFC1034]（DNSSEC）[RFC4033]のように安全ではないか、信頼できないディレクトリサービスを使用して、サーバーの完全修飾ドメイン名を正規化すべきではありません。

SHA-1 is used to derive SASL mechanism names, but no traditional cryptographic properties are required -- the required property is that the truncated output for distinct inputs are different for practical input values. GS2 does not use any other cryptographic algorithm. Therefore, GS2 is "algorithm agile", or, as agile as the GSS-API mechanisms that are available for use in SASL applications via GS2.

SHA-1は、SASL機構名を導出するために使用されるが、いかなる従来の暗号化特性が必要とされない - 必要性は、異なる入力の切り捨て出力は、実用的な入力値に対して異なっていることです。 GS2は、他の暗号アルゴリズムを使用していません。したがって、GS2は、GS2を介してSASL用途での使用のために利用可能であるGSS-APIメカニズムほどアジャイル「アジャイルアルゴリズム」である、または。

GS2 does not protect against downgrade attacks of channel binding types. Negotiation of channel binding type was intentionally left out of scope for this document.

GS2は、チャネル結合タイプのダウングレード攻撃から保護することはできません。チャネル結合タイプの交渉は、意図的にこのドキュメントのための範囲の外に残っていました。

The security considerations of SASL [RFC4422], the GSS-API [RFC2743], channel binding [RFC5056], any external channels (such as TLS, [RFC5246], channel binding types (see the IANA channel binding type registry), and GSS-API mechanisms (such as the Kerberos V5 mechanism [RFC4121] [RFC1964]), also apply.

SASL [RFC4422]のセキュリティ問題は、GSS-API [RFC2743]、チャネル結合[RFC5056]、TLSなどの任意の外部チャネル（[RFC5246]は、チャネル結合型（）タイプレジストリを結合IANAチャンネルを見て、GSS （例えば、ケルベロスV5機構[RFC4121]、[RFC1964]など）-API機構も当てはまります。

17. Acknowledgements

17.謝辞

The history of GS2 can be traced to the "GSSAPI" mechanism originally specified by RFC 2222. This document was derived from [SASL-GSSAPI], which was prepared by Alexey Melnikov with significant contributions from John G. Myers, although the majority of this document has been rewritten by the current authors.

GS2の歴史は、このの大部分が、もともとこの文書は、ジョンG.マイヤーズから重要な貢献とアレクセイメルニコフすることによって調製したSASL-GSSAPI]、から誘導されたRFC 2222で指定された「GSSAPI」機構に追跡することができます文書は、現在の著者によって書き直されました。

Contributions of many members of the SASL mailing list are gratefully acknowledged. In particular, ideas and feedback from Pasi Eronen, Sam Hartman, Jeffrey Hutzelman, Alexey Melnikov, and Tom Yu improved the document and the protocol. Other suggestions to the documents were made by Spencer Dawkins, Ralph Droms, Adrian Farrel, Robert Sparks, and Glen Zorn.

SASLメーリングリストの多くのメンバーの貢献は深く感謝しています。特に、パシEronen、サム・ハートマン、ジェフリーHutzelman、アレクセイ・メルニコフ、そしてトム・ゆうからアイデアやフィードバックは、ドキュメントやプロトコルを改善しました。ドキュメントへの他の提案はスペンサードーキンスラルフDroms、エードリアンファレル、ロバートスパークス、およびグレンツォルンによって作られました。

18. References

18.参考文献

18.1. Normative References

18.1. 引用規格

[FIPS.180-1.1995] National Institute of Standards and Technology, "Secure Hash Standard", FIPS PUB 180-1, April 1995, <http://www.itl.nist.gov/fipspubs/fip180-1.htm>.

[FIPS.180-1.1995]アメリカ国立標準技術研究所、 "セキュアハッシュ標準"、FIPS PUB 180-1の、1995年4月、<http://www.itl.nist.gov/fipspubs/fip180-1.htm> 。

[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月。

[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.

[RFC3629] Yergeau、F.、 "UTF-8、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。

[RFC4422] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.

[RFC4422]メルニコフ、A.およびK. Zeilenga、 "簡易認証セキュリティー層（SASL）"、RFC 4422、2006年6月。

[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.

[RFC4648] Josefsson氏、S.、 "Base16、Base32、およびBase64でデータエンコーディング"、RFC 4648、2006年10月。

[RFC5056] Williams, N., "On the Use of Channel Bindings to Secure Channels", RFC 5056, November 2007.

"チャネルを確保するチャネルバインディングの使用について" [RFC5056]ウィリアムズ、N.、RFC 5056、2007年11月。

[RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008.

[RFC5234]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、STD 68、RFC 5234、2008年1月。

[RFC5554] Williams, N., "Clarifications and Extensions to the Generic Security Service Application Program Interface (GSS-API) for the Use of Channel Bindings", RFC 5554, May 2009.

[RFC5554]ウィリアムズ、N.、RFC 5554、2009年05月05日「チャネルバインディングの使用のための一般的なセキュリティサービスアプリケーションプログラムインタフェース（GSS-API）への明確化と拡大」。

[CCITT.X690.2002] International Telephone and Telegraph Consultative Committee, "ASN.1 encoding rules: Specification of basic encoding Rules (BER), Canonical encoding rules (CER) and Distinguished encoding rules (DER)", CCITT Recommendation X.690, July 2002.

[CCITT.X690.2002]国際電信電話諮問委員会、「ASN.1エンコーディング規則：基本的な符号化規則（BER）、Canonicalの符号化規則（CER）との識別符号化規則（DER）の仕様」、CCITT勧告X.690 、2002年7月。

[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings for TLS", RFC 5929, July 2010.

[RFC5929]アルトマン、J.、ウィリアムズ、N.、およびL.朱、 "TLSのチャネルバインディング"、RFC 5929、2010年7月。

18.2. Informative References

18.2. 参考文献

[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.

[RFC1034] Mockapetris、P.、 "ドメイン名 - 概念と設備"、STD 13、RFC 1034、1987年11月。

[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.

[RFC1964]リン、J.、 "Kerberosバージョン5 GSS-APIメカニズム"、RFC 1964、1996年6月。

[RFC2025] Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC 2025, October 1996.

[RFC2025]アダムス、C.、 "単純な公開鍵GSS-APIメカニズム（SPKM）"、RFC 2025、1996年10月。

[RFC2222] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.

[RFC2222]マイヤーズ、J.、 "簡易認証セキュリティー層（SASL）"、RFC 2222、1997年10月。

[RFC2744] Wray, J., "Generic Security Service API Version 2 : C-bindings", RFC 2744, January 2000.

[RFC2744]レイ、J.、 "ジェネリックセキュリティサービスAPIバージョン2：C-バインディング"、RFC 2744、2000年1月。

[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.

[RFC4033]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "DNSセキュリティ序論と要件"、RFC 4033、2005年3月。

[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月。

[RFC4178] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism", RFC 4178, October 2005.

[RFC4178]朱、L.、リーチ、P.、Jaganathan、K.、およびW.インガーソル、 "単純で保護された一般的なセキュリティサービスアプリケーションプログラムインタフェース（GSS-API）交渉メカニズム"、RFC 4178、2005年10月。

[RFC4752] Melnikov, A., "The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism", RFC 4752, November 2006.

[RFC4752]メルニコフ、A.、 "ケルベロスV5（" GSSAPI "）簡易認証セキュリティー層（SASL）メカニズム"、RFC 4752、2006年11月。

[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.

[RFC5246]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。

[RFC5587] Williams, N., "Extended Generic Security Service Mechanism Inquiry APIs", RFC 5587, July 2009.

[RFC5587]ウィリアムズ、N.、 "拡張ジェネリックセキュリティサービスメカニズム問い合わせのAPI"、RFC 5587、2009年7月。

[RFC5802] Menon-Sen, A., Melnikov, A., Newman, C., and N. Williams, "Salted Challenge Response Authentication Mechanism (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010.

[RFC5802]メノンセン、A.、メルニコフ、A.、ニューマン、C.、およびN.ウィリアムズ、 "塩蔵チャレンジレスポンス認証メカニズム（SCRAM）SASLとGSS-APIメカニズム"、RFC 5802、2010年7月。

[MITM] Asokan, N., Niemi, V., and K. Nyberg, "Man-in-the-Middle in Tunnelled Authentication", in 11th Security Protocols Workshop, 2002.

[MITM] Asokan、N.、ニエミ、V.、およびK.ニベルグ、 "のman-in-the-middleトンネル化認証で" 第11回セキュリティプロトコルワークショップ、2002年に、。

[SASL-GSSAPI] Melnikov, A., "The Kerberos V5 ("GSSAPI") SASL mechanism", Work in Progress, March 2005.

[SASL-GSSAPI]メルニコフ、A.、 "ケルベロスV5（" GSSAPI "）SASLメカニズム"、進歩、2005年3月に作業。

Authors' Addresses

著者のアドレス

Simon Josefsson SJD AB Hagagatan 24 Stockholm 113 47 SE

サイモンJosefsson氏SJD AB Hagagatan 24ストックホルム113 47 SE

EMail: simon@josefsson.org URI: http://josefsson.org/

電子メール：simon@josefsson.org URI：http://josefsson.org/

Nicolas Williams Oracle 5300 Riata Trace Ct Austin, TX 78727 USA

ニコラス・ウィリアムズOracleの5300 RiataトレースのCtオースティン、TX 78727 USA

EMail: Nicolas.Williams@oracle.com

メールアドレス：Nicolas.Williams@oracle.com