RFC1508 日本語訳
1508 Generic Security Service Application Program Interface. J. Linn. September 1993. (Format: TXT=111228 bytes) (Obsoleted by RFC2078) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group J. Linn
Request for Comments: 1508 Geer Zolot Associates
September 1993
コメントを求めるワーキンググループJ.リンの要求をネットワークでつないでください: 1508イェールZolotは1993年9月に交際します。
Generic Security Service Application Program Interface
ジェネリックセキュリティー・サービス適用業務プログラム・インタフェース
Status of this Memo
このMemoの状態
This RFC 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" for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このRFCはインターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This Generic Security Service Application Program Interface (GSS-API) definition 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:
このGeneric Security Service Application Program Interface(GSS-API)定義は訪問者へのセキュリティー・サービスをジェネリックファッションに提供します、メカニズムと技術の基礎となって、したがって、アプリケーションのソース平らな移植性を異なった環境に許容する範囲で、我慢できます。 この仕様は、発症機序とプログラミング言語環境の如何にかかわらずレベルで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サービスがわかるために実装されるトークン書式、プロトコル、および手順を定義するドキュメント
Table of Contents
目次
1. GSS-API Characteristics and Concepts ....................... 2 1.1. GSS-API Constructs ....................................... 5 1.1.1. Credentials ........................................... 5 1.1.2. Tokens ................................................ 6 1.1.3. Security Contexts ..................................... 7 1.1.4. Mechanism Types ....................................... 8 1.1.5. Naming ................................................ 9 1.1.6. Channel Bindings ...................................... 10 1.2. GSS-API Features and Issues ............................. 11 1.2.1. Status Reporting ...................................... 11 1.2.2. Per-Message Security Service Availability ............. 12 1.2.3. Per-Message Replay Detection and Sequencing ........... 13 1.2.4. Quality of Protection ................................. 15
1. GSS-APIの特性と概念… 2 1.1. GSS-API構造物… 5 1.1.1. 資格証明書… 5 1.1.2. トークン… 6 1.1.3. セキュリティ文脈… 7 1.1.4. メカニズムはタイプされます… 8 1.1.5. 命名します。 9 1.1.6. チャンネル結合… 10 1.2. GSS-APIの特徴と問題… 11 1.2.1. 状態報告… 11 1.2.2. 1メッセージあたりのセキュリティー・サービスの有用性… 12 1.2.3. メッセージに従って、検出と配列を再演してください… 13 1.2.4. 保護の品質… 15
Linn [Page 1] RFC 1508 Generic Security Interface September 1993
リン[1ページ]RFC1508ジェネリックセキュリティは1993年9月に連結します。
2. Interface Descriptions ..................................... 15 2.1. Credential management calls ............................. 17 2.1.1. GSS_Acquire_cred call ................................. 17 2.1.2. GSS_Release_cred call ................................. 19 2.1.3. GSS_Inquire_cred call ................................. 20 2.2. Context-level calls ..................................... 21 2.2.1. GSS_Init_sec_context call ............................. 21 2.2.2. GSS_Accept_sec_context call ........................... 26 2.2.3. GSS_Delete_sec_context call ........................... 29 2.2.4. GSS_Process_context_token call ........................ 30 2.2.5. GSS_Context_time call ................................. 31 2.3. Per-message calls ....................................... 32 2.3.1. GSS_Sign call ......................................... 32 2.3.2. GSS_Verify call ....................................... 33 2.3.3. GSS_Seal call ......................................... 35 2.3.4. GSS_Unseal call ....................................... 36 2.4. Support calls ........................................... 37 2.4.1. GSS_Display_status call ............................... 37 2.4.2. GSS_Indicate_mechs call ............................... 38 2.4.3. GSS_Compare_name call ................................. 38 2.4.4. GSS_Display_name call ................................. 39 2.4.5. GSS_Import_name call .................................. 40 2.4.6. GSS_Release_name call ................................. 41 2.4.7. GSS_Release_buffer call ............................... 41 2.4.8. GSS_Release_oid_set call .............................. 42 3. Mechanism-Specific Example Scenarios ....................... 42 3.1. Kerberos V5, single-TGT ................................. 43 3.2. Kerberos V5, double-TGT ................................. 43 3.3. X.509 Authentication Framework .......................... 44 4. Related Activities ......................................... 45 5. Acknowledgments ............................................ 46 6. Security Considerations .................................... 46 7. Author's Address ........................................... 46 Appendix A .................................................... 47 Appendix B .................................................... 48 Appendix C .................................................... 49
2. 記述を連結してください… 15 2.1. 資格証明管理は電話をします… 17 2.1.1. GSS_Acquire_信用呼び出し… 17 2.1.2. GSS_Release_信用呼び出し… 19 2.1.3. GSS_Inquire_信用呼び出し… 20 2.2. 文脈レベルは呼びます… 21 2.2.1. GSS_Init_秒_文脈呼び出し… 21 2.2.2. GSS_Accept_秒_文脈呼び出し… 26 2.2.3. GSS_Delete_秒_文脈呼び出し… 29 2.2.4. GSS_Process_文脈_トークン呼び出し… 30 2.2.5. GSS_Context_時間呼び出し… 31 2.3. メッセージは呼びます… 32 2.3.1. GSS_Signは呼びます… 32 2.3.2. GSS_Verifyは呼びます… 33 2.3.3. GSS_Sealは呼びます… 35 2.3.4. GSS_Unsealは呼びます… 36 2.4. サポートは呼びます… 37 2.4.1. GSS_Display_状態呼び出し… 37 2.4.2. GSS_Indicate_mechsは呼びます… 38 2.4.3. GSS_Compare_名前呼び出し… 38 2.4.4. GSS_Display_名前呼び出し… 39 2.4.5. GSS_Import_名前呼び出し… 40 2.4.6. GSS_Release_名前呼び出し… 41 2.4.7. GSS_Release_バッファ呼び出し… 41 2.4.8. GSS_Release_oid_は呼び出しを設定しました… 42 3. メカニズム特有の例のシナリオ… 42 3.1. ケルベロスV5、独身のTGT… 43 3.2. ケルベロスV5、二重TGT… 43 3.3. X.509認証フレームワーク… 44 4. 活動を関係づけます… 45 5. 承認… 46 6. セキュリティ問題… 46 7. 作者のアドレス… 46 付録A… 47 付録B… 48 付録C… 49
1. GSS-API Characteristics and Concepts
1. GSS-APIの特性と概念
The operational paradigm in which GSS-API operates is as follows. 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
GSS-APIが作動する操作上のパラダイムは以下の通りです。 典型的なGSS-API訪問者はそれ自体でコミュニケーションプロトコルです、認証、保全、そして/または、秘密性セキュリティー・サービスとのコミュニケーションを保護するためにGSS-APIを訪問して。 GSS-API訪問者は、地方のGSS-API実行でそれに提供されたトークンを受け入れて、リモートシステムの上でトークンを同輩に移します。 その同輩は処理のための地方のGSS-API実行に容認されたトークンを通過します。 GSS-APIを通して利用可能なセキュリティー・サービスがこんなやり方で実装可能である、(ありました。
Linn [Page 2] RFC 1508 Generic Security Interface September 1993
リン[2ページ]RFC1508ジェネリックセキュリティは1993年9月に連結します。
implemented) over a range of underlying mechanisms based on secret- key and public-key cryptographic technologies.
実装する、)、秘密のキーと公開鍵暗号化技術に基づくさまざまな発症機序の上で。
The GSS-API separates the operations of initializing a security context between peers, achieving peer entity authentication (This security service definition, and other definitions used in this document, corresponds to that provided in International Standard ISO 7498-2-1988(E), Security Architecture.) (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_Sign() and GSS_Verify() calls) for messages subsequently transferred in conjunction with that context. Per-message GSS_Seal() and GSS_Unseal() calls provide the data origin authentication and data integrity services which GSS_Sign() and GSS_Verify() 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はセキュリティ文脈を初期化する操作を同輩の間に切り離します、同輩実体認証を達成して(このセキュリティー・サービス定義、および本書では使用される他の定義は国際規格ISO7498-2-1988(E)(Security Architecture)に提供されたそれに対応しています) (GSS_Init_秒_文脈()とGSS_Accept_秒_文脈()呼び出し), 提供の操作から、メッセージのための1メッセージあたりのデータ発生源認証とデータ保全保護(GSS_Sign()とGSS_Verify()呼び出し)は次に、その文脈に関連して移されました。 1メッセージあたりのGSS_Seal()とGSS_Unseal()呼び出しは、訪問者オプションとしてGSS_Sign()とGSS_Verify()が提供するデータ発生源認証とデータ保全サービスを提供して、また、秘密性サービスのサポート品揃えを提供します。 追加呼び出しは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 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 presently- documented CAT mechanisms but is not necessarily true for other cryptographic technologies and associated protocols.
以下のパラグラフはメカニズムから独立しているファッションでクライアントとサーバでGSS-APIの使用にかかわるデータフローを例証する例を提供します、セキュリティ文脈を確立して、保護されたメッセージを移して。 例は、資格証明買収が既に完了したと仮定します。 例は、ただ一つのトークンの中で運ばれた要素を使用することでサーバにクライアントを認証して、基本的な認証技術がただ一つの返されたトークンをもっているクライアント(互いの認証)にサーバを認証できると仮定します。 この仮定は、現在記録されたCATメカニズムに当てはまりますが、他の暗号化技術と関連プロトコルには、必ず本当であるというわけではありません。
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_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_COMPLETE status. The client sends the output_token to the server.
クライアントが、GSS_Init_をtarg_名前によって特定されたサーバにセキュリティ文脈を確立する秒_文脈()と呼んで、互いの_req_旗を設定するのを選ぶので、互いの認証は文脈設立の間に実行されます。 GSS_Init_秒_文脈()は、サーバに通過されるために出力_トークンを返して、GSS_CONTINUE_が互いの認証系列の完成まで状態を必要としたのを示します。 互いの_req_旗が設定されなかったなら、GSS_Init_秒_文脈()への初期の呼び出しはGSS_COMPLETEに状態を返したでしょうに。 クライアントは出力_トークンをサーバに送ります。
The server passes the received token as the input_token parameter to GSS_Accept_sec_context(). GSS_Accept_sec_context indicates GSS_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.
サーバは入力_トークンパラメタとしてGSS_Accept_秒_文脈()に容認されたトークンを通過します。 GSS_Accept_秒_文脈は、GSS_COMPLETE状態を示して、結果というsrc_名前にクライアントの認証されたアイデンティティを提供して、クライアントに渡されるために出力_トークンを提供します。 サーバは出力_トークンをクライアントに送ります。
The client passes the received token as the input_token parameter to a successor call to GSS_Init_sec_context(), which processes data
クライアントは入力_トークンパラメタとしてGSS_Init_秒_文脈()への後継者呼び出しに容認されたトークンを通過します。(文脈はデータを処理します)。
Linn [Page 3] RFC 1508 Generic Security Interface September 1993
リン[3ページ]RFC1508ジェネリックセキュリティは1993年9月に連結します。
included in the token in order to achieve mutual authentication from the client's viewpoint. This call to GSS_Init_sec_context() returns GSS_COMPLETE status, indicating successful mutual authentication and the completion of context establishment for this example.
トークンでは、クライアントの観点から互いの認証を達成するために、含まれています。 この例のための文脈設立のうまくいっている互いの認証と完成を示して、GSS_Init_秒_文脈()へのこの呼び出しはGSS_COMPLETEに状態を返します。
The client generates a data message and passes it to GSS_Seal(). GSS_Seal() performs data origin authentication, data integrity, and (optionally) confidentiality processing on the message and encapsulates the result into output_message, indicating GSS_COMPLETE status. The client sends the output_message to the server.
クライアントは、データメッセージを生成して、GSS_Seal()にそれを通過します。 GSS_Seal()はデータ発生源認証、データ保全、および(任意に)秘密性処理をメッセージに実行して、出力_メッセージに結果をカプセル化します、GSS_COMPLETE状態を示して。 クライアントは出力_メッセージをサーバに送ります。
The server passes the received message to GSS_Unseal(). GSS_Unseal inverts the encapsulation performed by GSS_Seal(), deciphers the message if the optional confidentiality feature was applied, and validates the data origin authentication and data integrity checking quantities. GSS_Unseal() indicates successful validation by returning GSS_COMPLETE status along with the resultant output_message.
サーバはGSS_Unseal()に受信されたメッセージを通過します。 GSS_UnsealはGSS_Seal()によって実行されたカプセル化を逆にして、任意の秘密性の特徴が適用されたならメッセージを解読して、量をチェックするデータ発生源認証とデータ保全を有効にします。 GSS_Unseal()は結果の出力_メッセージに伴う戻っているGSS_COMPLETE状態のそばでうまくいっている合法化を示します。
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. GSS_Delete_sec_context() returns a context_token for the server to pass to the client.
この例の目的のために、私たちは、クライアントからサーバまで1つの保護されたメッセージを移した後にサーバがバンドの外によるいいえがこの文脈でさらに使用する手段を知っていると思います。この前提を考えて、サーバは、現在、GSS_Delete_を豊富な文脈レベル情報に秒_文脈()と呼びます。 GSS_Delete_秒_文脈()はサーバがクライアントに渡す文脈_トークンを返します。
The client passes the returned context_token to GSS_Process_context_token(), which returns GSS_COMPLETE status after deleting context-level information at the client system.
クライアントはGSS_Process_文脈_トークン()に返された文脈_トークンを通過します。(クライアントシステムで文脈レベル情報を削除した後に、それは、GSS_COMPLETEに状態を返します)。
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 can be implemented by secret-key technologies (e.g.,
Kerberos) or public-key approaches (e.g., X.509).
メカニズム独立: GSS-APIは特定の発症機序から独立しているジェネリックレベルで暗号で実装している強い認証と他のセキュリティー・サービスとインタフェースを定義します。例えば、秘密鍵技術(例えば、ケルベロス)か公開鍵アプローチ(例えば、X.509)でGSS APIが提供されたサービスは実装することができます。
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 (e.g.,
Remote Procedure Call (RPC)) may be interposed between
applications which call that protocol and the GSS-API, thereby
invoking GSS-API facilities in conjunction with that protocol's
環境独立について議定書の中で述べてください: GSS-APIはそれが採用しているコミュニケーションプロトコル群から独立しています、広範囲なプロトコル環境における使用を可能にして。 適切な環境で、特定の通信プロトコル(例えば、Remote Procedure Call(RPC))に適応する中間的実装「ベニヤ」はそのプロトコルを呼ぶアプリケーションとGSS-APIの間で挿入されるかもしれません、その結果、そのプロトコルに関連してGSS-API施設を呼び出します。
Linn [Page 4] RFC 1508 Generic Security Interface September 1993
リン[4ページ]RFC1508ジェネリックセキュリティは1993年9月に連結します。
communications invocations.
コミュニケーション実施。
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が実装される定義されたどんなTrusted Computing基地(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. 資格証明書
Credentials structures provide the prerequisites enabling peers to
establish security contexts with each other. A caller may designate
that its default credential be used for context establishment calls
without presenting an explicit handle to that credential.
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").
資格証明書構造は同輩が互いと共にセキュリティ文脈を確立するのを可能にする前提条件を提供します。 訪問者は指定するかもしれません。明白なハンドルをその資格証明書に贈らないで、デフォルト資格証明書が文脈設立に使用されるのは呼びます。 交互に、特定の資格証明書構造の明白な品揃えをする必要があるそれらのGSS-API訪問者はGSS APIが提供された資格証明ハンドル(「_が扱う信用」)を通して資格証明書をそれらを参照するかもしれません。
A single credential structure may be used for initiation of outbound contexts and acceptance of 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 single credential structure may accommodate credential information associated with multiple underlying mechanisms (mech_types); a credential structure's contents will vary depending on the set of mech_types supported by a particular GSS-API implementation. Commonly, a single mech_type will be used for all security contexts established by a particular initiator to a particular target; the primary motivation for supporting credential sets representing multiple mech_types is to allow initiators on systems which are
ただ一つの資格証明構造は複数の発症機序に関連している資格証明情報に対応するかもしれません(mech_はタイプされます)。 特定のGSS-API実行でサポートされたmech_タイプのセットによって、資格証明構造のコンテンツは異なるでしょう。 一般的に、単独のmech_タイプは特定の創始者によって特定の目標に確立されたすべてのセキュリティ文脈に使用されるでしょう。 複数のmech_タイプの代理をする資格証明セットを支えることに関するプライマリ動機はそうするシステムの上に創始者を許容することです。
Linn [Page 5] RFC 1508 Generic Security Interface September 1993
リン[5ページ]RFC1508ジェネリックセキュリティは1993年9月に連結します。
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.
創始者のシステムで支えられたセットの部分集合しか対応できない他のシステムで目標に文脈を開始するために複数のタイプを扱うために、備えられています。
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機能の責任です。 この責任は作成者によって真剣に受け止められるべきです、実体が主体の資格証明書を利用する能力が首尾よくその主体のアイデンティティについて断言する実体の能力に同等であるので。
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.
1セットの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_信用()は呼びます。
as the default credentials installed on behalf of a process
プロセスを代表してインストールされたデフォルト資格証明書として
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 are exchanged in conjunction with an established context to provide protective security services for corresponding data messages. The internal contents of both classes of tokens are specific to the particular underlying mechanism used to support the GSS-API; Appendix B of this document provides a uniform recommendation for designers of GSS-API support mechanisms, encapsulating mechanism-specific information along with a globally-interpretable mechanism identifier.
トークンは、GSS-API訪問者の間に移されたデータ要素であり、2つのクラスに分割されます。 同輩の間のセキュリティ文脈を確立して、管理するために文脈レベルトークンを交換します。 対応するデータメッセージのための保護的なセキュリティー・サービスを提供するために確立した関係に関連して1メッセージあたりのトークンを交換します。 両方のクラスのトークンの内部の内容はGSS-APIをサポートするのに使用される特定の発症機序に特定です。 このドキュメントの付録BはGSS-APIサポートメカニズムのデザイナーのための一定の推薦を提供します、グローバルに解明できるメカニズム識別子に伴うメカニズム特殊情報をカプセル化して。
Linn [Page 6] RFC 1508 Generic Security Interface September 1993
リン[6ページ]RFC1508ジェネリックセキュリティは1993年9月に連結します。
Tokens 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. Tokens may be output by GSS-API primitives (and are to be transferred to GSS-API peers) independent of the status indications which those primitives indicate. 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-API訪問者に移されて、GSS-API実行でそのリモートエンドシステムに処理されるためにGSS-API訪問者に提供されたシステム。 GSS-API基関数(GSS-API同輩に移されることになっている)によってトークンはそれらの基関数が示す状態指摘の如何にかかわらず出力されるかもしれません。 トークン転送は論理的に別々のチャンネルの向こう側にバンドにおける他のデータ転送にGSS-API訪問者によって使用された同じプロトコルストリームと統合された方法かバンドで出ている方法で起こるかもしれません。
Development of GSS-API support primitives based on a particular underlying cryptographic technique and protocol does not necessarily imply that GSS-API callers invoking that GSS-API mechanism type will be able to interoperate with peers invoking the same technique and protocol outside the GSS-API paradigm. For example, 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 the same as those used by non-GSS-API callers of the same underlying technique.
特定の基本的な暗号のテクニックとプロトコルに基づく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.
セキュリティ文脈は同輩の間で確立されます、局所的に各同輩に関連して確立されたか、または委譲で同輩によって受け取られた資格証明書を使用して。 同じであるか異なったセットの資格証明書を使用して、複数の文脈が同時に、1組の同輩の間に存在するかもしれません。 資格証明書が期限が切れるとき、異なった資格証明書を使用する複数の文脈の共存は優雅なロールオーバーを許容します。 セキュリティ意味における異なったメッセージストリームを区別することによって、同じ資格証明書に基づく複数の文脈の中の区別はアプリケーションに役立ちます。
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
セキュリティ文脈と通信規約関係の間の相関関係は全く書き取られません。 (この.6通のセクション1.1ドキュメントで議論した施設を縛る任意のチャンネルはこの規則への意図的な例外を表します、メカニズムをサポートしながらGSS-APIの中で追加保護が特徴であるとサポートして。) この分離は、GSS-APIがさまざまなコミュニケーションで使用されるのを許容します。
Linn [Page 7] RFC 1508 Generic Security Interface September 1993
リン[7ページ]RFC1508ジェネリックセキュリティは1993年9月に連結します。
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.
環境、また、個々の呼び出しに関する呼出し手順を簡素化します。 多くの場合(キャッシュされた情報の基本的なセキュリティプロトコル、関連メカニズム、および有用性に依存する)、同時に文脈セットアップに必要である州の情報は頭文字署名利用者データと共に送ることができます、追加交換処理を挿入しないで。
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_タイプ)を特定するのが必要です。 メカニズムの定義は特定の暗号化技術(または、代替の暗号化技術の中のハイブリッドか選択)の使用だけではなく、そのメカニズムがセキュリティがサービスであるとサポートするのに使う構文の定義とデータ要素交換の意味論も具体化します。
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_タイプが中で評価する「デフォルト」を指定するのが、お勧めである、またはGSS-API実行で呼び出されて、適切なmech_タイプを選ぶために、訪問者だけが、特定のmech_タイプが雇われるよう指示するかもしれません。
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_タイプを特定するための手段は異なった環境と事情において異なるでしょう。 しかし、例が含んでいる、(制限されない、)、:
use of a fixed mech_type, defined by configuration, within an
environment
環境の中で構成によって定義された固定mech_タイプの使用
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_タイプを特定するために何らかの名前付けサービスでデータベースを命名します。
explicit negotiation between GSS-API callers in advance of
security context setup
セキュリティ文脈セットアップの前のGSS-API訪問者の間の明白な交渉
When transferred between GSS-API peers, mech_type specifiers (per Appendix B, represented as Object Identifiers (OIDs)) serve to qualify the interpretation of associated tokens. (The structure and encoding of Object Identifiers is defined in ISO/IEC 8824, "Specification of Abstract Syntax Notation One (ASN.1)" and in ISO/IEC 8825, "Specification of Basic Encoding Rules for Abstract Syntax Notation One (ASN.1)".) Use of hierarchically structured OIDs serves to preclude ambiguous interpretation of mech_type specifiers.
GSS-API同輩の間に移すと、mech_型指定子(1Object Identifiers(OIDs)として表されたAppendix Bあたりの)は、関連トークンの解釈に資格を与えるのに勤めます。 (Object Identifiersの構造とコード化はISO/IEC8824、「抽象構文記法1(ASN.1)の仕様」で定義されます、そして、ISO/IEC8825では、「基本的なコード化の仕様は抽象構文記法1(ASN.1)のために統治します」。) 階層的で構造化されたOIDsの使用は、mech_型指定子のあいまいな解釈を排除するのに役立ちます。
Linn [Page 8] RFC 1508 Generic Security Interface September 1993
リン[8ページ]RFC1508ジェネリックセキュリティは1993年9月に連結します。
The OID representing the DASS MechType, for example, is 1.3.12.2.1011.7.5.
例えばダスMechTypeを表すOIDはそうです。1.3 .12 .2 .1011 .7 .5。
1.1.5. Naming
1.1.5. 命名
The GSS-API avoids prescription of naming structures, treating the names transferred across the interface in order to initiate and accept security contexts as opaque octet string quantities. 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のimplementabilityの目標をサポートします、異なったメカニズムが異なったフォームで提示される名前を処理して、認証するという事実を認識して。GSS-APIの範囲の外に環境を命名する任意のセットに翻訳機能を提供する一般化されたサービスがあります。 与えられたエンドシステムの中でサポートされた命名形式の中で翻訳する地方の変換機能の有用性と使用は予期されます。
Two distinct classes of name representations are used in conjunction with different GSS-API parameters:
2つの異なったクラスの名前代理は異なったGSS-APIパラメタに関連して使用されます:
a printable form (denoted by OCTET STRING), for acceptance from
and presentation to users; printable name forms are accompanied by
OID tags identifying the namespace to which they correspond
ユーザへの承認とプレゼンテーションのための印刷可能なフォーム(OCTET STRINGによって指示されます)。 印刷可能な名前フォームはそれらが相当する名前空間を特定するOIDタグによって伴われます。
an internal form (denoted by INTERNAL NAME), opaque to callers and
defined by individual GSS-API implementations; GSS-API
implementations supporting multiple namespace types are
responsible for maintaining internal tags to disambiguate the
interpretation of particular names
内部のフォーム(INTERNAL NAMEによって指示される)、訪問者であって定義されることへの個々のGSS-API実行による不透明なもの。 複数の名前空間がタイプであるとサポートするGSS-API実行は特定の名前の解釈のあいまいさを除くために内部のタグを維持するのに原因となります。
Tagging of printable 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.
印刷可能な名前のタグ付けで、GSS-API訪問者と基本的なGSS-APIメカニズムを名前タイプのあいまいさを除いて、関連名前のタイプが彼らが処理できるものであるかどうかと決心しています、別のタイプの名前として1つのタイプの名前を誤解するので結果として生じることができたエイリアシング問題を避けて。
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()), and internal name deallocation (GSS_Release_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
名前がタグ付けをされる手段にタイプを提供することに加えて、この仕様は、ある呼ぶアプリケーションにちなんで環境を独立と命名するレベルをサポートするために基関数を定義します。 自分たちを必要とするというわけではない訪問者の要件に向かって指向の基本サービスを提供するために、名前の内部の構文と意味論を解釈してください、名前比較のためのGSS-API呼び出し。GSS_Import_は())、および内部名を反配分と命名します。(GSS_Compare_が())を命名する、人間読み込み可能なディスプレイ、(GSS_Display_名())、入力変換、((GSS_Release_名前())機能は定義されます。 (これらの提案されたGSS-API呼び出しが既にそれらのエンドシステムの中の実在のシステム種名操作基関数に基づく多くのエンドシステムで実装されると予期されます; GSS-APIの中の包含は意図します。
Linn [Page 9] RFC 1508 Generic Security Interface September 1993
リン[9ページ]RFC1508ジェネリックセキュリティは1993年9月に連結します。
offer GSS-API callers a portable means to perform specific operations, supportive of authorization and audit requirements, on authenticated names.)
特定の承認と監査要求事項を支持している操作を認証された名前に実行する携帯用の手段を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_名前()実装は適切であるところで与えられた名前空間(例えば、X.500 Distinguished Namesの代替の印刷可能な表現)に対応する1つ以上の印刷可能な構文をサポートできます、代替の表現の中で選ぶ彼らの訪問者のための柔軟性を許容して。 GSS_Display_名前()実装は適宜彼らの運用環境に選択された印刷可能な構文を出力しました。 この選択は地域にかかわる事柄です。 代替の印刷可能な構文の向こう側に移植性を望んでいる訪問者は、印刷可能な名前フォームに基づく比較を実装するのを控えるべきであり、1つの内部の形式名が別のものに合っているかどうか決定するのに代わりに呼ぶというGSS_Compare_名()を使用するべきです。
1.1.6. Channel Bindings
1.1.6. チャンネル結合
The GSS-API accommodates the concept of caller-provided channel
binding ("chan_binding") information, used by 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 and of protection mechanisms
applied to that communications channel. Verification by one peer of
chan_binding information provided by the other peer to a context
serves to protect against various active attacks. The caller
initiating a security context must determine the chan_binding values
before making the GSS_Init_sec_context() call, and consistent values
must be provided by both peers to a context. Callers should not
assume that underlying mechanisms provide confidentiality protection
for channel binding information.
GSS-APIはそのコミュニケーションチャンネルに情報を縛って(「chan_結合」)、基本的なコミュニケーションチャンネルの関連特性(例えば、アドレス、暗号化キーの変成している表現)にセキュリティ文脈の確立を縛るのにGSS-API訪問者によって使用されて、保護メカニズムについて適用された訪問者によって提供されたチャンネルの概念に対応します。 もう片方の同輩によって文脈に提供されたchanの_の拘束力がある情報の1人の同輩による検証は、様々な活発な攻撃から守るのに役立ちます。 セキュリティ文脈を開始する訪問者は、GSS_Init_を秒_文脈()にする前のchanの_の拘束力がある値が呼ぶと決心しなければなりません、そして、両方の同輩は一貫した値を文脈に提供しなければなりません。 訪問者は、発症機序がチャンネルのための秘密性保護に拘束力がある情報を提供すると仮定するべきではありません。
Use or non-use of the GSS-API channel binding facility is a caller option, and GSS-API supporting mechanisms can support operation in an environment where NULL channel bindings are presented. When non-NULL channel bindings are used, certain mechanisms will offer enhanced security value by interpreting the bindings' content (rather than simply representing those bindings, or signatures 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 into related documents.) In order for GSS-API callers to be portable across multiple mechanisms and achieve the full security functionality available from each mechanism, it is strongly recommended that GSS-API callers provide channel bindings consistent
施設を縛るGSS-APIチャンネルの使用か非使用が訪問者オプションです、そして、メカニズムをサポートするGSS-APIはNULLチャンネル結合が提示される環境における操作をサポートすることができます。 非NULLチャンネル結合が使用されているとき、あるメカニズムは、結合の内容(トークンの中に単にそれらの結合、またはそれらの上で計算された署名を表すよりむしろ)を解釈することによって警備の強化値を提供して、したがって、定義された形式の特定のデータのプレゼンテーションによるでしょう。 このために、メカニズム作成者の中の協定は議論を縛るチャンネルのコンテンツのための従来の解釈を定義します、文脈創始者とアクセプタのためにアドレス特許説明書の作成書を含んでいて(通信規約環境の満足している扶養家族と共に)。 (これらのコンベンションは関連するドキュメントに組み入れられています。) GSS-API訪問者が複数のメカニズムの向こう側に携帯用であり、各メカニズムから利用可能な完全なセキュリティの機能性を達成するように、GSS-API訪問者が結合をチャンネルに一貫していた状態で供給することが強く勧められます。
Linn [Page 10] RFC 1508 Generic Security Interface September 1993
リン[10ページ]RFC1508ジェネリックセキュリティは1993年9月に連結します。
with these conventions and those of the networking environment in which they operate.
それらが作動するネットワーク環境のこれらのコンベンションともので。
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
1.2.1. 状態報告
Each GSS-API call provides two status return values. Major_status values provide a mechanism-independent indication of call status (e.g., GSS_COMPLETE, GSS_FAILURE, GSS_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つの状態リターン値を提供します。 主要な_状態値が呼び出し状態のメカニズムから独立しているしるしを供給する、(例えば、GSS_COMPLETE、GSS_FAILURE、CONTINUE_が必要としたGSS_) 訪問者の中でジェネリックファッションで正常なコントロール流動を追い立てるために、十分です。 テーブル1は表ファッションで定義された主要な_状態復帰コードをまとめます。
Table 1: GSS-API Major Status Codes
テーブル1: GSS-APIの主要なステータスコード
FATAL ERROR CODES
致命的なエラーコード
GSS_BAD_BINDINGS channel binding mismatch
GSS_BAD_MECH unsupported mechanism requested
GSS_BAD_NAME invalid name provided
GSS_BAD_NAMETYPE name of unsupported type provided
GSS_BAD_STATUS invalid input status selector
GSS_BAD_SIG token had invalid signature
GSS_CONTEXT_EXPIRED specified security context expired
GSS_CREDENTIALS_EXPIRED expired credentials detected
GSS_DEFECTIVE_CREDENTIAL defective credential detected
GSS_DEFECTIVE_TOKEN defective token detected
GSS_FAILURE failure, unspecified at GSS-API
level
GSS_NO_CONTEXT no valid security context specified
GSS_NO_CRED no valid credentials provided
GSS_BAD_BINDINGS channel binding mismatch GSS_BAD_MECH unsupported mechanism requested GSS_BAD_NAME invalid name provided GSS_BAD_NAMETYPE name of unsupported type provided GSS_BAD_STATUS invalid input status selector GSS_BAD_SIG token had invalid signature GSS_CONTEXT_EXPIRED specified security context expired GSS_CREDENTIALS_EXPIRED expired credentials detected GSS_DEFECTIVE_CREDENTIAL defective credential detected GSS_DEFECTIVE_TOKEN defective token detected GSS_FAILURE failure, unspecified at GSS-API level GSS_NO_CONTEXT no valid security context specified GSS_NO_CRED no valid credentials provided
INFORMATORY STATUS CODES
INFORMATORY STATUS CODES
GSS_COMPLETE normal completion
GSS_CONTINUE_NEEDED continuation call to routine
required
GSS_DUPLICATE_TOKEN duplicate per-message token
detected
GSS_OLD_TOKEN timed-out per-message token
detected
GSS_UNSEQ_TOKEN out-of-order per-message token
detected
GSS_COMPLETE normal completion GSS_CONTINUE_NEEDED continuation call to routine required GSS_DUPLICATE_TOKEN duplicate per-message token detected GSS_OLD_TOKEN timed-out per-message token detected GSS_UNSEQ_TOKEN out-of-order per-message token detected
Linn [Page 11] RFC 1508 Generic Security Interface September 1993
Linn [Page 11] RFC 1508 Generic Security Interface September 1993
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 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.
GSS_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 accomodated with sequences of continuation calls to GSS_Init_sec_context() and GSS_Accept_sec_context(). The same mechanism is used to encapsulate mutual authentication within the GSS-API's context initiation calls.
GSS_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 accomodated with sequences of continuation calls to GSS_Init_sec_context() and GSS_Accept_sec_context(). The same mechanism is used to encapsulate mutual authentication within the GSS-API's context initiation calls.
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.
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.
1.2.2. Per-Message Security Service Availability
1.2.2. Per-Message Security Service Availability
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:
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:
the integ_avail flag indicates whether per-message integrity and
data origin authentication services are available
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
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
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_Sign() or GSS_Seal() primitives on the
associated context will apply no cryptographic protection to user
data messages.
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_Sign() or GSS_Seal() primitives on the associated context will apply no cryptographic protection to user data messages.
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_Seal(), encapsulate the protected data unit.
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_Seal(), encapsulate the protected data unit.
Linn [Page 12] RFC 1508 Generic Security Interface September 1993
Linn [Page 12] RFC 1508 Generic Security Interface September 1993
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.
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.
1.2.3. Per-Message Replay Detection and Sequencing
1.2.3. Per-Message Replay Detection and Sequencing
Certain underlying mech_types are expected to 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.
Certain underlying mech_types are expected to 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.
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 mech_type, 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.
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 mech_type, 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.
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:
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:
When replay_det_state is TRUE, the possible major_status returns for well-formed and correctly signed messages are as follows:
When replay_det_state is TRUE, the possible major_status returns for well-formed and correctly signed messages are as follows:
1. GSS_COMPLETE 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_COMPLETE 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.
2. GSS_DUPLICATE_TOKEN indicates that the signature on the
received message was correct, but that the message was recognized
as a duplicate of a previously-processed message.
2. GSS_DUPLICATE_TOKEN indicates that the signature on the received message was correct, but that the message was recognized as a duplicate of a previously-processed message.
3. GSS_OLD_TOKEN indicates that the signature on the received
message was correct, but that the message is too old to be checked
for duplication.
3. GSS_OLD_TOKEN indicates that the signature on the received message was correct, but that the message is too old to be checked for duplication.
Linn [Page 13] RFC 1508 Generic Security Interface September 1993
Linn [Page 13] RFC 1508 Generic Security Interface September 1993
When sequence_state is TRUE, the possible major_status returns for well-formed and correctly signed messages are as follows:
When sequence_state is TRUE, the possible major_status returns for well-formed and correctly signed messages are as follows:
1. GSS_COMPLETE 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_COMPLETE 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.
2. GSS_DUPLICATE_TOKEN indicates that the signature on the
received message was correct, but that the message was recognized
as a duplicate of a previously-processed message.
2. GSS_DUPLICATE_TOKEN indicates that the signature on the received message was correct, but that the message was recognized as a duplicate of a previously-processed message.
3. GSS_OLD_TOKEN indicates that the signature on the received
message was correct, but that the token is too old to be checked
for duplication.
3. GSS_OLD_TOKEN indicates that the signature on the received message was correct, but that the token is too old to be checked for duplication.
4. GSS_UNSEQ_TOKEN indicates that the signature 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_UNSEQ_TOKEN indicates that the signature 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.]
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.
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.
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_Sign() and GSS_Seal(), and would maintain (within a time- limited window) a cache (qualified by originator-recipient pair) identifying received data elements processed by GSS_Verify() and
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_Sign() and GSS_Seal(), and would maintain (within a time- limited window) a cache (qualified by originator-recipient pair) identifying received data elements processed by GSS_Verify() and
Linn [Page 14] RFC 1508 Generic Security Interface September 1993
Linn [Page 14] RFC 1508 Generic Security Interface September 1993
GSS_Unseal(). When this feature is active, exception status returns (GSS_DUPLICATE_TOKEN, GSS_ OLD_TOKEN) will be provided when GSS_Verify() or GSS_Unseal() 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.
GSS_Unseal(). When this feature is active, exception status returns (GSS_DUPLICATE_TOKEN, GSS_ OLD_TOKEN) will be provided when GSS_Verify() or GSS_Unseal() 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.
1.2.4. Quality of Protection
1.2.4. Quality of Protection
Some mech_types will 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.
Some mech_types will 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.
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.
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.
2. Interface Descriptions
2. Interface Descriptions
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.
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.
Linn [Page 15] RFC 1508 Generic Security Interface September 1993
Linn [Page 15] RFC 1508 Generic Security Interface September 1993
Table 2: GSS-API Calls
Table 2: GSS-API Calls
CREDENTIAL MANAGEMENT
CREDENTIAL MANAGEMENT
GSS_Acquire_cred acquire credentials for use
GSS_Release_cred release credentials after use
GSS_Inquire_cred display information about
credentials
GSS_Acquire_cred acquire credentials for use GSS_Release_cred release credentials after use GSS_Inquire_cred display information about credentials
CONTEXT-LEVEL CALLS
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_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
PER-MESSAGE CALLS
PER-MESSAGE CALLS
GSS_Sign apply signature, receive as token
separate from message
GSS_Verify validate signature token along with
message
GSS_Seal sign, optionally encrypt,
encapsulate
GSS_Unseal decapsulate, decrypt if needed,
validate signature
GSS_Sign apply signature, receive as token separate from message GSS_Verify validate signature token along with message GSS_Seal sign, optionally encrypt, encapsulate GSS_Unseal decapsulate, decrypt if needed, validate signature
SUPPORT CALLS
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 printable name
GSS_Release_oid_set free storage of OID set object
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 printable name GSS_Release_oid_set free storage of OID set object
Linn [Page 16] RFC 1508 Generic Security Interface September 1993
Linn [Page 16] RFC 1508 Generic Security Interface September 1993
2.1. Credential management calls
2.1. Credential management calls
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.
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.
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.
GSS_Acquire_信用()呼び出しはGSS-APIの中でアプリケーションの移植性を支持して定義されます、携帯用のサーバ・アプリケーションのサポートに向かった特定のオリエンテーションで。 対話的なユーザのための(あるシステムとメカニズムのための)資格証明書がサーバプロセスのために資格証明書と異なって管理されるかもしれないと認められます。 そのような環境で、これらのケースを区別するのが、GSS-API実行の責任であり、この区別をするための手順は地域にかかわる事柄です。 GSS_Release_信用()呼び出しは訪問者が、資格証明書構造の使用はもう必要でないことをGSS-APIに示す手段を提供します。 GSS_Inquire_信用()呼び出しで、訪問者は資格証明書構造の情報を決定できます。
2.1.1. GSS_Acquire_cred call
2.1.1. GSS_Acquire_信用呼び出し
Inputs:
入力:
o desired_name INTERNAL NAME, -NULL requests locally-determined
default
o 必要な_名前INTERNAL NAME、-NULL要求は局所的にデフォルトを決定しました。
o lifetime_req INTEGER,-in seconds; 0 requests default
o 中のreq INTEGERが後援する生涯_。 0つの要求がデフォルトとします。
o desired_mechs SET OF OBJECT IDENTIFIER,-empty set requests
system-selected default
o 必要な_mechs SET OF OBJECT IDENTIFIER空のセットはシステムで選択されたデフォルトを要求します。
o cred_usage INTEGER-0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
2=ACCEPT-ONLY
o 信用_用法のINTEGER-0=INITIATE AND ACCEPTの、そして、1=INITIATE唯一の2=ACCEPTだけ
Outputs:
出力:
o major_status INTEGER,
o 主要な_状態INTEGER
o minor_status INTEGER,
o 小さい方の_状態INTEGER
o output_cred_handle OCTET STRING,
o _信用_ハンドルOCTET STRINGを出力してください。
o actual_mechs SET OF OBJECT IDENTIFIER,
o 実際の_mechs SET OF OBJECT IDENTIFIER
o lifetime_rec INTEGER -in seconds, or reserved value for
INDEFINITE
o -中のrec INTEGERが後援する生涯_、またはINDEFINITEにおいて、予約された値
Linn [Page 17] RFC 1508 Generic Security Interface September 1993
リン[17ページ]RFC1508ジェネリックセキュリティは1993年9月に連結します。
Return major_status codes:
主要な_ステータスコードを返してください:
o GSS_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_COMPLETEは、それが、資格証明書が首尾よく確立されたよう要求したのを示します、生涯_recで示されて、用法に適した持続時間が、その後の使用のためにそれらの資格証明書に出力_信用_ハンドルでハンドルを返していて参照をつけることができるよう実際の_mechsで示されたmech_タイプと、そのセットのための信用_用法で要求したので。
o GSS_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_BAD_MECHは、GSS-API実行タイプによってサポートされないmech_タイプが要求されたのを示します。
o GSS_BAD_NAMETYPE indicates that the provided desired_name is
uninterpretable or of a type unsupported by the supporting GSS-API
implementation, so no credentials could be established for the
accompanying desired_name.
o GSS_BAD_NAMETYPEは、提供された必要な_名が「非-解明でき」であることを示すことができませんか、したがって、サポートGSS-API実行によってサポートされないタイプでは、付随の必要な_名のために資格証明書は全く確立できませんでした。
o GSS_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_BAD_NAMEが、提供された必要な_名が内部的に法人組織の型指定子情報で矛盾しているのを示すので、付随の必要な_名のために資格証明書を全く確立できませんでした。
o GSS_FAILURE indicates that credential establishment failed for
reasons unspecified at the GSS-API level, including lack of
authorization to establish and use credentials associated with the
identity named in the input desired_name argument.
o GSS_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 using only default credentials for context establishment purposes will have no need to invoke this call.
GSS_Acquire_信用()は、元本が必要な_名前入力引数で表されたアイデンティティの下でセキュリティ文脈を開始する、そして/または、受け入れることができる(入力信用_用法パラメタの関数として)ように資格証明書を取得するのに使用されます。 無事終了のときに、返された出力_信用_ハンドル結果は後天的な資格証明書のその後の参照のためのハンドルを提供します。 通常、文脈設立目的にデフォルト資格証明書だけを使用するシングルユーザークライアントプロセスがこの呼び出しを呼び出す必要性を全く持たないでしょう。
A caller may provide the value NULL for desired_name, signifying a request for credentials corresponding to a default principal identity. The procedures used by GSS-API implementations to select the appropriate principal identity in response to this form of request are local matters. 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
デフォルト主体のアイデンティティに対応する資格証明書を求める要求を意味して、訪問者は必要な_名に値のNULLを提供するかもしれません。 この形式の要求に対応して適切な主要なアイデンティティを選択するのにGSS-API実行で用いられた手順は地域にかかわる事柄です。 GSS_Acquire_信用()が呼ばれるとき、複数のプレ確立した資格証明書が同じ主要なアイデンティティ(例えば複数のユーザログインセッションの結果、)のために存在するのは、可能です。 特定の資格証明書を選択するのにそのような場合使用される手段は地域にかかわる事柄です。 GSS_Acquire_信用()への入力生涯_req議論は地方のGSS-API実行がこの曖昧さの解消をする際に使う役に立つ情報を提供するかもしれません。
Linn [Page 18] RFC 1508 Generic Security Interface September 1993
リン[18ページ]RFC1508ジェネリックセキュリティは1993年9月に連結します。
in a manner which will best satisfy a caller's intent.
特に満足させられる方法で、訪問者は熱心です。
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.
生涯_rec結果は後天的な資格証明書が有効になる時の長さを示します、プレゼントからのオフセットとして。 メカニズムは資格証明生涯の規制が全く課されないならINDEFINITEを示す予約された値を返すかもしれません。 GSS_Acquire_信用()の訪問者は、プレゼントで始まって、有効である後天的な資格証明書がことである時(生涯_req議論)の長さを要求できるか、またはデフォルト正当性間隔で資格証明書を要求できます。 (先日付を書かれた資格証明書を求める要求はGSS-APIの中でサポートされません。) あるメカニズムと実装は資格証明有効期間特許説明書の作成書にポイント準備段階でGSS_Acquire_信用()要求(例えば、ユーザログイン手順に関連した)の実施に固まるかもしれません。 その結果、生涯_reqのために非デフォルト値を要求する訪問者は、いつもそのような要求を光栄に思うことができるというわけではないのを見分けなければならなくて、生涯_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_信用()の訪問者は、明らかに返された資格証明書で対応することになっている1セットのmech_タイプ(必要な_mechs議論)は指定できるか、またはシステムの定義されたデフォルトセットのmech_タイプのために資格証明書を要求できます。 システムで指定されたデフォルトセットの選択はアプリケーションの移植性のためにお勧めです。 実際の_mechsリターン価値は、返された資格証明書が使用されるかもしれないメカニズムのセットを決定するために訪問者によって査問されるかもしれません。
2.1.2. GSS_Release_cred call
2.1.2. GSS_Release_信用呼び出し
Input:
以下を入力してください。
o cred_handle OCTET STRING-NULL specifies default credentials
o 信用_ハンドルOCTET STRING-NULLはデフォルト資格証明書を指定します。
Outputs:
出力:
o major_status INTEGER,
o 主要な_状態INTEGER
o minor_status INTEGER
o 小さい方の_状態INTEGER
Return major_status codes:
主要な_ステータスコードを返してください:
o GSS_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_COMPLETEは、入力信用_ハンドルによって参照をつけられる資格証明書がその後のアクセスの目的のために訪問者によってリリースされたのを示します。 そのような資格証明書への認可された共用アクセスであるかもしれない他のプロセスへの効果は地域にかかわる事柄です。
Linn [Page 19] RFC 1508 Generic Security Interface September 1993
リン[19ページ]RFC1508ジェネリックセキュリティは1993年9月に連結します。
o GSS_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_いいえ_CREDは、リリース操作が全く実行されなかったのを示します、入力信用_ハンドルが無効であったか、または訪問者が参照をつけられた資格証明書にアクセスする承認を欠いているので。
o GSS_FAILURE indicates that the release operation failed for
reasons unspecified at the GSS-API level.
o GSS_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_信用()の実施がシステム全体のベースで特定のセットの資格証明書を削除すると思うことができません。
2.1.3. GSS_Inquire_cred call
2.1.3. GSS_Inquire_信用呼び出し
Input:
以下を入力してください。
o cred_handle OCTET STRING -NULL specifies default credentials
o 信用_ハンドルOCTET STRING -NULLはデフォルト資格証明書を指定します。
Outputs:
出力:
o major_status INTEGER,
o 主要な_状態INTEGER
o minor_status INTEGER,
o 小さい方の_状態INTEGER
o cred_name INTERNAL NAME,
o 信用_名前INTERNAL NAME
o lifetime_rec INTEGER -in seconds, or reserved value for
INDEFINITE
o -中のrec INTEGERが後援する生涯_、またはINDEFINITEにおいて、予約された値
o cred_usage INTEGER, -0=INITIATE-AND-ACCEPT, 1=INITIATE-ONLY,
2=ACCEPT-ONLY
o 信用_用法INTEGER、-0=INITIATE AND-ACCEPT、1=INITIATEだけ、2=ACCEPTだけ
o mech_set SET OF OBJECT IDENTIFIER
o mech_セットSET OF OBJECT IDENTIFIER
Return major_status codes:
主要な_ステータスコードを返してください:
o GSS_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_COMPLETEは、入力信用_ハンドル議論で参照をつけられる資格証明書が有効であり、出力信用_名、生涯_rec、および信用_用法値がそれぞれ資格証明書の関連主要な名前、残っている生涯、適当な用法モード、およびサポートしているメカニズムタイプの代理をするのを示します。
Linn [Page 20] RFC 1508 Generic Security Interface September 1993
リン[20ページ]RFC1508ジェネリックセキュリティは1993年9月に連結します。
o GSS_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_いいえ_CREDは、参照をつけられた資格証明書に関して情報を全く返すことができなかったのを示します、入力信用_ハンドルが無効であったか、または訪問者が参照をつけられた資格証明書にアクセスする承認を欠いているので。
o GSS_FAILURE indicates that the release operation failed for
reasons unspecified at the GSS-API level.
o GSS_FAILUREは、リリース操作がGSS-APIレベルで不特定の理由で失敗したのを示します。
The GSS_Inquire_cred() call is defined primarily for the use of those callers which make use of default credentials 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_信用()呼び出しは主としてそれらの訪問者のGSS_Acquire_信用()で明らかに資格証明書を取得するよりむしろデフォルト資格証明書を利用する使用のために定義されます。 それは、訪問者が資格証明構造の関連主要な名前を決定するのを可能にします、有効期間、セキュリティ文脈開始のためのユーザビリティ、そして/または、承認と、サポートしているメカニズムのままで残っていて。
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_CONTINUE_NEEDED status returns from GSS_Init_sec_context() and GSS_Accept_sec_context(). 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_Init_を秒_文脈()と呼びます。 目標では、そのトークンはGSS_Accept_秒_文脈()に通過されます。 基本的なmech_タイプと指定されたオプションに頼っていて、追加トークン交換は文脈設立の間に実行されるかもしれません。 そのような交換は必要な状態がGSS_Init_秒_文脈()とGSS_Accept_秒_文脈()から返すGSS_CONTINUE_によって対応されます。 確立した関係への何れの当事者は、文脈がいつもう必要でないかという文脈情報を洗い流すためにGSS_Delete_秒_文脈()を呼び出すかもしれません。 GSS_Process_文脈_トークン()は、文脈レベルコントロール情報を運ぶ容認されたトークンを処理するのに使用されます。 GSS_Context_時間()で、訪問者は確立した関係が有効なままで残っている時間の長さを測定できます。
2.2.1. GSS_Init_sec_context call
2.2.1. GSS_Init_秒_文脈呼び出し
Inputs:
入力:
o claimant_cred_handle OCTET STRING, -NULL specifies "use
default"
o _主張者_信用ハンドルOCTET STRING、-NULLが指定する、「デフォルトを使用してください」
o input_context_handle INTEGER, -0 specifies "none assigned
yet"
o 入力_文脈_ハンドルINTEGER、-0は「まだ割り当てられていなかったなにも」を指定します。
o targ_name INTERNAL NAME,
o targ_名前INTERNAL NAME
o mech_type OBJECT IDENTIFIER, -NULL parameter specifies "use
default"
o mech_タイプOBJECT IDENTIFIER、パラメタが指定する-NULLは「デフォルトを使用します」。
o deleg_req_flag BOOLEAN,
o deleg_req_旗のブールです。
Linn [Page 21] RFC 1508 Generic Security Interface September 1993
リン[21ページ]RFC1508ジェネリックセキュリティは1993年9月に連結します。
o mutual_req_flag BOOLEAN,
o 互いの_req_旗のブールです。
o replay_det_req_flag BOOLEAN,
o ブールであることで_det_req_旗を再演してください。
o sequence_req_flag BOOLEAN,
o 系列_req_旗のブールです。
o lifetime_req INTEGER,-0 specifies default lifetime
o 生涯_req INTEGER-0がデフォルトを指定する、生涯
o chan_bindings OCTET STRING,
o chan_結合OCTET STRING
o input_token OCTET STRING-NULL or token received from target
o 入力_トークンOCTET STRING-NULLか目標から受け取られたトークン
Outputs:
出力:
o major_status INTEGER,
o 主要な_状態INTEGER
o minor_status INTEGER,
o 小さい方の_状態INTEGER
o output_context_handle INTEGER,
o _文脈_ハンドルINTEGERを出力してください。
o mech_type OBJECT IDENTIFIER, -actual mechanism always
indicated, never NULL
o mech_タイプOBJECT IDENTIFIER、いつも示された、実際のメカニズム、決してNULLでない
o output_token OCTET STRING, -NULL or token to pass to context
target
o 文脈目標に渡す出力_トークンOCTET STRING、-NULLまたはトークン
o deleg_state BOOLEAN,
o deleg_州のブールです。
o mutual_state BOOLEAN,
o 互いの_州のブールです。
o replay_det_state BOOLEAN,
o ブールであることで_det_状態を再演してください。
o sequence_state BOOLEAN,
o 系列_州のブールです。
o conf_avail BOOLEAN,
o conf_利益ブールです。
o integ_avail BOOLEAN,
o integ_利益ブールです。
o lifetime_rec INTEGER - in seconds, or reserved value for
INDEFINITE
o 秒の生涯_rec INTEGER、またはINDEFINITEにおいて、予約された値
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.
この呼び出しはプレゼンテーションに適した出力_トークンを指定された目標に生成するために文脈創始者を代表して認証サーバか他のネットワーク実体に相談しなければならないそれらのmech_タイプのために未定のネットワーク相互作用を妨げるかもしれません。
Return major_status codes:
主要な_ステータスコードを返してください:
Linn [Page 22] RFC 1508 Generic Security Interface September 1993
リン[22ページ]RFC1508ジェネリックセキュリティは1993年9月に連結します。
o GSS_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_COMPLETEが、文脈レベル情報が首尾よく初期化されて、返された出力_トークンが目標が実行する十分な情報を提供するのを示す、-、新設された文脈におけるメッセージ処理。
o GSS_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.
o CONTINUE_が必要としたGSS_は入力_トークン議論としてGSS_Init_秒_文脈()への継続呼び出しに回答を返された出力_トークンにおける制御情報を目標に送らなければならなくて、受け取って、通過しなければならないのを示します、この文脈に関連してメッセージ処理を実行できる前に。
o GSS_DEFECTIVE_TOKEN indicates that consistency checks performed on
the input_token failed, preventing further processing from being
performed based on that token.
o GSS_DEFECTIVE_TOKENは、一貫性チェックが処理がそのトークンに基づいて実行されるのをさらに防いで、失敗された入力_トークンに働いたのを示します。
o GSS_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_DEFECTIVE_CREDENTIALは、主張者_信用_ハンドルによって参照をつけられる資格証明構造に実行された一貫性チェックが失敗したのを示します、処理がその資格証明構造を使用することで実行されるのをさらに防いで。
o GSS_BAD_SIG indicates that the received input_token contains an
incorrect signature, so context setup cannot be accomplished.
o GSS_BAD_SIGが、容認された入力_トークンが正しくない署名を含むのを示すので、文脈セットアップを実行できません。
o GSS_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, or because
the caller lacks authorization to access the referenced
credentials.
o GSS_いいえ_CREDは、文脈が全く確立されなかったのを示します、文脈アクセプタ使用だけに、参照をつけられた資格証明書が有効であるので入力信用_ハンドルが無効であったか、または訪問者が参照をつけられた資格証明書にアクセスする承認を欠いているので。
o GSS_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_CREDENTIALS_EXPIREDが、入力主張者_信用_ハンドル議論で提供された資格証明書がもう有効でないことを示すので、文脈設立は終了できません。
o GSS_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_BAD_BINDINGSは、訪問者の提供されたchan_結合と入力_トークンから抽出されたものの間のミスマッチが検出されたのを示します、セキュリティ関連しているイベントを意味して、文脈設立を防いで。 (この結果は互いの_状態がTRUEである文脈だけのためにGSS_Init_秒_文脈によって返されるでしょう。)
o GSS_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_CONTINUE_NEEDED
status returns.
o GSS_いいえ_CONTEXTは、どんな有効な文脈も提供された入力文脈_ハンドルとして認識されなかったのを示します。 この主要な状態は必要な状態が返すGSS_CONTINUE_に続く後継者呼び出しのためだけに返されるでしょう。
o GSS_BAD_NAMETYPE indicates that the provided targ_name is of a
type uninterpretable or unsupported by the supporting GSS-API
implementation, so context establishment cannot be completed.
o GSS_BAD_NAMETYPEが、サポートGSS-API実行によって「非-解明でき」であるかサポートされないタイプには提供されたtarg_名前があるのを示すので、文脈設立は終了できません。
Linn [Page 23] RFC 1508 Generic Security Interface September 1993
リン[23ページ]RFC1508ジェネリックセキュリティは1993年9月に連結します。
o GSS_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_BAD_NAMEが、提供されたtarg_名前が内部的に法人組織の型指定子情報で矛盾しているのを示すので、文脈設立を実行できません。
o GSS_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_FAILUREはGSS-APIレベルで不特定の理由で文脈セットアップを実行できないで、どんなインタフェースで定義された回復動作も利用可能でないことを示します。
This routine is used by a context initiator, and ordinarily emits one (or, for the case of a multi-step exchange, more than one) output_token suitable for use by the target within the selected mech_type's protocol. 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. 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_CONTINUE_NEEDED status returns; different protocol sequences modeled by the GSS_CONTINUE_NEEDED mechanism will require access to credentials at different points in the context establishment sequence.
このルーチンは、文脈創始者によって使用されて、通常、選択されたmech_タイプのプロトコルの中で目標で使用に適した1つ(または、多段階交換に関するケースのためのより多くのもの)の出力_象徴を放ちます。 主張者_信用_ハンドルによって参照をつけられる信任状構造で情報を使用して、GSS_Init_秒_文脈()は目標targ_名でセキュリティ文脈を確立するのに必要であるデータ構造を初期化します。 主張者_信用_ハンドルはGSS_Init_秒_文脈()への初期の呼び出しの上と、そして、必要な状態が返すGSS_CONTINUE_から生じるどんな後継者呼び出しの上の同じ正当な証明書構造に対応しなければなりません。 _必要なメカニズムがそうするGSS_CONTINUEによってモデル化された異なったプロトコル系列は文脈設立系列の異なったポイントの信任状へのアクセスを必要とします。
The input_context_handle argument is 0, specifying "not yet assigned", on the first GSS_Init_sec_context() call relating to a given context. That call returns an output_context_handle for future references to this context. 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.
与えられた文脈に関連する最初のGSS_Init_秒の_文脈()呼び出しのときに入力_文脈_ハンドル議論は0、「まだ割り当てられなかった」指定です。 その呼び出しはこの文脈の後学のための出力_文脈_ハンドルを返します。 GSS_Init_秒_文脈()への継続試みが文脈設立を実行するのに必要であるときに、以前に返された非ゼロハンドル価値は、入力_文脈_ハンドル議論に入れられて、返された出力_文脈_ハンドル議論で反響されるでしょう。 そのような継続試み(そして継続試みだけに関して)のときに、入力_象徴値は、文脈の目標から返された象徴を提供するのに使用されます。
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_結合議論は、基本的なコミュニケーションチャンネルのセキュリティ関連の特性(例えば、アドレス、暗号化キー)にセキュリティ文脈を縛る情報を提供するのに訪問者によって使用されます。 この議論の用法の、より多くの議論のためのこの.6通のセクション1.1ドキュメントを見てください。
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_CONTINUE_NEEDED major_status.
入力_象徴議論は、目標から受け取られたメッセージを含んでいて、単に呼び出しのときにGSS_CONTINUE_が主要な_状態を必要としたのを示す前のリターンに続くGSS_Init_秒_文脈()に重要です。
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
コミュニケーション経路を目標に確立して、どんな返された出力_象徴(付随の返された主要な_状態値の如何にかかわらず)もその経路の上の目標に伝えるのは、訪問者の責任です。 しかしながら、出力_象徴と共に伝えることができます。
Linn [Page 24] RFC 1508 Generic Security Interface September 1993
リン[24ページ]RFC1508の一般的なセキュリティは1993年9月に連結します。
the first application-provided input message to be processed by GSS_Sign() or GSS_Seal() in conjunction with a successfully- established context.
首尾よく設立された文脈に関連してGSS_Sign()かGSS_Seal()によって処理されるべき最初のアプリケーションで提供された入力メッセージ。
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.)
創始者は入力旗で様々な文脈レベル機能を要求するかもしれません: アクセス権のdeleg_req_旗の要求代表団、互いの_req_旗は互いの認証、再生検出機能が確立した関係で移されたメッセージに適用されるという再生_det_req_旗の要求、および配列が実施されるという系列_req_旗の要求を要求します。 (再生検出と配列の特徴の詳しい情報に関してセクション1.2.3を見てください。)
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, 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. These state indicators' values are undefined unless the routine's major_status indicates COMPLETE. 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, and will never indicate the value for "default".
任意に要求可能な特徴のすべてがすべての基本的なmech_タイプで利用可能になるというわけではないでしょう。 対応するリターン州の値(deleg_状態、互いの_州は_det_状態を再演します、系列_状態)はmechの機能として_タイプ処理能力と創始者によって提供された入力旗(文脈でアクティブになる特徴のセット)を示します。 ルーチンの主要な_状態がCOMPLETEを示さない場合、これらの州のインディケータの値は未定義です。 訪問者によって要求された正確なセットの特徴を提供しない場合、文脈設立が行き詰まることを引き起こしません。 訪問者の使用に、提供された特徴セットが不適当であるなら、文脈を削除するのは、訪問者の特権です。 返されたmech_タイプ値は、文脈で使われた特定のメカニズムを示して、「デフォルト」のために値は決して示さないでしょう。
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_Seal() can be honored. In similar fashion, the integ_avail return value indicates whether per-message integrity services are available (through either GSS_Sign() or GSS_Seal()) on the established context.
文脈が1メッセージあたりの秘密性サービスを支持するかどうかを示すので、conf_利益リターン価値は、GSS_Seal()へのconf_req_旗の入力による暗号化を求める要求を光栄に思うことができるかどうかを訪問者に知らせます。 同様に、integ_利益リターン価値は、1メッセージの保全あたりのサービスが利用可能であるかどうかを示します。(確立した関係のGSS_Sign()かGSS_Seal())のどちらかを通して。
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 values of conf_avail, integ_avail, and lifetime_rec are undefined unless the routine's major_status indicates COMPLETE.
生涯_req入力は証明されるために文脈の生涯のための必要な上限を指定します、0の値が要求するのにおいて使用されていた状態でデフォルト、生涯 生涯_recリターン価値は有効で、言い表す文脈がオフセットとしてプレゼントからなる時間の長さを示します。 メカニズム能力、信任している生涯、およびローカルの方針によって、それは生涯_reqで要求された値に対応しないかもしれません。 文脈生涯の規制が全く課されないなら、これは、INDEFINITE生涯_reqを表す予約された値を返すことによって、示されるかもしれません。 ルーチンの主要な_状態がCOMPLETEを示さない場合、conf_利益、integ_利益、および生涯_recの値は未定義です。
If the mutual_state is TRUE, this fact will be reflected within the
互いの_状態がTRUEであるなら、この事実は中で反射するでしょう。
Linn [Page 25] RFC 1508 Generic Security Interface September 1993
リン[25ページ]RFC1508の一般的なセキュリティは1993年9月に連結します。
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.
_象徴を出力してください。 そのような文脈に関連した目標のGSS_Accept_秒_文脈()への呼び出しはGSS_Init_秒_文脈()への継続呼び出しで処理されるために象徴を返すでしょう、互いの認証を達成するために。
2.2.2. GSS_Accept_sec_context call
2.2.2. GSS_Accept_秒_文脈呼び出し
Inputs:
入力:
o acceptor_cred_handle OCTET STRING,-NULL specifies "use
default"
o OCTET STRING-NULLが指定するアクセプタ_信用_ハンドルは「デフォルトを使用します」。
o input_context_handle INTEGER, -0 specifies "not yet assigned"
o 入力_文脈_ハンドルINTEGER、-0は「まだ割り当てられなく」指定します。
o chan_bindings OCTET STRING,
o chan_結合OCTET STRING
o input_token OCTET STRING
o 入力_象徴OCTET STRING
Outputs:
出力:
o major_status INTEGER,
o 主要な_状態INTEGER
o minor_status INTEGER,
o 小さい方の_状態INTEGER
o src_name INTERNAL NAME,
o src_名前INTERNAL NAME
o mech_type OBJECT IDENTIFIER,
o mech_タイプOBJECT IDENTIFIER
o output_context_handle INTEGER,
o _文脈_ハンドルINTEGERを出力してください。
o deleg_state BOOLEAN,
o deleg_州のブールです。
o mutual_state BOOLEAN,
o 互いの_州のブールです。
o replay_det_state BOOLEAN,
o ブールであることで_det_状態を再演してください。
o sequence_state BOOLEAN,
o 系列_州のブールです。
o conf_avail BOOLEAN,
o conf_利益ブールです。
o integ_avail BOOLEAN,
o integ_利益ブールです。
o lifetime_rec INTEGER, - in seconds, or reserved value for
INDEFINITE
o 秒の生涯_rec INTEGER、またはINDEFINITEにおいて、予約された値
o delegated_cred_handle OCTET STRING,
o _信用_ハンドルOCTET STRINGを代表として派遣しました。
o output_token OCTET STRING -NULL or token to pass to context
o 出力_象徴OCTET STRING -NULLか文脈に渡す象徴
Linn [Page 26] RFC 1508 Generic Security Interface September 1993
リン[26ページ]RFC1508の一般的なセキュリティは1993年9月に連結します。
initiator
創始者
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.
この呼び出しは容認された入力_象徴を有効にするために文脈アクセプタを代表して電話番号案内か他のネットワーク実体に相談しなければならないそれらのmech_タイプのために未定のネットワーク相互作用を妨げるかもしれません。
Return major_status codes:
主要な_ステータスコードを返してください:
o GSS_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_COMPLETEは首尾よく文脈レベルデータ構造を初期化して、現在この文脈に関連してメッセージ処理を実行できるのを示します。
o GSS_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 CONTINUE_が必要としたGSS_は入力_象徴議論としてGSS_Accept_秒_文脈()への継続呼び出しに応答を返された出力_象徴の制御情報を創始者に送らなければならなくて、受けて、通過しなければならないのを示します、以前-、この文脈に関連してメッセージ処理を実行できます。
o GSS_DEFECTIVE_TOKEN indicates that consistency checks performed on
the input_token failed, preventing further processing from being
performed based on that token.
o GSS_DEFECTIVE_TOKENは、一貫性チェックが処理がその象徴に基づいて実行されるのをさらに防いで、失敗された入力_象徴に働いたのを示します。
o GSS_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_DEFECTIVE_CREDENTIALは、アクセプタ_信用_ハンドルによって参照をつけられる信任している構造に実行された一貫性チェックが失敗したのを示します、処理がその信任している構造を使用することで実行されるのをさらに防いで。
o GSS_BAD_SIG indicates that the received input_token contains an
incorrect signature, so context setup cannot be accomplished.
o GSS_BAD_SIGが、容認された入力_象徴が正しくない署名を含むのを示すので、文脈セットアップを実行できません。
o GSS_DUPLICATE_TOKEN indicates that the signature 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_DUPLICATE_TOKENは、容認された入力_象徴における署名が正しかったのですが、入力_象徴の写しに既に処理されたとき入力_象徴が認識されたのを示します。 どんな新しい関係も確立されません。
o GSS_OLD_TOKEN indicates that the signature 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_OLD_TOKENは、容認された入力_象徴における署名が正しかったのですが、入力_象徴が複製がないかどうか以前に処理された入力_象徴に対してチェックできないくらい古いのを示します。 どんな新しい関係も確立されません。
o GSS_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, or because
the caller lacks authorization to access the referenced
credentials.
o GSS_いいえ_CREDは、文脈が全く確立されなかったのを示します、文脈創始者使用だけに、参照をつけられた信任状が有効であるので入力信用_ハンドルが無効であったか、または訪問者が参照をつけられた信任状にアクセスする認可を欠いているので。
Linn [Page 27] RFC 1508 Generic Security Interface September 1993
リン[27ページ]RFC1508の一般的なセキュリティは1993年9月に連結します。
o GSS_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_CREDENTIALS_EXPIREDが、入力アクセプタ_信用_ハンドル議論で提供された信任状がもう有効でないことを示すので、文脈設立は終了できません。
o GSS_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_BAD_BINDINGSは、訪問者の提供されたchan_結合と入力_象徴から抽出されたものの間のミスマッチが検出されたのを示します、セキュリティ関連している出来事を意味して、文脈設立を防いで。
o GSS_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_CONTINUE_NEEDED
status returns.
o GSS_いいえ_CONTEXTは、どんな有効な文脈も提供された入力文脈_ハンドルとして認識されなかったのを示します。 この主要な状態は必要な状態が返すGSS_CONTINUE_に続く後継者呼び出しのためだけに返されるでしょう。
o GSS_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_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 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_CONTINUE_NEEDED status returns; different protocol sequences modeled by the GSS_CONTINUE_NEEDED mechanism will require access to credentials at different points in the context establishment sequence.
GSS_Accept_秒_文脈()ルーチンは文脈目標によって使用されます。 入力アクセプタ_信用_ハンドルによって参照をつけられる信任状構造で情報を使用して、入って来る入力_象徴について確かめます、そして、(文脈設立系列の無事終了に続きます)は認証されたsrc_名とタイプが使用したmech_を返します。 アクセプタ_信用_ハンドルはGSS_Accept_秒_文脈()への初期の呼び出しの上と、そして、必要な状態が返すGSS_CONTINUE_から生じるどんな後継者呼び出しの上の同じ正当な証明書構造に対応しなければなりません。 _必要なメカニズムがそうするGSS_CONTINUEによってモデル化された異なったプロトコル系列は文脈設立系列の異なったポイントの信任状へのアクセスを必要とします。
The input_context_handle argument is 0, specifying "not yet assigned", on the first GSS_Accept_sec_context() call relating to a given context. That call returns an output_context_handle for future references to this context; when continuation attempts to GSS_Accept_sec_context() are needed to perform context establishment, that handle value will be entered into the input_context_handle argument.
与えられた文脈に関連する最初のGSS_Accept_秒の_文脈()呼び出しのときに入力_文脈_ハンドル議論は0、「まだ割り当てられなかった」指定です。 その呼び出しはこの文脈の後学のための出力_文脈_ハンドルを返します。 GSS_Accept_秒_文脈()への継続試みが文脈設立を実行するのに必要であるときに、そのハンドル値は入力_文脈_ハンドル議論に入れられるでしょう。
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_結合議論は、基本的なコミュニケーションチャンネルのセキュリティ関連の特性(例えば、アドレス、暗号化キー)にセキュリティ文脈を縛る情報を提供するのに訪問者によって使用されます。 この議論の用法の、より多くの議論のためのこの.6通のセクション1.1ドキュメントを見てください。
The returned state results (deleg_state, mutual_state, replay_det_state, and sequence_state) reflect the same context state values as returned to GSS_Init_sec_context()'s caller at the initiator system.
(deleg_州、互いの_州、再生_det_州、および系列_状態)が同じ文脈を反映するという返された州の結果は、GSS_Init_秒_文脈()に返される値による創始者システムの訪問者であると述べます。
Linn [Page 28] RFC 1508 Generic Security Interface September 1993
リン[28ページ]RFC1508の一般的なセキュリティは1993年9月に連結します。
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_Seal() can be honored. In similar fashion, the integ_avail return value indicates whether per-message integrity services are available (through either GSS_Sign() or GSS_Seal()) on the established context.
文脈が1メッセージあたりの秘密性サービスを支持するかどうかを示すので、conf_利益リターン価値は、GSS_Seal()へのconf_req_旗の入力による暗号化を求める要求を光栄に思うことができるかどうかを訪問者に知らせます。 同様に、integ_利益リターン価値は、1メッセージの保全あたりのサービスが利用可能であるかどうかを示します。(確立した関係のGSS_Sign()かGSS_Seal())のどちらかを通して。
The lifetime_rec return value indicates the length of time for which the context will be valid, expressed as an offset from the present. The values of deleg_state, mutual_state, replay_det_state, sequence_state, conf_avail, integ_avail, and lifetime_rec are undefined unless the accompanying major_status indicates COMPLETE.
生涯_recリターン価値は有効で、言い表す文脈がオフセットとしてプレゼントからなる時間の長さを示します。 付随の主要な_状態がCOMPLETEを示さない場合、deleg_州、互いの_州、再生_det_州、系列_州、conf_利益、integ_利益、および生涯_recの値は未定義です。
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.
代表として派遣された_信用_ハンドル結果は、deleg_状態がTRUEであるときにだけ、重要であり、参照への目標のための手段に代表として派遣された信任状を提供します。 非NULLであるときに、出力_象徴結果は多段階文脈設立系列を続けるために文脈創始者に返される文脈レベル象徴を提供します。 GSS_Init_秒_文脈()で注意されるように、文脈の同輩(この場合文脈創始者)にどんな返された象徴も移すべきです、付随の返された主要な_状態の値の如何にかかわらず。
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_Verify() or GSS_Unseal(). 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_Verify()かGSS_Unseal()に渡された1メッセージあたりのデータ要素から。(象徴はGSS_Accept_秒_文脈()に渡されます)。 これらのデータ要素はただ一つのアプリケーションメッセージに届くかもしれません、そして、首尾よくメッセージ処理を実行できる前にGSS_Accept_秒_文脈()を実行しなければなりません。
2.2.3. GSS_Delete_sec_context call
2.2.3. GSS_Delete_秒_文脈呼び出し
Input:
以下を入力してください。
o context_handle INTEGER
o 文脈_ハンドルINTEGER
Outputs:
出力:
o major_status INTEGER,
o 主要な_状態INTEGER
o minor_status INTEGER,
o 小さい方の_状態INTEGER
o output_context_token OCTET STRING
o 出力_文脈_象徴OCTET STRING
Return major_status codes:
主要な_ステータスコードを返してください:
Linn [Page 29] RFC 1508 Generic Security Interface September 1993
リン[29ページ]RFC1508の一般的なセキュリティは1993年9月に連結します。
o GSS_COMPLETE indicates that the context was recognized, that
relevant context-specific information was flushed, and that the
returned output_context_token is ready for transfer to the
context's peer.
o GSS_COMPLETEは文脈が認識されて、関連文脈特殊情報が洗い流されて、返された出力_文脈_象徴が文脈の同輩への転送の準備ができているのを示します。
o GSS_NO_CONTEXT indicates that no valid context was recognized for
the input context_handle provide, so no deletion was performed.
o GSS_いいえ_CONTEXTは、どんな有効な文脈も_ハンドルが提供する入力文脈として認識されなかったので削除が全く実行されなかったのを示します。
o GSS_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_FAILUREは、文脈が認識されましたが、GSS-APIレベルで不特定の理由でGSS_Delete_秒_文脈()操作を実行できなかったのを示します。
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.
この呼び出しはセキュリティ文脈が削除されることであるときに活発な通知をセントラルサーバーにしなければならないmech_タイプのために未定のネットワーク相互作用を妨げるかもしれません。
This call can be made by either peer in a security context, to flush context-specific information and to return an output_context_token which can be passed to the context's peer informing it 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.) Attempts to perform per- message processing on a deleted context will result in error returns.
どちらの同輩も、文脈特殊情報を洗い流して、また、同輩の対応する文脈情報を洗い流すことができることをそれに知らせる文脈の同輩に渡すことができる出力_文脈_トークンを返すためにセキュリティ文脈でこの電話をかけることができます。 (文脈がいったん確立されると、かかわった同輩が情報の満了時間に達しているか、またはGSS_Delete_秒_文脈()電話をかけるまでキャッシュされた資格証明の、そして、文脈関連の情報を保有すると予想されます。) 働く試み、-、削除された文脈におけるメッセージ処理は誤りリターンをもたらすでしょう。
2.2.4. GSS_Process_context_token call
2.2.4. GSS_Process_文脈_トークン呼び出し
Inputs:
入力:
o context_handle INTEGER,
o 文脈_ハンドルINTEGER
o input_context_token OCTET STRING
o 入力_文脈_トークンOCTET STRING
Outputs:
出力:
o major_status INTEGER,
o 主要な_状態INTEGER
o minor_status INTEGER,
o 小さい方の_状態INTEGER
Return major_status codes:
主要な_ステータスコードを返してください:
o GSS_COMPLETE indicates that the input_context_token was
successfully processed in conjunction with the context referenced
by context_handle.
o GSS_COMPLETEは、入力_文脈_トークンが首尾よく文脈_ハンドルによって参照をつけられる文脈に関連して処理されたのを示します。
o GSS_DEFECTIVE_TOKEN indicates that consistency checks performed on
the received context_token failed, preventing further processing
o GSS_DEFECTIVE_TOKENは、一貫性チェックが、より遠い処理を防いで、失敗された容認された文脈_トークンに働いたのを示します。
Linn [Page 30] RFC 1508 Generic Security Interface September 1993
リン[30ページ]RFC1508ジェネリックセキュリティは1993年9月に連結します。
from being performed with that token.
そのトークンで実行されるのから。
o GSS_NO_CONTEXT indicates that no valid context was recognized for
the input context_handle provided.
o GSS_いいえ_CONTEXTは、どんな有効な文脈も提供された入力文脈_ハンドルとして認識されなかったのを示します。
o GSS_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_FAILUREは、文脈が認識されましたが、GSS-APIレベルで不特定の理由でGSS_Process_文脈_トークン()操作を実行できなかったのを示します。
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_COMPLETE status.
この呼び出しは文脈がいったん確立されると同輩から受け取られた文脈_トークンを処理するのに使用されます、文脈レベル州の情報に関する対応する影響で。 この施設の1つの使用がGSS_Delete_秒_文脈()によって生成された文脈_トークンの処理です。 GSS_Process_文脈_トークン()はそのために未定のネットワーク相互作用を妨げないでしょう。 別の使用はポイントのときに地方のGSS-API実行が既にGSS_COMPLETE状態を示した後リモート同輩文脈設立失敗を示すトークンを処理することです。
2.2.5. GSS_Context_time call
2.2.5. GSS_Context_時間呼び出し
Input:
以下を入力してください。
o context_handle INTEGER,
o 文脈_ハンドルINTEGER
Outputs:
出力:
o major_status INTEGER,
o 主要な_状態INTEGER
o minor_status INTEGER,
o 小さい方の_状態INTEGER
o lifetime_rec INTEGER - in seconds, or reserved value for
INDEFINITE
o 秒の生涯_rec INTEGER、またはINDEFINITEにおいて、予約された値
Return major_status codes:
主要な_ステータスコードを返してください:
o GSS_COMPLETE indicates that the referenced context is valid, and
will remain valid for the amount of time indicated in
lifetime_rec.
o GSS_COMPLETEは参照をつけられた文脈が有効であることを示して、生涯_recで示された時間、有効なままで残るでしょう。
o GSS_CONTEXT_EXPIRED indicates that data items related to the
referenced context have expired.
o GSS_CONTEXT_EXPIREDは、参照をつけられた文脈に関連するデータ項目が期限が切れたのを示します。
o GSS_CREDENTIALS_EXPIRED indicates that the context is recognized,
but that its associated credentials have expired.
o GSS_CREDENTIALS_EXPIREDは、文脈が認識されますが、関連資格証明書が期限が切れたのを示します。
o GSS_NO_CONTEXT indicates that no valid context was recognized for
the input context_handle provided.
o GSS_いいえ_CONTEXTは、どんな有効な文脈も提供された入力文脈_ハンドルとして認識されなかったのを示します。
Linn [Page 31] RFC 1508 Generic Security Interface September 1993
リン[31ページ]RFC1508ジェネリックセキュリティは1993年9月に連結します。
o GSS_FAILURE indicates that the requested operation failed for
reasons unspecified at the GSS-API level.
o GSS_FAILUREは、要求された操作がGSS-APIレベルで不特定の理由で失敗したのを示します。
This call is used to determine the amount of time for which a currently established context will remain valid.
この呼び出しは、現在確立した関係が有効なままで残っている時間を決定するのに使用されます。
2.3. Per-message calls
2.3. 1メッセージあたりの呼び出し
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_Sign() is properly input to GSS_Verify(), and the output from GSS_Seal() is properly input to GSS_Unseal().
呼び出しのこのグループは、確立したセキュリティ関係に1メッセージあたりの保護処理を実行するのに使用されます。 これらの呼び出しのいずれも未定のネットワーク相互作用を妨げません。 これらの呼び出しは文脈の創始者か文脈の目標によって呼び出されるかもしれません。 このグループの4人のメンバーが2組であるとみなされるべきです。 GSS_Sign()からの出力は適切にGSS_Verify()に入力されます、そして、GSS_Seal()からの出力は適切にGSS_Unseal()に入力されます。
GSS_Sign() and GSS_Verify() support data origin authentication and data integrity services. When GSS_Sign() 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_Verify(), which validates the message in conjunction with the separate token.
GSS_Sign()とGSS_Verify()は、データが発生源認証とデータ保全サービスであるとサポートします。 GSS_Sign()が入力メッセージに呼び出されるとき、それは発症機序が指定されたセキュリティー・サービスを提供できるデータ項目を含む1メッセージあたり1つのトークンをもたらします。 オリジナルのメッセージは1メッセージあたりの発生しているトークンと共にリモート同輩に渡されます。 これらの2つのデータ要素がGSS_Verify()によって処理されます。(Verify()は別々のトークンに関連してメッセージを有効にします)。
GSS_Seal() and GSS_Unseal() support caller-requested confidentiality in addition to the data origin authentication and data integrity services offered by GSS_Sign() and GSS_Verify(). GSS_Seal() outputs a single data element, encapsulating optionally enciphered user data as well as associated token data items. The data element output from GSS_Seal() is passed to the remote peer and processed by GSS_Unseal() at that system. GSS_Unseal() combines decipherment (as required) with validation of data items related to authentication and integrity.
GSS_Seal()とGSS_Unseal()はGSS_Sign()とGSS_Verify()によって提供されたデータ発生源認証とデータ保全サービスに加えた訪問者によって要求された秘密性をサポートします。 GSS_Seal()はただ一つのデータ要素を出力します、関連トークンデータ項目と同様に任意に暗号化された利用者データをカプセル化して。GSS_Seal()からのデータ要素出力は、リモート同輩に渡されて、GSS_Unseal()によってそのシステムに処理されます。 GSS_Unseal()は認証と保全に関連するデータ項目の合法化に解読(必要に応じて)を結合します。
2.3.1. GSS_Sign call
2.3.1. GSS_Signは呼びます。
Inputs:
入力:
o context_handle INTEGER,
o 文脈_ハンドルINTEGER
o qop_req INTEGER,-0 specifies default QOP
o qop_req INTEGER-0はデフォルトQOPを指定します。
o message OCTET STRING
o メッセージOCTET STRING
Outputs:
出力:
o major_status INTEGER,
o 主要な_状態INTEGER
Linn [Page 32] RFC 1508 Generic Security Interface September 1993
リン[32ページ]RFC1508ジェネリックセキュリティは1993年9月に連結します。
o minor_status INTEGER,
o 小さい方の_状態INTEGER
o per_msg_token OCTET STRING
o _msg_トークンOCTET STRING単位で
Return major_status codes:
主要な_ステータスコードを返してください:
o GSS_COMPLETE indicates that a signature, suitable for an
established security context, was successfully applied and that
the message and corresponding per_msg_token are ready for
transmission.
o GSS_COMPLETEは確立したセキュリティ関係に適した署名が首尾よく適用されて、_msg_トークンあたりのメッセージと対応がトランスミッションの準備ができているのを示します。
o GSS_CONTEXT_EXPIRED indicates that context-related data items have
expired, so that the requested operation cannot be performed.
o GSS_CONTEXT_EXPIREDは、要求された操作を実行できないように文脈関連のデータ項目が期限が切れたのを示します。
o GSS_CREDENTIALS_EXPIRED indicates that the context is recognized,
but that its associated credentials have expired, so that the
requested operation cannot be performed.
o GSS_CREDENTIALS_EXPIREDは、文脈が認識されますが、関連資格証明書が期限が切れたのを示します、要求された操作を実行できないように。
o GSS_NO_CONTEXT indicates that no valid context was recognized for
the input context_handle provided.
o GSS_いいえ_CONTEXTは、どんな有効な文脈も提供された入力文脈_ハンドルとして認識されなかったのを示します。
o GSS_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_FAILUREは、文脈が認識されましたが、GSS-APIレベルで不特定の理由で要求された操作を実行できなかったのを示します。
Using the security context referenced by context_handle, apply a signature to the input message (along with timestamps and/or other data included in support of mech_type-specific mechanisms) and return the result in per_msg_token. The qop_req parameter allows quality- of-protection control. The caller passes the message and the per_msg_token to the target.
セキュリティ文脈が文脈で_ハンドルに参照をつけて、入力メッセージ(mech_タイプ特有のメカニズムを支持してタイムスタンプ、そして/または、他のデータを含んでいるのに伴う)に署名を適用して、_msg_トークン単位で結果を返す使用。 qop_reqパラメタは保護の品質コントロールを許します。 そして、訪問者がメッセージが通る、_目標へのmsg_トークン単位で。
The GSS_Sign() function completes before the message and per_msg_token is sent to the peer; successful application of GSS_Sign() does not guarantee that a corresponding GSS_Verify() has been (or can necessarily be) performed successfully when the message arrives at the destination.
Sign()機能が_メッセージの前とmsg_トークン単位で完成するGSS_を同輩に送ります。 GSS_Sign()のうまくいっているアプリケーションは、メッセージが目的地に到着するとき、対応するGSS_Verify()が首尾よく実行されたのを(または、必ず、あることができます)保証しません。
2.3.2. GSS_Verify call
2.3.2. GSS_Verifyは呼びます。
Inputs:
入力:
o context_handle INTEGER,
o 文脈_ハンドルINTEGER
o message OCTET STRING,
o メッセージOCTET STRING
o per_msg_token OCTET STRING
o _msg_トークンOCTET STRING単位で
Linn [Page 33] RFC 1508 Generic Security Interface September 1993
リン[33ページ]RFC1508ジェネリックセキュリティは1993年9月に連結します。
Outputs:
出力:
o qop_state INTEGER,
o qop_州のINTEGER
o major_status INTEGER,
o 主要な_状態INTEGER
o minor_status INTEGER,
o 小さい方の_状態INTEGER
Return major_status codes:
主要な_ステータスコードを返してください:
o GSS_COMPLETE indicates that the message was successfully verified.
o GSS_COMPLETEは、メッセージが首尾よく確かめられたのを示します。
o GSS_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_DEFECTIVE_TOKENは、一貫性チェックが受け取られていること_処理がそのトークンで実行されるのをさらに防いで、失敗されたmsg_トークンあたりに働いたのを示します。
o GSS_BAD_SIG indicates that the received per_msg_token contains an
incorrect signature for the message.
o GSS_BAD_SIGは、_msg_トークンあたりの受け取られているのがメッセージのための正しくない署名を含むのを示します。
o GSS_DUPLICATE_TOKEN, GSS_OLD_TOKEN, and GSS_UNSEQ_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_DUPLICATE_TOKEN、GSS_OLD_TOKEN、およびGSS_UNSEQ_TOKEN値はセクション1.2.3で説明された1メッセージあたりの任意の再生検出機能に関連して現れます。 それらの意味論はそのセクションで説明されます。
o GSS_CONTEXT_EXPIRED indicates that context-related data items have
expired, so that the requested operation cannot be performed.
o GSS_CONTEXT_EXPIREDは、要求された操作を実行できないように文脈関連のデータ項目が期限が切れたのを示します。
o GSS_CREDENTIALS_EXPIRED indicates that the context is recognized,
but that its associated credentials have expired, so that the
requested operation cannot be performed.
o GSS_CREDENTIALS_EXPIREDは、文脈が認識されますが、関連資格証明書が期限が切れたのを示します、要求された操作を実行できないように。
o GSS_NO_CONTEXT indicates that no valid context was recognized for
the input context_handle provided.
o GSS_いいえ_CONTEXTは、どんな有効な文脈も提供された入力文脈_ハンドルとして認識されなかったのを示します。
o GSS_FAILURE indicates that the context is recognized, but that the
GSS_Verify() operation could not be performed for reasons
unspecified at the GSS-API level.
o GSS_FAILUREは、文脈が認識されましたが、GSS-APIレベルで不特定の理由でGSS_Verify()操作を実行できなかったのを示します。
Using the security context referenced by context_handle, verify that the input per_msg_token contains an appropriate signature for the input message, and apply any active replay detection or sequencing features. Return an indication of the quality-of-protection applied to the processed message in the qop_state result.
文脈_ハンドルによって参照をつけられるセキュリティ文脈を使用して、_msg_トークンあたりの入力が入力メッセージのための適切な署名を含むことを確かめてください、そして、あらゆる活発な再生検出や配列の特徴を適用してください。 qop_州の結果における処理メッセージに適用された保護の品質のしるしを返してください。
Linn [Page 34] RFC 1508 Generic Security Interface September 1993
リン[34ページ]RFC1508ジェネリックセキュリティは1993年9月に連結します。
2.3.3. GSS_Seal call
2.3.3. GSS_Sealは呼びます。
Inputs:
入力:
o context_handle INTEGER,
o 文脈_ハンドルINTEGER
o conf_req_flag BOOLEAN,
o conf_req_旗のブールです。
o qop_req INTEGER,-0 specifies default QOP
o qop_req INTEGER-0はデフォルトQOPを指定します。
o input_message OCTET STRING
o 入力_メッセージOCTET STRING
Outputs:
出力:
o major_status INTEGER,
o 主要な_状態INTEGER
o minor_status INTEGER,
o 小さい方の_状態INTEGER
o conf_state BOOLEAN,
o conf_州のブールです。
o output_message OCTET STRING
o 出力_メッセージOCTET STRING
Return major_status codes:
主要な_ステータスコードを返してください:
o GSS_COMPLETE indicates that the input_message was successfully
processed and that the output_message is ready for transmission.
o GSS_COMPLETEは入力_メッセージが首尾よく処理されて、出力_メッセージがトランスミッションの準備ができているのを示します。
o GSS_CONTEXT_EXPIRED indicates that context-related data items have
expired, so that the requested operation cannot be performed.
o GSS_CONTEXT_EXPIREDは、要求された操作を実行できないように文脈関連のデータ項目が期限が切れたのを示します。
o GSS_CREDENTIALS_EXPIRED indicates that the context is recognized,
but that its associated credentials have expired, so that the
requested operation cannot be performed.
o GSS_CREDENTIALS_EXPIREDは、文脈が認識されますが、関連資格証明書が期限が切れたのを示します、要求された操作を実行できないように。
o GSS_NO_CONTEXT indicates that no valid context was recognized for
the input context_handle provided.
o GSS_いいえ_CONTEXTは、どんな有効な文脈も提供された入力文脈_ハンドルとして認識されなかったのを示します。
o GSS_FAILURE indicates that the context is recognized, but that the
GSS_Seal() operation could not be performed for reasons
unspecified at the GSS-API level.
o GSS_FAILUREは、文脈が認識されましたが、GSS-APIレベルで不特定の理由でGSS_Seal()操作を実行できなかったのを示します。
Performs the data origin authentication and data integrity functions of GSS_Sign(). 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 allows quality-of-protection control.
GSS_Sign()のデータ発生源認証とデータ保全機能を実行します。 入力conf_req_旗がTRUEであるなら、要求します秘密性が入力_メッセージに適用されるという。 秘密性はすべてのmech_タイプかすべての実装によってサポートされないかもしれません。 返されたconf_州旗は、秘密性が入力_メッセージに提供されたかどうかを示します。 qop_reqパラメタは保護の品質コントロールを許します。
Linn [Page 35] RFC 1508 Generic Security Interface September 1993
リン[35ページ]RFC1508ジェネリックセキュリティは1993年9月に連結します。
In all cases, the GSS_Seal() call yields a single output_message data element containing (optionally enciphered) user data as well as control information.
すべての場合では、GSS_Seal()は、制御情報と同様に利用者データを含む(任意に暗号化されます)ただ一つの出力_メッセージデータ要素に利回りと呼びます。
2.3.4. GSS_Unseal call
2.3.4. GSS_Unsealは呼びます。
Inputs:
入力:
o context_handle INTEGER,
o 文脈_ハンドルINTEGER
o input_message OCTET STRING
o 入力_メッセージOCTET STRING
Outputs:
出力:
o conf_state BOOLEAN,
o conf_州のブールです。
o qop_state INTEGER,
o qop_州のINTEGER
o major_status INTEGER,
o 主要な_状態INTEGER
o minor_status INTEGER,
o 小さい方の_状態INTEGER
o output_message OCTET STRING
o 出力_メッセージOCTET STRING
Return major_status codes:
主要な_ステータスコードを返してください:
o GSS_COMPLETE indicates that the input_message was successfully
processed and that the resulting output_message is available.
o GSS_COMPLETEは入力_メッセージが首尾よく処理されて、結果として起こる出力_メッセージが利用可能であることを示します。
o GSS_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_DEFECTIVE_TOKENがチェックが働いたその一貫性を示す、_に従って、処理が実行されるのをさらに防いで、入力_メッセージから抽出されたmsg_トークンは失敗しました。
o GSS_BAD_SIG indicates that an incorrect signature was detected for
the message.
o GSS_BAD_SIGは、正しくない署名がメッセージのために検出されたのを示します。
o GSS_DUPLICATE_TOKEN, GSS_OLD_TOKEN, and GSS_UNSEQ_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_DUPLICATE_TOKEN、GSS_OLD_TOKEN、およびGSS_UNSEQ_TOKEN値はセクション1.2.3で説明された1メッセージあたりの任意の再生検出機能に関連して現れます。 それらの意味論はそのセクションで説明されます。
o GSS_CONTEXT_EXPIRED indicates that context-related data items have
expired, so that the requested operation cannot be performed.
o GSS_CONTEXT_EXPIREDは、要求された操作を実行できないように文脈関連のデータ項目が期限が切れたのを示します。
o GSS_CREDENTIALS_EXPIRED indicates that the context is recognized,
but that its associated credentials have expired, so that the
requested operation cannot be performed.
o GSS_CREDENTIALS_EXPIREDは、文脈が認識されますが、関連資格証明書が期限が切れたのを示します、要求された操作を実行できないように。
Linn [Page 36] RFC 1508 Generic Security Interface September 1993
リン[36ページ]RFC1508ジェネリックセキュリティは1993年9月に連結します。
o GSS_NO_CONTEXT indicates that no valid context was recognized for
the input context_handle provided.
o GSS_いいえ_CONTEXTは、どんな有効な文脈も提供された入力文脈_ハンドルとして認識されなかったのを示します。
o GSS_FAILURE indicates that the context is recognized, but that the
GSS_Unseal() operation could not be performed for reasons
unspecified at the GSS-API level.
o GSS_FAILUREは、文脈が認識されましたが、GSS-APIレベルで不特定の理由でGSS_Unseal()操作を実行できなかったのを示します。
Processes a data element generated (and optionally enciphered) by GSS_Seal(), provided as input_message. The returned conf_state value indicates whether confidentiality was applied to the input_message. If conf_state is TRUE, GSS_Unseal() deciphers the input_message. Returns an indication of the quality-of-protection applied to the processed message in the qop_state result. GSS_Seal() performs the data integrity and data origin authentication checking functions of GSS_Verify() on the plaintext data. Plaintext data is returned in output_message.
データ要素がGSS_Seal()で生成して(そして、任意に暗号化されます)、提供したプロセスは_メッセージを入力しました。 返されたconf_州の値は、秘密性が入力_メッセージに適用されたかどうかを示します。 conf_状態がTRUEであるなら、GSS_Unseal()は入力_メッセージを解読します。 保護の品質のしるしが処理メッセージに適用したリターンはqop_に結果を述べます。 GSS_Seal()は平文データでGSS_Verify()の機能をチェックするデータ保全とデータ発生源認証を実行します。 出力_メッセージで平文データを返します。
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_状態呼び出し
Inputs:
入力:
o status_value INTEGER,-GSS-API major_status or minor_status
return value
o 状態の_の値のINTEGER GSS-APIの主要な_状態か小さい方の_状態リターン価値
o status_type INTEGER,-1 if major_status, 2 if minor_status
o 状態_が主要な_状態、2であるならINTEGER-1をタイプする、小さい方の_状態です。
o mech_type OBJECT IDENTIFIER-mech_type to be used for minor_
status translation
o mech_タイプOBJECT IDENTIFIER-mech_は、小さい方の_状態翻訳に使用されるためにタイプします。
Outputs:
出力:
o major_status INTEGER,
o 主要な_状態INTEGER
o minor_status INTEGER,
o 小さい方の_状態INTEGER
o status_string_set SET OF OCTET STRING
o _状態ストリング_セットSET OF OCTET STRING
Return major_status codes:
主要な_ステータスコードを返してください:
o GSS_COMPLETE indicates that a valid printable status
representation (possibly representing more than one status event
o GSS_COMPLETEがそのa有効な印刷可能な状態表現を示す、(ことによると1回以上の状態イベントを表すこと。
Linn [Page 37] RFC 1508 Generic Security Interface September 1993
リン[37ページ]RFC1508ジェネリックセキュリティは1993年9月に連結します。
encoded within the status_value) is available in the returned
status_string_set.
中でコード化される、状態_値) 利用可能なコネは返された状態_ストリング_セットですか?
o GSS_BAD_MECH indicates that translation in accordance with an
unsupported mech_type was requested, so translation could not be
performed.
o GSS_BAD_MECHは、サポートされないmech_タイプに従った翻訳が要求されたので翻訳を実行できなかったのを示します。
o GSS_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_BAD_STATUSが、入力状態_値が無効であったか、または入力状態_タイプが1か2以外の値を運んだのを示すので、翻訳を実行できませんでした。
o GSS_FAILURE indicates that the requested operation could not be
performed for reasons unspecified at the GSS-API level.
o GSS_FAILUREは、GSS-APIレベルで不特定の理由で要求された操作を実行できなかったのを示します。
Provides a means for callers to translate GSS-API-returned major and minor status codes into printable string representations.
訪問者がAPIが返したGSSの主要で小さい方のステータスコードを印刷可能なストリング表現に翻訳する手段を提供します。
2.4.2. GSS_Indicate_mechs call
2.4.2. GSS_Indicate_mechs呼び出し
Input:
以下を入力してください。
o (none)
o (なにも)
Outputs:
出力:
o major_status INTEGER,
o 主要な_状態INTEGER
o minor_status INTEGER,
o 小さい方の_状態INTEGER
o mech_set SET OF OBJECT IDENTIFIER
o mech_セットSET OF OBJECT IDENTIFIER
Return major_status codes:
主要な_ステータスコードを返してください:
o GSS_COMPLETE indicates that a set of available mechanisms has
been returned in mech_set.
o GSS_COMPLETEは、1セットの利用可能なメカニズムが_が設定したmechで返されたのを示します。
o GSS_FAILURE indicates that the requested operation could not
be performed for reasons unspecified at the GSS-API level.
o GSS_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_Acquire_cred(), and should not be needed by other callers.
訪問者がローカルシステムに手があいているメカニズムタイプのセットを決定するのを許容します。 この呼び出しをGSS_Acquire_信用()から非デフォルトmech_タイプセットを要求する必要がある専門化している訪問者のサポートのために意図して、他の訪問者は必要とするべきではありません。
2.4.3. GSS_Compare_name call
2.4.3. GSS_Compare_名前呼び出し
Inputs:
入力:
Linn [Page 38] RFC 1508 Generic Security Interface September 1993
リン[38ページ]RFC1508ジェネリックセキュリティは1993年9月に連結します。
o name1 INTERNAL NAME,
o name1 INTERNAL NAME
o name2 INTERNAL NAME
o name2 INTERNAL NAME
Outputs:
出力:
o major_status INTEGER,
o 主要な_状態INTEGER
o minor_status INTEGER,
o 小さい方の_状態INTEGER
o name_equal BOOLEAN
o _を同輩とブールで命名してください。
Return major_status codes:
主要な_ステータスコードを返してください:
o GSS_COMPLETE indicates that name1 and name2 were comparable, and
that the name_equal result indicates whether name1 and name2 were
equal or unequal.
o GSS_COMPLETEは、name1とname2が匹敵していて、名前_同輩結果が、name1とname2が等しいか、または不平等であったかを示すのを示します。
o GSS_BAD_NAMETYPE indicates that one or both of name1 and name2
contained internal type specifiers uninterpretable by the
supporting GSS-API implementation, or that the two names' types
are different and incomparable, so the equality comparison could
not be completed.
o GSS_BAD_NAMETYPEが、2つの名前のタイプがname1とname2のものか両方がサポートGSS-API実行によって「非-解明でき」な内部の型指定子を含んだか、異なってまたは比較にならないほどであるのを示すので、平等比較は終了できませんでした。
o GSS_BAD_NAME indicates that one or both of the input names was
ill-formed in terms of its internal type specifier, so the
equality comparison could not be completed.
o GSS_BAD_NAMEが、入力名の1か両方が内部の型指定子で不適格であったのを示すので、平等比較は終了できませんでした。
o GSS_FAILURE indicates that the requested operation could not be
performed for reasons unspecified at the GSS-API level.
o GSS_FAILUREは、GSS-APIレベルで不特定の理由で要求された操作を実行できなかったのを示します。
Allows callers to compare two internal name representations for equality.
訪問者が平等の2つの内部名表現を比較するのを許容します。
2.4.4. GSS_Display_name call
2.4.4. GSS_Display_名前呼び出し
Inputs:
入力:
o name INTERNAL NAME
o 名前INTERNAL NAME
Outputs:
出力:
o major_status INTEGER,
o 主要な_状態INTEGER
o minor_status INTEGER,
o 小さい方の_状態INTEGER
o name_string OCTET STRING,
o ストリングOCTET STRINGと_を命名してください。
Linn [Page 39] RFC 1508 Generic Security Interface September 1993
リン[39ページ]RFC1508ジェネリックセキュリティは1993年9月に連結します。
o name_type OBJECT IDENTIFIER
o 名前_タイプOBJECT IDENTIFIER
Return major_status codes:
主要な_ステータスコードを返してください:
o GSS_COMPLETE indicates that a valid printable name representation
is available in the returned name_string.
o GSS_COMPLETEは、有効な印刷可能な名前表現が返された名前_ストリングで利用可能であることを示します。
o GSS_BAD_NAMETYPE indicates that the provided name was of a type
uninterpretable by the supporting GSS-API implementation, so no
printable representation could be generated.
o GSS_BAD_NAMETYPEが、タイプ「非-解明でき」には提供された名前がサポートGSS-API実行であったのを示すので、どんな印刷可能な表現も生成することができませんでした。
o GSS_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_BAD_NAMEが、提供された名前の内容がタイプという内部的に示された名前に反していたのを示すので、どんな印刷可能な表現も生成することができませんでした。
o GSS_FAILURE indicates that the requested operation could not be
performed for reasons unspecified at the GSS-API level.
o GSS_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.
訪問者が関連名前空間タイプ記述子で内部名表現を印刷可能なフォームに翻訳するのを許容します。 印刷可能なフォームの構文は地域にかかわる事柄です。
2.4.5. GSS_Import_name call
2.4.5. GSS_Import_名前呼び出し
Inputs:
入力:
o input_name_string OCTET STRING,
o _名前_ストリングOCTET STRINGを入力してください。
o input_name_type OBJECT IDENTIFIER
o 入力_名前_タイプOBJECT IDENTIFIER
Outputs:
出力:
o major_status INTEGER,
o 主要な_状態INTEGER
o minor_status INTEGER,
o 小さい方の_状態INTEGER
o output_name INTERNAL NAME
o 出力_名前INTERNAL NAME
Return major_status codes:
主要な_ステータスコードを返してください:
o GSS_COMPLETE indicates that a valid name representation is output
in output_name and described by the type value in
output_name_type.
o GSS_COMPLETEは、有効な名前表現が出力_名前で出力されて、出力_名前_タイプによるタイプ値によって説明されるのを示します。
o GSS_BAD_NAMETYPE indicates that the input_name_type is unsupported
by the GSS-API implementation, so the import operation could not
be completed.
o GSS_BAD_NAMETYPEが、タイプという入力_名前_がGSS-API実行でサポートされないのを必要とするので、輸入操作は完了できませんでした。
Linn [Page 40] RFC 1508 Generic Security Interface September 1993
リン[40ページ]RFC1508ジェネリックセキュリティは1993年9月に連結します。
o GSS_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_BAD_NAMEが、提供された入力_名前_ストリングがタイプという入力_名前_で不適格であることを必要とするので、輸入操作は完了できませんでした。
o GSS_FAILURE indicates that the requested operation could not be
performed for reasons unspecified at the GSS-API level.
o GSS_FAILUREは、GSS-APIレベルで不特定の理由で要求された操作を実行できなかったのを示します。
Allows callers to provide a printable name representation, designate the type of namespace in conjunction with which it should be parsed, and convert that printable representation to an internal form suitable for input to other GSS-API routines. The syntax of the input_name is a local matter.
訪問者が印刷可能な名前表現を提供して、名前空間に関連してそれが分析されるべきであるタイプを任命して、他のGSS-APIルーチンへの入力に適した内部のフォームにその印刷可能な表現を変換するのを許容します。 入力_名前の構文は地域にかかわる事柄です。
2.4.6. GSS_Release_name call
2.4.6. GSS_Release_名前呼び出し
Inputs:
入力:
o name INTERNAL NAME
o 名前INTERNAL NAME
Outputs:
出力:
o major_status INTEGER,
o 主要な_状態INTEGER
o minor_status INTEGER
o 小さい方の_状態INTEGER
Return major_status codes:
主要な_ステータスコードを返してください:
o GSS_COMPLETE indicates that the storage associated with the input
name was successfully released.
o GSS_COMPLETEは、入力名に関連しているストレージが首尾よくリリースされたのを示します。
o GSS_BAD_NAME indicates that the input name argument did not
contain a valid name.
o GSS_BAD_NAMEは、議論という入力名が妥当な名前を含まなかったのを示します。
o GSS_FAILURE indicates that the requested operation could not be
performed for reasons unspecified at the GSS-API level.
o GSS_FAILUREは、GSS-APIレベルで不特定の理由で要求された操作を実行できなかったのを示します。
Allows callers to release the storage associated with an internal name representation.
訪問者が内部名表現に関連しているストレージをリリースするのを許容します。
2.4.7. GSS_Release_buffer call
2.4.7. GSS_Release_バッファ呼び出し
Inputs:
入力:
o buffer OCTET STRING
o バッファOCTET STRING
Outputs:
出力:
o major_status INTEGER,
o 主要な_状態INTEGER
Linn [Page 41] RFC 1508 Generic Security Interface September 1993
リン[41ページ]RFC1508ジェネリックセキュリティは1993年9月に連結します。
o minor_status INTEGER
o 小さい方の_状態INTEGER
Return major_status codes:
主要な_ステータスコードを返してください:
o GSS_COMPLETE indicates that the storage associated with the input
buffer was successfully released.
o GSS_COMPLETEは、入力バッファに関連しているストレージが首尾よくリリースされたのを示します。
o GSS_FAILURE indicates that the requested operation could not be
performed for reasons unspecified at the GSS-API level.
o GSS_FAILUREは、GSS-APIレベルで不特定の理由で要求された操作を実行できなかったのを示します。
Allows callers to release the storage associated with an OCTET STRING buffer allocated by another GSS-API call.
訪問者が別のGSS-API呼び出しで割り当てるOCTET STRINGバッファに関連しているストレージをリリースするのを許容します。
2.4.8. GSS_Release_oid_set call
2.4.8. GSS_Release_oid_セット呼び出し
Inputs:
入力:
o buffer SET OF OBJECT IDENTIFIER
o バッファSET OF OBJECT IDENTIFIER
Outputs:
出力:
o major_status INTEGER,
o 主要な_状態INTEGER
o minor_status INTEGER
o 小さい方の_状態INTEGER
Return major_status codes:
主要な_ステータスコードを返してください:
o GSS_COMPLETE indicates that the storage associated with the input
object identifier set was successfully released.
o GSS_COMPLETEは、入力オブジェクト識別子セットに関連しているストレージが首尾よくリリースされたのを示します。
o GSS_FAILURE indicates that the requested operation could not be
performed for reasons unspecified at the GSS-API level.
o GSS_FAILUREは、GSS-APIレベルで不特定の理由で要求された操作を実行できなかったのを示します。
Allows callers to release the storage associated with an object identifier set object allocated by another GSS-API call.
訪問者が別のGSS-API呼び出しで割り当てるオブジェクト識別子セットオブジェクトに関連しているストレージをリリースするのを許容します。
3. Mechanism-Specific Example Scenarios
3. メカニズム特有の例のシナリオ
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の特徴を示すというわけではない唯一の手段を定義すると見なすべきではありません。
Linn [Page 42] RFC 1508 Generic Security Interface September 1993
リン[42ページ]RFC1508ジェネリックセキュリティは1993年9月に連結します。
3.1. Kerberos V5, single-TGT
3.1. ケルベロス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特有のログイン機能はローカルの分野ケルベロスサーバにTGTを譲ります。 TGTはクライアントのために資格証明書構造に置かれます。 クライアントは、GSS_をセキュリティ文脈を確立することにおける使用のために資格証明書に参照をつけるために信用_ハンドルを入手するAcquire_信用()と呼びます。
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_を秒_文脈()と呼びます。 要求されたサービスが異なった分野に位置しているなら、GSS_Init_秒_文脈()は分野を狙うためには地方から経路を横断するのが必要である必要なTGT/主要な組を得ます。 これらのデータは所有者のTGTキャッシュに置かれます。 どんな必要なリモート分野解決の後にも、GSS_Init_秒_文脈()は対応するセッションキーで要求されたサービスにサービスチケットを譲ります。 これらのデータは文脈に関連して保存されます。 GSS-APIコードは、_TGS_REQ要求をKRBに送って、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_秒_文脈()は、ケルベロスでフォーマットされたKRB_AP_REQメッセージを築き上げて、出力_トークンでそれを返します。 クライアントは出力_トークンをサービスに送ります。
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.
サービスは、GSS_Accept_秒_文脈()への入力_トークン議論がクライアントの認証された名前をサービスに提供するのに応じて容認されたトークンを通過して、出力_文脈_ハンドルを返します。文脈は固有識別文字について確かめます。
Both parties now hold the session key associated with the service ticket, and can use this key in subsequent GSS_Sign(), GSS_Verify(), GSS_Seal(), and GSS_Unseal() operations.
双方は、現在サービスチケットに関連しているセッションかぎを握って、その後のGSS_Sign()、GSS_Verify()、GSS_Seal()、およびGSS_Unseal()操作にこのキーを使用できます。
3.2. Kerberos V5, double-TGT
3.2. ケルベロスV5、二重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.
以下に注意してください。 ケルベロスV5の上でGSS-APIを実装するとき、誤り経路の不要な頻繁な実施を避けるために、表すのが適切に見える、「独身のTGT K-V5"、「別々のmech_と二重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_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_CONTINUE_NEEDED
(指定するか、またはデフォルトとします)mech_タイプに基づいて、GSS_Init_秒_文脈()は、二重TGTプロトコルが指定された目標に使われるべきであることを決定します。 GSS_Init_秒_文脈()はCONTINUE_が必要としたGSS_に主要な_状態を返します、そして、返された出力_トークンはサービスのTGTのためのサービスに要求を含んでいます。 (適当に長い残っている生涯があるサービスTGTがキャッシュで既に存在しているなら、使用可能であるかもしれません、このステップの必要性を取り除いて。) クライアントは出力_トークンをサービスに通過します。 以下に注意してください。 このシナリオは_が必要としたGSS_CONTINUEの異なった使用を例証します。
Linn [Page 43] RFC 1508 Generic Security Interface September 1993
リン[43ページ]RFC1508ジェネリックセキュリティは1993年9月に連結します。
status return facility than for support of mutual authentication; note that both uses can coexist as successive operations within a single context establishment operation.
状態は互いの認証のサポートより施設を返します。 両方の用途が連続した操作としてただ一つの文脈設立操作の中に共存できることに注意してください。
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_CONTINUE_NEEDED major_status and provides the service's TGT in its output_token. The service sends the output_token to the client.
サービスは入力_トークン議論としてGSS_Accept_秒_文脈()に容認されたトークンを通過します。(それは、TGTを求めてそれが要求であると認めます)。 (現在のケルベロスV5がそのような要求を表すためにイントラプロトコルメカニズムを全く定義しないことに注意してください。) GSS_Accept_秒_文脈()は、CONTINUE_が必要としたGSS_に主要な_状態を返して、出力_トークンにサービスのTGTを提供します。 サービスは出力_トークンをクライアントに送ります。
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_COMPLETE return major_status. The client sends the output_token to the service.
クライアントは入力_トークン議論としてGSS_Init_秒_文脈()の継続に容認されたトークンを通過します。 GSS_Init_秒_文脈()は、ケルベロス認証サーバに容認されたサービスTGTをキャッシュして、サービスチケット要求の一部としてそれを使用します、文脈に関連して主要な返されたサービスチケットとセッションを保存して。 GSS_Init_秒_文脈()は、ケルベロスでフォーマットされた固有識別文字を築き上げて、GSS_COMPLETEリターン少佐_状態に伴う出力_トークンでそれを返します。 クライアントは出力_トークンをサービスに送ります。
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_COMPLETE.
サービスは入力_トークン議論としてGSS_Accept_秒_文脈()への継続呼び出しに容認されたトークンを通過します。 GSS_Accept_秒_文脈()は、固有識別文字について確かめて、クライアントの認証された名前をサービスに提供して、主要な_状態GSS_COMPLETEを返します。
GSS_Sign(), GSS_Verify(), GSS_Seal(), and GSS_Unseal() as above.
GSS_Sign()、GSS_Verify()、GSS_Seal()、および上のGSS_Unseal()。
3.3. X.509 Authentication Framework
3.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ディレクトリAuthentication Frameworkと一致した公開鍵メカニズムに関連して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_信用()呼び出しは資格証明書構造を確立します。
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 signatures 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_を取得するディレクトリについて査問する秒_文脈()と呼ぶ、(有効にする、)、その結果サービスの公開鍵を集める公開鍵証明書のチェーン。 証明書合法化操作は適当な署名が信じられた当局によって適用されて、それらの証明書が呼吸が絶えていないことを決定します。 GSS_Init_秒_文脈()は、文脈で1メッセージあたりの保護操作における使用のための秘密鍵を生成して、サービスの公開鍵の下でその秘密鍵を暗号化します。
The enciphered secret key, along with an authenticator quantity
固有識別文字量に伴う暗号化された秘密鍵
Linn [Page 44] RFC 1508 Generic Security Interface September 1993
リン[44ページ]RFC1508ジェネリックセキュリティは1993年9月に連結します。
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.
クライアントの秘密鍵と契約して、出力_トークンにGSS_Init_秒_文脈()から含まれています。 また、クライアントに対するサービスから導く証明書チェーンから成って、出力_トークンは証明経路を運びます。 異形アプローチはこのクライアントによって断言されることの代わりにサービスで実行されるべき経路解決を延期するでしょう。 クライアントアプリケーションは出力_トークンをサービスに送ります。
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_秒_文脈()に容認されたトークンを通過します。 GSS_Accept_秒_文脈()は、証明経路を有効にして、その結果クライアントの分類名とクライアントの公開鍵の間の公認された結合を決定します。 その公開鍵を考えて、GSS_Accept_秒_文脈()は、入力_トークンの固有識別文字量を処理して、クライアントの秘密鍵が入力_トークンに署名するのに使用されたことを確かめることができます。 ここに、クライアントはサービスに認証されます。 サービスが暗号化された秘密鍵がそれに提供した暗号文の解読に秘密鍵を使用する、-、文脈におけるメッセージ保護操作。
The client calls GSS_Sign() or GSS_Seal() 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_Verify() and GSS_Unseal() calls.
クライアントは、データメッセージにGSS_Sign()かGSS_をSeal()と呼びます。(それは、通報認証、保全、および(任意)の秘密性施設をそのメッセージに適用します)。 サービスは文脈の対応するGSS_Verify()を実行するために主要な共有秘密キーを使用します、そして、GSS_Unseal()は呼びます。
4. Related Activities
4. 関連活動
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 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; such bindings for the C language are available in an associated RFC.
具体的な言語結合がGSS-APIが採用していることになっているプログラミング環境に必要です。 C言語のためのそのような結合は関連RFCで利用可能です。
Linn [Page 45] RFC 1508 Generic Security Interface September 1993
リン[45ページ]RFC1508ジェネリックセキュリティは1993年9月に連結します。
5. Acknowledgments
5. 承認
This proposal is the result of a collaborative effort. Acknowledgments are due to the many members of the IETF Security Area Advisory Group (SAAG) and the Common Authentication Technology (CAT) Working Group for their contributions at meetings and by electronic mail. Acknowledgments are also due to Kannan Alagappan, Doug Barlow, Bill Brown, Cliff Kahn, Charlie Kaufman, Butler Lampson, Richard Pitkin, Joe Tardo, and John Wray of Digital Equipment Corporation, and John Carr, John Kohl, Jon Rochlis, Jeff Schiller, and Ted T'so of MIT and Project Athena. Joe Pato and Bill Sommerfeld of HP/Apollo, Walt Tuvell of OSF, and Bill Griffith and Mike Merritt of AT&T, provided inputs which helped to focus and clarify directions. Precursor work by Richard Pitkin, presented to meetings of the Trusted Systems Interoperability Group (TSIG), helped to demonstrate the value of a generic, mechanism-independent security service API.
この提案は共同努力の結果です。 承認はミーティングにおける電子メールによる彼らの貢献のためのIETF Security Area Advisory Group(SAAG)とCommon Authentication Technology(CAT)作業部会の多くのメンバーのためです。 承認はKannan Alagappan、ダグ・バーロウ、ビル・ブラウン、クリフ・カーン、チャーリー・カウフマン、バトラーランプソン、リチャード・ピトキン、ジョーTardo、DECのジョン・レイ、ジョン・カー、ジョン・コール、ジョンRochlis、ジェフ・シラー、MITのテッドT'so、およびProjectアテーナーのもためです。 HP/アポロのジョー・パトとビル・ゾンマーフェルト(AT&TのOSFのウォルトTuvell、ビル・グリフィス、およびマイク・メリット)は、方向の焦点を合わせて、はっきりさせるのを助けた入力を、提供しました。 Trusted Systems Interoperability Group(TSIG)のミーティングに紹介されたリチャード・ピトキンによる先駆仕事は、ジェネリック(メカニズムから独立しているセキュリティー・サービスAPI)の値を示すのを助けました。
6. Security Considerations
6. セキュリティ問題
Security issues are discussed throughout this memo.
このメモ中で安全保障問題について議論します。
7. Author's Address
7. 作者のアドレス
John Linn Geer Zolot Associates One Main St. Cambridge, MA 02142 USA
ジョンリンイェールZolotは主な1つの聖MA02142ケンブリッジ(米国)を関連づけます。
Phone: +1 617.374.3700 Email: Linn@gza.com
以下に電話をしてください。 +1 617.374 .3700 メール: Linn@gza.com
Linn [Page 46] RFC 1508 Generic Security Interface September 1993
リン[46ページ]RFC1508ジェネリックセキュリティは1993年9月に連結します。
APPENDIX A
付録A
PACS AND AUTHORIZATION SERVICES
PACSと承認サービス
Consideration has been given to modifying the GSS-API service interface to recognize and manipulate Privilege Attribute Certificates (PACs) as in ECMA 138, carrying authorization data as a side effect of establishing a security context, but no such modifications have been incorporated at this time. This appendix provides rationale for this decision and discusses compatibility alternatives between PACs and the GSS-API which do not require that PACs be made visible to GSS-API callers.
そのような変更だけがこのときセキュリティ文脈を確立する副作用として承認データを運ぶECMA138に組み込んでいないのでPrivilege Attribute Certificates(PACs)を認識して、操作するようにGSS-APIサービスインタフェースを変更することに対して考慮を払いました。 この付録は、PACsをGSS-API訪問者にとって目に見えるようにするのを必要としないPACsとGSS-APIの間でこの決定に原理を提供して、互換性代替手段について議論します。
Existing candidate mechanism types such as Kerberos and X.509 do not incorporate PAC manipulation features, and exclusion of such mechanisms from the set of candidates equipped to fully support the GSS-API seems inappropriate. Inclusion (and GSS-API visibility) of a feature supported by only a limited number of mechanisms could encourage the development of ostensibly portable applications which would in fact have only limited portability.
ケルベロスやX.509などの既存の候補メカニズムタイプはPAC操作機能を取り入れません、そして、GSS-APIを完全にサポートするために持たせる候補のセットからのそのようなメカニズムの除外は不適当に見えます。 限られた数のメカニズムだけによってサポートされた特徴の包含(そして、GSS-API目に見えること)は事実上、移植性を制限するだけであった表面上携帯用のアプリケーションの開発を奨励するかもしれません。
The status quo, in which PACs are not visible across the GSS-API interface, does not preclude implementations in which PACs are carried transparently, within the tokens defined and used for certain mech_types, and stored within peers' credentials and context-level data structures. While invisible to API callers, such PACs could be used by operating system or other local functions as inputs in the course of mediating access requests made by callers. This course of action allows dynamic selection of PAC contents, if such selection is administratively-directed rather than caller-directed.
現状(PACsはGSS-APIインタフェースの向こう側に目に見えない)はPACsが透過的に運ばれる実装を排除しません、あるmech_タイプに定義されて、使用されて、同輩の資格証明書と文脈レベルデータ構造の中に保存されたトークンの中で。 API訪問者にとって目に見えない間、仲介の間の入力が訪問者によってされた要求にアクセスするとき、オペレーティングシステムか他の地方の機能はそのようなPACsを使用できました。 訪問者によって指示されているというよりむしろそのような選択が行政上向けられるなら、この行動はPACコンテンツのダイナミックな選択を許します。
In a distributed computing environment, authentication must span different systems; the need for such authentication provides motivation for GSS-API definition and usage. Heterogeneous systems in a network can intercommunicate, with globally authenticated names comprising the common bond between locally defined access control policies. Access control policies to which authentication provides inputs are often local, or specific to particular operating systems or environments. If the GSS-API made particular authorization models visible across its service interface, its scope of application would become less general. The current GSS-API paradigm is consistent with the precedent set by Kerberos, neither defining the interpretation of authorization-related data nor enforcing access controls based on such data.
分散コンピューティング環境では、認証は異系統にかからなければなりません。 そのような認証の必要性はGSS-API定義と用法に関する動機を提供します。 ネットワークにおける多相系は通信し合われることができます、局所的に定義されたアクセス制御方針の間の一般的な債券を包括する名前がグローバルに認証されていた状態で。 認証が入力を提供するアクセス制御方針は、特定のオペレーティングシステムか環境にしばしばローカルである、または特定です。 特定の承認モデルがGSS-APIでサービスインタフェースの向こう側に目に見えるようになるなら、適用範囲は、より一般的でなくなるでしょうに。 現在のGSS-APIパラダイムはケルベロスで先例セットと一致しています、どちらも承認関連のデータの解釈を定義しないで、そのようなデータに基づくアクセス制御を実施して。
The GSS-API is a general interface, whose callers may reside inside or outside any defined TCB or NTCB boundaries. Given this characteristic, it appears more realistic to provide facilities which
GSS-APIは一般的なインタフェースです。その訪問者は境界や中、または、どんな定義されたTCBやNTCB境界の外にも住むかもしれません。 この特性を考えて、便宜を与えるのが、より現実的に見える、どれ
Linn [Page 47] RFC 1508 Generic Security Interface September 1993
リン[47ページ]RFC1508ジェネリックセキュリティは1993年9月に連結します。
provide "value-added" security services to its callers than to offer facilities which enforce restrictions on those callers. Authorization decisions must often be mediated below the GSS-API level in a local manner against (or in spite of) applications, and cannot be selectively invoked or omitted at those applications' discretion. Given that the GSS-API's placement prevents it from providing a comprehensive solution to the authorization issue, the value of a partial contribution specific to particular authorization models is debatable.
訪問者への「付加価値が付く」セキュリティー・サービスを提供してください。制限にそれらの訪問者に押しつけるものを施設に提供するより。 それらのアプリケーションの裁量で選択的に承認決定は、(or in spite of)アプリケーションに対してGSS-APIレベルの下でしばしばローカルの方法で調停しなければならなくて、呼び出すことができないか、省略できません。 GSS-APIのプレースメントが、それが承認問題の包括的解決を提供するのを防ぐなら、特定の承認モデルに、特定の部分的な貢献の値は論争の余地があります。
APPENDIX B
付録B
MECHANISM-INDEPENDENT TOKEN FORMAT
メカニズムから独立しているトークン形式
This appendix 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. Use of this format (with ASN.1-encoded data elements represented in BER, constrained in the interests of parsing simplicity to the Distinguished Encoding Rule (DER) BER subset defined in X.509, clause 8.7) is recommended to the designers of GSS-API implementations based on various mechanisms, so that tokens can be interpreted unambiguously at GSS-API peers. There is no requirement that the mechanism-specific innerContextToken, innerMsgToken, and sealedUserData data elements be encoded in ASN.1 BER.
この付録はGSS-API文脈設立系列の初期のトークンのためのメカニズムから独立しているレベルの要約表現を指定します、その文脈で使用されるためにメカニズムタイプに関する識別子を取り入れて。 この形式(X.509で定義されたDistinguished Encoding Rule(DER)BER部分集合に簡単さを分析することのために抑制されたBERに表されたASN.1によってコード化されたデータ要素による8.7番目の節)の使用は様々なメカニズムに基づくGSS-API実行のデザイナーに推薦されます、明白にGSS-API同輩でトークンを解釈できるように。 メカニズム特有のinnerContextToken、innerMsgToken、およびsealedUserDataデータ要素がASN.1BERでコード化されるという要件が全くありません。
-- optional top-level token definitions to
-- frame different mechanisms
-- 任意のトップレベルトークン定義、--異なったメカニズムを縁どってください
GSS-API DEFINITIONS ::=
GSS-API定義:、:=
BEGIN
始まってください。
MechType ::= OBJECT IDENTIFIER
-- data structure definitions
MechType:、:= OBJECT IDENTIFIER--データ構造定義
-- callers must be able to distinguish among
-- InitialContextToken, SubsequentContextToken,
-- PerMsgToken, and SealedMessage data elements
-- based on the usage in which they occur
-- 訪問者は--InitialContextToken、SubsequentContextToken--PerMsgToken、およびSealedMessageデータ要素の中で区別できなければなりません--それらが起こる用法に基づいています。
InitialContextToken ::=
-- option indication (delegation, etc.) indicated within
-- mechanism-specific token
[APPLICATION 0] IMPLICIT SEQUENCE {
thisMech MechType,
innerContextToken ANY DEFINED BY thisMech
InitialContextToken:、:= -- 中で示された状態で指示(委譲など)をゆだねてください--、メカニズム特有のトークン[APPLICATION0]IMPLICIT SEQUENCE、thisMech MechType、innerContextToken、どんなDEFINED BY thisMech
Linn [Page 48] RFC 1508 Generic Security Interface September 1993
リン[48ページ]RFC1508ジェネリックセキュリティは1993年9月に連結します。
-- contents mechanism-specific
}
-- コンテンツメカニズム詳細
SubsequentContextToken ::= innerContextToken ANY
-- interpretation based on predecessor InitialContextToken
SubsequentContextToken:、:= innerContextToken、少しも、解釈は前任者InitialContextTokenを基礎づけました。
PerMsgToken ::=
-- as emitted by GSS_Sign and processed by GSS_Verify
innerMsgToken ANY
PerMsgToken:、:= -- GSS_Signによって放たれていて、何でもGSS_Verify innerMsgTokenによって処理されます。
SealedMessage ::=
-- as emitted by GSS_Seal and processed by GSS_Unseal
-- includes internal, mechanism-defined indicator
-- of whether or not encrypted
sealedUserData ANY
SealedMessage:、:= -- 放たれている、GSS_Unsealによって_Sealであって処理されたGSS--内部の、そして、メカニズムで定義されたインディケータを含んでいます--、少しもsealedUserDataを暗号化します。
END
終わり
APPENDIX C
付録C
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メカニズムのその後の記述で予期されます。
Use of the approach defined in Appendix B of this specification, applying a mechanism type tag to the InitialContextToken, is required.
メカニズムタイプタグをInitialContextTokenに適用して、この仕様のAppendix Bで定義されたアプローチの使用が必要です。
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メッセージあたりの保護サービスを提供するメカニズムが少なくとも再生検出と配列サービスの1つを提供することが強く勧められます、後者のどちらも提供しないメカニズムが、ある候補訪問者プロトコルの認識された要件を満たさないとき。
Linn [Page 49]
リン[49ページ]
一覧
スポンサーリンク
