RFC2755 日本語訳
2755 Security Negotiation for WebNFS. A. Chiu, M. Eisler, B.Callaghan. January 2000. (Format: TXT=23493 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group A. Chiu Request for Comments: 2755 M. Eisler Category: Informational B. Callaghan Sun Microsystems January 2000
コメントを求めるワーキンググループA.チウの要求をネットワークでつないでください: 2755年のM.アイスラーカテゴリ: 情報のB.キャラハンサン・マイクロシステムズ2000年1月
Security Negotiation for WebNFS
WebNFSのためのセキュリティ交渉
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Abstract
要約
This document describes a protocol for a WebNFS client [RFC2054] to negotiate the desired security mechanism with a WebNFS server [RFC2055] before the WebNFS client falls back to the MOUNT v3 protocol [RFC1813]. This document is provided so that people can write compatible implementations.
WebNFSクライアントがプロトコル[RFC1813]v3山へ後ろへ下がる前にWebNFSクライアント[RFC2054]がWebNFSサーバ[RFC2055]と必要なセキュリティー対策を交渉するように、このドキュメントはプロトコルについて説明します。 人々がコンパチブル実装を書くことができるように、このドキュメントを提供します。
Table of Contents
目次
1. Introduction .............................................. 2 2. Security Negotiation Multi-component LOOKUP ............... 3 3 Overloaded Filehandle ..................................... 4 3.1 Overloaded NFS Version 2 Filehandle ..................... 5 3.2 Overloaded NFS Version 3 Filehandle ..................... 6 4. WebNFS Security Negotiation ............................... 6 5. Security Considerations ................................... 10 6. References ................................................ 10 7. Acknowledgements .......................................... 10 8. Authors' Addresses ........................................ 11 9. Full Copyright Statement .................................. 12
1. 序論… 2 2. セキュリティの交渉の多成分系のルックアップ… 3 3はFilehandleを積みすぎました… 4 3.1はNFSバージョン2Filehandleを積みすぎました… 5 3.2はNFSバージョン3Filehandleを積みすぎました… 6 4. WebNFSセキュリティ交渉… 6 5. セキュリティ問題… 10 6. 参照… 10 7. 承認… 10 8. 作者のアドレス… 11 9. 完全な著作権宣言文… 12
Chiu, et al. Informational [Page 1] RFC 2755 Security Negotiation for WebNFS January 2000
チウ、他 WebNFS2000年1月のための情報[1ページ]のRFC2755セキュリティ交渉
1. Introduction
1. 序論
The MOUNT protocol is used by an NFS client to obtain the necessary filehandle for data access. MOUNT versions 1 and 2 [RFC1094] return NFS version 2 filehandles, whereas MOUNT version 3 [RFC1813] returns NFS version 3 filehandles.
山のプロトコルは、必要なfilehandleをデータ・アクセスに入手するのにNFSクライアントによって使用されます。 山のバージョン1と2[RFC1094]はNFSバージョン2filehandlesを返しますが、山のバージョン3[RFC1813]はNFSバージョン3filehandlesを返します。
Among the existing versions of the MOUNT protocol, only the MOUNT v3 provides an RPC procedure (MOUNTPROC3_MNT) which facilitates security negotiation between an NFS v3 client and an NSF v3 server. When this RPC procedure succeeds (MNT3_OK) the server returns to the client an array of security mechanisms it supports for the specified pathname, in addition to an NFS v3 filehandle.
山のプロトコルの既存のバージョンの中では、v3山だけがNFS v3クライアントとNSF v3サーバとのセキュリティ交渉を容易にするRPC手順(MOUNTPROC3_MNT)を提供します。このRPC手順が(MNT3_OK)を引き継ぐとき、サーバはそれが指定されたパス名のためにサポートするセキュリティー対策の配列をクライアントに返します、NFS v3 filehandleに加えて。
A security mechanism referred to in this document is a generalized security flavor which can be an RPC authentication flavor [RFC1831] or a security flavor referred to in the RPCSEC_GSS protocol [RFC2203]. A security mechanism is represented as a four-octet integer.
示されたセキュリティー対策は、本書ではRPC認証特色であるかもしれない一般化されたセキュリティ風味[RFC1831]かRPCSEC_GSSプロトコルで言及されたセキュリティ風味[RFC2203]です。 セキュリティー対策は4八重奏の整数として表されます。
No RPC procedures are available for security negotiation in versions 1 or 2 of the MOUNT protocol.
どんなRPC手順も山のプロトコルのバージョン1か2におけるセキュリティ交渉に利用可能ではありません。
The NFS mount command provides a "sec=" option for an NFS client to specify the desired security mechanism to use for NFS transactions. If this mount option is not specified, the default action is to use the default security mechanism over NFS v2 mounts, or to negotiate a security mechanism via the MOUNTPROC3_MNT procedure of MOUNT v3 and use it over NFS v3 mounts. In the latter, the client picks the first security mechanism in the array returned from the server that is also supported on the client.
NFSクライアントがNFSトランザクションに使用する必要なセキュリティー対策を指定するように、NFSマウントコマンドは「秒=」オプションを提供します。 このマウントオプションが指定されないなら、デフォルト動作は、NFS v2マウントの上にデフォルトセキュリティー対策を使用するか、v3山のMOUNTPROC3_MNT手順でセキュリティー対策を交渉して、またはNFS v3マウントの上にそれを使用することです。 後者では、クライアントはまた、クライアントの上でサポートされるサーバから返された配列における最初のセキュリティー対策を選びます。
As specified in RFC 2054, a WebNFS client first assumes that the server supports WebNFS and uses the publsc filehandle as the initial filehandle for data access, eliminating the need for the MOUNT protocol. The WebNFS client falls back to MOUNT if the server does not support WebNFS.
RFC2054で指定されるように、WebNFSクライアントは、最初にサーバがデータ・アクセスに初期のfilehandleとしてWebNFSをサポートして、publsc filehandleを使用すると仮定します、山のプロトコルの必要性を排除して。 サーバがWebNFSをサポートしないなら、WebNFSクライアントは山へ後ろへ下がります。
Since a WebNFS client does not use MOUNT initially, the MOUNTPROC3_MNT procedure of MOUNT v3 is not available for security negotiation until the WebNFS client falls back to MOUNT. A viable protocol needs to be devised for the WebNFS client to negotiate security mechanisms with the server in the absence of the MOUNTPROC3_MNT procedure.
WebNFSクライアントが初めは山を使用しないので、WebNFSクライアントが山へ後ろへ下がるまで、v3山のMOUNTPROC3_MNT手順はセキュリティ交渉に利用可能ではありません。 実行可能なプロトコルは、WebNFSクライアントがMOUNTPROC3_MNT手順がないときサーバとセキュリティー対策を交渉するように工夫される必要があります。
Chiu, et al. Informational [Page 2] RFC 2755 Security Negotiation for WebNFS January 2000
チウ、他 WebNFS2000年1月のための情報[2ページ]のRFC2755セキュリティ交渉
The WebNFS security negotiation protocol must meet the following requirements:
WebNFSセキュリティ交渉プロトコルは以下の必要条件を満たさなければなりません:
- Must work seamlessly with NFS v2 and v3, and the WebNFS protocols
- シームレスにNFS v2とv3との必須仕事、およびWebNFSプロトコル
- Must be backward compatible with servers that do not support this negotiation
- この交渉をサポートしないサーバと互換性があった状態で後方でなければなりません。
- Minimum number of network turnarounds (latency)
- 最小の数のネットワークターンアラウンド(潜在)
This document describes the WebNFS security negotiation protocol developed by Sun Microsystems, Inc. Terminology and definitions from RFCs 2054 and 2055 are used in this document. The reader is expected to be familiar with them.
このドキュメントはRFCs2054からサン・マイクロシステムズ・インクTerminologyと定義で開発されたWebNFSセキュリティ交渉プロトコルについて説明します、そして、2055は本書では使用されます。 読者がそれらによく知られさせると予想されます。
2. Security Negotiation Multi-component LOOKUP
2. セキュリティの交渉の多成分系のルックアップ
The goal of the WebNFS security negotiation is to allow a WebNFS client to identify a security mechanism which is used by the WebNFS server to protect a specified path and is also supported by the client. The WebNFS client initiates the negotiation by sending the WebNFS server the path. The WebNFS server responds with the array of security mechanisms it uses to secure the specified path. From the array of security mechanisms the WebNFS client selects the first one that it also supports.
WebNFSセキュリティ交渉の目標はWebNFSクライアントがWebNFSサーバによって使用されて、指定された経路を保護して、またクライアントがサポートされるセキュリティー対策を特定するのを許容することです。 WebNFSクライアントは、WebNFSサーバに経路を送ることによって、交渉を開始します。 WebNFSサーバはそれが指定された経路を保証するのに使用するセキュリティー対策の配列で反応します。 セキュリティー対策の配列から、WebNFSクライアントはまたそれがサポートする最初のものを選択します。
Without introducing a new WebNFS request, the WebNFS security negotiation is achieved by modifying the request and response of the existing multi-component LOOKUP (MCL) operation [RFC2055]. Note that the MCL operation is accomplished using the LOOKUP procedure (NFSPROC3_LOOKUP for NFS v3 and NFSPROC_LOOKUP for NFS v2). This and the next sections describe how the MCL request and response are modified to facilitate WebNFS security negotiation.
新しいWebNFS要求を紹介しないで、WebNFSセキュリティ交渉は、既存の多成分系のLOOKUP(MCL)操作[RFC2055]の要求と応答を変更することによって、達成されます。 MCL操作がLOOKUP手順(NFS v3のためのNFSPROC3_LOOKUPとNFS v2のためのNFSPROC_LOOKUP)を用いるのに優れていることに注意してください。 これと次のセクションはMCL要求と応答がWebNFSセキュリティ交渉を容易にするようにどう変更されるかを説明します。
For ease of reference, the modified MCL request is henceforth referred to as SNEGO-MCL (security negotiation multi-component LOOKUP) request.
参照する場合に便利なように、変更されたMCL要求は今後は、SNEGO-MCL(セキュリティ交渉の多成分系のLOOKUP)要求と呼ばれます。
A multi-component LOOKUP request [RFC2055] is composed of a public filehandle and a multi-component path:
多成分系のLOOKUP要求[RFC2055]は公共のfilehandleと多成分系の経路で構成されます:
For Canonical Path:
正準な経路に:
LOOKUP FH=0x0, "/a/b/c"
ルックアップFH=0x0、"/a/b/c"
Chiu, et al. Informational [Page 3] RFC 2755 Security Negotiation for WebNFS January 2000
チウ、他 WebNFS2000年1月のための情報[3ページ]のRFC2755セキュリティ交渉
For Native Path:
ネイティブの経路に:
LOOKUP FH=0x0, 0x80 "a:b:c"
ルックアップFH=0×0、0x80「a:b:c」
A multi-component path is either an ASCII string of slash separated components or a 0x80 character followed by a native path. Note that a multi-component LOOKUP implies the use of the public filehandle in the LOOKUP.
多成分系の経路は切り離されたコンポーネントか0×80キャラクタがネイティブの経路で後をつけたスラッシュのASCIIストリングです。 多成分系のLOOKUPがLOOKUPにおける公共のfilehandleの使用を含意することに注意してください。
Similar to the MCL request, a SNEGO-MCL request consists of a public filehandle and a pathname. However, the pathname is uniquely composed, as described below, to distinguish it from other pathnames.
MCL要求と同様であることで、SNEGO-MCL要求は公共のfilehandleとパス名から成ります。 しかしながら、パス名は他のパス名とそれを区別するために以下で説明されるように唯一構成されます。
The pathname used in a SNEGO-MCL is the regular WebNFS multi- component path prefixed with two octets. The first prefixed octet is the 0x81 non-ascii character, similar to the 0x80 non-ascii character for the native paths. This octet represents client's indication to negotiate security mechanisms. It is followed by the security index octet which stores the current value of the index into the array of security mechanisms to be returned from the server. The security index always starts with one and gets incremented as negotiation continues. It is then followed by the pathname, either an ASCII string of slash separated canonical components or 0x80 and a native path.
SNEGO-MCLで使用されるパス名は2つの八重奏で前に置かれた通常のWebNFSマルチコンポーネント経路です。 最初の前に置かれた八重奏はネイティブの経路に、0×80非ASCIIキャラクタと同様の0×81非ASCIIキャラクタです。 この八重奏は、セキュリティー対策を交渉するためにクライアントの指示を表します。サーバから返されるセキュリティー対策の配列としてインデックスの現行価値を保存するセキュリティインデックス八重奏はそれのあとに続いています。セキュリティインデックスは、いつも1つから始めて、交渉が続くように増加されます。 そして、パス名で、スラッシュのASCIIストリングが正準なコンポーネントか0×80とネイティブの経路を切り離したということになられます。
A security negotiation multi-component LOOKUP request looks like this:
多成分系のLOOKUPが要求するセキュリティ交渉はこれに似ています:
For Canonical Path:
正準な経路に:
LOOKUP FH=0x0, 0x81 <sec-index> "/a/b/c"
ルックアップFH=0×0、0x81<秒インデックス>"/a/b/c"
For Native Path:
ネイティブの経路に:
LOOKUP FH=0x0, 0x81 <sec-index> 0x80 "a:b:c"
ルックアップFH=0×0、0x81<秒インデックス>0x80「a:b:c」
In the next section we will see how the MCL response is modified for WebNFS security negotiation.
私たちは次のセクションの、MCL応答がWebNFSセキュリティ交渉のためにどう変更されるかを見るでしょう。
3. Overloaded Filehandle
3. 積みすぎられたFilehandle
As described in RFC2054, if a multi-component LOOKUP request succeeds, the server responds with a valid filehandle:
RFC2054で説明されるように、多成分系のLOOKUP要求が成功するなら、サーバは有効なfilehandleで反応します:
LOOKUP FH=0x0, "a/b/c" -----------> <----------- FH=0x3
ルックアップFH=0x0、「/b/c」-----------><。----------- FH=0x3
Chiu, et al. Informational [Page 4] RFC 2755 Security Negotiation for WebNFS January 2000
チウ、他 WebNFS2000年1月のための情報[4ページ]のRFC2755セキュリティ交渉
NFS filehandles are used to uniquely identify a particular file or directory on the server and are opaque to the client. The client neither examines a filehandle nor has any knowledge of its contents. Thus, filehandles make an ideal repository for the server to return the array of security mechanisms to the client in response to a SNEGO-MCL request.
NFS filehandlesは唯一サーバの特定のファイルかディレクトリを特定するのに使用されて、クライアントにとって、不透明です。 クライアントは、filehandleを調べないで、またコンテンツに関する少しの知識も持っていません。 したがって、サーバがSNEGO-MCL要求に対応してセキュリティー対策の配列をクライアントに返すように、filehandlesは理想的な倉庫を作ります。
To a successful SNEGO-MCL request the server responds, in place of the filehandle, with an array of integers that represents the valid security mechanisms the client must use to access the given path. A length field is introduced to store the size (in octets) of the array of integers.
うまくいっているSNEGO-MCLに、クライアントが与えられた経路にアクセスするのに使用しなければならない有効なセキュリティー対策を表す整数の勢ぞろいでサーバがfilehandleに代わって反応するよう要求してください。 整数の勢ぞろいのサイズ(八重奏における)を保存するために長さの野原を挿入します。
As the filehandles are limited in size (32 octets for NFS v2 and up to 64 octets for NFS v3), it can happen that there are more security mechanisms than the filehandles can accommodate. To circumvent this problem, a one-octet status field is introduced which indicates whether there are more security mechanisms (1 means yes, 0 means no) that require the client to perform another SNEGO-MCL to get them.
filehandlesがサイズ(NFS v2のための32の八重奏とNFS v3のための最大64の八重奏)が制限されるとき、filehandlesが収容できるより多くのセキュリティー対策があるのは起こることができます。 この問題を回避するために、クライアントがそれらを得るために別のSNEGO-MCLを実行するのを必要とするより多くのセキュリティー対策(1は、はいを意味して、0つの手段がノーである)があるかどうかを示す1八重奏の状態野原を挿入します。
To summarize, the response to a SNEGO-MCL request contains, in place of the filehandle, the length field, the status field, and the array of security mechanisms:
まとめる、SNEGO-MCL要求への応答はfilehandle、長さの分野、状態分野、およびセキュリティー対策の配列に代わって以下を含んでいます。
FH: length, status, {sec_1 sec_2 ... sec_n}
FH: 長さ、状態_2…秒の秒_1秒
The next two sub-sections describe how NFS v2 and v3 filehandles are "overloaded" to carry the length and status fields and the array of security mechanisms.
次の2つの小区分がNFS v2とv3 filehandlesがセキュリティー対策の長さ、状態野原、および配列を運ぶためにどう「積みすぎられるか」を説明します。
3.1 Overloaded NFS Version 2 Filehandle
3.1 積みすぎられたNFSバージョン2Filehandle
A regular NFS v2 filehandle is defined in RFC1094 as an opaque value occupying 32 octets:
通常のNFS v2 filehandleはRFC1094で32の八重奏を占領する不透明な値と定義されます:
1 2 3 4 32 +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+ | | | | | | | | | ... | | | | | | | | +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+
1 2 3 4 32 +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+ | | | | | | | | | ... | | | | | | | | +---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+
An overloaded NFS v2 filehandle looks like this:
積みすぎられたNFS v2 filehandleはこれに似ています:
1 2 3 4 5 8 32 +---+---+---+---+---+---+---+---+ +---+---+---+---+ +---+---+ | l | s | | | sec_1 | ... | sec_n | ... | | | +---+---+---+---+---+---+---+---+ +---+---+---+---+ +---+---+
1 2 3 4 5 8 32 +---+---+---+---+---+---+---+---+ +---+---+---+---+ +---+---+ | l| s| | | 秒_1| ... | 秒| ... | | | +---+---+---+---+---+---+---+---+ +---+---+---+---+ +---+---+
Chiu, et al. Informational [Page 5] RFC 2755 Security Negotiation for WebNFS January 2000
チウ、他 WebNFS2000年1月のための情報[5ページ]のRFC2755セキュリティ交渉
Note that the first four octets of an overloaded NFS v2 filehandle contain the length octet, the status octet, and two padded octets to make them XDR four-octet aligned. The length octet l = 4 * n, where n is the number of security mechanisms sent in the current overloaded filehandle. Apparently, an overloaded NFS v2 filehandle can carry up to seven security mechanisms.
積みすぎられたNFS v2 filehandleの最初の4つの八重奏が長さの八重奏、状態八重奏、および2を含んでいるというメモは、それらを4八重奏が並べたXDRにするように八重奏を水増ししました。 長さの八重奏lは4*nと等しいです、nが現在の積みすぎられたfilehandleで送られたセキュリティー対策の数であるところで。 明らかに、積みすぎられたNFS v2 filehandleは最大7台のセキュリティー対策を運ぶことができます。
3.2 Overloaded NFS Version 3 Filehandle
3.2 積みすぎられたNFSバージョン3Filehandle
A regular NFS v3 filehandle is defined in RFC1813 as a variable length opaque value occupying up to 64 octets. The length of the filehandle is indicated by an integer value contained in a four octet value which describes the number of valid octets that follow:
通常のNFS v3 filehandleはRFC1813で最大64の八重奏を占領する可変長の不透明な値と定義されます。 filehandleの長さは続く有効な八重奏の数について説明する4八重奏価値に含まれた整数値によって示されます:
1 4 +---+---+---+---+ | len | +---+---+---+---+
1 4 +---+---+---+---+ | len| +---+---+---+---+
1 4 up to 64 +---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+ | | | | | | | | | | | | | ... | | | | | +---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+
64+までの1 4---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+ | | | | | | | | | | | | | ... | | | | | +---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+
An overloaded NFS v3 filehandle looks like the following:
積みすぎられたNFS v3 filehandleは以下に似ています:
1 4 +---+---+---+---+ | len | +---+---+---+---+
1 4 +---+---+---+---+ | len| +---+---+---+---+
1 4 5 8 +---+---+---+---+---+---+---+---+ +---+---+---+---+ | s | | | | sec_1 | ... | sec_n | +---+---+---+---+---+---+---+---+ +---+---+---+---+
1 4 5 8 +---+---+---+---+---+---+---+---+ +---+---+---+---+ | s| | | | 秒_1| ... | 秒| +---+---+---+---+---+---+---+---+ +---+---+---+---+
Here, len = 4 * (n+1). Again, n is the number of security mechanisms contained in the current overloaded filehandle. Three octets are padded after the status octet to meet the XDR four-octet alignment requirement. An overloaded NFS v3 filehandle can carry up to fifteen security mechanisms.
ここで、lenは4*(n+1)と等しいです。 一方、nは現在の積みすぎられたfilehandleに含まれたセキュリティー対策の数です。 3つの八重奏が、状態八重奏の後にXDRの4八重奏の整列要求を満たすために水増しされます。 積みすぎられたNFS v3 filehandleは最大15台のセキュリティー対策を運ぶことができます。
4. WebNFS Security Negotiation
4. WebNFSセキュリティ交渉
With the SNEGO-MCL request and the overloaded NFS v2 and v3 filehandles defined above, the following diagram depicts the WebNFS security negotiation protocol:
積みすぎられたSNEGO-MCL要求、NFS v2、およびv3 filehandlesが上で定義されている状態で、以下のダイヤグラムはWebNFSセキュリティ交渉プロトコルについて表現します:
Chiu, et al. Informational [Page 6] RFC 2755 Security Negotiation for WebNFS January 2000
チウ、他 WebNFS2000年1月のための情報[6ページ]のRFC2755セキュリティ交渉
Client Server ------ ------
クライアントサーバ------ ------
LOOKUP FH=0x0, 0x81 <sec-index> "path" -----------> <----------- FH: length, status, {sec_1 sec_2 ... sec_n}
ルックアップFH=0x0、0×81<は>「経路」に秒索引をつけます。-----------><。----------- FH: 長さ、状態_2…秒の秒_1秒
where 0x81 represents client's indication to negotiate security mechanisms with the server,
0×81がサーバとセキュリティー対策を交渉するためにクライアントの指示を表すところ
path is either an ASCII string of slash separated components or 0x80 and a native path,
経路はスラッシュ切り離されたコンポーネントか0x80とネイティブの経路のASCIIストリングです。
sec-index, one octet, contains the index into the array of security mechanisms the server uses to protect the specified path,
秒インデックス(1つの八重奏)はサーバが指定された経路を保護するのに使用するセキュリティー対策の配列にインデックスを含んでいます。
status, one octet, indicates whether there are more security mechanisms (1 means yes, 0 means no) that require the client to perform another SNEGO-MCL to get them,
状態(1つの八重奏)は、クライアントがそれらを得るために別のSNEGO-MCLを実行するのを必要とするより多くのセキュリティー対策(1は、はいを意味して、0つの手段がノーである)があるかどうかを示します。
length (one octet for NFS v2 and four octets for NFS v3) describes the number of valid octets that follow,
長さ(NFS v2のための1つの八重奏とNFS v3のための4つの八重奏)は続く有効な八重奏の数について説明します。
{sec_1 sec_2 ... sec_n} represents the array of security mechanisms. As noted earlier, each security mechanism is represented by a four-octet integer.
_2…秒の秒_1秒はセキュリティー対策の配列を表します。より早く注意されるように、各セキュリティー対策は4八重奏の整数によって表されます。
Here is an example showing the WebNFS security negotiation protocol with NFS v2. In the example it is assumed the server shares /export with 10 security mechanisms {0x3900 0x3901 0x3902 ... 0x3909} on the export, two SNEGO-MCL requests would be needed for the client to get the complete security information:
ここに、NFS v2と共にWebNFSセキュリティ交渉プロトコルを示している例があります。 例では、それが10台のセキュリティー対策によるサーバシェア/輸出であると思われる、0×3900、0×3901、0×3902…0×3909、輸出のときに、クライアントが完全なセキュリティ情報を得るのに2つのSNEGO-MCL要求が必要でしょう:
LOOKUP FH=0x0, 0x81 0x01 "/export" -----------> <----------- 0x1c, 0x01, {0x3900 0x3901 0x3902 0x3903 0x3904 0x3905 0x3906}
「ルックアップFHは0×0、0×81 0×01インチ/輸出と等しいです」-----------><。----------- 0x1c、0×010×3900、0×3901、0×3902、0×3903、0×3904、0×3905、0×3906
LOOKUP FH=0x0, 0x81 0x08 "/export" -----------> <----------- 0x0c, 0x00, {0x3907 0x3908 0x3909}
「ルックアップFHは0×0、0×81 0×08インチ/輸出と等しいです」-----------><。----------- 0x0c、0×000×3907、0×3908、0×3909
Chiu, et al. Informational [Page 7] RFC 2755 Security Negotiation for WebNFS January 2000
チウ、他 WebNFS2000年1月のための情報[7ページ]のRFC2755セキュリティ交渉
The order of the security mechanisms returned in an overloaded filehandle implies preferences, i.e., one is more recommended than those following it. The ordering is the same as that returned by the MOUNT v3 protocol.
積みすぎられたfilehandleで返されたセキュリティー対策の注文が好みを含意して、すなわち、1つはそれに続くものよりお勧めです。 注文はそれが山のv3プロトコルで戻ったのと同じです。
The following shows a typical scenario which illustrates how the WebNFS security negotiation is accomplished in the course of accessing publicly shared filesystems.
以下は、どれが公的に共有されたファイルシステムにアクセスすることの間にWebNFSセキュリティ交渉がどう実行されるかを例証するかを典型的なシナリオに示します。
Normally, a WebNFS client first makes a regular multi-component LOOKUP request using the public filehandle to obtain the filehandle for the specified path. Since the WebNFS client does not have any prior knowledge as to how the path is protected by the server the default security mechanism is used in this first multi-component LOOKUP. If the default security mechanism does not meet server's requirements, the server replies with the AUTH_TOOWEAK RPC authentication error, indicating that the default security mechanism is not valid and the WebNFS client needs to use a stronger one.
通常、WebNFSクライアントは通常の多成分系のLOOKUPに最初に、指定された経路にfilehandleを入手するよう公共のfilehandleを使用するのに要求させます。 経路がサーバによってどう保護されるかに関してWebNFSクライアントには少しの先の知識もないので、デフォルトセキュリティー対策はこの最初の多成分系のLOOKUPで使用されます。 デフォルトセキュリティー対策がサーバの必要条件を出迎えないなら、サーバはAUTH_TOOWEAK RPC認証誤りで返答します、デフォルトセキュリティー対策が有効でなく、WebNFSクライアントが、より強いものを使用する必要であるのを示して。
Upon receiving the AUTH_TOOWEAK error, to find out what security mechanisms are required to access the specified path the WebNFS client sends a SNEGO-qMCL request, using the default security mechanism.
どんなセキュリティー対策が指定された経路にアクセスしなければならないかを見つけるためにAUTH_TOOWEAK誤りを受けると、WebNFSクライアントはSNEGO-qMCL要求を送ります、デフォルトセキュリティー対策を使用して。
If the SNEGO-MCL request succeeds the server responds with the filehandle overloaded with the array of security mechanisms required for the specified path. If the server does not support WebNFS security negotiation, the SNEGO-MCL request fails with NFSERR_IO for NFS v2 or NFS3ERR_IO for NFS v3 [RFC2055].
SNEGO-MCL要求が成功するなら、セキュリティー対策の配列が指定された経路に必要である状態でfilehandleが積みすぎられている状態で、サーバは反応します。 サーバが、WebNFSセキュリティが交渉であるとサポートしないなら、SNEGO-MCL要求はNFS v2のためのNFSERR_IOかNFS v3[RFC2055]のためのNFS3ERR_IOと共に失敗します。
Depending on the size of the array of security mechanisms, the WebNFS client may have to make more SNEGO-MCL requests to get the complete array.
セキュリティー対策の配列のサイズによって、WebNFSクライアントは完全な配列を得るというより多くのSNEGO-MCL要求をしなければならないかもしれません。
For successful SNEGO-MCL requests, the WebNFS client retrieves the array of security mechanisms from the overloaded filehandle, selects an appropriate one, and issues a regular multi-component LOOKUP using the selected security mechanism to acquire the filehandle.
うまくいっているSNEGO-MCL要求のために、WebNFSクライアントは、filehandleを入手するのに選択されたセキュリティー対策を使用することで積みすぎられたfilehandleからセキュリティー対策の配列を検索して、適切なものを選択して、通常の多成分系のLOOKUPを発行します。
All subsequent NFS requests are then made using the selected security mechanism and the filehandle.
そして、選択されたセキュリティー対策とfilehandleを使用することですべてのその後のNFS要求をします。
The following depicts the scenario outlined above. It is assumed that the server shares /export/home as follows:
以下は上に概説されたシナリオについて表現します。 サーバが以下の/export/homeを共有すると思われます:
share -o sec=sec_1:sec_2:sec_3,public /export/home
公衆/輸出/ホーム、-o秒=秒_1(秒_2(秒_3を))共有してください。
Chiu, et al. Informational [Page 8] RFC 2755 Security Negotiation for WebNFS January 2000
チウ、他 WebNFS2000年1月のための情報[8ページ]のRFC2755セキュリティ交渉
and AUTH_SYS is the client's default security mechanism and is not one of {sec_1, sec_2, sec_3}.
そして、AUTH_SYSはクライアントのデフォルトセキュリティー対策です、そして、1つが秒_1、秒_2、秒_3がありませんか?
Client Server ------ ------
クライアントサーバ------ ------
LOOKUP FH=0x0, "/export/home" AUTH_SYS -----------> <----------- AUTH_TOOWEAK
ルックアップFH=0x0、"/export/home"AUTH_SYS-----------><。----------- AUTH_TOOWEAK
LOOKUP FH=0x0, 0x81 0x01 "/export/home" AUTH_SYS -----------> <----------- overloaded FH: length, status, {sec_1 sec_2 sec_3}
ルックアップFH=0×0、0x81 0×01"/export/home"AUTH_SYS-----------><。----------- 積みすぎられたFH: 長さ、状態_2秒の秒_1秒の_3
LOOKUP FH=0x0, "/export/home" sec_n -----------> <----------- FH = 0x01
LOOKUP FH=0x0、"/export/home"秒-----------><。----------- FH=0x01
NFS request with FH=0x01 sec_n -----------> <----------- ...
NFSはFH=と共に0×01秒を要求します。-----------><。----------- ...
In the above scenario, the first request is a regular multi-component LOOKUP which fails with the AUTH_TOOWEAK error. The client then issues a SNEGO-MCL request to get the security information.
上のシナリオでは、最初の要求はAUTH_TOOWEAK誤りに応じて失敗する通常の多成分系のLOOKUPです。 そして、クライアントはセキュリティ情報を得るというSNEGO-MCL要求を出します。
There are WebNFS implementations that allow the public filehandle to work with NFS protocol procedures other than LOOKUP. For those WebNFS implementations, if the first request is not a regular multi- component LOOKUP and it fails with AUTH_TOOWEAK, the client should issue a SNEGO-MCL with
公共のfilehandleがLOOKUP以外のNFSプロトコル手順で働いているWebNFS実装があります。 それらのWebNFS実装のために、最初の要求が通常のマルチコンポーネントでないならAUTH_TOOWEAKと共に失敗します、とクライアントはSNEGO-MCLを発行するべきです。
0x81 0x01 "."
「0×81 0×01、インチ」
as the path to get the security information.
セキュリティ情報を得る経路として。
Chiu, et al. Informational [Page 9] RFC 2755 Security Negotiation for WebNFS January 2000
チウ、他 WebNFS2000年1月のための情報[9ページ]のRFC2755セキュリティ交渉
5. Security Considerations
5. セキュリティ問題
The reader may note that no mandatory security mechanisms are specified in the protocol that the client must use in making SNEGO- MCL requests. Normally, the client uses the default security mechanism configured on his system in the first SNEGO-MCL request. If the default security mechanism is not valid the server replies with the AUTH_TOOWEAK error. In this case the server does not return the array of security mechanisms to the client. The client can then make another SNEGO-MCL request using a stronger security mechanism. This continues until the client hits a valid one or has exhausted all the supported security mechanisms.
読者は、どんな義務的なセキュリティー対策もクライアントが作成SNEGO- MCL要求で使用しなければならないプロトコルで指定されないことに注意するかもしれません。 通常、クライアントはSNEGO-MCLが要求する1番目で彼のシステムの上で構成されたデフォルトセキュリティー対策を使用します。 デフォルトセキュリティー対策が有効でないなら、サーバはAUTH_TOOWEAK誤りで返答します。 この場合、サーバはセキュリティー対策の配列をクライアントに返しません。 そして、クライアントは、より強いセキュリティー対策を使用することで別のSNEGO-MCL要求をすることができます。 クライアントで有効なものを打つか、またはすべてのサポートしているセキュリティー対策がくたくたになるまで、これは続きます。
6. References
6. 参照
[RFC1094] Sun Microsystems, Inc., "NFS: Network File System Protocol Specification", RFC 1094, March 1989. http://www.ietf.org/rfc/rfc1094.txt
[RFC1094]サン・マイクロシステムズ・インク、「NFS:」 「ネットワークファイルシステムプロトコル仕様」、RFC1094、3月1989日の http://www.ietf.org/rfc/rfc1094.txt
[RFC1813] Callaghan, B., Pawlowski, B. and P. Staubach, "NFS Version 3 Protocol Specification", RFC 1813, June 1995. http://www.ietf.org/rfc/rfc1813.txt
[RFC1813] キャラハンとB.とポロウスキーとB.とP.ストーバック、「NFSバージョン3プロトコル仕様」、RFC1813、6月1995の http://www.ietf.org/rfc/rfc1813.txt
[RFC2054] Callaghan, B., "WebNFS Client Specification", RFC 2054, October 1996. http://www.ietf.org/rfc/rfc2054.txt
[RFC2054] キャラハン、B.、「WebNFSクライアント仕様」、RFC2054、10月1996日の http://www.ietf.org/rfc/rfc2054.txt
[RFC2055] Callaghan, B., "WebNFS Server Specification", RFC 2055, October 1996. http://www.ietf.org/rfc/rfc2055.txt
[RFC2055] キャラハン、B.、「WebNFSサーバ仕様」、RFC2055、10月1996日の http://www.ietf.org/rfc/rfc2055.txt
[RFC2203] Eisler, M., Chiu, A. and Ling, L., "RPCSEC_GSS Protocol Specification", RFC 2203, September 1997. http://www.ietf.org/rfc/rfc2203.txt
[RFC2203] アイスラーとM.とチウとA.と御柳もどき、L.、「RPCSEC_GSSプロトコル仕様」、RFC2203、9月1997の http://www.ietf.org/rfc/rfc2203.txt
7. Acknowledgements
7. 承認
This specification was extensively brainstormed and reviewed by the NFS group of Solaris Software Division.
この仕様は、Solaris Software事業部のNFSグループによって手広くブレインストーミングされて、再検討されました。
Chiu, et al. Informational [Page 10] RFC 2755 Security Negotiation for WebNFS January 2000
チウ、他 WebNFS2000年1月のための情報[10ページ]のRFC2755セキュリティ交渉
8. Authors' Addresses
8. 作者のアドレス
Alex Chiu Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303
アレックスチウサン・マイクロシステムズ・インク901サンアントニオRoadパロアルト、カリフォルニア 94303
Phone: +1 (650) 786-6465 EMail: alex.chiu@Eng.sun.com
以下に電話をしてください。 +1 (650) 786-6465 メールしてください: alex.chiu@Eng.sun.com
Mike Eisler Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303
マイクアイスラーサン・マイクロシステムズ・インク901サンアントニオRoadパロアルト、カリフォルニア 94303
Phone: +1 (719) 599-9026 EMail: michael.eisler@Eng.sun.com
以下に電話をしてください。 +1 (719) 599-9026 メールしてください: michael.eisler@Eng.sun.com
Brent Callaghan Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303
ブレントキャラハンサン・マイクロシステムズ・インク901サンアントニオRoadパロアルト、カリフォルニア 94303
Phone: +1 (650) 786-5067 EMail: brent.callaghan@Eng.sun.com
以下に電話をしてください。 +1 (650) 786-5067 メールしてください: brent.callaghan@Eng.sun.com
Chiu, et al. Informational [Page 11] RFC 2755 Security Negotiation for WebNFS January 2000
チウ、他 WebNFS2000年1月のための情報[11ページ]のRFC2755セキュリティ交渉
9. Full Copyright Statement
9. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Chiu, et al. Informational [Page 12]
チウ、他 情報[12ページ]
一覧
スポンサーリンク