Network Working Group A. Chiu
Request for Comments: 2755 M. Eisler
Category: Informational B. Callaghan
Sun Microsystems
January 2000
Security Negotiation for WebNFS
Status of this 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.
著作権（C）インターネット協会（2000）。全著作権所有。
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のクライアントは、MOUNT v3プロトコル[RFC1813]にフォールバックする前にWebNFSのサーバ[RFC2055]で必要なセキュリティメカニズムを交渉するWebNFSのクライアントのためのプロトコル[RFC2054]を説明しています。人々は互換性のある実装を書くことができるように、この文書が準備されています。
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
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.
MOUNTプロトコルは、データアクセスのために必要なファイルハンドルを取得するためにNFSクライアントによって使用されます。 MOUNTバージョン3 [RFC1813]一方MOUNTバージョン1及び2 [RFC1094] NFSバージョン2つのファイルハンドルを返すは、NFSバージョン3つのファイルハンドルを返します。
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.
MOUNTプロトコルの既存のバージョンのうち、唯一MOUNT V3はNFS v3のクライアントとNSF v3のサーバとの間のセキュリティネゴシエーションを容易RPC手順（MOUNTPROC3_MNT）を提供します。このRPC手順は（MNT3_OK）成功すると、サーバーは、NFS v3のファイルハンドルに加えて、クライアントには、指定されたパス名のためにサポートするセキュリティ・メカニズムの配列を返します。
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手順はMOUNTプロトコルのバージョンの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のマウントの上に、デフォルトのセキュリティ・メカニズムを使用する、またはMOUNT 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.
RFC 2054で指定されているように、WebNFSのクライアントは、最初のサーバーがWebNFSのをサポートし、MOUNTプロトコルの必要性を排除し、データアクセスのための最初のファイルハンドルとしてpublscファイルハンドルを使用していることを前提としています。サーバーがWebNFSのをサポートしていない場合のWebNFSクライアントは、バックMOUNTに落ちます。
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のクライアントが最初にMOUNTを使用していないのでWebNFSのクライアントがバックMOUNTに落ちるまで、MOUNT v3ののMOUNTPROC3_MNT手順は、セキュリティネゴシエーションには使用できません。実行可能なプロトコルはMOUNTPROC3_MNT手順が存在しない場合に、サーバとのセキュリティ・メカニズムを交渉するWebNFSのクライアントのために工夫する必要があります。
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.
この文書は、米国Sun Microsystems社が開発したのWebNFSセキュリティネゴシエーションプロトコル、Inc.の用語を説明しているRFC 2054および2055からの定義は、この文書で使用されています。読者はそれらに精通していることが期待されています。
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 v2のNFS V3とNFSPROC_LOOKUPためNFSPROC3_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:
マルチコンポーネントルックアップ要求[RFC2055]は、パブリックファイルハンドルと多成分パスから構成されています。
For Canonical Path:
正規のパスの場合：
LOOKUP FH=0x0, "/a/b/c"
LOOKUP FH = 0x0の、 "/ A / B / C"
For Native Path:
ネイティブパスの場合：
LOOKUP FH=0x0, 0x80 "a:b:c"
LOOKUP FH = 0x0の、0x80の "：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.
多成分パスはスラッシュ分離された成分のASCII文字列またはネイティブパスが続く0x80の文字のいずれかです。多成分LOOKUPはLOOKUPで公共ファイルハンドルの使用を意味することに留意されたいです。
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要求は、公開ファイルハンドルとパス名で構成されています。他のパス名と区別するため、以下に説明するようにしかし、パス名は一意に、構成されています。
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の多成分経路です。最初の接頭辞のオクテットは、ネイティブパスの0x80で非ASCII文字に似0x81と非ASCII文字、です。このオクテットは、セキュリティ・メカニズムを交渉するために、クライアントの表示を表しています。これは、サーバから返されるセキュリティメカニズムの配列へのインデックスの現在値を格納するセキュリティインデックスオクテットが続きます。セキュリティインデックスは常に1で始まり、交渉が継続するようにインクリメントされます。次いで、それをパス名に続いて、いずれかのスラッシュのASCII文字列が正規の構成要素または0x80のネイティブパスを分離します。
A security negotiation multi-component LOOKUP request looks like this:
セキュリティネゴシエーションマルチコンポーネントルックアップ要求は次のようになります。
For Canonical Path:
正規のパスの場合：
LOOKUP FH=0x0, 0x81 <sec-index> "/a/b/c"
LOOKUP FH = 0x0の、0x81と<秒インデックス> "/ A / B / C"
For Native Path:
ネイティブパスの場合：
LOOKUP FH=0x0, 0x81 <sec-index> 0x80 "a:b:c"
LOOKUP FH = 0x0の、0x81と<秒インデックス>は0x80 "：B：C"
In the next section we will see how the MCL response is modified for WebNFS security negotiation.
次のセクションでは、MCL応答がWebNFSのセキュリティネゴシエーションのために変更される方法について説明します。
As described in RFC2054, if a multi-component LOOKUP request succeeds, the server responds with a valid filehandle:
RFC2054に記載されているようにマルチコンポーネントルックアップ要求が成功した場合、サーバは、有効なファイルハンドルで応答します。
LOOKUP FH=0x0, "a/b/c"
----------->
<-----------
FH=0x3
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ファイルハンドルは一意に、サーバー上の特定のファイルやディレクトリを識別するために使用され、クライアントへの不透明されています。クライアントは、どちらもファイルハンドルを調べなかったり、その内容のいずれかの知識を持っています。このように、ファイルハンドルはサーバがSNEGO-MCLの要求に応じてクライアントにセキュリティメカニズムの配列を返すための理想的なリポジトリを作ります。
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の要求に対するサーバは、クライアントが指定されたパスにアクセスするために使用する必要があり、有効なセキュリティメカニズムを表し整数の配列で、ファイルハンドルの代わりに、応答します。長さフィールドは、整数の配列を（オクテットで）サイズを格納するために導入されます。
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.
ファイルハンドルが（32 NFS v2のオクテットとNFS v3の64オクテットまで）サイズが制限されるように、ファイルハンドルを収容することができるよりも多くのセキュリティメカニズムが存在することが起こり得ます。この問題を回避するには、1オクテットのステータスフィールドは、それらを得るために、別のSNEGO-MCLを実行するためにクライアントが必要な複数のセキュリティ・メカニズム（1つの手段はい、0が無意味）があるかどうかを示す導入されています。
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要求に対する応答が含まれ、ファイルハンドルの代わりに、長さフィールド、状態フィールド、およびセキュリティメカニズムの配列：
FH: length, status, {sec_1 sec_2 ... sec_n}
FH：長さ、状態、{SEC_1 sec_2 ... sec_n}
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.
次の二つのサブセクションでは、NFS v2およびv3のファイルハンドルは、長さおよびステータスフィールドおよびセキュリティメカニズムの配列を運ぶために「オーバーロード」する方法を記載しています。
A regular NFS v2 filehandle is defined in RFC1094 as an opaque value occupying 32 octets:
定期的なNFS v2のファイルハンドルは、32個のオクテットを占める不透明な値として、RFC1094で定義されています。
1 2 3 4 32
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+
| | | | | | | | | ... | | | | | | | |
+---+---+---+---+---+---+---+---+ +---+---+---+---+---+---+---+
An overloaded NFS v2 filehandle looks like this:
オーバーロードされたNFS v2のファイルハンドルは、次のようになります。
1 2 3 4 5 8 32
+---+---+---+---+---+---+---+---+ +---+---+---+---+ +---+---+
| l | s | | | sec_1 | ... | sec_n | ... | | |
+---+---+---+---+---+---+---+---+ +---+---+---+---+ +---+---+
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のファイルハンドルの最初の4つのオクテットはXDR 4オクテットが整列それらを作るために、長さオクテット、状態八重奏、および2つのパッド入りのオクテットを含んでいることに注意してください。長さオクテットL = 4×n個、nは現在の過負荷ファイルハンドルで送信セキュリティメカニズムの数です。どうやら、オーバーロードされたNFS v2のファイルハンドルは7つのセキュリティメカニズムまで運ぶことができます。
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のファイルハンドルは、64オクテットまで占有可変長の不透明な値として、RFC1813に定義されています。ファイルハンドルの長さは、以下の有効なオクテットの数を記述する4つのオクテット値に含まれる整数値で示されます。
1 4
+---+---+---+---+
| len |
+---+---+---+---+
1 4 up to 64
+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+
| | | | | | | | | | | | | ... | | | | |
+---+---+---+---+---+---+---+---+---+---+---+---+ +---+---+---+---+
An overloaded NFS v3 filehandle looks like the following:
オーバーロードされたNFS v3ではファイルハンドルは、次のようになります。
1 4
+---+---+---+---+
| len |
+---+---+---+---+
1 4 5 8
+---+---+---+---+---+---+---+---+ +---+---+---+---+
| s | | | | sec_1 | ... | sec_n |
+---+---+---+---+---+---+---+---+ +---+---+---+---+
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は現在の過負荷ファイルハンドルに含まれるセキュリティメカニズムの数です。 3つのオクテットは、XDR 4オクテット整列要件を満たすために状態八重奏の後に埋め込まれます。オーバーロードされたNFS v3ではファイルハンドルは15のセキュリティメカニズムまで運ぶことができます。
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のファイルハンドルと、次の図は、WebNFSのセキュリティネゴシエーションプロトコルを示します。
Client Server
------ ------
LOOKUP FH=0x0, 0x81 <sec-index> "path"
----------->
<-----------
FH: length, status, {sec_1 sec_2 ... sec_n}
where 0x81 represents client's indication to negotiate security mechanisms with the server,
0x81とは、サーバーとセキュリティメカニズムを交渉するために、クライアントの表示を表し、
path is either an ASCII string of slash separated components or 0x80 and a native path,
パスは、いずれかのスラッシュのASCII文字列は、0x80のネイティブパスまたはコンポーネントを分離します
sec-index, one octet, contains the index into the array of security mechanisms the server uses to protect the specified path,
SEC-インデックスは、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を実行するためにクライアントが必要な複数のセキュリティ・メカニズム（はい、0は決して1手段）があるかどうかを示します
length (one octet for NFS v2 and four octets for NFS v3) describes the number of valid octets that follow,
長さ（NFS v2およびNFS v3のための4つのオクテットのための1オクテット）が続く有効なオクテットの数を記述し、
{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.
{SEC_1 sec_2 ... sec_n}セキュリティメカニズムの配列を表します。先に述べたように、各セキュリティ機構は、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件のセキュリティメカニズム{0x3900 0x3901 0x3902 0x3909 ...}とサーバー共有/エクスポートを想定している例では、2つのSNEGO-MCL要求は、完全なセキュリティ情報を取得するために、クライアントのために必要とされるであろう。
LOOKUP FH=0x0, 0x81 0x01 "/export"
----------->
<-----------
0x1c, 0x01, {0x3900 0x3901 0x3902 0x3903 0x3904 0x3905 0x3906}
LOOKUP FH=0x0, 0x81 0x08 "/export"
----------->
<-----------
0x0c, 0x00, {0x3907 0x3908 0x3909}
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.
オーバーロードされたファイルハンドルに返さセキュリティメカニズムの順序、すなわち、一方がそれに続くものよりも推奨され、好みを暗示しています。順序はMOUNT 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要求を行います。 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要求が成功すると、サーバーは、指定されたパスに必要なセキュリティメカニズムの配列で過負荷にファイルハンドルで応答します。サーバーがWebNFSセキュリティネゴシエーションをサポートしていない場合は、SNEGO-MCL要求は、NFS v3の[RFC2055]のためのNFS v2またはNFS3ERR_IOためNFSERR_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のクライアントは、過負荷ファイルハンドルからのセキュリティメカニズムの配列を取得し、適切なものを選択し、ファイルハンドルを取得するために選択されたセキュリティメカニズムを使用して定期的な多成分LOOKUPを発行します。
All subsequent NFS requests are then made using the selected security mechanism and the filehandle.
この後に続くすべてのNFS要求は、選択されたセキュリティメカニズムとファイルハンドルを使用して作られています。
The following depicts the scenario outlined above. It is assumed that the server shares /export/home as follows:
以下は、上記で概説したシナリオを示しています。サーバーの共有/エクスポート/ homeは次のように想定されています。
share -o sec=sec_1:sec_2:sec_3,public /export/home
シェア-o秒= SEC_1：sec_2：sec_3、公共/ export / homeの
and AUTH_SYS is the client's default security mechanism and is not one of {sec_1, sec_2, sec_3}.
そしてAUTH_SYSは、クライアントのデフォルトのセキュリティメカニズムであると{SEC_1、sec_2、sec_3}の一つではありません。
Client Server
------ ------
LOOKUP 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}
LOOKUP FH=0x0, "/export/home"
sec_n
----------->
<-----------
FH = 0x01
NFS request with FH=0x01
sec_n
----------->
<-----------
...
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
公共ファイルハンドルがLOOKUP以外のNFSプロトコル手順で作業できるようにするWebNFSの実装があります。最初の要求は、通常のマルチコンポーネントLOOKUPではありません、それはAUTH_TOOWEAKに失敗した場合、それらのWebNFSの実装では、クライアントが持つSNEGO-MCLを発行する必要があります
0x81 0x01 "."
0x81と0x01の ""
as the path to get the security information.
パスなどのセキュリティ情報を取得します。
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要求に自分のシステム上で設定されたデフォルトのセキュリティ・メカニズムを使用しています。デフォルトのセキュリティ・メカニズムが有効でない場合、サーバーはAUTH_TOOWEAKエラーで応答します。この場合、サーバはクライアントにセキュリティメカニズムの配列を返しません。次に、クライアントはより強力なセキュリティ・メカニズムを使用して、別のSNEGO-MCL要求を行うことができます。クライアントが有効なものに当たるか、サポートされているすべてのセキュリティ・メカニズムを使い果たしたまでこれが続きます。
[RFC1094] Sun Microsystems, Inc., "NFS: Network File System Protocol Specification", RFC 1094, March 1989. http://www.ietf.org/rfc/rfc1094.txt
[RFC1094]サン・マイクロシステムズ社は、 "NFS：ネットワークシステムプロトコル仕様書ファイル"、RFC 1094、1989年3月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プロトコル仕様"、RFC 1813、1995年6月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のクライアント仕様"、RFC 2054、1996年10月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のサーバー仕様"、RFC 2055、1996年10月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プロトコル仕様"、RFC 2203、1997年9月http://www.ietf.org/rfc/rfc2203.txt
This specification was extensively brainstormed and reviewed by the NFS group of Solaris Software Division.
この仕様は広範囲にブレインストーミングおよびSolarisソフトウェア事業部のNFSグループで検討しました。
Alex Chiu Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303
アレックス・チウサン・マイクロシステムズ株式会社901サンアントニオの道パロアルト、CA 94303
Phone: +1 (650) 786-6465 EMail: alex.chiu@Eng.sun.com
電話：+1（650）786-6465 Eメール：alex.chiu@Eng.sun.com
Mike Eisler Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303
マイク・アイスラーサン・マイクロシステムズ株式会社901サンアントニオの道パロアルト、CA 94303
Phone: +1 (719) 599-9026 EMail: michael.eisler@Eng.sun.com
電話：+1（719）599-9026 Eメール：michael.eisler@Eng.sun.com
Brent Callaghan Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303
ブレントキャラハンサン・マイクロシステムズ株式会社901サンアントニオの道パロアルト、CA 94303
Phone: +1 (650) 786-5067 EMail: brent.callaghan@Eng.sun.com
電話：+1（650）786-5067 Eメール：brent.callaghan@Eng.sun.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネット協会（2000）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。