RFC2203 日本語訳
2203 RPCSEC_GSS Protocol Specification. M. Eisler, A. Chiu, L. Ling. September 1997. (Format: TXT=50937 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Eisler
Request for Comments: 2203 A. Chiu
Category: Standards Track L. Ling
September 1997
コメントを求めるワーキンググループM.アイスラー要求をネットワークでつないでください: 2203年のA.チウカテゴリ: 標準化過程L.御柳もどきの1997年9月
RPCSEC_GSS Protocol Specification
RPCSEC_GSSプロトコル仕様
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Abstract
要約
This memo describes an ONC/RPC security flavor that allows RPC protocols to access the Generic Security Services Application Programming Interface (referred to henceforth as GSS-API).
このメモはRPCプロトコルがGeneric Security Services Application Programming Interface(今後は、GSS-APIに言及される)にアクセスできるONC/RPCセキュリティ風味について説明します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. The ONC RPC Message Protocol . . . . . . . . . . . . . . . . . 2
3. Flavor Number Assignment . . . . . . . . . . . . . . . . . . . 3
4. New auth_stat Values . . . . . . . . . . . . . . . . . . . . . 3
5. Elements of the RPCSEC_GSS Security Protocol . . . . . . . . . 3
5.1. Version Selection . . . . . . . . . . . . . . . . . . . . . 5
5.2. Context Creation . . . . . . . . . . . . . . . . . . . . . . 5
5.2.1. Mechanism and QOP Selection . . . . . . . . . . . . . . . 5
5.2.2. Context Creation Requests . . . . . . . . . . . . . . . . 6
5.2.3. Context Creation Responses . . . . . . . . . . . . . . . . 8
5.2.3.1. Context Creation Response - Successful Acceptance . . . 8
5.2.3.1.1. Client Processing of Successful Context Creation
Responses . . . . . . . . . . . . . . . . . . . . . . 9
5.2.3.2. Context Creation Response - Unsuccessful Cases . . . . . 9
5.3. RPC Data Exchange . . . . . . . . . . . . . . . . . . . . 10
5.3.1. RPC Request Header . . . . . . . . . . . . . . . . . . . 10
5.3.2. RPC Request Data . . . . . . . . . . . . . . . . . . . . 11
5.3.2.1. RPC Request Data - No Data Integrity . . . . . . . . . 11
5.3.2.2. RPC Request Data - With Data Integrity . . . . . . . . 11
5.3.2.3. RPC Request Data - With Data Privacy . . . . . . . . . 12
5.3.3. Server Processing of RPC Data Requests . . . . . . . . . 12
5.3.3.1. Context Management . . . . . . . . . . . . . . . . . . 12
5.3.3.2. Server Reply - Request Accepted . . . . . . . . . . . 14
5.3.3.3. Server Reply - Request Denied . . . . . . . . . . . . 15
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 ONC RPCメッセージプロトコル. . . . . . . . . . . . . . . . . 2 3。 風味数の課題. . . . . . . . . . . . . . . . . . . 3 4。 新しいauth_スタットValues. . . . . . . . . . . . . . . . . . . . . 3 5。 RPCSEC_GSSセキュリティの要素は.35.1について議定書の中で述べます。 バージョン選択. . . . . . . . . . . . . . . . . . . . . 5 5.2。 文脈作成. . . . . . . . . . . . . . . . . . . . . . 5 5.2.1。 メカニズムとQOP選択. . . . . . . . . . . . . . . 5 5.2.2。 文脈作成要求. . . . . . . . . . . . . . . . 6 5.2.3。 文脈作成応答. . . . . . . . . . . . . . . . 8 5.2.3.1。 文脈作成、応答--うまくいっている承認、.85.2 .3 .1 .1。 うまくいっている文脈作成応答. . . . . . . . . . . . . . . . . . . . . . 9 5.2.3.2のクライアント処理。 文脈作成応答--失敗のケース. . . . . 9 5.3。 RPCデータ交換. . . . . . . . . . . . . . . . . . . . 10 5.3.1。 RPCはヘッダー. . . . . . . . . . . . . . . . . . . 10 5.3.2を要求します。 RPC要求データ. . . . . . . . . . . . . . . . . . . . 11 5.3.2.1。 RPCはデータを要求します--いいえデータの保全. . . . . . . . . 11 5.3.2、.2。 RPCはデータの保全. . . . . . . . 11 5.3.2で.3にデータを要求します。 RPCはデータプライバシー. . . . . . . . . 12 5.3.3でデータを要求します。 RPCデータ要求. . . . . . . . . 12 5.3.3.1のサーバ処理。 文脈管理. . . . . . . . . . . . . . . . . . 12 5.3.3.2。 サーバ回答--要求は.145.3に.3に.3を受け入れました。 サーバ回答--.15が否定したよう要求してください。
Eisler, et. al. Standards Track [Page 1] RFC 2203 RPCSEC_GSS Protocol Specification September 1997
etアイスラー、アル。 標準化過程[1ページ]RFC2203RPCSEC_GSSは仕様1997年9月に議定書を作ります。
5.3.3.4. Mapping of GSS-API Errors to Server Responses . . . . 16 5.3.3.4.1. GSS_GetMIC() Failure . . . . . . . . . . . . . . . . 16 5.3.3.4.2. GSS_VerifyMIC() Failure . . . . . . . . . . . . . . 16 5.3.3.4.3. GSS_Unwrap() Failure . . . . . . . . . . . . . . . . 16 5.3.3.4.4. GSS_Wrap() Failure . . . . . . . . . . . . . . . . . 16 5.4. Context Destruction . . . . . . . . . . . . . . . . . . . 17 6. Set of GSS-API Mechanisms . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . 18 7.1. Privacy of Call Header . . . . . . . . . . . . . . . . . . 18 7.2. Sequence Number Attacks . . . . . . . . . . . . . . . . . 18 7.2.1. Sequence Numbers Above the Window . . . . . . . . . . . 18 7.2.2. Sequence Numbers Within or Below the Window . . . . . . 18 7.3. Message Stealing Attacks . . . . . . . . . . . . . . . . . 19 Appendix A. GSS-API Major Status Codes . . . . . . . . . . . . . 20 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
5.3.3.4. GSS-API誤りは.1にサーバ応答. . . . 16 5.3.3.4に写像されます。 GSS_GetMIC()失敗. . . . . . . . . . . . . . . . 16 5.3.3.4.2。 GSS_VerifyMIC()失敗. . . . . . . . . . . . . . 16 5.3.3.4.3。 GSS_は.4に()失敗. . . . . . . . . . . . . . . . 16 5.3.3.4を開けます。 GSS_包装()の故障. . . . . . . . . . . . . . . . . 16 5.4。 文脈破壊. . . . . . . . . . . . . . . . . . . 17 6。 GSS-APIメカニズム. . . . . . . . . . . . . . . . . 17 7のセット。 セキュリティ問題. . . . . . . . . . . . . . . . . . 18 7.1。 呼び出しヘッダー. . . . . . . . . . . . . . . . . . 18 7.2のプライバシー。 一連番号は.1に.187.2を攻撃します。 窓. . . . . . . . . . . 18 7.2の.2を超えた一連番号。 窓か窓. . . . . . 18 7.3の下の一連番号。 メッセージ横取りは.19の付録のA.のGSS-APIの主要なステータスコード. . . . . . . . . . . . . 20承認. . . . . . . . . . . . . . . . . . . . . . . . 22作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . 23を攻撃します。
1. Introduction
1. 序論
This document describes the protocol used by the RPCSEC_GSS security flavor. Security flavors have been called authentication flavors for historical reasons. This memo recognizes that there are two other security services besides authentication, integrity, and privacy, and so defines a new RPCSEC_GSS security flavor.
このドキュメントはRPCSEC_GSSセキュリティ風味によって使用されるプロトコルについて説明します。 セキュリティ風味は歴史的な理由で認証特色と呼ばれました。 他の2つのセキュリティー・サービスが認証、保全、およびプライバシー以外にあると認めるので、このメモは、新しいRPCSEC_GSSセキュリティ風味を定義します。
The protocol is described using the XDR language [Srinivasan-xdr]. The reader is assumed to be familiar with ONC RPC and the security flavor mechanism [Srinivasan-rpc]. The reader is also assumed to be familiar with the GSS-API framework [Linn]. The RPCSEC_GSS security flavor uses GSS-API interfaces to provide security services that are independent of the underlying security mechanism.
プロトコルは、XDR言語[Srinivasan-xdr]を使用することで説明されます。 読者がONC RPCとセキュリティ風味メカニズム[Srinivasan-rpc]によく知られさせると思われます。 また、読者がGSS-APIフレームワーク[リン]によく知られさせると思われます。 RPCSEC_GSSセキュリティ風味は、基本的なセキュリティー対策から独立しているセキュリティー・サービスを提供するのにGSS-APIインタフェースを使用します。
2. The ONC RPC Message Protocol
2. ONC RPCメッセージプロトコル
This memo refers to the following XDR types of the ONC RPC protocol, which are described in the document entitled Remote Procedure Call Protocol Specification Version 2 [Srinivasan-rpc]:
このメモはONC RPCプロトコルの以下のXDRタイプを差し向けて、どれがドキュメントで説明されるかがプロトコルSpecificationバージョン2[Srinivasan-rpc]のRemote Procedure Callに権利を与えました:
msg_type
reply_stat
auth_flavor
accept_stat
reject_stat
auth_stat
opaque_auth
rpc_msg
call_body
reply_body
msg_タイプ回答_スタットauth_風味は_スタットのauth_スタットの不透明な_auth rpc_msg呼び出し_ボディー廃棄物_スタット回答_ボディーを受け入れます。
Eisler, et. al. Standards Track [Page 2] RFC 2203 RPCSEC_GSS Protocol Specification September 1997
etアイスラー、アル。 標準化過程[2ページ]RFC2203RPCSEC_GSSは仕様1997年9月に議定書を作ります。
accepted_reply
rejected_reply
受け入れられた_回答は_回答を拒絶しました。
3. Flavor Number Assignment
3. 風味数の課題
The RPCSEC_GSS security flavor has been assigned the value of 6:
RPCSEC_GSSセキュリティ風味に6の値を割り当ててあります:
enum auth_flavor {
...
RPCSEC_GSS = 6 /* RPCSEC_GSS security flavor */
};
enum auth_風味…RPCSEC_GSS=6/*RPCSEC_GSSセキュリティ風味*/。
4. New auth_stat Values
4. 新しいauth_スタットValues
RPCSEC_GSS requires the addition of two new values to the auth_stat enumerated type definition:
RPCSEC_GSSはauth_スタット列挙型定義に2つの新しい値の追加を必要とします:
enum auth_stat {
...
/*
* RPCSEC_GSS errors
*/
RPCSEC_GSS_CREDPROBLEM = 13,
RPCSEC_GSS_CTXPROBLEM = 14
};
enum auth_スタット、… /**RPCSEC_GSS誤り*/RPCSEC_GSS_CREDPROBLEMは13、RPCSEC_GSS_CTXPROBLEM=14と等しいです。
The descriptions of these two new values are defined later in this memo.
これらの2つの新しい値の記述は後でこのメモで定義されます。
5. Elements of the RPCSEC_GSS Security Protocol
5. RPCSEC_GSSセキュリティプロトコルのElements
An RPC session based on the RPCSEC_GSS security flavor consists of three phases: context creation, RPC data exchange, and context destruction. In the following discussion, protocol elements for these three phases are described.
RPCSEC_GSSセキュリティ風味に基づくRPCセッションは三相から成ります: 文脈作成、RPCデータ交換、および文脈破壊。 以下の議論では、これらの三相のためのプロトコル要素は説明されます。
The following description of the RPCSEC_GSS protocol uses some of the definitions within XDR language description of the RPC protocol.
RPCSEC_GSSプロトコルの以下の記述はRPCプロトコルのXDR言語記述の中で定義のいくつかを使用します。
Context creation and destruction use control messages that are not dispatched to service procedures registered by an RPC server. The program and version numbers used in these control messages are the same as the RPC service's program and version numbers. The procedure number used is NULLPROC (zero). A field in the credential information (the gss_proc field which is defined in the rpc_gss_cred_t structure below) specifies whether a message is to be interpreted as a control message or a regular RPC message. If this field is set to RPCSEC_GSS_DATA, no control action is implied; in
文脈作成と破壊はRPCサーバによって示されたサービス手順に派遣されないコントロールメッセージを使用します。数がこれらのコントロールメッセージで使用したプログラムとバージョンはRPCサービスのプログラムとバージョン番号と同じです。 数が用いた手順はNULLPROC(ゼロ)です。 資格証明情報(以下のrpc_gss_信用_t構造で定義されるgss_proc分野)の分野は、メッセージがコントロールメッセージか通常のRPCメッセージとして解釈されるかどうかことであると指定します。 この分野がRPCSEC_GSS_DATAに設定されるなら、コントロール動作は全く含意されません。 コネ
Eisler, et. al. Standards Track [Page 3] RFC 2203 RPCSEC_GSS Protocol Specification September 1997
etアイスラー、アル。 標準化過程[3ページ]RFC2203RPCSEC_GSSは仕様1997年9月に議定書を作ります。
this case, it is a regular data message. If this field is set to any other value, a control action is implied. This is described in the following sections.
このケースであり、それは通常のデータメッセージです。 この分野がいかなる他の値にも設定されるなら、コントロール動作は含意されます。 これは以下のセクションで説明されます。
Just as with normal RPC data exchange messages, the transaction identifier (the xid field in struct rpc_msg), should be set to unique values on each call for context creation and context destruction.
ちょうど正常なRPCなら、データ交換メッセージ(トランザクション識別子(struct rpc_msgのxid分野))は文脈作成と文脈破壊のための各呼び出しのユニークな値に設定されるべきです。
The following definitions are used for describing the protocol.
以下の定義は、プロトコルについて説明するのに使用されます。
/* RPCSEC_GSS control procedures */
/*RPCSEC_GSSコントロール手順*/
enum rpc_gss_proc_t {
RPCSEC_GSS_DATA = 0,
RPCSEC_GSS_INIT = 1,
RPCSEC_GSS_CONTINUE_INIT = 2,
RPCSEC_GSS_DESTROY = 3
};
enum rpc_gss_は_tをprocします。RPCSEC_GSS_DATAは0、RPCSEC_GSS_INIT=1、RPCSEC_GSS_CONTINUE_INIT=2、RPCSEC_GSS_DESTROY=3と等しいです。
/* RPCSEC_GSS services */
/*RPCSEC_GSSサービス*/
enum rpc_gss_service_t {
/* Note: the enumerated value for 0 is reserved. */
rpc_gss_svc_none = 1,
rpc_gss_svc_integrity = 2,
rpc_gss_svc_privacy = 3
};
enum rpc_gss_サービス_t{ /*注意: 0のための列挙された値は予約されています。 *_/rpc_gss_svcでないなにも=1、rpc_gss_svc_保全=2、rpc_gss_svc_プライバシー=3};
/* Credential */
/*資格証明書*/
/*
* Note: version 0 is reserved for possible future
* definition of a version negotiation protocol
*
*/
#define RPCSEC_GSS_VERS_1 1
/**注意: バージョン0は*バージョン交渉プロトコル**/#の定義がRPCSEC_GSS_VERS_1 1を定義する可能な未来に予約されます。
struct rpc_gss_cred_t {
union switch (unsigned int version) { /* version of
RPCSEC_GSS */
case RPCSEC_GSS_VERS_1:
struct {
rpc_gss_proc_t gss_proc; /* control procedure */
unsigned int seq_num; /* sequence number */
rpc_gss_service_t service; /* service used */
opaque handle<>; /* context handle */
} rpc_gss_cred_vers_1_t;
信用..組合..スイッチ..未署名..バージョン..バージョン..ケース..コントロール..手順..未署名..一連番号..サービス..サービス..サービス..使用..不透明..ハンドル..文脈..ハンドル..信用
Eisler, et. al. Standards Track [Page 4] RFC 2203 RPCSEC_GSS Protocol Specification September 1997
etアイスラー、アル。 標準化過程[4ページ]RFC2203RPCSEC_GSSは仕様1997年9月に議定書を作ります。
}
};
} };
/* Maximum sequence number value */
/*最大の一連番号値*/
#define MAXSEQ 0x80000000
#MAXSEQ0x80000000を定義してください。
5.1. Version Selection
5.1. バージョン選択
This document defines just one protocol version (RPCSEC_GSS_VERS_1). The client should assume that the server supports RPCSEC_GSS_VERS_1 and issue a Context Creation message (as described in the section RPCSEC_GSS_VERS_1, the RPC response will have a reply_stat of MSG_DENIED, a rejection status of AUTH_ERROR, and an auth_stat of AUTH_REJECTED_CRED.
このドキュメントはちょうど1つのプロトコルバージョン(RPCSEC_GSS_VERS_1)を定義します。 クライアントは、サーバが、RPCSEC_GSS_VERS_1と問題がContext Creationメッセージであるとサポートするのに就くべきです。(セクションでRPCSEC_GSS_VERS_1について説明するので、RPC応答には、エムエスジー_DENIEDの回答_スタット、AUTH_ERRORの拒絶状態、およびAUTH_REJECTED_CREDのauth_スタットがあるでしょう。
5.2. Context Creation
5.2. 文脈作成
Before RPC data is exchanged on a session using the RPCSEC_GSS flavor, a context must be set up between the client and the server. Context creation may involve zero or more RPC exchanges. The number of exchanges depends on the security mechanism.
セッションのときにRPCSEC_GSS風味を使用することでRPCデータを交換する前に、クライアントとサーバの間で文脈をセットアップしなければなりません。文脈作成は、RPCが交換するゼロか以上を伴うかもしれません。 交換の数はセキュリティー対策に依存します。
5.2.1. Mechanism and QOP Selection
5.2.1. メカニズムとQOP選択
There is no facility in the RPCSEC_GSS protocol to negotiate GSS-API mechanism identifiers or QOP values. At minimum, it is expected that implementations of the RPCSEC_GSS protocol provide a means to:
GSS-APIメカニズム識別子かQOP値を交渉するために、RPCSEC_GSSプロトコルには施設が全くありません。 最小限では、RPCSEC_GSSプロトコルの実装が手段を以下に提供すると予想されます。
* specify mechanism identifiers, QOP values, and RPCSEC_GSS
service values on the client side, and to
* そしてメカニズム識別子、QOP値、およびクライアント側のRPCSEC_GSSサービス値を指定してください。
* enforce mechanism identifiers, QOP values, and RPCSEC_GSS
service values on a per-request basis on the server side.
* サーバ側の1要求あたり1個のベースでメカニズム識別子、QOP値、およびRPCSEC_GSSサービス値を実施してください。
It is necessary that above capabilities exist so that applications have the means to conform the required set of required set of <mechanism, QOP, service> tuples (See the section entitled Set of GSS-API Mechanisms). An application may negotiate <mechanism, QOP, service> selection within its protocol or via an out of band protocol. Hence it may be necessary for RPCSEC_GSS implementations to provide programming interfaces for the specification and enforcement of <mechanism, QOP, service>.
アプリケーションには、そんなに上では、能力が存在するのが必要であるので、必要なセットの必要なセットの<メカニズムを従わせる手段があります、QOP、サービス>tuples(セクションがGSS-API MechanismsのSetの権利を与えられるのを見てください)。 を通してまたは、アプリケーションがプロトコルの中で<メカニズム、QOP、サービス>選択を交渉するかもしれない、バンドから、議定書を作ってください。 したがって、RPCSEC_GSS実装が<メカニズムの仕様と実施にプログラミングインターフェースを提供するのが必要であるかもしれません、QOP、サービス>。
Additionally, implementations may depend on negotiation schemes constructed as pseudo-mechanisms under the GSS-API. Because such schemes are below the GSS-API layer, the RPCSEC_GSS protocol, as specified in this document, can make use of them.
さらに、実装は疑似メカニズムとしてGSS-APIの下で構成された交渉体系によるかもしれません。 そのような体系がGSS-API層の下にあるので、本書では指定されるRPCSEC_GSSプロトコルは彼らを利用できます。
Eisler, et. al. Standards Track [Page 5] RFC 2203 RPCSEC_GSS Protocol Specification September 1997
etアイスラー、アル。 標準化過程[5ページ]RFC2203RPCSEC_GSSは仕様1997年9月に議定書を作ります。
5.2.2. Context Creation Requests
5.2.2. 文脈作成要求
The first RPC request from the client to the server initiates context creation. Within the RPC message protocol's call_body structure, rpcvers is set to 2. prog and vers are always those for the service being accessed. The proc is always set to NULLPROC (zero).
RPCがクライアントからサーバまで要求する1番目は文脈作成を開始します。 RPCメッセージプロトコルの呼び出し_ボディー構造の中では、rpcversは2progに用意ができています、そして、アクセスされていて、いつもversはサービスのためのそれらです。 procはいつもNULLPROC(ゼロ)に用意ができています。
Within the RPC message protocol's cred structure, flavor is set to RPCSEC_GSS (6). The opaque data of the cred structure (the body field) constituting the credential encodes the rpc_gss_cred_t structure defined previously.
RPCメッセージプロトコルの信用構造の中では、風味はRPCSEC_GSS(6)に設定されます。 資格証明書を構成する信用構造(ボディー分野)の不明瞭なデータは以前に定義されたrpc_gss_信用_t構造をコード化します。
The values of the fields contained in the rpc_gss_cred_t structure are set as follows. The version field is set to the version of the RPCSEC_GSS protocol the client wants to use. The remainder of this memo documents version RPCSEC_GSS_VERS_1 of RPCSEC_GSS, and so the version field would be set to RPCSEC_GSS_VERS_1. The gss_proc field must be set to RPCSEC_GSS_INIT for the first creation request. In subsequent creation requests, the gss_proc field must be set to RPCSEC_GSS_CONTINUE_INIT. In a creation request, the seq_num and service fields are undefined and both must be ignored by the server. In the first creation request, the handle field is NULL (opaque data of zero length). In subsequent creation requests, handle must be equal to the value returned by the server. The handle field serves as the identifier for the context, and will not change for the duration of the context, including responses to RPCSEC_GSS_CONTINUE_INIT.
rpc_gss_信用_t構造に含まれた分野の値は以下の通り設定されます。 バージョン分野はクライアントが使用したがっているRPCSEC_GSSプロトコルのバージョンに設定されます。 このメモの残りがRPCSEC_GSSのバージョンRPCSEC_GSS_VERS_1を記録するので、バージョン分野はRPCSEC_GSS_VERS_1へのセットでしょう。 最初の作成要求のためにRPCSEC_GSS_INITにgss_proc分野を設定しなければなりません。 その後の作成要求では、RPCSEC_GSS_CONTINUE_INITにgss_proc分野を設定しなければなりません。 作成要求では、seq_numとサービス分野を未定義であり、サーバでともに無視しなければなりません。最初の作成要求では、ハンドル分野はNULL(ゼロ・レングスの不明瞭なデータ)です。 その後の作成要求では、ハンドルはサーバによって返された値と等しいに違いありません。ハンドル分野は、文脈のために識別子として機能して、文脈の持続時間のために変化しないでしょう、RPCSEC_GSS_CONTINUE_INITへの応答を含んでいて。
The verifier field in the RPC message header is also described by the opaque_auth structure. All creation requests have the NULL verifier (AUTH_NONE flavor with zero length opaque data).
また、RPCメッセージヘッダーの検証分野は不明瞭な_auth構造によって説明されます。 万物要求には、NULL検証(ゼロ・レングスの不明瞭なデータがあるAUTH_NONE風味)があります。
Following the verifier are the call data (procedure specific parameters). Note that the proc field of the call_body structure is set to NULLPROC, and thus normally there would be zero octets following the verifier. However, since there is no RPC data exchange during a context creation, it is safe to transfer information following the verifier. It is necessary to "overload" the call data in this way, rather than pack the GSS-API token into the RPC header, because RPC Version 2 restricts the amount of data that can be sent in the header. The opaque body of the credential and verifier fields can be each at most 400 octets long, and GSS tokens can be longer than 800 octets.
検証に続くのは、呼び出しデータ(手順の特定のパラメタ)です。 呼び出し_ボディー構造のproc分野がNULLPROCに設定されて、その結果、通常、検証に続く八重奏が全くないことに注意してください。 しかしながら、RPCデータ交換が全く文脈作成の間、ないので、検証に続く情報を移すのは安全です。 呼び出しデータがGSS-APIトークンにRPCヘッダーに詰め込むよりこのようにむしろ「積みすぎ」であることが必要です、RPCバージョン2がヘッダーで送ることができるデータ量を制限するので。 長い間、それぞれほとんどの400の八重奏には資格証明書と検証分野の不透明体があることができて、GSSトークンは800の八重奏より長い場合があります。
Eisler, et. al. Standards Track [Page 6] RFC 2203 RPCSEC_GSS Protocol Specification September 1997
etアイスラー、アル。 標準化過程[6ページ]RFC2203RPCSEC_GSSは仕様1997年9月に議定書を作ります。
The call data for a context creation request is described by the following structure for all creation requests:
文脈作成のためのデータが要求する呼び出しは万物要求のために以下の構造によって説明されます:
struct rpc_gss_init_arg {
opaque gss_token<>;
};
_struct rpc_gss_イニットarg、不透明なgss_トークン<>;、。
Here, gss_token is the token returned by the call to GSS-API's GSS_Init_sec_context() routine, opaquely encoded. The value of this field will likely be different in each creation request, if there is more than one creation request. If no token is returned by the call to GSS_Init_sec_context(), the context must have been created (assuming no errors), and there will not be any more creation requests.
ここで、gss_トークンは呼び出しで不透明にコード化されたGSS-APIのGSS_Init_秒_文脈()ルーチンに返されたトークンです。 この分野の値はそれぞれの作成要求においておそらく異なるでしょう、1つ以上の作成要求があれば。 GSS_Init_秒_文脈()への呼び出しでトークンを全く返さないなら、文脈を作成したに違いありません、そして、(誤りを全く仮定しないで)それ以上の作成要求がないでしょう。
When GSS_Init_sec_context() is called, the parameters replay_det_req_flag and sequence_req_flag must be turned off. The reasons for this are:
GSS_Init_秒_文脈()が呼ばれるとき、パラメタ再生_det_req_旗と系列_req_旗をオフにしなければなりません。 この理由は以下の通りです。
* ONC RPC can be used over unreliable transports and provides no
layer to reliably re-assemble messages. Thus it is possible for
gaps in message sequencing to occur, as well as out of order
messages.
* ONC RPCは、頼り無い輸送の上で使用できて、メッセージを確かに組み立て直すために層を全く提供しません。 したがって、メッセージ配列におけるギャップが不適切なメッセージと同様に起こるのは、可能です。
* RPC servers can be multi-threaded, and thus the order in which
GSS-API messages are signed or wrapped can be different from the
order in which the messages are verified or unwrapped, even if
the requests are sent on reliable transports.
* RPCサーバをマルチスレッド化できます、そして、その結果、GSS-APIメッセージが署名されるか、または包装されるオーダーはメッセージが確かめられるか、または開けられるオーダーと異なる場合があります、信頼できる輸送に要求を送っても。
* To maximize convenience of implementation, the order in which an
ONC RPC entity will verify the header and verify/unwrap the body
of an RPC call or reply is left unspecified.
* 実装の便利を最大にするために、ONC RPC実体がRPC呼び出しか回答のボディーをヘッダーについて確かめて、確かめるか、または開けるオーダーは不特定のままにされます。
The RPCSEC_GSS protocol provides for protection from replay attack, yet tolerates out-of-order delivery or processing of messages and tolerates dropped requests.
GSSが議定書の中で述べるRPCSEC_は反射攻撃から保護に備えて、まだメッセージの不適切な配送か処理を許容していて、下げられた要求を許容します。
Eisler, et. al. Standards Track [Page 7] RFC 2203 RPCSEC_GSS Protocol Specification September 1997
etアイスラー、アル。 標準化過程[7ページ]RFC2203RPCSEC_GSSは仕様1997年9月に議定書を作ります。
5.2.3. Context Creation Responses
5.2.3. 文脈作成応答
5.2.3.1. Context Creation Response - Successful Acceptance
5.2.3.1. 文脈作成応答--うまくいっている承認
The response to a successful creation request has an MSG_ACCEPTED response with a status of SUCCESS. The results field encodes a response with the following structure:
うまくいっている作成要求への応答には、SUCCESSの状態があるエムエスジー_ACCEPTED応答があります。 分野が以下の構造による応答をコード化するという結果:
struct rpc_gss_init_res {
opaque handle<>;
unsigned int gss_major;
unsigned int gss_minor;
unsigned int seq_window;
opaque gss_token<>;
};
struct rpc_gss_イニット_resはハンドル<>; 未署名のint gss_少佐; 未署名のint seq_窓; gss_トークン<>について不透明にするという未署名のint gss_未成年者について不透明にします。
Here, handle is non-NULL opaque data that serves as the context identifier. The client must use this value in all subsequent requests whether control messages or otherwise). The gss_major and gss_minor fields contain the results of the call to GSS_Accept_sec_context() executed by the server. The values for the gss_major field are defined in Appendix A of this document. The values for the gss_minor field are GSS-API mechanism specific and are defined in the mechanism's specification. If gss_major is not one of GSS_S_COMPLETE or GSS_S_CONTINUE_NEEDED, the context setup has failed; in this case handle and gss_token must be set to NULL by the server. The value of gss_minor is dependent on the value of gss_major and the security mechanism used. The gss_token field contains any token returned by the GSS_Accept_sec_context() call executed by the server. A token may be returned for both successful values of gss_major. If the value is GSS_S_COMPLETE, it indicates that the server is not expecting any more tokens, and the RPC Data Exchange phase must begin on the subsequent request from the client. If the value is GSS_S_CONTINUE_NEEDED, the server is expecting another token. Hence the client must send at least one more creation request (with gss_proc set to RPCSEC_GSS_CONTINUE_INIT in the request's credential) carrying the required token.
ここで、ハンドルは文脈識別子として機能する非NULLの不明瞭なデータです。 コントロールメッセージかそうでないことにかかわらずすべてのその後のこの値が要求するクライアント必須使用) gss_少佐とgssの_の小さい方の分野はサーバによって実行されたGSS_Accept_秒_文脈()に呼び出しの結果を含んでいます。gss_専攻分野への値はこのドキュメントのAppendix Aで定義されます。 gssの_の小さい方の分野への値は、GSS-APIメカニズム特有であり、メカニズムの仕様に基づき定義されます。 gss_少佐が_が必要としたGSS__S COMPLETEか_GSS_S CONTINUEの1つでないなら、文脈セットアップは失敗しました。 この場合、サーバでハンドルとgss_トークンをNULLに設定しなければなりません。gss_未成年者の値は_少佐とセキュリティー対策が使用したgssの値に依存しています。 gss_トークン分野はサーバによって実行されたGSS_Accept_秒_文脈()呼び出しで返されたどんなトークンも含んでいます。gss_少佐の両方のうまくいっている値のためにトークンを返すかもしれません。 値がGSS_S_COMPLETEであるなら、サーバがそれ以上のトークンを予想していないのを示します、そして、RPC Data Exchangeフェーズはその後の要求のときにクライアントから始まらなければなりません。 値がCONTINUE_が必要としたGSS_S_であるなら、サーバは別のトークンを予想しています。 したがって、クライアントは少なくとももうひとつの作成要求(要求の資格証明書でRPCSEC_GSS_CONTINUE_INITに用意ができているgss_procと)に必要なトークンを運ばせなければなりません。
In a successful response, the seq_window field is set to the sequence window length supported by the server for this context. This window specifies the maximum number of client requests that may be outstanding for this context. The server will accept "seq_window" requests at a time, and these may be out of order. The client may use this number to determine the number of threads that can simultaneously send requests on this context.
うまくいっている応答では、seq_窓の分野はこの文脈のためにサーバによってサポートされた系列窓の長さに設定されます。 この窓はこの文脈において、傑出するかもしれないクライアント要求の最大数を指定します。 サーバは一度に「seq_窓」要求を受け入れるでしょう、そして、これらは故障しているかもしれません。 クライアントは、同時にこの文脈に要求を送ることができるスレッドの数を測定するのにこの数を使用するかもしれません。
Eisler, et. al. Standards Track [Page 8] RFC 2203 RPCSEC_GSS Protocol Specification September 1997
etアイスラー、アル。 標準化過程[8ページ]RFC2203RPCSEC_GSSは仕様1997年9月に議定書を作ります。
If gss_major is GSS_S_COMPLETE, the verifier's (the verf element in the response) flavor field is set to RPCSEC_GSS, and the body field set to the checksum of the seq_window (in network order). The QOP used for this checksum is 0 (zero), which is the default QOP. For all other values of gss_major, a NULL verifier (AUTH_NONE flavor with zero-length opaque data) is used.
gss_少佐がGSS_S_COMPLETEであるなら、検証(応答におけるverf要素)の風味分野はRPCSEC_GSSに設定されました、そして、ボディー分野はseq_窓(ネットワークオーダーにおける)のチェックサムにセットしました。 このチェックサムに使用されるQOPは0歳(ゼロ)です。(その歳はデフォルトQOPです)。 gss_少佐の他のすべての値において、NULL検証(ゼロ・レングスの不明瞭なデータがあるAUTH_NONE風味)は使用されています。
5.2.3.1.1. Client Processing of Successful Context Creation Responses
5.2.3.1.1. うまくいっている文脈作成応答のクライアント処理
If the value of gss_major in the response is GSS_S_CONTINUE_NEEDED, then the client, per the GSS-API specification, must invoke GSS_Init_sec_context() using the token returned in gss_token in the context creation response. The client must then generate a context creation request, with gss_proc set to RPCSEC_GSS_CONTINUE_INIT.
応答における、gss_少佐の値がCONTINUE_が必要としたGSS_S_であるなら、クライアントは、GSS-API仕様単位で文脈作成応答にgss_トークンで返されたトークンを使用することでGSS_Init_秒_文脈()を呼び出さなければなりません。 そして、クライアントはRPCSEC_GSS_CONTINUE_INITに用意ができているgss_procとの文脈作成要求を生成しなければなりません。
If the value of gss_major in the response is GSS_S_COMPLETE, and if the client's previous invocation of GSS_Init_sec_context() returned a gss_major value of GSS_S_CONTINUE_NEEDED, then the client, per the GSS-API specification, must invoke GSS_Init_sec_context() using the token returned in gss_token in the context creation response. If GSS_Init_sec_context() returns GSS_S_COMPLETE, the context is successfully set up, and the RPC data exchange phase must begin on the subsequent request from the client.
応答における、gss_少佐の値がGSS_S_COMPLETEであり、クライアントのGSS_Init_秒_文脈()の前の実施が_CONTINUE_が必要としたGSS_S_の主要な値をgssに返したなら、クライアントは、文脈作成応答にgss_トークンで返されたトークンを使用することでGSS-API仕様単位でGSS_Init_秒_文脈()を呼び出さなければなりません。 GSS_Init_秒_文脈()が_GSS_S COMPLETEを返すなら、文脈は首尾よくセットアップされます、そして、RPCデータ交換フェーズはその後の要求のときにクライアントから始まらなければなりません。
5.2.3.2. Context Creation Response - Unsuccessful Cases
5.2.3.2. 文脈作成応答--失敗のケース
An MSG_ACCEPTED reply (to a creation request) with an acceptance status of other than SUCCESS has a NULL verifier (flavor set to AUTH_NONE, and zero length opaque data in the body field), and is formulated as usual for different status values.
SUCCESSを除いて、ACCEPTEDが承認状態で返答する(作成要求に)エムエスジー_はNULL検証(風味はボディー分野にAUTH_NONE、およびゼロ・レングスの不明瞭なデータにセットした)を持って、異なった状態値のためにいつものように定式化されます。
An MSG_DENIED reply (to a creation request) is also formulated as usual. Note that MSG_DENIED could be returned because the server's RPC implementation does not recognize the RPCSEC_GSS security flavor. RFC 1831 does not specify the appropriate reply status in this instance, but common implementation practice appears to be to return a rejection status of AUTH_ERROR with an auth_stat of AUTH_REJECTEDCRED. Even though two new values (RPCSEC_GSS_CREDPROBLEM and RPCSEC_GSS_CTXPROBLEM) have been defined for the auth_stat type, neither of these two can be returned in responses to context creation requests. The auth_stat new values can be used for responses to normal (data) requests. This is described later.
また、エムエスジー_DENIED回答(作成要求への)はいつものように定式化されます。 サーバのRPC実装がRPCSEC_GSSセキュリティ風味を認識しないのでエムエスジー_DENIEDを返すことができたことに注意してください。 RFC1831はこの場合適切な回答状態を指定しませんが、一般的な実装習慣はAUTH_REJECTEDCREDのauth_スタットがあるAUTH_ERRORの拒絶状態を返すことになっているように見えます。 auth_スタットタイプのために、2つの新しい値(RPCSEC_GSS_CREDPROBLEMとRPCSEC_GSS_CTXPROBLEM)を定義しましたが、文脈作成要求への応答ではこれらの2のどちらも返すことができません。 通常の(データ)要求への応答にauth_スタットの新しい値を使用できます。 これは後で説明されます。
MSG_DENIED might also be returned if the RPCSEC_GSS version number in the credential is not supported on the server. In that case, the server returns a rejection status of AUTH_ERROR, with an auth_stat of
また、サーバで資格証明書におけるRPCSEC_GSSバージョン番号をサポートしないなら、エムエスジー_DENIEDを返すかもしれません。その場合、サーバはAUTH_ERRORの拒絶状態を返します、auth_スタットと共に
AUTH_REJECTED_CRED.
AUTH_は_信用を拒絶しました。
Eisler, et. al. Standards Track [Page 9] RFC 2203 RPCSEC_GSS Protocol Specification September 1997
etアイスラー、アル。 標準化過程[9ページ]RFC2203RPCSEC_GSSは仕様1997年9月に議定書を作ります。
5.3. RPC Data Exchange
5.3. RPCデータ交換
The data exchange phase is entered after a context has been successfully set up. The format of the data exchanged depends on the security service used for the request. Although clients can change the security service and QOP used on a per-request basis, this may not be acceptable to all RPC services; some RPC services may "lock" the data exchange phase into using the QOP and service used on the first data exchange message. For all three modes of service (no data integrity, data integrity, data privacy), the RPC request header has the same format.
文脈が首尾よくセットアップされた後にデータ交換フェーズは入れられます。 交換されたデータの形式は要求に使用されるセキュリティー・サービスに依存します。 クライアントはセキュリティー・サービスと1要求あたり1個のベースで使用されるQOPを変えることができますが、これはすべてのRPCサービスに許容できないかもしれません。 いくつかのRPCサービスが最初のデータ交換メッセージで利用されたQOPとサービスを利用するのにデータ交換フェーズを「ロックするかもしれません」。 サービス(データ保全がない、データ保全、データプライバシー)のすべての3つの方法のために、RPC要求ヘッダーには、同じ形式があります。
5.3.1. RPC Request Header
5.3.1. RPCはヘッダーを要求します。
The credential has the opaque_auth structure described earlier. The flavor field is set to RPCSEC_GSS. The credential body is created by XDR encoding the rpc_gss_cred_t structure listed earlier into an octet stream, and then opaquely encoding this octet stream as the body field.
資格証明書には、より早く説明された不明瞭な_auth構造があります。 風味分野はRPCSEC_GSSに設定されます。 資格証明ボディーは、より早く記載されたrpc_gss_信用_t構造を八重奏ストリームにコード化して、次にボディー分野としてこの八重奏ストリームを不透明にコード化するXDRによって作成されます。
Values of the fields contained in the rpc_gss_cred_t structure are set as follows. The version field is set to same version value that was used to create the context, which within the scope of this memo will always be RPCSEC_GSS_VERS_1. The gss_proc field is set to RPCSEC_GSS_DATA. The service field is set to indicate the desired service (one of rpc_gss_svc_none, rpc_gss_svc_integrity, or rpc_gss_svc_privacy). The handle field is set to the context handle value received from the RPC server during context creation. The seq_num field can start at any value below MAXSEQ, and must be incremented (by one or more) for successive requests. Use of sequence numbers is described in detail when server processing of the request is discussed.
rpc_gss_信用_t構造に含まれた分野の値は以下の通り設定されます。 バージョン分野はこのメモの範囲の中でいつもRPCSEC_GSS_になVERS_1る文脈を作成するのに使用された同じバージョン値に設定されます。 gss_proc分野はRPCSEC_GSS_DATAに設定されます。 サービス分野が必要なサービスを示すように設定されます(_rpcの_のgssの_のsvcでないなにも1つ、rpc_gss_svc_保全、またはrpc_gss_svc_プライバシー)。 ハンドル分野は文脈作成の間のRPCサーバからの文脈ハンドル対価領収へのセットです。 seq_num分野はMAXSEQの下のどんな値でも始まることができて、連続した要求のために増加しなければなりません(より1時までに)。 要求のサーバ処理について議論するとき、一連番号の使用は詳細に説明されます。
The verifier has the opaque_auth structure described earlier. The flavor field is set to RPCSEC_GSS. The body field is set as follows. The checksum of the RPC header (up to and including the credential) is computed using the GSS_GetMIC() call with the desired QOP. This returns the checksum as an opaque octet stream and its length. This is encoded into the body field. Note that the QOP is not explicitly specified anywhere in the request. It is implicit in the checksum or encrypted data. The same QOP value as is used for the header checksum must also be used for the data (for checksumming or encrypting), unless the service used for the request is rpc_gss_svc_none.
検証には、より早く説明された不明瞭な_auth構造があります。 風味分野はRPCSEC_GSSに設定されます。 ボディー分野は以下の通り設定されます。 RPCヘッダー(資格証明書を含めた)のチェックサムは、必要なQOPとのGSS_GetMIC()呼び出しを使用することで計算されます。 これは不透明な八重奏ストリームとその長さとしてチェックサムを返します。 これはボディー分野にコード化されます。 QOPが要求で何処にも明らかに指定されないことに注意してください。 それはチェックサムか暗号化されたデータで暗に示されています。 また、データ(checksummingか暗号化のための)にヘッダーチェックサムに使用されるのと同じQOP値を使用しなければなりません、要求に利用されたサービスが_svcに_なにもにrpc_gssでないなら。
Eisler, et. al. Standards Track [Page 10] RFC 2203 RPCSEC_GSS Protocol Specification September 1997
etアイスラー、アル。 標準化過程[10ページ]RFC2203RPCSEC_GSSは仕様1997年9月に議定書を作ります。
5.3.2. RPC Request Data
5.3.2. RPCはデータを要求します。
5.3.2.1. RPC Request Data - No Data Integrity
5.3.2.1. RPC要求データ--データの保全がありません。
If the service specified is rpc_gss_svc_none, the data (procedure arguments) are not integrity or privacy protected. They are sent in exactly the same way as they would be if the AUTH_NONE flavor were used (following the verifier). Note, however, that since the RPC header is integrity protected, the sender will still be authenticated in this case.
_指定されたサービスがrpc_gss_svcであるなら、なにも、データ(手順議論)は、保全でない、また保護されたプライバシーではありません。 それらはまさにずっとAUTH_NONE風味が使用されたかどうかという(検証に続いて)ことであるだろうことのように同じように送られます。 しかしながら、RPCヘッダー以来のそれが保護された保全であることに注意してください、そして、それでも、送付者はこの場合認証されるでしょう。
5.3.2.2. RPC Request Data - With Data Integrity
5.3.2.2. RPCはデータの保全でデータを要求します。
When data integrity is used, the request data is represented as follows:
データ保全が使用されているとき、要求データは以下の通り表されます:
struct rpc_gss_integ_data {
opaque databody_integ<>;
opaque checksum<>;
};
struct rpc_gss_integ_データはdatabody_integ<>(不透明なチェックサム<>)について不透明にします。
The databody_integ field is created as follows. A structure consisting of a sequence number followed by the procedure arguments is constructed. This is shown below as the type rpc_gss_data_t:
databody_integ分野は以下の通りで作成されます。 手順議論があとに続いた一連番号から成る構造は構成されます。 これはタイプrpc_gss_データ_tとして以下に示されます:
struct rpc_gss_data_t {
unsigned int seq_num;
proc_req_arg_t arg;
};
struct rpc_gss_データの_t未署名のint seq_num(proc_req_arg_t arg)。
Here, seq_num must have the same value as in the credential. The type proc_req_arg_t is the procedure specific XDR type describing the procedure arguments (and so is not specified here). The octet stream corresponding to the XDR encoded rpc_gss_data_t structure and its length are placed in the databody_integ field. Note that because the XDR type of databody_integ is opaque, the XDR encoding of databody_integ will include an initial four octet length field, followed by the XDR encoded octet stream of rpc_gss_data_t.
Here, seq_num must have the same value as in the credential. The type proc_req_arg_t is the procedure specific XDR type describing the procedure arguments (and so is not specified here). The octet stream corresponding to the XDR encoded rpc_gss_data_t structure and its length are placed in the databody_integ field. Note that because the XDR type of databody_integ is opaque, the XDR encoding of databody_integ will include an initial four octet length field, followed by the XDR encoded octet stream of rpc_gss_data_t.
The checksum field represents the checksum of the XDR encoded octet stream corresponding to the XDR encoded rpc_gss_data_t structure (note, this is not the checksum of the databody_integ field). This is obtained using the GSS_GetMIC() call, with the same QOP as was used to compute the header checksum (in the verifier). The
The checksum field represents the checksum of the XDR encoded octet stream corresponding to the XDR encoded rpc_gss_data_t structure (note, this is not the checksum of the databody_integ field). This is obtained using the GSS_GetMIC() call, with the same QOP as was used to compute the header checksum (in the verifier). The
Eisler, et. al. Standards Track [Page 11] RFC 2203 RPCSEC_GSS Protocol Specification September 1997
Eisler, et. al. Standards Track [Page 11] RFC 2203 RPCSEC_GSS Protocol Specification September 1997
GSS_GetMIC() call returns the checksum as an opaque octet stream and its length. The checksum field of struct rpc_gss_integ_data has an XDR type of opaque. Thus the checksum length from GSS_GetMIC() is encoded as a four octet length field, followed by the checksum, padded to a multiple of four octets.
GSS_GetMIC() call returns the checksum as an opaque octet stream and its length. The checksum field of struct rpc_gss_integ_data has an XDR type of opaque. Thus the checksum length from GSS_GetMIC() is encoded as a four octet length field, followed by the checksum, padded to a multiple of four octets.
5.3.2.3. RPC Request Data - With Data Privacy
5.3.2.3. RPC Request Data - With Data Privacy
When data privacy is used, the request data is represented as follows:
When data privacy is used, the request data is represented as follows:
struct rpc_gss_priv_data {
opaque databody_priv<>
};
struct rpc_gss_priv_data { opaque databody_priv<> };
The databody_priv field is created as follows. The rpc_gss_data_t structure described earlier is constructed again in the same way as for the case of data integrity. Next, the GSS_Wrap() call is invoked to encrypt the octet stream corresponding to the rpc_gss_data_t structure, using the same value for QOP (argument qop_req to GSS_Wrap()) as was used for the header checksum (in the verifier) and conf_req_flag (an argument to GSS_Wrap()) of TRUE. The GSS_Wrap() call returns an opaque octet stream (representing the encrypted rpc_gss_data_t structure) and its length, and this is encoded as the databody_priv field. Since databody_priv has an XDR type of opaque, the length returned by GSS_Wrap() is encoded as the four octet length, followed by the encrypted octet stream (padded to a multiple of four octets).
The databody_priv field is created as follows. The rpc_gss_data_t structure described earlier is constructed again in the same way as for the case of data integrity. Next, the GSS_Wrap() call is invoked to encrypt the octet stream corresponding to the rpc_gss_data_t structure, using the same value for QOP (argument qop_req to GSS_Wrap()) as was used for the header checksum (in the verifier) and conf_req_flag (an argument to GSS_Wrap()) of TRUE. The GSS_Wrap() call returns an opaque octet stream (representing the encrypted rpc_gss_data_t structure) and its length, and this is encoded as the databody_priv field. Since databody_priv has an XDR type of opaque, the length returned by GSS_Wrap() is encoded as the four octet length, followed by the encrypted octet stream (padded to a multiple of four octets).
5.3.3. Server Processing of RPC Data Requests
5.3.3. Server Processing of RPC Data Requests
5.3.3.1. Context Management
5.3.3.1. Context Management
When a request is received by the server, the following are verified to be acceptable:
When a request is received by the server, the following are verified to be acceptable:
* the version number in the credential
* the version number in the credential
* the service specified in the credential
* the service specified in the credential
* the context handle specified in the credential
* the context handle specified in the credential
* the header checksum in the verifier (via GSS_VerifyMIC())
* the header checksum in the verifier (via GSS_VerifyMIC())
* the sequence number (seq_num) specified in the credential (more
on this follows)
* the sequence number (seq_num) specified in the credential (more on this follows)
Eisler, et. al. Standards Track [Page 12] RFC 2203 RPCSEC_GSS Protocol Specification September 1997
Eisler, et. al. Standards Track [Page 12] RFC 2203 RPCSEC_GSS Protocol Specification September 1997
The gss_proc field in the credential must be set to RPCSEC_GSS_DATA for data requests (otherwise, the message will be interpreted as a control message).
The gss_proc field in the credential must be set to RPCSEC_GSS_DATA for data requests (otherwise, the message will be interpreted as a control message).
The server maintains a window of "seq_window" sequence numbers, starting with the last sequence number seen and extending backwards. If a sequence number higher than the last number seen is received (AND if GSS_VerifyMIC() on the header checksum from the verifier returns GSS_S_COMPLETE), the window is moved forward to the new sequence number. If the last sequence number seen is N, the server is prepared to receive requests with sequence numbers in the range N through (N - seq_window + 1), both inclusive. If the sequence number received falls below this range, it is silently discarded. If the sequence number is within this range, and the server has not seen it, the request is accepted, and the server turns on a bit to "remember" that this sequence number has been seen. If the server determines that it has already seen a sequence number within the window, the request is silently discarded. The server should select a seq_window value based on the number requests it expects to process simultaneously. For example, in a threaded implementation seq_window might be equal to the number of server threads. There are no known security issues with selecting a large window. The primary issue is how much space the server is willing to allocate to keep track of requests received within the window.
The server maintains a window of "seq_window" sequence numbers, starting with the last sequence number seen and extending backwards. If a sequence number higher than the last number seen is received (AND if GSS_VerifyMIC() on the header checksum from the verifier returns GSS_S_COMPLETE), the window is moved forward to the new sequence number. If the last sequence number seen is N, the server is prepared to receive requests with sequence numbers in the range N through (N - seq_window + 1), both inclusive. If the sequence number received falls below this range, it is silently discarded. If the sequence number is within this range, and the server has not seen it, the request is accepted, and the server turns on a bit to "remember" that this sequence number has been seen. If the server determines that it has already seen a sequence number within the window, the request is silently discarded. The server should select a seq_window value based on the number requests it expects to process simultaneously. For example, in a threaded implementation seq_window might be equal to the number of server threads. There are no known security issues with selecting a large window. The primary issue is how much space the server is willing to allocate to keep track of requests received within the window.
The reason for discarding requests silently is that the server is unable to determine if the duplicate or out of range request was due to a sequencing problem in the client, network, or the operating system, or due to some quirk in routing, or a replay attack by an intruder. Discarding the request allows the client to recover after timing out, if indeed the duplication was unintentional or well intended. Note that a consequence of the silent discard is that clients may increment the seq_num by more than one. The effect of this is that the window will move forward more quickly. It is not believed that there is any benefit to doing this.
The reason for discarding requests silently is that the server is unable to determine if the duplicate or out of range request was due to a sequencing problem in the client, network, or the operating system, or due to some quirk in routing, or a replay attack by an intruder. Discarding the request allows the client to recover after timing out, if indeed the duplication was unintentional or well intended. Note that a consequence of the silent discard is that clients may increment the seq_num by more than one. The effect of this is that the window will move forward more quickly. It is not believed that there is any benefit to doing this.
Note that the sequence number algorithm requires that the client increment the sequence number even if it is retrying a request with the same RPC transaction identifier. It is not infrequent for clients to get into a situation where they send two or more attempts and a slow server sends the reply for the first attempt. With RPCSEC_GSS, each request and reply will have a unique sequence number. If the client wishes to improve turn around time on the RPC call, it can cache the RPCSEC_GSS sequence number of each request it sends. Then when it receives a response with a matching RPC transaction identifier, it can compute the checksum of each sequence number in the cache to try to match the checksum in the reply's verifier.
Note that the sequence number algorithm requires that the client increment the sequence number even if it is retrying a request with the same RPC transaction identifier. It is not infrequent for clients to get into a situation where they send two or more attempts and a slow server sends the reply for the first attempt. With RPCSEC_GSS, each request and reply will have a unique sequence number. If the client wishes to improve turn around time on the RPC call, it can cache the RPCSEC_GSS sequence number of each request it sends. Then when it receives a response with a matching RPC transaction identifier, it can compute the checksum of each sequence number in the cache to try to match the checksum in the reply's verifier.
Eisler, et. al. Standards Track [Page 13] RFC 2203 RPCSEC_GSS Protocol Specification September 1997
Eisler, et. al. Standards Track [Page 13] RFC 2203 RPCSEC_GSS Protocol Specification September 1997
The data is decoded according to the service specified in the credential. In the case of integrity or privacy, the server ensures that the QOP value is acceptable, and that it is the same as that used for the header checksum in the verifier. Also, in the case of integrity or privacy, the server will reject the message (with a reply status of MSG_ACCEPTED, and an acceptance status of GARBAGE_ARGS) if the sequence number embedded in the request body is different from the sequence number in the credential.
The data is decoded according to the service specified in the credential. In the case of integrity or privacy, the server ensures that the QOP value is acceptable, and that it is the same as that used for the header checksum in the verifier. Also, in the case of integrity or privacy, the server will reject the message (with a reply status of MSG_ACCEPTED, and an acceptance status of GARBAGE_ARGS) if the sequence number embedded in the request body is different from the sequence number in the credential.
5.3.3.2. Server Reply - Request Accepted
5.3.3.2. Server Reply - Request Accepted
An MSG_ACCEPTED reply to a request in the data exchange phase will have the verifier's (the verf element in the response) flavor field set to RPCSEC_GSS, and the body field set to the checksum (the output of GSS_GetMIC()) of the sequence number (in network order) of the corresponding request. The QOP used is the same as the QOP used for the corresponding request.
An MSG_ACCEPTED reply to a request in the data exchange phase will have the verifier's (the verf element in the response) flavor field set to RPCSEC_GSS, and the body field set to the checksum (the output of GSS_GetMIC()) of the sequence number (in network order) of the corresponding request. The QOP used is the same as the QOP used for the corresponding request.
If the status of the reply is not SUCCESS, the rest of the message is formatted as usual.
If the status of the reply is not SUCCESS, the rest of the message is formatted as usual.
If the status of the message is SUCCESS, the format of the rest of the message depends on the service specified in the corresponding request message. Basically, what follows the verifier in this case are the procedure results, formatted in different ways depending on the requested service.
If the status of the message is SUCCESS, the format of the rest of the message depends on the service specified in the corresponding request message. Basically, what follows the verifier in this case are the procedure results, formatted in different ways depending on the requested service.
If no data integrity was requested, the procedure results are formatted as for the AUTH_NONE security flavor.
If no data integrity was requested, the procedure results are formatted as for the AUTH_NONE security flavor.
If data integrity was requested, the results are encoded in exactly the same way as the procedure arguments were in the corresponding request. See the section 'RPC Request Data - With Data Integrity.' The only difference is that the structure representing the procedure's result - proc_res_arg_t - must be substituted in place of the request argument structure proc_req_arg_t. The QOP used for the checksum must be the same as that used for constructing the reply verifier.
If data integrity was requested, the results are encoded in exactly the same way as the procedure arguments were in the corresponding request. See the section 'RPC Request Data - With Data Integrity.' The only difference is that the structure representing the procedure's result - proc_res_arg_t - must be substituted in place of the request argument structure proc_req_arg_t. The QOP used for the checksum must be the same as that used for constructing the reply verifier.
If data privacy was requested, the results are encoded in exactly the same way as the procedure arguments were in the corresponding request. See the section 'RPC Request Data - With Data Privacy.' The QOP used for encryption must be the same as that used for constructing the reply verifier.
If data privacy was requested, the results are encoded in exactly the same way as the procedure arguments were in the corresponding request. See the section 'RPC Request Data - With Data Privacy.' The QOP used for encryption must be the same as that used for constructing the reply verifier.
Eisler, et. al. Standards Track [Page 14] RFC 2203 RPCSEC_GSS Protocol Specification September 1997
Eisler, et. al. Standards Track [Page 14] RFC 2203 RPCSEC_GSS Protocol Specification September 1997
5.3.3.3. Server Reply - Request Denied
5.3.3.3. Server Reply - Request Denied
An MSG_DENIED reply (to a data request) is formulated as usual. Two new values (RPCSEC_GSS_CREDPROBLEM and RPCSEC_GSS_CTXPROBLEM) have been defined for the auth_stat type. When the reason for denial of the request is a reject_stat of AUTH_ERROR, one of the two new auth_stat values could be returned in addition to the existing values. These two new values have special significance from the existing reasons for denial of a request.
An MSG_DENIED reply (to a data request) is formulated as usual. Two new values (RPCSEC_GSS_CREDPROBLEM and RPCSEC_GSS_CTXPROBLEM) have been defined for the auth_stat type. When the reason for denial of the request is a reject_stat of AUTH_ERROR, one of the two new auth_stat values could be returned in addition to the existing values. These two new values have special significance from the existing reasons for denial of a request.
The server maintains a list of contexts for the clients that are currently in session with it. Normally, a context is destroyed when the client ends the session corresponding to it. However, due to resource constraints, the server may destroy a context prematurely (on an LRU basis, or if the server machine is rebooted, for example). In this case, when a client request comes in, there may not be a context corresponding to its handle. The server rejects the request, with the reason RPCSEC_GSS_CREDPROBLEM in this case. Upon receiving this error, the client must refresh the context - that is, reestablish it after destroying the old one - and try the request again. This error is also returned if the context handle matches that of a different context that was allocated after the client's context was destroyed (this will be detected by a failure in verifying the header checksum).
The server maintains a list of contexts for the clients that are currently in session with it. Normally, a context is destroyed when the client ends the session corresponding to it. However, due to resource constraints, the server may destroy a context prematurely (on an LRU basis, or if the server machine is rebooted, for example). In this case, when a client request comes in, there may not be a context corresponding to its handle. The server rejects the request, with the reason RPCSEC_GSS_CREDPROBLEM in this case. Upon receiving this error, the client must refresh the context - that is, reestablish it after destroying the old one - and try the request again. This error is also returned if the context handle matches that of a different context that was allocated after the client's context was destroyed (this will be detected by a failure in verifying the header checksum).
If the GSS_VerifyMIC() call on the header checksum (contained in the verifier) fails to return GSS_S_COMPLETE, the server rejects the request and returns an auth_stat of RPCSEC_GSS_CREDPROBLEM.
If the GSS_VerifyMIC() call on the header checksum (contained in the verifier) fails to return GSS_S_COMPLETE, the server rejects the request and returns an auth_stat of RPCSEC_GSS_CREDPROBLEM.
When the client's sequence number exceeds the maximum the server will allow, the server will reject the request with the reason RPCSEC_GSS_CTXPROBLEM. Also, if security credentials become stale while in use (due to ticket expiry in the case of the Kerberos V5 mechanism, for example), the failures which result cause the RPCSEC_GSS_CTXPROBLEM reason to be returned. In these cases also, the client must refresh the context, and retry the request.
When the client's sequence number exceeds the maximum the server will allow, the server will reject the request with the reason RPCSEC_GSS_CTXPROBLEM. Also, if security credentials become stale while in use (due to ticket expiry in the case of the Kerberos V5 mechanism, for example), the failures which result cause the RPCSEC_GSS_CTXPROBLEM reason to be returned. In these cases also, the client must refresh the context, and retry the request.
For other errors, retrying will not rectify the problem and the client must not refresh the context until the problem causing the client request to be denied is rectified.
For other errors, retrying will not rectify the problem and the client must not refresh the context until the problem causing the client request to be denied is rectified.
If the version field in the credential does not match the version of RPCSEC_GSS that was used when the context was created, the AUTH_BADCRED value is returned.
If the version field in the credential does not match the version of RPCSEC_GSS that was used when the context was created, the AUTH_BADCRED value is returned.
If there is a problem with the credential, such a bad length, illegal control procedure, or an illegal service, the appropriate auth_stat status is AUTH_BADCRED.
If there is a problem with the credential, such a bad length, illegal control procedure, or an illegal service, the appropriate auth_stat status is AUTH_BADCRED.
Eisler, et. al. Standards Track [Page 15] RFC 2203 RPCSEC_GSS Protocol Specification September 1997
Eisler, et. al. Standards Track [Page 15] RFC 2203 RPCSEC_GSS Protocol Specification September 1997
Other errors can be returned as appropriate.
Other errors can be returned as appropriate.
5.3.3.4. Mapping of GSS-API Errors to Server Responses
5.3.3.4. Mapping of GSS-API Errors to Server Responses
During the data exchange phase, the server may invoke GSS_GetMIC(), GSS_VerifyMIC(), GSS_Unwrap(), and GSS_Wrap(). If any of these routines fail to return GSS_S_COMPLETE, then various unsuccessful responses can be returned. The are described as follows for each of the aforementioned four interfaces.
During the data exchange phase, the server may invoke GSS_GetMIC(), GSS_VerifyMIC(), GSS_Unwrap(), and GSS_Wrap(). If any of these routines fail to return GSS_S_COMPLETE, then various unsuccessful responses can be returned. The are described as follows for each of the aforementioned four interfaces.
5.3.3.4.1. GSS_GetMIC() Failure
5.3.3.4.1. GSS_GetMIC() Failure
When GSS_GetMIC() is called to generate the verifier in the response, a failure results in an RPC response with a reply status of MSG_DENIED, reject status of AUTH_ERROR and an auth status of RPCSEC_GSS_CTXPROBLEM.
When GSS_GetMIC() is called to generate the verifier in the response, a failure results in an RPC response with a reply status of MSG_DENIED, reject status of AUTH_ERROR and an auth status of RPCSEC_GSS_CTXPROBLEM.
When GSS_GetMIC() is called to sign the call results (service is rpc_gss_svc_integrity), a failure results in no RPC response being sent. Since ONC RPC server applications will typically control when a response is sent, the failure indication will be returned to the server application and it can take appropriate action (such as logging the error).
When GSS_GetMIC() is called to sign the call results (service is rpc_gss_svc_integrity), a failure results in no RPC response being sent. Since ONC RPC server applications will typically control when a response is sent, the failure indication will be returned to the server application and it can take appropriate action (such as logging the error).
5.3.3.4.2. GSS_VerifyMIC() Failure
5.3.3.4.2. GSS_VerifyMIC() Failure
When GSS_VerifyMIC() is called to verify the verifier in request, a failure results in an RPC response with a reply status of MSG_DENIED, reject status of AUTH_ERROR and an auth status of RPCSEC_GSS_CREDPROBLEM.
When GSS_VerifyMIC() is called to verify the verifier in request, a failure results in an RPC response with a reply status of MSG_DENIED, reject status of AUTH_ERROR and an auth status of RPCSEC_GSS_CREDPROBLEM.
When GSS_VerifyMIC() is called to verify the call arguments (service is rpc_gss_svc_integrity), a failure results in an RPC response with a reply status of MSG_ACCEPTED, and an acceptance status of GARBAGE_ARGS.
When GSS_VerifyMIC() is called to verify the call arguments (service is rpc_gss_svc_integrity), a failure results in an RPC response with a reply status of MSG_ACCEPTED, and an acceptance status of GARBAGE_ARGS.
5.3.3.4.3. GSS_Unwrap() Failure
5.3.3.4.3. GSS_Unwrap() Failure
When GSS_Unwrap() is called to decrypt the call arguments (service is rpc_gss_svc_privacy), a failure results in an RPC response with a reply status of MSG_ACCEPTED, and an acceptance status of GARBAGE_ARGS.
When GSS_Unwrap() is called to decrypt the call arguments (service is rpc_gss_svc_privacy), a failure results in an RPC response with a reply status of MSG_ACCEPTED, and an acceptance status of GARBAGE_ARGS.
5.3.3.4.4. GSS_Wrap() Failure
5.3.3.4.4. GSS_Wrap() Failure
When GSS_Wrap() is called to encrypt the call results (service is rpc_gss_svc_privacy), a failure results in no RPC response being sent. Since ONC RPC server applications will typically control when a
When GSS_Wrap() is called to encrypt the call results (service is rpc_gss_svc_privacy), a failure results in no RPC response being sent. Since ONC RPC server applications will typically control when a
Eisler, et. al. Standards Track [Page 16] RFC 2203 RPCSEC_GSS Protocol Specification September 1997
Eisler, et. al. Standards Track [Page 16] RFC 2203 RPCSEC_GSS Protocol Specification September 1997
response is sent, the failure indication will be returned to the application and it can take appropriate action (such as logging the error).
response is sent, the failure indication will be returned to the application and it can take appropriate action (such as logging the error).
5.4. Context Destruction
5.4. Context Destruction
When the client is done using the session, it must send a control message informing the server that it no longer requires the context. This message is formulated just like a data request packet, with the following differences: the credential has gss_proc set to RPCSEC_GSS_DESTROY, the procedure specified in the header is NULLPROC, and there are no procedure arguments. The sequence number in the request must be valid, and the header checksum in the verifier must be valid, for the server to accept the message. The server sends a response as it would to a data request. The client and server must then destroy the context for the session.
When the client is done using the session, it must send a control message informing the server that it no longer requires the context. This message is formulated just like a data request packet, with the following differences: the credential has gss_proc set to RPCSEC_GSS_DESTROY, the procedure specified in the header is NULLPROC, and there are no procedure arguments. The sequence number in the request must be valid, and the header checksum in the verifier must be valid, for the server to accept the message. The server sends a response as it would to a data request. The client and server must then destroy the context for the session.
If the request to destroy the context fails for some reason, the client need not take any special action. The server must be prepared to deal with situations where clients never inform the server that they no longer are in session and so don't need the server to maintain a context. An LRU mechanism or an aging mechanism should be employed by the server to clean up in such cases.
If the request to destroy the context fails for some reason, the client need not take any special action. The server must be prepared to deal with situations where clients never inform the server that they no longer are in session and so don't need the server to maintain a context. An LRU mechanism or an aging mechanism should be employed by the server to clean up in such cases.
6. Set of GSS-API Mechanisms
6. Set of GSS-API Mechanisms
RPCSEC_GSS is effectively a "pass-through" to the GSS-API layer, and as such it is inappropriate for the RPCSEC_GSS specification to enumerate a minimum set of required security mechanisms and/or quality of protections.
RPCSEC_GSS is effectively a "pass-through" to the GSS-API layer, and as such it is inappropriate for the RPCSEC_GSS specification to enumerate a minimum set of required security mechanisms and/or quality of protections.
If an application protocol specification references RPCSEC_GSS, the
protocol specification must list a mandatory set of { mechanism, QOP,
service } triples, such that an implementation cannot claim
conformance to the protocol specification unless it implements the
set of triples. Within each triple, mechanism is a GSS-API security
mechanism, QOP is a valid quality-of-protection within the mechanism,
and service is either rpc_gss_svc_integrity or rpc_gss_svc_privacy.
If an application protocol specification references RPCSEC_GSS, the protocol specification must list a mandatory set of { mechanism, QOP, service } triples, such that an implementation cannot claim conformance to the protocol specification unless it implements the set of triples. Within each triple, mechanism is a GSS-API security mechanism, QOP is a valid quality-of-protection within the mechanism, and service is either rpc_gss_svc_integrity or rpc_gss_svc_privacy.
For example, a network filing protocol built on RPC that depends on RPCSEC_GSS for security, might require that Kerberos V5 with the default QOP using the rpc_gss_svc_integrity service be supported by implementations conforming to the network filing protocol specification.
For example, a network filing protocol built on RPC that depends on RPCSEC_GSS for security, might require that Kerberos V5 with the default QOP using the rpc_gss_svc_integrity service be supported by implementations conforming to the network filing protocol specification.
Eisler, et. al. Standards Track [Page 17] RFC 2203 RPCSEC_GSS Protocol Specification September 1997
Eisler, et. al. Standards Track [Page 17] RFC 2203 RPCSEC_GSS Protocol Specification September 1997
7. Security Considerations
7. Security Considerations
7.1. Privacy of Call Header
7.1. Privacy of Call Header
The reader will note that for the privacy option, only the call arguments and results are encrypted. Information about the application in the form of RPC program number, program version number, and program procedure number is transmitted in the clear. Encrypting these fields in the RPC call header would have changed the size and format of the call header. This would have required revising the RPC protocol which was beyond the scope of this proposal. Storing the encrypted numbers in the credential would have obviated a protocol change, but would have introduced more overloading of fields and would have made implementations of RPC more complex. Even if the fields were encrypted somehow, in most cases an attacker can determine the program number and version number by examining the destination address of the request and querying the rpcbind service on the destination host [Srinivasan-bind]. In any case, even by not encrypting the three numbers, RPCSEC_GSS still improves the state of security over what existing RPC services have had available previously. Implementors of new RPC services that are concerned about this risk may opt to design in a "sub-procedure" field that is included in the service specific call arguments.
The reader will note that for the privacy option, only the call arguments and results are encrypted. Information about the application in the form of RPC program number, program version number, and program procedure number is transmitted in the clear. Encrypting these fields in the RPC call header would have changed the size and format of the call header. This would have required revising the RPC protocol which was beyond the scope of this proposal. Storing the encrypted numbers in the credential would have obviated a protocol change, but would have introduced more overloading of fields and would have made implementations of RPC more complex. Even if the fields were encrypted somehow, in most cases an attacker can determine the program number and version number by examining the destination address of the request and querying the rpcbind service on the destination host [Srinivasan-bind]. In any case, even by not encrypting the three numbers, RPCSEC_GSS still improves the state of security over what existing RPC services have had available previously. Implementors of new RPC services that are concerned about this risk may opt to design in a "sub-procedure" field that is included in the service specific call arguments.
7.2. Sequence Number Attacks
7.2. Sequence Number Attacks
7.2.1. Sequence Numbers Above the Window
7.2.1. Sequence Numbers Above the Window
An attacker cannot coax the server into raising the sequence number beyond the range the legitimate client is aware of (and thus engineer a denial of server attack) without constructing an RPC request that will pass the header checksum. If the cost of verifying the header checksum is sufficiently large (depending on the speed of the processor doing the checksum and the cost of checksum algorithm), it is possible to envision a denial of service attack (vandalism, in the form of wasting processing resources) whereby the attacker sends requests that are above the window. The simplest method might be for the attacker to monitor the network traffic and then choose a sequence number that is far above the current sequence number. Then the attacker can send bogus requests using the above window sequence number.
An attacker cannot coax the server into raising the sequence number beyond the range the legitimate client is aware of (and thus engineer a denial of server attack) without constructing an RPC request that will pass the header checksum. If the cost of verifying the header checksum is sufficiently large (depending on the speed of the processor doing the checksum and the cost of checksum algorithm), it is possible to envision a denial of service attack (vandalism, in the form of wasting processing resources) whereby the attacker sends requests that are above the window. The simplest method might be for the attacker to monitor the network traffic and then choose a sequence number that is far above the current sequence number. Then the attacker can send bogus requests using the above window sequence number.
7.2.2. Sequence Numbers Within or Below the Window
7.2.2. Sequence Numbers Within or Below the Window
If the attacker sends requests that are within or below the window, then even if the header checksum is successfully verified, the server will silently discard the requests because the server assumes it has already processed the request. In this case, a server can optimize by
If the attacker sends requests that are within or below the window, then even if the header checksum is successfully verified, the server will silently discard the requests because the server assumes it has already processed the request. In this case, a server can optimize by
Eisler, et. al. Standards Track [Page 18] RFC 2203 RPCSEC_GSS Protocol Specification September 1997
Eisler, et. al. Standards Track [Page 18] RFC 2203 RPCSEC_GSS Protocol Specification September 1997
skipping the header checksum verification if the sequence number is below the window, or if it is within the window, not attempt the checksum verification if the sequence number has already been seen.
skipping the header checksum verification if the sequence number is below the window, or if it is within the window, not attempt the checksum verification if the sequence number has already been seen.
7.3. Message Stealing Attacks
7.3. Message Stealing Attacks
This proposal does not address attacks where an attacker can block or steal messages without being detected by the server. To implement such protection would be tantamount to assuming a state in the RPC service. RPCSEC_GSS does not worsen this situation.
This proposal does not address attacks where an attacker can block or steal messages without being detected by the server. To implement such protection would be tantamount to assuming a state in the RPC service. RPCSEC_GSS does not worsen this situation.
Eisler, et. al. Standards Track [Page 19] RFC 2203 RPCSEC_GSS Protocol Specification September 1997
Eisler, et. al. Standards Track [Page 19] RFC 2203 RPCSEC_GSS Protocol Specification September 1997
Appendix A. GSS-API Major Status Codes
Appendix A. GSS-API Major Status Codes
The GSS-API definition [Linn] does not include numerical values for the various GSS-API major status codes. It is expected that this will be addressed in future RFC. Until then, this appendix defines the values for each GSS-API major status code listed in the GSS-API definition. If in the future, the GSS-API definition defines values for the codes that are different than what follows, then implementors of RPCSEC_GSS will be obliged to map them into the values defined below. If in the future, the GSS-API definition defines additional status codes not defined below, then the RPCSEC_GSS definition will subsume those additional values.
The GSS-API definition [Linn] does not include numerical values for the various GSS-API major status codes. It is expected that this will be addressed in future RFC. Until then, this appendix defines the values for each GSS-API major status code listed in the GSS-API definition. If in the future, the GSS-API definition defines values for the codes that are different than what follows, then implementors of RPCSEC_GSS will be obliged to map them into the values defined below. If in the future, the GSS-API definition defines additional status codes not defined below, then the RPCSEC_GSS definition will subsume those additional values.
Here are the definitions of each GSS_S_* major status that the implementor of RPCSEC_GSS can expect in the gss_major major field of rpc_gss_init_res. These definitions are not in RPC description language form. The numbers are in base 16 (hexadecimal):
Here are the definitions of each GSS_S_* major status that the implementor of RPCSEC_GSS can expect in the gss_major major field of rpc_gss_init_res. These definitions are not in RPC description language form. The numbers are in base 16 (hexadecimal):
GSS_S_COMPLETE 0x00000000
GSS_S_CONTINUE_NEEDED 0x00000001
GSS_S_DUPLICATE_TOKEN 0x00000002
GSS_S_OLD_TOKEN 0x00000004
GSS_S_UNSEQ_TOKEN 0x00000008
GSS_S_GAP_TOKEN 0x00000010
GSS_S_BAD_MECH 0x00010000
GSS_S_BAD_NAME 0x00020000
GSS_S_BAD_NAMETYPE 0x00030000
GSS_S_BAD_BINDINGS 0x00040000
GSS_S_BAD_STATUS 0x00050000
GSS_S_BAD_MIC 0x00060000
GSS_S_BAD_SIG 0x00060000
GSS_S_NO_CRED 0x00070000
GSS_S_NO_CONTEXT 0x00080000
GSS_S_DEFECTIVE_TOKEN 0x00090000
GSS_S_DEFECTIVE_CREDENTIAL 0x000a0000
GSS_S_CREDENTIALS_EXPIRED 0x000b0000
GSS_S_CONTEXT_EXPIRED 0x000c0000
GSS_S_FAILURE 0x000d0000
GSS_S_BAD_QOP 0x000e0000
GSS_S_UNAUTHORIZED 0x000f0000
GSS_S_UNAVAILABLE 0x00100000
GSS_S_DUPLICATE_ELEMENT 0x00110000
GSS_S_NAME_NOT_MN 0x00120000
GSS_S_CALL_INACCESSIBLE_READ 0x01000000
GSS_S_CALL_INACCESSIBLE_WRITE 0x02000000
GSS_S_CALL_BAD_STRUCTURE 0x03000000
GSS_S_COMPLETE 0x00000000 GSS_S_CONTINUE_NEEDED 0x00000001 GSS_S_DUPLICATE_TOKEN 0x00000002 GSS_S_OLD_TOKEN 0x00000004 GSS_S_UNSEQ_TOKEN 0x00000008 GSS_S_GAP_TOKEN 0x00000010 GSS_S_BAD_MECH 0x00010000 GSS_S_BAD_NAME 0x00020000 GSS_S_BAD_NAMETYPE 0x00030000 GSS_S_BAD_BINDINGS 0x00040000 GSS_S_BAD_STATUS 0x00050000 GSS_S_BAD_MIC 0x00060000 GSS_S_BAD_SIG 0x00060000 GSS_S_NO_CRED 0x00070000 GSS_S_NO_CONTEXT 0x00080000 GSS_S_DEFECTIVE_TOKEN 0x00090000 GSS_S_DEFECTIVE_CREDENTIAL 0x000a0000 GSS_S_CREDENTIALS_EXPIRED 0x000b0000 GSS_S_CONTEXT_EXPIRED 0x000c0000 GSS_S_FAILURE 0x000d0000 GSS_S_BAD_QOP 0x000e0000 GSS_S_UNAUTHORIZED 0x000f0000 GSS_S_UNAVAILABLE 0x00100000 GSS_S_DUPLICATE_ELEMENT 0x00110000 GSS_S_NAME_NOT_MN 0x00120000 GSS_S_CALL_INACCESSIBLE_READ 0x01000000 GSS_S_CALL_INACCESSIBLE_WRITE 0x02000000 GSS_S_CALL_BAD_STRUCTURE 0x03000000
Eisler, et. al. Standards Track [Page 20] RFC 2203 RPCSEC_GSS Protocol Specification September 1997
Eisler, et. al. Standards Track [Page 20] RFC 2203 RPCSEC_GSS Protocol Specification September 1997
Note that the GSS-API major status is split into three fields as follows:
Note that the GSS-API major status is split into three fields as follows:
Most Significant Bit Least Significant Bit
|------------------------------------------------------------|
| Calling Error | Routine Error | Supplementary Info |
|------------------------------------------------------------|
Bit 31 24 23 16 15 0
Most Significant Bit Least Significant Bit |------------------------------------------------------------| | Calling Error | Routine Error | Supplementary Info | |------------------------------------------------------------| Bit 31 24 23 16 15 0
Up to one status in the Calling Error field can be logically ORed with up to one status in the Routine Error field which in turn can be logically ORed with zero or more statuses in the Supplementary Info field. If the resulting major status has a non-zero Calling Error and/or a non-zero Routine Error, then the applicable GSS-API operation has failed. For purposes of RPCSEC_GSS, this means that the GSS_Accept_sec_context() call executed by the server has failed.
Up to one status in the Calling Error field can be logically ORed with up to one status in the Routine Error field which in turn can be logically ORed with zero or more statuses in the Supplementary Info field. If the resulting major status has a non-zero Calling Error and/or a non-zero Routine Error, then the applicable GSS-API operation has failed. For purposes of RPCSEC_GSS, this means that the GSS_Accept_sec_context() call executed by the server has failed.
If the major status is equal GSS_S_COMPLETE, then this indicates the absence of any Errors or Supplementary Info.
If the major status is equal GSS_S_COMPLETE, then this indicates the absence of any Errors or Supplementary Info.
The meanings of most of the GSS_S_* status are defined in the GSS-API definition, which the exceptions of:
The meanings of most of the GSS_S_* status are defined in the GSS-API definition, which the exceptions of:
GSS_S_BAD_MIC This code has the same meaning as GSS_S_BAD_SIG.
GSS_S_BAD_MIC This code has the same meaning as GSS_S_BAD_SIG.
GSS_S_CALL_INACCESSIBLE_READ
A required input parameter could not be read.
GSS_S_CALL_INACCESSIBLE_READ A required input parameter could not be read.
GSS_S_CALL_INACCESSIBLE_WRITE
A required input parameter could not be written.
GSS_S_CALL_INACCESSIBLE_WRITE A required input parameter could not be written.
GSS_S_CALL_BAD_STRUCTURE
A parameter was malformed.
GSS_S_CALL_BAD_STRUCTURE A parameter was malformed.
Eisler, et. al. Standards Track [Page 21] RFC 2203 RPCSEC_GSS Protocol Specification September 1997
Eisler, et. al. Standards Track [Page 21] RFC 2203 RPCSEC_GSS Protocol Specification September 1997
Acknowledgements
Acknowledgements
Much of the protocol was based on the AUTH_GSSAPI security flavor developed by Open Vision Technologies [Jaspan]. In particular, we acknowledge Barry Jaspan, Marc Horowitz, John Linn, and Ellen McDermott.
Much of the protocol was based on the AUTH_GSSAPI security flavor developed by Open Vision Technologies [Jaspan]. In particular, we acknowledge Barry Jaspan, Marc Horowitz, John Linn, and Ellen McDermott.
Raj Srinivasan designed RPCSEC_GSS [Eisler] with input from Mike Eisler. Raj, Roland Schemers, Lin Ling, and Alex Chiu contributed to Sun Microsystems' implementation of RPCSEC_GSS.
Raj Srinivasan designed RPCSEC_GSS [Eisler] with input from Mike Eisler. Raj, Roland Schemers, Lin Ling, and Alex Chiu contributed to Sun Microsystems' implementation of RPCSEC_GSS.
Brent Callaghan, Marc Horowitz, Barry Jaspan, John Linn, Hilarie Orman, Martin Rex, Ted Ts'o, and John Wroclawski analyzed the specification and gave valuable feedback.
Brent Callaghan, Marc Horowitz, Barry Jaspan, John Linn, Hilarie Orman, Martin Rex, Ted Ts'o, and John Wroclawski analyzed the specification and gave valuable feedback.
Steve Nahm and Kathy Slattery reviewed various drafts of this specification.
Steve Nahm and Kathy Slattery reviewed various drafts of this specification.
Much of content of Appendix A was excerpted from John Wray's Work in Progress on GSS-API Version 2 C-bindings.
Much of content of Appendix A was excerpted from John Wray's Work in Progress on GSS-API Version 2 C-bindings.
References
References
[Eisler] Eisler, M., Schemers, R., and Srinivasan, R.
(1996). "Security Mechanism Independence in ONC
RPC," Proceedings of the Sixth Annual USENIX
Security Symposium, pp. 51-65.
[Eisler] Eisler, M., Schemers, R., and Srinivasan, R. (1996). "Security Mechanism Independence in ONC RPC," Proceedings of the Sixth Annual USENIX Security Symposium, pp. 51-65.
[Jaspan] Jaspan, B. (1995). "GSS-API Security for ONC
RPC," `95 Proceedings of The Internet Society
Symposium on Network and Distributed System
Security, pp. 144- 151.
[Jaspan]Jaspan、B.(1995。) 「ONC RPCのためのGSS-API Security」、NetworkとDistributed System Security、ページのインターネット協会Symposiumの95年Proceedings 144- 151.
[Linn] Linn, J., "Generic Security Service Application
Program Interface, Version 2", RFC 2078, January
1997.
[リン]リン、J.、「ジェネリックセキュリティー・サービス適用業務プログラム・インタフェース、バージョン2インチ、RFC2078、1997年1月。」
[Srinivasan-bind] Srinivasan, R., "Binding Protocols for
ONC RPC Version 2", RFC 1833, August 1995.
[Srinivasan-ひも] Srinivasan、R.、「ONC RPCでプロトコルをバージョン2インチ縛るRFC1833、1995年8月。」
[Srinivasan-rpc] Srinivasan, R., "RPC: Remote Procedure Call
Protocol Specification Version 2", RFC 1831,
August 1995.
[Srinivasan-rpc]Srinivasan、R.、「RPC:」 遠隔手続き呼び出しプロトコル仕様バージョン2インチ、RFC1831、1995年8月。
[Srinivasan-xdr] Srinivasan, R., "XDR: External Data
Representation Standard", RFC 1832, August 1995.
[Srinivasan-xdr]Srinivasan、R.、「XDR:」 「外部データ表現規格」、RFC1832、1995年8月。
Eisler, et. al. Standards Track [Page 22] RFC 2203 RPCSEC_GSS Protocol Specification September 1997
etアイスラー、アル。 標準化過程[22ページ]RFC2203RPCSEC_GSSは仕様1997年9月に議定書を作ります。
Authors' Addresses
作者のアドレス
Michael Eisler Sun Microsystems, Inc. M/S UCOS03 2550 Garcia Avenue Mountain View, CA 94043
マイケル・アイスラー・サン・マイクロシステムズ・インクM/S UCOS03 2550ガルシア・Avenueマウンテンビュー、カリフォルニア 94043
Phone: +1 (719) 599-9026 EMail: mre@eng.sun.com
以下に電話をしてください。 +1 (719) 599-9026 メールしてください: mre@eng.sun.com
Alex Chiu Sun Microsystems, Inc. M/S UMPK17-203 2550 Garcia Avenue Mountain View, CA 94043
アレックスチウサン・マイクロシステムズ・インクM/S UMPK17-203 2550ガルシア・Avenueマウンテンビュー、カリフォルニア 94043
Phone: +1 (415) 786-6465 EMail: hacker@eng.sun.com
以下に電話をしてください。 +1 (415) 786-6465 メールしてください: hacker@eng.sun.com
Lin Ling Sun Microsystems, Inc. M/S UMPK17-201 2550 Garcia Avenue Mountain View, CA 94043
リン御柳もどきのサン・マイクロシステムズ・インクM/S UMPK17-201 2550ガルシア・Avenueマウンテンビュー、カリフォルニア 94043
Phone: +1 (415) 786-5084 EMail: lling@eng.sun.com
以下に電話をしてください。 +1 (415) 786-5084 メールしてください: lling@eng.sun.com
Eisler, et. al. Standards Track [Page 23]
etアイスラー、アル。 標準化過程[23ページ]
一覧
スポンサーリンク
