RFC1961 日本語訳
1961 GSS-API Authentication Method for SOCKS Version 5. P. McMahon. June 1996. (Format: TXT=16036 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. McMahon Request for Comments: 1961 ICL Category: Standards Track June 1996
コメントを求めるワーキンググループP.マクマホン要求をネットワークでつないでください: 1961年のICLカテゴリ: 標準化過程1996年6月
GSS-API Authentication Method for SOCKS Version 5
ソックスバージョンのためのGSS-API認証方法、5
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)の現行版を参照してください。 このメモの分配は無制限です。
Table of Contents
目次
1. Purpose ............................................ 1
2. Introduction ....................................... 1
3. GSS-API Security Context Establishment ............. 2
4. GSS-API Protection-level Options ................... 5
5. GSS-API Per-message Protection ..................... 7
6. GSS-API Security Context Termination ............... 8
7. References ......................................... 8
8. Acknowledgments .................................... 8
9. Security Considerations ............................ 8
10. Author's Address .................................. 9
1. 目的… 1 2. 序論… 1 3. GSS-APIセキュリティ文脈設立… 2 4. GSS-API保護レベルオプション… 5 5. 1メッセージあたりのGSS-API保護… 7 6. GSS-APIセキュリティ文脈終了… 8 7. 参照… 8 8. 承認… 8 9. セキュリティ問題… 8 10. 作者のアドレス… 9
1. Purpose
1. 目的
The protocol specification for SOCKS Version 5 specifies a generalized framework for the use of arbitrary authentication protocols in the initial SOCKS connection setup. This document provides the specification for the SOCKS V5 GSS-API authentication protocol, and defines a GSS-API-based encapsulation for provision of integrity, authentication and optional confidentiality.
SOCKSバージョン5のためのプロトコル仕様は初期のSOCKS接続設定における任意の認証プロトコルの使用に一般化されたフレームワークを指定します。 このドキュメントは、SOCKS V5 GSS-API認証プロトコルに仕様を提供して、保全、認証、および任意の秘密性の支給のためにGSS APIベースのカプセル化を定義します。
2. Introduction
2. 序論
GSS-API provides an abstract interface which provides security services for use in distributed applications, but isolates callers from specific security mechanisms and implementations.
GSS-APIは分配されたアプリケーションにおける使用にセキュリティー・サービスを提供しますが、特定のセキュリティー対策と実装から訪問者を隔離する抽象的なインタフェースを提供します。
GSS-API peers achieve interoperability by establishing a common security mechanism for security context establishment - either through administrative action, or through negotiation. GSS-API is specified in [RFC 1508], and [RFC 1509]. This specification is intended for use with implementations of GSS-API, and the emerging
GSS-API同輩は、管理動作を通して、または、セキュリティ文脈設立、交渉を通して共通の安全保障メカニズムを確立することによって、相互運用性を達成します。 GSS-APIは[RFC1508]、および[RFC1509]で指定されます。 この仕様はGSS-APIの実装、および現れによる使用のために意図します。
McMahon Standards Track [Page 1] RFC 1961 GSS-API Authentication for SOCKS V5 June 1996
ソックスV5 June 1996のためのマクマホン標準化過程[1ページ]RFC1961GSS-API認証
GSS-API V2 specification.
GSS-API V2仕様。
The approach for use of GSS-API in SOCKS V5 is to authenticate the client and server by successfully establishing a GSS-API security context - such that the GSS-API encapsulates any negotiation protocol for mechanism selection, and the agreement of security service options.
SOCKS V5におけるGSS-APIの使用のためのアプローチは首尾よくGSS-APIセキュリティ文脈を確立することによってクライアントとサーバを認証することです--GSS-APIがメカニズム選択のためのどんな交渉プロトコル、およびセキュリティー・サービスオプションの協定もカプセル化するようなもの。
The GSS-API enables the context initiator to know what security services the target supports for the chosen mechanism. The required level of protection is then agreed by negotiation.
GSS-APIは、文脈創始者が、目標が選ばれたメカニズムのためにどんなセキュリティー・サービスをサポートするかを知っているのを可能にします。 そして、交渉で必要なレベルの保護は同意されます。
The GSS-API per-message protection calls are subsequently used to encapsulate any further TCP and UDP traffic between client and server.
1メッセージあたりのGSS-API保護呼び出しは、次に、TCPとUDPがクライアントとサーバの間のトラフィックであるとこれ以上カプセル化するのに使用されます。
3. GSS-API Security Context Establishment
3. GSS-APIセキュリティ文脈設立
3.1 Preparation
3.1 準備
Prior to use of GSS-API primitives, the client and server should be locally authenticated, and have established default GSS-API credentials.
GSS-API基関数の使用の前に、クライアントとサーバは、局所的に認証されて、デフォルトGSS-API資格証明書を確立するべきでした。
The client should call gss_import_name to obtain an internal representation of the server name. For maximal portability the default name_type GSS_C_NULL_OID should be used to specify the default name space, and the input name_string should treated by the client's code as an opaque name-space specific input.
クライアントは、gss_をサーバー名の内部の表現を得る輸入_名前と呼ぶべきです。 _デフォルト名_タイプGSS_C NULL_OIDが使用するべきである最大限度の移植性において、スペースというデフォルト名を指定するのにおいて使用されてください。そうすれば、不透明な名前空間特定の入力としてクライアントのコードによって扱われて、入力名前_ストリングは使用するべきです。
For example, when using Kerberos V5 naming, the imported name may be of the form "SERVICE:socks@socks_server_hostname" where "socks_server_hostname" is the fully qualified host name of the server with all letters in lower case. Other mechanisms may, however, have different name forms, so the client should not make assumptions about the name syntax.
ケルベロスV5命名を使用するとき、例えば、インポートしている名前は「ソックス_サーバ_ホスト名」がサーバの完全に適切なホスト名であるところのすべての手紙が小文字にあるフォーム「サービス: socks@socks_server_hostname 」のものであるかもしれません。 しかしながら、他のメカニズムには異なった名前フォームがあるかもしれないので、クライアントは構文という名前に関する仮定をするべきではありません。
3.2 Client Context Establishment
3.2 クライアント文脈設立
The client should then call gss_init_sec_context, typically passing:
そして、以下を通常通過して、クライアントは、gss_イニットを_秒_文脈と呼ぶべきです。
GSS_C_NO_CREDENTIAL into cred_handle to specify the default
credential (for initiator usage),
信用_へのCREDENTIALがデフォルト資格証明書(創始者用法のための)を指定するために扱うGSS_C_ノー_
GSS_C_NULL_OID into mech_type to specify the default
mechanism,
GSS_C_NULL_OIDは、デフォルトメカニズムを指定するためにmech_にタイプします。
McMahon Standards Track [Page 2] RFC 1961 GSS-API Authentication for SOCKS V5 June 1996
ソックスV5 June 1996のためのマクマホン標準化過程[2ページ]RFC1961GSS-API認証
GSS_C_NO_CONTEXT into context_handle to specify a NULL
context (initially), and,
文脈_へのCONTEXTがそして、(初めは)NULL文脈を指定するために扱うGSS_C_ノー_
the previously imported server name into target_name.
目標_名前への以前にインポートしているサーバー名。
The client must also specify its requirements for replay protection, delegation, and sequence protection via the gss_init_sec_context req_flags parameter. It is required by this specification that the client always requests these service options (i.e. passes GSS_C_MUTUAL_FLAG | GSS_C_REPLAY_FLAG | GSS_C_DELEG_FLAG | GSS_C_SEQUENCE_FLAG into req_flags).
また、クライアントはgss_イニット_秒_文脈req_フラッグ変数で反復操作による保護、委譲、および系列保護のための要件を指定しなければなりません。 クライアントがいつもこれらのサービスオプション(_すなわち、パスGSS_C MUTUAL_FLAG| _GSS_C_REPLAY_FLAG| GSS_C DELEG_FLAG| _req_旗へのGSS_C SEQUENCE_FLAG)を要求するのがこの仕様によって必要とされます。
However, GSS_C_SEQUENCE_FLAG should only be passed in for TCP-based clients, not for UDP-based clients.
しかしながら、GSS_C_SEQUENCE_FLAGはUDPベースのクライアントではなく、TCPベースのクライアントを受けそうで渡されるだけであるべきです。
3.3 Client Context Establishment Major Status codes
3.3 クライアントContext特権階級メージャーStatusコード
The gss_init_sec_context returned status code can take two different success values:
gss_イニットの_の秒_文脈の返されたステータスコードは2つの異なった成功値を取ることができます:
- If gss_init_sec_context returns GSS_S_CONTINUE_NEEDED, then the
client should expect the server to issue a token in the
subsequent subnegotiation response. The client must pass the
token to another call to gss_init_sec_context, and repeat this
procedure until "continue" operations are complete.
- gss_イニット_秒_文脈がCONTINUE_が必要としたGSS_S_を返すなら、クライアントは、サーバがその後の副交渉応答におけるトークンを発行すると予想するべきです。 「続いてください」という操作が完全になるまで、クライアントは、gss_イニット_秒_文脈への別の呼び出しにトークンを通過して、この手順を繰り返さなければなりません。
- If gss_init_sec_context returns GSS_S_COMPLETE, then the client
should respond to the server with any resulting output_token.
- gss_イニット_秒_文脈が_GSS_S COMPLETEを返すなら、クライアントはどんな結果として起こる出力_トークンでもサーバに応じるべきです。
If there is no output_token, the client should proceed to send
the protected request details, including any required message
protection subnegotiation as specified in sections 4 and 5
below.
出力_トークンが全くなければ、クライアントは保護された要求の詳細を送るべきでありかけます、下のセクション4と5での指定されるとしてのどんな必要なメッセージ保護副交渉も含んでいて。
3.4 Client initial token
3.4 クライアントの初期のトークン
The client's GSS-API implementation then typically responds with the resulting output_token which the client sends in a message to the server.
そして、クライアントのGSS-API実行はクライアントがメッセージでサーバに送る結果として起こる出力_トークンで通常応じます。
+------+------+------+.......................+
+ ver | mtyp | len | token |
+------+------+------+.......................+
+ 0x01 | 0x01 | 0x02 | up to 2^16 - 1 octets |
+------+------+------+.......................+
+------+------+------+.......................+ + ver| mtyp| len| トークン| +------+------+------+.......................+ + 0×01| 0×01| 0×02| 最大2^16--1八重奏| +------+------+------+.......................+
McMahon Standards Track [Page 3] RFC 1961 GSS-API Authentication for SOCKS V5 June 1996
ソックスV5 June 1996のためのマクマホン標準化過程[3ページ]RFC1961GSS-API認証
Where:
どこ:
- "ver" is the protocol version number, here 1 to represent the
first version of the SOCKS/GSS-API protocol
- "ver"がプロトコルバージョン番号である、ここで、SOCKS/GSS-APIの最初のバージョンを表す1は議定書を作ります。
- "mtyp" is the message type, here 1 to represent an
authentication message
- "mtyp"がメッセージタイプである、ここで、認証を表す1は通信します。
- "len" is the length of the "token" field in octets
- "len"は八重奏で、「トークン」分野の長さです。
- "token" is the opaque authentication token emitted by GSS-API
- 「トークン」はGSS-APIによって放たれた不透明な認証トークンです。
3.5 Client GSS-API Initialisation Failure
3.5 クライアントGSS-API初期設定失敗
If, however, the client's GSS-API implementation failed during gss_init_sec_context, the client must close its connection to the server.
しかしながら、クライアントのGSS-API実行がgss_イニット_秒_文脈の間、失敗したなら、クライアントは接続をサーバに終えなければなりません。
3.6 Server Context Establishment
3.6 サーバ文脈設立
For the case where a client successfully sends a token emitted by gss_init_sec_context() to the server, the server must pass the client-supplied token to gss_accept_sec_context as input_token.
クライアントが首尾よくgss_イニット_秒_文脈()によってサーバに放たれたトークンを送って、サーバがクライアントによって供給されたトークンをgss_に通過しなければならないケースには、_トークンを入力するので、_秒_文脈を受け入れてください。
When calling gss_accept_sec_context() for the first time, the context_handle argument is initially set to GSS_C_NO_CONTEXT.
gssを_と呼ぶときには初めて_秒_文脈()を受け入れてください、そして、文脈_ハンドル議論は初めは、_GSS_Cいいえ_CONTEXTに設定されます。
For portability, verifier_cred_handle is set to GSS_C_NO_CREDENTIAL to specify default credentials (for acceptor usage).
移植性において、_GSS_Cいいえ_CREDENTIALに検証_信用_ハンドルがデフォルト資格証明書(アクセプタ用法のための)を指定するように設定されます。
If gss_accept_sec_context returns GSS_CONTINUE_NEEDED, the server should return the generated output_token to the client, and subsequently pass the resulting client supplied token to another call to gss_accept_sec_context.
サーバは発生している出力_トークンをクライアントに返すべきです、そして、gss_であるなら、_GSS_CONTINUE_が必要とした秒_文脈リターンを受け入れてください、そして、次に結果として起こるクライアントがgss_への別の呼び出しへのトークンを供給したパスは_秒_文脈を受け入れます。
If gss_accept_sec_context returns GSS_S_COMPLETE, then, if an output_token is returned, the server should return it to the client.
gss_であるなら、_文脈が_GSS_S COMPLETEを返す_秒を受け入れてください、そして、出力_トークンを返すなら、次に、サーバはそれをクライアントに返すべきです。
If no token is returned, a zero length token should be sent by the server to signal to the client that it is ready to receive the client's request.
トークンを全く返さないなら、サーバでゼロ・レングストークンを送って、それがクライアントの要求を受け取る準備ができているとクライアントに合図するべきです。
McMahon Standards Track [Page 4] RFC 1961 GSS-API Authentication for SOCKS V5 June 1996
ソックスV5 June 1996のためのマクマホン標準化過程[4ページ]RFC1961GSS-API認証
3.7 Server Reply
3.7 サーバ回答
In all continue/confirmation cases, the server uses the same message type as for the client -> server interaction.
すべてでは、/確認ケースを続けてください、そして、サーバはクライアント->サーバ相互作用のように同じメッセージタイプを使用します。
+------+------+------+.......................+
+ ver | mtyp | len | token |
+------+------+------+.......................+
+ 0x01 | 0x01 | 0x02 | up to 2^16 - 1 octets |
+------+------+------+.......................+
+------+------+------+.......................+ + ver| mtyp| len| トークン| +------+------+------+.......................+ + 0×01| 0×01| 0×02| 最大2^16--1八重奏| +------+------+------+.......................+
3.8 Security Context Failure
3.8 セキュリティ文脈失敗
If the server refuses the client's connection for any reason (GSS-API authentication failure or otherwise), it will return:
サーバがどんな理由のためのクライアントの接続(GSS-API認証失敗であるかそうでない)も拒否すると、戻るでしょう:
+------+------+
+ ver | mtyp |
+------+------+
+ 0x01 | 0xff |
+------+------+
+------+------+ + ver| mtyp| +------+------+ + 0×01| 0xff| +------+------+
Where:
どこ:
- "ver" is the protocol version number, here 1 to represent the
first version of the SOCKS/GSS-API protocol
- "ver"がプロトコルバージョン番号である、ここで、SOCKS/GSS-APIの最初のバージョンを表す1は議定書を作ります。
- "mtyp" is the message type, here 0xff to represent an abort
message
- "mtyp"がメッセージタイプである、ここで、アボートを表す0xffは通信します。
4. GSS-API Protection-level Options
4. GSS-API保護レベルオプション
4.1 Message protection
4.1 メッセージ保護
Establishment of a GSS-API security context enables comunicating peers to determine which per-message protection services are available to them through the gss_init_sec_context() and gss_accept_sec_context() ret_flags GSS_C_INTEG_FLAG and GSS_C_CONF_FLAG which respectively indicate message integrity and confidentiality services.
GSS-APIセキュリティ文脈の確立は、同輩をcomunicatingするのが、それらに、保護サービスがgss_イニット_秒_文脈()を通して利用可能であり、gss_が_秒_文脈()を受け入れるというどのメッセージが_それぞれメッセージの保全と秘密性サービスを示す旗_GSS_C INTEG_FLAGと_GSS_C CONF_FLAGを浸水させるかを決定するのを可能にします。
It is necessary to ensure that the message protection applied to the traffic is appropriate to the sensitivity of the data, and the severity of the threats.
トラフィックに適用されたメッセージ保護が確実にデータの感度、および脅威の厳しさに適切になるようにするのが必要です。
McMahon Standards Track [Page 5] RFC 1961 GSS-API Authentication for SOCKS V5 June 1996
ソックスV5 June 1996のためのマクマホン標準化過程[5ページ]RFC1961GSS-API認証
4.2 Message Protection Subnegotiation
4.2 メッセージ保護Subnegotiation
For TCP and UDP clients and servers, different levels of protection are possible in the SOCKS V5 protocol, so an additional subnegotiation stage is needed to agree the message protection level. After successful completion of this subnegotiation, TCP and UDP clients and servers use GSS-API encapsulation as defined in section 5.1.
TCP、UDPクライアント、およびサーバにおいて、保護の異なったレベルがSOCKS V5プロトコルで可能であるので、追加副交渉ステージがメッセージ保護レベルに同意するのに必要です。 この副交渉の無事終了の後に、TCP、UDPクライアント、およびサーバはセクション5.1で定義されるようにGSS-APIカプセル化を使用します。
After successful establishment of a GSS-API security context, the client's GSS-API implementation sends its required security context protection level to the server. The server then returns the security context protection level which it agrees to - which may or may not take the the client's request into account.
GSS-APIセキュリティ文脈のうまくいっている確立の後に、クライアントのGSS-API実行は必要なセキュリティ文脈保護レベルをサーバに送ります。次に、サーバはそれが同意するセキュリティ文脈保護レベル(クライアントの要求を考慮に入れるかもしれない)を返します。
The security context protection level sent by client and server must be one of the following values:
クライアントとサーバによって送られたセキュリティ文脈保護レベルは以下の値の1つであるに違いありません:
1 required per-message integrity
2 required per-message integrity and confidentiality
3 selective per-message integrity or confidentiality based on
local client and server configurations
1 1メッセージの保全あたりの必要な2必要なメッセージの保全と秘密性3の選択しているメッセージの保全か地元のクライアントとサーバ構成に基づく秘密性
It is anticipated that most implementations will agree on level 1 or 2 due to the practical difficulties in applying selective controls to messages passed through a socks library.
ほとんどの実装がソックスライブラリに通り抜けるメッセージに選択的統制を適用することにおける実用的な苦労のためレベル1か2に同意すると予期されます。
4.3 Message Protection Subnegotiation Message Format
4.3 メッセージ保護Subnegotiationメッセージ・フォーマット
The security context protection level is sent from client to server and vice versa using the following protected message format:
セキュリティ文脈保護レベルはクライアントからサーバに送られました、そして、逆もまた同様に以下を使用すると、メッセージ・フォーマットは保護されました:
+------+------+------+.......................+
+ ver | mtyp | len | token |
+------+------+------+.......................+
+ 0x01 | 0x02 | 0x02 | up to 2^16 - 1 octets |
+------+------+------+.......................+
+------+------+------+.......................+ + ver| mtyp| len| トークン| +------+------+------+.......................+ + 0×01| 0×02| 0×02| 最大2^16--1八重奏| +------+------+------+.......................+
Where:
どこ:
- "ver" is the protocol version number, here 1 to represent the
first version of the SOCKS/GSS-API protocol
- "ver"がプロトコルバージョン番号である、ここで、SOCKS/GSS-APIの最初のバージョンを表す1は議定書を作ります。
- "mtyp" is the message type, here 2 to represent a protection
-level negotiation message
- "mtyp"がメッセージタイプである、ここに、保護を表す2は交渉メッセージを平らにします。
- "len" is the length of the "token" field in octets
- "len"は八重奏で、「トークン」分野の長さです。
McMahon Standards Track [Page 6] RFC 1961 GSS-API Authentication for SOCKS V5 June 1996
ソックスV5 June 1996のためのマクマホン標準化過程[6ページ]RFC1961GSS-API認証
- "token" is the GSS-API encapsulated protection level
- 「トークン」は保護レベルであるとカプセル化されたGSS-APIです。
4.4 Message Protection Subnegotiation Message Generation
4.4メッセージ保護Subnegotiationメッセージ世代
The token is produced by encapsulating an octet containing the required protection level using gss_seal()/gss_wrap() with conf_req set to FALSE. The token is verified using gss_unseal()/ gss_unwrap().
トークンは、FALSEに用意ができているconf_reqでgss_シール()/gss_包装()を使用することで必要な保護レベルを含む八重奏をカプセル化することによって、生産されます。 トークンは_が開くgssを使用することで確かめられて、()/gss_が()を開けるということです。
If the server's choice of protection level is unacceptable to the client, then the client must close its connection to the server
クライアントにとって、保護レベルのサーバの選択が容認できないなら、クライアントは接続をサーバに終えなければなりません。
5. GSS-API Per-message Protection
5. 1メッセージあたりのGSS-API保護
For TCP and UDP clients and servers, the GSS-API functions for encapsulation and de-encapsulation shall be used by implementations - i.e. gss_seal()/gss_wrap(), and gss_unseal()/ gss_unwrap().
TCP、UDPクライアント、およびサーバのために、カプセル化と反-カプセル化のためのGSS-API関数は実装によって使用されるものとします--すなわち、gss_シール()/のgss_包装()、およびgss_は()/gssを開きます。_()を開けてください。
The default value of quality of protection shall be specified, and the use of conf_req_flag shall be as determined by the previous subnegotiation step. If protection level 1 is agreed then conf_req_flag MUST always be FALSE; if protection level 2 is agreed then conf_req_flag MUST always be TRUE; and if protection level 3 is agreed then conf_req is determined on a per-message basis by client and server using local configuration.
保護の品質のデフォルト値は指定されるものとします、そして、conf_req_旗の使用は前の副交渉ステップで同じくらい決定するでしょう。 _保護レベル1が同意された当時のconfであるなら、いつもreq_旗はFALSEであるに違いありません。 _保護レベル2が同意された当時のconfであるなら、いつもreq_旗はTRUEであるに違いありません。 _そして、保護レベル3が同意された当時のconfであるなら、reqは、クライアントとサーバによる1メッセージあたり1個のベースで地方の構成を使用することで断固としています。
All encapsulated messages are prefixed by the following framing:
メッセージであるとカプセル化されたすべてが以下の縁どりで前に置かれています:
+------+------+------+.......................+
+ ver | mtyp | len | token |
+------+------+------+.......................+
+ 0x01 | 0x03 | 0x02 | up to 2^16 - 1 octets |
+------+------+------+.......................+
+------+------+------+.......................+ + ver| mtyp| len| トークン| +------+------+------+.......................+ + 0×01| 0×03| 0×02| 最大2^16--1八重奏| +------+------+------+.......................+
Where:
どこ:
- "ver" is the protocol version number, here 1 to represent the
first version of the SOCKS/GSS-API protocol
- "ver"がプロトコルバージョン番号である、ここで、SOCKS/GSS-APIの最初のバージョンを表す1は議定書を作ります。
- "mtyp" is the message type, here 3 to represent encapulated user
data
- "mtyp"がメッセージタイプである、ここで、表す3は利用者データをencapulatedしました。
- "len" is the length of the "token" field in octets
- "len"は八重奏で、「トークン」分野の長さです。
- "token" is the user data encapsulated by GSS-API
- 「トークン」はGSS-APIによってカプセル化された利用者データです。
McMahon Standards Track [Page 7] RFC 1961 GSS-API Authentication for SOCKS V5 June 1996
ソックスV5 June 1996のためのマクマホン標準化過程[7ページ]RFC1961GSS-API認証
6. GSS-API Security Context Termination
6. GSS-APIセキュリティ文脈終了
The GSS-API context termination message (emitted by gss_delete_sec_context) is not used by this protocol.
GSS-API文脈終了メッセージ(_gssによって放たれて、_秒_文脈を削除する)はこのプロトコルによって使用されません。
When the connection is closed, each peer invokes gss_delete_sec_context() passing GSS_C_NO_BUFFER into the output_token argument.
いつ、接続があるかは閉じて、各同輩はgssを呼び出します。__いいえ_BUFFERをGSS_Cに渡しながら、_秒_文脈()を出力_トークン議論に削除してください。
7. References
7. 参照
[RFC 1508] Linn, J., "Generic Security Service API",
September 1993.
[RFC1508] リン、J.、「ジェネリックセキュリティー・サービスAPI」、1993年9月。
[RFC 1509] Wray, J., "Generic Security Service API : C-bindings",
September 1993.
[RFC1509] レイ、J.、「ジェネリックセキュリティはAPIを調整します」。 1993年9月の「C-結合。」
[SOCKS V5] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D.,
and L. Jones, "SOCKS Protocol V5", RFC 1928, April
1996.
[ソックスV5] ヒル、M.、Ganis M.、リー、Y.、Kuris、R.、Koblas、D.、およびL.ジョーンズ、「ソックスはV5"について議定書の中で述べます、RFC1928、1996年4月。」
8. Acknowledgment
8. 承認
This document builds from a previous memo produced by Marcus Leech (BNR) - whose comments are gratefully acknowleged. It also reflects input from the AFT WG, and comments arising from implementation experience by Xavier Gosselin (IUT Lyons).
このドキュメントはマーカスLeech(BNR)(コメントは感謝してacknowlegedされる)によって製作された前のメモから建てられます。 また、それはAFT WG、およびザビエルGosselin(IUTリヨン)による実装経験から起こるコメントから入力を反映します。
9. Security Considerations
9. セキュリティ問題
The security services provided through the GSS-API are entirely dependent on the effectiveness of the underlying security mechanisms, and the correctness of the implementation of the underlying algorithms and protocols.
GSS-APIを通して提供されたセキュリティー・サービスは基本的なセキュリティー対策の有効性、および基本的なアルゴリズムとプロトコルの実装の正当性に完全に依存しています。
The user of a GSS-API service must ensure that the quality of protection provided by the mechanism implementation is consistent with their security policy.
GSS-APIサービスのユーザは、メカニズム実装によって提供された保護の品質が彼らの安全保障政策と一致しているのを保証しなければなりません。
In addition, where negotiation is supported under the GSS-API, constraints on acceptable mechanisms may be imposed to ensure suitability for application to authenticated firewall traversal.
さらに、交渉がGSS-APIの下でサポートされるところで許容できるメカニズムにおける規制は、認証されたファイアウォール縦断にアプリケーションへの適合を確実にするために課されるかもしれません。
McMahon Standards Track [Page 8] RFC 1961 GSS-API Authentication for SOCKS V5 June 1996
ソックスV5 June 1996のためのマクマホン標準化過程[8ページ]RFC1961GSS-API認証
10. Author's Address
10. 作者のアドレス
P. V. McMahon ICL Enterprises Kings House 33 Kings Road Reading, RG1 3PX UK
下院33列王紀道路読書、P.V.マクマホンICLエンタープライズRG1 3PXイギリス王
EMail: p.v.mcmahon@rea0803.wins.icl.co.uk Phone: +44 1734 634882 Fax: +44 1734 855106
メール: p.v.mcmahon@rea0803.wins.icl.co.uk 電話: +44 1734 634882、Fax: +44 1734 855106
McMahon Standards Track [Page 9]
マクマホン標準化過程[9ページ]
一覧
スポンサーリンク
