[要約] RFC 2743は、汎用セキュリティサービスアプリケーションプログラムインターフェース（GSS-API）のバージョン2のアップデートに関するものです。このRFCの目的は、セキュリティサービスを提供するための標準的なAPIを定義することです。
Network Working Group J. Linn
Request for Comments: 2743 RSA Laboratories
Obsoletes: 2078 January 2000
Category: Standards Track
Generic Security Service Application Program Interface Version 2, Update 1
ジェネリックセキュリティサービスアプリケーションプログラムインターフェイスバージョン2、アップデート1
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
Abstract
概要
The Generic Security Service Application Program Interface (GSS-API), Version 2, as defined in [RFC-2078], provides security services to callers in a generic fashion, supportable with a range of underlying mechanisms and technologies and hence allowing source-level portability of applications to different environments. This specification defines GSS-API services and primitives at a level independent of underlying mechanism and programming language environment, and is to be complemented by other, related specifications:
[RFC-2078]で定義されているジェネリックセキュリティサービスアプリケーションプログラムインターフェイス（GSS-API）、バージョン2は、さまざまな基礎となるメカニズムとテクノロジーでサポート可能であり、ソースレベルを可能にする一般的な方法で発信者にセキュリティサービスを提供します。さまざまな環境へのアプリケーションの移植性。この仕様は、基礎となるメカニズムとプログラミング言語環境から独立したレベルでGSS-APIサービスとプリミティブを定義し、他の関連する仕様によって補完されます。
documents defining specific parameter bindings for particular language environments
特定の言語環境の特定のパラメーターバインディングを定義するドキュメント
documents defining token formats, protocols, and procedures to be implemented in order to realize GSS-API services atop particular security mechanisms
特定のセキュリティメカニズムの上でGSS-APIサービスを実現するために実装するトークン形式、プロトコル、および手順を定義するドキュメント
This memo obsoletes [RFC-2078], making specific, incremental changes in response to implementation experience and liaison requests. It is intended, therefore, that this memo or a successor version thereto will become the basis for subsequent progression of the GSS-API specification on the standards track.
このメモは廃止され[RFC-2078]、実装エクスペリエンスとリエゾンリクエストに応じて特定の漸進的な変更を加えます。したがって、このメモまたは後継バージョンは、標準トラックでのGSS-API仕様のその後の進行の基礎となることを意図しています。
TABLE OF CONTENTS
目次
1: GSS-API Characteristics and Concepts . . . . . . . . . . . . 4
1.1: GSS-API Constructs . . . . . . . . . . . . . . . . . . . . 6
1.1.1: Credentials . . . . . . . . . . . . . . . . . . . . . . 6
1.1.1.1: Credential Constructs and Concepts . . . . . . . . . . 6
1.1.1.2: Credential Management . . . . . . . . . . . . . . . . 7
1.1.1.3: Default Credential Resolution . . . . . . . . . . . . 8
1.1.2: Tokens . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1.3: Security Contexts . . . . . . . . . . . . . . . . . . . 11
1.1.4: Mechanism Types . . . . . . . . . . . . . . . . . . . . 12
1.1.5: Naming . . . . . . . . . . . . . . . . . . . . . . . . 13
1.1.6: Channel Bindings . . . . . . . . . . . . . . . . . . . 16
1.2: GSS-API Features and Issues . . . . . . . . . . . . . . . 17
1.2.1: Status Reporting and Optional Service Support . . . . 17
1.2.1.1: Status Reporting . . . . . . . . . . . . . . . . . . . 17
1.2.1.2: Optional Service Support . . . . . . . . . . . . . . . 19
1.2.2: Per-Message Security Service Availability . . . . . . . 20
1.2.3: Per-Message Replay Detection and Sequencing . . . . . . 21
1.2.4: Quality of Protection . . . . . . . . . . . . . . . . . 24
1.2.5: Anonymity Support . . . . . . . . . . . . . . . . . . . 25
1.2.6: Initialization . . . . . . . . . . . . . . . . . . . . . 25
1.2.7: Per-Message Protection During Context Establishment . . 26
1.2.8: Implementation Robustness . . . . . . . . . . . . . . . 27
1.2.9: Delegation . . . . . . . . . . . . . . . . . . . . . . . 28
1.2.10: Interprocess Context Transfer . . . . . . . . . . . . . 28
2: Interface Descriptions . . . . . . . . . . . . . . . . . . 29
2.1: Credential management calls . . . . . . . . . . . . . . . 31
2.1.1: GSS_Acquire_cred call . . . . . . . . . . . . . . . . . 31
2.1.2: GSS_Release_cred call . . . . . . . . . . . . . . . . . 34
2.1.3: GSS_Inquire_cred call . . . . . . . . . . . . . . . . . 35
2.1.4: GSS_Add_cred call . . . . . . . . . . . . . . . . . . . 37
2.1.5: GSS_Inquire_cred_by_mech call . . . . . . . . . . . . . 40
2.2: Context-level calls . . . . . . . . . . . . . . . . . . . 41
2.2.1: GSS_Init_sec_context call . . . . . . . . . . . . . . . 42
2.2.2: GSS_Accept_sec_context call . . . . . . . . . . . . . . 49
2.2.3: GSS_Delete_sec_context call . . . . . . . . . . . . . . 53
2.2.4: GSS_Process_context_token call . . . . . . . . . . . . 54
2.2.5: GSS_Context_time call . . . . . . . . . . . . . . . . . 55
2.2.6: GSS_Inquire_context call . . . . . . . . . . . . . . . 56
2.2.7: GSS_Wrap_size_limit call . . . . . . . . . . . . . . . 57
2.2.8: GSS_Export_sec_context call . . . . . . . . . . . . . . 59
2.2.9: GSS_Import_sec_context call . . . . . . . . . . . . . . 61
2.3: Per-message calls . . . . . . . . . . . . . . . . . . . . 62
2.3.1: GSS_GetMIC call . . . . . . . . . . . . . . . . . . . . 63
2.3.2: GSS_VerifyMIC call . . . . . . . . . . . . . . . . . . 64
2.3.3: GSS_Wrap call . . . . . . . . . . . . . . . . . . . . . 65
2.3.4: GSS_Unwrap call . . . . . . . . . . . . . . . . . . . . 66
2.4: Support calls . . . . . . . . . . . . . . . . . . . . . . 68
2.4.1: GSS_Display_status call . . . . . . . . . . . . . . . . 68
2.4.2: GSS_Indicate_mechs call . . . . . . . . . . . . . . . . 69
2.4.3: GSS_Compare_name call . . . . . . . . . . . . . . . . . 70
2.4.4: GSS_Display_name call . . . . . . . . . . . . . . . . . 71
2.4.5: GSS_Import_name call . . . . . . . . . . . . . . . . . 72
2.4.6: GSS_Release_name call . . . . . . . . . . . . . . . . . 73
2.4.7: GSS_Release_buffer call . . . . . . . . . . . . . . . . 74
2.4.8: GSS_Release_OID_set call . . . . . . . . . . . . . . . 74
2.4.9: GSS_Create_empty_OID_set call . . . . . . . . . . . . . 75
2.4.10: GSS_Add_OID_set_member call . . . . . . . . . . . . . . 76
2.4.11: GSS_Test_OID_set_member call . . . . . . . . . . . . . 76
2.4.12: GSS_Inquire_names_for_mech call . . . . . . . . . . . . 77
2.4.13: GSS_Inquire_mechs_for_name call . . . . . . . . . . . . 77
2.4.14: GSS_Canonicalize_name call . . . . . . . . . . . . . . 78
2.4.15: GSS_Export_name call . . . . . . . . . . . . . . . . . 79
2.4.16: GSS_Duplicate_name call . . . . . . . . . . . . . . . . 80
3: Data Structure Definitions for GSS-V2 Usage . . . . . . . . 81
3.1: Mechanism-Independent Token Format . . . . . . . . . . . . 81
3.2: Mechanism-Independent Exported Name Object Format . . . . 84
4: Name Type Definitions . . . . . . . . . . . . . . . . . . . 85
4.1: Host-Based Service Name Form . . . . . . . . . . . . . . . 85
4.2: User Name Form . . . . . . . . . . . . . . . . . . . . . . 86
4.3: Machine UID Form . . . . . . . . . . . . . . . . . . . . . 87
4.4: String UID Form . . . . . . . . . . . . . . . . . . . . . 87
4.5: Anonymous Nametype . . . . . . . . . . . . . . . . . . . . 87
4.6: GSS_C_NO_OID . . . . . . . . . . . . . . . . . . . . . . . 88
4.7: Exported Name Object . . . . . . . . . . . . . . . . . . . 88
4.8: GSS_C_NO_NAME . . . . . . . . . . . . . . . . . . . . . . 88
5: Mechanism-Specific Example Scenarios . . . . . . . . . . . 88
5.1: Kerberos V5, single-TGT . . . . . . . . . . . . . . . . . 89
5.2: Kerberos V5, double-TGT . . . . . . . . . . . . . . . . . 89
5.3: X.509 Authentication Framework . . . . . . . . . . . . . 90
6: Security Considerations . . . . . . . . . . . . . . . . . . 91
7: Related Activities . . . . . . . . . . . . . . . . . . . . 92
8: Referenced Documents . . . . . . . . . . . . . . . . . . . 93
Appendix A: Mechanism Design Constraints . . . . . . . . . . . 94
Appendix B: Compatibility with GSS-V1 . . . . . . . . . . . . . 94
Appendix C: Changes Relative to RFC-2078 . . . . . . . . . . . 96
Author's Address . . . . . . . . . . . . . . . . . . . . . . .100
Full Copyright Statement . . . . . . . . . . . . . . . . . . .101
1: GSS-API Characteristics and Concepts
1：GSS-APIの特性と概念
GSS-API operates in the following paradigm. A typical GSS-API caller is itself a communications protocol, calling on GSS-API in order to protect its communications with authentication, integrity, and/or confidentiality security services. A GSS-API caller accepts tokens provided to it by its local GSS-API implementation and transfers the tokens to a peer on a remote system; that peer passes the received tokens to its local GSS-API implementation for processing. The security services available through GSS-API in this fashion are implementable (and have been implemented) over a range of underlying mechanisms based on secret-key and public-key cryptographic technologies.
GSS-APIは、次のパラダイムで動作します。典型的なGSS-API発信者はそれ自体が通信プロトコルであり、認証、整合性、および/または機密保持セキュリティサービスとの通信を保護するためにGSS-APIを求めています。GSS-API発信者は、ローカルGSS-APIの実装によって提供されたトークンを受け入れ、リモートシステムのピアにトークンを転送します。そのピアは、受信したトークンを、処理のためのローカルGSS-API実装に合格します。この方法でGSS-APIを通じて利用可能なセキュリティサービスは、シークレットキーおよびパブリックキーの暗号化技術に基づいたさまざまな基礎メカニズムを介して実装可能です（および実装されています）。
The GSS-API separates the operations of initializing a security context between peers, achieving peer entity authentication (GSS_Init_sec_context() and GSS_Accept_sec_context() calls), from the operations of providing per-message data origin authentication and data integrity protection (GSS_GetMIC() and GSS_VerifyMIC() calls) for messages subsequently transferred in conjunction with that context. (The definition for the peer entity authentication service, and other definitions used in this document, corresponds to that provided in [ISO-7498-2].) When establishing a security context, the GSS-API enables a context initiator to optionally permit its credentials to be delegated, meaning that the context acceptor may initiate further security contexts on behalf of the initiating caller. Per-message GSS_Wrap() and GSS_Unwrap() calls provide the data origin authentication and data integrity services which GSS_GetMIC() and GSS_VerifyMIC() offer, and also support selection of confidentiality services as a caller option. Additional calls provide supportive functions to the GSS-API's users.
GSS-APIは、ピア間のセキュリティコンテキストを初期化する操作を分離し、ピアエンティティ認証（gss_init_sec_context（）およびgss_accept_sec_context（）callsを達成することを分離します。その後、そのコンテキストと組み合わせて転送されたメッセージのGSS_VERIFYMIC（）呼び出し）。（ピアエンティティ認証サービスの定義、およびこのドキュメントで使用されるその他の定義は、[ISO-7498-2]で提供されるものに対応しています。）セキュリティコンテキストを確立する場合、GSS-APIはコンテキストイニシエーターがオプションで許可することを可能にします。委任される資格情報は、コンテキストアクセプターが開始発信者に代わってさらなるセキュリティコンテキストを開始できることを意味します。gss_wrap（）およびgss_unwrap（）呼び出しは、gss_getmic（）およびgss_verifymic（）オファーを提供するデータオリジン認証とデータインテグリティサービスを提供し、また、発信者オプションとして機密保持サービスの選択をサポートします。追加の呼び出しは、GSS-APIのユーザーにサポート機能を提供します。
The following paragraphs provide an example illustrating the dataflows involved in use of the GSS-API by a client and server in a mechanism-independent fashion, establishing a security context and transferring a protected message. The example assumes that credential acquisition has already been completed. The example also assumes that the underlying authentication technology is capable of authenticating a client to a server using elements carried within a single token, and of authenticating the server to the client (mutual authentication) with a single returned token; this assumption holds for some presently-documented CAT mechanisms but is not necessarily true for other cryptographic technologies and associated protocols.
次の段落は、メカニズムに依存しない方法でクライアントとサーバーによるGSS-APIの使用に関与するデータフローを示す例を示し、セキュリティコンテキストを確立し、保護されたメッセージを転送します。この例は、資格の獲得がすでに完了していることを前提としています。また、この例では、基礎となる認証テクノロジーは、単一のトークン内で運ばれる要素を使用してクライアントをサーバーに認証し、単一の返されたトークンでサーバーをクライアントに認証する（相互認証）できることを前提としています。この仮定は、いくつかの文書化されている猫のメカニズムにも当てはまりますが、他の暗号化技術や関連プロトコルには必ずしも当てはまるわけではありません。
The client calls GSS_Init_sec_context() to establish a security context to the server identified by targ_name, and elects to set the mutual_req_flag so that mutual authentication is performed in the course of context establishment. GSS_Init_sec_context() returns an output_token to be passed to the server, and indicates GSS_S_CONTINUE_NEEDED status pending completion of the mutual authentication sequence. Had mutual_req_flag not been set, the initial call to GSS_Init_sec_context() would have returned GSS_S_COMPLETE status. The client sends the output_token to the server.
クライアントはGSS_INIT_SEC_CONTEXT（）を呼び出して、TARG_NAMEで識別されたサーバーにセキュリティコンテキストを確立し、コンテキスト確立の過程で相互認証が実行されるように相互認証を設定することを選択します。gss_init_sec_context（）は、output_tokenを返してサーバーに渡され、相互認証シーケンスの完了が保留されているgss_s_continue_neededステータスを示します。相互_req_flagが設定されていなかった場合、gss_init_sec_context（）への最初の呼び出しはgss_s_completeステータスを返していました。クライアントは、output_tokenをサーバーに送信します。
The server passes the received token as the input_token parameter to GSS_Accept_sec_context(). GSS_Accept_sec_context indicates GSS_S_COMPLETE status, provides the client's authenticated identity in the src_name result, and provides an output_token to be passed to the client. The server sends the output_token to the client.
サーバーは、input_tokenパラメーターとしてgss_accept_sec_context（）に受信されたトークンを渡します。GSS_ACCEPT_SEC_CONTEXT GSS_S_COMPLETEステータスを示し、SRC_NAME結果にクライアントの認証されたアイデンティティを提供し、クライアントに渡されるoutput_tokenを提供します。サーバーは、output_tokenをクライアントに送信します。
The client passes the received token as the input_token parameter to a successor call to GSS_Init_sec_context(), which processes data included in the token in order to achieve mutual authentication from the client's viewpoint. This call to GSS_Init_sec_context() returns GSS_S_COMPLETE status, indicating successful mutual authentication and the completion of context establishment for this example.
クライアントは、受信したトークンをinput_tokenパラメーターとして渡し、gss_init_sec_context（）への後継コールに渡します。gss_init_sec_context（）へのこの呼び出しは、gss_s_completeステータスを返し、相互認証の成功とこの例のコンテキスト確立の完了を示します。
The client generates a data message and passes it to GSS_Wrap(). GSS_Wrap() performs data origin authentication, data integrity, and (optionally) confidentiality processing on the message and encapsulates the result into output_message, indicating GSS_S_COMPLETE status. The client sends the output_message to the server.
クライアントはデータメッセージを生成し、gss_wrap（）に渡します。gss_wrap（）は、データの起源認証、データの整合性、および（オプションで）メッセージの機密性処理を実行し、結果をoutput_messageにカプセル化し、GSS_S_Completeステータスを示します。クライアントは、output_messageをサーバーに送信します。
The server passes the received message to GSS_Unwrap(). GSS_Unwrap() inverts the encapsulation performed by GSS_Wrap(), deciphers the message if the optional confidentiality feature was applied, and validates the data origin authentication and data integrity checking quantities. GSS_Unwrap() indicates successful validation by returning GSS_S_COMPLETE status along with the resultant output_message.
サーバーは、受信したメッセージをgss_unwrap（）に渡します。gss_unwrap（）gss_wrap（）によって実行されるカプセル化を反転し、オプションの機密性機能が適用された場合、メッセージを解読し、データの原点認証とデータの整合性チェック数を検証します。gss_unwrap（）は、gss_s_completeステータスと結果のoutput_messageを返すことにより、検証の成功を示します。
For purposes of this example, we assume that the server knows by out-of-band means that this context will have no further use after one protected message is transferred from client to server. Given this premise, the server now calls GSS_Delete_sec_context() to flush context-level information. Optionally, the server-side application may provide a token buffer to GSS_Delete_sec_context(), to receive a context_token to be transferred to the client in order to request that client-side context-level information be deleted.
この例の目的のために、サーバーが帯域外で知っていることは、1つの保護されたメッセージがクライアントからサーバーに転送された後、このコンテキストがこれ以上使用しないことを意味すると仮定します。この前提を考えると、サーバーはgss_delete_sec_context（）を呼び出して、コンテキストレベルの情報をフラッシュします。オプションで、サーバー側のアプリケーションは、gss_delete_sec_context（）にトークンバッファーを提供し、クライアント側のコンテキストレベルの情報を削除するように要求するために、Context_tokenをクライアントに転送するようにcontext_tokenを受信する場合があります。
If a context_token is transferred, the client passes the context_token to GSS_Process_context_token(), which returns GSS_S_COMPLETE status after deleting context-level information at the client system.
Context_Tokenが転送された場合、クライアントはContext_Tokenをgss_process_context_token（）に渡します。
The GSS-API design assumes and addresses several basic goals, including:
GSS-APIデザインは、次のようないくつかの基本的な目標を想定し、対処しています。
Mechanism independence: The GSS-API defines an interface to cryptographically implemented strong authentication and other security services at a generic level which is independent of particular underlying mechanisms. For example, GSS-API-provided services have been implemented using secret-key technologies (e.g., Kerberos, per [RFC-1964]) and with public-key approaches (e.g., SPKM, per [RFC-2025]).
メカニズムの独立性：GSS-APIは、特定の基礎となるメカニズムに依存しない一般的なレベルで、暗号化された強力な認証およびその他のセキュリティサービスへのインターフェイスを定義します。たとえば、GSS-APIを提供するサービスは、Secret-Key Technologies（例：Kerberos、[RFC-1964]）およびパブリックキーアプローチ（例：SPKM、[RFC-2025]ごと）を使用して実装されています。
Protocol environment independence: The GSS-API is independent of the communications protocol suites with which it is employed, permitting use in a broad range of protocol environments. In appropriate environments, an intermediate implementation "veneer" which is oriented to a particular communication protocol may be interposed between applications which call that protocol and the GSS-API (e.g., as defined in [RFC-2203] for Open Network Computing Remote Procedure Call (RPC)), thereby invoking GSS-API facilities in conjunction with that protocol's communications invocations.
プロトコル環境の独立性：GSS-APIは、採用されている通信プロトコルスイートとは独立しており、広範なプロトコル環境での使用を許可しています。適切な環境では、特定の通信プロトコルに向けられた中間実装「ベニヤ」は、そのプロトコルとGSS-APIを呼び出すアプリケーション（例：[RFC-2203]で定義されているオープンネットワークコンピューティングリモートプロシージャコール）を呼び出すアプリケーション間に介在する場合があります。（RPC））、それにより、そのプロトコルの通信の呼び出しと併せてGSS-API施設を呼び出します。
Protocol association independence: The GSS-API's security context construct is independent of communications protocol association constructs. This characteristic allows a single GSS-API implementation to be utilized by a variety of invoking protocol modules on behalf of those modules' calling applications. GSS-API services can also be invoked directly by applications, wholly independent of protocol associations.
プロトコル協会の独立性：GSS-APIのセキュリティコンテキスト構成は、通信プロトコルアソシエーションコンストラクトとは無関係です。この特性により、単一のGSS-API実装を、これらのモジュールの呼び出しアプリケーションに代わって、さまざまな呼び出しプロトコルモジュールによって利用されることができます。GSS-APIサービスは、プロトコル関連から完全に独立したアプリケーションによって直接呼び出されることもできます。
Suitability to a range of implementation placements: GSS-API clients are not constrained to reside within any Trusted Computing Base (TCB) perimeter defined on a system where the GSS-API is implemented; security services are specified in a manner suitable to both intra-TCB and extra-TCB callers.
さまざまな実装の配置に対する適合性：GSS-APIクライアントは、GSS-APIが実装されているシステムで定義されている信頼できるコンピューティングベース（TCB）周囲に存在するように制約されていません。セキュリティサービスは、TCB内とTCBの両方の発信者の両方に適した方法で指定されています。
1.1: GSS-API Constructs
1.1：GSS-APIコンストラクト
This section describes the basic elements comprising the GSS-API.
このセクションでは、GSS-APIを含む基本要素について説明します。
1.1.1: Credentials
1.1.1：資格情報
1.1.1.1: Credential Constructs and Concepts
1.1.1.1：資格情報の構成と概念
Credentials provide the prerequisites which permit GSS-API peers to establish security contexts with each other. A caller may designate that the credential elements which are to be applied for context initiation or acceptance be selected by default. Alternately, those GSS-API callers which need to make explicit selection of particular credentials structures may make references to those credentials through GSS-API-provided credential handles ("cred_handles"). In all cases, callers' credential references are indirect, mediated by GSS-API implementations and not requiring callers to access the selected credential elements.
資格情報は、GSS-APIのピアが互いにセキュリティコンテキストを確立できるようにする前提条件を提供します。発信者は、デフォルトでコンテキストの開始または受け入れに適用される資格要素を選択することを指定する場合があります。あるいは、特定の資格情報構造の明示的な選択を行う必要があるGSS-API発信者は、GSS-APIが提供する資格情報（ "cred_handles"）を介してそれらの資格情報に言及する場合があります。すべての場合において、発信者の資格的参照は間接的であり、GSS-APIの実装によって媒介され、選択した資格情報要素にアクセスすることを発信者に要求しません。
A single credential structure may be used to initiate outbound contexts and to accept inbound contexts. Callers needing to operate in only one of these modes may designate this fact when credentials are acquired for use, allowing underlying mechanisms to optimize their processing and storage requirements. The credential elements defined by a particular mechanism may contain multiple cryptographic keys, e.g., to enable authentication and message encryption to be performed with different algorithms.
単一の資格構造を使用して、アウトバウンドコンテキストを開始し、インバウンドコンテキストを受け入れることができます。これらのモードの1つのみで動作する必要がある発信者は、資格情報が使用された場合にこの事実を指定し、基礎となるメカニズムが処理要件とストレージ要件を最適化できるようにすることができます。特定のメカニズムによって定義された資格要素には、複数の暗号化キーが含まれている場合があります。たとえば、異なるアルゴリズムで認証とメッセージの暗号化を実行できるようにします。
A GSS-API credential structure may contain multiple credential elements, each containing mechanism-specific information for a particular underlying mechanism (mech_type), but the set of elements within a given credential structure represent a common entity. A credential structure's contents will vary depending on the set of mech_types supported by a particular GSS-API implementation. Each credential element identifies the data needed by its mechanism in order to establish contexts on behalf of a particular principal, and may contain separate credential references for use in context initiation and context acceptance. Multiple credential elements within a given credential having overlapping combinations of mechanism, usage mode, and validity period are not permitted.
GSS-API資格構造には、特定の基礎となるメカニズム（MECH_TYPE）のメカニズム固有の情報を含む複数の資格要素を含む場合がありますが、特定の資格構造内の要素のセットは共通のエンティティを表します。資格構造のコンテンツは、特定のGSS-API実装によってサポートされるMECH_TYPESのセットによって異なります。各資格要素は、特定のプリンシパルに代わってコンテキストを確立するためにそのメカニズムに必要なデータを識別し、コンテキストの開始とコンテキストの受け入れで使用するための個別の資格的参照を含めることができます。メカニズム、使用モード、および妥当性期間の重複する組み合わせを持つ特定の資格情報内の複数の資格要素は許可されていません。
Commonly, a single mech_type will be used for all security contexts established by a particular initiator to a particular target. A major motivation for supporting credential sets representing multiple mech_types is to allow initiators on systems which are equipped to handle multiple types to initiate contexts to targets on other systems which can accommodate only a subset of the set supported at the initiator's system.
一般的に、特定のイニシエーターによって特定のターゲットに確立されたすべてのセキュリティコンテキストに、単一のmech_typeが使用されます。複数のMech_Typesを表す資格情報セットをサポートする主な動機は、複数のタイプを処理できるシステム上のイニシエーターを、イニシエーターシステムでサポートされているセットのサブセットのみに対応できる他のシステムのターゲットにコンテキストを開始するようにすることです。
1.1.1.2: Credential Management
1.1.1.2：資格管理
It is the responsibility of underlying system-specific mechanisms and OS functions below the GSS-API to ensure that the ability to acquire and use credentials associated with a given identity is constrained to appropriate processes within a system. This responsibility should be taken seriously by implementors, as the ability for an entity to utilize a principal's credentials is equivalent to the entity's ability to successfully assert that principal's identity.
これは、GSS-APIの下の基礎となるシステム固有のメカニズムとOS機能の責任であり、特定のIDに関連する資格情報を取得および使用する能力が、システム内の適切なプロセスに制約されることを保証します。エンティティがプリンシパルの資格情報を利用する能力は、プリンシパルのアイデンティティを成功裏に主張するエンティティの能力と同等であるため、この責任は実装者に真剣に受け止められるべきです。
Once a set of GSS-API credentials is established, the transferability of that credentials set to other processes or analogous constructs within a system is a local matter, not defined by the GSS-API. An example local policy would be one in which any credentials received as a result of login to a given user account, or of delegation of rights to that account, are accessible by, or transferable to, processes running under that account.
GSS-API資格情報のセットが確立されると、システム内の他のプロセスまたは類似の構成要素に設定されたその資格情報の転送可能性は、GSS-APIによって定義されていないローカルな問題です。現地ポリシーの例は、特定のユーザーアカウントへのログインの結果として受け取った資格情報、またはそのアカウントへの権利の委任の結果として、そのアカウントの下で実行されているプロセスがアクセスできる、または譲渡可能なものです。
The credential establishment process (particularly when performed on behalf of users rather than server processes) is likely to require access to passwords or other quantities which should be protected locally and exposed for the shortest time possible. As a result, it will often be appropriate for preliminary credential establishment to be performed through local means at user login time, with the result(s) cached for subsequent reference. These preliminary credentials would be set aside (in a system-specific fashion) for subsequent use, either:
資格設定プロセス（特にサーバープロセスではなくユーザーに代わって実行される場合）は、ローカルで保護し、可能な限り短期間露出するパスワードまたはその他の数量へのアクセスを必要とする可能性があります。その結果、多くの場合、ユーザーログイン時間に現地の手段を通じて実行される予備資格設立が適切であり、結果は後続の参照のためにキャッシュされます。これらの予備的な資格情報は、次の使用のために（システム固有の方法で）脇に置かれます。
to be accessed by an invocation of the GSS-API GSS_Acquire_cred() call, returning an explicit handle to reference that credential
GSS-API GSS_ACQUIRE_CRED（）呼び出しの呼び出しによってアクセスするには、その資格情報を参照するために明示的なハンドルを返します
to comprise default credential elements to be installed, and to be used when default credential behavior is requested on behalf of a process
インストールするデフォルトの資格情報要素を含み、プロセスに代わってデフォルトの資格情報の動作が要求されるときに使用する
1.1.1.3: Default Credential Resolution
1.1.1.3：デフォルトの資格情報の解決
The GSS_Init_sec_context() and GSS_Accept_sec_context() routines allow the value GSS_C_NO_CREDENTIAL to be specified as their credential handle parameter. This special credential handle indicates a desire by the application to act as a default principal. In support of application portability, support for the default resolution behavior described below for initiator credentials (GSS_Init_sec_context() usage) is mandated; support for the default resolution behavior described below for acceptor credentials (GSS_Accept_sec_context() usage) is recommended. If default credential resolution fails, GSS_S_NO_CRED status is to be returned.
GSS_INIT_SEC_CONTEXT（）およびGSS_ACCEPT_SEC_CONTEXT（）ルーチンにより、値GSS_C_NO_CREDENTIALを資格情報ハンドルパラメーターとして指定することができます。この特別な資格情報は、デフォルトのプリンシパルとして機能するというアプリケーションによる欲求を示しています。アプリケーションの移植性をサポートするために、initiatator資格情報（gss_init_sec_context（）usage）の以下で説明するデフォルトの解決策のサポートが義務付けられています。Accedor資格情報（gss_accept_sec_context（）usage）の以下で説明するデフォルトの解決策のサポートが推奨されます。デフォルトの資格情報の解像度が失敗した場合、GSS_S_NO_CREDステータスを返します。
GSS_Init_sec_context:
gss_init_sec_context：
(i) If there is only a single principal capable of initiating security contexts that the application is authorized to act on behalf of, then that principal shall be used, otherwise (ii) If the platform maintains a concept of a default network-identity, and if the application is authorized to act on behalf of that identity for the purpose of initiating security contexts, then the principal corresponding to that identity shall be used, otherwise
(i) アプリケーションに代わって行動することが許可されているセキュリティコンテキストを開始できる単一のプリンシパルがある場合、そのプリンシパルを使用するものとします。申請は、セキュリティコンテキストを開始する目的でそのアイデンティティに代わって行動することが許可されている場合、そのアイデンティティに対応する校長が使用されます。
(iii) If the platform maintains a concept of a default local identity, and provides a means to map local identities into network-identities, and if the application is authorized to act on behalf of the network-identity image of the default local identity for the purpose of initiating security contexts, then the principal corresponding to that identity shall be used, otherwise
（iii）プラットフォームがデフォルトのローカルIDの概念を維持し、ローカルアイデンティティをネットワークアイデンティティにマッピングする手段を提供し、アプリケーションがデフォルトのローカルIDのネットワークアイデンティティイメージに代わって行動することを許可されている場合セキュリティコンテキストを開始する目的、その後、そのアイデンティティに対応するプリンシパルが使用されます。
(iv) A user-configurable default identity should be used.
（iv）ユーザー構成可能なデフォルトIDを使用する必要があります。
GSS_Accept_sec_context:
gss_accept_sec_context：
(i) If there is only a single authorized principal identity capable of accepting security contexts, then that principal shall be used, otherwise
(i) セキュリティのコンテキストを受け入れることができる単一の承認された校長IDのみがある場合、その校長は使用されます。
(ii) If the mechanism can determine the identity of the target principal by examining the context-establishment token, and if the accepting application is authorized to act as that principal for the purpose of accepting security contexts, then that principal identity shall be used, otherwise
（ii）コンテキスト確立トークンを調べてメカニズムがターゲットプリンシパルのアイデンティティを決定できる場合、および受容アプリケーションがセキュリティコンテキストを受け入れる目的でそのプリンシパルとして行動することを許可されている場合、そのプリンシパルアイデンティティを使用するものとします。さもないと
(iii) If the mechanism supports context acceptance by any principal, and mutual authentication was not requested, any principal that the application is authorized to accept security contexts under may be used, otherwise
（iii）メカニズムが元本によるコンテキストの受け入れをサポートし、相互認証が要求されなかった場合、アプリケーションが使用されているセキュリティコンテキストを受け入れることを許可されているプリンシパル、そうでなければ使用することができます。
(iv) A user-configurable default identity shall be used.
（iv）ユーザー構成可能なデフォルトIDを使用するものとします。
The purpose of the above rules is to allow security contexts to be established by both initiator and acceptor using the default behavior wherever possible. Applications requesting default behavior are likely to be more portable across mechanisms and platforms than those that use GSS_Acquire_cred() to request a specific identity.
上記のルールの目的は、可能な限りデフォルトの動作を使用して、イニシエーターとアクセプターの両方によってセキュリティコンテキストを確立できるようにすることです。デフォルトの動作を要求するアプリケーションは、特定のIDを要求するためにGSS_ACQUIRE_CRED（）を使用したものよりも、メカニズムやプラットフォーム間でよりポータブルである可能性があります。
1.1.2: Tokens
1.1.2：トークン
Tokens are data elements transferred between GSS-API callers, and are divided into two classes. Context-level tokens are exchanged in order to establish and manage a security context between peers. Per-message tokens relate to an established context and are exchanged to provide protective security services (i.e., data origin authentication, integrity, and optional confidentiality) for corresponding data messages.
トークンは、GSS-API発信者間で転送されるデータ要素であり、2つのクラスに分割されます。コンテキストレベルのトークンは、ピア間のセキュリティコンテキストを確立および管理するために交換されます。メッセージごとのトークンは、確立されたコンテキストに関連しており、対応するデータメッセージに対して保護セキュリティサービス（つまり、データオリジン認証、整合性、およびオプションの機密性）を提供するために交換されます。
The first context-level token obtained from GSS_Init_sec_context() is required to indicate at its very beginning a globally-interpretable mechanism identifier, i.e., an Object Identifier (OID) of the security mechanism. The remaining part of this token as well as the whole content of all other tokens are specific to the particular underlying mechanism used to support the GSS-API. Section 3.1 of this document provides, for designers of GSS-API mechanisms, the description of the header of the first context-level token which is then followed by mechanism-specific information.
GSS_INIT_SEC_CONTEXT（）から取得した最初のコンテキストレベルトークンは、グローバルに解釈可能なメカニズム識別子、つまりセキュリティメカニズムのオブジェクト識別子（OID）を示すために必要です。このトークンの残りの部分と他のすべてのトークンのコンテンツ全体は、GSS-APIをサポートするために使用される特定の基礎メカニズムに固有です。このドキュメントのセクション3.1は、GSS-APIメカニズムの設計者に、最初のコンテキストレベルトークンのヘッダーの説明を提供し、その後メカニズム固有の情報が続きます。
Tokens' contents are opaque from the viewpoint of GSS-API callers. They are generated within the GSS-API implementation at an end system, provided to a GSS-API caller to be transferred to the peer GSS-API caller at a remote end system, and processed by the GSS-API implementation at that remote end system.
トークンの内容は、GSS-API発信者の観点からの不透明です。それらは、リモートエンドシステムでピアGSS-API発信者に転送され、そのリモートエンドシステムでのGSS-API実装によって処理されるためにGSS-API発信者に提供されるEndシステムでGSS-API実装内で生成されます。
Context-level tokens may be output by GSS-API calls (and should be transferred to GSS-API peers) whether or not the calls' status indicators indicate successful completion. Per-message tokens, in contrast, are to be returned only upon successful completion of per-message calls. Zero-length tokens are never returned by GSS routines for transfer to a peer. Token transfer may take place in an in-band manner, integrated into the same protocol stream used by the GSS-API callers for other data transfers, or in an out-of-band manner across a logically separate channel.
コンテキストレベルのトークンは、GSS-API呼び出しによって出力される場合があります（およびGSS-APIピアに転送する必要があります）。「ステータスインジケーターが正常に完了したことを示すかどうかがあります。対照的に、メッセージごとのトークンは、メッセージごとの呼び出しが正常に完了したときにのみ返されます。ゼロ長のトークンは、ピアへの転送のためにGSSルーチンによって返されることはありません。トークン転送は、GSS-API発信者が他のデータ転送に使用するのと同じプロトコルストリームに統合された、または論理的に個別のチャネル全体で帯域外で統合され、帯域内で行われる場合があります。
Different GSS-API tokens are used for different purposes (e.g., context initiation, context acceptance, protected message data on an established context), and it is the responsibility of a GSS-API caller receiving tokens to distinguish their types, associate them with corresponding security contexts, and pass them to appropriate GSS-API processing routines. Depending on the caller protocol environment, this distinction may be accomplished in several ways.
異なるGSS-APIトークンは、さまざまな目的（例：コンテキストの開始、コンテキスト受け入れ、確立されたコンテキストに関する保護されたメッセージデータ）に使用され、それはタイプを区別するためのトークンを受け取るGSS-API発信者の責任であり、対応するものと関連付けますセキュリティコンテキスト、およびそれらを適切なGSS-API処理ルーチンに渡します。発信者のプロトコル環境に応じて、この区別はいくつかの方法で達成される場合があります。
The following examples illustrate means through which tokens' types may be distinguished:
次の例は、トークンのタイプが区別される可能性のある手段を示しています。
- implicit tagging based on state information (e.g., all tokens on a new association are considered to be context establishment tokens until context establishment is completed, at which point all tokens are considered to be wrapped data objects for that context),
- 状態情報に基づいた暗黙のタグ付け（たとえば、新しい関連付けのすべてのトークンは、コンテキスト確立が完了するまでコンテキスト確立トークンと見なされます。
- explicit tagging at the caller protocol level,
- 発信者プロトコルレベルでの明示的なタグ付け、
- a hybrid of these approaches.
- これらのアプローチのハイブリッド。
Commonly, the encapsulated data within a token includes internal mechanism-specific tagging information, enabling mechanism-level processing modules to distinguish tokens used within the mechanism for different purposes. Such internal mechanism-level tagging is recommended to mechanism designers, and enables mechanisms to determine whether a caller has passed a particular token for processing by an inappropriate GSS-API routine.
一般的に、トークン内のカプセル化されたデータには、内部メカニズム固有のタグ付け情報が含まれ、メカニズムレベルの処理モジュールがさまざまな目的でメカニズム内で使用されるトークンを区別できるようにします。このような内部メカニズムレベルのタグ付けは、メカニズム設計者に推奨され、メカニズムが不適切なGSS-APIルーチンによって処理のために特定のトークンに合格したかどうかを決定できるようにします。
Development of GSS-API mechanisms based on a particular underlying cryptographic technique and protocol (i.e., conformant to a specific GSS-API mechanism definition) does not necessarily imply that GSS-API callers using that GSS-API mechanism will be able to interoperate with peers invoking the same technique and protocol outside the GSS-API paradigm, or with peers implementing a different GSS-API mechanism based on the same underlying technology. The format of GSS-API tokens defined in conjunction with a particular mechanism, and the techniques used to integrate those tokens into callers' protocols, may not be interoperable with the tokens used by non-GSS-API callers of the same underlying technique.
特定の基礎となる暗号化技術とプロトコル（つまり、特定のGSS-APIメカニズム定義に準拠する）に基づくGSS-APIメカニズムの開発は、GSS-APIメカニズムを使用してGSS-API発信者がピアと交流できることを必ずしも意味するものではありません。GSS-APIパラダイムの外側の同じ手法とプロトコルを呼び出すか、同じ基礎技術に基づいて異なるGSS-APIメカニズムを実装するピアを使用します。特定のメカニズムと組み合わせて定義されたGSS-APIトークンの形式と、これらのトークンを発信者のプロトコルに統合するために使用される手法は、同じ基礎技術の非GSS-API発信者が使用するトークンと相互運用できない場合があります。
1.1.3: Security Contexts
1.1.3：セキュリティコンテキスト
Security contexts are established between peers, using credentials established locally in conjunction with each peer or received by peers via delegation. Multiple contexts may exist simultaneously between a pair of peers, using the same or different sets of credentials. Coexistence of multiple contexts using different credentials allows graceful rollover when credentials expire. Distinction among multiple contexts based on the same credentials serves applications by distinguishing different message streams in a security sense.
セキュリティのコンテキストは、ピアと局所的に確立された資格情報を使用して、代表団を介してピアが受け取った資格を使用して、ピア間で確立されます。同じまたは異なる資格情報セットを使用して、ピアのペア間で複数のコンテキストが同時に存在する場合があります。異なる資格情報を使用した複数のコンテキストの共存により、資格情報が期限切れになると優雅なロールオーバーが可能になります。同じ資格情報に基づいた複数のコンテキスト間の区別は、セキュリティの意味で異なるメッセージストリームを区別することにより、アプリケーションにサービスを提供します。
The GSS-API is independent of underlying protocols and addressing structure, and depends on its callers to transport GSS-API-provided data elements. As a result of these factors, it is a caller responsibility to parse communicated messages, separating GSS-API-related data elements from caller-provided data. The GSS-API is independent of connection vs. connectionless orientation of the underlying communications service.
GSS-APIは、基礎となるプロトコルとアドレス指定構造から独立しており、GSS-APIが提供するデータ要素を輸送するために発信者に依存しています。これらの要因の結果として、通信されたメッセージを解析し、GSS-API関連のデータ要素を発信者が提供するデータから分離することは発信者の責任です。GSS-APIは、基礎となる通信サービスの接続とコネクションレスオリエンテーションとは無関係です。
No correlation between security context and communications protocol association is dictated. (The optional channel binding facility, discussed in Section 1.1.6 of this document, represents an intentional exception to this rule, supporting additional protection features within GSS-API supporting mechanisms.) This separation allows the GSS-API to be used in a wide range of communications environments, and also simplifies the calling sequences of the individual calls. In many cases (depending on underlying security protocol, associated mechanism, and availability of cached information), the state information required for context setup can be sent concurrently with initial signed user data, without interposing additional message exchanges. Messages may be protected and transferred in both directions on an established GSS-API security context concurrently; protection of messages in one direction does not interfere with protection of messages in the reverse direction.
セキュリティコンテキストと通信プロトコルアソシエーションの間に相関関係は決定されていません。（このドキュメントのセクション1.1.6で説明されているオプションのチャネル結合施設は、この規則の意図的な例外を表しており、GSS-APIサポートメカニズム内の追加の保護機能をサポートしています。）この分離により、GSS-APIを広く使用できます。通信環境の範囲、および個々の呼び出しの呼び出しシーケンスを簡素化します。多くの場合（基礎となるセキュリティプロトコル、関連するメカニズム、およびキャッシュされた情報の可用性に応じて）、コンテキストのセットアップに必要な状態情報は、追加のメッセージ交換を挿入することなく、初期署名されたユーザーデータと同時に送信できます。メッセージは、確立されたGSS-APIセキュリティコンテキストの両方の方向に保護および転送される場合があります。一方向のメッセージの保護は、逆方向のメッセージの保護を妨げません。
GSS-API implementations are expected to retain inquirable context data on a context until the context is released by a caller, even after the context has expired, although underlying cryptographic data elements may be deleted after expiration in order to limit their exposure.
GSS-APIの実装は、コンテキストの有効期限が切れた後でも、コンテキストが発信者によってリリースされるまで、コンテキスト上の問い合わせコンテキストデータを保持することが期待されていますが、露出を制限するために、根本的な暗号化データ要素は有効期限の後に削除される場合があります。
1.1.4: Mechanism Types
1.1.4：メカニズムの種類
In order to successfully establish a security context with a target peer, it is necessary to identify an appropriate underlying mechanism type (mech_type) which both initiator and target peers support. The definition of a mechanism embodies not only the use of a particular cryptographic technology (or a hybrid or choice among alternative cryptographic technologies), but also definition of the syntax and semantics of data element exchanges which that mechanism will employ in order to support security services.
ターゲットピアでセキュリティコンテキストを正常に確立するには、イニシエーターとターゲットピアの両方のサポートの両方の適切な基礎メカニズムタイプ（MECH_TYPE）を特定する必要があります。メカニズムの定義は、特定の暗号技術（または代替暗号化技術の間でハイブリッドまたは選択）の使用だけでなく、セキュリティサービスをサポートするためにそのメカニズムが採用するデータ要素交換の構文とセマンティクスの定義も具体化します。。
It is recommended that callers initiating contexts specify the "default" mech_type value, allowing system-specific functions within or invoked by the GSS-API implementation to select the appropriate mech_type, but callers may direct that a particular mech_type be employed when necessary.
コンテキストを開始する発信者は、「デフォルト」mech_type値を指定し、GSS-API実装によってシステム固有の機能を許可して適切なmech_typeを選択することをお勧めしますが、必要に応じて特定のmech_typeを使用することをお勧めします。
For GSS-API purposes, the phrase "negotiating mechanism" refers to a mechanism which itself performs negotiation in order to select a concrete mechanism which is shared between peers and is then used for context establishment. Only those mechanisms which are defined in their specifications as negotiating mechanisms are to yield selected mechanisms with different identifier values than the value which is input by a GSS-API caller, except for the case of a caller requesting the "default" mech_type.
GSS-APIの目的では、「交渉メカニズム」というフレーズとは、ピア間で共有され、コンテキスト確立に使用される具体的なメカニズムを選択するために、それ自体が交渉を実行するメカニズムを指します。交渉メカニズムとして仕様で定義されているメカニズムのみが、「デフォルト」mech_typeを要求する発信者の場合を除き、GSS-API発信者が入力する値とは異なる識別子値を持つ選択されたメカニズムを生成することです。
The means for identifying a shared mech_type to establish a security context with a peer will vary in different environments and circumstances; examples include (but are not limited to):
共有されたmech_typeを識別して、ピアでセキュリティコンテキストを確立するための手段は、環境や状況によって異なります。例には（ただし、これらに限定されない）が含まれます。
use of a fixed mech_type, defined by configuration, within an environment
環境内で、構成によって定義された固定mech_typeの使用
syntactic convention on a target-specific basis, through examination of a target's name lookup of a target's name in a naming service or other database in order to identify mech_types supported by that target
そのターゲットでサポートされているmech_typesを識別するために、ネーミングサービスまたはその他のデータベースでターゲットの名前をターゲットの名前のルックアップを調べることにより、ターゲット固有の構文条約をターゲット固有の慣習
explicit negotiation between GSS-API callers in advance of security context setup
セキュリティコンテキストセットアップの前にGSS-API発信者間の明示的な交渉
use of a negotiating mechanism
交渉メカニズムの使用
When transferred between GSS-API peers, mech_type specifiers (per Section 3 of this document, represented as Object Identifiers (OIDs)) serve to qualify the interpretation of associated tokens. (The structure and encoding of Object Identifiers is defined in [ISOIEC-8824] and [ISOIEC-8825].) Use of hierarchically structured OIDs serves to preclude ambiguous interpretation of mech_type specifiers. The OID representing the DASS ([RFC-1507]) MechType, for example, is 1.3.12.2.1011.7.5, and that of the Kerberos V5 mechanism ([RFC-1964]), having been advanced to the level of Proposed Standard, is 1.2.840.113554.1.2.2.
GSS-APIピア間で転送されると、MECH_TYPE仕様（このドキュメントのセクション3によると、オブジェクト識別子（OID）として表されます）は、関連するトークンの解釈を修飾するのに役立ちます。（オブジェクト識別子の構造とエンコーディングは、[ISOIEC-8824]および[ISOIEC-8825]で定義されています。）階層構造化されたOIDの使用は、mech_type仕様の曖昧な解釈を排除するのに役立ちます。たとえば、DASS（[rfc-1507]）mechtypeを表すoidは1.3.12.2.1011.7.5であり、Kerberos v5メカニズム（[RFC-1964]）のそれは、提案された標準のレベルまで進歩しています。、IS 1.2.840.113554.1.2.2。
1.1.5: Naming
1.1.5：命名
The GSS-API avoids prescribing naming structures, treating the names which are transferred across the interface in order to initiate and accept security contexts as opaque objects. This approach supports the GSS-API's goal of implementability atop a range of underlying security mechanisms, recognizing the fact that different mechanisms process and authenticate names which are presented in different forms. Generalized services offering translation functions among arbitrary sets of naming environments are outside the scope of the GSS-API; availability and use of local conversion functions to translate among the naming formats supported within a given end system is anticipated.
GSS-APIは、セキュリティコンテキストを不透明なオブジェクトとして開始および受け入れるために、インターフェイス全体で転送される名前を扱う命名構造の処方を避けます。このアプローチは、さまざまなメカニズムが異なる形式で提示される名前を処理および認証するという事実を認識して、基礎となるセキュリティメカニズムの範囲でGSS-APIの目標をサポートしています。命名環境の任意のセット間の翻訳機能を提供する一般化されたサービスは、GSS-APIの範囲外です。特定のエンドシステム内でサポートされている命名形式間で翻訳するためのローカル変換関数の可用性と使用が予想されます。
Different classes of name representations are used in conjunction with different GSS-API parameters:
さまざまなクラスの名前表現が、さまざまなGSS-APIパラメーターと組み合わせて使用されます。
- Internal form (denoted in this document by INTERNAL NAME), opaque to callers and defined by individual GSS-API implementations. GSS-API implementations supporting multiple namespace types must maintain internal tags to disambiguate the interpretation of particular names. A Mechanism Name (MN) is a special case of INTERNAL NAME, guaranteed to contain elements corresponding to one and only one mechanism; calls which are guaranteed to emit MNs or which require MNs as input are so identified within this specification.
- 内部フォーム（このドキュメントでは内部名で示されています）、発信者に不透明で、個々のGSS-API実装によって定義されています。複数の名前空間タイプをサポートするGSS-API実装は、特定の名前の解釈を明確にするために内部タグを維持する必要があります。メカニズム名（MN）は内部名の特別なケースであり、1つのメカニズムのみに対応する要素を含むことが保証されています。この仕様内で、MNSを放出することが保証されている、または入力としてMNSを必要とする呼び出しがそのように識別されます。
- Contiguous string ("flat") form (denoted in this document by OCTET STRING); accompanied by OID tags identifying the namespace to which they correspond. Depending on tag value, flat names may or may not be printable strings for direct acceptance from and presentation to users. Tagging of flat names allows GSS-API callers and underlying GSS-API mechanisms to disambiguate name types and to determine whether an associated name's type is one which they are capable of processing, avoiding aliasing problems which could result from misinterpreting a name of one type as a name of another type.
- 隣接する文字列（ "flat"）フォーム（Octet stringでこのドキュメントで示されています）;OIDタグが添付されており、対応する名前空間を識別します。タグ値に応じて、フラット名は、ユーザーから直接受け入れてプレゼンテーションを行うための印刷可能な文字列である場合とそうでない場合があります。フラット名のタグ付けにより、GSS-API発信者と基礎となるGSS-APIメカニズムが名前のタイプを明確にし、関連する名前のタイプが処理できるかどうかを判断することができます。別のタイプの名前。
- The GSS-API Exported Name Object, a special case of flat name designated by a reserved OID value, carries a canonicalized form of a name suitable for binary comparisons.
- GSS-APIエクスポート名オブジェクトは、予約されたOID値によって指定されたフラット名の特殊なケースであり、バイナリ比較に適した名前の標準化された形式を搭載しています。
In addition to providing means for names to be tagged with types, this specification defines primitives to support a level of naming environment independence for certain calling applications. To provide basic services oriented towards the requirements of callers which need not themselves interpret the internal syntax and semantics of names, GSS-API calls for name comparison (GSS_Compare_name()), human-readable display (GSS_Display_name()), input conversion (GSS_Import_name()), internal name deallocation (GSS_Release_name()), and internal name duplication (GSS_Duplicate_name()) functions are defined. (It is anticipated that these proposed GSS-API calls will be implemented in many end systems based on system-specific name manipulation primitives already extant within those end systems; inclusion within the GSS-API is intended to offer GSS-API callers a portable means to perform specific operations, supportive of authorization and audit requirements, on authenticated names.)
この仕様では、名前をタイプでタグ付けする手段を提供することに加えて、特定の呼び出しアプリケーションの命名環境の独立性のレベルをサポートするプリミティブを定義します。GSS-APIは、それ自体が内部構文と名前のセマンティクスを解釈する必要はない発信者の要件に向けた基本サービスを提供するために、名前の比較（gss_compare_name（））、人間の読み取り可能なディスプレイ（gss_display_name（）、入力変換（gss_import_name（gss_import_name）を呼びます。（））、内部名deallocation（gss_release_name（））、およびinternal name duplication（gss_duplicate_name（））関数が定義されています。（これらの提案されたGSS-API呼び出しは、これらの最終システム内にすでに現存するシステム固有の名前操作プリミティブに基づいて、多くのエンドシステムに実装されると予想されます。GSS-API内に含めることは、GSS-API発信者にポータブル手段を提供することを目的としています。認証された名前で、特定の運用、承認要件と監査要件を支援することを実行します。
GSS_Import_name() implementations can, where appropriate, support more than one printable syntax corresponding to a given namespace (e.g., alternative printable representations for X.500 Distinguished Names), allowing flexibility for their callers to select among alternative representations. GSS_Display_name() implementations output a printable syntax selected as appropriate to their operational environments; this selection is a local matter. Callers desiring portability across alternative printable syntaxes should refrain from implementing comparisons based on printable name forms and should instead use the GSS_Compare_name() call to determine whether or not one internal-format name matches another.
GSS_IMPORT_NAME（）実装は、必要に応じて、特定の名前空間に対応する複数の印刷可能な構文（X.500の著名な名前の代替印刷可能な表現）をサポートすることができ、発信者が代替表現から選択できるようにすることができます。gss_display_name（）実装は、動作環境に適切に選択された印刷可能な構文を出力します。この選択は地元の問題です。代替の印刷可能な構文全体での移植性を希望する発信者は、印刷可能な名前フォームに基づいて比較の実装を控える必要があり、代わりにGSS_compare_name（）呼び出しを使用して、1つの内部形式名が別のものと一致するかどうかを判断する必要があります。
When used in large access control lists, the overhead of invoking GSS_Import_name() and GSS_Compare_name() on each name from the ACL may be prohibitive. As an alternative way of supporting this case, GSS-API defines a special form of the contiguous string name which may be compared directly (e.g., with memcmp()). Contiguous names suitable for comparison are generated by the GSS_Export_name() routine, which requires an MN as input. Exported names may be re-imported by the GSS_Import_name() routine, and the resulting internal name will also be an MN. The symbolic constant GSS_C_NT_EXPORT_NAME identifies the "export name" type. Structurally, an exported name object consists of a header containing an OID identifying the mechanism that authenticated the name, and a trailer containing the name itself, where the syntax of the trailer is defined by the individual mechanism specification. The precise format of an exported name is defined in Section 3.2 of this specification.
大規模なアクセス制御リストで使用する場合、ACLの各名前でGSS_IMPORT_NAME（）およびGSS_Compare_Name（）を呼び出すオーバーヘッドは法外な場合があります。このケースをサポートする別の方法として、GSS-APIは、直接比較できる隣接する文字列名の特別な形式を定義します（例：memcmp（））。比較に適した隣接する名前は、gss_export_name（）ルーチンによって生成されます。これには、入力としてMNが必要です。エクスポートされた名前はGSS_IMPORT_NAME（）ルーチンによって再インポートされる場合があり、結果の内部名もMNになります。シンボリック定数GSS_C_NT_EXPORT_NAMEは、「エクスポート名」タイプを識別します。構造的には、エクスポートされた名前オブジェクトは、名前を認証するメカニズムを識別するOIDを含むヘッダーと、名前自体を含むトレーラーで構成されています。トレーラーの構文は個々のメカニズム仕様によって定義されます。エクスポートされた名前の正確な形式は、この仕様のセクション3.2で定義されています。
Note that the results obtained by using GSS_Compare_name() will in general be different from those obtained by invoking GSS_Canonicalize_name() and GSS_Export_name(), and then comparing the exported names. The first series of operations determines whether two (unauthenticated) names identify the same principal; the second whether a particular mechanism would authenticate them as the same principal. These two operations will in general give the same results only for MNs.
gss_compare_name（）を使用して得られた結果は、一般にgss_canonicalize_name（）およびgss_export_name（）を呼び出して取得した結果とは異なることに注意してください。最初の一連の操作は、2つの（認証されていない）名前が同じプリンシパルを識別するかどうかを決定します。2番目は、特定のメカニズムがそれらを同じプリンシパルとして認証するかどうか。これらの2つの操作は、一般にMNSでのみ同じ結果をもたらします。
The following diagram illustrates the intended dataflow among name-related GSS-API processing routines.
次の図は、名前関連GSS-API処理ルーチン間の意図したデータフローを示しています。
GSS-API library defaults
|
|
V text, for
text --------------> internal_name (IN) -----------> display only
import_name() / display_name()
/
/
/
accept_sec_context() /
| /
| /
| / canonicalize_name()
| /
| /
| /
| /
| /
| |
V V <---------------------
single mechanism import_name() exported name: flat
internal_name (MN) binary "blob" usable
----------------------> for access control
export_name()
1.1.6: Channel Bindings
1.1.6：チャネルバインディング
The GSS-API accommodates the concept of caller-provided channel binding ("chan_binding") information. Channel bindings are used to strengthen the quality with which peer entity authentication is provided during context establishment, by limiting the scope within which an intercepted context establishment token can be reused by an attacker. Specifically, they enable GSS-API callers to bind the establishment of a security context to relevant characteristics (e.g., addresses, transformed representations of encryption keys) of the underlying communications channel, of protection mechanisms applied to that communications channel, and to application-specific data.
GSS-APIは、発信者が提供するチャネル結合（「Chan_binding」）情報の概念に対応します。チャネルバインディングは、コンテキスト確立中にピアエンティティ認証が提供される品質を強化するために使用されます。これは、攻撃者が傍受されたコンテキスト確立トークンを再利用できる範囲を制限します。具体的には、GSS-API発信者は、基礎となる通信チャネルの関連特性（例えば、アドレス、暗号化キーのアドレス、変換された表現）、その通信チャネルに適用される保護メカニズム、およびアプリケーション固有のアプリケーション固有に結合することを可能にします。データ。
The caller initiating a security context must determine the appropriate channel binding values to provide as input to the GSS_Init_sec_context() call, and consistent values must be provided to GSS_Accept_sec_context() by the context's target, in order for both peers' GSS-API mechanisms to validate that received tokens possess correct channel-related characteristics. Use or non-use of the GSS-API channel binding facility is a caller option. GSS-API mechanisms can operate in an environment where NULL channel bindings are presented; mechanism implementors are encouraged, but not required, to make use of caller-provided channel binding data within their mechanisms. Callers should not assume that underlying mechanisms provide confidentiality protection for channel binding information.
セキュリティコンテキストを開始する発信者は、GSS_INIT_SEC_CONTEXT（）コールへの入力として提供する適切なチャネルバインディング値を決定する必要があり、一貫した値をコンテキストのターゲットによってGSS_ACCEPT_SEC_CONTEXT（）に提供する必要があります。受信したトークンが正しいチャネル関連の特性を持っていることを検証します。GSS-APIチャネルバインディング施設の使用または不使用は、発信者オプションです。GSS-APIメカニズムは、ヌルチャネルバインディングが提示される環境で動作する可能性があります。メカニズムの実装者は、メカニズム内で発信者が提供するチャネル結合データを利用することを奨励されていますが、必要ありません。発信者は、基礎となるメカニズムがチャネル結合情報の機密保護を提供すると想定すべきではありません。
When non-NULL channel bindings are provided by callers, certain mechanisms can offer enhanced security value by interpreting the bindings' content (rather than simply representing those bindings, or integrity check values computed on them, within tokens) and will therefore depend on presentation of specific data in a defined format. To this end, agreements among mechanism implementors are defining conventional interpretations for the contents of channel binding arguments, including address specifiers (with content dependent on communications protocol environment) for context initiators and acceptors. (These conventions are being incorporated in GSS-API mechanism specifications and into the GSS-API C language bindings specification.) In order for GSS-API callers to be portable across multiple mechanisms and achieve the full security functionality which each mechanism can provide, it is strongly recommended that GSS-API callers provide channel bindings consistent with these conventions and those of the networking environment in which they operate.
発信者によって非ヌルチャネルバインディングが提供される場合、特定のメカニズムは、バインディングのコンテンツを解釈することにより（トークン内で計算された整合性チェック値を単に表すのではなく）、したがって、整合性チェック値を単に表すのではなく）を提供するため、セキュリティ値を高めることができます。定義された形式の特定のデータ。この目的のために、メカニズムの実装者間の合意は、コンテキストイニシエーターとアクセプターのアドレス仕様（コンテンツを含むコンテンツを含む）を含むチャネル結合引数の内容の従来の解釈を定義しています。（これらの規則は、GSS-APIメカニズムの仕様とGSS-API C言語バインディングの仕様に組み込まれています。）GSS-API発信者が複数のメカニズムに携帯する可能性があり、各メカニズムが提供できる完全なセキュリティ機能を実現するために、GSS-API発信者は、これらの規則とそれらが運営されているネットワーキング環境の条約と一致するチャネルバインディングを提供することを強くお勧めします。
1.2: GSS-API Features and Issues
1.2：GSS-API機能と問題
This section describes aspects of GSS-API operations, of the security services which the GSS-API provides, and provides commentary on design issues.
このセクションでは、GSS-APIが提供するセキュリティサービスのGSS-API運用の側面について説明し、設計の問題に関する解説を提供します。
1.2.1: Status Reporting and Optional Service Support
1.2.1：ステータスレポートとオプションのサービスサポート
1.2.1.1: Status Reporting
1.2.1.1：ステータスレポート
Each GSS-API call provides two status return values. Major_status values provide a mechanism-independent indication of call status (e.g., GSS_S_COMPLETE, GSS_S_FAILURE, GSS_S_CONTINUE_NEEDED), sufficient to drive normal control flow within the caller in a generic fashion. Table 1 summarizes the defined major_status return codes in tabular fashion.
各GSS-API呼び出しは、2つのステータス戻り値を提供します。Major_Status値は、コールステータス（GSS_S_Complete、GSS_S_FAILURE、GSS_S_CONTINUE_NEEDEDなど）のメカニズムに依存しない表示を提供します。表1は、定義されたMajor_Statusリターンコードを表形式でまとめたものです。
Sequencing-related informatory major_status codes (GSS_S_DUPLICATE_TOKEN, GSS_S_OLD_TOKEN, GSS_S_UNSEQ_TOKEN, and GSS_S_GAP_TOKEN) can be indicated in conjunction with either GSS_S_COMPLETE or GSS_S_FAILURE status for GSS-API per-message calls. For context establishment calls, these sequencing-related codes will be indicated only in conjunction with GSS_S_FAILURE status (never in conjunction with GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED), and, therefore, always correspond to fatal failures if encountered during the context establishment phase.
シーケンス関連の情報Major_statusコード（gss_s_duplicate_token、gss_s_old_token、gss_s_unseq_token、およびgss_s_gap_token）は、gss_s_completeまたはgs-ap-ap-ap-ap-ap-ap-ap-ap-ap-ap-ap-ap-ap-ap-ap-ap-ap-aapのいずれかと黙示的に示されます。コンテキスト設立コールの場合、これらのシーケンス関連コードは、GSS_S_FAILUREステータスと併せてのみ表示されます（GSS_S_COMPLETEまたはGSS_S_CONTINUE_NEEDEDと併用することはありません）。
Table 1: GSS-API Major Status Codes
表1：GSS-API主要なステータスコード
FATAL ERROR CODES
致命的なエラーコード
GSS_S_BAD_BINDINGS channel binding mismatch
GSS_S_BAD_MECH unsupported mechanism requested
GSS_S_BAD_NAME invalid name provided
GSS_S_BAD_NAMETYPE name of unsupported type provided
GSS_S_BAD_STATUS invalid input status selector
GSS_S_BAD_SIG token had invalid integrity check
GSS_S_BAD_MIC preferred alias for GSS_S_BAD_SIG
GSS_S_CONTEXT_EXPIRED specified security context expired
GSS_S_CREDENTIALS_EXPIRED expired credentials detected
GSS_S_DEFECTIVE_CREDENTIAL defective credential detected
GSS_S_DEFECTIVE_TOKEN defective token detected
GSS_S_FAILURE failure, unspecified at GSS-API
level
GSS_S_NO_CONTEXT no valid security context specified
GSS_S_NO_CRED no valid credentials provided
GSS_S_BAD_QOP unsupported QOP value
GSS_S_UNAUTHORIZED operation unauthorized
GSS_S_UNAVAILABLE operation unavailable
GSS_S_DUPLICATE_ELEMENT duplicate credential element requested
GSS_S_NAME_NOT_MN name contains multi-mechanism elements
INFORMATORY STATUS CODES
情報ステータスコード
GSS_S_COMPLETE normal completion
GSS_S_CONTINUE_NEEDED continuation call to routine
required
GSS_S_DUPLICATE_TOKEN duplicate per-message token
detected
GSS_S_OLD_TOKEN timed-out per-message token
detected
GSS_S_UNSEQ_TOKEN reordered (early) per-message token
detected
GSS_S_GAP_TOKEN skipped predecessor token(s)
detected
Minor_status provides more detailed status information which may include status codes specific to the underlying security mechanism. Minor_status values are not specified in this document.
Minor_Statusは、基礎となるセキュリティメカニズムに固有のステータスコードを含む、より詳細なステータス情報を提供します。このドキュメントでは、minor_status値は指定されていません。
GSS_S_CONTINUE_NEEDED major_status returns, and optional message outputs, are provided in GSS_Init_sec_context() and GSS_Accept_sec_context() calls so that different mechanisms' employment of different numbers of messages within their authentication sequences need not be reflected in separate code paths within calling applications. Instead, such cases are accommodated with sequences of continuation calls to GSS_Init_sec_context() and GSS_Accept_sec_context(). The same facility is used to encapsulate mutual authentication within the GSS-API's context initiation calls.
gss_s_s_continue_needed major_statusリターン、およびオプションのメッセージ出力はgss_init_sec_context（）およびgss_accept_sec_context（）呼び出しで提供されているため、認証シーケンス内の異なる数のメッセージの異なる数のメッセージの採用は、応用の中で個別のコードパスに反映される必要はありません。代わりに、そのようなケースは、GSS_INIT_SEC_CONTEXT（）およびGSS_ACCEPT_SEC_CONTEXT（）の一連の継続コールで対応します。同じ施設は、GSS-APIのコンテキスト開始コール内で相互認証をカプセル化するために使用されます。
For mech_types which require interactions with third-party servers in order to establish a security context, GSS-API context establishment calls may block pending completion of such third-party interactions. On the other hand, no GSS-API calls pend on serialized interactions with GSS-API peer entities. As a result, local GSS-API status returns cannot reflect unpredictable or asynchronous exceptions occurring at remote peers, and reflection of such status information is a caller responsibility outside the GSS-API.
セキュリティコンテキストを確立するためにサードパーティサーバーとの対話を必要とするMech_Typesの場合、GSS-APIコンテキストの確立コールは、そのようなサードパーティの相互作用の保留中の完了をブロックする可能性があります。一方、GSS-APIエンティティとのシリアル化された相互作用に関するGSS-APIコールは、PENDを呼び出しません。その結果、ローカルGSS-APIステータスリターンは、リモートピアで発生する予測不可能または非同期例外を反映することはできません。そのようなステータス情報を反映することは、GSS-API以外の発信者の責任です。
1.2.1.2: Optional Service Support
1.2.1.2：オプションのサービスサポート
A context initiator may request various optional services at context establishment time. Each of these services is requested by setting a flag in the req_flags input parameter to GSS_Init_sec_context().
コンテキストイニシエーターは、コンテキストの確立時間にさまざまなオプションサービスを要求する場合があります。これらの各サービスは、REQ_FLAGS入力パラメーターにGSS_INIT_SEC_CONTEXT（）にフラグを設定することにより要求されます。
The optional services currently defined are:
現在定義されているオプションのサービスは次のとおりです。
- Delegation - The (usually temporary) transfer of rights from initiator to acceptor, enabling the acceptor to authenticate itself as an agent of the initiator.
- 委任 - （通常は一時的な）イニシエーターからアクセプターへの権利の移転により、アクセプターがイニシエーターのエージェントとして認証できるようにします。
- Mutual Authentication - In addition to the initiator authenticating its identity to the context acceptor, the context acceptor should also authenticate itself to the initiator.
- 相互認証 - そのアイデンティティをコンテキストアクセプターに認証するイニシエーターに加えて、コンテキストアクセプターはイニシエーターにも認証する必要があります。
- Replay detection - In addition to providing message integrity services, GSS_GetMIC() and GSS_Wrap() should include message numbering information to enable GSS_VerifyMIC() and GSS_Unwrap() to detect if a message has been duplicated.
- リプレイ検出 - メッセージ整合性サービスの提供に加えて、gss_getmic（）およびgss_wrap（）には、gss_verifymic（）およびgss_unwrap（）を有効にするメッセージ番号情報を含める必要があります。
- Out-of-sequence detection - In addition to providing message integrity services, GSS_GetMIC() and GSS_Wrap() should include message sequencing information to enable GSS_VerifyMIC() and GSS_Unwrap() to detect if a message has been received out of sequence.
- アウトシーケンス検出 - メッセージ整合性サービスの提供に加えて、gss_getmic（）およびgss_wrap（）を含める必要があります。メッセージシーケンス情報を含めて、gss_verifymic（）およびgss_unwrap（）を有効にして、メッセージが順番に受信されたかどうかを検出します。
- Anonymous authentication - The establishment of the security context should not reveal the initiator's identity to the context acceptor.
- 匿名認証 - セキュリティコンテキストの確立は、Context Acceptorにイニシエーターの身元を明らかにするべきではありません。
- Available per-message confidentiality - requests that per-message confidentiality services be available on the context.
- 利用可能なメッセージごとの機密性 - コンテキストで利用可能な機密性サービスを利用できるように要求します。
- Available per-message integrity - requests that per-message integrity services be available on the context.
- 利用可能なメッセージごとの整合性 - メスごとの整合性サービスがコンテキストで利用可能になることを要求します。
Any currently undefined bits within such flag arguments should be ignored by GSS-API implementations when presented by an application, and should be set to zero when returned to the application by the GSS-API implementation.
このようなフラグの引数内の未定義のビットは、アプリケーションによって提示された場合、GSS-API実装によって無視される必要があり、GSS-API実装によってアプリケーションに返されるとゼロに設定する必要があります。
Some mechanisms may not support all optional services, and some mechanisms may only support some services in conjunction with others. Both GSS_Init_sec_context() and GSS_Accept_sec_context() inform the applications which services will be available from the context when the establishment phase is complete, via the ret_flags output parameter. In general, if the security mechanism is capable of providing a requested service, it should do so, even if additional services must be enabled in order to provide the requested service. If the mechanism is incapable of providing a requested service, it should proceed without the service, leaving the application to abort the context establishment process if it considers the requested service to be mandatory.
一部のメカニズムはすべてのオプションのサービスをサポートしない場合があり、一部のメカニズムは他のサービスと併せて一部のサービスのみをサポートする場合があります。gss_init_sec_context（）とgss_accept_sec_context（）の両方が、ret_flags出力パラメーターを介して、確立フェーズが完了したときにコンテキストから利用できるサービスをアプリケーションに通知します。一般に、セキュリティメカニズムが要求されたサービスを提供できる場合、要求されたサービスを提供するために追加のサービスを有効にする必要がある場合でも、そうする必要があります。メカニズムが要求されたサービスを提供できない場合は、サービスなしで進行する必要があり、要求されたサービスが必須であると考える場合、コンテキスト確立プロセスを中止するためにアプリケーションを残します。
Some mechanisms may specify that support for some services is optional, and that implementors of the mechanism need not provide it. This is most commonly true of the confidentiality service, often because of legal restrictions on the use of data-encryption, but may apply to any of the services. Such mechanisms are required to send at least one token from acceptor to initiator during context establishment when the initiator indicates a desire to use such a service, so that the initiating GSS-API can correctly indicate whether the service is supported by the acceptor's GSS-API.
一部のメカニズムは、一部のサービスのサポートがオプションであり、メカニズムの実装者がそれを提供する必要はないことを指定する場合があります。これは、多くの場合、データ暗号化の使用に関する法的制限があるため、機密性サービスに最も一般的ですが、どのサービスにも適用される場合があります。このようなメカニズムは、イニシエーターがそのようなサービスを使用したいという欲求を示している場合、コンテキスト確立中にアクセプターから開始者に少なくとも1つのトークンを送信するために必要です。。
1.2.2: Per-Message Security Service Availability
1.2.2：セキュリティごとのセキュリティサービスの可用性
When a context is established, two flags are returned to indicate the set of per-message protection security services which will be available on the context:
コンテキストが確立されると、2つのフラグが返され、コンテキストで利用可能になるメスごとの保護セキュリティサービスのセットを示します。
the integ_avail flag indicates whether per-message integrity and data origin authentication services are available the conf_avail flag indicates whether per-message confidentiality services are available, and will never be returned TRUE unless the integ_avail flag is also returned TRUE
INTEG_AVAILフラグは、メッセージごとの整合性とデータオリジン認証サービスが利用可能かどうかを示しますconf_availフラグは、integ_availフラグも返品されない限り、conf_availフラグが利用可能であるかどうかを示し、真実は返されません
GSS-API callers desiring per-message security services should check the values of these flags at context establishment time, and must be aware that a returned FALSE value for integ_avail means that invocation of GSS_GetMIC() or GSS_Wrap() primitives on the associated context will apply no cryptographic protection to user data messages.
セキュリティごとのセキュリティサービスを希望するGSS-API発信者は、コンテキストの確立時間にこれらのフラグの値を確認する必要があり、INTEG_AVAILの返された誤った値は、関連するコンテキストでのGSS_GETMIC（）またはGSS_WRAP（）のプリミティブの呼び出しを意味することに注意する必要があります。ユーザーデータメッセージに暗号化保護を適用しません。
The GSS-API per-message integrity and data origin authentication services provide assurance to a receiving caller that protection was applied to a message by the caller's peer on the security context, corresponding to the entity named at context initiation. The GSS-API per-message confidentiality service provides assurance to a sending caller that the message's content is protected from access by entities other than the context's named peer.
GSS-APIメッセージごとの整合性とデータオリジン認証サービスは、コンテキスト開始時に指定されたエンティティに対応するセキュリティコンテキストに関する発信者のピアによって保護が適用されることを受信者に保証を提供します。GSS-APIメッセージごとの機密性サービスは、メッセージのコンテンツがコンテキストの名前付きピア以外のエンティティによってアクセスから保護されていることを送信者に保証します。
The GSS-API per-message protection service primitives, as the category name implies, are oriented to operation at the granularity of protocol data units. They perform cryptographic operations on the data units, transfer cryptographic control information in tokens, and, in the case of GSS_Wrap(), encapsulate the protected data unit. As such, these primitives are not oriented to efficient data protection for stream-paradigm protocols (e.g., Telnet) if cryptography must be applied on an octet-by-octet basis.
カテゴリ名が示すように、GSS-APIのメッセージごとの保護サービスプリミティブは、プロトコルデータユニットの粒度で動作する方向に向けられています。データユニットで暗号操作を実行し、トークンで暗号制御情報を転送し、GSS_WRAP（）の場合、保護されたデータユニットをカプセル化します。そのため、これらのプリミティブは、暗号化をオクテットごとに適用する必要がある場合、ストリームパラダイムプロトコル（例：Telnet）の効率的なデータ保護を指向していません。
1.2.3: Per-Message Replay Detection and Sequencing
1.2.3：メッセージごとのリプレイの検出とシーケンス
Certain underlying mech_types offer support for replay detection and/or sequencing of messages transferred on the contexts they support. These optionally-selectable protection features are distinct from replay detection and sequencing features applied to the context establishment operation itself; the presence or absence of context-level replay or sequencing features is wholly a function of the underlying mech_type's capabilities, and is not selected or omitted as a caller option.
特定の基礎となるmech_typesは、サポートするコンテキストで転送されるメッセージのリプレイ検出および/またはシーケンスのサポートを提供します。これらのオプションの選択可能な保護機能は、コンテキスト確立運用自体に適用されるリプレイの検出およびシーケンス機能とは異なります。コンテキストレベルのリプレイまたはシーケンス機能の有無は、基礎となるmech_typeの機能の関数であり、発信者オプションとして選択または省略されていません。
The caller initiating a context provides flags (replay_det_req_flag and sequence_req_flag) to specify whether the use of per-message replay detection and sequencing features is desired on the context being established. The GSS-API implementation at the initiator system can determine whether these features are supported (and whether they are optionally selectable) as a function of the selected mechanism, without need for bilateral negotiation with the target. When enabled, these features provide recipients with indicators as a result of GSS-API processing of incoming messages, identifying whether those messages were detected as duplicates or out-of-sequence. Detection of such events does not prevent a suspect message from being provided to a recipient; the appropriate course of action on a suspect message is a matter of caller policy.
コンテキストを開始する発信者は、フラグ（REPLAY_DET_REQ_FLAGおよびSECENCE_REQ_FLAG）を提供して、リプレイごとの検出とシーケンス機能の使用が確立されているコンテキストに必要なかどうかを指定します。イニシエーターシステムでのGSS-API実装は、ターゲットとの二国間交渉を必要とせずに、選択したメカニズムの関数としてこれらの機能がサポートされている（およびオプションで選択可能かどうか）を判断できます。有効にすると、これらの機能は、受信者に、受信メッセージのGSS-API処理の結果としてインジケータを提供し、それらのメッセージが複製またはアウトシーケンスとして検出されたかどうかを識別します。このようなイベントの検出は、疑わしいメッセージが受信者に提供されることを妨げません。疑わしいメッセージに対する適切なアクションコースは、発信者ポリシーの問題です。
The semantics of the replay detection and sequencing services applied to received messages, as visible across the interface which the GSS-API provides to its clients, are as follows:
GSS-APIがクライアントに提供するインターフェイス全体に表示される、受信メッセージに適用されるリプレイ検出およびシーケンスサービスのセマンティクスは次のとおりです。
When replay_det_state is TRUE, the possible major_status returns for well-formed and correctly signed messages are as follows:
replay_det_stateが真の場合、可能なMajoy_statusは、整形式および正しい署名されたメッセージに対して戻ります。次のとおりです。
1. GSS_S_COMPLETE, without concurrent indication of GSS_S_DUPLICATE_TOKEN or GSS_S_OLD_TOKEN, indicates that the message was within the window (of time or sequence space) allowing replay events to be detected, and that the message was not a replay of a previously-processed message within that window.
1. GSS_S_COMPLETEは、GSS_S_S_DUPLICATION_TOKENまたはGSS_S_OLD_TOKENを同時に示さずに、メッセージを（時間またはシーケンス空間の）ウィンドウ内にあるため、リプレイイベントを検出できること、およびメッセージが以前に入力されたメッセージのリプレイではないことを示します。
2. GSS_S_DUPLICATE_TOKEN indicates that the cryptographic checkvalue on the received message was correct, but that the message was recognized as a duplicate of a previously-processed message. In addition to identifying duplicated tokens originated by a context's peer, this status may also be used to identify reflected copies of locally-generated tokens; it is recommended that mechanism designers include within their protocols facilities to detect and report such tokens.
2. GSS_S_DUPLICATION_TOKENは、受信したメッセージの暗号化チェック値が正しかったが、メッセージが以前に処理されたメッセージの複製として認識されたことを示しています。コンテキストのピアから発信された重複したトークンを識別することに加えて、このステータスを使用して、ローカルで生成されたトークンの反射コピーを識別することもできます。メカニズム設計者は、そのようなトークンを検出および報告するために、プロトコル施設内に含めることをお勧めします。
3. GSS_S_OLD_TOKEN indicates that the cryptographic checkvalue on the received message was correct, but that the message is too old to be checked for duplication.
3. GSS_S_OLD_TOKENは、受信したメッセージの暗号化チェック値が正しかったが、メッセージが古すぎて複製をチェックするには古すぎることを示しています。
When sequence_state is TRUE, the possible major_status returns for well-formed and correctly signed messages are as follows:
Sequence_StateがTRUEの場合、可能なMajoy_Statusは、整形式および正しく署名されたメッセージに対して戻ります。
1. GSS_S_COMPLETE, without concurrent indication of GSS_S_DUPLICATE_TOKEN, GSS_S_OLD_TOKEN, GSS_S_UNSEQ_TOKEN, or GSS_S_GAP_TOKEN, indicates that the message was within the window (of time or sequence space) allowing replay events to be detected, that the message was not a replay of a previously-processed message within that window, and that no predecessor sequenced messages are missing relative to the last received message (if any) processed on the context with a correct cryptographic checkvalue.
1. GSS_S_Complete、GSS_S_DUPLICATION_TOKEN、GSS_S_OLD_TOKEN、GSS_S_S_UNSEQ_TOKEN、またはGSS_S_GAP_TOKENの同時表示なし、GSS_S_GAP_TOKENは、メッセージが[時間またはシーケンススペースの）内にあることを示しています。そのウィンドウ内で、そして正しい暗号化チェック値でコンテキストで処理された最後の受信メッセージ（ある場合）に対して、前身のシーケンスされたメッセージが欠落していないこと。
2. GSS_S_DUPLICATE_TOKEN indicates that the integrity check value on the received message was correct, but that the message was recognized as a duplicate of a previously-processed message. In addition to identifying duplicated tokens originated by a context's peer, this status may also be used to identify reflected copies of locally-generated tokens; it is recommended that mechanism designers include within their protocols facilities to detect and report such tokens.
2. GSS_S_DUPLICATION_TOKENは、受信したメッセージの整合性チェック値が正しかったが、メッセージが以前に処理されたメッセージの複製として認識されたことを示しています。コンテキストのピアから発信された重複したトークンを識別することに加えて、このステータスを使用して、ローカルで生成されたトークンの反射コピーを識別することもできます。メカニズム設計者は、そのようなトークンを検出および報告するために、プロトコル施設内に含めることをお勧めします。
3. GSS_S_OLD_TOKEN indicates that the integrity check value on the received message was correct, but that the token is too old to be checked for duplication.
3. GSS_S_OLD_TOKENは、受信したメッセージの整合性チェック値が正しかったが、トークンが古すぎて複製をチェックするには古すぎることを示しています。
4. GSS_S_UNSEQ_TOKEN indicates that the cryptographic checkvalue on the received message was correct, but that it is earlier in a sequenced stream than a message already processed on the context. [Note: Mechanisms can be architected to provide a stricter form of sequencing service, delivering particular messages to recipients only after all predecessor messages in an ordered stream have been delivered. This type of support is incompatible with the GSS-API paradigm in which recipients receive all messages, whether in order or not, and provide them (one at a time, without intra-GSS-API message buffering) to GSS-API routines for validation. GSS-API facilities provide supportive functions, aiding clients to achieve strict message stream integrity in an efficient manner in conjunction with sequencing provisions in communications protocols, but the GSS-API does not offer this level of message stream integrity service by itself.]
4. GSS_S_UNSEQ_TOKENは、受信したメッセージの暗号化チェック値が正しいことを示していますが、コンテキストですでに処理されているメッセージよりもシーケンスされたストリームの早い段階であることを示しています。[注：メカニズムは、より厳格な形式のシーケンスサービスを提供するためにアーキテクチャ化でき、順序付けられたストリーム内のすべての前任メッセージが配信された後にのみ、受信者に特定のメッセージを配信することができます。このタイプのサポートは、受信者が順番であろうとなかろうと、すべてのメッセージを受信し、検証用のGSS-APIメッセージバッファリングなしで一度に1つずつ）提供するGSS-APIパラダイムと互換性がありません。。GSS-API施設は、サポート機能を提供し、クライアントが通信プロトコルでのシーケンス条項と組み合わせて効率的な方法で厳格なメッセージストリームの整合性を達成するよう支援しますが、GSS-APIはそれ自体でこのレベルのメッセージストリーム整合性サービスを提供しません。]
5. GSS_S_GAP_TOKEN indicates that the cryptographic checkvalue on the received message was correct, but that one or more predecessor sequenced messages have not been successfully processed relative to the last received message (if any) processed on the context with a correct cryptographic checkvalue.
5. GSS_S_GAP_TOKENは、受信したメッセージの暗号化チェック値が正しいことを示していますが、1つまたは複数の前任シーケンスメッセージが、正しい暗号化チェック値でコンテキストで処理された最後の受信メッセージ（存在する場合）に対して正常に処理されていないことを示しています。
As the message stream integrity features (especially sequencing) may interfere with certain applications' intended communications paradigms, and since support for such features is likely to be resource intensive, it is highly recommended that mech_types supporting these features allow them to be activated selectively on initiator request when a context is established. A context initiator and target are provided with corresponding indicators (replay_det_state and sequence_state), signifying whether these features are active on a given context.
メッセージストリームの整合性機能（特にシーケンス）が特定のアプリケーションの意図した通信パラダイムに干渉する可能性があるため、このような機能のサポートはリソース集中的である可能性が高いため、これらの機能をサポートするMECH_TYPEがイニシエーターで選択的にアクティブ化できるようにすることを強くお勧めします。コンテキストが確立されたときのリクエスト。コンテキストイニシエーターとターゲットには、対応するインジケーター（Replay_Det_StateおよびSequence_State）が提供され、これらの機能が特定のコンテキストでアクティブであるかどうかを示します。
An example mech_type supporting per-message replay detection could (when replay_det_state is TRUE) implement the feature as follows: The underlying mechanism would insert timestamps in data elements output by GSS_GetMIC() and GSS_Wrap(), and would maintain (within a time-limited window) a cache (qualified by originator-recipient pair) identifying received data elements processed by GSS_VerifyMIC() and GSS_Unwrap(). When this feature is active, exception status returns (GSS_S_DUPLICATE_TOKEN, GSS_S_OLD_TOKEN) will be provided when GSS_VerifyMIC() or GSS_Unwrap() is presented with a message which is either a detected duplicate of a prior message or which is too old to validate against a cache of recently received messages.
mech_typeサポートごとのリプレイ検出をサポートする例は（Replay_det_stateがtrueである場合）機能を実装できます。基礎となるメカニズムは、gss_getmic（）およびgss_wrap（）によって出力されたデータ要素にタイムスタンプを挿入し、時間内に（時間内に維持します）ウィンドウ）gss_verifymic（）およびgss_unwrap（）によって処理された受信したデータ要素を識別するキャッシュ（オリジネーター - レシピエントペアの資格）。この機能がアクティブな場合、gss_verifymic（）またはgss_unwrap（）には、以前のメッセージの検出された複製であるか、キャシュに対して検証することができない場合があるメッセージが表示されているメッセージが表示されている場合、例外ステータスはreturns（gss_s_duplicate_token、gss_old_token）が提供されると提供されます。最近受け取ったメッセージの。
1.2.4: Quality of Protection
1.2.4：保護の質
Some mech_types provide their users with fine granularity control over the means used to provide per-message protection, allowing callers to trade off security processing overhead dynamically against the protection requirements of particular messages. A per-message quality-of-protection parameter (analogous to quality-of-service, or QOS) selects among different QOP options supported by that mechanism. On context establishment for a multi-QOP mech_type, context-level data provides the prerequisite data for a range of protection qualities.
一部のmech_typesは、ユーザーに、メッセージごとの保護を提供するために使用される手段に対する粒度制御をユーザーに提供し、特定のメッセージの保護要件に対して発信者がセキュリティ処理をオーバーヘッドに動的に取引できるようにします。保護ごとの品質パラメーター（サービスの質、またはQoSに類似）が、そのメカニズムでサポートされているさまざまなQOPオプションの中から選択されます。マルチQOP Mech_Typeのコンテキスト確立では、コンテキストレベルのデータが、さまざまな保護品質の前提条件データを提供します。
It is expected that the majority of callers will not wish to exert explicit mechanism-specific QOP control and will therefore request selection of a default QOP. Definitions of, and choices among, non-default QOP values are mechanism-specific, and no ordered sequences of QOP values can be assumed equivalent across different mechanisms. Meaningful use of non-default QOP values demands that callers be familiar with the QOP definitions of an underlying mechanism or mechanisms, and is therefore a non-portable construct. The GSS_S_BAD_QOP major_status value is defined in order to indicate that a provided QOP value is unsupported for a security context, most likely because that value is unrecognized by the underlying mechanism.
大多数の発信者は、明示的なメカニズム固有のQOP制御を行使することを望まないため、デフォルトのQOPの選択を要求することが予想されます。非デフォルトQOP値の定義と選択はメカニズム固有であり、QOP値の順序付けられたシーケンスは、異なるメカニズムにわたって同等と想定できません。非デフォルトQOP値の意味のある使用には、発信者が根本的なメカニズムまたはメカニズムのQOP定義に精通していることを要求しているため、ポータブルな構成要素です。GSS_S_BAD_QOP Major_Status値は、提供されたQOP値がセキュリティコンテキストに対してサポートされていないことを示すために定義されます。
In the interests of interoperability, mechanisms which allow optional support of particular QOP values shall satisfy one of the following conditions. Either:
相互運用性の利益のために、特定のQOP値のオプションのサポートを可能にするメカニズムは、次の条件のいずれかを満たすものとします。どちらか：
(i) All implementations of the mechanism are required to be capable of processing messages protected using any QOP value, regardless of whether they can apply protection corresponding to that QOP, or
(i) メカニズムのすべての実装は、そのQOPに対応する保護を適用できるかどうかに関係なく、QOP値を使用して保護されたメッセージを処理できるようにする必要があります。
(ii) The set of mutually-supported receiver QOP values must be determined during context establishment, and messages may be protected by either peer using only QOP values from this mutually-supported set.
（ii）相互にサポートされたレシーバーQOP値のセットは、コンテキストの確立中に決定する必要があり、この相互にサポートされたセットのQOP値のみを使用して、いずれかのピアによってメッセージを保護する必要があります。
NOTE: (i) is just a special-case of (ii), where implementations are required to support all QOP values on receipt.
注：（i）は（ii）の特別ケースであり、領収書のすべてのQOP値をサポートするために実装が必要です。
1.2.5: Anonymity Support
1.2.5：匿名のサポート
In certain situations or environments, an application may wish to authenticate a peer and/or protect communications using GSS-API per-message services without revealing its own identity. For example, consider an application which provides read access to a research database, and which permits queries by arbitrary requestors. A client of such a service might wish to authenticate the service, to establish trust in the information received from it, but might not wish to disclose its identity to the service for privacy reasons.
特定の状況または環境では、アプリケーションは、独自のアイデンティティを明らかにすることなく、GSS-APIのメッセージごとのサービスを使用して、ピアを認証したり、コミュニケーションを保護したりする場合があります。たとえば、研究データベースへの読み取りアクセスを提供し、任意の要求者によるクエリを許可するアプリケーションを検討します。そのようなサービスのクライアントは、サービスを認証し、そこから受け取った情報に対する信頼を確立することを希望するかもしれませんが、プライバシー上の理由でそのアイデンティティをサービスに開示したくないかもしれません。
In ordinary GSS-API usage, a context initiator's identity is made available to the context acceptor as part of the context establishment process. To provide for anonymity support, a facility (input anon_req_flag to GSS_Init_sec_context()) is provided through which context initiators may request that their identity not be provided to the context acceptor. Mechanisms are not required to honor this request, but a caller will be informed (via returned anon_state indicator from GSS_Init_sec_context()) whether or not the request is honored. Note that authentication as the anonymous principal does not necessarily imply that credentials are not required in order to establish a context.
通常のGSS-API使用では、コンテキスト設立プロセスの一部としてコンテキストイニシエーターのIDがコンテキストアクセプターに利用可能になります。匿名サポートを提供するために、施設（gss_init_sec_context（）への入力anon_req_flag）が提供されます。この要求を尊重するためにメカニズムは必要ありませんが、呼び出し元に通知されます（リクエストが尊重されているかどうかにかかわらず、gss_init_sec_context（）からの返されたanon_stateインジケーターを介して）。匿名のプリンシパルとしての認証は、コンテキストを確立するために資格情報が必要ないことを必ずしも意味しないことに注意してください。
Section 4.5 of this document defines the Object Identifier value used to identify an anonymous principal.
このドキュメントのセクション4.5は、匿名のプリンシパルを識別するために使用されるオブジェクト識別子値を定義します。
Four possible combinations of anon_state and mutual_state are possible, with the following results:
ANON_STATEとMutual_Stateの4つの可能な組み合わせが可能で、次の結果が可能です。
anon_state == FALSE, mutual_state == FALSE: initiator authenticated to target.
anon_state == false、untuly_state == false：ターゲットに認証されたイニシエーター。
anon_state == FALSE, mutual_state == TRUE: initiator authenticated to target, target authenticated to initiator.
ANON_STATE == false、untulal_state == true：ターゲットに認証されたイニシエーター、イニシエーターに認証されたターゲット。
anon_state == TRUE, mutual_state == FALSE: initiator authenticated as anonymous principal to target.
anon_state == true、mutual_state == false：anonymousプリンシパルとしてターゲットに認証されたイニシエーター。
anon_state == TRUE, mutual_state == TRUE: initiator authenticated as anonymous principal to target, target authenticated to initiator.
anon_state == true、mutual_state == true：initiatatorは、ターゲットに匿名のプリンシパルとして認証され、ターゲット、イニシエーターに認証されたターゲット。
1.2.6: Initialization
1.2.6：初期化
No initialization calls (i.e., calls which must be invoked prior to invocation of other facilities in the interface) are defined in GSS-API. As an implication of this fact, GSS-API implementations must themselves be self-initializing.
GSS-APIで定義されているのは、初期化の呼び出し（つまり、インターフェイス内の他の施設の呼び出しの前に呼び出されなければならない呼び出し）はありません。この事実の意味として、GSS-API実装自体は自己考え方でなければなりません。
1.2.7: Per-Message Protection During Context Establishment
1.2.7：コンテキスト確立中の誤った保護
A facility is defined in GSS-V2 to enable protection and buffering of data messages for later transfer while a security context's establishment is in GSS_S_CONTINUE_NEEDED status, to be used in cases where the caller side already possesses the necessary session key to enable this processing. Specifically, a new state Boolean, called prot_ready_state, is added to the set of information returned by GSS_Init_sec_context(), GSS_Accept_sec_context(), and GSS_Inquire_context().
施設はGSS-V2で定義されており、セキュリティコンテキストの確立がGSS_S_CONTINUE_NEEDEDステータスである間に、後の転送のためにデータメッセージの保護とバッファリングを可能にします。この処理を有効にするために必要なセッションキーを既に所有している場合に使用されます。具体的には、gss_init_sec_context（）、gss_accept_sec_context（）、およびgss_inquire_context（）によって返される情報のセットに追加された新しい状態ブール値が追加されます。
For context establishment calls, this state Boolean is valid and interpretable when the associated major_status is either GSS_S_CONTINUE_NEEDED, or GSS_S_COMPLETE. Callers of GSS-API (both initiators and acceptors) can assume that per-message protection (via GSS_Wrap(), GSS_Unwrap(), GSS_GetMIC() and GSS_VerifyMIC()) is available and ready for use if either: prot_ready_state == TRUE, or major_status == GSS_S_COMPLETE, though mutual authentication (if requested) cannot be guaranteed until GSS_S_COMPLETE is returned. Callers making use of per-message protection services in advance of GSS_S_COMPLETE status should be aware of the possibility that a subsequent context establishment step may fail, and that certain context data (e.g., mech_type) as returned for subsequent calls may change.
コンテキスト確立コールの場合、関連するMajor_StatusがGSS_S_CONTINUE_NEEDEDまたはGSS_S_COMPLETEのいずれかである場合、この状態ブール波は有効で解釈可能です。GSS-API（イニシエーターとアクセプターの両方）の発信者は、gss_wrap（）、gss_unwrap（）、gss_getmic（）、gss_verifymic（）を介して、メッセージごとの保護を想定できます。またはmajor_status == gss_s_completeですが、相互認証（要求された場合）は、GSS_S_Completeが返されるまで保証することはできません。GSS_S_COMPLETEステータスの前に、男性ごとの保護サービスを使用する発信者は、後続のコンテキスト確立ステップが失敗する可能性があり、後続の呼び出しで返される特定のコンテキストデータ（Mech_Typeなど）が変更される可能性を認識する必要があります。
This approach achieves full, transparent backward compatibility for GSS-API V1 callers, who need not even know of the existence of prot_ready_state, and who will get the expected behavior from GSS_S_COMPLETE, but who will not be able to use per-message protection before GSS_S_COMPLETE is returned.
このアプローチは、PROT_READY_STATEの存在さえ知らないGSS-API V1発信者の完全で透明な逆方向の互換性を達成し、GSS_S_Completeから期待される動作を得るが、GSS_S_COMPLETETELETEの前には、gss_s_completeの前に保護を使用することができない人返されます。
It is not a requirement that GSS-V2 mechanisms ever return TRUE prot_ready_state before completion of context establishment (indeed, some mechanisms will not evolve usable message protection keys, especially at the context acceptor, before context establishment is complete). It is expected but not required that GSS-V2 mechanisms will return TRUE prot_ready_state upon completion of context establishment if they support per-message protection at all (however GSS-V2 applications should not assume that TRUE prot_ready_state will always be returned together with the GSS_S_COMPLETE major_status, since GSS-V2 implementations may continue to support GSS-V1 mechanism code, which will never return TRUE prot_ready_state).
GSS-V2メカニズムがコンテキスト確立の完了前に真のprot_ready_stateを返すことは要件ではありません（実際、一部のメカニズムは、特にコンテキストアクセプターで使用可能なメッセージ保護キーを進化させません。GSS-V2メカニズムが、問題ごとの保護をまったくサポートする場合、GSS-V2メカニズムがコンテキスト確立の完了時にTrue Prot_ready_stateを返すことが予想されますが、GSS-V2アプリケーションがGSS_S_S_COMPLETE MASE_STATUSとともに常に戻ってくると仮定すべきではありません。、GSS-V2の実装は、GSS-V1メカニズムコードを引き続きサポートしている可能性があるため、True Prot_ready_stateを返すことはありません）。
When prot_ready_state is returned TRUE, mechanisms shall also set those context service indicator flags (deleg_state, mutual_state, replay_det_state, sequence_state, anon_state, trans_state, conf_avail, integ_avail) which represent facilities confirmed, at that time, to be available on the context being established. In situations where prot_ready_state is returned before GSS_S_COMPLETE, it is possible that additional facilities may be confirmed and subsequently indicated when GSS_S_COMPLETE is returned.
prot_ready_stateがtrueを返す場合、メカニズムは、それらのコンテキストサービスインジケーターフラグ（deleg_state、untulal_state、repray_det_state、sequence_state、anon_state、trans_state、conf_avail、integ_avail）を設定します。gss_s_completeの前にprot_ready_stateが返される状況では、GSS_S_completeが返されたときに追加の施設が確認され、その後示される可能性があります。
1.2.8: Implementation Robustness
1.2.8：実装の堅牢性
This section recommends aspects of GSS-API implementation behavior in the interests of overall robustness.
このセクションでは、全体的な堅牢性のためにGSS-API実装行動の側面を推奨しています。
Invocation of GSS-API calls is to incur no undocumented side effects visible at the GSS-API level.
GSS-APIコールの呼び出しは、GSS-APIレベルで見える文書化されていない副作用を発生させないことです。
If a token is presented for processing on a GSS-API security context and that token generates a fatal error in processing or is otherwise determined to be invalid for that context, the context's state should not be disrupted for purposes of processing subsequent valid tokens.
GSS-APIセキュリティコンテキストで処理するためにトークンが提示され、そのトークンが処理に致命的なエラーを生成する場合、またはそのコンテキストに対して無効であると判断された場合、その後の有効なトークンを処理するためにコンテキストの状態を破壊するべきではありません。
Certain local conditions at a GSS-API implementation (e.g., unavailability of memory) may preclude, temporarily or permanently, the successful processing of tokens on a GSS-API security context, typically generating GSS_S_FAILURE major_status returns along with locally-significant minor_status. For robust operation under such conditions, the following recommendations are made:
GSS-API実装での特定のローカル条件（メモリの利用不能など）は、GSS-APIセキュリティコンテキストでのトークンの処理の成功により、通常GSS_S_S_FAILURE MAJOR_STATUSが地元の有意なマイナー_STATUSとともに戻ります。このような条件下で堅牢な操作のために、次の推奨事項が作成されます。
Failing calls should free any memory they allocate, so that callers may retry without causing further loss of resources.
コールに失敗すると、割り当てたメモリが解放されると、発信者がリソースをさらに損失することなく再試行することができます。
Failure of an individual call on an established context should not preclude subsequent calls from succeeding on the same context.
確立されたコンテキストでの個々の呼び出しの失敗は、同じコンテキストで後続の呼び出しを妨げるものではありません。
Whenever possible, it should be possible for GSS_Delete_sec_context() calls to be successfully processed even if other calls cannot succeed, thereby enabling context-related resources to be released.
可能な場合はいつでも、GSS_DELETE_SEC_CONTEXT（）呼び出しが他の呼び出しが成功できなくても成功裏に処理され、コンテキスト関連のリソースをリリースできるようにすることができます。
A failure of GSS_GetMIC() or GSS_Wrap() due to an attempt to use an unsupported QOP will not interfere with context validity, nor shall such a failure impact the ability of the application to subsequently invoke GSS_GetMIC() or GSS_Wrap() using a supported QOP. Any state information concerning sequencing of outgoing messages shall be unchanged by an unsuccessful call of GSS_GetMIC() or GSS_Wrap().
サポートされていないQOPを使用しようとする試みによるgss_getmic（）またはgss_wrap（）の障害は、コンテキストの妥当性を妨害しません。QOP。発信メッセージのシーケンスに関する状態情報は、gss_getmic（）またはgss_wrap（）の失敗した呼び出しによって変更されません。
1.2.9: Delegation
1.2.9：代表団
The GSS-API allows delegation to be controlled by the initiating application via a Boolean parameter to GSS_Init_sec_context(), the routine that establishes a security context. Some mechanisms do not support delegation, and for such mechanisms attempts by an application to enable delegation are ignored.
GSS-APIにより、セキュリティコンテキストを確立するルーチンであるGSS_INIT_SEC_CONTEXT（）へのブールパラメーターを介して、開始アプリケーションによって委任を制御できます。一部のメカニズムは委任をサポートしておらず、そのようなメカニズムについては、委任を有効にするためのアプリケーションによる試みは無視されます。
The acceptor of a security context for which the initiator enabled delegation will receive (via the delegated_cred_handle parameter of GSS_Accept_sec_context()) a credential handle that contains the delegated identity, and this credential handle may be used to initiate subsequent GSS-API security contexts as an agent or delegate of the initiator. If the original initiator's identity is "A" and the delegate's identity is "B", then, depending on the underlying mechanism, the identity embodied by the delegated credential may be either "A" or "B acting for A".
イニシエーターが代表団を有効にしたセキュリティコンテキストのアクセプターは（GSS_ACCEPT_SEC_CONTEXT（）のDELEGATED_CRED_HANDLEパラメーターを介して）イニシエーターのエージェントまたは代表者。元のイニシエーターのアイデンティティが「A」であり、代表者のアイデンティティが「B」である場合、基礎となるメカニズムに応じて、委任された資格情報によって具体化されるアイデンティティは「A」または「Aのために作用する」のいずれかである場合があります。
For many mechanisms that support delegation, a simple Boolean does not provide enough control. Examples of additional aspects of delegation control that a mechanism might provide to an application are duration of delegation, network addresses from which delegation is valid, and constraints on the tasks that may be performed by a delegate. Such controls are presently outside the scope of the GSS-API. GSS-API implementations supporting mechanisms offering additional controls should provide extension routines that allow these controls to be exercised (perhaps by modifying the initiator's GSS-API credential prior to its use in establishing a context). However, the simple delegation control provided by GSS-API should always be able to over-ride other mechanism-specific delegation controls; if the application instructs GSS_Init_sec_context() that delegation is not desired, then the implementation must not permit delegation to occur. This is an exception to the general rule that a mechanism may enable services even if they are not requested; delegation may only be provided at the explicit request of the application.
代表団をサポートする多くのメカニズムでは、単純なブール値は十分な制御を提供しません。アプリケーションにメカニズムが提供する可能性のある委任制御の追加の側面の例は、委任の期間、委任が有効なネットワークアドレス、および代表者が実行できるタスクの制約です。このようなコントロールは現在、GSS-APIの範囲外です。追加のコントロールを提供するメカニズムをサポートするGSS-API実装は、これらのコントロールを行使できるようにする拡張ルーチンを提供する必要があります（おそらく、コンテキストの確立に使用する前にイニシエーターのGSS-API資格情報を変更することにより）。ただし、GSS-APIによって提供される単純な委任制御は、常に他のメカニズム固有の委任コントロールをオーバーライドできるはずです。アプリケーションがGSS_INIT_SEC_CONTEXT（）に代表団が望まれないことを指示した場合、実装により委任が行われることはありません。これは、メカニズムがサービスが要求されていなくてもサービスを有効にする可能性があるという一般的なルールの例外です。委任は、申請の明示的な要求でのみ提供される場合があります。
1.2.10: Interprocess Context Transfer
1.2.10：インタープロセスコンテキスト転送
GSS-API V2 provides routines (GSS_Export_sec_context() and GSS_Import_sec_context()) which allow a security context to be transferred between processes on a single machine. The most common use for such a feature is a client-server design where the server is implemented as a single process that accepts incoming security contexts, which then launches child processes to deal with the data on these contexts. In such a design, the child processes must have access to the security context data structure created within the parent by its call to GSS_Accept_sec_context() so that they can use per-message protection services and delete the security context when the communication session ends.
GSS-API V2は、単一のマシンのプロセス間でセキュリティコンテキストを転送できるようにするルーチン（gss_export_sec_context（）およびgss_import_sec_context（））を提供します。このような機能の最も一般的な用途は、サーバーが着信セキュリティコンテキストを受け入れる単一のプロセスとして実装され、これらのコンテキストに関するデータに対処するための子プロセスを起動するクライアントサーバー設計です。このような設計では、子のプロセスは、gss_accept_sec_context（）を呼び出すことにより、親の中に作成されたセキュリティコンテキストデータ構造にアクセスする必要があります。これにより、通信セッションが終了したときにセキュリティコンテキストを削除し、セキュリティコンテキストを削除できます。
Since the security context data structure is expected to contain sequencing information, it is impractical in general to share a context between processes. Thus GSS-API provides a call (GSS_Export_sec_context()) that the process which currently owns the context can call to declare that it has no intention to use the context subsequently, and to create an inter-process token containing information needed by the adopting process to successfully import the context. After successful completion of this call, the original security context is made inaccessible to the calling process by GSS-API, and any context handles referring to this context are no longer valid. The originating process transfers the inter-process token to the adopting process, which passes it to GSS_Import_sec_context(), and a fresh context handle is created such that it is functionally identical to the original context.
セキュリティコンテキストデータ構造にはシーケンス情報が含まれると予想されるため、プロセス間でコンテキストを共有することは一般に非現実的です。したがって、GSS-APIは、現在コンテキストを所有しているプロセスが、その後のコンテキストを使用するつもりがないことを宣言し、採用プロセスに必要な情報を含むプロセス間トークンを作成することを宣言するために呼び出しができるという呼び出し（gss_export_sec_context（））を提供します。コンテキストを正常にインポートします。この呼び出しが正常に完了した後、元のセキュリティコンテキストはGSS-APIによる呼び出しプロセスにアクセスできなくなり、このコンテキストを参照するコンテキストハンドルはもはや有効ではありません。発信元のプロセスは、インタープロセストークンを採用プロセスに転送し、GSS_IMPORT_SEC_CONTEXT（）に渡し、元のコンテキストと機能的に同一になるような新しいコンテキストハンドルが作成されます。
The inter-process token may contain sensitive data from the original security context (including cryptographic keys). Applications using inter-process tokens to transfer security contexts must take appropriate steps to protect these tokens in transit. Implementations are not required to support the inter-process transfer of security contexts. The ability to transfer a security context is indicated when the context is created, by GSS_Init_sec_context() or GSS_Accept_sec_context() indicating a TRUE trans_state return value.
プロセス間トークンには、元のセキュリティコンテキスト（暗号化キーを含む）からの機密データが含まれている場合があります。プロセス間トークンを使用してセキュリティコンテキストを転送するアプリケーションは、これらのトークンを輸送中に保護するために適切な措置を講じる必要があります。セキュリティコンテキストのプロセス間転送をサポートするために実装は必要ありません。セキュリティコンテキストを転送する機能は、gss_init_sec_context（）またはgss_accept_sec_context（）によって、コンテキストが作成されたときに示されます。
2: Interface Descriptions
2：インターフェイスの説明
This section describes the GSS-API's service interface, dividing the set of calls offered into four groups. Credential management calls are related to the acquisition and release of credentials by principals. Context-level calls are related to the management of security contexts between principals. Per-message calls are related to the protection of individual messages on established security contexts. Support calls provide ancillary functions useful to GSS-API callers. Table 2 groups and summarizes the calls in tabular fashion.
このセクションでは、GSS-APIのサービスインターフェイスについて説明し、提供されるコールのセットを4つのグループに分割します。資格管理コールは、校長による資格情報の獲得とリリースに関連しています。コンテキストレベルの呼び出しは、プリンシパル間のセキュリティコンテキストの管理に関連しています。メッセージごとの呼び出しは、確立されたセキュリティコンテキストでの個々のメッセージの保護に関連しています。サポートコールは、GSS-API発信者に役立つ補助機能を提供します。表2のグループとコールを表形式で要約します。
Table 2: GSS-API Calls
表2：GSS-API呼び出し
CREDENTIAL MANAGEMENT
資格管理
GSS_Acquire_cred acquire credentials for use
GSS_Release_cred release credentials after use
GSS_Inquire_cred display information about
credentials
GSS_Add_cred construct credentials incrementally GSS_Inquire_cred_by_mech display per-mechanism credential information
GSS_ADD_CRED CONSTRUMTION資格情報gss_inquire_cred_by_mechディスプレイメカニズムの資格情報
CONTEXT-LEVEL CALLS
コンテキストレベルの呼び出し
GSS_Init_sec_context initiate outbound security context
GSS_Accept_sec_context accept inbound security context
GSS_Delete_sec_context flush context when no longer needed
GSS_Process_context_token process received control token on
context
GSS_Context_time indicate validity time remaining on
context
GSS_Inquire_context display information about context
GSS_Wrap_size_limit determine GSS_Wrap token size limit
GSS_Export_sec_context transfer context to other process
GSS_Import_sec_context import transferred context
PER-MESSAGE CALLS
メッセージごとの呼び出し
GSS_GetMIC apply integrity check, receive as
token separate from message
GSS_VerifyMIC validate integrity check token
along with message
GSS_Wrap sign, optionally encrypt,
encapsulate
GSS_Unwrap decapsulate, decrypt if needed,
validate integrity check
SUPPORT CALLS
サポートコール
GSS_Display_status translate status codes to printable
form
GSS_Indicate_mechs indicate mech_types supported on
local system
GSS_Compare_name compare two names for equality
GSS_Display_name translate name to printable form
GSS_Import_name convert printable name to
normalized form
GSS_Release_name free storage of normalized-form
name
GSS_Release_buffer free storage of general GSS-allocated
object
GSS_Release_OID_set free storage of OID set object
GSS_Create_empty_OID_set create empty OID set
GSS_Add_OID_set_member add member to OID set
GSS_Test_OID_set_member test if OID is member of OID set
GSS_Inquire_names_for_mech indicate name types supported by
mechanism
GSS_Inquire_mechs_for_name indicates mechanisms supporting name
type
GSS_Canonicalize_name translate name to per-mechanism form
GSS_Export_name externalize per-mechanism name
GSS_Duplicate_name duplicate name object
2.1: Credential management calls
2.1：資格管理コール
These GSS-API calls provide functions related to the management of credentials. Their characterization with regard to whether or not they may block pending exchanges with other network entities (e.g., directories or authentication servers) depends in part on OS-specific (extra-GSS-API) issues, so is not specified in this document.
これらのGSS-API呼び出しは、資格情報の管理に関連する関数を提供します。他のネットワークエンティティ（例：ディレクトリや認証サーバーなど）との保留中の交換をブロックする可能性があるかどうかに関する彼らの特性評価は、OS固有の（Extra-GSS-API）問題に一部依存しているため、このドキュメントでは指定されていません。
The GSS_Acquire_cred() call is defined within the GSS-API in support of application portability, with a particular orientation towards support of portable server applications. It is recognized that (for certain systems and mechanisms) credentials for interactive users may be managed differently from credentials for server processes; in such environments, it is the GSS-API implementation's responsibility to distinguish these cases and the procedures for making this distinction are a local matter. The GSS_Release_cred() call provides a means for callers to indicate to the GSS-API that use of a credentials structure is no longer required. The GSS_Inquire_cred() call allows callers to determine information about a credentials structure. The GSS_Add_cred() call enables callers to append elements to an existing credential structure, allowing iterative construction of a multi-mechanism credential. The GSS_Inquire_cred_by_mech() call enables callers to extract per-mechanism information describing a credentials structure.
GSS_ACQUIRE_CRED（）呼び出しは、Portable Serverアプリケーションのサポートに向けた特定のオリエンテーションを備えた、アプリケーションポータビリティをサポートするGSS-API内で定義されます。インタラクティブユーザーの（特定のシステムとメカニズムの）資格情報は、サーバープロセスの資格情報とは異なる方法で管理される可能性があることが認識されています。このような環境では、これらのケースを区別するのはGSS-API実装の責任であり、この区別を行う手順はローカルな問題です。GSS_RELEASE_CRED（）コールは、CARLERSがGSS-APIに資格情報構造の使用が不要であることをGSS-APIに示す手段を提供します。GSS_INQUIRE_CRED（）コールにより、発信者は資格情報の構造に関する情報を決定できます。GSS_ADD_CRED（）コールにより、発信者は既存の資格構造に要素を追加し、マルチメカニズムの資格情報の反復構造を可能にします。GSS_INQUIRE_CRED_BY_MECH（）呼び出しにより、発信者は資格情報の構造を説明するメカニズムごとの情報を抽出できます。
2.1.1: GSS_Acquire_cred call
2.1.1：GSS_ACQUIRE_CRED CALL
Inputs:
入力：
o desired_name INTERNAL NAME, -- NULL requests locally-determined -- default
o 希望_name内部名、 - null requests locally-determined-デフォルト
o lifetime_req INTEGER, -- in seconds; 0 requests default
o lifetime_req integer、 - 秒単位。0デフォルトのリクエスト
o desired_mechs SET OF OBJECT IDENTIFIER, -- NULL requests -- system-selected default
o 希望_mechsオブジェクト識別子のセット - null requests-システム選択デフォルト
o cred_usage INTEGER -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY, -- 2=ACCEPT-ONLY Outputs:
o cred_usage integer-0 = initiate-and-accept、1 = initiateのみ、2 =承認専用出力：
o major_status INTEGER,
o Major_status整数、
o minor_status INTEGER,
o minor_status整数、
o output_cred_handle CREDENTIAL HANDLE, -- if returned non-NULL, -- caller must release with GSS_Release_cred()
o output_cred_handle資格情報ハンドル、-null以外の返された場合、発信者はgss_release_cred（）でリリースする必要があります
o actual_mechs SET OF OBJECT IDENTIFIER, -- if returned non-NULL, -- caller must release with GSS_Release_oid_set()
o altual_mechsオブジェクト識別子のセット - null以外の返された場合、発信者はgss_release_oid_set（）でリリースする必要があります
o lifetime_rec INTEGER -- in seconds, or reserved value for -- INDEFINITE
o lifetime_rec integer-秒単位または予約価値 - 不定
Return major_status codes:
Major_statusコードを返す：
o GSS_S_COMPLETE indicates that requested credentials were successfully established, for the duration indicated in lifetime_rec, suitable for the usage requested in cred_usage, for the set of mech_types indicated in actual_mechs, and that those credentials can be referenced for subsequent use with the handle returned in output_cred_handle.
o GSS_S_COMPLETEは、Requiredの資格情報が正常に確立されたことを示しています。Lifetime_Recに示されている期間、CRED_USAGEで要求された使用法に適した場合、実際の_Mechsに示されているMech_Typesのセットについて、およびそれらの資格情報は、Output_Cred_credleで返されるハンドルでその後の使用のために参照できることを示しています。
o GSS_S_BAD_MECH indicates that a mech_type unsupported by the GSS-API implementation type was requested, causing the credential establishment operation to fail.
o GSS_S_BAD_MECHは、GSS-API実装タイプによってサポートされていないMECH_TYPEが要求され、資格設定の操作が失敗することを示しています。
o GSS_S_BAD_NAMETYPE indicates that the provided desired_name is uninterpretable or of a type unsupported by the applicable underlying GSS-API mechanism(s), so no credentials could be established for the accompanying desired_name.
o gss_s_bad_nameTypeは、提供された希望の_nameが該当する基礎となるGSS-APIメカニズムによってサポートされていない型であることを示しているため、付随する希望の_nameについては資格情報を確立することはできません。
o GSS_S_BAD_NAME indicates that the provided desired_name is inconsistent in terms of internally-incorporated type specifier information, so no credentials could be established for the accompanying desired_name.
o GSS_S_BAD_NAMEは、提供された希望の型型指定機情報の点では、提供された希望の型が一貫性がないことを示しているため、添付の希望_nameについては資格情報を確立できません。
o GSS_S_CREDENTIALS_EXPIRED indicates that underlying credential elements corresponding to the requested desired_name have expired, so requested credentials could not be established.
o GSS_S_CREDENTIALS_EXPIREDは、要求された希望_nameに対応する基礎となる資格情報要素が有効期限が切れているため、要求された資格情報を確立できなかったことを示しています。
o GSS_S_NO_CRED indicates that no credential elements corresponding to the requested desired_name and usage could be accessed, so requested credentials could not be established. In particular, this status should be returned upon temporary user-fixable conditions preventing successful credential establishment and upon lack of authorization to establish and use credentials associated with the identity named in the input desired_name argument.
o GSS_S_NO_CREDは、要求された希望者に対応する資格要素がないことを示しており、要求された資格情報を確立できなかったためです。特に、このステータスは、クレデンシャルの確立の成功を妨げる一時的なユーザー固定可能な条件と、入力希望の_NAME引数で指定されたアイデンティティに関連する資格情報を確立および使用する許可の欠如に応じて返される必要があります。
o GSS_S_FAILURE indicates that credential establishment failed for reasons unspecified at the GSS-API level.
o GSS_S_FAILUREは、GSS-APIレベルで不特定の理由で資格情報が失敗したことを示しています。
GSS_Acquire_cred() is used to acquire credentials so that a principal can (as a function of the input cred_usage parameter) initiate and/or accept security contexts under the identity represented by the desired_name input argument. On successful completion, the returned output_cred_handle result provides a handle for subsequent references to the acquired credentials. Typically, single-user client processes requesting that default credential behavior be applied for context establishment purposes will have no need to invoke this call.
GSS_ACQUIRE_CRED（）は、資格情報を取得するために使用され、[入力CRED_USAGEパラメーターの関数として）aseired_name入力引数で表されるIDの下でセキュリティコンテキストを開始および/または受け入れることができます。正常に完了すると、返されたoutput_cred_handle resultは、取得した資格情報へのその後の参照のハンドルを提供します。通常、シングルユーザークライアントプロセスは、デフォルトの資格情報の動作をコンテキストの確立目的に適用することを要求します。この呼び出しを呼び出す必要はありません。
A caller may provide the value NULL (GSS_C_NO_NAME) for desired_name, which will be interpreted as a request for a credential handle that will invoke default behavior when passed to GSS_Init_sec_context(), if cred_usage is GSS_C_INITIATE or GSS_C_BOTH, or GSS_Accept_sec_context(), if cred_usage is GSS_C_ACCEPT or GSS_C_BOTH. It is possible that multiple pre-established credentials may exist for the same principal identity (for example, as a result of multiple user login sessions) when GSS_Acquire_cred() is called; the means used in such cases to select a specific credential are local matters. The input lifetime_req argument to GSS_Acquire_cred() may provide useful information for local GSS-API implementations to employ in making this disambiguation in a manner which will best satisfy a caller's intent.
発信者は、希望_nameの値null（gss_c_no_name）を提供することができます。これは、gss_init_sec_context（）に渡された場合にデフォルトの動作を呼び出す資格情報のリクエストとして解釈されます。GSS_C_ACCEPTまたはGSS_C_OTHです。GSS_ACQUIRE_CRED（）が呼び出された場合、同じ主要なアイデンティティ（たとえば、複数のユーザーログインセッションの結果として）に対して複数の事前に確立された資格情報が存在する可能性があります。そのような場合に特定の資格情報を選択するために使用される手段は、ローカルの問題です。gss_acquire_cred（）への入力lifetime_req引数は、ローカルGSS-API実装が、発信者の意図を最もよく満たす方法でこの曖昧性を採用する際に採用するための有用な情報を提供する場合があります。
This routine is expected to be used primarily by context acceptors, since implementations are likely to provide mechanism-specific ways of obtaining GSS-API initiator credentials from the system login process. Some implementations may therefore not support the acquisition of GSS_C_INITIATE or GSS_C_BOTH credentials via GSS_Acquire_cred() for any name other than GSS_C_NO_NAME, or a name resulting from applying GSS_Inquire_context() to an active context, or a name resulting from applying GSS_Inquire_cred() against a credential handle corresponding to default behavior. It is important to recognize that the explicit name which is yielded by resolving a default reference may change over time, e.g., as a result of local credential element management operations outside GSS-API; once resolved, however, the value of such an explicit name will remain constant.
このルーチンは、システムログインプロセスからGSS-APIイニシエーター資格情報を取得するメカニズム固有の方法を提供する可能性が高いため、主にコンテキストアクセプターによって使用されることが期待されています。したがって、一部の実装は、GSS_CQUIRE_CRED（）を介してGSS_CQUIRE_CRED（）を介したGSS_C_INITIATEまたはGSS_C_BOTH資格情報の取得をサポートしていない場合があります。デフォルトの動作に対応するハンドル。デフォルトのリファレンスを解決することで生成される明示的な名前は、GSS-API以外のローカル資格要素管理操作の結果として、時間とともに変更される可能性があることを認識することが重要です。ただし、解決すると、そのような明示的な名前の値は一定のままです。
The lifetime_rec result indicates the length of time for which the acquired credentials will be valid, as an offset from the present. A mechanism may return a reserved value indicating INDEFINITE if no constraints on credential lifetime are imposed. A caller of GSS_Acquire_cred() can request a length of time for which acquired credentials are to be valid (lifetime_req argument), beginning at the present, or can request credentials with a default validity interval. (Requests for postdated credentials are not supported within the GSS-API.) Certain mechanisms and implementations may bind in credential validity period specifiers at a point preliminary to invocation of the GSS_Acquire_cred() call (e.g., in conjunction with user login procedures). As a result, callers requesting non-default values for lifetime_req must recognize that such requests cannot always be honored and must be prepared to accommodate the use of returned credentials with different lifetimes as indicated in lifetime_rec.
lifetime_recの結果は、現在からのオフセットとして、取得した資格情報が有効になる時間の長さを示します。メカニズムは、資格情報のライフタイムに制約が課されない場合、不定を示す予約価値を返すことがあります。GSS_ACQUIRE_CRED（）の発信者は、取得した資格情報が有効である（lifetime_req引数）、現在から始まる、またはデフォルトの妥当性間隔で資格情報を要求する時間を要求できます。（郵便番号付きの資格情報の要求は、GSS-API内でサポートされていません。）特定のメカニズムと実装は、GSS_ACQUIRE_CRED（）呼び出しの呼び出しの予備的なポイントで資格情報の妥当性期間仕様に結合する場合があります（例えば、ユーザーログイン手順と組み合わせて）。その結果、lifetime_reqの非デフォルト値を要求する発信者は、そのような要求が常に尊重されることはできないことを認識し、lifetime_recに示されているように異なる寿命で返された資格情報の使用に対応する必要があることを認識する必要があります。
The caller of GSS_Acquire_cred() can explicitly specify a set of mech_types which are to be accommodated in the returned credentials (desired_mechs argument), or can request credentials for a system-defined default set of mech_types. Selection of the system-specified default set is recommended in the interests of application portability. The actual_mechs return value may be interrogated by the caller to determine the set of mechanisms with which the returned credentials may be used.
GSS_ACQUIRE_CRED（）の発信者は、返された資格情報に対応するMECH_TYPESのセットを明示的に指定することができ、システム定義されたMECH_TYPESのデフォルトセットの資格情報を要求できます。システム指定のデフォルトセットの選択は、アプリケーションの携帯性のために推奨されます。実際の_mechs返品値は、呼び出し元によって尋問され、返された資格情報が使用されるメカニズムのセットを決定できます。
2.1.2: GSS_Release_cred call
2.1.2：GSS_RELEASE_CRED CALL
Input:
入力：
o cred_handle CREDENTIAL HANDLE -- if GSS_C_NO_CREDENTIAL -- is specified, the call will complete successfully, but -- will have no effect; no credential elements will be -- released.
o CRED_HANDLE資格情報 - GSS_C_NO_CREDENTIAL-指定されている場合、コールは正常に完了しますが、効果はありません。資格要素はありません - リリースされます。
Outputs:
出力：
o major_status INTEGER,
o Major_status整数、
o minor_status INTEGER
o minor_status整数
Return major_status codes:
Major_statusコードを返す：
o GSS_S_COMPLETE indicates that the credentials referenced by the input cred_handle were released for purposes of subsequent access by the caller. The effect on other processes which may be authorized shared access to such credentials is a local matter.
o GSS_S_COMPLETEは、入力CRED_HANDLEが参照されている資格情報が、発信者による後続のアクセスの目的でリリースされたことを示しています。そのような資格情報への共有アクセスを許可されている可能性のある他のプロセスへの影響は、ローカルな問題です。
o GSS_S_NO_CRED indicates that no release operation was performed, either because the input cred_handle was invalid or because the caller lacks authorization to access the referenced credentials.
o GSS_S_NO_CREDは、入力CRED_HANDLEが無効であるか、発信者が参照された資格情報にアクセスする許可がないため、リリース操作が実行されなかったことを示しています。
o GSS_S_FAILURE indicates that the release operation failed for reasons unspecified at the GSS-API level.
o GSS_S_FAILUREは、GSS-APIレベルで不特定の理由でリリース操作が失敗したことを示しています。
Provides a means for a caller to explicitly request that credentials be released when their use is no longer required. Note that system-specific credential management functions are also likely to exist, for example to assure that credentials shared among processes are properly deleted when all affected processes terminate, even if no explicit release requests are issued by those processes. Given the fact that multiple callers are not precluded from gaining authorized access to the same credentials, invocation of GSS_Release_cred() cannot be assumed to delete a particular set of credentials on a system-wide basis.
発信者が、使用が不要になったときに資格情報をリリースすることを明示的に要求する手段を提供します。たとえば、これらのプロセスによって明示的なリリース要求が発行されていなくても、影響を受けるすべてのプロセスが終了するとプロセス間で共有される資格情報が適切に削除されることを保証するために、システム固有の資格管理機能も存在する可能性が高いことに注意してください。複数の発信者が同じ資格情報への許可されたアクセスを取得することを妨げられないという事実を考えると、GSS_RELEASE_CRED（）の呼び出しは、システム全体で特定の資格情報のセットを削除するとは想定できません。
2.1.3: GSS_Inquire_cred call
2.1.3：GSS_INQUIRE_CRED CALL
Input:
入力：
o cred_handle CREDENTIAL HANDLE -- if GSS_C_NO_CREDENTIAL -- is specified, default initiator credentials are queried
o CRED_HANDLE資格情報 - GSS_C_NO_CREDENTIAL-指定されている場合、デフォルトのイニシエーター資格情報がQUERIEDされます
Outputs:
出力：
o major_status INTEGER,
o Major_status整数、
o minor_status INTEGER,
o minor_status整数、
o cred_name INTERNAL NAME, -- caller must release with -- GSS_Release_name()
o CRED_NAME内部名、 - 発信者はwith -gss_release_name（）でリリースする必要があります
o lifetime_rec INTEGER -- in seconds, or reserved value for -- INDEFINITE
o lifetime_rec integer-秒単位または予約価値 - 不定
o cred_usage INTEGER, -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY, -- 2=ACCEPT-ONLY
o cred_usage integer、-0 = initiate-and-accept、1 = initiate-only、-2 = accept-only
o mech_set SET OF OBJECT IDENTIFIER -- caller must release -- with GSS_Release_oid_set() Return major_status codes:
o mech_setオブジェクト識別子のセット - 発信者はリリースする必要があります - gss_release_oid_set（）return major_statusコード：
o GSS_S_COMPLETE indicates that the credentials referenced by the input cred_handle argument were valid, and that the output cred_name, lifetime_rec, and cred_usage values represent, respectively, the credentials' associated principal name, remaining lifetime, suitable usage modes, and supported mechanism types.
o GSS_S_COMPLETEは、入力CRED_HANDLE引数で参照される資格情報が有効であり、出力CRED_NAME、LIFETIME_REC、およびCRED_USAGE値が、それぞれ資格情報の関連する元名、残りの寿命、適切な使用モード、サポートされているメカニズムタイプを表していることを示しています。
o GSS_S_NO_CRED indicates that no information could be returned about the referenced credentials, either because the input cred_handle was invalid or because the caller lacks authorization to access the referenced credentials.
o GSS_S_NO_CREDは、入力CRED_HANDLEが無効であるか、呼び出し元が参照された資格情報にアクセスする許可がないため、参照された資格情報について情報を返すことができないことを示しています。
o GSS_S_DEFECTIVE_CREDENTIAL indicates that the referenced credentials are invalid.
o gss_s_defective_credentialは、参照された資格情報が無効であることを示します。
o GSS_S_CREDENTIALS_EXPIRED indicates that the referenced credentials have expired.
o GSS_S_CREDENTIALS_EXPIREDは、参照された資格情報の有効期限が切れていることを示します。
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_cred() call is defined primarily for the use of those callers which request use of default credential behavior rather than acquiring credentials explicitly with GSS_Acquire_cred(). It enables callers to determine a credential structure's associated principal name, remaining validity period, usability for security context initiation and/or acceptance, and supported mechanisms.
GSS_INQUIRE_CRED（）コールは、GSS_ACQUIRE_CRED（）で明示的に資格情報を取得するのではなく、デフォルトの資格情報の使用を要求する発信者の使用のために主に定義されます。これにより、発信者は資格情報構造の関連する主名、残りの妥当性期間、セキュリティコンテキストの開始および/または受け入れのための使いやすさ、およびサポートされているメカニズムを決定できます。
For a multi-mechanism credential, the returned "lifetime" specifier indicates the shortest lifetime of any of the mechanisms' elements in the credential (for either context initiation or acceptance purposes).
マルチメカニズムの資格情報の場合、返された「寿命」指定子は、資格内のメカニズムの要素の中で最も短い寿命を示します（コンテキストの開始または受け入れ目的のいずれか）。
GSS_Inquire_cred() should indicate INITIATE-AND-ACCEPT for "cred_usage" if both of the following conditions hold:
GSS_INQUIRE_CRED（）は、次の両方の条件が保持されている場合は、「CRED_USAGE」の開始とacceptを示す必要があります。
(1) there exists in the credential an element which allows context initiation using some mechanism
(1) 資格情報には、何らかのメカニズムを使用してコンテキスト開始を可能にする要素があります
(2) there exists in the credential an element which allows context acceptance using some mechanism (allowably, but not necessarily, one of the same mechanism(s) qualifying for (1)).
(2) 資格情報には、いくつかのメカニズムを使用してコンテキストの受け入れを可能にする要素が存在します（（1）、必ずしもそうではない、必ずしもそうではありません）。
If condition (1) holds but not condition (2), GSS_Inquire_cred() should indicate INITIATE-ONLY for "cred_usage". If condition (2) holds but not condition (1), GSS_Inquire_cred() should indicate ACCEPT-ONLY for "cred_usage".
条件（1）が条件（2）ではなく保持しますが、GSS_INQUIRE_CRED（）は、「chread_usage」の開始のみを示す必要があります。条件（2）が条件（1）ではなく保持しますが、GSS_INQUIRE_CRED（）は「cred_usage」の承認のみを示す必要があります。
Callers requiring finer disambiguation among available combinations of lifetimes, usage modes, and mechanisms should call the GSS_Inquire_cred_by_mech() routine, passing that routine one of the mech OIDs returned by GSS_Inquire_cred().
寿命、使用モード、およびメカニズムの利用可能な組み合わせの間でより細かい分離を必要とする発信者は、GSS_INQUIRE_CRED_BY_MECH（）ルーチンを呼び出す必要があります。
2.1.4: GSS_Add_cred call
2.1.4：GSS_ADD_CRED CALL
Inputs:
入力：
o input_cred_handle CREDENTIAL HANDLE -- handle to credential -- structure created with prior GSS_Acquire_cred() or -- GSS_Add_cred() call; see text for definition of behavior -- when GSS_C_NO_CREDENTIAL provided.
o input_cred_handle資格情報 - 資格情報へのハンドル - 以前のgss_acquire_cred（）または-gss_add_cred（）callで作成された構造;動作の定義については、GSS_C_NO_CREDENTIALが提供された場合のテキストを参照してください。
o desired_name INTERNAL NAME
o 希望_name内部名
o initiator_time_req INTEGER -- in seconds; 0 requests default
o initiator_time_req integer-秒単位。0デフォルトのリクエスト
o acceptor_time_req INTEGER -- in seconds; 0 requests default
o Acceptor_time_req integer-秒単位。0デフォルトのリクエスト
o desired_mech OBJECT IDENTIFIER
o 希望する_mechオブジェクト識別子
o cred_usage INTEGER -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY, -- 2=ACCEPT-ONLY
o cred_usage integer-0 = initiate-and-accept、1 = initiate-only、-2 = accept-only
Outputs:
出力：
o major_status INTEGER,
o Major_status整数、
o minor_status INTEGER,
o minor_status整数、
o output_cred_handle CREDENTIAL HANDLE, -- NULL to request that -- credential elements be added "in place" to the credential -- structure identified by input_cred_handle, -- non-NULL pointer to request that -- a new credential structure and handle be created. -- if credential handle returned, caller must release with -- GSS_Release_cred()
o output_cred_handle資格情報ハンドル - それを要求するためにnull-資格要素を資格情報に「所定の位置に追加する」 - input_cred_handleによって識別された構造 - それを要求するための非ヌルポインター - 新しい資格的構造とハンドルを作成します。 - 資格情報ハンドルが返された場合、発信者はgss_release_cred（）でリリースする必要があります
o actual_mechs SET OF OBJECT IDENTIFIER, -- if returned, caller must -- release with GSS_Release_oid_set()
o altual_mechsオブジェクト識別子のセット - 返された場合、発信者はgss_release_oid_set（）でリリースする必要があります
o initiator_time_rec INTEGER -- in seconds, or reserved value for -- INDEFINITE
o initiator_time_rec integer-秒単位または予約価値 - 無期限
o acceptor_time_rec INTEGER -- in seconds, or reserved value for -- INDEFINITE o cred_usage INTEGER, -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY, -- 2=ACCEPT-ONLY
o Acceptor_time_rec integer-秒単位または予約価値-definite o cred_usage integer、0 = initiate-and-accept、1 = initiate-only、-2 = accept-only
o mech_set SET OF OBJECT IDENTIFIER -- full set of mechanisms -- supported by resulting credential.
o MECH_SETオブジェクト識別子のセット - メカニズムの完全なセット - は、結果として得られる資格によってサポートされます。
Return major_status codes:
Major_statusコードを返す：
o GSS_S_COMPLETE indicates that the credentials referenced by the input_cred_handle argument were valid, and that the resulting credential from GSS_Add_cred() is valid for the durations indicated in initiator_time_rec and acceptor_time_rec, suitable for the usage requested in cred_usage, and for the mechanisms indicated in actual_mechs.
o GSS_S_COMPLETEは、input_cred_handle引数によって参照される資格情報が有効であり、gss_add_cred（）から得られた資格情報がinitiator_time_recおよびaccedor_time_recで有効であることを示しています。
o GSS_S_DUPLICATE_ELEMENT indicates that the input desired_mech specified a mechanism for which the referenced credential already contained a credential element with overlapping cred_usage and validity time specifiers.
o GSS_S_DUPLICATION_ELEMENTは、入力希望の_mechが、参照された資格情報に既に重複したCRED_USAGEおよび有効性時間指定を持つ資格情報要素を含むメカニズムを指定したことを示します。
o GSS_S_BAD_MECH indicates that the input desired_mech specified a mechanism unsupported by the GSS-API implementation, causing the GSS_Add_cred() operation to fail.
o GSS_S_BAD_MECHは、入力目的の_mechがGSS-API実装によってサポートされていないメカニズムを指定し、GSS_ADD_CRED（）操作を失敗させることを示します。
o GSS_S_BAD_NAMETYPE indicates that the provided desired_name is uninterpretable or of a type unsupported by the applicable underlying GSS-API mechanism(s), so the GSS_Add_cred() operation could not be performed for that name.
o GSS_S_S_BAD_NAMATYPEは、提供された希望の_NAMEが解釈できないか、該当する基礎となるGSS-APIメカニズムによってサポートされていないタイプであることを示しているため、GSS_ADD_CRED（）操作はその名前で実行できませんでした。
o GSS_S_BAD_NAME indicates that the provided desired_name is inconsistent in terms of internally-incorporated type specifier information, so the GSS_Add_cred() operation could not be performed for that name.
o GSS_S_BAD_NAMEは、提供された希望の型型指定者情報の点では提供された希望の型が一貫していないことを示しているため、GSS_ADD_CRED（）操作はその名前で実行できませんでした。
o GSS_S_NO_CRED indicates that the input_cred_handle referenced invalid or inaccessible credentials. In particular, this status should be returned upon temporary user-fixable conditions preventing successful credential establishment or upon lack of authorization to establish or use credentials representing the requested identity.
o GSS_S_NO_CREDは、input_cred_handleが無効またはアクセス不可の資格情報を参照していることを示します。特に、このステータスは、クレデンシャルの確立の成功を妨げる一時的な使い捨て条件で、または要求された身元を表す資格情報を確立または使用する許可の欠如に戻す必要があります。
o GSS_S_CREDENTIALS_EXPIRED indicates that referenced credential elements have expired, so the GSS_Add_cred() operation could not be performed.
o GSS_S_CREDENTIALS_EXPIREDは、参照された資格情報要素の有効期限が切れているため、GSS_ADD_CRED（）操作が実行できなかったことを示しています。
o GSS_S_FAILURE indicates that the operation failed for reasons unspecified at the GSS-API level.
o GSS_S_FAILUREは、GSS-APIレベルで不特定の理由で操作が失敗したことを示しています。
GSS_Add_cred() enables callers to construct credentials iteratively by adding credential elements in successive operations, corresponding to different mechanisms. This offers particular value in multi-mechanism environments, as the major_status and minor_status values returned on each iteration are individually visible and can therefore be interpreted unambiguously on a per-mechanism basis. A credential element is identified by the name of the principal to which it refers. GSS-API implementations must impose a local access control policy on callers of this routine to prevent unauthorized callers from acquiring credential elements to which they are not entitled. This routine is not intended to provide a "login to the network" function, as such a function would involve the creation of new mechanism-specific authentication data, rather than merely acquiring a GSS-API handle to existing data. Such functions, if required, should be defined in implementation-specific extension routines.
GSS_ADD_CRED（）により、異なるメカニズムに対応する連続操作に資格要素を追加することにより、発信者が資格情報を反復的に構築できます。これは、各反復で返されるMajor_StatusとMinor_Status値が個別に見えるため、機械ごとに明確に解釈できるため、マルチメカニズム環境で特定の価値を提供します。資格要素は、それが言及するプリンシパルの名前によって識別されます。GSS-APIの実装は、このルーチンの発信者にローカルアクセス制御ポリシーを課して、許可されていない発信者が資格のない資格要素を取得できないようにする必要があります。このルーチンは、既存のデータにGSS-APIハンドルを取得するのではなく、そのような関数には新しいメカニズム固有の認証データの作成が含まれるため、「ネットワークへのログイン」機能を提供することを意図したものではありません。このような関数は、必要に応じて、実装固有の拡張ルーチンで定義する必要があります。
If credential acquisition is time-consuming for a mechanism, the mechanism may choose to delay the actual acquisition until the credential is required (e.g. by GSS_Init_sec_context() or GSS_Accept_sec_context()). Such mechanism-specific implementation decisions should be invisible to the calling application; thus a call of GSS_Inquire_cred() immediately following the call of GSS_Acquire_cred() must return valid credential data, and may therefore incur the overhead of a deferred credential acquisition.
資格取得がメカニズムに時間がかかる場合、メカニズムは、資格情報が必要になるまで実際の取得を遅らせることを選択する場合があります（たとえば、gss_init_sec_context（）またはgss_accept_sec_context（））。このようなメカニズム固有の実装決定は、呼び出しアプリケーションには見えない必要があります。したがって、GSS_ACQUIRE_CRED（）の呼び出し直後のGSS_INQUIRE_CRED（）の呼び出しは、有効な資格情報データを返す必要があり、したがって、延期された資格取得のオーバーヘッドが発生する可能性があります。
If GSS_C_NO_CREDENTIAL is specified as input_cred_handle, a non-NULL output_cred_handle must be supplied. For the case of GSS_C_NO_CREDENTIAL as input_cred_handle, GSS_Add_cred() will create the credential referenced by its output_cred_handle based on default behavior. That is, the call will have the same effect as if the caller had previously called GSS_Acquire_cred(), specifying the same usage and passing GSS_C_NO_NAME as the desired_name parameter (thereby obtaining an explicit credential handle corresponding to default behavior), had passed that credential handle to GSS_Add_cred(), and had finally called GSS_Release_cred() on the credential handle received from GSS_Acquire_cred().
GSS_C_NO_CREDENTIALがinput_CRED_HANDLEとして指定されている場合、NON-NULL OUTPUT_CRED_HANDLEを提供する必要があります。input_cred_handleとしてGSS_C_NO_CREDENTIALの場合、GSS_ADD_CRED（）は、デフォルトの動作に基づいてoutput_cred_handleによって参照される資格情報を作成します。つまり、コールは、発信者が以前にgss_acquire_cred（）を呼び出した場合と同じ効果を持ち、同じ使用法を指定し、GSS_C_NO_NAMEを希望_NAMEパラメーターとして渡します（デフォルトの動作に対応する明示的な資格的ハンドルを取得する）は、その認可ハンドルを渡しました。GSS_ADD_CRED（）に、ついにGSS_ACQUIRE_CRED（）から受信した資格情報ハンドルでGSS_RELEASE_CRED（）を呼び出しました。
This routine is expected to be used primarily by context acceptors, since implementations are likely to provide mechanism-specific ways of obtaining GSS-API initiator credentials from the system login process. Some implementations may therefore not support the acquisition of GSS_C_INITIATE or GSS_C_BOTH credentials via GSS_Acquire_cred() for any name other than GSS_C_NO_NAME, or a name resulting from applying GSS_Inquire_context() to an active context, or a name resulting from applying GSS_Inquire_cred() against a credential handle corresponding to default behavior. It is important to recognize that the explicit name which is yielded by resolving a default reference may change over time, e.g., as a result of local credential element management operations outside GSS-API; once resolved, however, the value of such an explicit name will remain constant.
このルーチンは、システムログインプロセスからGSS-APIイニシエーター資格情報を取得するメカニズム固有の方法を提供する可能性が高いため、主にコンテキストアクセプターによって使用されることが期待されています。したがって、一部の実装は、GSS_CQUIRE_CRED（）を介してGSS_CQUIRE_CRED（）を介したGSS_C_INITIATEまたはGSS_C_BOTH資格情報の取得をサポートしていない場合があります。デフォルトの動作に対応するハンドル。デフォルトのリファレンスを解決することで生成される明示的な名前は、GSS-API以外のローカル資格要素管理操作の結果として、時間とともに変更される可能性があることを認識することが重要です。ただし、解決すると、そのような明示的な名前の値は一定のままです。
A caller may provide the value NULL (GSS_C_NO_NAME) for desired_name, which will be interpreted as a request for a credential handle that will invoke default behavior when passed to GSS_Init_sec_context(), if cred_usage is GSS_C_INITIATE or GSS_C_BOTH, or GSS_Accept_sec_context(), if cred_usage is GSS_C_ACCEPT or GSS_C_BOTH.
発信者は、希望_nameの値null（gss_c_no_name）を提供することができます。これは、gss_init_sec_context（）に渡された場合にデフォルトの動作を呼び出す資格情報のリクエストとして解釈されます。GSS_C_ACCEPTまたはGSS_C_OTHです。
The same input desired_name, or default reference, should be used on all GSS_Acquire_cred() and GSS_Add_cred() calls corresponding to a particular credential.
すべてのgss_acquire_cred（）およびgss_add_cred（）呼び出しで特定の資格情報に対応する同じ入力希望_name、またはデフォルトの参照をすべて使用する必要があります。
2.1.5: GSS_Inquire_cred_by_mech call
2.1.5：gss_inquire_cred_by_mech呼び出し
Inputs:
入力：
o cred_handle CREDENTIAL HANDLE -- if GSS_C_NO_CREDENTIAL -- specified, default initiator credentials are queried
o Cred_handle資格情報ハンドル-GSS_C_NO_CREDENTIAL -指定された、デフォルトのイニシエーター資格情報がQUERIEDされます
o mech_type OBJECT IDENTIFIER -- specific mechanism for -- which credentials are being queried
o mech_typeオブジェクト識別子 - 特定のメカニズム - どの資格情報が照会されているか
Outputs:
出力：
o major_status INTEGER,
o Major_status整数、
o minor_status INTEGER,
o minor_status整数、
o cred_name INTERNAL NAME, -- guaranteed to be MN; caller must -- release with GSS_Release_name()
o cred_name内部名、 - mnであることが保証されています。発信者はgss_release_name（）でリリースする必要があります
o lifetime_rec_initiate INTEGER -- in seconds, or reserved value for -- INDEFINITE
o lifetime_rec_initiate integer-秒単位または予約価値 - 無期限
o lifetime_rec_accept INTEGER -- in seconds, or reserved value for -- INDEFINITE
o lifetime_rec_accept integer-秒単位または予約価値 - 無期限
o cred_usage INTEGER, -- 0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY, -- 2=ACCEPT-ONLY
o cred_usage integer、-0 = initiate-and-accept、1 = initiate-only、-2 = accept-only
Return major_status codes:
Major_statusコードを返す：
o GSS_S_COMPLETE indicates that the credentials referenced by the input cred_handle argument were valid, that the mechanism indicated by the input mech_type was represented with elements within those credentials, and that the output cred_name, lifetime_rec_initiate, lifetime_rec_accept, and cred_usage values represent, respectively, the credentials' associated principal name, remaining lifetimes, and suitable usage modes.
o GSS_S_COMPLETEは、入力CRED_HANDLE引数で参照されている資格情報が有効であること、入力MECH_TYPEで示されるメカニズムがそれらの資格情報内の要素で表されたこと、および出力CRED_NAME、LIFETIME_INITIATE、LIFETIME_REC_ACCECT、およびCRED_USAGE値は、それぞれのクレイデンス値を表現することを示しています。関連する主名、残りの寿命、および適切な使用モード。
o GSS_S_NO_CRED indicates that no information could be returned about the referenced credentials, either because the input cred_handle was invalid or because the caller lacks authorization to access the referenced credentials.
o GSS_S_NO_CREDは、入力CRED_HANDLEが無効であるか、呼び出し元が参照された資格情報にアクセスする許可がないため、参照された資格情報について情報を返すことができないことを示しています。
o GSS_S_DEFECTIVE_CREDENTIAL indicates that the referenced credentials are invalid.
o gss_s_defective_credentialは、参照された資格情報が無効であることを示します。
o GSS_S_CREDENTIALS_EXPIRED indicates that the referenced credentials have expired.
o GSS_S_CREDENTIALS_EXPIREDは、参照された資格情報の有効期限が切れていることを示します。
o GSS_S_BAD_MECH indicates that the referenced credentials do not contain elements for the requested mechanism.
o GSS_S_BAD_MECHは、参照された資格情報に要求されたメカニズムの要素が含まれていないことを示します。
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_cred_by_mech() call enables callers in multi-mechanism environments to acquire specific data about available combinations of lifetimes, usage modes, and mechanisms within a credential structure. The lifetime_rec_initiate result indicates the available lifetime for context initiation purposes; the lifetime_rec_accept result indicates the available lifetime for context acceptance purposes.
GSS_INQUIRE_CRED_BY_MECH（）CALLは、マルチメカニズム環境で発信者が、資格構造内の寿命、使用モード、およびメカニズムの利用可能な組み合わせに関する特定のデータを取得できるようにします。lifetime_rec_initiateの結果は、コンテキスト開始目的で利用可能な寿命を示します。lifetime_rec_acceptの結果は、コンテキスト受け入れ目的で利用可能な寿命を示します。
2.2: Context-level calls
2.2：コンテキストレベルの呼び出し
This group of calls is devoted to the establishment and management of security contexts between peers. A context's initiator calls GSS_Init_sec_context(), resulting in generation of a token which the caller passes to the target. At the target, that token is passed to GSS_Accept_sec_context(). Depending on the underlying mech_type and specified options, additional token exchanges may be performed in the course of context establishment; such exchanges are accommodated by GSS_S_CONTINUE_NEEDED status returns from GSS_Init_sec_context() and GSS_Accept_sec_context().
この呼び出しグループは、ピア間のセキュリティコンテキストの確立と管理に専念しています。コンテキストのイニシエーターがGSS_INIT_SEC_CONTEXT（）を呼び出し、発信者がターゲットに渡すトークンの生成をもたらします。ターゲットでは、そのトークンはgss_accept_sec_context（）に渡されます。基礎となるMECH_TYPEおよび指定されたオプションに応じて、コンテキスト確立の過程で追加のトークン交換が実行される場合があります。このような交換は、gss_init_sec_context（）およびgss_accept_sec_context（）からのgss_s_continue_neededステータスのリターンによって収容されます。
Either party to an established context may invoke GSS_Delete_sec_context() to flush context information when a context is no longer required. GSS_Process_context_token() is used to process received tokens carrying context-level control information. GSS_Context_time() allows a caller to determine the length of time for which an established context will remain valid.
確立されたコンテキストのいずれかの当事者は、gss_delete_sec_context（）を呼び出して、コンテキストが不要になったときにコンテキスト情報をフラッシュする場合があります。gss_process_context_token（）は、コンテキストレベルの制御情報を運ぶ受信したトークンを処理するために使用されます。GSS_CONTEXT_TIME（）により、発信者は、確立されたコンテキストが有効なままである時間の長さを決定できます。
GSS_Inquire_context() returns status information describing context characteristics. GSS_Wrap_size_limit() allows a caller to determine the size of a token which will be generated by a GSS_Wrap() operation. GSS_Export_sec_context() and GSS_Import_sec_context() enable transfer of active contexts between processes on an end system.
gss_inquire_context（）は、コンテキストの特性を説明するステータス情報を返します。gss_wrap_size_limit（）を使用すると、発信者はgss_wrap（）操作によって生成されるトークンのサイズを決定できます。gss_export_sec_context（）およびgss_import_sec_context（）エンドシステム上のプロセス間でアクティブコンテキストの転送を有効にします。
2.2.1: GSS_Init_sec_context call
2.2.1：gss_init_sec_contextコール
Inputs:
入力：
o claimant_cred_handle CREDENTIAL HANDLE, -- NULL specifies "use -- default"
o 請求者_cred_handleクレデンシャルハンドル、 - nullは「使用 - デフォルト」を指定します
o input_context_handle CONTEXT HANDLE, -- 0 -- (GSS_C_NO_CONTEXT) specifies "none assigned yet"
o input_context_handleコンテキストハンドル、 - 0-（gss_c_no_context）「まだ割り当てられていない」を指定します
o targ_name INTERNAL NAME,
o targ_name内部名、
o mech_type OBJECT IDENTIFIER, -- NULL parameter specifies "use -- default"
o mech_typeオブジェクト識別子 - nullパラメーターは「使用 - デフォルト」を指定します
o deleg_req_flag BOOLEAN,
o deleg_req_flag boolean、
o mutual_req_flag BOOLEAN,
o untulal_req_flag boolean、
o replay_det_req_flag BOOLEAN,
o repray_det_req_flag boolean、
o sequence_req_flag BOOLEAN,
o sequence_req_flag boolean、
o anon_req_flag BOOLEAN,
o anon_req_flag boolean、
o conf_req_flag BOOLEAN,
o conf_req_flag boolean、
o integ_req_flag BOOLEAN,
o integ_req_flag boolean、
o lifetime_req INTEGER, -- 0 specifies default lifetime
o lifetime_req integer、-0はデフォルトのライフタイムを指定します
o chan_bindings OCTET STRING,
o chan_bindingsオクテット文字列、
o input_token OCTET STRING -- NULL or token received from target
o input_token octet string-ターゲットから受信したnullまたはトークン
Outputs:
出力：
o major_status INTEGER,
o Major_status整数、
o minor_status INTEGER, o output_context_handle CONTEXT HANDLE, -- once returned non-NULL, -- caller must release with GSS_Delete_sec_context()
o minor_status integer、o output_context_handleコンテキストハンドル、-nullを返した後、発信者はgss_delete_sec_context（）でリリースする必要があります
o mech_type OBJECT IDENTIFIER, -- actual mechanism always -- indicated, never NULL; caller should treat as read-only -- and should not attempt to release
o mech_typeオブジェクト識別子 - 常に実際のメカニズム - は示されている、決してnull;発信者は読み取り専用として扱う必要があり、リリースしようとしないでください
o output_token OCTET STRING, -- NULL or token to pass to context -- target; caller must release with GSS_Release_buffer()
o output_token octet string、 - null or token for contextに渡す - ターゲット。発信者はgss_release_buffer（）でリリースする必要があります
o deleg_state BOOLEAN,
o deleg_state boolean、
o mutual_state BOOLEAN,
o 相互_State boolean、
o replay_det_state BOOLEAN,
o repray_det_state boolean、
o sequence_state BOOLEAN,
o sequence_state boolean、
o anon_state BOOLEAN,
o anon_state boolean、
o trans_state BOOLEAN,
o trans_state boolean、
o prot_ready_state BOOLEAN, -- see Section 1.2.7
o prot_ready_state boolean、セクション1.2.7を参照してください
o conf_avail BOOLEAN,
o conf_avail boolean、
o integ_avail BOOLEAN,
o INTEG_AVAIL BOOLEAN、
o lifetime_rec INTEGER -- in seconds, or reserved value for -- INDEFINITE
o lifetime_rec integer-秒単位または予約価値 - 不定
This call may block pending network interactions for those mech_types in which an authentication server or other network entity must be consulted on behalf of a context initiator in order to generate an output_token suitable for presentation to a specified target.
この呼び出しは、指定されたターゲットへのプレゼンテーションに適したoutput_tokenを生成するために、認証サーバーまたは他のネットワークエンティティをコンテキストイニシエーターに代わって相談する必要があるmech_typesの保留中のネットワークインタラクションをブロックする場合があります。
Return major_status codes:
Major_statusコードを返す：
o GSS_S_COMPLETE indicates that context-level information was successfully initialized, and that the returned output_token will provide sufficient information for the target to perform per-message processing on the newly-established context.
o GSS_S_COMPLETEは、コンテキストレベルの情報が正常に初期化され、返されたoutput_Tokenがターゲットが新たに確立されたコンテキストで検索ごとの処理を実行するのに十分な情報を提供することを示しています。
o GSS_S_CONTINUE_NEEDED indicates that control information in the returned output_token must be sent to the target, and that a reply must be received and passed as the input_token argument to a continuation call to GSS_Init_sec_context(), before per-message processing can be performed in conjunction with this context (unless the prot_ready_state value is concurrently returned TRUE).
o GSS_S_CONTINUE_NEEDEDは、返された出力_TOKENの制御情報をターゲットに送信する必要があり、induct_Init_sec_context（）への継続コールへの入力_token引数として、入力_token引数として渡される必要があることを示します。コンテキスト（prot_ready_state値が同時に真の返されない限り）。
o GSS_S_DEFECTIVE_TOKEN indicates that consistency checks performed on the input_token failed, preventing further processing from being performed based on that token.
o gss_s_defective_tokenは、input_tokenで実行された一貫性チェックが失敗し、そのトークンに基づいてさらなる処理が実行されないことを示します。
o GSS_S_DEFECTIVE_CREDENTIAL indicates that consistency checks performed on the credential structure referenced by claimant_cred_handle failed, preventing further processing from being performed using that credential structure.
o gss_s_defective_credentialは、rachant_cred_handleが参照する資格構造で実行される一貫性チェックが失敗し、その資格構造を使用してさらに処理が実行されるのを防ぐことを示します。
o GSS_S_BAD_SIG (GSS_S_BAD_MIC) indicates that the received input_token contains an incorrect integrity check, so context setup cannot be accomplished.
o GSS_S_BAD_SIG（GSS_S_BAD_MIC）は、受信した入力_Tokenに誤った整合性チェックが含まれていることを示しているため、コンテキストのセットアップを達成できません。
o GSS_S_NO_CRED indicates that no context was established, either because the input cred_handle was invalid, because the referenced credentials are valid for context acceptor use only, because the caller lacks authorization to access the referenced credentials, or because the resolution of default credentials failed.
o GSS_S_NO_CREDは、入力CRED_HANDLEが無効であったため、コンテキストが確立されていないことを示しています。これは、参照された資格情報がコンテキストアクセプター使用に対してのみ有効であるためです。
o GSS_S_CREDENTIALS_EXPIRED indicates that the credentials provided through the input claimant_cred_handle argument are no longer valid, so context establishment cannot be completed.
o GSS_S_CREDENTIALS_EXPIREDは、入力請求請求者の引数を介して提供される資格情報がもはや有効ではないことを示しているため、コンテキストの確立は完了できません。
o GSS_S_BAD_BINDINGS indicates that a mismatch between the caller-provided chan_bindings and those extracted from the input_token was detected, signifying a security-relevant event and preventing context establishment. (This result will be returned by GSS_Init_sec_context() only for contexts where mutual_state is TRUE.)
o GSS_S_BAD_BINDINGSは、発信者が提供するCHAN_BINDINGSとinput_Tokenから抽出されたものとの間の不一致が検出され、セキュリティ関連のイベントを示し、コンテキストの確立を防止することを示します。（この結果は、gss_init_sec_context（）によって返されます。
o GSS_S_OLD_TOKEN indicates that the input_token is too old to be checked for integrity. This is a fatal error during context establishment.
o GSS_S_OLD_TOKENは、input_tokenが古すぎて整合性を確認できないことを示します。これは、コンテキスト確立中の致命的なエラーです。
o GSS_S_DUPLICATE_TOKEN indicates that the input token has a correct integrity check, but is a duplicate of a token already processed. This is a fatal error during context establishment.
o GSS_S_DUPLICATION_TOKENは、入力トークンに正しい整合性チェックがあるが、すでに処理されているトークンの複製であることを示します。これは、コンテキスト確立中の致命的なエラーです。
o GSS_S_NO_CONTEXT indicates that no valid context was recognized for the input context_handle provided; this major status will be returned only for successor calls following GSS_S_CONTINUE_ NEEDED status returns.
o GSS_S_NO_CONTEXTは、提供された入力コンテキスト_Handleに対して有効なコンテキストが認識されなかったことを示します。この主要なステータスは、GSS_S_CONTINUE_必要なステータスリターン後の後継コールに対してのみ返されます。
o GSS_S_BAD_NAMETYPE indicates that the provided targ_name is of a type uninterpretable or unsupported by the applicable underlying GSS-API mechanism(s), so context establishment cannot be completed.
o GSS_S_BAD_NAMETYPEは、提供されたTARG_NAMEが、該当する基礎となるGSS-APIメカニズムによって解釈できないか、サポートされていないタイプであることを示しているため、コンテキスト確立を完了できないことを示しています。
o GSS_S_BAD_NAME indicates that the provided targ_name is inconsistent in terms of internally-incorporated type specifier information, so context establishment cannot be accomplished.
o GSS_S_BAD_NAMEは、提供されたTARG_NAMEが内部に組み込まれたタイプの仕様情報の点で一貫性がないことを示しているため、コンテキストの確立は達成できません。
o GSS_S_BAD_MECH indicates receipt of a context establishment token or of a caller request specifying a mechanism unsupported by the local system or with the caller's active credentials
o GSS_S_BAD_MECHは、コンテキスト確立トークンまたはローカルシステムによってサポートされていないメカニズムまたは発信者のアクティブな資格情報を指定する発信者要求の受領を示します
o GSS_S_FAILURE indicates that context setup could not be accomplished for reasons unspecified at the GSS-API level, and that no interface-defined recovery action is available.
o GSS_S_FAILUREは、GSS-APIレベルで不特定の理由でコンテキストのセットアップを達成できなかったこと、およびインターフェイス定義の回復アクションが利用できないことを示しています。
This routine is used by a context initiator, and ordinarily emits an output_token suitable for use by the target within the selected mech_type's protocol. For the case of a multi-step exchange, this output_token will be one in a series, each generated by a successive call. Using information in the credentials structure referenced by claimant_cred_handle, GSS_Init_sec_context() initializes the data structures required to establish a security context with target targ_name.
このルーチンは、コンテキストイニシエーターによって使用され、通常、選択したmech_typeのプロトコル内でターゲットが使用するのに適した出力_tokenを放出します。マルチステップ交換の場合、このoutput_tokenはシリーズの1つであり、それぞれが連続するコールによって生成されます。racionant_cred_handleが参照される資格情報構造で情報を使用すると、gss_init_sec_context（）がターゲットTARG_NAMEでセキュリティコンテキストを確立するために必要なデータ構造を初期化します。
The targ_name may be any valid INTERNAL NAME; it need not be an MN. In addition to support for other name types, it is recommended (newly as of GSS-V2, Update 1) that mechanisms be able to accept GSS_C_NO_NAME as an input type for targ_name. While recommended, such support is not required, and it is recognized that not all mechanisms can construct tokens without explicitly naming the context target, even when mutual authentication of the target is not obtained. Callers wishing to make use of this facility and concerned with portability should be aware that support for GSS_C_NO_NAME as input targ_name type is unlikely to be provided within mechanism definitions specified prior to GSS-V2, Update 1.
TARG_NAMEは、有効な内部名です。Mnである必要はありません。他の名前のタイプのサポートに加えて、メカニズムはGSS_C_NO_NAMEをTARG_NAMEの入力タイプとして受け入れることができることを推奨（新たにGSS-V2、更新1の時点）に推奨されます。推奨されていますが、そのようなサポートは必要ありません。また、ターゲットの相互認証が取得されない場合でも、すべてのメカニズムがコンテキストターゲットを明示的に名前を付けることなくトークンを構築できるわけではないことが認識されています。この施設を利用したい発信者は、入力TARG_NAMEタイプとしてのGSS_C_NO_NAMEのサポートが、GSS-V2、アップデート1の前に指定されたメカニズム定義内で提供される可能性は低いことを認識する必要があります。
The claimant_cred_handle must correspond to the same valid credentials structure on the initial call to GSS_Init_sec_context() and on any successor calls resulting from GSS_S_CONTINUE_NEEDED status returns; different protocol sequences modeled by the GSS_S_CONTINUE_NEEDED facility will require access to credentials at different points in the context establishment sequence.
racionant_cred_handleは、gss_init_sec_context（）への最初の呼び出しと、gss_s_continue_needed returnsに起因する後継コールの同じ有効な資格情報構造に対応する必要があります。GSS_S_CONTINUE_NEEDED機能によってモデル化されたさまざまなプロトコルシーケンスには、コンテキスト確立シーケンスのさまざまなポイントで資格情報へのアクセスが必要です。
The caller-provided input_context_handle argument is to be 0 (GSS_C_NO_CONTEXT), specifying "not yet assigned", on the first GSS_Init_sec_context() call relating to a given context. If successful (i.e., if accompanied by major_status GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED), and only if successful, the initial GSS_Init_sec_context() call returns a non-zero output_context_handle for use in future references to this context. Once a non-zero output_context_handle has been returned, GSS-API callers should call GSS_Delete_sec_context() to release context-related resources if errors occur in later phases of context establishment, or when an established context is no longer required. If GSS_Init_sec_context() is passed the handle of a context which is already fully established, GSS_S_FAILURE status is returned.
発信者が提供するinput_context_handle引数は、最初のgss_init_sec_context（）指定されたコンテキストに関連する「まだ割り当てられていない」を指定し、「まだ割り当てられていない」を指定する0（gss_c_no_context）であることです。成功した場合（つまり、Major_Status GSS_S_CompleteまたはGSS_Continue_Neededを伴う場合）、成功した場合にのみ、最初のGSS_INIT_SEC_CONTEXT（）CALLは、この文脈を参照して使用するZero output_context_handle以外のoutput_context_handleを返します。ゼロ以外のoutput_context_handleが返されると、GSS-API発信者はgss_delete_sec_context（）を呼び出して、コンテキスト確立の後のフェーズでエラーが発生した場合、または確立されたコンテキストが不要になった場合にコンテキスト関連のリソースをリリースする必要があります。gss_init_sec_context（）が既に完全に確立されているコンテキストのハンドルに渡されると、gss_s_failureステータスが返されます。
When continuation attempts to GSS_Init_sec_context() are needed to perform context establishment, the previously-returned non-zero handle value is entered into the input_context_handle argument and will be echoed in the returned output_context_handle argument. On such continuation attempts (and only on continuation attempts) the input_token value is used, to provide the token returned from the context's target.
Continuationがコンテキスト確立を実行するためにGSS_INIT_SEC_CONTEXT（）を試みる場合、以前に回復した非ゼロハンドル値がinput_context_handle引数に入力され、返されたoutput_context_handle引数にエコーされます。このような継続試行（および継続試行のみ）では、input_token値が使用され、コンテキストのターゲットから返されるトークンを提供します。
The chan_bindings argument is used by the caller to provide information binding the security context to security-related characteristics (e.g., addresses, cryptographic keys) of the underlying communications channel. See Section 1.1.6 of this document for more discussion of this argument's usage.
CHAN_BINDINGS引数は、基礎となる通信チャネルのセキュリティ関連の特性（アドレス、暗号化キーなど）にセキュリティコンテキストをバインドする情報を提供するために、発信者によって使用されます。この引数の使用に関する詳細については、このドキュメントのセクション1.1.6を参照してください。
The input_token argument contains a message received from the target, and is significant only on a call to GSS_Init_sec_context() which follows a previous return indicating GSS_S_CONTINUE_NEEDED major_status.
input_token引数には、ターゲットから受信されたメッセージが含まれており、gss_s_continue_needed major_statusを示す以前のリターンに続くgss_init_sec_context（）への呼び出しでのみ重要です。
It is the caller's responsibility to establish a communications path to the target, and to transmit any returned output_token (independent of the accompanying returned major_status value) to the target over that path. The output_token can, however, be transmitted along with the first application-provided input message to be processed by GSS_GetMIC() or GSS_Wrap() in conjunction with a successfully-established context. (Note: when the GSS-V2 prot_ready_state indicator is returned TRUE, it can be possible to transfer a protected message before context establishment is complete: see also Section 1.2.7)
ターゲットへの通信パスを確立し、返されたoutput_token（添付されたmajor_status値とは無関係）をそのパス上のターゲットに送信することは、発信者の責任です。ただし、output_tokenは、gss_getmic（）またはgss_wrap（）によって処理される最初のアプリケーションが提供する入力メッセージとともに送信できます。（注：GSS-V2 ProT_Ready_StateインジケーターがTRUEを返した場合、コンテキストの確立が完了する前に保護されたメッセージを転送することができます。セクション1.2.7も参照）
The initiator may request various context-level functions through input flags: the deleg_req_flag requests delegation of access rights, the mutual_req_flag requests mutual authentication, the replay_det_req_flag requests that replay detection features be applied to messages transferred on the established context, and the sequence_req_flag requests that sequencing be enforced. (See Section 1.2.3 for more information on replay detection and sequencing features.) The anon_req_flag requests that the initiator's identity not be transferred within tokens to be sent to the acceptor.
イニシエーターは、入力フラグを介してさまざまなコンテキストレベルの関数を要求することができます：DELEG_REQ_FLAGはアクセス権の委任、相互_REQ_FLAGリクエスト相互認証、REPRAY_DET_REQ_FLAGリクエスト、リプレイ検出機能は確立されたコンテキストで転送されるメッセージに適用されること、およびシーケンス_REQ_FLAGリクエストのリクエスト。強制される。（リプレイの検出とシーケンス機能の詳細については、セクション1.2.3を参照してください。）ANON_REQ_FLAGは、イニシエーターのIDをトークン内で転送してアクセプターに送信することを要求します。
The conf_req_flag and integ_req_flag provide informatory inputs to the GSS-API implementation as to whether, respectively, per-message confidentiality and per-message integrity services will be required on the context. This information is important as an input to negotiating mechanisms. It is important to recognize, however, that the inclusion of these flags (which are newly defined for GSS-V2) introduces a backward incompatibility with callers implemented to GSS-V1, where the flags were not defined. Since no GSS-V1 callers would set these flags, even if per-message services are desired, GSS-V2 mechanism implementations which enable such services selectively based on the flags' values may fail to provide them to contexts established for GSS-V1 callers. It may be appropriate under certain circumstances, therefore, for such mechanism implementations to infer these service request flags to be set if a caller is known to be implemented to GSS-V1.
conf_req_flagおよびinteg_req_flagは、それぞれ、コンテキストでメッセージごとの機密性と統合ごとの整合性サービスがそれぞれ必要であるかどうかについて、GSS-API実装に情報入力を提供します。この情報は、メカニズムを交渉するための入力として重要です。ただし、これらのフラグ（GSS-V2のために新たに定義されている）を含めると、GSS-V1に実装された発信者との後方互換性が導入され、フラグが定義されていないことを認識することが重要です。GSS-V1の発信者はこれらのフラグを設定しないため、出気ごとのサービスが必要な場合でも、フラグの値に基づいて選択的にそのようなサービスを可能にするGSS-V2メカニズムの実装は、GSS-V1発信者に確立されたコンテキストにそれらを提供できない場合があります。したがって、特定の状況下では、このようなメカニズムの実装が、発信者がGSS-V1に実装されていることが知られていることが知られている場合、これらのサービス要求フラグが設定されるように設定することが適切かもしれません。
Not all of the optionally-requestable features will be available in all underlying mech_types. The corresponding return state values deleg_state, mutual_state, replay_det_state, and sequence_state indicate, as a function of mech_type processing capabilities and initiator-provided input flags, the set of features which will be active on the context. The returned trans_state value indicates whether the context is transferable to other processes through use of GSS_Export_sec_context(). These state indicators' values are undefined unless either the routine's major_status indicates GSS_S_COMPLETE, or TRUE prot_ready_state is returned along with GSS_S_CONTINUE_NEEDED major_status; for the latter case, it is possible that additional features, not confirmed or indicated along with TRUE prot_ready_state, will be confirmed and indicated when GSS_S_COMPLETE is subsequently returned.
すべての基礎となるmech_typesで、オプションの要求可能な機能のすべてが利用できるわけではありません。対応するリターン状態値Deleg_State、umulition_state、Replay_det_state、およびSequence_Stateは、Mech_Type処理機能とイニシエーターが提供する入力フラグの関数として、コンテキストでアクティブな機能のセットとして示されます。返されたtrans_state値は、gss_export_sec_context（）を使用して、コンテキストが他のプロセスに転送可能かどうかを示します。これらの状態指標の値は、ルーチンのMajor_statusがGSS_S_Completeを示しているか、True Prot_ready_StateがGSS_S_S_CONTINUE_NEEDED MASINE_STATUSとともに返されない限り、定義されていません。後者の場合、True Prot_ready_stateとともに確認または示されていない追加機能が確認され、GSS_S_Completeがその後返されたときに確認され、示される可能性があります。
The returned anon_state and prot_ready_state values are significant for both GSS_S_COMPLETE and GSS_S_CONTINUE_NEEDED major_status returns from GSS_Init_sec_context(). When anon_state is returned TRUE, this indicates that neither the current token nor its predecessors delivers or has delivered the initiator's identity. Callers wishing to perform context establishment only if anonymity support is provided should transfer a returned token from GSS_Init_sec_context() to the peer only if it is accompanied by a TRUE anon_state indicator. When prot_ready_state is returned TRUE in conjunction with GSS_S_CONTINUE_NEEDED major_status, this indicates that per-message protection operations may be applied on the context: see Section 1.2.7 for further discussion of this facility.
返されたanon_stateおよびprot_ready_state値は、gss_s_completeとgss_s_continue_needed major_statusの両方でgss_init_sec_context（）の両方で重要です。Anon_StateがTrueを返すと、これは現在のトークンもその前身も、イニシエーターの身元を提供するか、提供していないことを示しています。匿名のサポートが提供されている場合にのみコンテキスト確立を実行したい発信者は、gss_init_sec_context（）から返されたトークンをピアに転送する必要があります。prot_ready_stateがgss_s_s_continue_needed major_statusと併せてtrueを返す場合、これは、この施設の詳細については、セクション1.2.7を参照してください。
Failure to provide the precise set of features requested by the caller does not cause context establishment to fail; it is the caller's prerogative to delete the context if the feature set provided is unsuitable for the caller's use.
発信者が要求した正確な一連の機能を提供しないと、コンテキスト確立が失敗しません。提供された機能セットが発信者の使用に適していない場合、コンテキストを削除することは発信者の特権です。
The returned mech_type value indicates the specific mechanism employed on the context; it will never indicate the value for "default". A valid mech_type result must be returned along with a GSS_S_COMPLETE status return; GSS-API implementations may (but are not required to) also return mech_type along with predecessor calls indicating GSS_S_CONTINUE_NEEDED status or (if a mechanism is determinable) in conjunction with fatal error cases. For the case of mechanisms which themselves perform negotiation, the returned mech_type result may indicate selection of a mechanism identified by an OID different than that passed in the input mech_type argument, and the returned value may change between successive calls returning GSS_S_CONTINUE_NEEDED and the final call returning GSS_S_COMPLETE.
返されたmech_type値は、コンテキストで使用される特定のメカニズムを示します。「デフォルト」の値を示すことはありません。有効なMECH_TYPE結果は、GSS_S_Completeステータスリターンとともに返される必要があります。GSS-APIの実装は、GSS_S_CONTINUE_NEEDEDステータスを示す前任者の呼び出しとともに、MECH_TYPEを致命的なエラーケースと組み合わせて（メカニズムが決定可能である場合）とともにmech_typeを返すこともできます（必要ではありません）。交渉を実行するメカニズムの場合、返されたmech_typeの結果は、入力mech_type引数で渡されたものとは異なるoidによって識別されるメカニズムの選択を示している可能性があります。gss_s_complete。
The conf_avail return value indicates whether the context supports per-message confidentiality services, and so informs the caller whether or not a request for encryption through the conf_req_flag input to GSS_Wrap() can be honored. In similar fashion, the integ_avail return value indicates whether per-message integrity services are available (through either GSS_GetMIC() or GSS_Wrap()) on the established context. These state indicators' values are undefined unless either the routine's major_status indicates GSS_S_COMPLETE, or TRUE prot_ready_state is returned along with GSS_S_CONTINUE_NEEDED major_status.
conf_availのリターン値は、コンテキストが精神ごとの機密保持サービスをサポートするかどうかを示し、gss_wrap（）へのconf_req_flag入力を介した暗号化のリクエストを尊重できるかどうかを発信者に通知します。同様に、INTEG_Availの返品値は、確立されたコンテキストで（gss_getmic（）またはgss_wrap（）のいずれかを介して、統合ごとの整合性サービスが利用可能かどうかを示します。これらの状態指標の値は、ルーチンのMajor_StatusがGSS_S_Completeを示しているか、True Prot_ready_StateがGSS_S_S_CONTINUE_NEEDED MASINE_STATUSとともに返されない限り、定義されていません。
The lifetime_req input specifies a desired upper bound for the lifetime of the context to be established, with a value of 0 used to request a default lifetime. The lifetime_rec return value indicates the length of time for which the context will be valid, expressed as an offset from the present; depending on mechanism capabilities, credential lifetimes, and local policy, it may not correspond to the value requested in lifetime_req. If no constraints on context lifetime are imposed, this may be indicated by returning a reserved value representing INDEFINITE lifetime_req. The value of lifetime_rec is undefined unless the routine's major_status indicates GSS_S_COMPLETE.
lifetime_req入力は、デフォルトの寿命を要求するために値が使用され、確立されるコンテキストの寿命に対して望ましい上限を指定します。lifetime_recリターン値は、現在からのオフセットとして表現されるコンテキストが有効になる時間の長さを示します。メカニズムの能力、資格の寿命、ローカルポリシーに応じて、Lifetime_Reqで要求された値に対応しない場合があります。コンテキストの寿命に制約が課されない場合、これは、無期限のlifetime_reqを表す予約価値を返すことによって示される場合があります。ルーチンのMajor_StatusがGSS_S_Completeを示していない限り、Lifetime_Recの値は未定義です。
If the mutual_state is TRUE, this fact will be reflected within the output_token. A call to GSS_Accept_sec_context() at the target in conjunction with such a context will return a token, to be processed by a continuation call to GSS_Init_sec_context(), in order to achieve mutual authentication.
相互_Stateが真である場合、この事実はoutput_token内に反映されます。このようなコンテキストと組み合わせてターゲットでgss_accept_sec_context（）への呼び出しは、トークンを返し、相互認証を実現するためにgss_init_sec_context（）への継続コールによって処理されます。
2.2.2: GSS_Accept_sec_context call
2.2.2：gss_accept_sec_contextコール
Inputs:
入力：
o acceptor_cred_handle CREDENTIAL HANDLE, -- NULL specifies -- "use default"
o Accedor_cred_handle資格情報ハンドル、-nullは指定 - 「デフォルトを使用」
o input_context_handle CONTEXT HANDLE, -- 0 -- (GSS_C_NO_CONTEXT) specifies "not yet assigned"
o input_context_handleコンテキストハンドル、-0-（gss_c_no_context）は「まだ割り当てられていない」を指定します
o chan_bindings OCTET STRING,
o chan_bindingsオクテット文字列、
o input_token OCTET STRING
o input_tokenオクテット文字列
Outputs:
出力：
o major_status INTEGER,
o Major_status整数、
o minor_status INTEGER,
o minor_status整数、
o src_name INTERNAL NAME, -- guaranteed to be MN -- once returned, caller must release with GSS_Release_name()
o src_name内部名、 - Mnになることが保証されます - 返されると、発信者はgss_release_name（）でリリースする必要があります
o mech_type OBJECT IDENTIFIER, -- caller should treat as -- read-only; does not need to be released
o mech_typeオブジェクト識別子 - 発信者は扱う必要があります - 読み取り専用;リリースする必要はありません
o output_context_handle CONTEXT HANDLE, -- once returned -- non-NULL in context establishment sequence, caller -- must release with GSS_Delete_sec_context()
o output_context_handleコンテキストハンドル - 返されると、コンテキストの確立シーケンスで非ヌル、発信者 - gss_delete_sec_context（）でリリースする必要があります
o deleg_state BOOLEAN,
o deleg_state boolean、
o mutual_state BOOLEAN,
o 相互_State boolean、
o replay_det_state BOOLEAN,
o repray_det_state boolean、
o sequence_state BOOLEAN,
o sequence_state boolean、
o anon_state BOOLEAN,
o anon_state boolean、
o trans_state BOOLEAN,
o trans_state boolean、
o prot_ready_state BOOLEAN, -- see Section 1.2.7 for discussion
o prot_ready_state boolean、ディスカッションについてはセクション1.2.7を参照してください
o conf_avail BOOLEAN,
o conf_avail boolean、
o integ_avail BOOLEAN, o lifetime_rec INTEGER, -- in seconds, or reserved value for -- INDEFINITE
o integ_avail boolean、o lifetime_rec integer、 - 秒単位または予約価値 - 不定
o delegated_cred_handle CREDENTIAL HANDLE, -- if returned non-NULL, -- caller must release with GSS_Release_cred()
o Delegated_cred_handle資格情報ハンドル、 - null以外の返された場合、発信者はgss_release_cred（）でリリースする必要があります
o output_token OCTET STRING -- NULL or token to pass to context -- initiator; if returned non-NULL, caller must release with -- GSS_Release_buffer()
o output_token octet string-コンテキストに渡すためのnullまたはトークン - イニシエーター。非ヌルを返した場合、発信者はgss_release_buffer（）でリリースする必要があります
This call may block pending network interactions for those mech_types in which a directory service or other network entity must be consulted on behalf of a context acceptor in order to validate a received input_token.
この呼び出しは、受信したinput_tokenを検証するために、ディレクトリサービスまたは他のネットワークエンティティをコンテキストアクセプターに代わって相談する必要があるmech_typesの保留中のネットワークインタラクションをブロックする場合があります。
Return major_status codes:
Major_statusコードを返す：
o GSS_S_COMPLETE indicates that context-level data structures were successfully initialized, and that per-message processing can now be performed in conjunction with this context.
o GSS_S_COMPLETEは、コンテキストレベルのデータ構造が正常に初期化され、このコンテキストと組み合わせて処理ごとに実行できることを示しています。
o GSS_S_CONTINUE_NEEDED indicates that control information in the returned output_token must be sent to the initiator, and that a response must be received and passed as the input_token argument to a continuation call to GSS_Accept_sec_context(), before per-message processing can be performed in conjunction with this context.
o gss_s_continue_neededは、返されたoutput_tokenのコントロール情報をイニシエーターに送信する必要があり、input_cept_sec_context（）への継続コールへのinput_token引数としてinput_token引数として応答を受信して渡す必要があることを示します。コンテクスト。
o GSS_S_DEFECTIVE_TOKEN indicates that consistency checks performed on the input_token failed, preventing further processing from being performed based on that token.
o gss_s_defective_tokenは、input_tokenで実行された一貫性チェックが失敗し、そのトークンに基づいてさらなる処理が実行されないことを示します。
o GSS_S_DEFECTIVE_CREDENTIAL indicates that consistency checks performed on the credential structure referenced by acceptor_cred_handle failed, preventing further processing from being performed using that credential structure.
o gss_s_defective_credentialは、Accedor_cred_handleが参照する資格構造で実行される一貫性チェックが失敗し、その資格構造を使用してさらに処理が実行されるのを防ぐことを示します。
o GSS_S_BAD_SIG (GSS_S_BAD_MIC) indicates that the received input_token contains an incorrect integrity check, so context setup cannot be accomplished.
o GSS_S_BAD_SIG（GSS_S_BAD_MIC）は、受信した入力_Tokenに誤った整合性チェックが含まれていることを示しているため、コンテキストのセットアップを達成できません。
o GSS_S_DUPLICATE_TOKEN indicates that the integrity check on the received input_token was correct, but that the input_token was recognized as a duplicate of an input_token already processed. No new context is established.
o GSS_S_DUPLICATION_TOKENは、受信したinput_tokenの整合性チェックが正しいことを示していますが、input_tokenは既に処理されているinput_tokenの複製として認識されていました。新しいコンテキストは確立されていません。
o GSS_S_OLD_TOKEN indicates that the integrity check on the received input_token was correct, but that the input_token is too old to be checked for duplication against previously-processed input_tokens. No new context is established.
o GSS_S_OLD_TOKENは、受信した入力_TOKENの整合性チェックが正しかったが、入力_TOKENが古すぎて以前に処理された入力_Tokensに対する複製をチェックするには古すぎることを示しています。新しいコンテキストは確立されていません。
o GSS_S_NO_CRED indicates that no context was established, either because the input cred_handle was invalid, because the referenced credentials are valid for context initiator use only, because the caller lacks authorization to access the referenced credentials, or because the procedure for default credential resolution failed.
o GSS_S_NO_CREDは、入力CRED_HANDLEが無効であったため、コンテキストが確立されていないことを示しています。これは、参照された資格情報がコンテキスト開始者の使用に対してのみ有効であるためです。
o GSS_S_CREDENTIALS_EXPIRED indicates that the credentials provided through the input acceptor_cred_handle argument are no longer valid, so context establishment cannot be completed.
o GSS_S_CREDENTIALS_EXPIREDは、入力accedor_cred_handle引数を介して提供される資格情報がもはや有効ではないことを示しているため、コンテキストの確立は完了できません。
o GSS_S_BAD_BINDINGS indicates that a mismatch between the caller-provided chan_bindings and those extracted from the input_token was detected, signifying a security-relevant event and preventing context establishment.
o GSS_S_BAD_BINDINGSは、発信者が提供するCHAN_BINDINGSとinput_Tokenから抽出されたものとの間の不一致が検出され、セキュリティ関連のイベントを示し、コンテキストの確立を防止することを示します。
o GSS_S_NO_CONTEXT indicates that no valid context was recognized for the input context_handle provided; this major status will be returned only for successor calls following GSS_S_CONTINUE_ NEEDED status returns.
o GSS_S_NO_CONTEXTは、提供された入力コンテキスト_Handleに対して有効なコンテキストが認識されなかったことを示します。この主要なステータスは、GSS_S_CONTINUE_必要なステータスリターン後の後継コールに対してのみ返されます。
o GSS_S_BAD_MECH indicates receipt of a context establishment token specifying a mechanism unsupported by the local system or with the caller's active credentials.
o GSS_S_BAD_MECHは、ローカルシステムによってサポートされていないメカニズムまたは発信者のアクティブな資格情報を指定するコンテキスト確立トークンの受領を示します。
o GSS_S_FAILURE indicates that context setup could not be accomplished for reasons unspecified at the GSS-API level, and that no interface-defined recovery action is available.
o GSS_S_FAILUREは、GSS-APIレベルで不特定の理由でコンテキストのセットアップを達成できなかったこと、およびインターフェイス定義の回復アクションが利用できないことを示しています。
The GSS_Accept_sec_context() routine is used by a context target. Using information in the credentials structure referenced by the input acceptor_cred_handle, it verifies the incoming input_token and (following the successful completion of a context establishment sequence) returns the authenticated src_name and the mech_type used. The returned src_name is guaranteed to be an MN, processed by the mechanism under which the context was established. The acceptor_cred_handle must correspond to the same valid credentials structure on the initial call to GSS_Accept_sec_context() and on any successor calls resulting from GSS_S_CONTINUE_NEEDED status returns; different protocol sequences modeled by the GSS_S_CONTINUE_NEEDED mechanism will require access to credentials at different points in the context establishment sequence.
gss_accept_sec_context（）ルーチンは、コンテキストターゲットによって使用されます。入力accedor_cred_handleによって参照される資格情報構造の情報を使用して、受信入力_tokenを検証し、（コンテキスト確立シーケンスの正常に完了した後）は、認証されたSRC_NAMEと使用されたMECH_TYPEを返します。返されたSRC_NAMEは、コンテキストが確立されたメカニズムによって処理されるMNであることが保証されています。Acceptor_cred_handleは、gss_accept_sec_context（）への最初の呼び出しと、gss_s_continue_needed returnsに起因する後継コールの同じ有効な資格情報構造に対応する必要があります。GSS_S_CONTINUE_NEEDEDメカニズムによってモデル化されたさまざまなプロトコルシーケンスには、コンテキスト確立シーケンスの異なるポイントで資格情報へのアクセスが必要です。
The caller-provided input_context_handle argument is to be 0 (GSS_C_NO_CONTEXT), specifying "not yet assigned", on the first GSS_Accept_sec_context() call relating to a given context. If successful (i.e., if accompanied by major_status GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED), and only if successful, the initial GSS_Accept_sec_context() call returns a non-zero output_context_handle for use in future references to this context. Once a non-zero output_context_handle has been returned, GSS-API callers should call GSS_Delete_sec_context() to release context-related resources if errors occur in later phases of context establishment, or when an established context is no longer required. If GSS_Accept_sec_context() is passed the handle of a context which is already fully established, GSS_S_FAILURE status is returned.
発信者が提供するinput_context_handle引数は、最初のgss_accept_sec_context（）指定されたコンテキストに関連する「まだ割り当てられていない」を指定し、「まだ割り当てられていない」を指定する0（gss_c_no_context）であることです。成功した場合（つまり、Major_Status GSS_S_COMPLETEまたはGSS_CONTINUE_NEEDEDを伴う場合）、成功した場合にのみ、最初のGSS_ACCEPT_SEC_CONTEXT（）CALLは、この文脈を参照するためにZero Zero output_context_handle以外のoutput_context_handleを返します。ゼロ以外のoutput_context_handleが返されると、GSS-API発信者はgss_delete_sec_context（）を呼び出して、コンテキスト確立の後のフェーズでエラーが発生した場合、または確立されたコンテキストが不要になった場合にコンテキスト関連のリソースをリリースする必要があります。gss_accept_sec_context（）が既に完全に確立されているコンテキストのハンドルに渡された場合、gss_s_failureステータスが返されます。
The chan_bindings argument is used by the caller to provide information binding the security context to security-related characteristics (e.g., addresses, cryptographic keys) of the underlying communications channel. See Section 1.1.6 of this document for more discussion of this argument's usage.
CHAN_BINDINGS引数は、基礎となる通信チャネルのセキュリティ関連の特性（アドレス、暗号化キーなど）にセキュリティコンテキストをバインドする情報を提供するために、発信者によって使用されます。この引数の使用に関する詳細については、このドキュメントのセクション1.1.6を参照してください。
The returned state results (deleg_state, mutual_state, replay_det_state, sequence_state, anon_state, trans_state, and prot_ready_state) reflect the same information as described for GSS_Init_sec_context(), and their values are significant under the same return state conditions.
返された状態の結果（Deleg_state、umulition_state、Replay_det_state、sequence_state、anon_state、trans_state、およびprot_ready_state）は、gss_init_sec_context（）について説明したのと同じ情報を反映しており、それらの値は同じリターン状態条件下で重要です。
The conf_avail return value indicates whether the context supports per-message confidentiality services, and so informs the caller whether or not a request for encryption through the conf_req_flag input to GSS_Wrap() can be honored. In similar fashion, the integ_avail return value indicates whether per-message integrity services are available (through either GSS_GetMIC() or GSS_Wrap()) on the established context. These values are significant under the same return state conditions as described under GSS_Init_sec_context().
conf_availのリターン値は、コンテキストが精神ごとの機密保持サービスをサポートするかどうかを示し、gss_wrap（）へのconf_req_flag入力を介した暗号化のリクエストを尊重できるかどうかを発信者に通知します。同様に、INTEG_Availの返品値は、確立されたコンテキストで（gss_getmic（）またはgss_wrap（）のいずれかを介して、統合ごとの整合性サービスが利用可能かどうかを示します。これらの値は、gss_init_sec_context（）で説明されているのと同じ戻り状態条件の下で重要です。
The lifetime_rec return value is significant only in conjunction with GSS_S_COMPLETE major_status, and indicates the length of time for which the context will be valid, expressed as an offset from the present.
lifetime_recのリターン値は、gss_s_complete major_statusとのみ重要であり、コンテキストが有効になる時間の長さを示し、現在からのオフセットとして表現されます。
The returned mech_type value indicates the specific mechanism employed on the context; it will never indicate the value for "default". A valid mech_type result must be returned whenever GSS_S_COMPLETE status is indicated; GSS-API implementations may (but are not required to) also return mech_type along with predecessor calls indicating GSS_S_CONTINUE_NEEDED status or (if a mechanism is determinable) in conjunction with fatal error cases. For the case of mechanisms which themselves perform negotiation, the returned mech_type result may indicate selection of a mechanism identified by an OID different than that passed in the input mech_type argument, and the returned value may change between successive calls returning GSS_S_CONTINUE_NEEDED and the final call returning GSS_S_COMPLETE.
返されたmech_type値は、コンテキストで使用される特定のメカニズムを示します。「デフォルト」の値を示すことはありません。GSS_S_COMPLETEステータスが示されるたびに、有効なMECH_TYPE結果を返す必要があります。GSS-APIの実装は、GSS_S_CONTINUE_NEEDEDステータスを示す前任者の呼び出しとともに、MECH_TYPEを致命的なエラーケースと組み合わせて（メカニズムが決定可能である場合）とともにmech_typeを返すこともできます（必要ではありません）。交渉を実行するメカニズムの場合、返されたmech_typeの結果は、入力mech_type引数で渡されたものとは異なるoidによって識別されるメカニズムの選択を示している可能性があります。gss_s_complete。
The delegated_cred_handle result is significant only when deleg_state is TRUE, and provides a means for the target to reference the delegated credentials. The output_token result, when non-NULL, provides a context-level token to be returned to the context initiator to continue a multi-step context establishment sequence. As noted with GSS_Init_sec_context(), any returned token should be transferred to the context's peer (in this case, the context initiator), independent of the value of the accompanying returned major_status.
Delegated_cred_handleの結果は、Deleg_Stateが真である場合にのみ重要であり、ターゲットが委任された資格情報を参照する手段を提供します。output_tokenの結果は、非ヌルの場合、コンテキストレベルのトークンを提供して、コンテキストイニシエーターに返され、マルチステップコンテキスト確立シーケンスを継続します。GSS_INIT_SEC_CONTEXT（）に記載されているように、返されたトークンは、添付されたMASINE_STATUSの値とは無関係に、コンテキストのピア（この場合はコンテキストイニシエーター）に転送する必要があります。
Note: A target must be able to distinguish a context-level input_token, which is passed to GSS_Accept_sec_context(), from the per-message data elements passed to GSS_VerifyMIC() or GSS_Unwrap(). These data elements may arrive in a single application message, and GSS_Accept_sec_context() must be performed before per-message processing can be performed successfully.
注：ターゲットは、gss_verifymic（）またはgss_unwrap（）に渡されたメッセージごとのデータ要素から、gss_accept_sec_context（）に渡されるコンテキストレベルのinput_tokenを区別できる必要があります。これらのデータ要素は単一のアプリケーションメッセージに到着する場合があり、gss_accept_sec_context（）を実行する前に実行する必要があります。
2.2.3: GSS_Delete_sec_context call
2.2.3：gss_delete_sec_context呼び出し
Input:
入力：
o context_handle CONTEXT HANDLE
o Context_handleコンテキストハンドル
Outputs:
出力：
o major_status INTEGER,
o Major_status整数、
o minor_status INTEGER,
o minor_status整数、
o output_context_token OCTET STRING
o output_context_token octet文字列
Return major_status codes:
Major_statusコードを返す：
o GSS_S_COMPLETE indicates that the context was recognized, and that relevant context-specific information was flushed. If the caller provides a non-null buffer to receive an output_context_token, and the mechanism returns a non-NULL token into that buffer, the returned output_context_token is ready for transfer to the context's peer.
o GSS_S_Completeは、コンテキストが認識され、関連するコンテキスト固有の情報がフラッシュされたことを示します。発信者がoutput_context_tokenを受信するために非ヌルバッファーを提供し、メカニズムが非ヌルトークンをそのバッファーに戻すと、returned output_context_tokenはコンテキストのピアに転送する準備ができています。
o GSS_S_NO_CONTEXT indicates that no valid context was recognized for the input context_handle provided, so no deletion was performed.
o GSS_S_NO_CONTEXTは、提供された入力コンテキスト_Handleに対して有効なコンテキストが認識されていないことを示しているため、削除は実行されませんでした。
o GSS_S_FAILURE indicates that the context is recognized, but that the GSS_Delete_sec_context() operation could not be performed for reasons unspecified at the GSS-API level.
o GSS_S_FAILUREは、コンテキストが認識されているが、GSS-APIレベルでは不特定の理由でGSS_DELETE_SEC_CONTEXT（）操作を実行できなかったことを示しています。
This call can be made by either peer in a security context, to flush context-specific information. Once a non-zero output_context_handle has been returned by context establishment calls, GSS-API callers should call GSS_Delete_sec_context() to release context-related resources if errors occur in later phases of context establishment, or when an established context is no longer required. This call may block pending network interactions for mech_types in which active notification must be made to a central server when a security context is to be deleted.
この呼び出しは、コンテキスト固有の情報をフラッシュするために、セキュリティコンテキストでのピアによって行うことができます。ゼロ以外のoutput_context_handleがコンテキスト確立コールによって返されると、GSS-API発信者はgss_delete_sec_context（）を呼び出して、コンテキストに関連するコンテキスト確立の後の段階でエラーが発生した場合、または確立されたコンテキストが不要になった場合にコンテキスト関連のリソースをリリースする必要があります。この呼び出しは、セキュリティコンテキストを削除するときに中央サーバーにアクティブな通知を行う必要があるmech_typesの保留中のネットワークインタラクションをブロックする場合があります。
If a non-null output_context_token parameter is provided by the caller, an output_context_token may be returned to the caller. If an output_context_token is provided to the caller, it can be passed to the context's peer to inform the peer's GSS-API implementation that the peer's corresponding context information can also be flushed. (Once a context is established, the peers involved are expected to retain cached credential and context-related information until the information's expiration time is reached or until a GSS_Delete_sec_context() call is made.)
null output_context_tokenパラメーターが発信者によって提供されている場合、output_context_tokenが発信者に返される場合があります。output_context_tokenが発信者に提供される場合、ピアのGSS-API実装に、ピアの対応するコンテキスト情報もフラッシュできることをピアのGSS-API実装に通知するために、コンテキストのピアに渡すことができます。（コンテキストが確立されると、関係するピアは、情報の有効期限に達するまで、またはGSS_DELETE_SEC_CONTEXT（）呼び出しが行われるまで、キャッシュされた資格情報とコンテキスト関連情報を保持することが期待されます。
The facility for context_token usage to signal context deletion is retained for compatibility with GSS-API Version 1. For current usage, it is recommended that both peers to a context invoke GSS_Delete_sec_context() independently, passing a null output_context_token buffer to indicate that no context_token is required. Implementations of GSS_Delete_sec_context() should delete relevant locally-stored context information.
Context_Tokenの使用のための機能コンテキスト削除を信号する施設は、GSS-APIバージョン1との互換性のために保持されます。現在の使用については、両方のピアがコンテキストへの両方のピアを個別に呼び出し、null output_context_tokenバッファーを渡すことをお勧めします。必須。gss_delete_sec_context（）の実装は、関連するローカルに保存されたコンテキスト情報を削除する必要があります。
Attempts to perform per-message processing on a deleted context will result in error returns.
削除されたコンテキストでメサージごとの処理を実行しようとすると、エラーリターンが発生します。
2.2.4: GSS_Process_context_token call
2.2.4：gss_process_context_token call
Inputs:
入力：
o context_handle CONTEXT HANDLE,
o Context_handleコンテキストハンドル、
o input_context_token OCTET STRING
o input_context_token octet文字列
Outputs:
出力：
o major_status INTEGER,
o Major_status整数、
o minor_status INTEGER, Return major_status codes:
o minor_status integer、return major_statusコード：
o GSS_S_COMPLETE indicates that the input_context_token was successfully processed in conjunction with the context referenced by context_handle.
o gss_s_completeは、input_context_tokenがContext_handleで参照されるコンテキストと組み合わせて正常に処理されたことを示します。
o GSS_S_DEFECTIVE_TOKEN indicates that consistency checks performed on the received context_token failed, preventing further processing from being performed with that token.
o gss_s_defective_tokenは、受信したContext_tokenで実行された一貫性チェックが失敗し、そのトークンでさらに処理が実行されないことを示します。
o GSS_S_NO_CONTEXT indicates that no valid context was recognized for the input context_handle provided.
o GSS_S_NO_CONTEXTは、提供された入力コンテキスト_Handleに対して有効なコンテキストが認識されなかったことを示します。
o GSS_S_FAILURE indicates that the context is recognized, but that the GSS_Process_context_token() operation could not be performed for reasons unspecified at the GSS-API level.
o GSS_S_FAILUREは、コンテキストが認識されていることを示していますが、GSS-APIレベルで不特定の理由でGSS_Process_Context_Token（）操作を実行できなかったことを示します。
This call is used to process context_tokens received from a peer once a context has been established, with corresponding impact on context-level state information. One use for this facility is processing of the context_tokens generated by GSS_Delete_sec_context(); GSS_Process_context_token() will not block pending network interactions for that purpose. Another use is to process tokens indicating remote-peer context establishment failures after the point where the local GSS-API implementation has already indicated GSS_S_COMPLETE status.
この呼び出しは、コンテキストが確立されたら、ピアから受信したコンテキスト_TOKENSを処理するために使用され、コンテキストレベルの状態情報に対応する影響を受けます。この機能の1つの用途は、gss_delete_sec_context（）;によって生成されたContext_tokensの処理です。gss_process_context_token（）は、その目的のために保留中のネットワークインタラクションをブロックしません。別の用途は、ローカルGSS-APIの実装が既にGSS_S_Completeステータスを示しているポイントの後に、リモートピアコンテキストの確立障害を示すトークンを処理することです。
2.2.5: GSS_Context_time call
2.2.5：gss_context_timeコール
Input:
入力：
o context_handle CONTEXT HANDLE,
o Context_handleコンテキストハンドル、
Outputs:
出力：
o major_status INTEGER,
o Major_status整数、
o minor_status INTEGER,
o minor_status整数、
o lifetime_rec INTEGER -- in seconds, or reserved value for -- INDEFINITE
o lifetime_rec integer-秒単位または予約価値 - 不定
Return major_status codes:
Major_statusコードを返す：
o GSS_S_COMPLETE indicates that the referenced context is valid, and will remain valid for the amount of time indicated in lifetime_rec.
o GSS_S_COMPLETEは、参照されるコンテキストが有効であることを示し、Lifetime_Recに示されている時間に対して有効なままであることを示します。
o GSS_S_CONTEXT_EXPIRED indicates that data items related to the referenced context have expired.
o gss_s_context_expiredは、参照されるコンテキストに関連するデータ項目が有効期限が切れていることを示します。
o GSS_S_NO_CONTEXT indicates that no valid context was recognized for the input context_handle provided.
o GSS_S_NO_CONTEXTは、提供された入力コンテキスト_Handleに対して有効なコンテキストが認識されなかったことを示します。
o GSS_S_FAILURE indicates that the requested operation failed for reasons unspecified at the GSS-API level.
o GSS_S_FAILUREは、要求された操作がGSS-APIレベルで不特定の理由で失敗したことを示しています。
This call is used to determine the amount of time for which a currently established context will remain valid.
この呼び出しは、現在確立されているコンテキストが有効なままである時間を決定するために使用されます。
2.2.6: GSS_Inquire_context call
2.2.6：gss_inquire_context呼び出し
Input:
入力：
o context_handle CONTEXT HANDLE,
o Context_handleコンテキストハンドル、
Outputs:
出力：
o major_status INTEGER,
o Major_status整数、
o minor_status INTEGER,
o minor_status整数、
o src_name INTERNAL NAME, -- name of context initiator, -- guaranteed to be MN; -- caller must release with GSS_Release_name() if returned
o src_name内部名、 - コンテキストイニシエーターの名前、 - mnであることが保証されています。-Callerはgss_release_name（）でリリースする必要があります
o targ_name INTERNAL NAME, -- name of context target, -- guaranteed to be MN; -- caller must release with GSS_Release_name() if returned
o targ_name内部名、 - コンテキストターゲットの名前、 - mnであることが保証されています。-Callerはgss_release_name（）でリリースする必要があります
o lifetime_rec INTEGER -- in seconds, or reserved value for -- INDEFINITE or EXPIRED
o lifetime_rec integer-秒単位または予約価値 - 無期限または期限切れ
o mech_type OBJECT IDENTIFIER, -- the mechanism supporting this -- security context; caller should treat as read-only and not -- attempt to release
o mech_typeオブジェクト識別子 - これをサポートするメカニズム - セキュリティコンテキスト。発信者は読み取り専用として扱うべきであり、リリースしようとする必要があります
o deleg_state BOOLEAN,
o deleg_state boolean、
o mutual_state BOOLEAN,
o 相互_State boolean、
o replay_det_state BOOLEAN,
o repray_det_state boolean、
o sequence_state BOOLEAN,
o sequence_state boolean、
o anon_state BOOLEAN, o trans_state BOOLEAN,
o anon_state boolean、o trans_state boolean、
o prot_ready_state BOOLEAN,
o prot_ready_state boolean、
o conf_avail BOOLEAN,
o conf_avail boolean、
o integ_avail BOOLEAN,
o INTEG_AVAIL BOOLEAN、
o locally_initiated BOOLEAN, -- TRUE if initiator, FALSE if acceptor
o locally_initiated boolean、 - イニシエーターの場合、acceptorの場合はfalse
o open BOOLEAN, -- TRUE if context fully established, FALSE -- if partly established (in CONTINUE_NEEDED state)
o Open Boolean、 - Contextが完全に確立されている場合はTrue、false-部分的に確立されている場合（continue_needed State）
Return major_status codes:
Major_statusコードを返す：
o GSS_S_COMPLETE indicates that the referenced context is valid and that deleg_state, mutual_state, replay_det_state, sequence_state, anon_state, trans_state, prot_ready_state, conf_avail, integ_avail, locally_initiated, and open return values describe the corresponding characteristics of the context. If open is TRUE, lifetime_rec is also returned: if open is TRUE and the context peer's name is known, src_name and targ_name are valid in addition to the values listed above. The mech_type value must be returned for contexts where open is TRUE and may be returned for contexts where open is FALSE.
o gss_s_completeは、参照されるコンテキストが有効であること、およびdeleg_state、mulute_state、repray_det_state、sequence_state、anon_state、trans_state、prot_ready_state、conf_avail、integ_avail、localally_initiate、およびopen return valuesが、コンテキストの対応する特性を説明することを示します。オープンが真である場合、lifetime_recも返されます。オープンが真であり、コンテキストピアの名前がわかっている場合、src_nameとtarg_nameは上記の値に加えて有効です。mech_type値は、開くことが真であり、オープンがfalseのコンテキストで返される場合があるコンテキストに対して返される必要があります。
o GSS_S_NO_CONTEXT indicates that no valid context was recognized for the input context_handle provided. Return values other than major_status and minor_status are undefined.
o GSS_S_NO_CONTEXTは、提供された入力コンテキスト_Handleに対して有効なコンテキストが認識されなかったことを示します。Major_statusおよびminor_status以外の返品値は未定義です。
o GSS_S_FAILURE indicates that the requested operation failed for reasons unspecified at the GSS-API level. Return values other than major_status and minor_status are undefined.
o GSS_S_FAILUREは、要求された操作がGSS-APIレベルで不特定の理由で失敗したことを示しています。Major_statusおよびminor_status以外の返品値は未定義です。
This call is used to extract information describing characteristics of a security context. Note that GSS-API implementations are expected to retain inquirable context data on a context until the context is released by a caller, even after the context has expired, although underlying cryptographic data elements may be deleted after expiration in order to limit their exposure.
この呼び出しは、セキュリティコンテキストの特性を説明する情報を抽出するために使用されます。GSS-APIの実装は、コンテキストが期限切れになった後でも、コンテキストが発信者によってリリースされるまでコンテキスト上の問い合わせ可能なコンテキストデータを保持することが期待されていることに注意してください。
2.2.7: GSS_Wrap_size_limit call
2.2.7：gss_wrap_size_limitコール
Inputs:
入力：
o context_handle CONTEXT HANDLE,
o Context_handleコンテキストハンドル、
o conf_req_flag BOOLEAN, o qop INTEGER,
o conf_req_flag boolean、o qop integer、
o output_size INTEGER
o output_size integer
Outputs:
出力：
o major_status INTEGER,
o Major_status整数、
o minor_status INTEGER,
o minor_status整数、
o max_input_size INTEGER
o max_input_size integer
Return major_status codes:
Major_statusコードを返す：
o GSS_S_COMPLETE indicates a successful token size determination: an input message with a length in octets equal to the returned max_input_size value will, when passed to GSS_Wrap() for processing on the context identified by the context_handle parameter with the confidentiality request state as provided in conf_req_flag and with the quality of protection specifier provided in the qop parameter, yield an output token no larger than the value of the provided output_size parameter.
o gss_s_completeは、成功したトークンサイズの決定を示します。返されたmax_input_size値に等しいオクテットの長さの入力メッセージは、context_req_flagおよびconfreq_flagおよび提供されるコンキシデントリクエスト状態で識別されたコンテキストで識別されるコンテキストで処理するためにgss_wrap（）に渡された場合になります。QOPパラメーターに提供される保護仕様の品質により、提供されたoutput_sizeパラメーターの値より大きくない出力トークンを生成します。
o GSS_S_CONTEXT_EXPIRED indicates that the provided input context_handle is recognized, but that the referenced context has expired. Return values other than major_status and minor_status are undefined.
o GSS_S_CONTEXT_EXPIREDは、提供された入力コンテキスト_Handleが認識されているが、参照されるコンテキストが有効期限が切れていることを示します。Major_statusおよびminor_status以外の返品値は未定義です。
o GSS_S_NO_CONTEXT indicates that no valid context was recognized for the input context_handle provided. Return values other than major_status and minor_status are undefined.
o GSS_S_NO_CONTEXTは、提供された入力コンテキスト_Handleに対して有効なコンテキストが認識されなかったことを示します。Major_statusおよびminor_status以外の返品値は未定義です。
o GSS_S_BAD_QOP indicates that the provided QOP value is not recognized or supported for the context.
o GSS_S_BAD_QOPは、提供されたQOP値がコンテキストに対して認識またはサポートされていないことを示します。
o GSS_S_FAILURE indicates that the requested operation failed for reasons unspecified at the GSS-API level. Return values other than major_status and minor_status are undefined.
o GSS_S_FAILUREは、要求された操作がGSS-APIレベルで不特定の理由で失敗したことを示しています。Major_statusおよびminor_status以外の返品値は未定義です。
This call is used to determine the largest input datum which may be passed to GSS_Wrap() without yielding an output token larger than a caller-specified value.
この呼び出しは、発信者指定値よりも大きい出力トークンを生成せずにgss_wrap（）に渡すことができる最大の入力データムを決定するために使用されます。
2.2.8: GSS_Export_sec_context call
2.2.8：gss_export_sec_contextコール
Inputs:
入力：
o context_handle CONTEXT HANDLE
o Context_handleコンテキストハンドル
Outputs:
出力：
o major_status INTEGER,
o Major_status整数、
o minor_status INTEGER,
o minor_status整数、
o interprocess_token OCTET STRING -- caller must release -- with GSS_Release_buffer()
o interprocess_token octet string-発信者はリリースする必要があります-GSS_RELEASE_BUFFER（）
Return major_status codes:
Major_statusコードを返す：
o GSS_S_COMPLETE indicates that the referenced context has been successfully exported to a representation in the interprocess_token, and is no longer available for use by the caller.
o GSS_S_Completeは、参照されるコンテキストがInterProcess_Tokenの表現に正常にエクスポートされており、発信者が使用できなくなったことを示しています。
o GSS_S_UNAVAILABLE indicates that the context export facility is not available for use on the referenced context. (This status should occur only for contexts for which the trans_state value is FALSE.) Return values other than major_status and minor_status are undefined.
o GSS_S_UNAVAILABLEは、コンテキストエクスポート機能が参照されるコンテキストで使用できないことを示しています。（このステータスは、trans_state値がfalseであるコンテキストに対してのみ発生する必要があります。）Majoy_statusおよびminor_status以外の返品値は未定義です。
o GSS_S_CONTEXT_EXPIRED indicates that the provided input context_handle is recognized, but that the referenced context has expired. Return values other than major_status and minor_status are undefined.
o GSS_S_CONTEXT_EXPIREDは、提供された入力コンテキスト_Handleが認識されているが、参照されるコンテキストが有効期限が切れていることを示します。Major_statusおよびminor_status以外の返品値は未定義です。
o GSS_S_NO_CONTEXT indicates that no valid context was recognized for the input context_handle provided. Return values other than major_status and minor_status are undefined.
o GSS_S_NO_CONTEXTは、提供された入力コンテキスト_Handleに対して有効なコンテキストが認識されなかったことを示します。Major_statusおよびminor_status以外の返品値は未定義です。
o GSS_S_FAILURE indicates that the requested operation failed for reasons unspecified at the GSS-API level. Return values other than major_status and minor_status are undefined.
o GSS_S_FAILUREは、要求された操作がGSS-APIレベルで不特定の理由で失敗したことを示しています。Major_statusおよびminor_status以外の返品値は未定義です。
This call generates an interprocess token for transfer to another process within an end system, in order to transfer control of a security context to that process. The recipient of the interprocess token will call GSS_Import_sec_context() to accept the transfer. The GSS_Export_sec_context() operation is defined for use only with security contexts which are fully and successfully established (i.e., those for which GSS_Init_sec_context() and GSS_Accept_sec_context() have returned GSS_S_COMPLETE major_status).
この呼び出しは、セキュリティコンテキストの制御をそのプロセスに転送するために、エンドシステム内の別のプロセスに転送するためのプロセストークンを生成します。インタープロセストークンの受信者は、gss_import_sec_context（）を呼び出して転送を受け入れます。gss_export_sec_context（）操作は、完全かつ正常に確立されたセキュリティコンテキスト（つまり、gss_init_sec_context（）およびgss_accept_sec_context（）がgss_s_s_complete_status）を返したセキュリティコンテキストでのみ使用するために定義されます。
A successful GSS_Export_sec_context() operation deactivates the security context for the calling process; for this case, the GSS-API implementation shall deallocate all process-wide resources associated with the security context and shall set the context_handle to GSS_C_NO_CONTEXT. In the event of an error that makes it impossible to complete export of the security context, the GSS-API implementation must not return an interprocess token and should strive to leave the security context referenced by the context_handle untouched. If this is impossible, it is permissible for the implementation to delete the security context, provided that it also sets the context_handle parameter to GSS_C_NO_CONTEXT.
成功したgss_export_sec_context（）操作呼び出しプロセスのセキュリティコンテキストを非アクティブ化します。この場合、GSS-API実装は、セキュリティコンテキストに関連付けられたすべてのプロセス全体のリソースを扱い、Context_HandleをGSS_C_NO_CONTEXTに設定するものとします。セキュリティコンテキストのエクスポートを完了することを不可能にするエラーが発生した場合、GSS-APIの実装は、インタープロセストークンを返してはなりません。これが不可能な場合は、Context_HandleパラメーターをGSS_C_NO_CONTEXTに設定すると、実装がセキュリティコンテキストを削除することが許可されます。
Portable callers must not assume that a given interprocess token can be imported by GSS_Import_sec_context() more than once, thereby creating multiple instantiations of a single context. GSS-API implementations may detect and reject attempted multiple imports, but are not required to do so.
ポータブル発信者は、特定のインタープロセストークンをgss_import_sec_context（）によって複数回インポートできると想定してはなりません。これにより、単一のコンテキストの複数のインスタンス化が作成されます。GSS-APIの実装は、試行された複数の輸入を検出および拒否する場合がありますが、そうする必要はありません。
The internal representation contained within the interprocess token is an implementation-defined local matter. Interprocess tokens cannot be assumed to be transferable across different GSS-API implementations.
インタープロセストークン内に含まれる内部表現は、実装定義のローカル問題です。インタープロセストークンは、さまざまなGSS-API実装で転送可能であると想定できません。
It is recommended that GSS-API implementations adopt policies suited to their operational environments in order to define the set of processes eligible to import a context, but specific constraints in this area are local matters. Candidate examples include transfers between processes operating on behalf of the same user identity, or processes comprising a common job. However, it may be impossible to enforce such policies in some implementations.
GSS-API実装は、コンテキストをインポートする資格のあるプロセスのセットを定義するために、運用環境に適したポリシーを採用することをお勧めしますが、この分野の特定の制約はローカルな問題です。候補の例には、同じユーザーIDに代わって動作するプロセス間の転送、または共通のジョブを含むプロセスが含まれます。ただし、一部の実装でそのようなポリシーを実施することは不可能かもしれません。
In support of the above goals, implementations may protect the transferred context data by using cryptography to protect data within the interprocess token, or by using interprocess tokens as a means to reference local interprocess communication facilities (protected by other means) rather than storing the context data directly within the tokens.
上記の目標をサポートするために、実装は、コンテキストを保存するのではなく、ローカルプロセス通信施設（他の手段で保護）を参照する手段として、インタープロセストークン内のデータを保護するために暗号化を使用して、インタープロセストークンを使用することにより、転送されたコンテキストデータを保護する場合があります。トークン内のデータ。
Transfer of an open context may, for certain mechanisms and implementations, reveal data about the credential which was used to establish the context. Callers should, therefore, be cautious about the trustworthiness of processes to which they transfer contexts. Although the GSS-API implementation may provide its own set of protections over the exported context, the caller is responsible for protecting the interprocess token from disclosure, and for taking care that the context is transferred to an appropriate destination process.
オープンコンテキストの転送は、特定のメカニズムと実装について、コンテキストを確立するために使用された資格情報に関するデータを明らかにする場合があります。したがって、発信者は、コンテキストを転送するプロセスの信頼性について注意する必要があります。GSS-APIの実装は、エクスポートされたコンテキストを介した独自の保護セットを提供する可能性がありますが、発信者は、インタープロセストークンを開示から保護し、コンテキストが適切な宛先プロセスに転送されることに注意を払う責任があります。
2.2.9: GSS_Import_sec_context call
2.2.9：gss_import_sec_contextコール
Inputs:
入力：
o interprocess_token OCTET STRING
o interprocess_tokenオクテット文字列
Outputs:
出力：
o major_status INTEGER,
o Major_status整数、
o minor_status INTEGER,
o minor_status整数、
o context_handle CONTEXT HANDLE -- if successfully returned, -- caller must release with GSS_Delete_sec_context()
o Context_handleコンテキストハンドル - 正常に返された場合、発信者はgss_delete_sec_context（）でリリースする必要があります
Return major_status codes:
Major_statusコードを返す：
o GSS_S_COMPLETE indicates that the context represented by the input interprocess_token has been successfully transferred to the caller, and is available for future use via the output context_handle.
o GSS_S_COMPLETEは、入力InterProcess_Tokenで表されるコンテキストが発信者に正常に転送され、output Context_handleを介して将来使用できることを示します。
o GSS_S_NO_CONTEXT indicates that the context represented by the input interprocess_token was invalid. Return values other than major_status and minor_status are undefined.
o GSS_S_NO_CONTEXTは、入力interprocess_tokenで表されるコンテキストが無効であることを示します。Major_statusおよびminor_status以外の返品値は未定義です。
o GSS_S_DEFECTIVE_TOKEN indicates that the input interprocess_token was defective. Return values other than major_status and minor_status are undefined.
o gss_s_defective_tokenは、入力interprocess_tokenに欠陥があることを示します。Major_statusおよびminor_status以外の返品値は未定義です。
o GSS_S_UNAVAILABLE indicates that the context import facility is not available for use on the referenced context. Return values other than major_status and minor_status are undefined.
o GSS_S_UNAVAILABLEは、コンテキストインポート機能が参照されるコンテキストで使用できないことを示しています。Major_statusおよびminor_status以外の返品値は未定義です。
o GSS_S_UNAUTHORIZED indicates that the context represented by the input interprocess_token is unauthorized for transfer to the caller. Return values other than major_status and minor_status are undefined.
o GSS_S_UNAUTHORIZEDは、入力interprocess_tokenで表されるコンテキストが発信者への転送に対して不正であることを示します。Major_statusおよびminor_status以外の返品値は未定義です。
o GSS_S_FAILURE indicates that the requested operation failed for reasons unspecified at the GSS-API level. Return values other than major_status and minor_status are undefined.
o GSS_S_FAILUREは、要求された操作がGSS-APIレベルで不特定の理由で失敗したことを示しています。Major_statusおよびminor_status以外の返品値は未定義です。
This call processes an interprocess token generated by GSS_Export_sec_context(), making the transferred context available for use by the caller. After a successful GSS_Import_sec_context() operation, the imported context is available for use by the importing process. In particular, the imported context is usable for all per-message operations and may be deleted or exported by its importer. The inability to receive delegated credentials through gss_import_sec_context() precludes establishment of new contexts based on information delegated to the importer's end system within the context which is being imported, unless those delegated credentials are obtained through separate routines (e.g., XGSS-API calls) outside the GSS-V2 definition.
この呼び出しは、gss_export_sec_context（）によって生成されたインタープロセストークンを処理し、転送されたコンテキストを発信者が使用できるようにします。gss_import_sec_context（）操作が成功した後、インポートされたコンテキストはインポートプロセスで使用できます。特に、輸入されたコンテキストはすべてのメッセージごとの操作に使用可能であり、輸入業者によって削除またはエクスポートされる場合があります。gss_import_sec_context（）を介して委任された資格情報を受け取ることができないことは、委任された資格が別々のルーチン（xgss-apiコールなど）を介して取得されない限り、インポートされているコンテキスト内のインポーターの最終システムに委任された情報に基づいて、新しいコンテキストの確立を排除します。GSS-V2定義。
For further discussion of the security and authorization issues regarding this call, please see the discussion in Section 2.2.8.
この呼び出しに関するセキュリティと承認の問題の詳細については、セクション2.2.8の議論をご覧ください。
2.3: Per-message calls
2.3：メッセージごとの呼び出し
This group of calls is used to perform per-message protection processing on an established security context. None of these calls block pending network interactions. These calls may be invoked by a context's initiator or by the context's target. The four members of this group should be considered as two pairs; the output from GSS_GetMIC() is properly input to GSS_VerifyMIC(), and the output from GSS_Wrap() is properly input to GSS_Unwrap().
このコールのグループは、確立されたセキュリティコンテキストでメッセージごとの保護処理を実行するために使用されます。これらの呼び出しは、保留中のネットワークインタラクションをブロックしません。これらの呼び出しは、コンテキストのイニシエーターまたはコンテキストのターゲットによって呼び出される場合があります。このグループの4人のメンバーは、2つのペアと見なされるべきです。gss_getmic（）からの出力はgss_verifymic（）に適切に入力され、gss_wrap（）からの出力はgss_unwrap（）に適切に入力されます。
GSS_GetMIC() and GSS_VerifyMIC() support data origin authentication and data integrity services. When GSS_GetMIC() is invoked on an input message, it yields a per-message token containing data items which allow underlying mechanisms to provide the specified security services. The original message, along with the generated per-message token, is passed to the remote peer; these two data elements are processed by GSS_VerifyMIC(), which validates the message in conjunction with the separate token.
gss_getmic（）およびgss_verifymic（）サポートデータの起源認証とデータ整合性サービス。GSS_GETMIC（）が入力メッセージに呼び出されると、基礎となるメカニズムが指定されたセキュリティサービスを提供できるようにするデータ項目を含むテークスごとのトークンが生成されます。元のメッセージは、生成されたメッセージごとのトークンとともに、リモートピアに渡されます。これらの2つのデータ要素は、gss_verifymic（）によって処理され、個別のトークンと併せてメッセージを検証します。
GSS_Wrap() and GSS_Unwrap() support caller-requested confidentiality in addition to the data origin authentication and data integrity services offered by GSS_GetMIC() and GSS_VerifyMIC(). GSS_Wrap() outputs a single data element, encapsulating optionally enciphered user data as well as associated token data items. The data element output from GSS_Wrap() is passed to the remote peer and processed by GSS_Unwrap() at that system. GSS_Unwrap() combines decipherment (as required) with validation of data items related to authentication and integrity.
GSS_WRAP（）およびGSS_UNWRAP（）は、GSS_GETMIC（）およびGSS_VERIFYMIC（）によって提供されるデータオリジン認証とデータ整合性サービスに加えて、発信者が要求した機密性をサポートしています。gss_wrap（）は、単一のデータ要素を出力し、オプションでエンコースされたユーザーデータと関連するトークンデータ項目をカプセル化します。gss_wrap（）からのデータ要素出力は、リモートピアに渡され、そのシステムでgss_unwrap（）によって処理されます。gss_unwrap（）は、解読（必要に応じて）と認証と整合性に関連するデータ項目の検証を組み合わせます。
Although zero-length tokens are never returned by GSS calls for transfer to a context's peer, a zero-length object may be passed by a caller into GSS_Wrap(), in which case the corresponding peer calling GSS_Unwrap() on the transferred token will receive a zero-length object as output from GSS_Unwrap(). Similarly, GSS_GetMIC() can be called on an empty object, yielding a MIC which GSS_VerifyMIC() will successfully verify against the active security context in conjunction with a zero-length object.
ゼロ長さのトークンは、コンテキストのピアへの転送のGSSコールによって返されることはありませんが、ゼロ長さのオブジェクトを発信者からgss_wrap（）に渡すことができます。gss_unwrap（）からの出力としてのゼロ長オブジェクト。同様に、GSS_GETMIC（）は空のオブジェクトで呼び出すことができ、GSS_VerifyMic（）がゼロ長さのオブジェクトと組み合わせてアクティブセキュリティコンテキストに対して正常に検証するマイクを生成します。
2.3.1: GSS_GetMIC call
2.3.1：GSS_GETMICコール
Note: This call is functionally equivalent to the GSS_Sign call as defined in previous versions of this specification. In the interests of backward compatibility, it is recommended that implementations support this function under both names for the present; future references to this function as GSS_Sign are deprecated.
注：この呼び出しは、この仕様の以前のバージョンで定義されているGSS_SIGNコールと機能的に同等です。後方互換性のために、実装は現在の両方の名前でこの機能をサポートすることをお勧めします。GSS_SIGNとしてのこの機能への将来の参照は非推奨です。
Inputs:
入力：
o context_handle CONTEXT HANDLE,
o Context_handleコンテキストハンドル、
o qop_req INTEGER, -- 0 specifies default QOP
o QOP_REQ Integer、-0はデフォルトQOPを指定します
o message OCTET STRING
o メッセージオクテット文字列
Outputs:
出力：
o major_status INTEGER,
o Major_status整数、
o minor_status INTEGER,
o minor_status整数、
o per_msg_token OCTET STRING -- caller must release -- with GSS_Release_buffer()
o per_msg_token octet string-発信者はリリースする必要があります - gss_release_buffer（）
Return major_status codes:
Major_statusコードを返す：
o GSS_S_COMPLETE indicates that an integrity check, suitable for an established security context, was successfully applied and that the message and corresponding per_msg_token are ready for transmission.
o GSS_S_Completeは、確立されたセキュリティコンテキストに適した整合性チェックが正常に適用され、メッセージと対応するPER_MSG_TOKENが送信の準備ができていることを示しています。
o GSS_S_CONTEXT_EXPIRED indicates that context-related data items have expired, so that the requested operation cannot be performed.
o gss_s_context_expiredは、コンテキスト関連のデータ項目が有効期限が切れているため、要求された操作を実行できないことを示します。
o GSS_S_NO_CONTEXT indicates that no context was recognized for the input context_handle provided.
o GSS_S_NO_CONTEXTは、提供されている入力コンテキスト_Handleに対してコンテキストが認識されなかったことを示します。
o GSS_S_BAD_QOP indicates that the provided QOP value is not recognized or supported for the context.
o GSS_S_BAD_QOPは、提供されたQOP値がコンテキストに対して認識またはサポートされていないことを示します。
o GSS_S_FAILURE indicates that the context is recognized, but that the requested operation could not be performed for reasons unspecified at the GSS-API level.
o GSS_S_FAILUREは、コンテキストが認識されていることを示していますが、GSS-APIレベルで不特定の理由で要求された操作を実行できなかったことを示します。
Using the security context referenced by context_handle, apply an integrity check to the input message (along with timestamps and/or other data included in support of mech_type-specific mechanisms) and (if GSS_S_COMPLETE status is indicated) return the result in per_msg_token. The qop_req parameter, interpretation of which is discussed in Section 1.2.4, allows quality-of-protection control. The caller passes the message and the per_msg_token to the target.
Context_Handleで参照されるセキュリティコンテキストを使用して、整合性チェックを入力メッセージに適用します（Mech_Type固有のメカニズムをサポートするためにタイムスタンプおよび/またはその他のデータとともに）、および（GSS_S_Completeステータスが示されている場合）PER_MSG_TOKENで結果を返します。セクション1.2.4で説明されているQOP_REQパラメーターについては、保護品質の制御が可能になります。発信者はメッセージを渡し、per_msg_tokenはターゲットに渡されます。
The GSS_GetMIC() function completes before the message and per_msg_token is sent to the peer; successful application of GSS_GetMIC() does not guarantee that a corresponding GSS_VerifyMIC() has been (or can necessarily be) performed successfully when the message arrives at the destination.
gss_getmic（）関数はメッセージが完了し、per_msg_tokenがピアに送信されます。GSS_GETMIC（）の適用の成功は、メッセージが宛先に到着したときに対応するgss_verifymic（）が正常に実行された（または必然的に実行できる）ことを保証するものではありません。
Mechanisms which do not support per-message protection services should return GSS_S_FAILURE if this routine is called.
このルーチンが呼び出された場合、メッセージごとの保護サービスをサポートしないメカニズムはGSS_S_FAILUREを返す必要があります。
2.3.2: GSS_VerifyMIC call
2.3.2：GSS_VERIFYMIC CALL
Note: This call is functionally equivalent to the GSS_Verify call as defined in previous versions of this specification. In the interests of backward compatibility, it is recommended that implementations support this function under both names for the present; future references to this function as GSS_Verify are deprecated.
注：この呼び出しは、この仕様の以前のバージョンで定義されているGSS_Verifyコールと機能的に同等です。後方互換性のために、実装は現在の両方の名前でこの機能をサポートすることをお勧めします。gss_verifyとしてのこの機能への将来の参照は非推奨です。
Inputs:
入力：
o context_handle CONTEXT HANDLE,
o Context_handleコンテキストハンドル、
o message OCTET STRING,
o メッセージオクテット文字列、
o per_msg_token OCTET STRING
o per_msg_tokenオクテット文字列
Outputs:
出力：
o qop_state INTEGER,
o qop_state integer、
o major_status INTEGER,
o Major_status整数、
o minor_status INTEGER,
o minor_status整数、
Return major_status codes:
Major_statusコードを返す：
o GSS_S_COMPLETE indicates that the message was successfully verified.
o gss_s_completeは、メッセージが正常に検証されたことを示します。
o GSS_S_DEFECTIVE_TOKEN indicates that consistency checks performed on the received per_msg_token failed, preventing further processing from being performed with that token.
o gss_s_defective_tokenは、受信したper_msg_tokenで実行された一貫性チェックが失敗し、そのトークンでさらに処理が実行されないことを示します。
o GSS_S_BAD_SIG (GSS_S_BAD_MIC) indicates that the received per_msg_token contains an incorrect integrity check for the message.
o GSS_S_BAD_SIG（GSS_S_BAD_MIC）は、受信したPER_MSG_TOKENにメッセージの誤った整合性チェックが含まれていることを示します。
o GSS_S_DUPLICATE_TOKEN, GSS_S_OLD_TOKEN, GSS_S_UNSEQ_TOKEN, and GSS_S_GAP_TOKEN values appear in conjunction with the optional per-message replay detection features described in Section 1.2.3; their semantics are described in that section.
o GSS_S_DUPLICATION_TOKEN、GSS_S_OLD_TOKEN、GSS_S_UNSEQ_TOKEN、およびGSS_S_GAP_TOKEN値は、セクション1.2.3で説明されているオプションごとのリプレイ検出機能と組み合わせて表示されます。それらのセマンティクスについては、そのセクションで説明します。
o GSS_S_CONTEXT_EXPIRED indicates that context-related data items have expired, so that the requested operation cannot be performed.
o gss_s_context_expiredは、コンテキスト関連のデータ項目が有効期限が切れているため、要求された操作を実行できないことを示します。
o GSS_S_NO_CONTEXT indicates that no context was recognized for the input context_handle provided.
o GSS_S_NO_CONTEXTは、提供されている入力コンテキスト_Handleに対してコンテキストが認識されなかったことを示します。
o GSS_S_FAILURE indicates that the context is recognized, but that the GSS_VerifyMIC() operation could not be performed for reasons unspecified at the GSS-API level.
o GSS_S_FAILUREは、コンテキストが認識されていることを示していますが、GSS-APIレベルでは不特定の理由でGSS_VERIFYMIC（）操作を実行できなかったことを示しています。
Using the security context referenced by context_handle, verify that the input per_msg_token contains an appropriate integrity check for the input message, and apply any active replay detection or sequencing features. Returns an indication of the quality-of-protection applied to the processed message in the qop_state result.
Context_Handleで参照されるセキュリティコンテキストを使用して、入力PER_MSG_TOKENに入力メッセージの適切な整合性チェックが含まれていることを確認し、アクティブなリプレイ検出またはシーケンス機能を適用します。QOP_STATE結果の処理されたメッセージに適用された保護の質の兆候を返します。
Mechanisms which do not support per-message protection services should return GSS_S_FAILURE if this routine is called.
このルーチンが呼び出された場合、メッセージごとの保護サービスをサポートしないメカニズムはGSS_S_FAILUREを返す必要があります。
2.3.3: GSS_Wrap call
2.3.3：GSS_WRAPコール
Note: This call is functionally equivalent to the GSS_Seal call as defined in previous versions of this specification. In the interests of backward compatibility, it is recommended that implementations support this function under both names for the present; future references to this function as GSS_Seal are deprecated.
注：この呼び出しは、この仕様の以前のバージョンで定義されているGSS_SEALコールと機能的に同等です。後方互換性のために、実装は現在の両方の名前でこの機能をサポートすることをお勧めします。GSS_SEALとしてのこの機能への将来の言及は非推奨です。
Inputs:
入力：
o context_handle CONTEXT HANDLE,
o Context_handleコンテキストハンドル、
o conf_req_flag BOOLEAN,
o conf_req_flag boolean、
o qop_req INTEGER, -- 0 specifies default QOP
o QOP_REQ Integer、-0はデフォルトQOPを指定します
o input_message OCTET STRING
o input_messageオクテット文字列
Outputs:
出力：
o major_status INTEGER,
o Major_status整数、
o minor_status INTEGER, o conf_state BOOLEAN,
o minor_status integer、o conf_state boolean、
o output_message OCTET STRING -- caller must release with -- GSS_Release_buffer()
o output_messageオクテット文字列 - 発信者はwith -gss_release_buffer（）でリリースする必要があります
Return major_status codes:
Major_statusコードを返す：
o GSS_S_COMPLETE indicates that the input_message was successfully processed and that the output_message is ready for transmission.
o gss_s_completeは、input_messageが正常に処理され、output_messageが送信の準備ができていることを示します。
o GSS_S_CONTEXT_EXPIRED indicates that context-related data items have expired, so that the requested operation cannot be performed.
o gss_s_context_expiredは、コンテキスト関連のデータ項目が有効期限が切れているため、要求された操作を実行できないことを示します。
o GSS_S_NO_CONTEXT indicates that no context was recognized for the input context_handle provided.
o GSS_S_NO_CONTEXTは、提供されている入力コンテキスト_Handleに対してコンテキストが認識されなかったことを示します。
o GSS_S_BAD_QOP indicates that the provided QOP value is not recognized or supported for the context.
o GSS_S_BAD_QOPは、提供されたQOP値がコンテキストに対して認識またはサポートされていないことを示します。
o GSS_S_FAILURE indicates that the context is recognized, but that the GSS_Wrap() operation could not be performed for reasons unspecified at the GSS-API level.
o GSS_S_FAILUREは、コンテキストが認識されているが、GSS-APIレベルでは不特定の理由でGSS_WRAP（）操作を実行できなかったことを示しています。
Performs the data origin authentication and data integrity functions of GSS_GetMIC(). If the input conf_req_flag is TRUE, requests that confidentiality be applied to the input_message. Confidentiality may not be supported in all mech_types or by all implementations; the returned conf_state flag indicates whether confidentiality was provided for the input_message. The qop_req parameter, interpretation of which is discussed in Section 1.2.4, allows quality-of-protection control.
GSS_GETMIC（）のデータオリジン認証とデータの整合性関数を実行します。入力conf_req_flagがtrueの場合、confidentionlageはinput_messageに適用されることを要求します。機密性は、すべてのmech_typesまたはすべての実装でサポートされていない場合があります。返されたconf_stateフラグは、input_messageに対して機密性が提供されたかどうかを示します。セクション1.2.4で説明されているQOP_REQパラメーターについては、保護品質の制御が可能になります。
When GSS_S_COMPLETE status is returned, the GSS_Wrap() call yields a single output_message data element containing (optionally enciphered) user data as well as control information.
gss_s_completeステータスが返されると、gss_wrap（）callは、（オプションでエンシパー付き）ユーザーデータと制御情報を含む単一のoutput_messageデータ要素を生成します。
Mechanisms which do not support per-message protection services should return GSS_S_FAILURE if this routine is called.
このルーチンが呼び出された場合、メッセージごとの保護サービスをサポートしないメカニズムはGSS_S_FAILUREを返す必要があります。
2.3.4: GSS_Unwrap call
2.3.4：gss_unwrapコール
Note: This call is functionally equivalent to the GSS_Unseal call as defined in previous versions of this specification. In the interests of backward compatibility, it is recommended that implementations support this function under both names for the present; future references to this function as GSS_Unseal are deprecated.
注：この呼び出しは、この仕様の以前のバージョンで定義されているGSS_UNSEALコールと機能的に同等です。後方互換性のために、実装は現在の両方の名前でこの機能をサポートすることをお勧めします。GSS_UNSEALとしてのこの機能への将来の言及は非推奨です。
Inputs:
入力：
o context_handle CONTEXT HANDLE,
o Context_handleコンテキストハンドル、
o input_message OCTET STRING
o input_messageオクテット文字列
Outputs:
出力：
o conf_state BOOLEAN,
o conf_state boolean、
o qop_state INTEGER,
o qop_state integer、
o major_status INTEGER,
o Major_status整数、
o minor_status INTEGER,
o minor_status整数、
o output_message OCTET STRING -- caller must release with -- GSS_Release_buffer()
o output_messageオクテット文字列 - 発信者はwith -gss_release_buffer（）でリリースする必要があります
Return major_status codes:
Major_statusコードを返す：
o GSS_S_COMPLETE indicates that the input_message was successfully processed and that the resulting output_message is available.
o gss_s_completeは、input_messageが正常に処理され、結果のoutput_messageが利用可能であることを示します。
o GSS_S_DEFECTIVE_TOKEN indicates that consistency checks performed on the per_msg_token extracted from the input_message failed, preventing further processing from being performed.
o gss_s_defective_tokenは、input_messageから抽出されたper_msg_tokenで実行された一貫性チェックが失敗し、さらに処理が実行されないことを示します。
o GSS_S_BAD_SIG (GSS_S_BAD_MIC) indicates that an incorrect integrity check was detected for the message.
o GSS_S_BAD_SIG（GSS_S_BAD_MIC）は、メッセージに対して誤った整合性チェックが検出されたことを示します。
o GSS_S_DUPLICATE_TOKEN, GSS_S_OLD_TOKEN, GSS_S_UNSEQ_TOKEN, and GSS_S_GAP_TOKEN values appear in conjunction with the optional per-message replay detection features described in Section 1.2.3; their semantics are described in that section.
o GSS_S_DUPLICATION_TOKEN、GSS_S_OLD_TOKEN、GSS_S_UNSEQ_TOKEN、およびGSS_S_GAP_TOKEN値は、セクション1.2.3で説明されているオプションごとのリプレイ検出機能と組み合わせて表示されます。それらのセマンティクスについては、そのセクションで説明します。
o GSS_S_CONTEXT_EXPIRED indicates that context-related data items have expired, so that the requested operation cannot be performed.
o gss_s_context_expiredは、コンテキスト関連のデータ項目が有効期限が切れているため、要求された操作を実行できないことを示します。
o GSS_S_NO_CONTEXT indicates that no context was recognized for the input context_handle provided.
o GSS_S_NO_CONTEXTは、提供されている入力コンテキスト_Handleに対してコンテキストが認識されなかったことを示します。
o GSS_S_FAILURE indicates that the context is recognized, but that the GSS_Unwrap() operation could not be performed for reasons unspecified at the GSS-API level.
o GSS_S_FAILUREは、コンテキストが認識されているが、GSS-APIレベルでは不特定の理由でGSS_UNWRAP（）操作を実行できなかったことを示しています。
Processes a data element generated (and optionally enciphered) by GSS_Wrap(), provided as input_message. The returned conf_state value indicates whether confidentiality was applied to the input_message. If conf_state is TRUE, GSS_Unwrap() has deciphered the input_message. Returns an indication of the quality-of-protection applied to the processed message in the qop_state result. GSS_Unwrap() performs the data integrity and data origin authentication checking functions of GSS_VerifyMIC() on the plaintext data. Plaintext data is returned in output_message.
input_messageとして提供されるgss_wrap（）によって生成された（およびオプションでエンコールされた）データ要素を処理します。返されたconf_state値は、機密性がinput_messageに適用されたかどうかを示します。conf_stateがtrueの場合、gss_unwrap（）がinput_messageを解読しました。QOP_STATE結果の処理されたメッセージに適用された保護の質の兆候を返します。gss_unwrap（）は、プレーンテキストデータ上のgss_verifymic（）のデータの整合性とデータの起源認証チェック関数を実行します。プレーンテキストデータはoutput_messageで返されます。
Mechanisms which do not support per-message protection services should return GSS_S_FAILURE if this routine is called.
このルーチンが呼び出された場合、メッセージごとの保護サービスをサポートしないメカニズムはGSS_S_FAILUREを返す必要があります。
2.4: Support calls
2.4：サポートコール
This group of calls provides support functions useful to GSS-API callers, independent of the state of established contexts. Their characterization with regard to blocking or non-blocking status in terms of network interactions is unspecified.
このコールグループは、確立されたコンテキストの状態とは無関係に、GSS-API発信者に役立つサポート機能を提供します。ネットワークインタラクションの観点からのブロッキングまたは非ブロッキングステータスに関するそれらの特性評価は、不特定です。
2.4.1: GSS_Display_status call
2.4.1：GSS_DISPLAY_STATUSコール
Inputs:
入力：
o status_value INTEGER, -- GSS-API major_status or minor_status -- return value
o status_value integer、-GSS-API Major_statusまたはminor_status-戻り値
o status_type INTEGER, -- 1 if major_status, 2 if minor_status
o status_type integer、-1 major_statusの場合、2 minor_status if if if_status
o mech_type OBJECT IDENTIFIER -- mech_type to be used for -- minor_status translation
o mech_typeオブジェクト識別子 - 使用するmech_type -minor_status翻訳
Outputs:
出力：
o major_status INTEGER,
o Major_status整数、
o minor_status INTEGER,
o minor_status整数、
o status_string_set SET OF OCTET STRING -- required calls for -- release by caller are specific to language bindings
o status_string_set octet文字列のセット - 必要な呼び出し - 発信者によるリリースは言語のバインディングに固有です
Return major_status codes:
Major_statusコードを返す：
o GSS_S_COMPLETE indicates that a valid printable status representation (possibly representing more than one status event encoded within the status_value) is available in the returned status_string_set.
o GSS_S_COMPLETEは、returned Status_String_setで有効な印刷可能なステータス表現（Status_Value内でエンコードされた複数のステータスイベントを表す）が利用可能であることを示します。
o GSS_S_BAD_MECH indicates that translation in accordance with an unsupported mech_type was requested, so translation could not be performed.
o GSS_S_BAD_MECHは、サポートされていないmech_typeに従って翻訳が要求されたことを示しているため、翻訳は実行できませんでした。
o GSS_S_BAD_STATUS indicates that the input status_value was invalid, or that the input status_type carried a value other than 1 or 2, so translation could not be performed.
o GSS_S_BAD_STATUSは、入力STATUS_VALUEが無効であること、または入力STATUS_TYPEが1または2以外の値を携帯していることを示しているため、翻訳は実行できませんでした。
o GSS_S_FAILURE indicates that the requested operation could not be performed for reasons unspecified at the GSS-API level.
o GSS_S_FAILUREは、GSS-APIレベルで不特定の理由で要求された操作を実行できなかったことを示しています。
Provides a means for callers to translate GSS-API-returned major and minor status codes into printable string representations. Note: some language bindings may employ an iterative approach in order to emit successive status components; this approach is acceptable but not required for conformance with the current specification.
発信者がGSS-API-Returnedの主要なステータスコードを印刷可能な文字列表現に翻訳する手段を提供します。注：一部の言語バインディングは、連続したステータスコンポーネントを放出するために反復的なアプローチを採用する場合があります。このアプローチは受け入れられますが、現在の仕様に準拠するためには必要ありません。
Although not contemplated in [RFC-2078], it has been observed that some existing GSS-API implementations return GSS_S_CONTINUE_NEEDED status when iterating through successive messages returned from GSS_Display_status(). This behavior is deprecated; GSS_S_CONTINUE_NEEDED should be returned only by GSS_Init_sec_context() and GSS_Accept_sec_context(). For maximal portability, however, it is recommended that defensive callers be able to accept and ignore GSS_S_CONTINUE_NEEDED status if indicated by GSS_Display_status() or any other call other than GSS_Init_sec_context() or GSS_Accept_sec_context().
[RFC-2078]では考えられていませんが、既存のGSS-API実装の一部は、GSS_DISPLAY_STATUS（）から返された連続したメッセージを介して繰り返されるときにGSS_S_CONTINUE_NEEDEDステータスを返すことが観察されています。この動作は非推奨です。gss_s_continue_neededは、gss_init_sec_context（）およびgss_accept_sec_context（）によってのみ返される必要があります。ただし、最大の移植性のために、GSS_DISPLAY_STATUS（）またはGSS_INIT_SEC_CONTEXT（）またはGSS_ACCEPT_SEC_CONTEXT（）で示される場合、防御的な発信者はGSS_SS_SS_CONTINUE_NEEDEDステータスを受け入れて無視できるようにすることをお勧めします。
2.4.2: GSS_Indicate_mechs call
2.4.2：gss_indicate_mechs呼び出し
Input:
入力：
o (none)
o （なし）
Outputs:
出力：
o major_status INTEGER,
o Major_status整数、
o minor_status INTEGER,
o minor_status整数、
o mech_set SET OF OBJECT IDENTIFIER -- caller must release -- with GSS_Release_oid_set()
o mech_setオブジェクト識別子のセット - 発信者はリリースする必要があります - gss_release_oid_set（）
Return major_status codes:
Major_statusコードを返す：
o GSS_S_COMPLETE indicates that a set of available mechanisms has been returned in mech_set.
o GSS_S_COMPLETEは、利用可能なメカニズムのセットがmech_setで返されたことを示します。
o GSS_S_FAILURE indicates that the requested operation could not be performed for reasons unspecified at the GSS-API level.
o GSS_S_FAILUREは、GSS-APIレベルで不特定の理由で要求された操作を実行できなかったことを示しています。
Allows callers to determine the set of mechanism types available on the local system. This call is intended for support of specialized callers who need to request non-default mech_type sets from GSS-API calls which accept input mechanism type specifiers.
発信者は、ローカルシステムで利用可能なメカニズムタイプのセットを決定できます。この呼び出しは、入力メカニズムタイプの仕様を受け入れるGSS-APIコールから非デフォルトMech_Typeセットを要求する必要がある専門の発信者のサポートを目的としています。
2.4.3: GSS_Compare_name call
2.4.3：gss_compare_nameコール
Inputs:
入力：
o name1 INTERNAL NAME,
o name1内部名、
o name2 INTERNAL NAME
o name2内部名
Outputs:
出力：
o major_status INTEGER,
o Major_status整数、
o minor_status INTEGER,
o minor_status整数、
o name_equal BOOLEAN
o name_equal boolean
Return major_status codes:
Major_statusコードを返す：
o GSS_S_COMPLETE indicates that name1 and name2 were comparable, and that the name_equal result indicates whether name1 and name2 represent the same entity.
o gss_s_completeは、name1とname2が同等であり、name_equal resultがname1とname2が同じエンティティを表すかどうかを示していることを示します。
o GSS_S_BAD_NAMETYPE indicates that the two input names' types are different and incomparable, so that the comparison operation could not be completed.
o GSS_S_BAD_NAMETYPEは、2つの入力名のタイプが異なり、比類のないものであるため、比較操作を完了できないことを示しています。
o GSS_S_BAD_NAME indicates that one or both of the input names was ill-formed in terms of its internal type specifier, so the comparison operation could not be completed.
o GSS_S_BAD_NAMEは、入力名の1つまたは両方が内部型仕様の観点から不調であるため、比較操作を完了できなかったことを示しています。
o GSS_S_FAILURE indicates that the call's operation could not be performed for reasons unspecified at the GSS-API level.
o GSS_S_FAILUREは、GSS-APIレベルで不特定の理由でコールの操作を実行できなかったことを示しています。
Allows callers to compare two internal name representations to determine whether they refer to the same entity. If either name presented to GSS_Compare_name() denotes an anonymous principal, GSS_Compare_name() shall indicate FALSE. It is not required that either or both inputs name1 and name2 be MNs; for some implementations and cases, GSS_S_BAD_NAMETYPE may be returned, indicating name incomparability, for the case where neither input name is an MN.
発信者は、2つの内部名表現を比較して、同じエンティティを参照するかどうかを判断できます。gss_compare_name（）に提示されたいずれかの名前が匿名のプリンシパルを示す場合、gss_compare_name（）はfalseを示します。name1とname2がmnsであるか、両方の入力または両方の入力が必要ではありません。いくつかの実装およびケースでは、GSS_S_BAD_NAMETYPEが返される場合があり、どちらの入力名がMNではない場合には、名前の比例性を示します。
2.4.4: GSS_Display_name call
2.4.4：GSS_DISPLAY_NAME CALL
Inputs:
入力：
o name INTERNAL NAME
o 名前の内部名
Outputs:
出力：
o major_status INTEGER,
o Major_status整数、
o minor_status INTEGER,
o minor_status整数、
o name_string OCTET STRING, -- caller must release -- with GSS_Release_buffer()
o name_string occet string、 - 発信者はリリースする必要があります - gss_release_buffer（）
o name_type OBJECT IDENTIFIER -- caller should treat -- as read-only; does not need to be released
o name_typeオブジェクト識別子 - 発信者は扱う必要があります - 読み取り専用として。リリースする必要はありません
Return major_status codes:
Major_statusコードを返す：
o GSS_S_COMPLETE indicates that a valid printable name representation is available in the returned name_string.
o GSS_S_COMPLETEは、返されたname_stringで有効な印刷可能な名前の表現が利用可能であることを示します。
o GSS_S_BAD_NAME indicates that the contents of the provided name were inconsistent with the internally-indicated name type, so no printable representation could be generated.
o GSS_S_BAD_NAMEは、提供された名前の内容が内部指定の名前タイプと矛盾していることを示しているため、印刷可能な表現を生成できません。
o GSS_S_FAILURE indicates that the requested operation could not be performed for reasons unspecified at the GSS-API level.
o GSS_S_FAILUREは、GSS-APIレベルで不特定の理由で要求された操作を実行できなかったことを示しています。
Allows callers to translate an internal name representation into a printable form with associated namespace type descriptor. The syntax of the printable form is a local matter.
発信者は、内部名表現を関連付けられた名前空間型記述子を持つ印刷可能なフォームに変換できます。印刷可能なフォームの構文はローカルな問題です。
If the input name represents an anonymous identity, a reserved value (GSS_C_NT_ANONYMOUS) shall be returned for name_type.
入力名が匿名のIDを表す場合、name_typeの場合、予約値（gss_c_nt_anonymous）を返品するものとします。
The GSS_C_NO_OID name type is to be returned only when the corresponding internal name was created through import with GSS_C_NO_OID. It is acceptable for mechanisms to normalize names imported with GSS_C_NO_OID into other supported types and, therefore, to display them with types other than GSS_C_NO_OID.
GSS_C_NO_OID名タイプは、対応する内部名がGSS_C_NO_OIDを使用してインポートを通じて作成された場合にのみ返されます。メカニズムは、GSS_C_NO_OIDでインポートされた名前を他のサポートされているタイプに正規化するため、GSS_C_NO_OID以外のタイプでそれらを表示することは許容されます。
2.4.5: GSS_Import_name call
2.4.5：GSS_IMPORT_NAME CALL
Inputs:
入力：
o input_name_string OCTET STRING,
o input_name_stringオクテット文字列、
o input_name_type OBJECT IDENTIFIER
o input_name_typeオブジェクト識別子
Outputs:
出力：
o major_status INTEGER,
o Major_status整数、
o minor_status INTEGER,
o minor_status整数、
o output_name INTERNAL NAME -- caller must release with -- GSS_Release_name()
o output_name内部名 - 発信者は-gss_release_name（）でリリースする必要があります
Return major_status codes:
Major_statusコードを返す：
o GSS_S_COMPLETE indicates that a valid name representation is output in output_name and described by the type value in output_name_type.
o gss_s_completeは、有効な名前表現がoutput_nameで出力され、output_name_typeの型値で記述されていることを示します。
o GSS_S_BAD_NAMETYPE indicates that the input_name_type is unsupported by the applicable underlying GSS-API mechanism(s), so the import operation could not be completed.
o gss_s_bad_nameTypeは、input_name_typeが該当する基礎となるGSS-APIメカニズムによってサポートされていないことを示しているため、インポート操作を完了できませんでした。
o GSS_S_BAD_NAME indicates that the provided input_name_string is ill-formed in terms of the input_name_type, so the import operation could not be completed.
o GSS_S_BAD_NAMEは、提供されたinput_name_stringがinput_name_typeの観点から不適切であることを示しているため、インポート操作を完了できませんでした。
o GSS_S_BAD_MECH indicates that the input presented for import was an exported name object and that its enclosed mechanism type was not recognized or was unsupported by the GSS-API implementation.
o GSS_S_BAD_MECHは、インポート用に提示された入力がエクスポートされた名前オブジェクトであり、その囲まれたメカニズムタイプがGSS-API実装によって認識されないか、サポートされていないことを示しています。
o GSS_S_FAILURE indicates that the requested operation could not be performed for reasons unspecified at the GSS-API level.
o GSS_S_FAILUREは、GSS-APIレベルで不特定の理由で要求された操作を実行できなかったことを示しています。
Allows callers to provide a name representation as a contiguous octet string, designate the type of namespace in conjunction with which it should be parsed, and convert that representation to an internal form suitable for input to other GSS-API routines. The syntax of the input_name_string is defined in conjunction with its associated name type; depending on the input_name_type, the associated input_name_string may or may not be a printable string. If the input_name_type's value is GSS_C_NO_OID, a mechanism-specific default printable syntax (which shall be specified in the corresponding GSS-V2 mechanism specification) is assumed for the input_name_string;
発信者は、隣接するオクテット文字列として名前表現を提供し、それを解析する必要がある名前空間のタイプを指定し、その表現を他のGSS-APIルーチンへの入力に適した内部形式に変換できます。input_name_stringの構文は、関連する名前タイプと組み合わせて定義されます。input_name_typeに応じて、関連するinput_name_stringは印刷可能な文字列である場合とそうでない場合があります。input_name_typeの値がGSS_C_NO_OIDの場合、MECHANISM固有のデフォルトの印刷可能な構文（対応するGSS-V2メカニズム仕様で指定される）がinput_name_stringに対して想定されます。
other input_name_type values as registered by GSS-API implementations can be used to indicate specific non-default name syntaxes. Note: The input_name_type argument serves to describe and qualify the interpretation of the associated input_name_string; it does not specify the data type of the returned output_name.
GSS-API実装によって登録されているその他のinput_name_type値を使用して、特定の非デフォルト名構文を示すことができます。注：input_name_type引数は、関連するinput_name_stringの解釈を記述し、修飾するのに役立ちます。返されたoutput_nameのデータ型を指定しません。
If a mechanism claims support for a particular name type, its GSS_Import_name() operation shall be able to accept all possible values conformant to the external name syntax as defined for that name type. These imported values may correspond to:
メカニズムが特定の名前タイプのサポートを主張する場合、そのgss_import_name（）操作は、その名前タイプに定義されているように、外部名構文に適合したすべての可能な値を受け入れることができます。これらのインポートされた値は、次のように対応できます。
(1) locally registered entities (for which credentials may be acquired),
(1) 地元の登録エンティティ（資格情報が取得される可能性がある）、
(2) non-local entities (for which local credentials cannot be acquired, but which may be referenced as targets of initiated security contexts or initiators of accepted security contexts), or to
(2) 非ローカルエンティティ（ローカル資格情報を取得できませんが、開始されたセキュリティコンテキストのターゲットまたは受け入れられたセキュリティコンテキストの開始者として参照される場合があります）、または
(3) neither of the above.
(3) どちらも上記ではありません。
Determination of whether a particular name belongs to class (1), (2), or (3) as described above is not guaranteed to be performed by the GSS_Import_name() function.
特定の名前がクラス（1）、（2）、または（3）に属するかどうかの決定は、GSS_IMPORT_NAME（）関数によって実行されることは保証されていません。
The internal name generated by a GSS_Import_name() operation may be a single-mechanism MN, and is likely to be an MN within a single-mechanism implementation, but portable callers must not depend on this property (and must not, therefore, assume that the output from GSS_Import_name() can be passed directly to GSS_Export_name() without first being processed through GSS_Canonicalize_name()).
GSS_IMPORT_NAME（）操作によって生成される内部名は単一メカニズムMNである可能性があり、単一メカニズムの実装内でMNになる可能性がありますが、ポータブル発信者はこのプロパティに依存してはなりません（したがって、したがって、したがって、そうでないでください。GSS_IMPORT_NAME（）からの出力は、GSS_CANONICALIZE_NAME（））を介して最初に処理されることなく、GSS_EXPORT_NAME（）に直接渡すことができます。
2.4.6: GSS_Release_name call
2.4.6：GSS_RELEASE_NAME CALL
Inputs:
入力：
o name INTERNAL NAME
o 名前の内部名
Outputs:
出力：
o major_status INTEGER,
o Major_status整数、
o minor_status INTEGER
o minor_status整数
Return major_status codes:
Major_statusコードを返す：
o GSS_S_COMPLETE indicates that the storage associated with the input name was successfully released.
o GSS_S_COMPLETEは、入力名に関連付けられたストレージが正常にリリースされたことを示します。
o GSS_S_BAD_NAME indicates that the input name argument did not contain a valid name.
o GSS_S_BAD_NAMEは、入力名引数に有効な名前が含まれていないことを示します。
o GSS_S_FAILURE indicates that the requested operation could not be performed for reasons unspecified at the GSS-API level.
o GSS_S_FAILUREは、GSS-APIレベルで不特定の理由で要求された操作を実行できなかったことを示しています。
Allows callers to release the storage associated with an internal name representation. This call's specific behavior depends on the language and programming environment within which a GSS-API implementation operates, and is therefore detailed within applicable bindings specifications; in particular, implementation and invocation of this call may be superfluous (and may be omitted) within bindings where memory management is automatic.
発信者は、内部名表現に関連付けられたストレージをリリースできます。この呼び出しの特定の動作は、GSS-APIの実装が動作する言語とプログラミング環境に依存しているため、適用可能なバインディング仕様内で詳しく説明されています。特に、この呼び出しの実装と呼び出しは、メモリ管理が自動的であるバインディング内では不要（および省略される場合があります）です。
2.4.7: GSS_Release_buffer call
2.4.7：gss_release_bufferコール
Inputs:
入力：
o buffer OCTET STRING
o バッファオクテット文字列
Outputs:
出力：
o major_status INTEGER,
o Major_status整数、
o minor_status INTEGER
o minor_status整数
Return major_status codes:
Major_statusコードを返す：
o GSS_S_COMPLETE indicates that the storage associated with the input buffer was successfully released.
o GSS_S_COMPLETEは、入力バッファーに関連付けられたストレージが正常に放出されたことを示します。
o GSS_S_FAILURE indicates that the requested operation could not be performed for reasons unspecified at the GSS-API level.
o GSS_S_FAILUREは、GSS-APIレベルで不特定の理由で要求された操作を実行できなかったことを示しています。
Allows callers to release the storage associated with an OCTET STRING buffer allocated by another GSS-API call. This call's specific behavior depends on the language and programming environment within which a GSS-API implementation operates, and is therefore detailed within applicable bindings specifications; in particular, implementation and invocation of this call may be superfluous (and may be omitted) within bindings where memory management is automatic.
発信者は、別のGSS-APIコールによって割り当てられたOctet Stringバッファに関連付けられたストレージをリリースできます。この呼び出しの特定の動作は、GSS-APIの実装が動作する言語とプログラミング環境に依存しているため、適用可能なバインディング仕様内で詳しく説明されています。特に、この呼び出しの実装と呼び出しは、メモリ管理が自動的であるバインディング内では不要（および省略される場合があります）です。
2.4.8: GSS_Release_OID_set call
2.4.8：gss_release_oid_set call
Inputs:
入力：
o buffer SET OF OBJECT IDENTIFIER Outputs:
o オブジェクト識別子出力のバッファセット：
o major_status INTEGER,
o Major_status整数、
o minor_status INTEGER
o minor_status整数
Return major_status codes:
Major_statusコードを返す：
o GSS_S_COMPLETE indicates that the storage associated with the input object identifier set was successfully released.
o GSS_S_COMPLETEは、入力オブジェクト識別子セットに関連付けられたストレージが正常にリリースされたことを示します。
o GSS_S_FAILURE indicates that the requested operation could not be performed for reasons unspecified at the GSS-API level.
o GSS_S_FAILUREは、GSS-APIレベルで不特定の理由で要求された操作を実行できなかったことを示しています。
Allows callers to release the storage associated with an object identifier set object allocated by another GSS-API call. This call's specific behavior depends on the language and programming environment within which a GSS-API implementation operates, and is therefore detailed within applicable bindings specifications; in particular, implementation and invocation of this call may be superfluous (and may be omitted) within bindings where memory management is automatic.
発信者は、別のGSS-APIコールによって割り当てられたオブジェクト識別子セットオブジェクトに関連付けられたストレージをリリースできます。この呼び出しの特定の動作は、GSS-APIの実装が動作する言語とプログラミング環境に依存しているため、適用可能なバインディング仕様内で詳しく説明されています。特に、この呼び出しの実装と呼び出しは、メモリ管理が自動的であるバインディング内では不要（および省略される場合があります）です。
2.4.9: GSS_Create_empty_OID_set call
2.4.9：gss_create_empty_oid_setコール
Inputs:
入力：
o (none)
o （なし）
Outputs:
出力：
o major_status INTEGER,
o Major_status整数、
o minor_status INTEGER,
o minor_status整数、
o oid_set SET OF OBJECT IDENTIFIER -- caller must release -- with GSS_Release_oid_set()
o oid_setオブジェクト識別子のセット - 発信者はリリースする必要があります-GSS_RELEASE_OID_SET（）
Return major_status codes:
Major_statusコードを返す：
o GSS_S_COMPLETE indicates successful completion
o GSS_S_COMPLETEは、正常に完了したことを示します
o GSS_S_FAILURE indicates that the operation failed
o GSS_S_FAILUREは、操作が失敗したことを示します
Creates an object identifier set containing no object identifiers, to which members may be subsequently added using the GSS_Add_OID_set_member() routine. These routines are intended to be used to construct sets of mechanism object identifiers, for input to GSS_Acquire_cred().
オブジェクト識別子を含むオブジェクト識別子セットを作成します。この識別子は、その後、メンバーをGSS_ADD_OID_SET_MEMBER（）ルーチンを使用して追加できます。これらのルーチンは、GSS_ACQUIRE_CRED（）に入力するために、メカニズムオブジェクト識別子のセットを構築するために使用されることを目的としています。
2.4.10: GSS_Add_OID_set_member call
2.4.10：gss_add_oid_set_memberコール
Inputs:
入力：
o member_oid OBJECT IDENTIFIER,
o member_oidオブジェクト識別子、
o oid_set SET OF OBJECT IDENTIFIER
o oid_setオブジェクト識別子のセット
Outputs:
出力：
o major_status INTEGER,
o Major_status整数、
o minor_status INTEGER,
o minor_status整数、
Return major_status codes:
Major_statusコードを返す：
o GSS_S_COMPLETE indicates successful completion
o GSS_S_COMPLETEは、正常に完了したことを示します
o GSS_S_FAILURE indicates that the operation failed
o GSS_S_FAILUREは、操作が失敗したことを示します
Adds an Object Identifier to an Object Identifier set. This routine is intended for use in conjunction with GSS_Create_empty_OID_set() when constructing a set of mechanism OIDs for input to GSS_Acquire_cred().
オブジェクト識別子をオブジェクト識別子セットに追加します。このルーチンは、GSS_ACQUIRE_CRED（）に入力するための一連のメカニズムOIDを構築するときに、GSS_CREATE_EMPTY_OID_SET（）と組み合わせて使用することを目的としています。
2.4.11: GSS_Test_OID_set_member call
2.4.11：gss_test_oid_set_memberコール
Inputs:
入力：
o member OBJECT IDENTIFIER,
o メンバーオブジェクト識別子、
o set SET OF OBJECT IDENTIFIER
o オブジェクト識別子のセットセット
Outputs:
出力：
o major_status INTEGER,
o Major_status整数、
o minor_status INTEGER,
o minor_status整数、
o present BOOLEAN
o 現在のブール
Return major_status codes:
Major_statusコードを返す：
o GSS_S_COMPLETE indicates successful completion
o GSS_S_COMPLETEは、正常に完了したことを示します
o GSS_S_FAILURE indicates that the operation failed Interrogates an Object Identifier set to determine whether a specified Object Identifier is a member. This routine is intended to be used with OID sets returned by GSS_Indicate_mechs(), GSS_Acquire_cred(), and GSS_Inquire_cred().
o GSS_S_FAILUREは、操作が失敗したことが、指定されたオブジェクト識別子がメンバーであるかどうかを判断するためにオブジェクト識別子セットを尋問したことを示します。このルーチンは、gss_indicate_mechs（）、gss_acquire_cred（）、およびgss_inquire_cred（）によって返されるoidセットで使用することを目的としています。
2.4.12: GSS_Inquire_names_for_mech call
2.4.12：gss_inquire_names_for_mech呼び出し
Input:
入力：
o input_mech_type OBJECT IDENTIFIER, -- mechanism type
o input_mech_typeオブジェクト識別子、 - メカニズムタイプ
Outputs:
出力：
o major_status INTEGER,
o Major_status整数、
o minor_status INTEGER,
o minor_status整数、
o name_type_set SET OF OBJECT IDENTIFIER -- caller must release -- with GSS_Release_oid_set()
o name_type_setオブジェクト識別子のセット - 発信者はリリースする必要があります - gss_release_oid_set（）
Return major_status codes:
Major_statusコードを返す：
o GSS_S_COMPLETE indicates that the output name_type_set contains a list of name types which are supported by the locally available mechanism identified by input_mech_type.
o gss_s_completeは、出力name_type_setに、input_mech_typeによって識別されるローカルで利用可能なメカニズムによってサポートされる名前のタイプのリストが含まれていることを示します。
o GSS_S_BAD_MECH indicates that the mechanism identified by input_mech_type was unsupported within the local implementation, causing the query to fail.
o GSS_S_BAD_MECHは、input_mech_typeによって識別されたメカニズムがローカル実装内でサポートされておらず、クエリが失敗することを示しています。
o GSS_S_FAILURE indicates that the requested operation could not be performed for reasons unspecified at the GSS-API level.
o GSS_S_FAILUREは、GSS-APIレベルで不特定の理由で要求された操作を実行できなかったことを示しています。
Allows callers to determine the set of name types which are supportable by a specific locally-available mechanism.
発信者は、特定のローカルで利用可能なメカニズムによってサポートできる名前のセットを決定できます。
2.4.13: GSS_Inquire_mechs_for_name call
2.4.13：gss_inquire_mechs_for_name call
Inputs:
入力：
o input_name INTERNAL NAME,
o input_name内部名、
Outputs:
出力：
o major_status INTEGER,
o Major_status整数、
o minor_status INTEGER, o mech_types SET OF OBJECT IDENTIFIER -- caller must release -- with GSS_Release_oid_set()
o minor_status integer、o mech_typesオブジェクト識別子のセット - 発信者はリリースする必要があります-gss_release_oid_set（）
Return major_status codes:
Major_statusコードを返す：
o GSS_S_COMPLETE indicates that a set of object identifiers, corresponding to the set of mechanisms suitable for processing the input_name, is available in mech_types.
o GSS_S_COMPLETEは、input_nameの処理に適した一連のメカニズムに対応するオブジェクト識別子のセットがmech_typesで利用可能であることを示します。
o GSS_S_BAD_NAME indicates that the input_name was ill-formed and could not be processed.
o GSS_S_BAD_NAMEは、input_nameが不適切で処理できなかったことを示します。
o GSS_S_BAD_NAMETYPE indicates that the input_name parameter contained an invalid name type or a name type unsupported by the GSS-API implementation.
o gss_s_bad_nameTypeは、input_nameパラメーターに無効な名前タイプまたはGSS-API実装によってサポートされていない名前のタイプが含まれていることを示します。
o GSS_S_FAILURE indicates that the requested operation could not be performed for reasons unspecified at the GSS-API level.
o GSS_S_FAILUREは、GSS-APIレベルで不特定の理由で要求された操作を実行できなかったことを示しています。
This routine returns the mechanism set with which the input_name may be processed.
このルーチンは、input_nameが処理される可能性のあるメカニズムセットを返します。
Each mechanism returned will recognize at least one element within the name. It is permissible for this routine to be implemented within a mechanism-independent GSS-API layer, using the type information contained within the presented name, and based on registration information provided by individual mechanism implementations. This means that the returned mech_types result may indicate that a particular mechanism will understand a particular name when in fact it would refuse to accept that name as input to GSS_Canonicalize_name(), GSS_Init_sec_context(), GSS_Acquire_cred(), or GSS_Add_cred(), due to some property of the particular name rather than a property of the name type. Thus, this routine should be used only as a pre-filter for a call to a subsequent mechanism-specific routine.
返される各メカニズムは、名前内の少なくとも1つの要素を認識します。このルーチンは、提示された名前に含まれるタイプ情報を使用し、個々のメカニズムの実装によって提供される登録情報に基づいて、メカニズムに依存しないGSS-APIレイヤー内で実装されることが許されます。これは、返されたmech_typesの結果が、特定のメカニズムが特定の名前を理解することを示している可能性があることを意味します。実際、GSS_CANONICALIZE_NAME（）、GSS_INIT_SEC_CONTEXT（）、GSS_ACQUIRE_CRED（）、またはGSS_ADD_CRED（）、GSS_ACQUIRE_CRED（）、GSS_ACQUIRE_CRED（）への入力としてその名前を受け入れることを拒否することを示しています。名前タイプのプロパティではなく、特定の名前の一部のプロパティ。したがって、このルーチンは、その後のメカニズム固有のルーチンを呼び出すための事前フィルターとしてのみ使用する必要があります。
2.4.14: GSS_Canonicalize_name call
2.4.14：GSS_CANONICALIZE_NAME CALL
Inputs:
入力：
o input_name INTERNAL NAME,
o input_name内部名、
o mech_type OBJECT IDENTIFIER -- must be explicit mechanism, -- not "default" specifier or identifier of negotiating mechanism
o mech_typeオブジェクト識別子 - 明示的なメカニズムでなければなりません - 「デフォルト」指定子または交渉メカニズムの識別子ではありません
Outputs:
出力：
o major_status INTEGER, o minor_status INTEGER,
o major_status integer、o minor_status integer、
o output_name INTERNAL NAME -- caller must release with -- GSS_Release_name()
o output_name内部名 - 発信者は-gss_release_name（）でリリースする必要があります
Return major_status codes:
Major_statusコードを返す：
o GSS_S_COMPLETE indicates that a mechanism-specific reduction of the input_name, as processed by the mechanism identified by mech_type, is available in output_name.
o GSS_S_COMPLETEは、mech_typeによって識別されたメカニズムによって処理されるように、input_nameのメカニズム固有の削減がoutput_nameで利用可能であることを示しています。
o GSS_S_BAD_MECH indicates that the identified mechanism is unsupported for this operation; this may correspond either to a mechanism wholly unsupported by the local GSS-API implementation or to a negotiating mechanism with which the canonicalization operation cannot be performed.
o GSS_S_BAD_MECHは、特定されたメカニズムがこの操作にサポートされていないことを示しています。これは、ローカルGSS-APIの実装によって完全にサポートされていないメカニズムまたは標準化操作を実行できない交渉メカニズムに対応する場合があります。
o GSS_S_BAD_NAMETYPE indicates that the input name does not contain an element with suitable type for processing by the identified mechanism.
o GSS_S_BAD_NAMETYPEは、入力名に、特定されたメカニズムによって処理に適したタイプの要素が含まれていないことを示しています。
o GSS_S_BAD_NAME indicates that the input name contains an element with suitable type for processing by the identified mechanism, but that this element could not be processed successfully.
o GSS_S_BAD_NAMEは、入力名に識別されたメカニズムで処理するのに適したタイプの要素が含まれているが、この要素を正常に処理できなかったことを示します。
o GSS_S_FAILURE indicates that the requested operation could not be performed for reasons unspecified at the GSS-API level.
o GSS_S_FAILUREは、GSS-APIレベルで不特定の理由で要求された操作を実行できなかったことを示しています。
This routine reduces a GSS-API internal name input_name, which may in general contain elements corresponding to multiple mechanisms, to a mechanism-specific Mechanism Name (MN) output_name by applying the translations corresponding to the mechanism identified by mech_type. The contents of input_name are unaffected by the GSS_Canonicalize_name() operation. References to output_name will remain valid until output_name is released, independent of whether or not input_name is subsequently released.
このルーチンは、一般に、複数のメカニズムに対応する要素をメカニズム固有のメカニズム名（MN）output_nameに、mech_typeで識別されるメカニズムに対応する変換を適用することにより、メカニズム固有のメカニズム名（mn）output_nameを含むGSS-APIの内部名input_nameを削減します。input_nameの内容は、gss_canonicalize_name（）操作の影響を受けません。output_nameへの参照は、input_nameがその後リリースされるかどうかに関係なく、output_nameがリリースされるまで有効なままです。
2.4.15: GSS_Export_name call
2.4.15：GSS_EXPORT_NAME CALL
Inputs:
入力：
o input_name INTERNAL NAME, -- required to be MN
o input_name内部名、mnである必要があります
Outputs:
出力：
o major_status INTEGER,
o Major_status整数、
o minor_status INTEGER, o output_name OCTET STRING -- caller must release -- with GSS_Release_buffer()
o minor_status integer、o output_nameオクテット文字
Return major_status codes:
Major_statusコードを返す：
o GSS_S_COMPLETE indicates that a flat representation of the input name is available in output_name.
o GSS_S_COMPLETEは、入力名のフラット表現がoutput_nameで利用可能であることを示します。
o GSS_S_NAME_NOT_MN indicates that the input name contained elements corresponding to multiple mechanisms, so cannot be exported into a single-mechanism flat form.
o GSS_S_NAME_NOT_MNは、入力名に複数のメカニズムに対応する要素が含まれていることを示しているため、単一メカニズムのフラットフォームにエクスポートできないことを示します。
o GSS_S_BAD_NAME indicates that the input name was an MN, but could not be processed.
o GSS_S_BAD_NAMEは、入力名がMNであったことを示しますが、処理できませんでした。
o GSS_S_BAD_NAMETYPE indicates that the input name was an MN, but that its type is unsupported by the GSS-API implementation.
o GSS_S_BAD_NAMETYPEは、入力名がMNであるが、そのタイプはGSS-API実装によってサポートされていないことを示しています。
o GSS_S_FAILURE indicates that the requested operation could not be performed for reasons unspecified at the GSS-API level.
o GSS_S_FAILUREは、GSS-APIレベルで不特定の理由で要求された操作を実行できなかったことを示しています。
This routine creates a flat name representation, suitable for bytewise comparison or for input to GSS_Import_name() in conjunction with the reserved GSS-API Exported Name Object OID, from a internal-form Mechanism Name (MN) as emitted, e.g., by GSS_Canonicalize_name() or GSS_Accept_sec_context().
このルーチンは、BYTEWISEの比較または予約されたGSS_IMPORT_NAME（）への入力に適したフラット名表現を作成します。）またはgss_accept_sec_context（）。
The emitted GSS-API Exported Name Object is self-describing; no associated parameter-level OID need be emitted by this call. This flat representation consists of a mechanism-independent wrapper layer, defined in Section 3.2 of this document, enclosing a mechanism-defined name representation.
放出されたGSS-APIエクスポート名オブジェクトは自己記述的です。この呼び出しで関連するパラメーターレベルのOIDを放射する必要はありません。このフラット表現は、このドキュメントのセクション3.2で定義されているメカニズムに依存しないラッパー層で構成され、メカニズム定義の名前表現を囲みます。
In all cases, the flat name output by GSS_Export_name() to correspond to a particular input MN must be invariant over time within a particular installation.
すべての場合において、特定の入力MNに対応するGSS_EXPORT_NAME（）によるフラット名出力は、特定のインストール内で時間の経過とともに不変でなければなりません。
The GSS_S_NAME_NOT_MN status code is provided to enable implementations to reject input names which are not MNs. It is not, however, required for purposes of conformance to this specification that all non-MN input names must necessarily be rejected.
GSS_S_NAME_NOT_MNステータスコードは、MNSではない入力名を拒否できるように実装できるように提供されます。ただし、すべての非MN入力名を必然的に拒否しなければならないというこの仕様への適合の目的では、必要ではありません。
2.4.16: GSS_Duplicate_name call
2.4.16：gss_duplicate_name call
Inputs:
入力：
o src_name INTERNAL NAME Outputs:
o src_name内部名出力：
o major_status INTEGER,
o Major_status整数、
o minor_status INTEGER,
o minor_status整数、
o dest_name INTERNAL NAME -- caller must release -- with GSS_Release_name()
o DEST_NAME内部名 - 発信者はリリースする必要があります-GSS_RELEASE_NAME（）
Return major_status codes:
Major_statusコードを返す：
o GSS_S_COMPLETE indicates that dest_name references an internal name object containing the same name as passed to src_name.
o gss_s_completeは、dest_nameがsrc_nameに渡されたのと同じ名前を含む内部名オブジェクトを参照することを示します。
o GSS_S_BAD_NAME indicates that the input name was invalid.
o GSS_S_BAD_NAMEは、入力名が無効であることを示します。
o GSS_S_FAILURE indicates that the requested operation could not be performed for reasons unspecified at the GSS-API level.
o GSS_S_FAILUREは、GSS-APIレベルで不特定の理由で要求された操作を実行できなかったことを示しています。
This routine takes input internal name src_name, and returns another reference (dest_name) to that name which can be used even if src_name is later freed. (Note: This may be implemented by copying or through use of reference counts.)
このルーチンは、入力内部名src_nameを取得し、src_nameが後で解放された場合でも使用できる別の参照（dest_name）をその名前に返します。（注：これは、コピーまたは参照カウントの使用によって実装される場合があります。）
3: Data Structure Definitions for GSS-V2 Usage
3：GSS-V2の使用に関するデータ構造定義
Subsections of this section define, for interoperability and portability purposes, certain data structures for use with GSS-V2.
このセクションのサブセクションは、相互運用性と携帯性の目的で、GSS-V2で使用する特定のデータ構造を定義しています。
3.1: Mechanism-Independent Token Format
3.1：メカニズムに依存しないトークン形式
This section specifies a mechanism-independent level of encapsulating representation for the initial token of a GSS-API context establishment sequence, incorporating an identifier of the mechanism type to be used on that context and enabling tokens to be interpreted unambiguously at GSS-API peers. Use of this format is required for initial context establishment tokens of Internet standards-track GSS-API mechanisms; use in non-initial tokens is optional.
このセクションでは、GSS-APIコンテキスト確立シーケンスの初期トークンのメカニズムに依存しないレベルのカプセル化表現を指定し、そのコンテキストで使用するメカニズムタイプの識別子を組み込み、トークンがGSS-APIピアで明確に解釈されることを可能にします。この形式の使用は、インターネット標準のGSS-APIメカニズムのトークンの初期コンテキスト確立トークンに必要です。非初期トークンでの使用はオプションです。
The encoding format for the token tag is derived from ASN.1 and DER (per illustrative ASN.1 syntax included later within this subsection), but its concrete representation is defined directly in terms of octets rather than at the ASN.1 level in order to facilitate interoperable implementation without use of general ASN.1 processing code. The token tag consists of the following elements, in order:
トークンタグのエンコーディング形式は、asn.1およびder（このサブセクション内に後で含まれる例のasn.1構文ごと）から派生していますが、その具体的な表現は、asn.1レベルではなくオクテットの観点から直接定義されます。一般的なASN.1処理コードを使用せずに相互運用可能な実装を容易にする。トークンタグは、次の要素で構成されています。
1. 0x60 -- Tag for [APPLICATION 0] SEQUENCE; indicates that -- constructed form, definite length encoding follows.
1. 0x60 -[アプリケーション0]シーケンスのタグ。 - 構築されたフォーム、明確な長さエンコーディングが続くことを示します。
2. Token length octets, specifying length of subsequent data (i.e., the summed lengths of elements 3-5 in this list, and of the mechanism-defined token object following the tag). This element comprises a variable number of octets:
2. トークンの長さのオクテット、後続のデータの長さを指定します（つまり、このリストの要素3〜5の合計長さ、およびタグに続くメカニズム定義のトークンオブジェクトの長さ）。この要素は、さまざまな数のオクテットで構成されています。
2a. If the indicated value is less than 128, it shall be represented in a single octet with bit 8 (high order) set to "0" and the remaining bits representing the value.
2a。指定された値が128未満の場合、それは「0」に設定されたビット8（高次）と値を表す残りのビットを持つ単一のオクテットで表されるものとします。
2b. If the indicated value is 128 or more, it shall be represented in two or more octets, with bit 8 of the first octet set to "1" and the remaining bits of the first octet specifying the number of additional octets. The subsequent octets carry the value, 8 bits per octet, most significant digit first. The minimum number of octets shall be used to encode the length (i.e., no octets representing leading zeros shall be included within the length encoding).
2b。指定された値が128以上の場合、最初のオクテットのビット8を「1」に設定し、最初のオクテットの残りのビットが追加のオクテットの数を指定し、2つ以上のオクテットで表されます。後続のオクテットは、最初に最も重要な数字で、オクテットあたり8ビットの値を持ちます。オクテットの最小数は、長さをエンコードするために使用するものとします（つまり、主要なゼロを表すオクテットは長さエンコーディングに含まれないものとします）。
3. 0x06 -- Tag for OBJECT IDENTIFIER
3. 0x06-オブジェクト識別子のタグ
4. Object identifier length -- length (number of octets) of -- the encoded object identifier contained in element 5, -- encoded per rules as described in 2a. and 2b. above.
4. オブジェクト識別子の長さ - 長さ（オクテットの数） - 要素5に含まれるエンコードされたオブジェクト識別子 - 2Aで説明されている規則ごとにエンコードされた。および2b。その上。
5. Object identifier octets -- variable number of octets, -- encoded per ASN.1 BER rules:
5. オブジェクト識別子オクテット - オクテットの可変数、-ASN.1 BERルールごとにエンコードされています。
5a. The first octet contains the sum of two values: (1) the top-level object identifier component, multiplied by 40 (decimal), and (2) the second-level object identifier component. This special case is the only point within an object identifier encoding where a single octet represents contents of more than one component.
5a。最初のオクテットには、2つの値の合計が含まれています。（1）上位オブジェクト識別子コンポーネントに40（小数）を掛け、（2）第2レベルオブジェクト識別子コンポーネント。この特別なケースは、単一のオクテットが複数のコンポーネントの内容を表す場合、オブジェクト識別子エンコード内の唯一のポイントです。
5b. Subsequent octets, if required, encode successively-lower components in the represented object identifier. A component's encoding may span multiple octets, encoding 7 bits per octet (most significant bits first) and with bit 8 set to "1" on all but the final octet in the component's encoding. The minimum number of octets shall be used to encode each component (i.e., no octets representing leading zeros shall be included within a component's encoding).
5b。後続のオクテットは、必要に応じて、表現されたオブジェクト識別子で連続して低いコンポーネントをエンコードします。コンポーネントのエンコーディングは、オクテットあたり7ビット（最初に最も重要なビット）をエンコードし、ビット8がコンポーネントのエンコードの最後のオクテットを除くすべてで「1」に設定されている複数のオクテットにまたがる場合があります。オクテットの最小数は、各コンポーネントをエンコードするために使用されます（つまり、主要なゼロを表すオクテットはコンポーネントのエンコードに含まれてはなりません）。
(Note: In many implementations, elements 3-5 may be stored and referenced as a contiguous string constant.)
（注：多くの実装では、要素3-5が保存され、連続した文字列定数として参照される場合があります。）
The token tag is immediately followed by a mechanism-defined token object. Note that no independent size specifier intervenes following the object identifier value to indicate the size of the mechanism-defined token object. While ASN.1 usage within mechanism-defined tokens is permitted, there is no requirement that the mechanism-specific innerContextToken, innerMsgToken, and sealedUserData data elements must employ ASN.1 BER/DER encoding conventions.
トークンタグのすぐ後に、メカニズム定義のトークンオブジェクトが続きます。メカニズム定義のトークンオブジェクトのサイズを示すために、オブジェクト識別子値に従って独立したサイズの仕様が介入しないことに注意してください。メカニズムで定義されたトークン内のASN.1の使用は許可されていますが、メカニズム固有のInternContextToken、Innermsgtoken、およびSealeduserDataデータ要素がASN.1 BER/DERエンコード規則を使用する必要があるという要件はありません。
The following ASN.1 syntax is included for descriptive purposes only, to illustrate structural relationships among token and tag objects. For interoperability purposes, token and tag encoding shall be performed using the concrete encoding procedures described earlier in this subsection.
次のASN.1構文は、トークンとタグオブジェクト間の構造的関係を説明するために、記述目的のみを目的としています。相互運用性のために、このサブセクションで前述した具体的なエンコード手順を使用して、トークンとタグエンコードを実行するものとします。
GSS-API DEFINITIONS ::=
BEGIN
始める
MechType ::= OBJECT IDENTIFIER
-- data structure definitions
-- callers must be able to distinguish among
-- InitialContextToken, SubsequentContextToken,
-- PerMsgToken, and SealedMessage data elements
-- based on the usage in which they occur
InitialContextToken ::=
-- option indication (delegation, etc.) indicated within
-- mechanism-specific token
[APPLICATION 0] IMPLICIT SEQUENCE {
thisMech MechType,
innerContextToken ANY DEFINED BY thisMech
-- contents mechanism-specific
-- ASN.1 structure not required
}
SubsequentContextToken ::= innerContextToken ANY
-- interpretation based on predecessor InitialContextToken
-- ASN.1 structure not required
PerMsgToken ::=
-- as emitted by GSS_GetMIC and processed by GSS_VerifyMIC
-- ASN.1 structure not required
innerMsgToken ANY
SealedMessage ::=
-- as emitted by GSS_Wrap and processed by GSS_Unwrap
-- includes internal, mechanism-defined indicator
-- of whether or not encrypted
-- ASN.1 structure not required sealedUserData ANY
-ASN.1構造は必要ありませんsealeduserdata any
END
終わり
3.2: Mechanism-Independent Exported Name Object Format
3.2：メカニズムに依存しないエクスポートされた名前オブジェクト形式
This section specifies a mechanism-independent level of encapsulating representation for names exported via the GSS_Export_name() call, including an object identifier representing the exporting mechanism. The format of names encapsulated via this representation shall be defined within individual mechanism drafts. The Object Identifier value to indicate names of this type is defined in Section 4.7 of this document.
このセクションでは、エクスポートメカニズムを表すオブジェクト識別子を含むGSS_EXPORT_NAME（）コールを介してエクスポートされる名前のカプセル化表現のメカニズムに依存しないレベルを指定します。この表現を介してカプセル化された名前の形式は、個々のメカニズムドラフト内で定義されるものとします。このタイプの名前を示すオブジェクト識別子値は、このドキュメントのセクション4.7で定義されています。
No name type OID is included in this mechanism-independent level of format definition, since (depending on individual mechanism specifications) the enclosed name may be implicitly typed or may be explicitly typed using a means other than OID encoding.
（個々のメカニズムの仕様に応じて）囲まれた名前が暗黙的にタイプされるか、OIDエンコード以外の平均を使用して明示的に入力される場合があるため、このメカニズムに依存しないレベルの形式定義には、名前タイプのOIDは含まれていません。
The bytes within MECH_OID_LEN and NAME_LEN elements are represented most significant byte first (equivalently, in IP network byte order).
mech_oid_lenおよびname_len要素内のバイトは、最初に最も重要なバイトと表されます（同等に、IPネットワークバイトの順序で）。
Length Name Description
長さの名前の説明
2 TOK_ID Token Identifier
For exported name objects, this
must be hex 04 01.
2 MECH_OID_LEN Length of the Mechanism OID
MECH_OID_LEN MECH_OID Mechanism OID, in DER
4 NAME_LEN Length of name
NAME_LEN NAME Exported name; format defined in
applicable mechanism draft.
A concrete example of the contents of an exported name object, derived from the Kerberos Version 5 mechanism, is as follows:
Kerberosバージョン5メカニズムから派生したエクスポートされた名前オブジェクトの内容の具体的な例は次のとおりです。
04 01 00 0B 06 09 2A 86 48 86 F7 12 01 02 02 hx xx xx xl pp qq ... zz
04 01 00 0B 06 09 2A 86 48 86 F7 12 01 02 02 HX XX XX XL PP QQ ... ZZ
04 01 mandatory token identifier
04 01必須トークン識別子
00 0B 2-byte length of the immediately following DER-encoded ASN.1 value of type OID, most significant octet first
00 0B 2バイトの長さの直後のderエンコードされたasn.1タイプの値、最も重要なオクテット
06 09 2A 86 48 86 F7 12 01 02 02 DER-encoded ASN.1 value of type OID; Kerberos V5 mechanism OID indicates Kerberos V5 exported name
06 09 2A 86 48 86 F7 12 01 02 02 DER-ENCODED ASN.1タイプOIDの値。Kerberos V5メカニズムOIDは、Kerberos V5エクスポート名を示しています
in Detail: 06 Identifier octet (6=OID)
09 Length octet(s)
2A 86 48 86 F7 12 01 02 02 Content octet(s)
hx xx xx xl 4-byte length of the immediately following exported name blob, most significant octet first
HX XX XX XL 4バイトの長さの直後のエクスポートされた名前Blob、最も重要なOctet First
pp qq ... zz exported name blob of specified length, bits and bytes specified in the (Kerberos 5) GSS-API v2 mechanism spec
PP QQ ... ZZエクスポートされた名前のブロブ、（Kerberos 5）GSS-API V2メカニズムスペックで指定された指定されたビット、バイト
4: Name Type Definitions
4：名前タイプ定義
This section includes definitions for name types and associated syntaxes which are defined in a mechanism-independent fashion at the GSS-API level rather than being defined in individual mechanism specifications.
このセクションには、個々のメカニズム仕様で定義されるのではなく、GSS-APIレベルでメカニズムに依存しない方法で定義される名前タイプと関連する構文の定義が含まれています。
4.1: Host-Based Service Name Form
4.1：ホストベースのサービス名フォーム
This name form shall be represented by the Object Identifier:
この名前フォームは、オブジェクト識別子で表されるものとします。
{iso(1) member-body(2) United States(840) mit(113554) infosys(1) "gssapi(2) generic(1) service_name(4)}.
{ISO（1）メンバーボディ（2）米国（840）MIT（113554）Infosys（1） "gssapi（2）generic（1）service_name（4）}。
The recommended symbolic name for this type is "GSS_C_NT_HOSTBASED_SERVICE".
このタイプの推奨されるシンボリック名は「GSS_C_NT_HOSTBASED_SERVICE」です。
For reasons of compatibility with existing implementations, it is recommended that this OID be used rather than the alternate value as included in [RFC-2078]:
既存の実装との互換性の理由により、[RFC-2078]に含まれる代替値ではなく、このOIDを使用することをお勧めします。
{1(iso), 3(org), 6(dod), 1(internet), 5(security), 6(nametypes),
2(gss-host-based-services)}
While it is not recommended that this alternate value be emitted on output by GSS implementations, it is recommended that it be accepted on input as equivalent to the recommended value.
この代替値をGSS実装により出力で放出することはお勧めしませんが、推奨値に相当するように入力で受け入れられることをお勧めします。
This name type is used to represent services associated with host computers. Support for this name form is recommended to mechanism designers in the interests of portability, but is not mandated by this specification. This name form is constructed using two elements, "service" and "hostname", as follows:
この名前のタイプは、ホストコンピューターに関連するサービスを表すために使用されます。この名前のサポートは、携帯性のために設計者にメカニズムに推奨されますが、この仕様では義務付けられていません。この名前フォームは、次のように、「サービス」と「ホスト名」の2つの要素を使用して構築されます。
service@hostname
service@hostname
When a reference to a name of this type is resolved, the "hostname" may (as an example implementation strategy) be canonicalized by attempting a DNS lookup and using the fully-qualified domain name which is returned, or by using the "hostname" as provided if the DNS lookup fails. The canonicalization operation also maps the host's name into lower-case characters.
このタイプの名前への参照が解決されると、「ホスト名」は（実装戦略の例として）DNSルックアップを試み、返される完全に適格なドメイン名を使用するか、「ホスト名」を使用することにより、標準化される可能性があります。DNSルックアップが失敗した場合は提供されています。また、標準化操作は、ホストの名前を低ケース文字にマッピングします。
The "hostname" element may be omitted. If no "@" separator is included, the entire name is interpreted as the service specifier, with the "hostname" defaulted to the canonicalized name of the local host.
「ホスト名」要素は省略できます。「@」セパレーターが含まれていない場合、名前全体がサービス仕様として解釈され、「ホスト名」はローカルホストの標準化された名前にデフォルトされました。
Documents specifying means for GSS integration into a particular protocol should state either:
特定のプロトコルへのGSS統合の手段を指定するドキュメントは次のとおりです。
(a) that a specific IANA-registered name associated with that protocol shall be used for the "service" element (this admits, if needed, the possibility that a single name can be registered and shared among a related set of protocols), or
(a) そのプロトコルに関連付けられた特定のIANA登録名は、「サービス」要素に使用されるものとすること（これは、必要に応じて、単一の名前を関連するプロトコルのセット間で登録および共有できる可能性を認めます）、または
(b) that the generic name "host" shall be used for the "service" element, or
(b) 一般名「ホスト」が「サービス」要素に使用されること、または
(c) that, for that protocol, fallback in specified order (a, then b) or (b, then a) shall be applied.
(c) そのプロトコルでは、指定された順序（a、b）または（b、a）のフォールバックを適用するものとします。
IANA registration of specific names per (a) should be handled in accordance with the "Specification Required" assignment policy, defined by BCP 26, RFC 2434 as follows: "Values and their meaning must be documented in an RFC or other available reference, in sufficient detail so that interoperability between independent implementations is possible."
（a）あたりの特定の名前のIANA登録は、BCP 26、RFC 2434で定義された「必要な」割り当てポリシーに従って処理する必要があります。独立した実装間の相互運用性が可能であるため、十分な詳細が可能です。」
4.2: User Name Form
4.2：ユーザー名フォーム
This name form shall be represented by the Object Identifier {iso(1) member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) generic(1) user_name(1)}. The recommended mechanism-independent symbolic name for this type is "GSS_C_NT_USER_NAME". (Note: the same name form and OID is defined within the Kerberos V5 GSS-API mechanism, but the symbolic name recommended there begins with a "GSS_KRB5_NT_" prefix.)
この名前の形式は、オブジェクト識別子{ISO（1）メンバーボディ（2）米国（840）MIT（113554）Infosys（1）GSSAPI（2）generic（1）user_name（1）}で表されるものとします。このタイプの推奨メカニズムに依存しないシンボリック名は「GSS_C_NT_USER_NAME」です。（注：同じ名前フォームとOIDはKerberos V5 GSS-APIメカニズム内で定義されていますが、そこから推奨されるシンボリック名は「GSS_KRB5_NT_」プレフィックスで始まります。）
This name type is used to indicate a named user on a local system. Its syntax and interpretation may be OS-specific. This name form is constructed as:
この名前のタイプは、ローカルシステムで指定されたユーザーを示すために使用されます。その構文と解釈はOS固有のものである場合があります。この名前のフォームは次のように構築されています。
username
ユーザー名
4.3: Machine UID Form
4.3：マシンUIDフォーム
This name form shall be represented by the Object Identifier {iso(1) member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) generic(1) machine_uid_name(2)}. The recommended mechanism-independent symbolic name for this type is "GSS_C_NT_MACHINE_UID_NAME". (Note: the same name form and OID is defined within the Kerberos V5 GSS-API mechanism, but the symbolic name recommended there begins with a "GSS_KRB5_NT_" prefix.)
この名前の形式は、オブジェクト識別子{ISO（1）メンバーボディ（2）米国（840）MIT（113554）Infosys（1）GSSAPI（2）Generic（1）Machine_Uid_Name（2）}で表されるものとします。このタイプの推奨メカニズムに依存しないシンボリック名は「GSS_C_NT_MACHINE_UID_NAME」です。（注：同じ名前フォームとOIDはKerberos V5 GSS-APIメカニズム内で定義されていますが、そこから推奨されるシンボリック名は「GSS_KRB5_NT_」プレフィックスで始まります。）
This name type is used to indicate a numeric user identifier corresponding to a user on a local system. Its interpretation is OS-specific. The gss_buffer_desc representing a name of this type should contain a locally-significant user ID, represented in host byte order. The GSS_Import_name() operation resolves this uid into a username, which is then treated as the User Name Form.
この名前のタイプは、ローカルシステム上のユーザーに対応する数値ユーザー識別子を示すために使用されます。その解釈はOS固有です。このタイプの名前を表すGSS_BUFFER_DESCには、ホストバイトの順序で表されるローカルに重要なユーザーIDを含める必要があります。gss_import_name（）操作は、このuidをユーザー名に解決し、ユーザー名フォームとして扱います。
4.4: String UID Form
4.4：文字列uidフォーム
This name form shall be represented by the Object Identifier {iso(1) member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) generic(1) string_uid_name(3)}. The recommended symbolic name for this type is "GSS_C_NT_STRING_UID_NAME". (Note: the same name form and OID is defined within the Kerberos V5 GSS-API mechanism, but the symbolic name recommended there begins with a "GSS_KRB5_NT_" prefix.)
この名前の形式は、オブジェクト識別子{ISO（1）メンバーボディ（2）米国（840）MIT（113554）Infosys（1）GSSAPI（2）Generic（1）String_uid_name（3）}で表されるものとします。このタイプの推奨されるシンボリック名は「GSS_C_NT_STRING_UID_NAME」です。（注：同じ名前フォームとOIDはKerberos V5 GSS-APIメカニズム内で定義されていますが、そこから推奨されるシンボリック名は「GSS_KRB5_NT_」プレフィックスで始まります。）
This name type is used to indicate a string of digits representing the numeric user identifier of a user on a local system. Its interpretation is OS-specific. This name type is similar to the Machine UID Form, except that the buffer contains a string representing the user ID.
この名前のタイプは、ローカルシステム上のユーザーの数値ユーザー識別子を表す一連の数字を示すために使用されます。その解釈はOS固有です。この名前のタイプは、バッファにユーザーIDを表す文字列が含まれていることを除いて、マシンUIDフォームに似ています。
4.5: Anonymous Nametype
4.5：匿名のNameType
The following Object Identifier value is provided as a means to identify anonymous names, and can be compared against in order to determine, in a mechanism-independent fashion, whether a name refers to an anonymous principal:
次のオブジェクト識別子値は、匿名の名前を識別する手段として提供され、メカニズムに依存しない方法で、名前が匿名のプリンシパルを指すかどうかを決定するために比較することができます。
{1(iso), 3(org), 6(dod), 1(internet), 5(security), 6(nametypes),
3(gss-anonymous-name)}
The recommended symbolic name corresponding to this definition is GSS_C_NT_ANONYMOUS.
この定義に対応する推奨されるシンボリック名は、GSS_C_NT_ANNYMOUSです。
4.6: GSS_C_NO_OID
4.6：GSS_C_NO_OID
The recommended symbolic name GSS_C_NO_OID corresponds to a null input value instead of an actual object identifier. Where specified, it indicates interpretation of an associated name based on a mechanism-specific default printable syntax.
推奨されるシンボリック名gss_c_no_oidは、実際のオブジェクト識別子の代わりにnull入力値に対応します。指定されている場合、メカニズム固有のデフォルトの印刷可能な構文に基づいて、関連付けられた名前の解釈を示します。
4.7: Exported Name Object
4.7：エクスポートされた名前オブジェクト
Name objects of the Mechanism-Independent Exported Name Object type, as defined in Section 3.2 of this document, will be identified with the following Object Identifier:
このドキュメントのセクション3.2で定義されているメカニズムに依存しないエクスポートされた名前オブジェクトタイプの名前オブジェクトは、次のオブジェクト識別子で識別されます。
{1(iso), 3(org), 6(dod), 1(internet), 5(security), 6(nametypes),
4(gss-api-exported-name)}
The recommended symbolic name corresponding to this definition is GSS_C_NT_EXPORT_NAME.
この定義に対応する推奨されるシンボリック名は、GSS_C_NT_EXPORT_NAMEです。
4.8: GSS_C_NO_NAME
4.8：gss_c_no_name
The recommended symbolic name GSS_C_NO_NAME indicates that no name is being passed within a particular value of a parameter used for the purpose of transferring names. Note: GSS_C_NO_NAME is not an actual name type, and is not represented by an OID; its acceptability in lieu of an actual name is confined to specific calls (GSS_Acquire_cred(), GSS_Add_cred(), and GSS_Init_sec_context()) with usages as identified within this specification.
推奨されるシンボリック名GSS_C_NO_NAMEは、名前を転送する目的で使用されるパラメーターの特定の値内に名前が渡されないことを示します。注：GSS_C_NO_NAMEは実際の名前タイプではなく、OIDで表されません。実際の名前の代わりにその受容性は、特定の呼び出し（gss_acquire_cred（）、gss_add_cred（）、およびgss_init_sec_context（）に限定されています。
5: Mechanism-Specific Example Scenarios
5：メカニズム固有の例シナリオ
This section provides illustrative overviews of the use of various candidate mechanism types to support the GSS-API. These discussions are intended primarily for readers familiar with specific security technologies, demonstrating how GSS-API functions can be used and implemented by candidate underlying mechanisms. They should not be regarded as constrictive to implementations or as defining the only means through which GSS-API functions can be realized with a particular underlying technology, and do not demonstrate all GSS-API features with each technology.
このセクションでは、GSS-APIをサポートするために、さまざまな候補メカニズムタイプの使用に関する説明的な概要を説明します。これらの議論は、主に特定のセキュリティテクノロジーに精通している読者向けに意図されており、GSS-API機能を候補者の基礎メカニズムによってどのように使用および実装できるかを示しています。それらは、実装に拘束力があると見なされるべきではない、またはGSS-API関数を特定の基礎となるテクノロジーで実現できる唯一の手段を定義するべきではなく、各テクノロジーですべてのGSS-API機能を実証しないでください。
5.1: Kerberos V5, single-TGT
5.1：Kerberos V5、シングルTGT
OS-specific login functions yield a TGT to the local realm Kerberos server; TGT is placed in a credentials structure for the client. Client calls GSS_Acquire_cred() to acquire a cred_handle in order to reference the credentials for use in establishing security contexts.
OS固有のログイン関数は、ローカルレルムKerberosサーバーにTGTを生成します。TGTは、クライアントの資格情報構造に配置されます。クライアントはGSS_ACQUIRE_CRED（）を呼び出して、セキュリティコンテキストの確立に使用する資格情報を参照するためにCRED_HANDLEを取得します。
Client calls GSS_Init_sec_context(). If the requested service is located in a different realm, GSS_Init_sec_context() gets the necessary TGT/key pairs needed to traverse the path from local to target realm; these data are placed in the owner's TGT cache. After any needed remote realm resolution, GSS_Init_sec_context() yields a service ticket to the requested service with a corresponding session key; these data are stored in conjunction with the context. GSS-API code sends KRB_TGS_REQ request(s) and receives KRB_TGS_REP response(s) (in the successful case) or KRB_ERROR.
クライアントはgss_init_sec_context（）を呼び出します。要求されたサービスが別の領域にある場合、GSS_INIT_SEC_CONTEXT（）は、ローカルからターゲットレルムにパスを通過するために必要なTGT/キーペアを取得します。これらのデータは、所有者のTGTキャッシュに配置されます。必要なリモートレルム解像度の後、GSS_INIT_SEC_CONTEXT（）は、対応するセッションキーを使用して、要求されたサービスへのサービスチケットを生成します。これらのデータは、コンテキストと組み合わせて保存されます。GSS-APIコードはKRB_TGS_REQ要求を送信し、KRB_TGS_REP応答（成功した場合）またはKRB_ERRORを受信します。
Assuming success, GSS_Init_sec_context() builds a Kerberos-formatted KRB_AP_REQ message, and returns it in output_token. The client sends the output_token to the service.
成功を仮定すると、GSS_INIT_SEC_CONTEXT（）はKerberos-Formatted KRB_AP_REQメッセージをビルドし、output_Tokenで返します。クライアントは、output_tokenをサービスに送信します。
The service passes the received token as the input_token argument to GSS_Accept_sec_context(), which verifies the authenticator, provides the service with the client's authenticated name, and returns an output_context_handle.
Authenticatorを検証し、クライアントの認証名をサービスに提供し、output_Context_handleを返すGSS_ACCEPT_SEC_CONTEXT（）へのinput_token引数として、受信トークンを渡します。
Both parties now hold the session key associated with the service ticket, and can use this key in subsequent GSS_GetMIC(), GSS_VerifyMIC(), GSS_Wrap(), and GSS_Unwrap() operations.
両当事者は現在、サービスチケットに関連付けられているセッションキーを保持し、このキーを後続のgss_getmic（）、gss_verifymic（）、gss_wrap（）、gss_unwrap（）操作で使用できます。
5.2: Kerberos V5, double-TGT
5.2：Kerberos V5、Double-TGT
TGT acquisition as above.
上記のTGT買収。
Note: To avoid unnecessary frequent invocations of error paths when implementing the GSS-API atop Kerberos V5, it seems appropriate to represent "single-TGT K-V5" and "double-TGT K-V5" with separate mech_types, and this discussion makes that assumption.
注：kerberos v5でGSS-APIを実装するときに不必要な頻繁なエラーパスの呼び出しを回避するには、個別のmech_typesを使用して「シングル-tgt k-v5」および「double-tgt k-v5」を表すことが適切であると思われます。その仮定。
Based on the (specified or defaulted) mech_type, GSS_Init_sec_context() determines that the double-TGT protocol should be employed for the specified target. GSS_Init_sec_context() returns GSS_S_CONTINUE_NEEDED major_status, and its returned output_token contains a request to the service for the service's TGT. (If a service TGT with suitably long remaining lifetime already exists in a cache, it may be usable, obviating the need for this step.) The client passes the output_token to the service. Note: this scenario illustrates a different use for the GSS_S_CONTINUE_NEEDED status return facility than for support of mutual authentication; note that both uses can coexist as successive operations within a single context establishment operation.
（指定またはデフォルトの）mech_typeに基づいて、gss_init_sec_context（）は、指定されたターゲットにdouble-tgtプロトコルを使用する必要があると判断します。gss_init_sec_context（）gss_s_s_continue_needed major_statusを返し、returned output_tokenにはサービスのTGTのサービスへのリクエストが含まれています。（適切に長い寿命のあるサービスTGTがすでにキャッシュに存在する場合、このステップの必要性を取り除く可能性があります。）クライアントはoutput_tokenをサービスに渡します。注：このシナリオは、相互認証のサポートというよりも、GSS_S_S_CONTINUE_NEEDEDステータスリターンファシリティの異なる使用を示しています。両方の使用は、単一のコンテキスト確立操作内で連続的な操作として共存できることに注意してください。
The service passes the received token as the input_token argument to GSS_Accept_sec_context(), which recognizes it as a request for TGT. (Note that current Kerberos V5 defines no intra-protocol mechanism to represent such a request.) GSS_Accept_sec_context() returns GSS_S_CONTINUE_NEEDED major_status and provides the service's TGT in its output_token. The service sends the output_token to the client.
このサービスは、input_token引数としてgss_accept_sec_context（）の入力_token引数として渡されます。これは、TGTのリクエストとして認識されます。（現在のKerberos V5は、そのような要求を表すためにプロトコル内メカニズムを定義していないことに注意してください。）gss_accept_sec_context（）は、gss_s_s_continue_needed major_statusを返し、output_tokenでサービスのTGTを提供します。このサービスは、output_tokenをクライアントに送信します。
The client passes the received token as the input_token argument to a continuation of GSS_Init_sec_context(). GSS_Init_sec_context() caches the received service TGT and uses it as part of a service ticket request to the Kerberos authentication server, storing the returned service ticket and session key in conjunction with the context. GSS_Init_sec_context() builds a Kerberos-formatted authenticator, and returns it in output_token along with GSS_S_COMPLETE return major_status. The client sends the output_token to the service.
クライアントは、input_token引数として受信したトークンをgss_init_sec_context（）の継続に渡します。GSS_INIT_SEC_CONTEXT（）キャッシュ受信サービスTGTをキャッシュし、Kerberos Authentication Serverへのサービスチケットリクエストの一部として使用し、コンテキストと併せて返されたサービスチケットとセッションキーを保存します。GSS_INIT_SEC_CONTEXT（）は、Kerberos-Formatted Authenticatorを構築し、GSS_S_COKENとともにoutput_tokenで返します。クライアントは、output_tokenをサービスに送信します。
Service passes the received token as the input_token argument to a continuation call to GSS_Accept_sec_context(). GSS_Accept_sec_context() verifies the authenticator, provides the service with the client's authenticated name, and returns major_status GSS_S_COMPLETE.
サービスは、input_token引数として受信したトークンをgss_accept_sec_context（）に継続的に通過します。GSS_ACCEPT_SEC_CONTEXT（）Authenticatorを検証し、クライアントの認証名をサービスに提供し、Major_Status GSS_S_Completeを返します。
GSS_GetMIC(), GSS_VerifyMIC(), GSS_Wrap(), and GSS_Unwrap() as above.
gss_getmic（）、gss_verifymic（）、gss_wrap（）、およびgss_unwrap（）上記のように。
5.3: X.509 Authentication Framework
5.3：X.509認証フレームワーク
This example illustrates use of the GSS-API in conjunction with public-key mechanisms, consistent with the X.509 Directory Authentication Framework.
この例は、X.509ディレクトリ認証フレームワークと一致して、パブリックキーメカニズムと組み合わせてGSS-APIの使用を示しています。
The GSS_Acquire_cred() call establishes a credentials structure, making the client's private key accessible for use on behalf of the client.
GSS_ACQUIRE_CRED（）コールは資格情報構造を確立し、クライアントに代わって使用できるクライアントのプライベートキーにアクセスできるようにします。
The client calls GSS_Init_sec_context(), which interrogates the Directory to acquire (and validate) a chain of public-key certificates, thereby collecting the public key of the service. The certificate validation operation determines that suitable integrity checks were applied by trusted authorities and that those certificates have not expired. GSS_Init_sec_context() generates a secret key for use in per-message protection operations on the context, and enciphers that secret key under the service's public key.
クライアントは、GSS_INIT_SEC_CONTEXT（）を呼び出します。これにより、ディレクトリが公開された証明書のチェーンを取得（および検証）する（および検証）するため、サービスの公開鍵を収集します。証明書の検証操作は、適切な整合性チェックが信頼できる当局によって適用され、それらの証明書が期限切れになっていないことを決定します。GSS_INIT_SEC_CONTEXT（）は、コンテキストでのメッセージごとの保護操作で使用する秘密キーを生成し、サービスの公開キーの下にその秘密キーを取り込みます。
The enciphered secret key, along with an authenticator quantity signed with the client's private key, is included in the output_token from GSS_Init_sec_context(). The output_token also carries a certification path, consisting of a certificate chain leading from the service to the client; a variant approach would defer this path resolution to be performed by the service instead of being asserted by the client. The client application sends the output_token to the service.
クライアントの秘密鍵で署名された認証装置の数量とともに、cipheredのシークレットキーは、gss_init_sec_context（）のoutput_tokenに含まれています。output_tokenには、サービスからクライアントへの証明書チェーンで構成される認定パスも搭載されています。バリアントアプローチは、クライアントによって主張されるのではなく、サービスによって実行されるこのパス解像度を延期します。クライアントアプリケーションは、output_tokenをサービスに送信します。
The service passes the received token as the input_token argument to GSS_Accept_sec_context(). GSS_Accept_sec_context() validates the certification path, and as a result determines a certified binding between the client's distinguished name and the client's public key. Given that public key, GSS_Accept_sec_context() can process the input_token's authenticator quantity and verify that the client's private key was used to sign the input_token. At this point, the client is authenticated to the service. The service uses its private key to decipher the enciphered secret key provided to it for per-message protection operations on the context.
サービスは、gss_accept_sec_context（）へのinput_token引数として受信したトークンを渡します。gss_accept_sec_context（）は、認証パスを検証し、その結果、クライアントの著名な名前とクライアントの公開キーとの間の認定バインディングを決定します。その公開鍵を考えると、gss_accept_sec_context（）は、input_tokenの認証装置の数量を処理し、クライアントの秘密鍵がinput_tokenに署名するために使用されたことを確認できます。この時点で、クライアントはサービスに認証されます。このサービスは、秘密鍵を使用して、コンテキストでのメッセージごとの保護操作のために提供された秘密の鍵を解読します。
The client calls GSS_GetMIC() or GSS_Wrap() on a data message, which causes per-message authentication, integrity, and (optional) confidentiality facilities to be applied to that message. The service uses the context's shared secret key to perform corresponding GSS_VerifyMIC() and GSS_Unwrap() calls.
クライアントは、データメッセージにgss_getmic（）またはgss_wrap（）を呼び出します。このサービスは、コンテキストの共有シークレットキーを使用して、対応するgss_verifymic（）およびgss_unwrap（）呼び出しを実行します。
6: Security Considerations
6：セキュリティ上の考慮事項
This document specifies a service interface for security facilities and services; as such, security considerations are considered throughout the specification. Nonetheless, it is appropriate to summarize certain specific points relevant to GSS-API implementors and calling applications. Usage of the GSS-API interface does not in itself provide security services or assurance; instead, these attributes are dependent on the underlying mechanism(s) which support a GSS-API implementation. Callers must be attentive to the requests made to GSS-API calls and to the status indicators returned by GSS-API, as these specify the security service characteristics which GSS-API will provide. When the interprocess context transfer facility is used, appropriate local controls should be applied to constrain access to interprocess tokens and to the sensitive data which they contain.
このドキュメントは、セキュリティ機能とサービスのサービスインターフェイスを指定します。そのため、セキュリティ上の考慮事項は、仕様全体で考慮されます。それにもかかわらず、GSS-APIの実装者と呼び出しアプリケーションに関連する特定の特定のポイントを要約することが適切です。GSS-APIインターフェイスの使用自体は、セキュリティサービスまたは保証を提供しません。代わりに、これらの属性は、GSS-APIの実装をサポートする基礎となるメカニズムに依存します。発信者は、GSS-APIによって返されるGSS-APIコールとGSS-APIによって返されるステータスインジケーターに行われたリクエストに注意を払う必要があります。インタープロセスコンテキスト転送施設を使用する場合、適切なローカルコントロールを適用して、インタープロセストークンとそれらに含まれる機密データへのアクセスを制約する必要があります。
7: Related Activities
7：関連する活動
In order to implement the GSS-API atop existing, emerging, and future security mechanisms:
既存、新興、および将来のセキュリティメカニズムの上にGSS-APIを実装するために：
object identifiers must be assigned to candidate GSS-API mechanisms and the name types which they support
オブジェクト識別子は、候補GSS-APIメカニズムとそれらがサポートする名前のタイプに割り当てる必要があります
concrete data element formats and processing procedures must be defined for candidate mechanisms
具体的なデータ要素の形式と処理手順は、候補メカニズムに対して定義する必要があります
Calling applications must implement formatting conventions which will enable them to distinguish GSS-API tokens from other data carried in their application protocols.
呼び出しアプリケーションは、アプリケーションプロトコルに掲載された他のデータとGSS-APIトークンを区別できるようにするためのフォーマット規則を実装する必要があります。
Concrete language bindings are required for the programming environments in which the GSS-API is to be employed, as [RFC-1509] defines for the C programming language and GSS-V1. C Language bindings for GSS-V2 are defined in [RFC-2744].
[RFC-1509]がCプログラミング言語とGSS-V1に定義するように、GSS-APIを採用するプログラミング環境には、具体的な言語のバインディングが必要です。GSS-V2のc言語バインディングは[RFC-2744]で定義されています。
8: Referenced Documents
8：参照されたドキュメント
[ISO-7498-2] International Standard ISO 7498-2-1988(E), Security Architecture.
[ISO-7498-2]国際標準ISO 7498-2-1988（e）、セキュリティアーキテクチャ。
[ISOIEC-8824] ISO/IEC 8824, "Specification of Abstract Syntax Notation One (ASN.1)".
[ISOIEC-8824] ISO/IEC 8824、「抽象的構文表記の仕様（ASN.1）」。
[ISOIEC-8825] ISO/IEC 8825, "Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1)".)
[ISOIEC-8825] ISO/IEC 8825、「抽象的構文表記1（asn.1）の基本エンコーディングルールの仕様」。
[RFC-1507]: Kaufman, C., "DASS: Distributed Authentication Security Service", RFC 1507, September 1993.
[RFC-1507]：Kaufman、C。、「Dass：分散認証セキュリティサービス」、RFC 1507、1993年9月。
[RFC-1508]: Linn, J., "Generic Security Service Application Program Interface", RFC 1508, September 1993.
[RFC-1508]：Linn、J。、「ジェネリックセキュリティサービスアプリケーションプログラムインターフェイス」、RFC 1508、1993年9月。
[RFC-1509]: Wray, J., "Generic Security Service API: C-bindings", RFC 1509, September 1993.
[RFC-1509]：Wray、J。、「ジェネリックセキュリティサービスAPI：C-Bindings」、RFC 1509、1993年9月。
[RFC-1964]: Linn, J., "The Kerberos Version 5 GSS-API Mechanism", RFC 1964, June 1996.
[RFC-1964]：Linn、J。、「Kerberosバージョン5 GSS-APIメカニズム」、RFC 1964、1996年6月。
[RFC-2025]: Adams, C., "The Simple Public-Key GSS-API Mechanism (SPKM)", RFC 2025, October 1996.
[RFC-2025]：Adams、C。、「シンプルなパブリックキーGSS-APIメカニズム（SPKM）」、RFC 2025、1996年10月。
[RFC-2078]: Linn, J., "Generic Security Service Application Program Interface, Version 2", RFC 2078, January 1997.
[RFC-2078]：Linn、J。、「ジェネリックセキュリティサービスアプリケーションプログラムインターフェイス、バージョン2」、RFC 2078、1997年1月。
[RFC-2203]: Eisler, M., Chiu, A. and L. Ling, "RPCSEC_GSS Protocol Specification", RFC 2203, September 1997.
[RFC-2203]：Eisler、M.、Chiu、A。、およびL. Ling、「RPCSEC_GSSプロトコル仕様」、RFC 2203、1997年9月。
[RFC-2744]: Wray, J., "Generic Security Service API Version 2 : C-bindings", RFC 2744, January 2000.
[RFC-2744]：Wray、J。、「ジェネリックセキュリティサービスAPIバージョン2：C-Bindings」、RFC 2744、2000年1月。
APPENDIX A
付録A
MECHANISM DESIGN CONSTRAINTS
メカニズムの設計制約
The following constraints on GSS-API mechanism designs are adopted in response to observed caller protocol requirements, and adherence thereto is anticipated in subsequent descriptions of GSS-API mechanisms to be documented in standards-track Internet specifications.
GSS-APIメカニズムの設計に関する以下の制約は、観察された発信者プロトコル要件に応じて採用されており、その後のGSS-APIメカニズムが標準トラックインターネット仕様で文書化されることがその後の説明で予想されます。
It is strongly recommended that mechanisms offering per-message protection services also offer at least one of the replay detection and sequencing services, as mechanisms offering neither of the latter will fail to satisfy recognized requirements of certain candidate caller protocols.
メサージごとの保護サービスを提供するメカニズムは、リプレイ検出およびシーケンスサービスの少なくとも1つを提供することを強くお勧めします。
APPENDIX B
付録B
COMPATIBILITY WITH GSS-V1
GSS-V1との互換性
It is the intent of this document to define an interface and procedures which preserve compatibility between GSS-V1 [RFC-1508] callers and GSS-V2 providers. All calls defined in GSS-V1 are preserved, and it has been a goal that GSS-V1 callers should be able to operate atop GSS-V2 provider implementations. Certain detailed changes, summarized in this section, have been made in order to resolve omissions identified in GSS-V1.
このドキュメントの意図は、GSS-V1 [RFC-1508]発信者とGSS-V2プロバイダー間の互換性を維持するインターフェイスと手順を定義することです。GSS-V1で定義されているすべての呼び出しは保存されており、GSS-V1発信者がGSS-V2プロバイダーの実装の上で動作できるはずであることを目標としています。このセクションにまとめられた特定の詳細な変更は、GSS-V1で特定された省略を解決するために行われました。
The following GSS-V1 constructs, while supported within GSS-V2, are deprecated:
GSS-V2内でサポートされていますが、次のGSS-V1コンストラクトは非推奨です。
Names for per-message processing routines: GSS_Seal() deprecated in favor of GSS_Wrap(); GSS_Sign() deprecated in favor of GSS_GetMIC(); GSS_Unseal() deprecated in favor of GSS_Unwrap(); GSS_Verify() deprecated in favor of GSS_VerifyMIC().
メッサージごとの処理ルーチンの名前：gss_wrap（）を支持して削除されました。gss_getmic（）;gss_unseal（）gss_unwrap（）;gss_verify（）は、gss_verifymic（）を支持して非推奨されています。
GSS_Delete_sec_context() facility for context_token usage, allowing mechanisms to signal context deletion, is retained for compatibility with GSS-V1. For current usage, it is recommended that both peers to a context invoke GSS_Delete_sec_context() independently, passing a null output_context_token buffer to indicate that no context_token is required. Implementations of GSS_Delete_sec_context() should delete relevant locally-stored context information.
GSS_DELETE_SEC_CONTEXT（）コンテキストの使用のための施設、メカニズムがコンテキストの削除を信号することを可能にし、GSS-V1との互換性のために保持されます。現在の使用については、両方のピアへのコンテキストへのピアがGSS_DELETE_SEC_CONTEXT（）を個別に呼び出し、null output_context_tokenバッファを渡して、コンテキスト_tokenが不要であることを示すことをお勧めします。gss_delete_sec_context（）の実装は、関連するローカルに保存されたコンテキスト情報を削除する必要があります。
This GSS-V2 specification adds the following calls which are not present in GSS-V1:
このGSS-V2仕様は、GSS-V1に存在しない次の呼び出しを追加します。
Credential management calls: GSS_Add_cred(), GSS_Inquire_cred_by_mech().
資格管理コール：gss_add_cred（）、gss_inquire_cred_by_mech（）。
Context-level calls: GSS_Inquire_context(), GSS_Wrap_size_limit(), GSS_Export_sec_context(), GSS_Import_sec_context().
コンテキストレベルの呼び出し：gss_inquire_context（）、gss_wrap_size_limit（）、gss_export_sec_context（）、gss_import_sec_context（）。
Per-message calls: No new calls. Existing calls have been renamed.
メッセージごとの呼び出し：新しい呼び出しはありません。既存の呼び出しは改名されました。
Support calls: GSS_Create_empty_OID_set(), GSS_Add_OID_set_member(), GSS_Test_OID_set_member(), GSS_Inquire_names_for_mech(), GSS_Inquire_mechs_for_name(), GSS_Canonicalize_name(), GSS_Export_name(), GSS_Duplicate_name().
サポートコール：gss_create_empty_oid_set（）、gss_add_oid_set_member（）、gss_test_oid_set_member（）、gss_inquire_names_for_mech（）、gss_inquire_mechs_for_name（）、gss_nonicize_name（）、gsadize_name（）、gsdupert_name（）、gss_namize_name（） ame（）。
This GSS-V2 specification introduces three new facilities applicable to security contexts, indicated using the following context state values which are not present in GSS-V1:
このGSS-V2仕様は、GSS-V1に存在しない以下のコンテキスト状態値を使用して、セキュリティコンテキストに適用される3つの新しい施設を導入します。
anon_state, set TRUE to indicate that a context's initiator is anonymous from the viewpoint of the target; Section 1.2.5 of this specification provides a summary description of the GSS-V2 anonymity support facility, support and use of which is optional.
anon_stateは、ターゲットの観点からコンテキストのイニシエーターが匿名であることを示すようにtrueを設定します。この仕様のセクション1.2.5では、GSS-V2匿名サポート機能の要約説明を提供します。サポートと使用はオプションです。
prot_ready_state, set TRUE to indicate that a context may be used for per-message protection before final completion of context establishment; Section 1.2.7 of this specification provides a summary description of the GSS-V2 facility enabling mechanisms to selectively permit per-message protection during context establishment, support and use of which is optional.
prot_ready_stateは、コンテキストが最終的に完了する前に、コンテキストがメッセージごとの保護に使用される可能性があることを示すようにtrueを設定します。この仕様のセクション1.2.7は、コンテキストの確立、サポート、および使用中にメッサージごとの保護を選択できるようにするメカニズムを可能にするGSS-V2施設の要約説明を提供します。
trans_state, set TRUE to indicate that a context is transferable to another process using the GSS-V2 GSS_Export_sec_context() facility.
trans_Stateは、GSS-V2 GSS_EXPORT_SEC_CONTEXT（）施設を使用して、コンテキストが別のプロセスに転送可能であることを示すようにtrueを設定します。
These state values are represented (at the C bindings level) in positions within a bit vector which are unused in GSS-V1, and may be safely ignored by GSS-V1 callers.
これらの状態値は、GSS-V1で使用されていないビットベクトル内の位置で（Cバインディングレベルで）表され、GSS-V1発信者によって安全に無視される場合があります。
New conf_req_flag and integ_req_flag inputs are defined for GSS_Init_sec_context(), primarily to provide information to negotiating mechanisms. This introduces a compatibility issue with GSS-V1 callers, discussed in section 2.2.1 of this specification.
新しいconf_req_flagおよびinteg_req_flag入力は、主に交渉メカニズムに情報を提供するために、gss_init_sec_context（）に対して定義されています。これにより、この仕様のセクション2.2.1で説明されているGSS-V1発信者との互換性の問題が導入されています。
Relative to GSS-V1, GSS-V2 provides additional guidance to GSS-API implementors in the following areas: implementation robustness, credential management, behavior in multi-mechanism configurations, naming support, and inclusion of optional sequencing services. The token tagging facility as defined in GSS-V2, Section 3.1, is now described directly in terms of octets to facilitate interoperable implementation without general ASN.1 processing code; the corresponding ASN.1 syntax, included for descriptive purposes, is unchanged from that in GSS-V1. For use in conjunction with added naming support facilities, a new Exported Name Object construct is added. Additional name types are introduced in Section 4.
GSS-V1と比較して、GSS-V2は、以下の分野でGSS-API実装者に追加のガイダンスを提供します。実装の堅牢性、資格管理、マルチメカニズム構成の動作、サポートの命名、およびオプションのシーケンスサービスの含有。GSS-V2、セクション3.1で定義されているトークンタグ付け施設は、一般的なASN.1処理コードなしで相互運用可能な実装を促進するために、オクテットの観点から直接説明されています。記述目的のために含まれる対応するASN.1構文は、GSS-V1のそれから変化しません。追加の命名サポートサポート施設と組み合わせて使用するために、新しいエクスポートされた名前オブジェクトコンストラクトが追加されます。セクション4に追加の名前のタイプが紹介されています。
This GSS-V2 specification adds the following major_status values which are not defined in GSS-V1:
このGSS-V2仕様は、GSS-V1で定義されていない次のMajor_Status値を追加します。
GSS_S_BAD_QOP unsupported QOP value
GSS_S_UNAUTHORIZED operation unauthorized
GSS_S_UNAVAILABLE operation unavailable
GSS_S_DUPLICATE_ELEMENT duplicate credential element
requested
GSS_S_NAME_NOT_MN name contains multi-mechanism
elements
GSS_S_GAP_TOKEN skipped predecessor token(s)
detected
Of these added status codes, only two values are defined to be returnable by calls existing in GSS-V1: GSS_S_BAD_QOP (returnable by GSS_GetMIC() and GSS_Wrap()), and GSS_S_GAP_TOKEN (returnable by GSS_VerifyMIC() and GSS_Unwrap()).
これらの追加されたステータスコードのうち、GSS-V1：GSS_S_BAD_QOP（GSS_GETMIC（）およびGSS_WRAP（）によって返されるコールによって返されると定義される2つの値のみが定義されています。
Additionally, GSS-V2 descriptions of certain calls present in GSS-V1 have been updated to allow return of additional major_status values from the set as defined in GSS-V1: GSS_Inquire_cred() has GSS_S_DEFECTIVE_CREDENTIAL and GSS_S_CREDENTIALS_EXPIRED defined as returnable, GSS_Init_sec_context() has GSS_S_OLD_TOKEN, GSS_S_DUPLICATE_TOKEN, and GSS_S_BAD_MECH defined as returnable, and GSS_Accept_sec_context() has GSS_S_BAD_MECH defined as returnable.
Additionally, GSS-V2 descriptions of certain calls present in GSS-V1 have been updated to allow return of additional major_status values from the set as defined in GSS-V1: GSS_Inquire_cred() has GSS_S_DEFECTIVE_CREDENTIAL and GSS_S_CREDENTIALS_EXPIRED defined as returnable, GSS_Init_sec_context() has GSS_S_OLD_TOKEN、gss_s_duplicate_token、およびgss_s_bad_mechは返されると定義されており、gss_accept_sec_context（）はgss_s_bad_mechが返されると定義されています。
APPENDIX C
付録c
CHANGES RELATIVE TO RFC-2078
RFC-2078に関連する変更
This document incorporates a number of changes relative to RFC-2078, made primarily in response to implementation experience, for purposes of alignment with the GSS-V2 C language bindings document, and to add informative clarification. This section summarizes technical changes incorporated.
このドキュメントには、GSS-V2 C Language Bindingsドキュメントとの調整を目的として、実装の経験に応じて主に作成されたRFC-2078に対する多くの変更が組み込まれています。このセクションでは、組み込まれた技術的な変更をまとめます。
General:
一般的な：
Clarified usage of object release routines, and incorporated statement that some may be omitted within certain operating environments.
オブジェクトリリースルーチンの使用法を明確にし、特定の動作環境内で省略される可能性があるという声明を設立しました。
Removed GSS_Release_OID, GSS_OID_to_str(), and GSS_Str_to_OID() routines.
gss_release_oid、gss_oid_to_str（）、およびgss_str_to_oio（）ルーチンを削除しました。
Clarified circumstances under which zero-length tokens may validly exist as inputs and outputs to/from GSS-API calls.
ゼロ長トークンがGSS-API呼び出しの入力および出力として有効に存在する可能性がある明確な状況。
Added GSS_S_BAD_MIC status code as alias for GSS_S_BAD_SIG.
GSS_S_S_BAD_SIGのエイリアスとしてGSS_S_BAD_MICステータスコードを追加しました。
For GSS_Display_status(), deferred to language bindings the choice of whether to return multiple status values in parallel or via iteration, and added commentary deprecating return of GSS_S_CONTINUE_NEEDED.
GSS_DISPLAY_STATUS（）の場合、言語バインディングに延期され、複数のステータス値を並列または反復で返すかどうかを選択し、GSS_S_CONTINUE_NEEDEDのリターンを非難する解説を追加しました。
Adapted and incorporated clarifying material on optional service support, delegation, and interprocess context transfer from C bindings document.
C Bindingsドキュメントからのオプションのサービスサポート、委任、およびプロセスインタープロセスのコンテキスト転送に適応および組み込まれた資料。
Added and updated references to related documents, and to current status of cited Kerberos mechanism OID.
関連文書への参照を追加および更新し、引用されたKerberosメカニズムOIDの現在のステータス。
Added general statement about GSS-API calls having no side effects visible at the GSS-API level.
GSS-APIレベルで副作用が見えないGSS-APIコールに関する一般的な声明が追加されました。
Context-related (including per-message protection issues):
コンテキスト関連（男性ごとの保護の問題を含む）：
Clarified GSS_Delete_sec_context() usage for partially-established contexts.
部分的に確立されたコンテキストのgss_delete_sec_context（）の使用。
Added clarification on GSS_Export_sec_context() and GSS_Import_sec_context() behavior and context usage following an export-import sequence.
gss_export_sec_context（）およびgss_import_sec_context（）のclarificationを追加しました。
Added informatory conf_req_flag, integ_req_flag inputs to GSS_Init_sec_context(). (Note: this facility introduces a backward incompatibility with GSS-V1 callers, discussed in Section 2.2.1; this implication was recognized and accepted in working group discussion.)
gss_init_sec_context（）にinformatory conf_req_flag、integ_req_flag入力を追加しました。（注：この施設は、セクション2.2.1で説明したGSS-V1発信者との後方互換性を導入します。この意味は、ワーキンググループディスカッションで認識され、受け入れられました。）
Stated that GSS_S_FAILURE is to be returned if GSS_Init_sec_context() or GSS_Accept_sec_context() is passed the handle of a context which is already fully established.
gss_init_sec_context（）またはgss_accept_sec_context（）が既に完全に確立されているコンテキストのハンドルに渡された場合、GSS_S_FAILUREは返されると述べました。
Re GSS_Inquire_sec_context(), stated that src_name and targ_name are not returned until GSS_S_COMPLETE status is reached; removed use of GSS_S_CONTEXT_EXPIRED status code (replacing with EXPIRED lifetime return value); stated requirement to retain inquirable data until context released by caller; added result value indicating whether or not context is fully open.
re gss_inquire_sec_context（）は、src_nameおよびtarg_nameがgss_s_completeステータスに到達するまで返されないと述べました。GSS_S_S_CONTEXT_EXPIREDステータスコードの使用を削除しました（期限切れの寿命の返品値に置き換えます）。発信者によってリリースされたコンテキストまで、問い合わせデータを保持するための定められた要件。コンテキストが完全に開いているかどうかを示す追加の結果値。
Added discussion of interoperability conditions for mechanisms permitting optional support of QOPs. Removed reference to structured QOP elements in GSS_Verify_MIC().
QOPのオプションのサポートを可能にするメカニズムの相互運用性条件の議論が追加されました。gss_verify_mic（）の構造化されたqop要素への参照を削除しました。
Added discussion of use of GSS_S_DUPLICATE_TOKEN status to indicate reflected per-message tokens.
GSS_S_DUPLICATION_TOKENステータスの使用に関する議論を追加して、反射したメッセージごとのトークンを示します。
Clarified use of informational sequencing codes from per-message protection calls in conjunction with GSS_S_COMPLETE and GSS_S_FAILURE major_status returns, adjusting status code descriptions accordingly.
gss_s_completeおよびgss_s_failure major_status Returnsと併せて、メッセージごとの保護コールからの情報シーケンスコードの使用を明確に使用し、それに応じてステータスコードの説明を調整します。
Added specific statements about impact of GSS_GetMIC() and GSS_Wrap() failures on context state information, and generalized existing statements about impact of processing failures on received per-message tokens.
コンテキスト状態情報に対するGSS_GETMIC（）およびGSS_WRAP（）障害の影響に関する特定のステートメントを追加し、受信した1つのメッサージトークンに対する処理障害の影響に関する既存のステートメントを一般化しました。
For GSS_Init_sec_context() and GSS_Accept_sec_context(), permitted returned mech_type to be valid before GSS_S_COMPLETE, recognizing that the value may change on successive continuation calls in the negotiated mechanism case.
gss_init_sec_context（）およびgss_accept_sec_context（）の場合、gss_s_completeの前にmech_typeが有効であることを許可され、交渉メカニズムの場合に連続した継続コールで値が変化する可能性があることを認識しました。
Deleted GSS_S_CONTEXT_EXPIRED status from GSS_Import_sec_context().
gss_import_sec_context（）から削除されたgss_s_context_expiredステータス。
Added conf_req_flag input to GSS_Wrap_size_limit().
conf_req_flag入力をgss_wrap_size_limit（）に追加しました。
Stated requirement for mechanisms' support of per-message protection services to be usable concurrently in both directions on a context.
コンテキストの両方の方向で同時に使用できるように、メカニズムのメカニズムのサポートがコンテキストで同時に使用できるようにする要件。
Credential-related:
資格関連：
For GSS_Acquire_cred() and GSS_Add_cred(), aligned with C bindings statement of likely non-support for INITIATE or BOTH credentials if input name is neither empty nor a name resulting from applying GSS_Inquire_cred() against the default credential. Further, stated that an explicit name returned by GSS_Inquire_context() should also be accepted. Added commentary about potentially time-variant results of default resolution and attendant implications. Aligned with C bindings re behavior when GSS_C_NO_NAME provided for desired_name. In GSS_Acquire_cred(), stated that NULL, rather than empty OID set, should be used for desired_mechs in order to request default mechanism set.
GSS_ACQUIRE_CRED（）およびGSS_ADD_CRED（）の場合、入力名が空でもない場合も、gss_inquire_cred（）をデフォルトの資格情報に対して適用することに起因する名前がない場合は、開始または両方の資格情報のc bindingsステートメントと整列しています。さらに、gss_inquire_context（）によって返された明示的な名前も受け入れられるべきであると述べました。デフォルトの解決と付随する意味の潜在的に時間的に変動した結果についてのコメントを追加しました。GSS_C_NO_NAMEが希望_nameに提供された場合、c bindings reの動作と整列しています。GSS_ACQUIRE_CRED（）では、デフォルトのメカニズムセットを要求するために、空のoidセットではなくnullを希望することに使用する必要があると述べました。
Added GSS_S_CREDENTIALS_EXPIRED as returnable major_status for GSS_Acquire_cred(), GSS_Add_cred(), also specifying GSS_S_NO_CRED as appropriate return for temporary, user-fixable credential unavailability. GSS_Acquire_cred() and GSS_Add_cred() are also to return GSS_S_NO_CRED if an authorization failure is encountered upon credential acquisition.
gss_cquire_cred（）、gss_add_cred（）のreturnable major_statusとしてGSS_S_CREDENTIALS_EXPIREDを追加し、GSS_S_NO_CREDを適切なリターンとして指定して、一時的なユーザーフィックス可能な資格情報の不利用性を指定します。GSS_ACQUIRE_CRED（）およびGSS_ADD_CRED（）は、資格取得時に承認の失敗が発生した場合にもGSS_S_NO_CREDを返します。
Removed GSS_S_CREDENTIALS_EXPIRED status return from per-message protection, GSS_Context_time(), and GSS_Inquire_context() calls.
削除gss_s_s_credentials_expiredステータス保護、gss_context_time（）、およびgss_inquire_context（）呼び出しからのリターン。
For GSS_Add_cred(), aligned with C bindings' description of behavior when addition of elements to the default credential is requested.
GSS_ADD_CRED（）の場合、デフォルトの資格情報に要素を追加すると、C BINDINGSの動作の説明が要求されます。
Upgraded recommended default credential resolution algorithm to status of requirement for initiator credentials.
アップグレードされた推奨デフォルトの資格情報解像度アルゴリズムは、イニシエーター資格情報の要件のステータスになりました。
For GSS_Release_cred(), GSS_Inquire_cred(), and GSS_Inquire_cred_by_mech(), clarified behavior for input GSS_C_NO_CREDENTIAL.
GSS_RELEASE_CRED（）、GSS_ACQUIRE_CRED（）、およびGSS_INQUIRE_CRED_BY_MECH（）の場合、入力GSS_C_NO_CREDENTIALの明確な動作。
Name-related:
名前関連：
Aligned GSS_Inquire_mechs_for_name() description with C bindings.
Aligned GSS_INQUIRE_MECHS_FOR_NAME（）説明Cバインディングを使用。
Removed GSS_S_BAD_NAMETYPE status return from GSS_Duplicate_name(), GSS_Display_name(); constrained its applicability for GSS_Compare_name().
gss_s_bad_nameTypeステータスgss_duplicate_name（）、gss_display_name（）;gss_compare_name（）の適用性を制約しました。
Aligned with C bindings statement re GSS_Import_name() behavior with GSS_C_NO_OID input name type, and stated that GSS-V2 mechanism specifications are to define processing procedures applicable to their mechanisms. Also clarified GSS_C_NO_OID usage with GSS_Display_name().
c bindings statement re gss_import_name（）の動作とgss_c_no_oid入力名タイプと整列し、GSS-V2メカニズムの仕様はメカニズムに適用される処理手順を定義することであると述べました。また、gss_display_name（）を使用してGSS_C_NO_OIDの使用を承認しました。
Downgraded reference to name canonicalization via DNS lookup to an example.
DNSルックアップを介した名前の標準化への格下げの参照を例に挙げました。
For GSS_Canonicalize_name(), stated that neither negotiated mechanisms nor the default mechanism are supported input mech_types for this operation, and specified GSS_S_BAD_MECH status to be returned in this case. Clarified that the GSS_Canonicalize_name() operation is non-destructive to its input name.
GSS_CANONICALIZE_NAME（）の場合、ネゴシエートされたメカニズムもデフォルトのメカニズムも、この操作の入力MECH_TYPESをサポートされていないと述べ、この場合にはGSS_S_BAD_MECHステータスが返されるように指定されています。gss_canonicalize_name（）操作が入力名に対して非破壊的であることを明確にしました。
Clarified semantics of GSS_C_NT_USER_NAME name type.
GSS_C_NT_USER_NAME名タイプの明確なセマンティクス。
Added descriptions of additional name types. Also added discussion of GSS_C_NO_NAME and its constrained usage with specific GSS calls.
追加の名前タイプの説明が追加されました。また、GSS_C_NO_NAMEと特定のGSSコールでその制約付き使用法の議論も追加されました。
Adapted and incorporated C bindings discussion about name comparisons with exported name objects.
エクスポートされた名前オブジェクトとの名前の比較に関するCバインディングの適応と組み込まれた議論。
Added recommendation to mechanism designers for support of host-based service name type, deferring any requirement statement to individual mechanism specifications. Added discussion of host-based service's service name element and proposed approach for IANA registration policy therefor.
ホストベースのサービス名タイプをサポートするためのメカニズム設計者に推奨を追加し、個々のメカニズム仕様に要件ステートメントを延期しました。ホストベースのサービスのサービス名要素の議論と、IANA登録ポリシーの提案されたアプローチの追加。
Clarified byte ordering within exported name object. Stated that GSS_S_BAD_MECH is to be returned if, in the course of attempted import of an exported name object, the name object's enclosed mechanism type is unrecognized or unsupported.
エクスポートされた名前オブジェクト内の明確なバイト順序。gss_s_bad_mechは、エクスポートされた名前オブジェクトのインポートの試行中に、名前オブジェクトの囲まれたメカニズムタイプが認識されていないか、サポートされていない場合に返されると述べました。
Stated that mechanisms may optionally accept GSS_C_NO_NAME as an input target name to GSS_Init_sec_context(), with comment that such support is unlikely within mechanisms predating GSS-V2, Update 1.
メカニズムは、GSS_INIT_SEC_CONTEXT（）の入力ターゲット名としてGSS_C_NO_NAMEをオプションで受け入れる可能性があると述べました。これは、GSS-V2、Update 1よりもそのようなサポートがありそうもないというコメントがあります。
AUTHOR'S ADDRESS
著者の連絡先
John Linn RSA Laboratories 20 Crosby Drive Bedford, MA 01730 USA
John Linn RSA Laboratories 20 Crosby Drive Bedford、MA 01730 USA
Phone: +1 781.687.7817
EMail: jlinn@rsasecurity.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（2000）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の限られた許可は永続的であり、インターネット社会またはその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。