[要約] RFC 2755は、WebNFSのセキュリティ交渉に関する標準化されたプロトコルであり、セキュリティ要件を満たすための方法を提供します。目的は、WebNFSのセキュリティを向上させ、データの機密性と完全性を確保することです。
Network Working Group A. Chiu
Request for Comments: 2755 M. Eisler
Category: Informational B. Callaghan
Sun Microsystems
January 2000
Security Negotiation for WebNFS
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.
Copyright（c）The Internet Society（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サーバー[RFC2055]で目的のセキュリティメカニズムを交渉するためのWebNFSクライアント[RFC2054]のプロトコルについて説明します[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
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.
マウントプロトコルは、NFSクライアントがデータアクセスに必要なファイルハンドルを取得するために使用されます。マウントバージョン1および2 [RFC1094]は、NFSバージョン2ファイルハンドルを返しますが、マウントバージョン3 [RFC1813]は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.
マウントプロトコルの既存のバージョンの中で、NFS V3クライアントとNSF V3サーバーの間のセキュリティ交渉を容易にするRPC手順（MountProc3_MNT）を提供するMount V3のみが提供されます。この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.
マウントプロトコルのバージョン1または2のセキュリティ交渉には、RPC手順はありません。
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クライアントに「SEC =」オプションを提供します。このマウントオプションが指定されていない場合、デフォルトのアクションは、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.
RFC 2054で指定されているように、WebNFSクライアントは、サーバーが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クライアントは最初にMountを使用していないため、Mount V3のMountProc3_MNT手順は、WebNFSクライアントがマウントに戻るまでセキュリティネゴシエーションに使用できません。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、Inc。によって開発されたWebNFSセキュリティネゴシエーションプロトコルと、RFCS 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セキュリティネゴシエーションは、既存のマルチコンポーネントルックアップ（MCL）操作[RFC2055]のリクエストと応答を変更することにより達成されます。MCL操作は、ルックアップ手順（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（セキュリティネゴシエーションマルチコンポーネント検索）要求と呼ばれます。
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"
ルックアップfh = 0x0、 "/a/b/c"
For Native Path:
ネイティブパスの場合：
LOOKUP FH=0x0, 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.
マルチコンポーネントパスは、スラッシュ分離コンポーネントのASCIIストリングまたは0x80文字に続いてネイティブパスが続くかのいずれかです。マルチコンポーネントの検索は、ルックアップでのパブリックファイルハンドルの使用を意味することに注意してください。
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文字です。このオクテットは、セキュリティメカニズムを交渉するというクライアントの兆候を表しています。その後、セキュリティインデックスOctetが続き、インデックスの現在の値をサーバーから返すセキュリティメカニズムの配列に保存します。セキュリティインデックスは常に1つから始まり、交渉が続くと増加します。その後、パス名が続きます。これには、Slash分離された標準コンポーネントのASCII文字列または0x80とネイティブパスが続きます。
A security negotiation multi-component LOOKUP request looks like this:
セキュリティネゴシエーションマルチコンポーネントルックアップリクエストは次のようになります。
For Canonical Path:
標準的なパスの場合：
LOOKUP FH=0x0, 0x81 <sec-index> "/a/b/c"
For Native Path:
ネイティブパスの場合：
LOOKUP FH=0x0, 0x81 <sec-index> 0x80 "a:b:c"
In the next section we will see how the MCL response is modified for WebNFS security negotiation.
次のセクションでは、WebNFSセキュリティネゴシエーションのMCL応答がどのように変更されるかを確認します。
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.
ファイルハンドルのサイズは制限されているため（NFS V2の場合は32オクテット、NFS V3で最大64オクテット）、ファイルハンドルが収容できるよりも多くのセキュリティメカニズムがあることがあります。この問題を回避するために、クライアントが別のSNEGO-MCLを実行してそれらを取得する必要があるより多くのセキュリティメカニズムがあるかどうか（1つの意味はい、0はNO）があるかどうかを示します。
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}
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ファイルハンドルが長さとステータスフィールド、およびセキュリティメカニズムの配列を運ぶ方法を説明しています。
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 FileHandleは次のようになります。
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.
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ファイルハンドルは、RFC1813で最大64オクテットを占める可変長さの不透明値として定義されています。ファイルハンドルの長さは、次の有効なオクテットの数を説明する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は、現在の過負荷ファイルハンドルに含まれるセキュリティメカニズムの数です。XDR 4-OCTETアライメント要件を満たすために、ステータスOctetの後に3つのオクテットがパッドにされます。オーバーロードされた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-Index、1つのOctetには、指定されたパスを保護するためにサーバーが使用するセキュリティメカニズムの配列へのインデックスが含まれています。
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 Octetは、クライアントがそれらを取得するために別のSNEGO-MCLを実行する必要があるセキュリティメカニズムがより多くあるかどうか（1つはYES、0はNOを意味します）を示します。
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.
{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.
過負荷のファイルハンドルで返されるセキュリティメカニズムの順序は、好みを意味します。つまり、それに従ったものよりも推奨されます。順序は、マウント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クライアントは、最初にパブリックファイルハンドルを使用して定期的なマルチコンポーネントルックアップリクエストを行い、指定されたパスのファイルハンドルを取得します。WebNFSクライアントには、サーバーによってパスがどのように保護されているかについての事前知識はないため、この最初のマルチコンポーネント検索でデフォルトのセキュリティメカニズムが使用されます。デフォルトのセキュリティメカニズムがサーバーの要件を満たしていない場合、サーバーは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エラーを受信すると、指定されたパスにアクセスするために必要なセキュリティメカニズムを確認するために、デフォルトのセキュリティメカニズムを使用して、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 V2またはNFS V3 [RFC2055]のNFSERR_IOまたは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クライアントは、過負荷のファイルハンドルから一連のセキュリティメカニズムを取得し、適切なファイルハンドルを選択し、選択したセキュリティメカニズムを使用してファイルハンドルを取得して通常のマルチコンポーネントルックアップを発行します。
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:
以下は、上記のシナリオを示しています。サーバーは次のように共有 /エクスポート /ホームであると想定されています。
share -o sec=sec_1:sec_2:sec_3,public /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}の1つではありません。
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エラーで失敗する定期的なマルチコンポーネントルックアップです。その後、クライアントは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
Public FileHandleがLookup以外のNFSプロトコル手順で動作できるようにするWebNFS実装があります。 これらのWebNFSの実装の場合、最初のリクエストが通常のマルチコンポーネントルックアップではなく、auth_tooweakで失敗する場合、クライアントは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] Sun Microsystems、Inc。、「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] Callaghan、B.、Pawlowski、B。and P. Staubach、「NFSバージョン3プロトコル仕様」、RFC 1813、1995年6月。http：//www.ietf.org/rfc/rfc1813.txtxt
[RFC2054] Callaghan, B., "WebNFS Client Specification", RFC 2054, October 1996. http://www.ietf.org/rfc/rfc2054.txt
[RFC2054] Callaghan、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] Callaghan、B。、「Webnfs Server仕様」、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] Eisler、M.、Chiu、A。and Ling、L。、「RPCSEC_GSSプロトコル仕様」、RFC 2203、1997年9月。http：//www.ietf.org/rfc/rfc2203.txtxt
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
Alex Chiu Sun Microsystems、Inc。901 San Antonio Road Palo Alto、CA 94303
Phone: +1 (650) 786-6465
EMail: alex.chiu@Eng.sun.com
Mike Eisler Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303
Mike Eisler Sun Systems、Inc。901 San Antonio Road Palo Alto、CA 94303
Phone: +1 (719) 599-9026
EMail: michael.eisler@Eng.sun.com
Brent Callaghan Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303
Brent Callaghan Sun Systems、Inc。901 San Antonio Road Palo Alto、CA 94303
Phone: +1 (650) 786-5067
EMail: brent.callaghan@Eng.sun.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright（c）The Internet Society（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エディター機能の資金は現在、インターネット協会によって提供されています。