[要約] RFC 5801は、Simple Authentication and Security Layer（SASL）でのGeneric Security Service Application Program Interface（GSS-API）メカニズムの使用に関するものであり、GS2メカニズムファミリーを定義しています。このRFCの目的は、セキュリティレイヤーでの認証とセキュリティを強化するために、GSS-APIメカニズムをSASLに統合することです。
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
一般的なセキュリティサービスアプリケーションプログラムインターフェイス（GSS-API）シンプルな認証とセキュリティレイヤー（SASL）のメカニズム：GS2メカニズムファミリ
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.
このドキュメントでは、Simple認証およびセキュリティレイヤー（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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5801で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。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
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]は、さまざまな認証メカニズムを使用してアプリケーションにセキュリティサービスを提供するフレームワークです。Simple認証とセキュリティレイヤー（SASL）[RFC4422]は、さまざまなメカニズムを使用して、接続ベースのプロトコルに認証とセキュリティレイヤーを提供するフレームワークです。このドキュメントでは、GSS-APIメカニズムをSASLメカニズムのように使用する方法について説明します。この施設はGS2と呼ばれます。これは、これが2番目のGSS-API-> SASLメカニズムブリッジであることを示すモニカーです。元の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メカニズム」[RFC1964] [RFC4121]以外のGSS-APIメカニズムの幅広い展開を獲得できませんでした。具体的には、a）GS1は往復最適化されておらず、b）GS1はチャネル結合をサポートしていませんでした[RFC5056]。これらの問題と、次のSASLパスワードベースのメカニズムを作成する機会「Salted Challenge Response Authentication Mechanism（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認証IDの長さ）を追加します。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とアプリケーションのプレーンテキストが送信される安全なチャネルへのチャネルバインディングを使用すると、すべてのプレーンテキストが認証されます。
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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
The document uses many terms and function names defined in [RFC2743], as updated by [RFC5554].
このドキュメントは、[RFC5554]で更新されたように、[RFC2743]で定義された多くの用語と関数名を使用します。
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メカニズム名があります。1つは、サーバーがチャネルバインディングをサポートしていることを示します。もう1つは、そうではないことを示します。
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メカニズム名は、指定された場合、指定されたときにそのメカニズムによって提供されるものです。この名前は、サーバーがチャネルバインディングをサポートしていないことを示しています。接尾辞「-Plus」を追加すると、結果の名前は、サーバーがチャネルバインディングをサポートしていることを示します。SASLの実装では、GSS_INQUIRE_SASLNAME_FOR_MECH呼び出し（以下を参照）を使用して、GSS-APIメカニズムのSASLメカニズム名をクエリできます。
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実装には、メカニズムオブジェクト識別子（OID）をSASL名に内部的にマッピングするために他のメカニズムが必要です。この場合、実装はSASL名を知っているメカニズムのみをサポートできます。GSS_INQUIRE_SASLNAME_FOR_MECH（）が失敗し、GS2実装がOIDを他の手段でSASLメカニズム名にマッピングできない場合、GS2実装は特定のGSS-APIメカニズムを使用してはなりません。
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メカニズムとともに定義されていないGSS-APIメカニズムまたはこのドキュメントでは、SASLメカニズム名は文字列「GS2-」とBase32エンコード[RFC4648]（uppercaseアルファベットを使用）の連結です。GSS-APIメカニズムのオブジェクト識別子のタグと長さのオクテットを含む[ccitt.x690.2002]をasn.1 derエンコードするasn.1 der上で計算されたバイナリSHA-1ハッシュ[FIPS.180-1.1995]の最初の55ビット[fips.180-1.1995]。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".
非OF由来のSASLメカニズム名を持つGS2メカニズムには、「使いやすいSASLメカニズム名」があると言われています。
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を実装する必要性が排除されます。計算されたメカニズム名は実装で直接使用でき、メカニズムがメカニズムファミリの一部であるかどうかを実装する必要はありません。
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.1です。タグと長さを含むoidのasn.1 derエンコードは（hex）06 07 2b 06 01 05 05 01 01.F4 2B 5A 9F 80 FA E9 F8 31 22 6D 5D 9D 56 27 86 61 AD。最初の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 0101101010011111000000
binary in groups of 5: 00011 10011 11100 01111 01000 01010 11010 11010 10011 11110 00000
5：00011 10011 11100 01111 01000 010101101011010100111110 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:
Kerberos V5 GSS-APIメカニズム[RFC1964]のOIDは1.2.840.113554.1.2.2であり、そのderエンコードは（16進）06 09 2a 86 48 86 f7 12 01 02 02.73 25 76 6b D6 C8 45 AA 93 25 51 6A FC FF 04 B0 43 60. 7オクテットをバイナリに変換し、最後のビットをドロップし、5のグループに再グループ化し、それらを小数点に戻します。これらの計算で：
hex: 82 d2 73 25 76 6b d6
ヘックス：82 D2 73 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 010111011001101 01111 01011 01001 00111 00110 01001のグループのバイナリ
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を使用して各小数値を変換します。したがって、Kerberos V5 GSS-APIメカニズムのSASLメカニズム名は「GS2-Qljhgjlwnpl」であり、（このメカニズムがチャネル結合をサポートしているため）「GS2-Qljhgjlwnpl-plus」です。代わりに、次のセクションでは、Kerberos V5メカニズムに非ハッシュ由来のメカニズム名を割り当てます。
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メカニズム名で指定されていませんでした。それにもかかわらず、短い名前を使用すると便利です。Kerberos V5メカニズムに「GS2-KRB5」と「GS2-KRB5-PLUS」という名前を指定します。
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-APIエラートークン（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-flag」フラグを送信する必要があります（以下を参照）。サーバー側では、「gs2- nonstd-flag」が送信される場合を除き、トークンを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-Header」という形式があります。
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
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.
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-FLAG」フラグが存在する場合、クライアントは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」の1つが使用されます。「P」は、クライアントがチャネルバインディングをサポートし、使用したことを意味し、チャネル結合タイプの名前が示されています。「N」とは、クライアントがチャネルバインディングをサポートしていないことを意味します。「Y」は、クライアントがチャネルバインディングをサポートすることを意味しますが、サーバーがサポートしていないと考えているため、チャネルバインディングを使用しませんでした。詳細については、次のセクションを参照してください。
The "gs2-authzid" holds the SASL authorization identity. It is encoded using UTF-8 [RFC3629] with three exceptions:
「GS2-Authzid」は、SASL認証IDを保持しています。3つの例外を除いて、UTF-8 [RFC3629]を使用してエンコードされています。
o The NUL character is forbidden as required by section 3.4.1 of [RFC4422].
o NUL文字は、[RFC4422]のセクション3.4.1で要求されるように禁止されています。
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プロトコルプロファイルに従って正確性を確認します。検証に失敗した結果、認証交換が失敗します。
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 チャネルバインディングの使用をサポートするサーバーは、各GS2メカニズム名の非プラスとプラス変数の両方を宣伝する必要があります。サーバーがチャネルバインディングをサポートできない場合、非プラス変数のみを宣伝する必要があります。政策上の理由により、サーバーが非プラス変動の認証に成功しない場合、プラス変のみを宣伝する必要があります。
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-FLAGを使用してはなりません。
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.
o メカニズムのネゴシエーションとチャネルバインディングをサポートするクライアントは、サーバーが目的のGS2メカニズムのプラス変動を提供する場合、「P」GS2-CB-FLAGを使用する必要があります。
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-FLAGを使用する必要があります。逆に、クライアントがチャネルバインディングの使用を必要とする場合、「P」GS2-CB-FLAGを使用する必要があります。メカニズムのネゴシエーションをサポートしていないクライアントは、「Y」GS2-CB-FLAGを使用することはありません。チャネルバインディングの使用を必要とし、そうでないかどうかに応じて「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 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.
o 初期認証メッセージを受信すると、サーバーはGS2ヘッダーのGS2-CB-FLAGをチェックし、以下に説明するようにGSS_ACCEPT_SEC_CONTEXTのCHAN_BINDINGSパラメーターを構築します。クライアントチャネルのバインディングフラグが「Y」であり、サーバーがチャネルバインディングのサポートを宣伝した場合（クライアントが選択したメカニズムのプラスバリアントを宣伝することにより）、サーバーは認証を失敗させる必要があります。クライアントチャネルバインディングフラグが「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.
o クライアントが「N」GS2-CB-FLAGを使用し、サーバーがチャネルバインディングの使用を必要とする場合、サーバーは認証に失敗する必要があります。
FLAG CLIENT CB SUPPORT SERVER CB SUPPORT DISPOSITION
---- ----------------- ----------------- -----------
n no support N/A If server disallows
non-channel-bound
authentication, then
fail
y Yes, not required No Authentication may succeed; CB not used
Yはい、必須ではありません認証は成功しません。CBは使用されていません
y Yes, not required Yes Authentication must fail
Yはい、必須ではありませんYES認証は失敗する必要があります
p Yes Yes Authentication may
succeed, with CB used
p Yes No Authentication will fail
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]を参照してください。
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チャネルバインディング構造です[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-Channel-Bindings構造のイニシエーター - アドレス型およびアクセプターアドレス型フィールドは、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.
アプリケーション-DATAフィールドは、GS2-CB-FLAGの「P」のGS2-CB-FLAGが使用されている場合、アプリケーションのチャネルバインディングを使用して、初期[GS2-NONSTD-FLAG "、"]を除く、GS2-Headerに設定する必要があります。データ。
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-Unique」は、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-Unique」[RFC5929]チャネル結合タイプを実装する必要があります。クライアントは、チャネルバインディングを実装する場合は、「TLS-Unique」チャネルバインディングタイプを実装する必要があります。クライアントとサーバーは、バインドするチャネルとして、最高層/最も内側のエンドツーエンドTLSチャネルを選択する必要があります。
Servers MUST choose the channel binding type indicated by the client, or fail authentication if they don't support it.
サーバーは、クライアントが示すチャネルバインディングタイプを選択するか、サポートしていない場合は認証を失敗する必要があります。
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では、クライアントからトークンをまだ受け取っていない場合、サーバーは最初の空のチャレンジ（ゼロバイト文字列）を送信します。[RFC4422]のセクション3を参照してください。
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_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.
o クライアントが要求されたauthzidに許可されていない場合、またはauthzidをクライアントのイニシエータープリンシパル名から導き出すことができませんでした。
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（）からのgss_init_sec_context（）からのメッセージごとのtoken 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.
相互_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命名オプションの優れたマッピングを提供するプログラミングインターフェイスを提供することをお勧めします。
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 Name-Typesを使用するという要件はありません。ただし、通常、SASLサーバーにはホストベースのアクセプタープリンシパル名があり（[RFC2743]、セクション4.1を参照）、クライアントには通常、ユーザー名イニシエータープリンシパル名があります（[RFC2743]、セクション4.2を参照）。ホストベースのアクセプタープリンシパル名（ "Service@hostname"）を使用する場合、「サービス」はプロトコルのプロファイルで指定されたサービス名であり、「ホスト名」はサーバーの完全な資格のあるホスト名です。
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.
新しいGSS-APIユーティリティ関数を指定して、SASL実装が特定のSASLメカニズム名が参照するGSS-APIメカニズムをより効率的に識別できるようにします。
Inputs:
入力：
o desired_mech OBJECT IDENTIFIER
o 希望_mechオブジェクト識別子
Outputs:
出力：
o major_status INTEGER
o Major_status整数
o minor_status INTEGER
o minor_status整数
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は、希望の_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から計算されたメカニズム名を保持します。
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 *MINTER_STATUS、const gss_oid desired_mech、gss_buffer_t sasl_mech_name、gss_buffer_t mech_name、gss_buffer_t mek_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 integer、メカニズム固有のステータスコードを変更します。
desired_mech OID, read Identifies the GSS-API mechanism to query.
希望_mech oid、readは、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.
gss_s_bad_mech steaid_mech oidはサポートされていません。
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整数
o minor_status INTEGER
o minor_status整数
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を取得するために使用されます。
The C binding for the GSS_Inquire_mech_for_SASLname call is as follows.
GSS_INQUIRE_MECH_FOR_SASLNAMEコールの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_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 *MINTER_STATUS、const gss_buffer_t sasl_mech_name、gss_oid *mech_type）;
Purpose:
目的：
Output GSS-API mechanism OID of mechanism associated with given sasl_mech_name.
出力GSS-APIメカニズムSASL_MECH_NAMEを与えられたメカニズムのOID。
Parameters:
パラメーター：
minor_status Integer, modify Mechanism-specific status code.
minor_status integer、メカニズム固有のステータスコードを変更します。
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メカニズムはありません。
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メカニズムのいずれかを使用できます。
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.
Kerberos V5 GSS-API [RFC1964]メカニズムは現在、GSSAPIという名前でSASLで使用されています。[RFC4752]を参照してください。Kerberos V5メカニズムは、GS2ファミリーでも使用できます。これにより、相互運用性の問題が発生し、以下で説明および解決されます。
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メカニズムとして使用されるKerberos v GSS-APIメカニズムとワイヤ互換ではありません。
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.
クライアント（またはサーバー）が「GSSAPI」名の下でKerberos V5のみをサポートし、サーバー（またはクライアント）がGS2ファミリーの下でKerberos V5のみをサポートする場合、メカニズムの交渉は失敗します。
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.
サーバーのGS2でKerberos V5メカニズムがサポートされている場合、サーバーは「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]を参照）。
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.
アプリケーションが外部チャネルにチャネルバインディングを使用できる場合、「GSSAPI」メカニズムではなくGS2メカニズムを介してKerberos V5を選択することをお勧めします。
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つの問題があります。1つ目は相互運用性の問題であり、2つ目はセキュリティ上の問題です。問題について説明し、以下で解決します。
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メカニズムYを介して潜在的にネゴシエートされたGSS-APIメカニズムXを実装し、サーバーがGSS-APIメカニズムZを介して交渉されたGSS-APIメカニズムXも実装する場合、認証交渉は失敗します。
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を好む場合、サーバーがXではなくメカニズムをサポートしている場合、クライアントはGSSを使用してメカニズムXを交渉しようとする場合 - 他のメカニズム（単純および保護されたGSS-API交渉（SPNEGO）[RFC4178]など）を交渉するAPIメカニズムは、メカニズムZを使用した場合にメカニズムZを使用することになります。他のメカニズムを交渉するAPIメカニズムは、GS2で許可されていません。
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属性を使用して、そのようなメカニズムを特定できます。
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詳細については連絡先：Simon Josefsson <simon@josefsson.org>意図した使用量：一般的な所有者：一般的な所有者/Change Controller：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」で接尾辞が付いている場合を除き、「-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ライブラリの実装者に便利なものとして提供されます。
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メカニズムのセキュリティに依存します。GS2メカニズムファミリはチャネル結合サポートに依存しているため、チャネル結合をサポートしないGSS-APIメカニズムは、GS2ブリッジを介してSASLメカニズムとして使用することはできません。
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はセキュリティレイヤーをサポートしていないため、安全な外部チャネルへのチャネル結合を使用することを強くお勧めします。成功したチャネル結合は、外部チャネルとそのチャネル結合データが安全であり、使用されるGSS-APIメカニズムが安全であることを条件に、中間（MITM）攻撃の可能性を排除します。チャネル結合障害による認証障害は、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_import_nameのinput_name_stringをgss_c_nt_hostbased_service名タイプで構築する場合、クライアントは、DNSセキュリティなしでドメイン名システム[RFC1033]などの安全で信頼されていないディレクトリサービスを使用してサーバーの完全資格のドメイン名を正規化してはなりません。
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チャネルバインディングタイプレジストリを参照）、GSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSSのセキュリティに関する考慮事項-APIメカニズム（Kerberos V5メカニズム[RFC4121] [RFC1964]など）も適用されます。
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の歴史は、元々RFC 2222によって指定された「GSSAPI」メカニズムにまで由来することができます。この文書は[SASL-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メーリングリストの多くのメンバーの貢献は感謝されています。特に、Pasi Eronen、Sam Hartman、Jeffrey Hutzelman、Alexey Melnikov、およびTom Yuからのアイデアとフィードバックは、文書とプロトコルを改善しました。文書に対するその他の提案は、スペンサー・ドーキンス、ラルフ・ドロム、エイドリアン・ファレル、ロバート・スパークス、グレン・ゾーンによって作成されました。
[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]国立標準技術研究所、「Secure Hash Standard」、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] 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月。
[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] Melnikov、A。およびK. Zeilenga、「Simple Authentication and Security Layer（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] Crocker、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。、「チャネルバインディングの使用のための一般的なセキュリティサービスアプリケーションプログラムインターフェイス（GSS-API）の明確化と拡張」、2009年5月、RFC 5554。
[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）、標準エンコードルール（CER）および識別済みエンコードルール（DER）の仕様」、CCITT推奨X.690、2002年7月。
[RFC5929] Altman, J., Williams, N., and L. Zhu, "Channel Bindings for TLS", RFC 5929, July 2010.
[RFC5929] Altman、J.、Williams、N。、およびL. Zhu、「TLSのチャネルバインディング」、RFC 5929、2010年7月。
[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] Linn、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] Adams、C。、「シンプルなパブリックキーGSS-APIメカニズム（SPKM）」、RFC 2025、1996年10月。
[RFC2222] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.
[RFC2222] Myers、J。、「Simple Authentication and Security Layer（SASL）」、RFC 2222、1997年10月。
[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月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「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] Zhu、L.、Jaganathan、K。、およびS. Hartman、「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] Zhu、L.、Leach、P.、Jaganathan、K。、およびW. Ingersoll、「シンプルで保護されたジェネリックセキュリティサービスアプリケーションプログラムインターフェイス（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] Melnikov、A。、「Kerberos 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] Dierks、T。およびE. Rescorla、「The Transport Layer Security（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] Menon-Sen、A.、Melnikov、A.、Newman、C。、およびN. Williams、「Salted Challenge Response認証メカニズム（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.、Niemi、V。、およびK. Nyberg、「Tunnelled認証の中間者」、2002年11番目のセキュリティプロトコルワークショップで。
[SASL-GSSAPI] Melnikov, A., "The Kerberos V5 ("GSSAPI") SASL mechanism", Work in Progress, March 2005.
[Sasl-Gssapi] Melnikov、A。、「Kerberos V5（ "gssapi"）SASLメカニズム」、2005年3月、進行中の作業。
Authors' Addresses
著者のアドレス
Simon Josefsson SJD AB Hagagatan 24 Stockholm 113 47 SE
Simon Josefsson SJD AB Hagagatan 24 Stockholm 113 47 SE
EMail: simon@josefsson.org
URI: http://josefsson.org/
Nicolas Williams Oracle 5300 Riata Trace Ct Austin, TX 78727 USA
ニコラス・ウィリアムズオラクル5300リアタトレースCTオースティン、テキサス78727 USA
EMail: Nicolas.Williams@oracle.com