[要約] RFC 7546は、GSSネゴシエーションループの構造を定義しており、セキュリティサービスの交渉プロセスを効率化することを目的としています。
Internet Engineering Task Force (IETF) B. Kaduk
Request for Comments: 7546 MIT
Category: Informational May 2015
ISSN: 2070-1721
Structure of the Generic Security Service (GSS) Negotiation Loop
Generic Security Service（GSS）交渉ループの構造
Abstract
概要
This document specifies the generic structure of the negotiation loop to establish a Generic Security Service (GSS) security context between initiator and acceptor. The control flow of the loop is indicated for both parties, including error conditions, and indications are given for where application-specific behavior must be specified.
このドキュメントでは、イニシエーターとアクセプターの間にGeneric Security Service（GSS）セキュリティコンテキストを確立するためのネゴシエーションループの一般的な構造を指定します。ループの制御フローは、エラー条件を含め、両方の当事者に対して示され、アプリケーション固有の動作を指定する必要がある場所について示されます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 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/rfc7546.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7546で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
2. Application Protocol Requirements ...............................3
3. Loop Structure ..................................................4
3.1. Anonymous Initiators .......................................5
3.2. GSS_Init_sec_context .......................................5
3.3. Sending from Initiator to Acceptor .........................6
3.4. Acceptor Sanity Checking ...................................6
3.5. GSS_Accept_sec_context .....................................7
3.6. Sending from Acceptor to Initiator .........................8
3.7. Initiator Input Validation .................................9
3.8. Continue the Loop ..........................................9
4. After Security Context Negotiation ..............................9
4.1. Authorization Checks ......................................10
4.2. Using Partially Complete Security Contexts ................10
4.3. Additional Context Tokens .................................11
5. Sample Code ....................................................12
5.1. GSS Application Sample Code ...............................13
6. Security Considerations ........................................19
7. References .....................................................20
7.1. Normative References ......................................20
7.2. Informative References ....................................20
Acknowledgements ..................................................21
Author's Address ..................................................21
"Generic Security Service Application Program Interface Version 2, Update 1" [RFC2743] provides a generic interface for security services in the form of an abstraction layer over the underlying security mechanisms that an application may use. A GSS initiator and acceptor exchange messages, called "tokens", until a security context is established. Such a security context allows for each party to authenticate the other, the passing of confidential and/or integrity-protected messages between the initiator and acceptor, the generation of identical pseudorandom bit strings by both participants [RFC4401], and more.
「汎用セキュリティサービスアプリケーションプログラムインターフェイスバージョン2、更新1」[RFC2743]は、アプリケーションが使用する可能性のある基本的なセキュリティメカニズム上の抽象化レイヤーの形式で、セキュリティサービスの汎用インターフェイスを提供します。 GSSの開始側と受け入れ側は、セキュリティコンテキストが確立されるまで、「トークン」と呼ばれるメッセージを交換します。このようなセキュリティコンテキストにより、各パーティは互いを認証し、機密情報や完全性が保護されたメッセージをイニシエータとアクセプタ間で受け渡し、両方の参加者が同一の疑似ランダムビット文字列を生成することができます[RFC4401]など。
During context establishment, security context tokens are exchanged synchronously, one at a time; the initiator sends the first context token. The number of tokens that must be exchanged between the initiator and acceptor in order to establish the security context is dependent on the underlying mechanism as well as the desired properties of the security context and is, in general, not known to the application. Accordingly, the application's control flow must include a loop within which GSS security context tokens are exchanged; the loop terminates upon successful establishment of a security context or an error condition. The GSS-API, together with its security mechanisms, specifies the format and encoding of the context tokens themselves, but the application protocol must specify the necessary framing for the application to determine what octet strings constitute GSS security context tokens and pass them into the GSS-API implementation as appropriate.
コンテキストの確立中、セキュリティコンテキストトークンは、一度に1つずつ同期的に交換されます。イニシエーターは最初のコンテキストトークンを送信します。セキュリティコンテキストを確立するためにイニシエーターとアクセプター間で交換する必要があるトークンの数は、基になるメカニズムとセキュリティコンテキストの目的のプロパティに依存し、通常はアプリケーションにはわかりません。したがって、アプリケーションの制御フローには、GSSセキュリティコンテキストトークンが交換されるループが含まれている必要があります。ループは、セキュリティコンテキストまたはエラー状態の確立に成功すると終了します。 GSS-APIは、そのセキュリティメカニズムとともに、コンテキストトークン自体の形式とエンコーディングを指定しますが、アプリケーションプロトコルは、アプリケーションがGSSセキュリティコンテキストトークンを構成するオクテット文字列を決定してGSSに渡すために必要なフレーミングを指定する必要があります。 -APIの実装。
The GSS-API C-bindings [RFC2744] provide some example code for such a negotiation loop, but this code does not specify the application's behavior on unexpected or error conditions. As such, individual application protocol specifications have had to specify the structure of their GSS negotiation loops, including error handling, on a per-protocol basis (see [RFC4462], [RFC3645], [RFC5801], [RFC4752], and [RFC2203]). This represents a substantial duplication of effort, and the various specifications go into different levels of detail and describe different possible error conditions. Therefore, it is preferable to have the structure of the GSS negotiation loop, including error conditions and token passing, described in a single specification that can then be referred to from other documents in lieu of repeating the structure of the loop each time. This document fills that role.
GSS-API Cバインディング[RFC2744]は、このようなネゴシエーションループのサンプルコードをいくつか提供していますが、このコードは、予期しない状況やエラー状況でのアプリケーションの動作を指定していません。そのため、個々のアプリケーションプロトコル仕様では、プロトコルごとに、エラー処理を含むGSSネゴシエーションループの構造を指定する必要がありました（[RFC4462]、[RFC3645]、[RFC5801]、[RFC4752]、および[RFC2203を参照] ]）。これはかなりの作業の重複を表しており、さまざまな仕様がさまざまな詳細レベルに入り、考えられるさまざまなエラー状態を説明しています。したがって、エラー状態やトークンの受け渡しを含むGSSネゴシエーションループの構造を単一の仕様で記述し、ループの構造を毎回繰り返す代わりに他のドキュメントから参照できるようにすることが望ましいです。このドキュメントはその役割を果たします。
The necessary requirements for correctly performing a GSS negotiation loop are essentially all included in [RFC2743], but they are scattered in many different places. This document brings all the requirements together into one place for the convenience of implementors, even though the normative requirements remain in [RFC2743]. In a few places, this document notes additional behavior that is useful for applications but is not mandated by [RFC2743].
GSS交渉ループを正しく実行するために必要な要件は基本的にすべて[RFC2743]に含まれていますが、それらは多くの異なる場所に散在しています。このドキュメントでは、規範的な要件が[RFC2743]に残っている場合でも、実装者の便宜のためにすべての要件を1つの場所にまとめています。いくつかの箇所で、このドキュメントは、アプリケーションには有用であるが[RFC2743]によって義務付けられていない追加の動作に言及しています。
Part of the purpose of this document is to guide the development of new application protocols using the GSS-API, as well as the development of new application software using such protocols. The following list consists of features that are necessary or useful in such an application protocol:
このドキュメントの目的の一部は、GSS-APIを使用した新しいアプリケーションプロトコルの開発、およびそのようなプロトコルを使用した新しいアプリケーションソフトウェアの開発を導くことです。次のリストは、このようなアプリケーションプロトコルで必要または役立つ機能で構成されています。
o Protocols require a way to frame and identify security context negotiation tokens during the GSS negotiation loop.
o プロトコルには、GSSネゴシエーションループ中にセキュリティコンテキストネゴシエーショントークンをフレーム化して識別する方法が必要です。
o Error tokens should generally also get special framing, as the recipient may have no other way to distinguish unexpected error context tokens from per-message tokens.
o 受信者が予期しないエラーコンテキストトークンをメッセージごとのトークンから区別する他の方法がない場合があるため、エラートークンは通常、特別なフレーミングも取得する必要があります。
o Protocols may benefit from a generic means of indicating an error, possibly accompanied by a descriptive string, to be used if error tokens are not available or not usable due to constraints of the application protocol.
o アプリケーションプロトコルの制約のためにエラートークンが利用できない、または使用できない場合に使用される、説明文字列を伴う可能性のあるエラーを示す一般的な手段は、プロトコルにメリットがあります。
o A protocol may use the negotiated GSS security context for per-message operations; in such cases, the protocol will need a way to frame and identify those per-message tokens and the nature of their contents. For example, a protocol message may be accompanied by the output of GSS_GetMIC() over that message; the protocol must identify the location and size of that Message Identity Code (MIC) token and indicate that it is a MIC token and to what cleartext it corresponds.
o プロトコルは、メッセージごとの操作にネゴシエートされたGSSセキュリティコンテキストを使用できます。このような場合、プロトコルには、メッセージごとのトークンとその内容の性質をフレーム化して識別する方法が必要です。たとえば、プロトコルメッセージには、そのメッセージに対するGSS_GetMIC()の出力が伴う場合があります。プロトコルは、そのメッセージ識別コード（MIC）トークンの場所とサイズを識別し、それがMICトークンであることと、それに対応するクリアテキストを示す必要があります。
o Applications are responsible for authorization of the authenticated peer principal names that are supplied by the GSS-API. Such names are mechanism specific and may come from a different portion of a federated identity scheme. Application protocols may need to supply additional information to support the authorization of access to a given resource, such as the Secure Shell version 2 (SSHv2) "username" parameter.
o アプリケーションは、GSS-APIによって提供される認証されたピアプリンシパル名の承認を担当します。このような名前はメカニズム固有であり、フェデレーションIDスキームの別の部分に由来する場合があります。アプリケーションプロトコルは、Secure Shellバージョン2（SSHv2）の「username」パラメータなど、特定のリソースへのアクセスの承認をサポートするために追加情報を提供する必要がある場合があります。
The loop is begun by the appropriately named initiator, which calls GSS_Init_sec_context() with an empty (zero-length) input_token and a fixed set of input flags containing the desired attributes for the security context. The initiator should not change any of the input parameters to GSS_Init_sec_context() between calls to it during the loop, with the exception of the input_token parameter, which will contain a message from the acceptor after the initial call, and the input_context_handle, which must be the result returned in the output_context_handle of the previous call to GSS_Init_sec_context() (GSS_C_NO_CONTEXT for the first call). (In the C bindings, there is only a single read/modify context_handle argument, so the same variable should be passed for each call in the loop.) RFC 2743 only requires that the claimant_cred_handle argument remain constant over all calls in the loop, but the other non-excepted arguments should also remain fixed for reliable operation.
ループは適切に名前が付けられたイニシエーターによって開始されます。このイニシエーターは、GSS_Init_sec_context()を空（長さゼロ）のinput_tokenと、セキュリティコンテキストに必要な属性を含む固定の入力フラグのセットで呼び出します。イニシエーターは、最初の呼び出しの後にアクセプターからのメッセージが含まれるinput_tokenパラメーターと、 GSS_Init_sec_context()への前の呼び出しのoutput_context_handleで返された結果（最初の呼び出しではGSS_C_NO_CONTEXT）。 （Cバインディングでは、read / modify context_handle引数が1つしかないため、ループ内の呼び出しごとに同じ変数を渡す必要があります。）RFC 2743では、claimant_cred_handle引数がループ内のすべての呼び出しで一定であることだけが必要ですが、信頼できる操作のために、他の例外のない引数も固定したままにする必要があります。
The following subsections will describe the various steps of the loop, without special consideration to whether a call to GSS_Init_sec_context() or GSS_Accept_sec_context() is the first such call in the loop.
以下のサブセクションでは、GSS_Init_sec_context()またはGSS_Accept_sec_context()への呼び出しがループ内で最初のそのような呼び出しであるかどうかについては特に考慮せずに、ループのさまざまなステップについて説明します。
If the initiator is requesting anonymity by setting the anon_req_flag input to GSS_Init_sec_context(), then on non-error returns from GSS_Init_sec_context() (that is, when the major status is GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED) the initiator must verify that the output value of anon_state from GSS_Init_sec_context() is true before sending the security context token to the acceptor. Failing to perform this check could cause the initiator to lose anonymity.
イニシエーターがanon_req_flag入力をGSS_Init_sec_context()に設定して匿名性を要求している場合、GSS_Init_sec_context()からエラー以外の戻りで（つまり、メジャーステータスがGSS_S_COMPLETEまたはGSS_S_CONTINUE_NEEDEDの場合）、イニシエーターはanon_stateの出力値を確認する必要があります。 GSS_Init_sec_context()は、セキュリティコンテキストトークンをアクセプターに送信する前にtrueになります。このチェックを実行しないと、イニシエーターが匿名性を失う可能性があります。
The initiator calls GSS_Init_sec_context() using the input_context_handle for the current security context being established and its fixed set of input parameters and the input_token received from the acceptor (if this is not the first iteration of the loop). The presence or absence of a nonempty output_token and the value of the major status code are the indicators for how to proceed:
イニシエータは、確立されている現在のセキュリティコンテキストのinput_context_handleと、その固定の入力パラメータのセットと、アクセプタから受信したinput_tokenを使用してGSS_Init_sec_context()を呼び出します（これがループの最初の反復でない場合）。空でないoutput_tokenの有無とメジャーステータスコードの値は、次の手順を示すインジケータです。
o If the major status code is GSS_S_COMPLETE and the output_token is empty, then the context negotiation is fully complete and ready for use by the initiator with no further actions.
o メジャーステータスコードがGSS_S_COMPLETEで、output_tokenが空の場合、コンテキストネゴシエーションは完全に完了しており、イニシエーターはそれ以上のアクションなしで使用できます。
o If the major status code is GSS_S_COMPLETE and the output_token is nonempty, then the initiator's portion of the security context negotiation is complete but the acceptor's is not. The initiator must send the output_token to the acceptor so that the acceptor can establish its half of the security context.
o メジャーステータスコードがGSS_S_COMPLETEで、output_tokenが空でない場合、セキュリティコンテキストネゴシエーションの開始側の部分は完了していますが、受け入れ側の部分は完了していません。イニシエーターは、アクセプターがセキュリティコンテキストの半分を確立できるように、output_tokenをアクセプターに送信する必要があります。
o If the major status code is GSS_S_CONTINUE_NEEDED and the output_token is nonempty, the context negotiation is incomplete. The initiator must send the output_token to the acceptor and await another input_token from the acceptor.
o メジャーステータスコードがGSS_S_CONTINUE_NEEDEDで、output_tokenが空でない場合、コンテキストネゴシエーションは不完全です。イニシエーターは、output_tokenをアクセプターに送信し、アクセプターからの別のinput_tokenを待つ必要があります。
o If the major status code is GSS_S_CONTINUE_NEEDED and the output_token is empty, the mechanism has produced an output that is not compliant with [RFC2743]. However, there are some known implementations of certain mechanisms such as NT LAN Manager Security Support Provider [NTLMSSP] that do produce empty context negotiation tokens. For maximum interoperability, applications should be prepared to accept such tokens and should transmit them to the acceptor if they are generated.
o メジャーステータスコードがGSS_S_CONTINUE_NEEDEDで、output_tokenが空の場合、メカニズムは[RFC2743]に準拠していない出力を生成しています。ただし、空のコンテキストネゴシエーショントークンを生成するNT LAN Managerセキュリティサポートプロバイダー[NTLMSSP]など、特定のメカニズムのいくつかの既知の実装があります。相互運用性を最大にするために、アプリケーションはそのようなトークンを受け入れる準備をして、生成された場合はそれらをアクセプターに送信する必要があります。
o If the major status code is any other value, the context negotiation has failed. If the output_token is nonempty, it is an error token and the initiator should send it to the acceptor. If the output_token is empty, then the initiator should indicate the failure to the acceptor if an appropriate application-protocol channel to do so is available.
o メジャーステータスコードが他の値の場合、コンテキストネゴシエーションは失敗しています。 output_tokenが空でない場合、それはエラートークンであり、イニシエーターはそれをアクセプターに送信する必要があります。 output_tokenが空の場合、適切なアプリケーションプロトコルチャネルが利用可能であれば、イニシエーターはアクセプターに失敗を示す必要があります。
The establishment of a GSS security context between initiator and acceptor requires some communication channel by which to exchange the context negotiation tokens. The nature of this channel is not specified by the GSS specification -- it could be a dedicated TCP channel, a UDP-based Remote Procedure Call (RPC) protocol, or any other sort of channel. In many cases, the channel will be multiplexed with non-GSS application data; the application protocol must always provide some means by which the GSS context tokens can be identified (e.g., length and start location) and passed through to the mechanism accordingly. The application protocol may also include a facility for indicating errors from one party to the other, which can be used to convey errors resulting from GSS-API calls when appropriate (such as when no error token was generated by the GSS-API implementation). Note that GSS major and minor status codes are specified by language bindings, not the abstract API; sending a major status code and optionally the display form of the two error codes may be the best that can be done in this case.
イニシエータとアクセプタ間のGSSセキュリティコンテキストの確立には、コンテキストネゴシエーショントークンを交換するための通信チャネルが必要です。このチャネルの性質はGSS仕様では指定されていません。専用のTCPチャネル、UDPベースのリモートプロシージャコール（RPC）プロトコル、またはその他の種類のチャネルである可能性があります。多くの場合、チャネルは非GSSアプリケーションデータと多重化されます。アプリケーションプロトコルは、常にGSSコンテキストトークンを識別できる手段（長さや開始位置など）を提供し、それに応じてメカニズムに渡す必要があります。アプリケーションプロトコルには、一方の当事者から他方の当事者へのエラーを示す機能も含まれている場合があります。これは、GSS-API呼び出しから生じるエラーを伝えるために使用できます（GSS-API実装によってエラートークンが生成されなかった場合など）。 GSSメジャーおよびマイナーステータスコードは、抽象APIではなく言語バインディングによって指定されることに注意してください。メジャーステータスコードとオプションで2つのエラーコードの表示形式を送信するのが、この場合に実行できる最善の方法です。
However, even the presence of a communication channel does not necessarily indicate that it is appropriate for the initiator to indicate such errors. For example, if the acceptor is a stateless or near-stateless UDP server, there is probably no need for the initiator to explicitly indicate its failure to the acceptor. Conditions such as this can be treated in individual application protocol specifications.
しかしながら、通信チャネルの存在でさえ、イニシエータがそのようなエラーを示すことが適切であることを必ずしも示すわけではない。たとえば、アクセプターがステートレスまたはステートレスに近いUDPサーバーである場合、イニシエーターがその失敗をアクセプターに明示的に示す必要はおそらくありません。このような条件は、個々のアプリケーションプロトコル仕様で処理できます。
If a regular security context output_token is produced by the call to GSS_Init_sec_context(), the initiator must transmit this token to the acceptor over the application's communication channel. If the call to GSS_Init_sec_context() returns an error token as output_token, it is recommended that the initiator transmit this token to the acceptor over the application's communication channel.
通常のセキュリティコンテキストoutput_tokenがGSS_Init_sec_context()の呼び出しによって生成された場合、イニシエーターはアプリケーションの通信チャネルを介してこのトークンをアクセプターに送信する必要があります。 GSS_Init_sec_context()への呼び出しがoutput_tokenとしてエラートークンを返す場合、イニシエーターがアプリケーションの通信チャネルを介してこのトークンをアクセプターに送信することをお勧めします。
The acceptor's half of the negotiation loop is triggered by the receipt of a context token from the initiator. Before calling GSS_Accept_sec_context(), the acceptor may find it useful to perform some sanity checks on the state of the negotiation loop.
受け入れ側のネゴシエーションループの半分は、開始側からのコンテキストトークンの受信によってトリガーされます。 GSS_Accept_sec_context()を呼び出す前に、受け入れ側は、ネゴシエーションループの状態に対していくつかの健全性チェックを実行すると便利な場合があります。
If the acceptor receives a context token but was not expecting such a token (for example, if the acceptor's previous call to GSS_Accept_sec_context() returned GSS_S_COMPLETE), this is probably an error condition indicating that the initiator's state is invalid. See Section 4.3 for some exceptional cases. It is likely appropriate for the acceptor to report this error condition to the initiator via the application's communication channel.
アクセプターがコンテキストトークンを受け取ったが、そのようなトークンを期待していなかった場合（たとえば、アクセプターのGSS_Accept_sec_context()への以前の呼び出しがGSS_S_COMPLETEを返した場合）、これはおそらくイニシエーターの状態が無効であることを示すエラー状態です。例外的なケースについては、セクション4.3を参照してください。アクセプターは、アプリケーションの通信チャネルを介してこのエラー状態をイニシエーターに報告することが適切です。
If the acceptor is expecting a context token (e.g., if the previous call to GSS_Accept_sec_context() returned GSS_S_CONTINUE_NEEDED) but does not receive such a token within a reasonable amount of time after transmitting the previous output_token to the initiator, the acceptor should assume that the initiator's state is invalid (timeout) and fail the GSS negotiation. Again, it is likely appropriate for the acceptor to report this error condition to the initiator via the application's communication channel.
アクセプターがコンテキストトークンを期待している場合（たとえば、GSS_Accept_sec_context()への以前の呼び出しがGSS_S_CONTINUE_NEEDEDを返した場合）、前のoutput_tokenをイニシエーターに送信した後、妥当な時間内にそのようなトークンを受信しない場合、アクセプターは、イニシエータの状態は無効（タイムアウト）であり、GSSネゴシエーションに失敗します。この場合も、アクセプターがアプリケーションの通信チャネルを介してこのエラー状態をイニシエーターに報告するのが適切です。
The GSS acceptor responds to the actions of an initiator; as such, there should always be a nonempty input_token to calls to GSS_Accept_sec_context(). The input_context_handle parameter will always be given as the output_context_handle from the previous call to GSS_Accept_sec_context() in a given negotiation loop, or GSS_C_NO_CONTEXT on the first call, but the acceptor_cred_handle and chan_bindings arguments should remain fixed over the course of a given GSS negotiation loop. [RFC2743] only requires that the acceptor_cred_handle remain fixed throughout the loop, but the chan_bindings argument should also remain fixed for reliable operation.
GSSアクセプターは、イニシエーターのアクションに応答します。そのため、GSS_Accept_sec_context()の呼び出しには常に空でないinput_tokenが必要です。 input_context_handleパラメータは常に、特定のネゴシエーションループでのGSS_Accept_sec_context()への以前の呼び出しからのoutput_context_handle、または最初の呼び出しでのGSS_C_NO_CONTEXTとして指定されますが、acceptor_cred_handleおよびchan_bindings引数は、特定のGSSネゴシエーションループの過程で固定されたままにする必要があります。 [RFC2743]は、ループ全体でacceptor_cred_handleが固定されたままである必要があるだけですが、信頼できる操作のためにchan_bindings引数も固定されたままにする必要があります。
The GSS acceptor calls GSS_Accept_sec_context(), using the input_context_handle for the current security context being established and the input_token received from the initiator. The presence or absence of a nonempty output_token and the value of the major status code are the indicators for how to proceed:
GSSアクセプターは、確立中の現在のセキュリティコンテキストのinput_context_handleとイニシエーターから受信したinput_tokenを使用して、GSS_Accept_sec_context()を呼び出します。空でないoutput_tokenの有無とメジャーステータスコードの値は、次の手順を示すインジケータです。
o If the major status code is GSS_S_COMPLETE and the output_token is empty, then the context negotiation is fully complete and ready for use by the acceptor with no further actions.
o メジャーステータスコードがGSS_S_COMPLETEで、output_tokenが空の場合、コンテキストネゴシエーションは完全に完了しており、アクセプターはそれ以上のアクションなしで使用できます。
o If the major status code is GSS_S_COMPLETE and the output_token is nonempty, then the acceptor's portion of the security context negotiation is complete but the initiator's is not. The acceptor must send the output_token to the initiator so that the initiator can establish its half of the security context.
o メジャーステータスコードがGSS_S_COMPLETEで、output_tokenが空でない場合、セキュリティコンテキストネゴシエーションのアクセプターの部分は完了していますが、イニシエーターの部分は完了していません。受け入れ側は、開始側がセキュリティコンテキストの半分を確立できるように、output_tokenを開始側に送信する必要があります。
o If the major status code is GSS_S_CONTINUE_NEEDED and the output_token is nonempty, the context negotiation is incomplete. The acceptor must send the output_token to the initiator and await another input_token from the initiator.
o メジャーステータスコードがGSS_S_CONTINUE_NEEDEDで、output_tokenが空でない場合、コンテキストネゴシエーションは不完全です。アクセプターは、output_tokenをイニシエーターに送信し、イニシエーターからの別のinput_tokenを待つ必要があります。
o If the major status code is GSS_S_CONTINUE_NEEDED and the output_token is empty, the mechanism has produced an output that is not compliant with [RFC2743]. However, there are some known implementations of certain mechanisms such as NTLMSSP [NTLMSSP] that do produce empty context negotiation tokens. For maximum interoperability, applications should be prepared to accept such tokens and should transmit them to the initiator if they are generated.
o メジャーステータスコードがGSS_S_CONTINUE_NEEDEDで、output_tokenが空の場合、メカニズムは[RFC2743]に準拠していない出力を生成しています。ただし、空のコンテキストネゴシエーショントークンを生成するNTLMSSP [NTLMSSP]などの特定のメカニズムのいくつかの既知の実装があります。相互運用性を最大にするために、アプリケーションはそのようなトークンを受け入れる準備をして、生成された場合はそれらをイニシエーターに送信する必要があります。
o If the major status code is any other value, the context negotiation has failed. If the output_token is nonempty, it is an error token and the acceptor should send it to the initiator. If the output_token is empty, then the acceptor should indicate the failure to the initiator if an appropriate application-protocol channel to do so is available.
o メジャーステータスコードが他の値の場合、コンテキストネゴシエーションは失敗しています。 output_tokenが空でない場合、それはエラートークンであり、アクセプターはそれをイニシエーターに送信する必要があります。 output_tokenが空の場合、アクセプターは、適切なアプリケーションプロトコルチャネルが利用可能であれば、失敗をイニシエーターに通知する必要があります。
The mechanism for sending the context token from acceptor to initiator will depend on the nature of the communication channel between the two parties. For a synchronous bidirectional channel, it can be just another piece of data sent over the link, but for a stateless UDP RPC acceptor, the token will probably end up being sent as an RPC output parameter. Application protocol specifications will need to specify the nature of this behavior.
アクセプターからイニシエーターにコンテキストトークンを送信するメカニズムは、2つのパーティ間の通信チャネルの性質によって異なります。同期双方向チャネルの場合、それはリンクを介して送信される別のデータの一部である可能性がありますが、ステートレスUDP RPCアクセプターの場合、トークンはおそらくRPC出力パラメーターとして送信されます。アプリケーションプロトコルの仕様では、この動作の性質を指定する必要があります。
If the application protocol has the initiator driving the application's control flow, it is particularly helpful for the acceptor to indicate a failure to the initiator, as mentioned in some of the above cases conditional on "an appropriate application-protocol channel to do so".
アプリケーションプロトコルに、アプリケーションの制御フローを駆動するイニシエーターがある場合、「そうするのに適切なアプリケーションプロトコルチャネル」を条件とする上記のケースの一部で述べたように、アクセプターがイニシエーターに障害を示すことが特に役立ちます。
If a regular security context output_token is produced by the call to GSS_Accept_sec_context(), the acceptor must transmit this token to the initiator over the application's communication channel. If the call to GSS_Accept_sec_context() returns an error token as output_token, it is recommended that the acceptor transmit this token to the initiator over the application's communication channel.
通常のセキュリティコンテキストoutput_tokenがGSS_Accept_sec_context()の呼び出しによって生成される場合、アクセプターはこのトークンをアプリケーションの通信チャネルを介してイニシエーターに送信する必要があります。 GSS_Accept_sec_context()の呼び出しでoutput_tokenとしてエラートークンが返された場合は、アクセプターがこのトークンをアプリケーションの通信チャネルを介してイニシエーターに送信することをお勧めします。
The initiator's half of the negotiation loop is triggered (after the first call) by receipt of a context token from the acceptor. Before calling GSS_Init_sec_context(), the initiator may find it useful to perform some sanity checks on the state of the negotiation loop.
イニシエーターのネゴシエーションループの半分は、アクセプターからのコンテキストトークンの受信によってトリガーされます（最初の呼び出しの後）。 GSS_Init_sec_context()を呼び出す前に、イニシエーターは、ネゴシエーションループの状態に対して健全性チェックを実行すると便利な場合があります。
If the initiator receives a context token but was not expecting such a token (for example, if the initiator's previous call to GSS_Init_sec_context() returned GSS_S_COMPLETE), this is probably an error condition indicating that the acceptor's state is invalid. See Section 4.3 for some exceptional cases. It may be appropriate for the initiator to report this error condition to the acceptor via the application's communication channel.
イニシエーターがコンテキストトークンを受信したが、そのようなトークンを予期していなかった場合（たとえば、イニシエーターの以前のGSS_Init_sec_context()の呼び出しがGSS_S_COMPLETEを返した場合）、これはおそらくアクセプターの状態が無効であることを示すエラー状態です。例外的なケースについては、セクション4.3を参照してください。イニシエーターがこのエラー状態をアプリケーションの通信チャネルを介してアクセプターに報告することが適切な場合があります。
If the initiator is expecting a context token (that is, the previous call to GSS_Init_sec_context() returned GSS_S_CONTINUE_NEEDED) but does not receive such a token within a reasonable amount of time after transmitting the previous output_token to the acceptor, the initiator should assume that the acceptor's state is invalid and fail the GSS negotiation. Again, it may be appropriate for the initiator to report this error condition to the acceptor via the application's communication channel.
イニシエーターがコンテキストトークンを期待している（つまり、GSS_Init_sec_context()への以前の呼び出しがGSS_S_CONTINUE_NEEDEDを返した）が、前のoutput_tokenをアクセプターに送信した後、妥当な時間内にそのようなトークンを受信しない場合、イニシエーターは、アクセプターの状態は無効であり、GSSネゴシエーションに失敗しました。この場合も、イニシエーターがこのエラー状態をアプリケーションの通信チャネルを介してアクセプターに報告することが適切な場合があります。
If the loop is in neither a success nor a failure condition, then the loop must continue. Control flow returns to Section 3.2.
ループが成功条件でも失敗条件でもない場合、ループは継続する必要があります。制御フローはセクション3.2に戻ります。
Once a party has completed its half of the security context and fulfilled its obligations to the other party, the context is complete, but it is not necessarily ready and appropriate for use. In particular, the security context flags may not be appropriate for the given application's use. In some cases, the context may be ready for use before the negotiation is complete, see Section 4.2.
ある当事者がセキュリティコンテキストの半分を完了し、他の当事者に対する義務を果たすと、コンテキストは完成しますが、必ずしも準備ができていて、使用に適しているとは限りません。特に、セキュリティコンテキストフラグは、特定のアプリケーションの使用には適さない場合があります。場合によっては、ネゴシエーションが完了する前にコンテキストが使用できる状態になることがあります。セクション4.2を参照してください。
The initiator specifies, as part of its fixed set of inputs to GSS_Init_sec_context(), values for all defined request flag booleans, among them: deleg_req_flag, mutual_req_flag, replay_det_req_flag, sequence_req_flag, conf_req_flag, and integ_req_flag. Upon completion of the security context negotiation, the initiator must verify that the values of deleg_state, mutual_state, replay_det_state, sequence_state, conf_avail, and integ_avail (and any additional flags added by extensions) from the last call to GSS_Init_sec_context() correspond to the requested flags. If a flag was requested but is not available and that feature is necessary for the application protocol, the initiator must destroy the security context and not use the security context for application traffic.
イニシエーターは、GSS_Init_sec_context()への入力の固定セットの一部として、定義されたすべてのリクエストフラグブール値の値を指定します。セキュリティコンテキストのネゴシエーションが完了すると、開始者は、GSS_Init_sec_context()への最後の呼び出しからのdeleg_state、mutual_state、replay_det_state、sequence_state、conf_avail、およびinteg_avail（および拡張機能によって追加された追加のフラグ）の値が、要求されたフラグに対応することを確認する必要があります。フラグが要求されたが利用できない場合で、その機能がアプリケーションプロトコルに必要な場合、イニシエーターはセキュリティコンテキストを破棄し、アプリケーショントラフィックにセキュリティコンテキストを使用しないでください。
Application protocol specifications citing this document should indicate which context flags are required for their application protocol.
このドキュメントを引用するアプリケーションプロトコルの仕様では、アプリケーションプロトコルに必要なコンテキストフラグを示す必要があります。
The acceptor receives as output the following booleans: deleg_state, mutual_state, replay_det_state, sequence_state, anon_state, trans_state, conf_avail, and integ_avail, and any additional flags added by extensions to the GSS-API. The acceptor must verify that any flags necessary for the application protocol are set. If a necessary flag is not set, the acceptor must destroy the security context and not use the security context for application traffic.
受け入れ側は、deleg_state、mutual_state、replay_det_state、sequence_state、anon_state、trans_state、conf_avail、およびinteg_availのブール値と、GSS-APIの拡張機能によって追加された追加のブール値を出力として受け取ります。受け入れ側は、アプリケーションプロトコルに必要なフラグが設定されていることを確認する必要があります。必要なフラグが設定されていない場合、アクセプターはセキュリティコンテキストを破棄し、アプリケーショントラフィックにセキュリティコンテキストを使用しないようにする必要があります。
The acceptor receives as one of the outputs of GSS_Accept_sec_context() the name of the initiator that has authenticated during the security context negotiation. Applications need to implement authorization checks on this received name ('client_name' in the sample code) before providing access to restricted resources. In particular, security context negotiation can be successful when the client is anonymous or is from a different identity realm than the acceptor, depending on the details of the mechanism used by the GSS-API to establish the security context. Acceptor applications can check which target name was used by the initiator, but the details are out of scope for this document. See Sections 2.2.6 and 1.1.5 of [RFC2743]. Additional information can be available in GSS-API Naming Extensions [RFC6680].
アクセプターは、GSS_Accept_sec_context()の出力の1つとして、セキュリティーコンテキストのネゴシエーション中に認証されたイニシエーターの名前を受け取ります。アプリケーションは、制限されたリソースへのアクセスを提供する前に、この受信した名前（サンプルコードでは 'client_name'）に承認チェックを実装する必要があります。特に、GSS-APIがセキュリティコンテキストを確立するために使用するメカニズムの詳細に応じて、クライアントが匿名であるか、アクセプターとは異なるIDレルムからのものである場合、セキュリティコンテキストネゴシエーションは成功する可能性があります。アクセプターアプリケーションは、イニシエーターによって使用されたターゲット名を確認できますが、詳細はこのドキュメントの範囲外です。 [RFC2743]のセクション2.2.6および1.1.5を参照してください。 GSS-APIネーミング拡張[RFC6680]で追加情報を入手できます。
For mechanism/flag combinations that require multiple token exchanges, the GSS-API specification [RFC2743] provides a prot_ready_state output value from GSS_Init_sec_context() and GSS_Accept_sec_context(), which indicates when per-message operations are available. However, many mechanism implementations do not provide this functionality and the analysis of the security consequences of its use is rather complicated, so it is not expected to be useful in most application protocols.
複数のトークン交換を必要とするメカニズムとフラグの組み合わせに対して、GSS-API仕様[RFC2743]は、GSS_Init_sec_context()およびGSS_Accept_sec_context()からのprot_ready_state出力値を提供し、メッセージごとの操作がいつ利用可能かを示します。ただし、多くのメカニズム実装はこの機能を提供せず、その使用のセキュリティ結果の分析はかなり複雑であるため、ほとんどのアプリケーションプロトコルで役立つとは考えられていません。
In particular, mutual authentication, replay protection, and other services (if requested) are services that will be active when GSS_S_COMPLETE is returned but that are not necessarily active before the security context is fully established.
特に、相互認証、リプレイ保護、およびその他のサービス（要求された場合）は、GSS_S_COMPLETEが返されたときにアクティブになりますが、セキュリティコンテキストが完全に確立されるまでは必ずしもアクティブではないサービスです。
Under some conditions, a context token will be received by a party to a security context negotiation after that party has completed the negotiation (i.e., after GSS_Init_sec_context() or GSS_Accept_sec_context() has returned GSS_S_COMPLETE). Such tokens must be passed to GSS_Process_context_token() for processing. It may not always be necessary for a mechanism implementation to generate an error token on the initiator side or for an initiator application to transmit that token to the acceptor; such decisions are out of scope for this document. Both peers should always be prepared to process such tokens and application protocols should provide means by which they can be transmitted.
状況によっては、セキュリティトークンネゴシエーションのパーティがネゴシエーションを完了した後（GSS_Init_sec_context()またはGSS_Accept_sec_context()がGSS_S_COMPLETEを返した後）に、コンテキストトークンがパーティによって受信されます。このようなトークンは、処理のためにGSS_Process_context_token()に渡す必要があります。メカニズムの実装がイニシエーター側でエラートークンを生成したり、イニシエーターアプリケーションがそのトークンをアクセプターに送信したりする必要は必ずしもありません。そのような決定は、このドキュメントの範囲外です。両方のピアは常にそのようなトークンを処理する準備をしておく必要があり、アプリケーションプロトコルはそれらを送信できる手段を提供する必要があります。
Such tokens can be security context deletion tokens, emitted when the remote party called GSS_Delete_sec_context() with a non-null output_context_token parameter, or error tokens, emitted when the remote party experiences an error processing the last token in a security context negotiation exchange. Errors experienced when processing tokens earlier in the negotiation would be transmitted as normal security context tokens and processed by GSS_Init_sec_context() or GSS_Accept_sec_context(), as appropriate. With the GSS-API version 2, it is not recommended to use security context deletion tokens, so error tokens are expected to be the most common form of additional context token for new application protocols.
このようなトークンは、セキュリティコンテキスト削除トークンであり、リモートパーティがnull以外のoutput_context_tokenパラメータを指定してGSS_Delete_sec_context()を呼び出したときに発行されるか、リモートパーティがセキュリティコンテキストネゴシエーション交換で最後のトークンの処理中にエラーを経験したときに発行されるエラートークンです。ネゴシエーションの早い段階でトークンを処理するときに発生したエラーは、通常のセキュリティコンテキストトークンとして送信され、必要に応じてGSS_Init_sec_context()またはGSS_Accept_sec_context()によって処理されます。 GSS-APIバージョン2では、セキュリティコンテキスト削除トークンの使用は推奨されていないため、エラートークンは、新しいアプリケーションプロトコルの追加のコンテキストトークンの最も一般的な形式であると予想されます。
GSS_Process_context_token() may indicate an error in its major_status field if an error is encountered locally during token processing or to indicate that an error was encountered on the peer and conveyed in an error token. See [Err4151] of [RFC2743]. Regardless of the major_status output of GSS_Process_context_token(), GSS_Inquire_context() should be used after processing the extra token, to query the status of the security context and whether it can supply the features necessary for the application protocol.
GSS_Process_context_token()は、トークンの処理中にローカルでエラーが発生した場合、またはピアでエラーが発生し、エラートークンで伝達されたことを示すために、major_statusフィールドにエラーを示す場合があります。 [RFC2743]の[Err4151]を参照してください。 GSS_Process_context_token()のmajor_status出力に関係なく、追加のトークンの処理後にGSS_Inquire_context()を使用して、セキュリティコンテキストのステータスと、アプリケーションプロトコルに必要な機能を提供できるかどうかを照会する必要があります。
At present, all tokens that should be handled by GSS_Process_context_token() will lead to the security context being effectively unusable. Future extensions to the GSS-API may allow for applications to continue to function after a call to GSS_Process_context_token(), and it is expected that the outputs of GSS_Inquire_context() will indicate whether it is safe to do so. However, since there are no such extensions at present (error tokens and deletion tokens both result in the security context being essentially unusable), there is no guidance to give to applications regarding this possibility at this time.
現在、GSS_Process_context_token()によって処理される必要のあるすべてのトークンは、セキュリティコンテキストを事実上使用不可能にします。 GSS-APIの将来の拡張により、GSS_Process_context_token()の呼び出し後もアプリケーションが機能し続けることが可能になる可能性があり、GSS_Inquire_context()の出力が安全かどうかを示すことが期待されます。ただし、現時点ではそのような拡張機能がないため（エラートークンと削除トークンの両方が原因でセキュリティコンテキストが本質的に使用できなくなります）、現時点では、この可能性に関してアプリケーションに提供するガイダンスはありません。
Even if GSS_Process_context_token() processes an error or deletion token that renders the context essentially unusable, the resources associated with the context must eventually be freed with a call to GSS_Delete_sec_context(), just as would be needed if GSS_Init_sec_context() or GSS_Accept_sec_context() had returned an error while processing an input context token and the input_context_handle was not GSS_C_NO_CONTEXT. RFC 2743 has some text that is slightly ambiguous in this regard, but the best practice is to always call GSS_Delete_sec_context().
GSS_Process_context_token()がエラーまたは削除トークンを処理して、コンテキストを実質的に使用できなくしても、GSS_Init_sec_context()またはGSS_Accept_sec_context()が必要だった場合と同様に、コンテキストに関連付けられたリソースは、GSS_Delete_sec_context()の呼び出しで最終的に解放する必要があります。入力コンテキストトークンの処理中にエラーが返され、input_context_handleはGSS_C_NO_CONTEXTではありませんでした。 RFC 2743には、この点で少しあいまいなテキストがありますが、ベストプラクティスは、常にGSS_Delete_sec_context()を呼び出すことです。
This section gives sample code for the GSS negotiation loop, both for a regular application and for an application where the initiator wishes to remain anonymous. Since the code for the two cases is very similar, the anonymous-specific additions are wrapped in a conditional check; that check and the conditional code may be ignored if anonymous processing is not needed.
このセクションでは、GSSネゴシエーションループのサンプルコードを示します。通常のアプリケーションと、イニシエーターが匿名を維持したいアプリケーションの両方に対応しています。 2つのケースのコードは非常に似ているため、匿名固有の追加は条件付きチェックでラップされます。匿名処理が不要な場合、そのチェックと条件付きコードは無視されます。
Since the communication channel between the initiator and acceptor is a matter for individual application protocols, it is inherently unspecified at the GSS-API level, which can lead to examples that are less satisfying than may be desired. For example, the sample code in [RFC2744] uses an unspecified send_token_to_peer() routine. Fully correct and general code to frame and transmit tokens requires a substantial amount of error checking and would detract from the core purpose of this document, so we only present the function signature for one example of what such functions might be and leave some comments in the otherwise empty function bodies.
イニシエータとアクセプタ間の通信チャネルは個々のアプリケーションプロトコルの問題であるため、GSS-APIレベルでは本質的に指定されておらず、必要とされるよりも満足のいく例ではない可能性があります。たとえば、[RFC2744]のサンプルコードでは、未指定のsend_token_to_peer()ルーチンを使用しています。トークンをフレーム化して送信するための完全に正しい一般的なコードは、かなりの量のエラーチェックを必要とし、このドキュメントの主要な目的を損なうため、そのような関数がどのようなものであるかの1つの例についてのみ関数シグネチャを提示し、それ以外の場合は空の関数本体。
This sample code is written in C, using the GSS-API C-bindings [RFC2744]. It uses the macro GSS_ERROR() to help unpack the various sorts of information that can be stored in the major status field; supplementary information does not necessarily indicate an error. Applications written in other languages will need to exercise care that checks against the major status value are written correctly.
このサンプルコードは、GSS-API Cバインディング[RFC2744]を使用してCで記述されています。マクロGSS_ERROR()を使用して、メジャーステータスフィールドに格納できるさまざまな種類の情報を展開します。補足情報は必ずしもエラーを示すものではありません。他の言語で記述されたアプリケーションは、主要なステータス値に対するチェックが正しく記述されるように注意する必要があります。
This sample code should be compilable as a standalone program, linked against a GSS-API library. In addition to supplying implementations for the token transmission/receipt routines, in order for the program to successfully run when linked against most GSS-API libraries, the initiator will need to specify an explicit target name for the acceptor, which must match the credentials available to the acceptor. A skeleton for how this may be done is provided, using a dummy name.
このサンプルコードは、GSS-APIライブラリに対してリンクされたスタンドアロンプログラムとしてコンパイルできる必要があります。トークン送信/受信ルーチンの実装を提供することに加えて、ほとんどのGSS-APIライブラリに対してリンクされたときにプログラムが正常に実行されるためには、イニシエーターはアクセプターの明示的なターゲット名を指定する必要があります。アクセプターに。これを行うためのスケルトンが、ダミー名を使用して提供されています。
This sample code assumes use of v2 of the GSS-API. Applications wishing to remain compatible with v1 of the GSS-API may need to perform additional checks in some locations.
このサンプルコードは、GSS-APIのv2の使用を前提としています。 GSS-APIのv1との互換性を維持したいアプリケーションは、一部の場所で追加のチェックを実行する必要がある場合があります。
#include <unistd.h>
#include <err.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <gssapi/gssapi.h>
/*
* This helper is used only on buffers that we allocate ourselves (e.g.,
* from receive_token()). Buffers allocated by GSS routines must use
* gss_release_buffer().
*/
static void
release_buffer(gss_buffer_t buf)
{
free(buf->value);
buf->value = NULL;
buf->length = 0;
}
/*
* Helper to send a token on the specified file descriptor.
*
* If errors are encountered, this routine must not directly cause
* termination of the process because compliant GSS applications
* must release resources allocated by the GSS library before
* exiting.
*
* Returns 0 on success, nonzero on failure.
*/
static int
send_token(int fd, gss_buffer_t token)
{
/*
* Supply token framing and transmission code here.
*
* It is advisable for the application protocol to specify the
* length of the token being transmitted unless the underlying
* transit does so implicitly.
*
* In addition to checking for error returns from whichever
* syscall(s) are used to send data, applications should have
* a loop to handle EINTR returns.
*/
return 1;
}
/*
* Helper to receive a token on the specified file descriptor.
*
* If errors are encountered, this routine must not directly cause
* termination of the process because compliant GSS applications
* must release resources allocated by the GSS library before
* exiting.
*
* Returns 0 on success, nonzero on failure.
*/
static int
receive_token(int fd, gss_buffer_t token)
{
/*
* Supply token framing and transmission code here.
*
* In addition to checking for error returns from whichever
* syscall(s) are used to receive data, applications should have
* a loop to handle EINTR returns.
*
* This routine is assumed to allocate memory for the local copy
* of the received token, which must be freed with release_buffer().
*/
return 1;
}
static void
do_initiator(int readfd, int writefd, int anon)
{
int initiator_established = 0, ret;
gss_ctx_id_t ctx = GSS_C_NO_CONTEXT;
OM_uint32 major, minor, req_flags, ret_flags;
gss_buffer_desc input_token = GSS_C_EMPTY_BUFFER;
gss_buffer_desc output_token = GSS_C_EMPTY_BUFFER;
gss_buffer_desc name_buf = GSS_C_EMPTY_BUFFER;
gss_name_t target_name = GSS_C_NO_NAME;
/* Applications should set target_name to a real value. */
name_buf.value = "<service>@<hostname.domain>";
name_buf.length = strlen(name_buf.value);
major = gss_import_name(&minor, &name_buf,
GSS_C_NT_HOSTBASED_SERVICE, &target_name);
if (GSS_ERROR(major)) {
warnx(1, "Could not import name\n");
goto cleanup;
}
/* Mutual authentication will require a token from acceptor to
* initiator and thus a second call to gss_init_sec_context(). */
req_flags = GSS_C_MUTUAL_FLAG | GSS_C_CONF_FLAG | GSS_C_INTEG_FLAG;
if (anon)
req_flags |= GSS_C_ANON_FLAG;
while (!initiator_established) {
/* The initiator_cred_handle, mech_type, time_req,
* input_chan_bindings, actual_mech_type, and time_rec
* parameters are not needed in many cases. We pass
* GSS_C_NO_CREDENTIAL, GSS_C_NO_OID, 0, NULL, NULL, and NULL
* for them, respectively. */
major = gss_init_sec_context(&minor, GSS_C_NO_CREDENTIAL, &ctx,
target_name, GSS_C_NO_OID,
req_flags, 0, NULL, &input_token,
NULL, &output_token, &ret_flags,
NULL);
/* This was allocated by receive_token() and is no longer
* needed. Free it now to avoid leaks if the loop continues. */
release_buffer(&input_token);
if (anon) {
/* Initiators that wish to remain anonymous must check
* whether their request has been honored before sending
* each token. */
if (!(ret_flags & GSS_C_ANON_FLAG)) {
warnx("Anonymous requested but not available\n");
goto cleanup;
}
}
/* Always send a token if we are expecting another input token
* (GSS_S_CONTINUE_NEEDED is set) or if it is nonempty. */
if ((major & GSS_S_CONTINUE_NEEDED) ||
output_token.length > 0) {
ret = send_token(writefd, &output_token);
if (ret != 0)
goto cleanup;
}
/* Check for errors after sending the token so that we will send
* error tokens. */
if (GSS_ERROR(major)) {
warnx("gss_init_sec_context() error major 0x%x\n", major);
goto cleanup;
}
/* Free the output token's storage; we don't need it anymore.
* gss_release_buffer() is safe to call on the output buffer
* from gss_int_sec_context(), even if there is no storage
* associated with that buffer. */
(void)gss_release_buffer(&minor, &output_token);
if (major & GSS_S_CONTINUE_NEEDED) {
ret = receive_token(readfd, &input_token);
if (ret != 0)
goto cleanup;
} else if (major == GSS_S_COMPLETE) {
initiator_established = 1;
} else {
/* This situation is forbidden by RFC 2743. Bail out. */
warnx("major not complete or continue but not error\n");
goto cleanup;
}
} /* while (!initiator_established) */
if ((ret_flags & req_flags) != req_flags) {
warnx("Negotiated context does not support requested flags\n");
goto cleanup;
}
printf("Initiator's context negotiation successful\n");
cleanup:
/* We are required to release storage for nonzero-length output
* tokens. gss_release_buffer() zeros the length, so we
* will not attempt to release the same buffer twice. */
if (output_token.length > 0)
(void)gss_release_buffer(&minor, &output_token);
/* Do not request a context deletion token; pass NULL. */
(void)gss_delete_sec_context(&minor, &ctx, NULL);
(void)gss_release_name(&minor, &target_name);
}
/*
* Perform authorization checks on the initiator's GSS name object.
*
* Returns 0 on success (the initiator is authorized) and nonzero
* when the initiator is not authorized.
*/
static int
check_authz(gss_name_t client_name)
{
/*
* Supply authorization checking code here.
*
* Options include bitwise comparison of the exported name against
* a local database and introspection against name attributes.
*/
return 0;
}
static void
do_acceptor(int readfd, int writefd)
{
int acceptor_established = 0, ret;
gss_ctx_id_t ctx = GSS_C_NO_CONTEXT;
OM_uint32 major, minor, ret_flags;
gss_buffer_desc input_token = GSS_C_EMPTY_BUFFER;
gss_buffer_desc output_token = GSS_C_EMPTY_BUFFER;
gss_name_t client_name;
major = GSS_S_CONTINUE_NEEDED;
メジャー= GSS_S_CONTINUE_NEEDED;
while (!acceptor_established) {
if (major & GSS_S_CONTINUE_NEEDED) {
ret = receive_token(readfd, &input_token);
if (ret != 0)
goto cleanup;
} else if (major == GSS_S_COMPLETE) {
acceptor_established = 1;
break;
} else {
/* This situation is forbidden by RFC 2743. Bail out. */
warnx("major not complete or continue but not error\n");
goto cleanup;
}
/* We can use the default behavior or do not need the returned
* information for the parameters acceptor_cred_handle,
* input_chan_bindings, mech_type, time_rec, and
* delegated_cred_handle, and pass the values
* GSS_C_NO_CREDENTIAL, NULL, NULL, NULL, and NULL,
* respectively. In some cases the src_name will not be
* needed, but most likely it will be needed for some
* authorization or logging functionality. */
major = gss_accept_sec_context(&minor, &ctx,
GSS_C_NO_CREDENTIAL,
&input_token, NULL,
&client_name, NULL,
&output_token, &ret_flags, NULL,
NULL);
/* This was allocated by receive_token() and is no longer
* needed. Free it now to avoid leaks if the loop continues. */
release_buffer(&input_token);
/* Always send a token if we are expecting another input token
* (GSS_S_CONTINUE_NEEDED is set) or if it is nonempty. */
if ((major & GSS_S_CONTINUE_NEEDED) ||
output_token.length > 0) {
ret = send_token(writefd, &output_token);
if (ret != 0)
goto cleanup;
}
/* Check for errors after sending the token so that we will send
* error tokens. */
if (GSS_ERROR(major)) {
warnx("gss_accept_sec_context() error major 0x%x\n", major);
goto cleanup;
}
/* Free the output token's storage; we don't need it anymore.
* gss_release_buffer() is safe to call on the output buffer
* from gss_accept_sec_context(), even if there is no storage
* associated with that buffer. */
(void)gss_release_buffer(&minor, &output_token);
} /* while (!acceptor_established) */
if (!(ret_flags & GSS_C_INTEG_FLAG)) {
warnx("Negotiated context does not support integrity\n");
goto cleanup;
}
printf("Acceptor's context negotiation successful\n");
ret = check_authz(client_name);
if (ret != 0)
printf("Client is not authorized; rejecting access\n");
cleanup:
release_buffer(&input_token);
/* We are required to release storage for nonzero-length output
* tokens. gss_release_buffer() zeros the length, so we
* will not attempt to release the same buffer twice. */
if (output_token.length > 0)
(void)gss_release_buffer(&minor, &output_token);
/* Do not request a context deletion token, pass NULL. */
(void)gss_delete_sec_context(&minor, &ctx, NULL);
(void)gss_release_name(&minor, &client_name);
}
int
main(void)
{
pid_t pid;
int fd1 = -1, fd2 = -1;
/* Create file descriptors for reading/writing here. */
pid = fork();
if (pid == 0)
do_initiator(fd1, fd2, 0);
else if (pid > 0)
do_acceptor(fd2, fd1);
else
err(1, "fork() failed\n");
exit(0);
}
This document provides a (reasonably) concise description and example for correct construction of the GSS-API security context negotiation loop. Since everything relating to the construction and use of a GSS security context is security related, there are security-relevant considerations throughout the document. It is useful to call out a few things in this section, though.
このドキュメントでは、GSS-APIセキュリティコンテキストのネゴシエーションループを正しく構築するための（合理的に）簡潔な説明と例を提供します。 GSSセキュリティコンテキストの構築と使用に関連するものはすべてセキュリティに関連しているため、ドキュメント全体でセキュリティ関連の考慮事項があります。ただし、このセクションでいくつかのことを呼び出すと便利です。
The GSS-API uses a request-and-check model for features. An application using the GSS-API requests certain features (e.g., confidentiality protection for messages or anonymity), but such a request does not require the GSS implementation to provide that feature. The application must check the returned flags to verify whether a requested feature is present; if the feature was non-optional for the application, the application must generate an error. Phrased differently, the GSS-API will not generate an error if it is unable to satisfy the features requested by the application.
GSS-APIは、機能のリクエストアンドチェックモデルを使用します。 GSS-APIを使用するアプリケーションは、特定の機能（メッセージの機密保護や匿名性など）を要求しますが、そのような要求では、GSS実装がその機能を提供する必要はありません。アプリケーションは返されたフラグをチェックして、要求された機能が存在するかどうかを確認する必要があります。機能がアプリケーションでオプションでない場合、アプリケーションはエラーを生成する必要があります。言い換えると、GSS-APIは、アプリケーションから要求された機能を満たすことができない場合でもエラーを生成しません。
In many cases, it is convenient for GSS acceptors to accept security contexts using multiple acceptor names (such as by using the default credential set, as happens when GSS_C_NO_CREDENTIAL is passed to GSS_Accept_sec_context()). This allows acceptors to use any credentials to which they have access for accepting security contexts, which may not be the desired behavior for a given application. (For example, the Secure Shell daemon (sshd) may wish to accept only using GSS_C_NT_HOSTBASED credentials of the form host@<hostname>, and not nfs@<hostname>.) Acceptor applications can check which target name was used by the initiator, but the details are out of scope for this document. See Sections 2.2.6 and 1.1.5 of [RFC2743]
多くの場合、GSSアクセプターが複数のアクセプター名を使用して（GSS_C_NO_CREDENTIALがGSS_Accept_sec_context()に渡されるときに発生するように、デフォルトの資格情報セットを使用するなどして）セキュリティーコンテキストを受け入れると便利です。これにより、アクセプターは、セキュリティコンテキストを受け入れるためにアクセスできる資格情報を使用できます。これは、特定のアプリケーションにとって望ましい動作ではない場合があります。 （たとえば、Secure Shellデーモン（sshd）は、nfs @ <hostname>ではなく、hosts << hostname>という形式のGSS_C_NT_HOSTBASED資格情報のみを使用して受け入れたい場合があります。）アクセプターアプリケーションは、イニシエーターによって使用されたターゲット名を確認できます。詳細はこのドキュメントの範囲外です。 [RFC2743]のセクション2.2.6と1.1.5を参照してください
The C sample code uses the macro GSS_ERROR() to assess the return value of gss_init_sec_context() and gss_accept_sec_context(). This is done to indicate where checks are needed in writing code for other languages and what the nature of those checks might be. The C code could be made simpler by omitting that macro. In applications expecting to receive protected octet streams, this macro should not be used on the result of per-message operations, as it omits checking for supplementary status values such as GSS_S_DUPLICATE_TOKEN, GSS_S_OLD_TOKEN, etc. Use of the GSS_ERROR() macro on the results of GSS-API per-message operations has resulted in security vulnerabilities in existing software.
CサンプルコードはマクロGSS_ERROR()を使用して、gss_init_sec_context()およびgss_accept_sec_context()の戻り値を評価します。これは、他の言語のコードを記述する際にチェックが必要な場所と、それらのチェックの性質を示すために行われます。そのマクロを省略することにより、Cコードをより簡単にすることができます。保護されたオクテットストリームを受信することが予想されるアプリケーションでは、GSS_S_DUPLICATE_TOKEN、GSS_S_OLD_TOKENなどの補足ステータス値のチェックが省略されるため、メッセージごとの操作の結果に対してこのマクロを使用しないでください。結果でのGSS_ERROR()マクロの使用メッセージごとのGSS-APIオペレーションの数は、既存のソフトウェアにセキュリティの脆弱性をもたらしました。
The security considerations from RFCs 2743 and 2744 remain applicable to consumers of this document.
RFC 2743および2744のセキュリティに関する考慮事項は、引き続きこのドキュメントの利用者に適用されます。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, DOI 10.17487/RFC2743, January 2000, <http://www.rfc-editor.org/info/rfc2743>.
[RFC2743] Linn、J。、「Generic Security Service Application Program Interface Version 2、Update 1」、RFC 2743、DOI 10.17487 / RFC2743、2000年1月、<http://www.rfc-editor.org/info/rfc2743> 。
[RFC2744] Wray, J., "Generic Security Service API Version 2 : C-bindings", RFC 2744, DOI 10.17487/RFC2744, January 2000, <http://www.rfc-editor.org/info/rfc2744>.
[RFC2744] Wray、J。、「Generic Security Service API Version 2：C-bindings」、RFC 2744、DOI 10.17487 / RFC2744、2000年1月、<http://www.rfc-editor.org/info/rfc2744>。
[Err4151] RFC Errata, Erratum ID 4151, RFC 2743.
[Err4151] RFC Errata、Erratum ID 4151、RFC 2743。
[NTLMSSP] Microsoft Corporation, "[MS-NLMP]: NT LAN Manager (NTLM) Authentication Protocol", May 2014, <https://msdn.microsoft.com/en-us/library/cc236621.aspx>.
[NTLMSSP] Microsoft Corporation、「[MS-NLMP]：NT LAN Manager（NTLM）Authentication Protocol」、2014年5月、<https://msdn.microsoft.com/en-us/library/cc236621.aspx>。
[RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol Specification", RFC 2203, DOI 10.17487/RFC2203, September 1997, <http://www.rfc-editor.org/info/rfc2203>.
[RFC2203] Eisler、M.、Chiu、A。、およびL. Ling、「RPCSEC_GSS Protocol Specification」、RFC 2203、DOI 10.17487 / RFC2203、1997年9月、<http://www.rfc-editor.org/info/ rfc2203>。
[RFC3645] Kwan, S., Garg, P., Gilroy, J., Esibov, L., Westhead, J., and R. Hall, "Generic Security Service Algorithm for Secret Key Transaction Authentication for DNS (GSS-TSIG)", RFC 3645, DOI 10.17487/RFC3645, October 2003, <http://www.rfc-editor.org/info/rfc3645>.
[RFC3645] Kwan、S.、Garg、P.、Gilroy、J.、Esibov、L.、Westhead、J。、およびR. Hall、「DNSの秘密鍵トランザクション認証のための汎用セキュリティサービスアルゴリズム（GSS-TSIG） "、RFC 3645、DOI 10.17487 / RFC3645、2003年10月、<http://www.rfc-editor.org/info/rfc3645>。
[RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API Extension for the Generic Security Service Application Program Interface (GSS-API)", RFC 4401, DOI 10.17487/RFC4401, February 2006, <http://www.rfc-editor.org/info/rfc4401>.
[RFC4401]ウィリアムズ、N。、「Generic Security Service Application Program Interface（GSS-API）の疑似ランダム関数（PRF）API拡張」、RFC 4401、DOI 10.17487 / RFC4401、2006年2月、<http：// www.rfc-editor.org/info/rfc4401>。
[RFC4462] Hutzelman, J., Salowey, J., Galbraith, J., and V. Welch, "Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol", RFC 4462, DOI 10.17487/RFC4462, May 2006, <http://www.rfc-editor.org/info/rfc4462>.
[RFC4462] Hutzelman、J.、Salowey、J.、Galbraith、J。、およびV. Welch、「Generic Security Service Application Program Interface（GSS-API）Authentication and Key Exchange for the Secure Shell（SSH）Protocol」、RFC 4462、DOI 10.17487 / RFC4462、2006年5月、<http://www.rfc-editor.org/info/rfc4462>。
[RFC4752] Melnikov, A., Ed., "The Kerberos V5 ("GSSAPI") Simple Authentication and Security Layer (SASL) Mechanism", RFC 4752, DOI 10.17487/RFC4752, November 2006, <http://www.rfc-editor.org/info/rfc4752>.
[RFC4752] Melnikov、A。、編、「The Kerberos V5（ "GSSAPI"）Simple Authentication and Security Layer（SASL）Mechanism "、RFC 4752、DOI 10.17487 / RFC4752、2006年11月、<http：//www.rfc -editor.org/info/rfc4752>。
[RFC5801] Josefsson, S. and N. Williams, "Using Generic Security Service Application Program Interface (GSS-API) Mechanisms in Simple Authentication and Security Layer (SASL): The GS2 Mechanism Family", RFC 5801, DOI 10.17487/RFC5801, July 2010, <http://www.rfc-editor.org/info/rfc5801>.
[RFC5801] Josefsson、S。およびN. Williams、「Simple Authentication and Security Layer（SASL）：Generic Security Service Application Program Interface（GSS-API）Mechanisms in Simple Authentication and Security Layer（SASL）：The GS2 Mechanism Family」、RFC 5801、DOI 10.17487 / RFC5801 2010年7月、<http://www.rfc-editor.org/info/rfc5801>。
[RFC6680] Williams, N., Johansson, L., Hartman, S., and S. Josefsson, "Generic Security Service Application Programming Interface (GSS-API) Naming Extensions", RFC 6680, DOI 10.17487/RFC6680, August 2012, <http://www.rfc-editor.org/info/rfc6680>.
[RFC6680]ウィリアムズ、N。、ヨハンソン、L。、ハートマン、S。、およびS.ジョセフソン、「Generic Security Service Application Programming Interface（GSS-API）Naming Extensions」、RFC 6680、DOI 10.17487 / RFC6680、2012年8月、 <http://www.rfc-editor.org/info/rfc6680>。
Acknowledgements
謝辞
Thanks to Nico Williams and Jeff Hutzleman for prompting me to write this document.
この文書の作成を促してくれたNico WilliamsとJeff Hutzlemanに感謝します。
Author's Address
著者のアドレス
Benjamin Kaduk MIT Kerberos Consortium
ベンジャミンカドゥックMIT Kerberosコンソーシアム
EMail: kaduk@mit.edu