[要約] RFC 8000は、NFSv4のマルチドメイン名前空間展開に関する要件を定義しており、異なるドメイン間でのファイルシステムの統合を可能にすることを目的としています。
Internet Engineering Task Force (IETF) W. Adamson
Request for Comments: 8000 NetApp
Category: Standards Track N. Williams
ISSN: 2070-1721 Cryptonector
November 2016
Requirements for NFSv4 Multi-Domain Namespace Deployment
NFSv4マルチドメイン名前空間の展開の要件
Abstract
概要
This document presents requirements for the deployment of the NFSv4 protocols for the construction of an NFSv4 file namespace in environments with multiple NFSv4 Domains. To participate in an NFSv4 multi-domain file namespace, the server must offer a multi-domain-capable file system and support RPCSEC_GSS for user authentication. In most instances, the server must also support identity-mapping services.
このドキュメントでは、複数のNFSv4ドメインが存在する環境でNFSv4ファイルの名前空間を構築するためのNFSv4プロトコルの展開の要件について説明します。 NFSv4マルチドメインファイル名前空間に参加するには、サーバーはマルチドメイン対応のファイルシステムを提供し、ユーザー認証用にRPCSEC_GSSをサポートする必要があります。ほとんどの場合、サーバーはIDマッピングサービスもサポートする必要があります。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc8000.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8000で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Federated File System . . . . . . . . . . . . . . . . . . . . 5
4. Identity Mapping . . . . . . . . . . . . . . . . . . . . . . 6
4.1. NFSv4 Server Identity Mapping . . . . . . . . . . . . . . 6
4.2. NFSv4 Client Identity Mapping . . . . . . . . . . . . . . 7
5. Stand-Alone NFSv4 Domain Deployment Examples . . . . . . . . 7
5.1. AUTH_SYS with Stringified UID/GID . . . . . . . . . . . . 7
5.2. AUTH_SYS with Name@domain . . . . . . . . . . . . . . . . 8
5.3. RPCSEC_GSS with Name@domain . . . . . . . . . . . . . . . 8
6. Multi-Domain Constraints to the NFSv4 Protocol . . . . . . . 9
6.1. Name@domain Constraints . . . . . . . . . . . . . . . . . 9
6.1.1. NFSv4 Domain and DNS Services . . . . . . . . . . . . 9
6.1.2. NFSv4 Domain and Name Services . . . . . . . . . . . 10
6.2. RPC Security Constraints . . . . . . . . . . . . . . . . 10
6.2.1. NFSv4 Domain and Security Services . . . . . . . . . 11
7. Stand-Alone Examples in an NFSv4 Multi-Domain Deployment . . 11
8. Resolving Multi-Domain Authorization Information . . . . . . 12
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
10.1. Normative References . . . . . . . . . . . . . . . . . . 14
10.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
The NFSv4 protocols NFSv4.0 [RFC7530], NFSv4.1 [RFC5661], and NFSv4.2 [RFC7862] introduce the concept of an NFS Domain. An NFSv4 Domain is defined as a set of users and groups using the NFSv4 name@domain user and group identification syntax with the same specified @domain.
NFSv4プロトコルNFSv4.0 [RFC7530]、NFSv4.1 [RFC5661]、およびNFSv4.2 [RFC7862]は、NFSドメインの概念を導入しています。 NFSv4ドメインは、NFSv4 name @ domainユーザーおよびグループ識別構文を使用して、同じ指定された@domainを持つユーザーおよびグループのセットとして定義されます。
Previous versions of the NFS protocol, such as NFSv3 [RFC1813], use the UNIX-centric user identification mechanism of numeric user and group ID for the uid3 and gid3 [RFC1813] file attributes and for identity in the authsys_parms AUTH_SYS credential defined in the Open Network Computing (ONC) Remote Procedure Call (RPC) protocol [RFC5531]. Section 6.1 of [RFC2624] notes that the use of UNIX-centric numeric IDs limits the scale of NFS to large local work groups. UNIX-centric numeric IDs are not unique across NFSv3 deployments and so are not designed for Internet scaling achieved by taking into account multiple naming domains and multiple naming mechanisms (see Section 6.2). The NFSv4 Domain's use of the name@domain syntax provides this Internet scaling by allowing servers and clients to translate between the external name@domain string representation to a local or internal numeric (or other identifier) representation, which matches internal implementation needs.
NFSv3 [RFC1813]など、NFSプロトコルの以前のバージョンは、uid3およびgid3 [RFC1813]ファイル属性、およびOpenで定義されたauthsys_parms AUTH_SYSクレデンシャルのIDに、数値ユーザーおよびグループIDのUNIX中心のユーザー識別メカニズムを使用します。ネットワークコンピューティング（ONC）リモートプロシージャコール（RPC）プロトコル[RFC5531]。 [RFC2624]のセクション6.1では、UNIX中心の数値IDを使用すると、NFSの規模が大規模なローカルワークグループに制限されることに注意しています。 UNIX中心の数値IDは、NFSv3展開全体で一意ではないため、複数のネーミングドメインと複数のネーミングメカニズムを考慮して実現されるインターネットスケーリング用に設計されていません（セクション6.2を参照）。 NFSv4ドメインのname @ domain構文の使用は、サーバーとクライアントが外部のname @ domain文字列表現をローカルまたは内部の数値（またはその他の識別子）表現に変換できるようにすることで、このインターネットのスケーリングを提供します。
Multi-domain deployments require support for unique identities across the deployment's name services and security services, as well as the use of multi-domain file systems capable of the on-disk representation of identities belonging to multiple NFSv4 Domains. The name@domain syntax can provide unique identities and thus enables the NFSv4 multi-domain file namespace.
マルチドメインデプロイメントでは、デプロイメントのネームサービスとセキュリティサービス全体で一意のIDをサポートする必要があります。また、複数のNFSv4ドメインに属するIDをディスク上で表現できるマルチドメインファイルシステムを使用する必要があります。 name @ domain構文は一意のIDを提供できるため、NFSv4マルチドメインファイル名前空間を有効にします。
Unlike previous versions of NFS, the NFSv4 protocols define a referral mechanism (Section 8.4.3 of [RFC7530]) that allows a single server or a set of servers to present a multi-server namespace that encompasses file systems located on multiple servers. This enables the establishment of site-wide, organization-wide, or even a truly global file namespace.
以前のバージョンのNFSとは異なり、NFSv4プロトコルは参照メカニズム（[RFC7530]のセクション8.4.3）を定義し、単一のサーバーまたはサーバーのセットが、複数のサーバーにあるファイルシステムを含むマルチサーバーの名前空間を提示できるようにします。これにより、サイト全体、組織全体、さらには真にグローバルなファイル名前空間を確立できます。
The NFSv4 protocols' name@domain syntax and referral mechanism along with the use of RPCSEC_GSS security mechanisms enables the construction of an NFSv4 multi-domain file namespace.
NFSv4プロトコルのname @ domain構文と参照メカニズム、およびRPCSEC_GSSセキュリティメカニズムの使用により、NFSv4マルチドメインファイル名前空間の構築が可能になります。
This document presents requirements on the deployment of the NFSv4 protocols for the construction of an NFSv4 file namespace in environments with multiple NFSv4 Domains. To participate in an NFSv4 multi-domain file namespace, the server must offer a multi-domain-capable file system and support RPCSEC_GSS [RFC2203] for user authentication. In most instances, the server must also support identity-mapping services.
このドキュメントでは、複数のNFSv4ドメインが存在する環境でNFSv4ファイル名前空間を構築するためのNFSv4プロトコルの展開に関する要件について説明します。 NFSv4マルチドメインファイルの名前空間に参加するには、サーバーがマルチドメイン対応のファイルシステムを提供し、ユーザー認証用にRPCSEC_GSS [RFC2203]をサポートしている必要があります。ほとんどの場合、サーバーはIDマッピングサービスもサポートする必要があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
NFSv4 Domain: A set of users and groups using the NFSv4 name@domain user and group identification syntax with the same specified @domain.
NFSv4ドメイン：NFSv4 name @ domainユーザーとグループの識別構文を使用し、同じ指定された@domainを持つユーザーとグループのセット。
Stand-alone NFSv4 Domain: A deployment of the NFSv4 protocols and NFSv4 file namespace in an environment with a single NFSv4 Domain.
スタンドアロンNFSv4ドメイン：NFSv4ドメインが1つある環境でのNFSv4プロトコルとNFSv4ファイル名前空間の展開。
Local representation of identity: A representation of a user or a group of users capable of being stored persistently within a file system. Typically, such representations are identical to the form in which users and groups are represented within internal server APIs. Examples are numeric IDs such as a uidNumber (UID), gidNumber (GID) [RFC2307], or a Windows Security Identifier (SID) [CIFS]. In some cases, the identifier space for user and groups overlap, requiring anyone using such an ID to know a priori whether the identifier is for a user or a group.
IDのローカル表現：ファイルシステム内に永続的に格納できるユーザーまたはユーザーグループの表現。通常、このような表現は、ユーザーとグループが内部サーバーAPI内で表現される形式と同じです。例は、uidNumber（UID）、gidNumber（GID）[RFC2307]、またはWindows Security Identifier（SID）[CIFS]などの数値IDです。場合によっては、ユーザーとグループの識別子スペースが重複し、そのようなIDを使用するユーザーは、識別子がユーザー用かグループ用かをアプリオリに知る必要があります。
Unique identity: An on-the-wire form of identity that is unique across an NFSv4 multi-domain namespace that can be mapped to a local representation. For example, the NFSv4 name@domain or the Kerberos principal [RFC4120].
一意のID：ローカル表現にマップできる、NFSv4マルチドメイン名前空間全体で一意のネットワーク上のIDです。たとえば、NFSv4 name @ domainまたはKerberosプリンシパル[RFC4120]。
Multi-domain: In this document, the term "multi-domain" always refers to multiple NFSv4 Domains.
マルチドメイン：このドキュメントでは、「マルチドメイン」という用語は常に複数のNFSv4ドメインを指します。
Multi-domain-capable file system: A local file system that uses a local ID form that can represent NFSv4 identities from multiple domains.
マルチドメイン対応ファイルシステム：複数のドメインからのNFSv4 IDを表すことができるローカルIDフォームを使用するローカルファイルシステム。
Principal: An RPCSEC_GSS [RFC2203] authentication identity. It is usually, but not always, a user; rarely, if ever, a group; and sometimes a host or server.
プリンシパル：RPCSEC_GSS [RFC2203]認証ID。通常は、常にではありませんが、ユーザーです。まれに、グループです。そして時にはホストまたはサーバー。
Authorization Context: A collection of information about a principal such as user name, userID, group membership, etc., used in authorization decisions.
承認コンテキスト：承認の決定に使用される、ユーザー名、ユーザーID、グループメンバーシップなどのプリンシパルに関する情報のコレクション。
Stringified UID or GID: NFSv4 owner and group strings that consist of decimal numeric values with no leading zeros and that do not contain an '@' sign. See Section 5.9 of [RFC5661].
文字列化されたUIDまたはGID：先行ゼロのない10進数の数値で構成され、「@」記号を含まないNFSv4所有者およびグループ文字列。 [RFC5661]のセクション5.9をご覧ください。
Name Service: Facilities that provide the mapping between {NFSv4 Domain, group, or user name} and the appropriate local representation of identity. Also includes facilities providing mapping between a security principal and local representation of identity. Can be applied to unique identities or principals from within local and remote domains. Often provided by a Directory Service such as the Lightweight Directory Access Protocol (LDAP) [RFC4511].
ネームサービス：{NFSv4ドメイン、グループ、またはユーザー名}とIDの適切なローカル表現との間のマッピングを提供する機能。また、セキュリティプリンシパルとIDのローカル表現との間のマッピングを提供する機能も含まれています。ローカルおよびリモートドメイン内から一意のIDまたはプリンシパルに適用できます。多くの場合、ライトウェイトディレクトリアクセスプロトコル（LDAP）[RFC4511]などのディレクトリサービスによって提供されます。
Name Service Switch (nsswitch): A facility that provides a variety of sources for common configuration databases and name resolution mechanisms.
ネームサービススイッチ（nsswitch）：一般的な構成データベースと名前解決メカニズムにさまざまなソースを提供する機能。
FedFS: The Federated File System (FedFS) [RFC5716] describes the requirements and administrative tools to construct a uniform NFSv4 file-server-based namespace that is capable of spanning a whole enterprise and that is easy to manage.
FedFS：フェデレーテッドファイルシステム（FedFS）[RFC5716]では、企業全体にまたがることができ、管理が容易な、統一されたNFSv4ファイルサーバーベースの名前空間を構築するための要件と管理ツールについて説明しています。
Domain: This term is used in multiple contexts where it has different meanings. "NFSv4 Domain" and "multi-domain" are defined above.
ドメイン：この用語は、異なる意味を持つ複数のコンテキストで使用されます。 「NFSv4ドメイン」と「マルチドメイン」は上記で定義されています。
DNS domain: A set of computers, services, or any Internet resource identified by a DNS domain name [RFC1034].
DNSドメイン：DNSドメイン名[RFC1034]で識別されるコンピューター、サービス、またはインターネットリソースのセット。
Security realm or domain: A set of configured security providers, users, groups, security roles, and security policies running a single security protocol and administered by a single entity, for example, a Kerberos realm.
セキュリティレルムまたはドメイン：単一のセキュリティプロトコルを実行し、単一のエンティティ（Kerberosレルムなど）によって管理される、コンフィグレーション済みのセキュリティプロバイダ、ユーザー、グループ、セキュリティロール、およびセキュリティポリシーのセット。
FedFS domain: A file namespace that can cross multiple shares on multiple file servers using file-access protocols such as NFSv4. A FedFS domain is typically a single administrative entity and has a name that is similar to a DNS domain name. Also known as a "Federation".
FedFSドメイン：NFSv4などのファイルアクセスプロトコルを使用して、複数のファイルサーバー上の複数の共有を横断できるファイル名前空間。 FedFSドメインは通常、単一の管理エンティティであり、DNSドメイン名に似た名前を持っています。 「フェデレーション」とも呼ばれます。
Administrative domain: A set of users, groups, computers, and services administered by a single entity. Can include multiple DNS domains, NFSv4 Domains, security domains, and FedFS domains.
管理ドメイン：単一のエンティティーによって管理されるユーザー、グループ、コンピューター、およびサービスのセット。複数のDNSドメイン、NFSv4ドメイン、セキュリティドメイン、およびFedFSドメインを含めることができます。
The FedFS is the standardized method of constructing and administrating an enterprise-wide NFSv4 file system and is thus referenced in this document. The requirements for multi-domain deployments described in this document apply to all NFSv4 multi-domain deployments, whether or not they are run as a FedFS.
FedFSは、企業全体のNFSv4ファイルシステムを構築および管理する標準化された方法であるため、このドキュメントで参照されます。このドキュメントで説明するマルチドメインデプロイメントの要件は、FedFSとして実行されているかどうかに関係なく、すべてのNFSv4マルチドメインデプロイメントに適用されます。
Stand-alone NFSv4 Domain deployments can be run in many ways. While a FedFS can be run within all stand-alone NFSv4 Domain configurations, some of these configurations (Section 5) are not compatible with joining a multi-domain FedFS namespace.
スタンドアロンNFSv4ドメインのデプロイメントは、さまざまな方法で実行できます。 FedFSはすべてのスタンドアロンNFSv4ドメイン構成内で実行できますが、一部の構成（セクション5）はマルチドメインFedFS名前空間への参加と互換性がありません。
NFSv4 servers deal with two kinds of identities: authentication identities (referred to here as "principals") and authorization identities ("users" and "groups" of users). NFSv4 supports multiple authentication methods, each authenticating an "initiator principal" (typically representing a user) to an "acceptor principal" (always corresponding to the NFSv4 server). NFSv4 does not prescribe how to represent authorization identities on file systems. All file access decisions constitute "authorization" and are made by NFSv4 servers using authorization context information and file metadata related to authorization, such as a file's access control list (ACL).
NFSv4サーバーは、認証ID（ここでは「プリンシパル」と呼ばれます）と承認ID（ユーザーの「ユーザー」と「グループ」）の2種類のIDを扱います。 NFSv4は複数の認証方法をサポートし、それぞれが「イニシエータープリンシパル」（通常はユーザーを表す）を「アクセプタープリンシパル」（常にNFSv4サーバーに対応）に対して認証します。 NFSv4は、ファイルシステムで認証IDを表す方法を規定していません。すべてのファイルアクセスの決定は「承認」を構成し、承認コンテキスト情報と、ファイルのアクセス制御リスト（ACL）などの承認に関連するファイルメタデータを使用してNFSv4サーバーによって行われます。
NFSv4 servers may be required to perform two kinds of mappings depending upon what authentication and authorization information is sent on the wire and what is stored in the exported file system. For example, if an authentication identity such as a Kerberos principal is sent with authorization information such as a "privilege attribute certificate" (PAC) [PAC], then mapping is not required (see Section 8).
NFSv4サーバーは、どの認証および許可情報がネットワーク上で送信され、何がエクスポートされたファイルシステムに格納されているかに応じて、2種類のマッピングを実行する必要があります。たとえば、Kerberosプリンシパルなどの認証IDが「特権属性証明書」（PAC）[PAC]などの承認情報とともに送信される場合、マッピングは必要ありません（セクション8を参照）。
1. Auth-to-authz: A mapping between the authentication identity and the authorization context information.
1. Auth-to-authz：認証IDと承認コンテキスト情報の間のマッピング。
2. Wire-to-disk: A mapping between the on-the-wire authorization identity representation and the on-disk authorization identity representation.
2. ワイヤーからディスクへ：ワイヤー上の承認ID表現とディスク上の承認ID表現の間のマッピング。
A name service such as LDAP often provides these mappings.
LDAPなどのネームサービスは、多くの場合、これらのマッピングを提供します。
Many aspects of these mappings are entirely implementation specific, but some require multi-domain-capable name resolution and security services in order to interoperate in a multi-domain environment.
これらのマッピングの多くの側面は完全に実装固有ですが、マルチドメイン環境で相互運用するために、マルチドメイン対応の名前解決とセキュリティサービスを必要とするものもあります。
NFSv4 servers use these mappings for:
NFSv4サーバーはこれらのマッピングを次の目的で使用します。
1. File access: Both the auth-to-authz and the wire-to-disk mappings may be required for file access decisions.
1. ファイルアクセス：ファイルアクセスの決定には、auth-to-authzマッピングとWire-to-diskマッピングの両方が必要になる場合があります。
2. Metadata setting and listing: The auth-to-authz mapping is usually required to service file metadata setting or listing requests such as ACL or UNIX permission setting or listing. This mapping is needed because NFSv4 messages use identity representations of the form name@domain, which normally differs from the server's local representation of identity.
2. メタデータの設定と一覧表示：ACLやUNIXのアクセス許可の設定や一覧など、ファイルのメタデータの設定や一覧の要求を処理するには、通常、auth-to-authzマッピングが必要です。 NFSv4メッセージはname @ domain形式のID表現を使用するため、このマッピングが必要です。これは通常、サーバーのローカルのID表現とは異なります。
A client setting the owner or group attribute will often need access to identity-mapping services. This is because APIs within the client will specify the identity in a local form (e.g., UNIX using a UID/ GID) so that when stringified id's cannot be used, the ID must be converted to a unique identity form.
多くの場合、所有者またはグループ属性を設定するクライアントは、IDマッピングサービスにアクセスする必要があります。これは、クライアント内のAPIがローカル形式（たとえば、UID / GIDを使用するUNIX）でIDを指定するため、文字列化されたIDを使用できない場合、IDを一意のID形式に変換する必要があるためです。
A client obtaining values for the owner or group attributes will similarly need access to identity-mapping services. This is because the client API will need these attributes in a local form, as above. As a result, name services need to be available to convert the unique identity to a local form.
所有者またはグループ属性の値を取得するクライアントは、同様にアイデンティティーマッピングサービスにアクセスする必要があります。これは、上記のように、クライアントAPIがローカルフォームでこれらの属性を必要とするためです。その結果、一意のIDをローカルフォームに変換するためにネームサービスを利用できる必要があります。
Note that each of these situations arises because client-side APIs require a particular local identity representation. The need for mapping services would not arise if the clients could use the unique representation of identity directly.
クライアント側のAPIには特定のローカルID表現が必要なため、これらの各状況が発生することに注意してください。クライアントがIDの一意の表現を直接使用できる場合、マッピングサービスの必要性は発生しません。
The purpose of this section is to list some typical stand-alone deployment examples to highlight the need for the required restraints to the NFSv4 protocol, name service configuration, and security service choices in an NFSv4 multi-domain environment described in Section 6.
このセクションの目的は、セクション6で説明されているNFSv4マルチドメイン環境でのNFSv4プロトコル、ネームサービス構成、およびセキュリティサービスの選択に対する必要な制約の必要性を強調するために、いくつかの典型的なスタンドアロン展開の例をリストすることです。
Section 7 notes how these stand-alone deployment examples would need to change to participate in an NFSv4 multi-domain deployment.
セクション7では、NFSv4マルチドメインデプロイメントに参加するために、これらのスタンドアロンデプロイメントの例をどのように変更する必要があるかについて説明します。
In order to service as many environments as possible, the NFSv4 protocol is designed to allow administrators freedom to configure their NFSv4 Domains as they please. Stand-alone NFSv4 Domains can be run in many ways.
できるだけ多くの環境にサービスを提供するために、NFSv4プロトコルは、管理者が自由にNFSv4ドメインを自由に構成できるように設計されています。スタンドアロンNFSv4ドメインは、さまざまな方法で実行できます。
These examples are for an NFSv4 server exporting a POSIX UID/GID-based file system, a typical deployment. These examples are listed in the order of increasing NFSv4 administrative complexity.
これらの例は、POSIX UID / GIDベースのファイルシステムをエクスポートするNFSv4サーバーの典型的な展開です。これらの例は、NFSv4管理の複雑さが増す順にリストされています。
This example is the closest NFSv4 gets to being run as NFSv3 as there is no need for a name service for file metadata listing.
この例は、ファイルメタデータのリストにネームサービスが必要ないため、NFSv3として実行される最も近いNFSv4です。
File access: The AUTH_SYS RPC credential [RFC5531] provides a UID as the authentication identity, and a list of GIDs as authorization context information. File access decisions require no name service interaction as the on-the-wire and on-disk representation are the same and the auth-to-authz UID and GID authorization context information is provided in the RPC credential.
ファイルアクセス：AUTH_SYS RPCクレデンシャル[RFC5531]は、認証IDとしてUIDを提供し、承認コンテキスト情報としてGIDのリストを提供します。 on-the-wireとon-diskの表現は同じであり、auth-to-authzのUIDとGIDの承認コンテキスト情報がRPC資格情報で提供されるため、ファイルアクセスの決定にはネームサービスの相互作用は必要ありません。
Metadata setting and listing: When the NFSv4 clients and servers implement a stringified UID/GID scheme, where a stringified UID or GID is used for the NFSv4 name@domain on-the-wire identity, then a name service is not required for file metadata listing as the UID, or GID can be constructed from the stringified form on the fly by the server.
メタデータの設定とリスト：NFSv4クライアントとサーバーが文字列化されたUID / GIDスキームを実装する場合、文字列化されたUIDまたはGIDがNFSv4 name @ domain on-the-wire IDに使用される場合、ファイルメタデータにネームサービスは必要ありませんサーバーは、UIDまたはGIDとしてリストをオンザフライで文字列化された形式から構築できます。
Another possibility is to express identity using the form 'name@domain', rather than using a stringified UID/GID scheme for file metadata setting and listing.
別の可能性は、ファイルメタデータの設定とリストに文字列化されたUID / GIDスキームを使用するのではなく、「name @ domain」の形式を使用してIDを表現することです。
File access: This is the same as in Section 5.1.
ファイルアクセス：これは、セクション5.1と同じです。
Metadata setting and listing: The NFSv4 server will need to use a name service for the wire-to-disk mappings to map between the on-the-wire name@domain syntax and the on-disk UID/GID representation. Often, the NFSv4 server will use the nsswitch interface for these mappings. A typical use of the nsswitch name service interface uses no domain component, just the UID attribute [RFC2307] (or login name) as the name component. This is not an issue in a stand-alone NFSv4 Domain deployment as the NFSv4 Domain is known to the NFSv4 server and can be combined with the login name to form the name@domain syntax after the return of the name service call.
メタデータの設定とリスト：NFSv4サーバーは、ワイヤーからディスクへのマッピングにネームサービスを使用して、ワイヤー上のname @ domain構文とディスク上のUID / GID表現をマッピングする必要があります。多くの場合、NFSv4サーバーはこれらのマッピングにnsswitchインターフェースを使用します。 nsswitchネームサービスインターフェースの一般的な使用方法では、ドメインコンポーネントを使用せず、UID属性[RFC2307]（またはログイン名）のみを名前コンポーネントとして使用します。 NFSv4ドメインはNFSv4サーバーに認識されており、ネームサービスコールが返された後、ログイン名と組み合わせてname @ domain構文を形成できるため、これはスタンドアロンNFSv4ドメインの展開では問題になりません。
RPCSEC_GSS uses Generic Security Service Application Program Interface (GSS-API) [RFC2743] security mechanisms to securely authenticate users to servers. The most common mechanism is Kerberos [RFC4121].
RPCSEC_GSSは、汎用セキュリティサービスアプリケーションプログラムインターフェイス（GSS-API）[RFC2743]セキュリティメカニズムを使用して、サーバーに対してユーザーを安全に認証します。最も一般的なメカニズムは、Kerberos [RFC4121]です。
This final example adds the use of RPCSEC_GSS with the Kerberos 5 GSS security mechanism.
この最後の例では、Kerberos 5 GSSセキュリティメカニズムでRPCSEC_GSSの使用を追加しています。
File Access: The forms of GSS principal names are mechanism specific. For Kerberos, these are of the form principal@REALM. Sometimes authorization context information is delivered with authentication, but this cannot be counted on. Authorization context information not delivered with authentication has timely update considerations (i.e., generally it's not possible to get a timely update). File access decisions therefore require a wire-to-disk mapping of the GSS principal to a UID and an auth-to-authz mapping to obtain the list of GIDs as the authorization context.
ファイルアクセス：GSSプリンシパル名の形式は、メカニズム固有です。 Kerberosの場合、これらの形式はprincipal @ REALMです。承認コンテキスト情報が認証とともに配信されることがありますが、これは当てにできません。認証で配信されない承認コンテキスト情報には、タイムリーな更新の考慮事項があります（つまり、通常、タイムリーな更新を取得することはできません）。したがって、ファイルアクセスの決定には、GSSプリンシパルのUIDへのワイヤーからディスクへのマッピングと、auth-to-authzマッピングから、承認コンテキストとしてのGIDのリストを取得する必要があります。
Metadata setting and listing: This is the same as in Section 5.2.
メタデータの設定とリスト：これはセクション5.2と同じです。
Joining NFSv4 Domains under a single file namespace imposes slightly on the NFSv4 administrative freedom. In this section, we describe the required constraints.
単一のファイル名前空間の下でNFSv4ドメインに参加すると、NFSv4の管理の自由度がわずかに低下します。このセクションでは、必要な制約について説明します。
NFSv4 uses a syntax of the form "name@domain" (see Section 5.9 of [RFC7530]) as the on-the-wire representation of the "who" field of an NFSv4 access control entry (ACE) for users and groups. This design provides a level of indirection that allows NFSv4 clients and servers with different internal representations of authorization identity to interoperate even when referring to authorization identities from different NFSv4 Domains.
NFSv4は、「name @ domain」（[RFC7530]のセクション5.9を参照）という形式の構文を、ユーザーとグループのNFSv4アクセス制御エントリ（ACE）の「who」フィールドの送信中の表現として使用します。この設計は、許可IDの内部表現が異なるNFSv4クライアントとサーバーが、異なるNFSv4ドメインの許可IDを参照する場合でも相互運用できるレベルの間接参照を提供します。
Multi-domain-capable sites need to meet the following requirements in order to ensure that NFSv4 clients and servers can map between name@domain and internal representations reliably. While some of these constraints are basic assumptions in NFSv4.0 [RFC7530] and NFSv4.1 [RFC5661], they need to be clearly stated for the multi-domain case.
マルチドメイン対応のサイトは、NFSv4クライアントとサーバーがname @ domainと内部表現を確実にマッピングできるようにするために、次の要件を満たす必要があります。これらの制約の一部は、NFSv4.0 [RFC7530]およびNFSv4.1 [RFC5661]の基本的な仮定ですが、マルチドメインの場合は明確に述べる必要があります。
o The NFSv4 Domain portion of name@domain MUST be unique within the multi-domain namespace. See [RFC5661], Section 5.9 ("Interpreting owner and owner_group") for a discussion on NFSv4 Domain configuration.
o name @ domainのNFSv4ドメイン部分は、マルチドメイン名前空間内で一意である必要があります。 NFSv4ドメインの構成については、[RFC5661]のセクション5.9（「所有者とowner_groupの解釈」）をご覧ください。
o The name portion of name@domain MUST be unique within the specified NFSv4 Domain.
o name @ domainの名前部分は、指定されたNFSv4ドメイン内で一意である必要があります。
Due to UID and GID collisions, stringified UID/GIDs MUST NOT be used in a multi-domain deployment. This means that multi-domain-capable servers MUST reject requests that use stringified UID/GIDs.
UIDとGIDの衝突のため、文字列化されたUID / GIDはマルチドメイン展開で使用してはなりません（MUST NOT）。つまり、マルチドメイン対応サーバーは、文字列化されたUID / GIDを使用するリクエストを拒否する必要があります。
Here we address the relationship between NFSv4 Domain name and DNS domain name in a multi-domain deployment.
ここでは、マルチドメイン展開におけるNFSv4ドメイン名とDNSドメイン名の関係について説明します。
The definition of an NFSv4 Domain name, the @domain portion of the name@domain syntax, needs clarification to work in a multi-domain file system namespace. [RFC5661], Section 5.9 loosely defines the NFSv4 Domain name as a DNS domain name. This loose definition for the NFSv4 Domain name is a good one, as DNS domain names are globally unique. As noted in Section 6.1, any choice of NFSv4 Domain name can
NFSv4ドメイン名の定義、name @ domain構文の@domain部分は、マルチドメインファイルシステムの名前空間で機能するように明確にする必要があります。 [RFC5661]、セクション5.9では、NFSv4ドメイン名をDNSドメイン名として大まかに定義しています。 DNSドメイン名はグローバルに一意であるため、NFSv4ドメイン名のこの緩い定義は適切です。セクション6.1で述べたように、NFSv4ドメイン名を選択すると、
work within a stand-alone NFSv4 Domain deployment whereas the NFSv4 Domain name is required to be unique across a multi-domain deployment.
スタンドアロンのNFSv4ドメイン展開内で機能しますが、NFSv4ドメイン名はマルチドメイン展開全体で一意である必要があります。
A typical configuration is that there is a single NFSv4 Domain that is served by a single DNS domain. In this case, the NFSv4 Domain name can be the same as the DNS domain name.
典型的な構成は、単一のDNSドメインによって提供される単一のNFSv4ドメインがあることです。この場合、NFSv4ドメイン名はDNSドメイン名と同じにすることができます。
An NFSv4 Domain can span multiple DNS domains. In this case, one of the DNS domain names can be chosen as the NFSv4 Domain name.
NFSv4ドメインは複数のDNSドメインにまたがることができます。この場合、DNSドメイン名の1つをNFSv4ドメイン名として選択できます。
Multiple NFSv4 Domains can also share a DNS domain. In this case, only one of the NFSv4 Domains can use the DNS domain name, the other NFSv4 Domains must choose another unique NFSv4 Domain name.
複数のNFSv4ドメインがDNSドメインを共有することもできます。この場合、1つのNFSv4ドメインのみがDNSドメイン名を使用でき、他のNFSv4ドメインは別の一意のNFSv4ドメイン名を選択する必要があります。
As noted in Section 6.1, each name@domain is unique across the multi-domain namespace and maps, on each NFSv4 server, to the local representation of identity used by that server. Typically, this representation consists of an indication of the particular domain combined with the UID/GID corresponding to the name component. To support such an arrangement, each NFSv4 Domain needs to have a single name resolution service capable of converting the names defined within the domain to the corresponding local representation.
セクション6.1で述べたように、各name @ domainはマルチドメイン名前空間全体で一意であり、各NFSv4サーバーで、そのサーバーが使用するIDのローカル表現にマップします。通常、この表現は、名前コンポーネントに対応するUID / GIDと組み合わせた特定のドメインの表示で構成されます。このような配置をサポートするには、各NFSv4ドメインに、ドメイン内で定義された名前を対応するローカル表現に変換できる単一の名前解決サービスが必要です。
As described in [RFC5661], Section 2.2.1.1 ("RPC Security Flavors"):
[RFC5661]のセクション2.2.1.1（「RPCセキュリティフレーバー」）に記載されているとおり：
NFSv4.1 clients and servers MUST implement RPCSEC_GSS. (This requirement to implement is not a requirement to use.) Other flavors, such as AUTH_NONE and AUTH_SYS, MAY be implemented as well.
NFSv4.1クライアントとサーバーは、RPCSEC_GSSを実装する必要があります。 （この実装するための要件は、使用するための要件ではありません。）AUTH_NONEやAUTH_SYSなどの他のフレーバーも実装できます（MAY）。
The underlying RPCSEC_GSS GSS-API [RFC2203] security mechanism used in a multi-domain namespace is REQUIRED to employ a method of cross NFSv4 Domain trust so that a principal from a security service in one NFSv4 Domain can be authenticated in another NFSv4 Domain that uses a security service with the same security mechanism. Kerberos is an example of such a security service.
マルチドメイン名前空間で使用されている基になるRPCSEC_GSS GSS-API [RFC2203]セキュリティメカニズムは、NFSv4ドメイン間の信頼の方法を使用して、あるNFSv4ドメインのセキュリティサービスのプリンシパルを、別のNFSv4ドメインで認証できるようにする必要があります。同じセキュリティメカニズムを持つセキュリティサービス。 Kerberosはそのようなセキュリティサービスの例です。
The AUTH_NONE [RFC5531] security flavor can be useful in a multi-domain deployment to grant universal read-only access to public data without any credentials.
AUTH_NONE [RFC5531]セキュリティフレーバーは、マルチドメイン展開で、資格情報なしでパブリックデータへの読み取り専用アクセスを許可するのに役立ちます。
The AUTH_SYS security flavor [RFC5531] uses a host-based authentication model where the weakly authenticated host (the NFSv4 client) asserts the user's authorization identities using small integers, uidNumber, and gidNumber [RFC2307] as user and group identity representations. Because this authorization ID representation has no domain component, AUTH_SYS can only be used in a namespace where all NFSv4 clients and servers share a name service as described in [RFC2307]. A shared name service is required because uidNumbers and gidNumbers are passed in the RPC credential; there is no negotiation of namespace in AUTH_SYS. Collisions can occur if multiple name services are used, so AUTH_SYS MUST NOT be used in a multi-domain file system deployment.
AUTH_SYSセキュリティフレーバー[RFC5531]は、弱く認証されたホスト（NFSv4クライアント）が小さな整数、uidNumber、およびgidNumber [RFC2307]をユーザーおよびグループID表現として使用してユーザーの承認IDをアサートするホストベースの認証モデルを使用します。この認証ID表現にはドメインコンポーネントがないため、AUTH_SYSは、[RFC2307]で説明されているように、すべてのNFSv4クライアントとサーバーがネームサービスを共有するネームスペースでのみ使用できます。 uidNumbersとgidNumbersはRPC資格情報で渡されるため、共有ネームサービスが必要です。 AUTH_SYSでは名前空間のネゴシエーションはありません。複数のネームサービスを使用すると衝突が発生する可能性があるため、マルチドメインファイルシステムのデプロイメントではAUTH_SYSを使用してはなりません（MUST NOT）。
As noted in Section 6.2 regarding AUTH_NONE, multiple NFSv4 Domain security services are RPCSEC_GSS based with the Kerberos 5 security mechanism being the most commonly (and as of this writing, the only) deployed service.
AUTH_NONEに関するセクション6.2で述べたように、複数のNFSv4ドメインセキュリティサービスはRPCSEC_GSSに基づいており、Kerberos 5セキュリティメカニズムが最も一般的に（このドキュメントの執筆時点では唯一）展開されているサービスです。
A single Kerberos 5 security service per NFSv4 Domain with the upper case NFSv4 Domain name as the Kerberos 5 REALM name is a common deployment.
大文字のNFSv4ドメイン名をKerberos 5 REALM名として使用するNFSv4ドメインごとの単一のKerberos 5セキュリティサービスは、一般的な展開です。
Multiple security services per NFSv4 Domain is allowed and brings the need of mapping multiple Kerberos 5 principal@REALMs to the same local ID. Methods of achieving this are beyond the scope of this document.
NFSv4ドメインごとに複数のセキュリティサービスが許可され、複数のKerberos 5 principal @ REALMを同じローカルIDにマッピングする必要が生じます。これを達成する方法は、このドキュメントの範囲を超えています。
In this section, we revisit the stand-alone NFSv4 Domain deployment examples in Section 5 and note what is prohibiting them from participating in an NFSv4 multi-domain deployment.
このセクションでは、セクション5のスタンドアロンNFSv4ドメイン展開の例を再検討し、NFSv4マルチドメイン展開への参加を妨げている原因に注意します。
Note that because all on-disk identities participating in a stand-alone NFSv4 Domain belong to the same NFSv4 Domain, stand-alone NFSv4 Domain deployments have no requirement for exporting multi-domain-capable file systems. To participate in an NFSv4 multi-domain deployment, all three examples in Section 5 would need to export multi-domain-capable file systems.
スタンドアロンNFSv4ドメインに参加しているすべてのディスク上のIDは同じNFSv4ドメインに属しているため、スタンドアロンNFSv4ドメインのデプロイメントでは、マルチドメイン対応のファイルシステムをエクスポートする必要がないことに注意してください。 NFSv4マルチドメイン展開に参加するには、セクション5の3つの例すべてがマルチドメイン対応のファイルシステムをエクスポートする必要があります。
Due to the use of AUTH_SYS and stringified UID/GIDs, the first stand-alone deployment example (described in Section 5.1) is not suitable for participation in an NFSv4 multi-domain deployment.
AUTH_SYSと文字列化されたUID / GIDを使用しているため、最初のスタンドアロン展開の例（セクション5.1で説明）は、NFSv4マルチドメイン展開への参加には適していません。
The second example (described in Section 5.2) does use the name@domain syntax, but the use of AUTH_SYS prohibits its participation in an NFSv4 multi-domain deployment.
2番目の例（セクション5.2で説明）ではname @ domain構文を使用していますが、AUTH_SYSを使用すると、NFSv4マルチドメインデプロイメントへの参加が禁止されます。
The third example (described in Section 5.3) can participate in a multi-domain namespace deployment if:
3番目の例（セクション5.3で説明）は、次の場合にマルチドメイン名前空間のデプロイメントに参加できます。
o The NFSv4 Domain name is unique across the namespace.
o NFSv4ドメイン名は名前空間全体で一意です。
o All exported file systems are multi-domain capable.
o エクスポートされたすべてのファイルシステムはマルチドメイン対応です。
o A secure method is used to resolve the remote NFSv4 Domain principal's authorization information from an authoritative source.
o 安全な方法を使用して、信頼できるソースからリモートNFSv4ドメインプリンシパルの承認情報を解決します。
When an RPCSEC_GSS principal is seeking access to files on an NFSv4 server, after authenticating the principal, the server SHOULD obtain in a secure manner the principal's authorization context information from an authoritative source such as the name service in the principal's NFSv4 Domain.
RPCSEC_GSSプリンシパルがNFSv4サーバー上のファイルへのアクセスを求めている場合、プリンシパルを認証した後、サーバーは、プリンシパルのNFSv4ドメインのネームサービスなどの信頼できるソースから、プリンシパルの承認コンテキスト情報を安全な方法で取得する必要があります。
In the stand-alone NFSv4 Domain case where the principal is seeking access to files on an NFSv4 server in the principal's home NFSv4 Domain, the server administrator has knowledge of the local policies and methods for obtaining the principal's authorization information and the mappings to local representation of identity from an authoritative source. For example, the administrator can configure secure access to the local NFSv4 Domain name service.
プリンシパルがプリンシパルのホームNFSv4ドメイン内のNFSv4サーバー上のファイルへのアクセスを求めているスタンドアロンのNFSv4ドメインの場合、サーバー管理者は、プリンシパルの承認情報とローカル表現へのマッピングを取得するためのローカルポリシーとメソッドに関する知識を持っています。信頼できるソースからのアイデンティティの。たとえば、管理者はローカルのNFSv4ドメインネームサービスへの安全なアクセスを設定できます。
In the multi-domain case where a principal is seeking access to files on an NFSv4 server not in the principal's home NFSv4 Domain, the NFSv4 server may be required to contact the remote name service in the principal's NFSv4 Domain. In this case, there is no assumption of:
プリンシパルが、プリンシパルのホームNFSv4ドメインにないNFSv4サーバー上のファイルへのアクセスを求めているマルチドメインの場合、NFSv4サーバーは、プリンシパルのNFSv4ドメインのリモートネームサービスに接続する必要がある場合があります。この場合、以下の仮定はありません。
o Remote name service configuration knowledge.
o リモートネームサービス構成の知識。
o The syntax of the remote authorization context information presented to the NFSv4 server by the remote name service for mapping to a local representation.
o ローカル表現にマッピングするためにリモートネームサービスによってNFSv4サーバーに提示されるリモート許可コンテキスト情報の構文。
There are several methods the NFSv4 server can use to obtain the NFSv4 Domain authoritative authorization information for a remote principal from an authoritative source. While detailing these methods is beyond the scope of this document, some general methods are listed here.
権限のあるソースからリモートプリンシパルのNFSv4ドメインの権限のある承認情報を取得するためにNFSv4サーバーが使用できる方法はいくつかあります。これらの方法の詳細はこのドキュメントの範囲外ですが、いくつかの一般的な方法をここにリストします。
1. A mechanism-specific GSS-API authorization payload containing credential authorization data such as a "privilege attribute certificate" (PAC) [PAC] or a "principal authorization data" (PAD) [GEN-PAC]. This is the preferred method as the payload is delivered as part of GSS-API authentication, avoids requiring any knowledge of the remote authoritative service configuration, and has a well-known syntax.
1. 「特権属性証明書」（PAC）[PAC]または「プリンシパル認証データ」（PAD）[GEN-PAC]などの認証情報認証データを含む、メカニズム固有のGSS-API認証ペイロード。ペイロードはGSS-API認証の一部として配信され、リモートの信頼できるサービス構成の知識を必要とせず、よく知られた構文を持つため、これは推奨される方法です。
2. When there is a security agreement between the local and remote NFSv4 Domain name services plus regular update data feeds, the NFSv4 server local NFSv4 Domain name service can be authoritative for principals in the remote NFSv4 Domain. In this case, the NFSv4 server makes a query to its local NFSv4 Domain name service just as it does when servicing a local domain principal. While this requires detailed knowledge of the remote NFSv4 Domain name service for the update data feeds, the authorization context information presented to the NFSv4 server is in the same form as a query for a local principal.
2. ローカルとリモートのNFSv4ドメインネームサービスと定期的な更新データフィードの間にセキュリティ協定がある場合、NFSv4サーバーのローカルNFSv4ドメインネームサービスは、リモートNFSv4ドメインのプリンシパルに対して権限を持つことができます。この場合、NFSv4サーバーは、ローカルドメインプリンシパルにサービスを提供する場合と同様に、ローカルNFSv4ドメインネームサービスにクエリを実行します。これには、更新データフィード用のリモートNFSv4ドメインネームサービスの詳細な知識が必要ですが、NFSv4サーバーに提示される承認コンテキスト情報は、ローカルプリンシパルのクエリと同じ形式です。
3. An authenticated direct query from the NFSv4 server to the principal's NFSv4 Domain authoritative name service. This requires the NFSv4 server to have detailed knowledge of the remote NFSv4 Domain's authoritative name service and detailed knowledge of the syntax of the resultant authorization context information.
3. NFSv4サーバーからプリンシパルのNFSv4ドメイン権限のあるネームサービスへの認証された直接クエリ。これには、NFSv4サーバーがリモートNFSv4ドメインの信頼できるネームサービスの詳細な知識と、結果として得られる承認コンテキスト情報の構文の詳細な知識を持っている必要があります。
This RFC discusses security throughout. All the security considerations of the relevant protocols, such as NFSv4.0 [RFC7530], NFSv4.1 [RFC5661], RPCSEC_GSS [RFC2203], GSS-API [RFC4121], LDAP [RFC4511], Requirements for Federated FS [RFC5716], FedFS Namespace Database Protocol [RFC7532], FedFS Administration Protocol [RFC7533], and FedFS Security Addendum [SEC-ADD] apply.
このRFCは、セキュリティ全体を説明しています。 NFSv4.0 [RFC7530]、NFSv4.1 [RFC5661]、RPCSEC_GSS [RFC2203]、GSS-API [RFC4121]、LDAP [RFC4511]、フェデレーテッドFSの要件[RFC5716]など、関連プロトコルのセキュリティに関するすべての考慮事項FedFS名前空間データベースプロトコル[RFC7532]、FedFS管理プロトコル[RFC7533]、およびFedFSセキュリティ補足[SEC-ADD]が適用されます。
Authentication and authorization across administrative domains present security considerations, most of which are treated elsewhere, but we repeat some of them here:
管理ドメイン間での認証と承認にはセキュリティ上の考慮事項があり、そのほとんどは他の場所で扱われますが、ここではそれらの一部を繰り返します。
o latency in propagation of revocation of authentication credentials
o 認証資格情報の失効の伝播における待ち時間
o latency in propagation of revocation of authorizations
o 承認の取り消しの伝播における待ち時間
o latency in propagation of granting of authorizations
o 認可の付与の伝播における待ち時間
o complications in establishing a complete authorization context for users of a foreign domain (only parts may be available to servers)
o 外部ドメインのユーザーに対して完全な承認コンテキストを確立する際の複雑さ（サーバーで使用できるのは一部のみ）
o privacy considerations in a federated environment
o 連合環境でのプライバシーに関する考慮事項
Most of these are security considerations of the mechanisms used to authenticate users to servers and servers to users and of the mechanisms used to evaluate a user's authorization context.
これらのほとんどは、ユーザーをサーバーに、サーバーをユーザーに認証するために使用されるメカニズムと、ユーザーの承認コンテキストを評価するために使用されるメカニズムのセキュリティに関する考慮事項です。
Implementors may be tempted to assume that "realm" (or "issuer") and "NFSv4 Domain" are roughly the same thing, but they are not. Configuration and/or lookup protocols (such as LDAP) and associated schemas are generally required in order to evaluate a user principal's authorization context (see Section 8). In the simplest scheme, a server has access to a database mapping all known principal names to user names whose authorization context can be evaluated using operating system interfaces that deal in user names rather than principal names.
実装者は、「レルム」（または「発行者」）と「NFSv4ドメイン」は大体同じものであると想定したくなるかもしれませんが、そうではありません。一般に、ユーザープリンシパルの承認コンテキストを評価するには、構成プロトコルやルックアッププロトコル（LDAPなど）および関連するスキーマが必要です（セクション8を参照）。最も単純なスキームでは、サーバーはデータベースにアクセスして、すべての既知のプリンシパル名をユーザー名にマッピングします。その承認コンテキストは、プリンシパル名ではなくユーザー名を扱うオペレーティングシステムインターフェイスを使用して評価できます。
Note that clients may also need to evaluate a server's authorization context when using labeled security [RFC7862] (e.g., is the server authorized to handle content at a given security level for the given client process subject label).
ラベル付きセキュリティ[RFC7862]を使用する場合、クライアントもサーバーの承認コンテキストを評価する必要がある場合があることに注意してください（たとえば、サーバーは、特定のクライアントプロセスサブジェクトラベルの特定のセキュリティレベルでコンテンツを処理することを承認されています）。
When the server accepts user credentials from more than one realm, it is important to remember that the server must verify that the client it is talking to has a credential for the name the client has presented the server and that the credential's issuer (i.e., its realm) is allowed to issue it. Usually, the service principal realm authorization function is implemented by the security mechanism, but the implementor should check this.
サーバーが複数のレルムからユーザーの資格情報を受け入れる場合、サーバーは、クライアントがサーバーに提示した名前の資格情報と、資格情報の発行者（つまり、レルム）を発行できます。通常、サービスプリンシパルレルム認可機能はセキュリティメカニズムによって実装されますが、実装者はこれを確認する必要があります。
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <http://www.rfc-editor.org/info/rfc1034>.
[RFC1034] Mockapetris、P。、「ドメイン名-概念と機能」、STD 13、RFC 1034、DOI 10.17487 / RFC1034、1987年11月、<http://www.rfc-editor.org/info/rfc1034>。
[RFC1813] Callaghan, B., Pawlowski, B., and P. Staubach, "NFS Version 3 Protocol Specification", RFC 1813, DOI 10.17487/RFC1813, June 1995, <http://www.rfc-editor.org/info/rfc1813>.
[RFC1813] Callaghan、B.、Pawlowski、B。、およびP. Staubach、「NFSバージョン3プロトコル仕様」、RFC 1813、DOI 10.17487 / RFC1813、1995年6月、<http://www.rfc-editor.org/ info / rfc1813>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC2203] Eisler, M., Chiu, A., and L. Ling, "RPCSEC_GSS Protocol Specification", RFC 2203, DOI 10.17487/RFC2203, September 1997, <http://www.rfc-editor.org/info/rfc2203>.
[RFC2203] Eisler、M.、Chiu、A。、およびL. Ling、「RPCSEC_GSS Protocol Specification」、RFC 2203、DOI 10.17487 / RFC2203、1997年9月、<http://www.rfc-editor.org/info/ rfc2203>。
[RFC2743] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, DOI 10.17487/RFC2743, January 2000, <http://www.rfc-editor.org/info/rfc2743>.
[RFC2743] Linn、J。、「Generic Security Service Application Program Interface Version 2、Update 1」、RFC 2743、DOI 10.17487 / RFC2743、2000年1月、<http://www.rfc-editor.org/info/rfc2743> 。
[RFC4121] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2", RFC 4121, DOI 10.17487/RFC4121, July 2005, <http://www.rfc-editor.org/info/rfc4121>.
[RFC4121] Zhu、L.、Jaganathan、K。、およびS. Hartman、「The Kerberos Version 5 Generic Security Service Application Program Interface（GSS-API）Mechanism：Version 2」、RFC 4121、DOI 10.17487 / RFC4121、2005年7月、<http://www.rfc-editor.org/info/rfc4121>。
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access Protocol (LDAP): The Protocol", RFC 4511, DOI 10.17487/RFC4511, June 2006, <http://www.rfc-editor.org/info/rfc4511>.
[RFC4511] Sermersheim、J。、編、「ライトウェイトディレクトリアクセスプロトコル（LDAP）：プロトコル」、RFC 4511、DOI 10.17487 / RFC4511、2006年6月、<http://www.rfc-editor.org/info/ rfc4511>。
[RFC5661] Shepler, S., Ed., Eisler, M., Ed., and D. Noveck, Ed., "Network File System (NFS) Version 4 Minor Version 1 Protocol", RFC 5661, DOI 10.17487/RFC5661, January 2010, <http://www.rfc-editor.org/info/rfc5661>.
[RFC5661] Shepler、S.、Ed。、Eisler、M.、Ed。、and D. Noveck、Ed。、 "Network File System（NFS）Version 4 Minor Version 1 Protocol"、RFC 5661、DOI 10.17487 / RFC5661、 2010年1月、<http://www.rfc-editor.org/info/rfc5661>。
[RFC7530] Haynes, T., Ed. and D. Noveck, Ed., "Network File System (NFS) Version 4 Protocol", RFC 7530, DOI 10.17487/RFC7530, March 2015, <http://www.rfc-editor.org/info/rfc7530>.
[RFC7530]ヘインズ、T。、エド。およびD. Noveck編、「Network File System（NFS）Version 4 Protocol」、RFC 7530、DOI 10.17487 / RFC7530、2015年3月、<http://www.rfc-editor.org/info/rfc7530>。
[RFC7862] Haynes, T., "Network File System (NFS) Version 4 Minor Version 2 Protocol", RFC 7862, DOI 10.17487/RFC7862, November 2016, <http://www.rfc-editor.org/info/rfc7862>.
[RFC7862]ヘインズ、T。、「ネットワークファイルシステム（NFS）バージョン4マイナーバージョン2プロトコル」、RFC 7862、DOI 10.17487 / RFC7862、2016年11月、<http://www.rfc-editor.org/info/rfc7862 >。
[CIFS] Microsoft Corporation, "[MS-CIFS]: Common Internet File System (CIFS) Protocol", MS-CIFS v20160714 (Rev 26.0), July 2016.
[CIFS] Microsoft Corporation、「[MS-CIFS]：Common Internet File System（CIFS）Protocol」、MS-CIFS v20160714（Rev 26.0）、2016年7月。
[GEN-PAC] Sorce, S., Ed., Yu, T., Ed., and T. Hardjono, Ed., "A Generalized PAC for Kerberos V5", Work in Progress, draft-ietf-krb-wg-general-pac-01, October 2011.
[GEN-PAC] Sorce、S。、編、Yu、T。、編、およびT. Hardjono、編、「A Kerberos V5向けの一般化されたPAC」、作業中、draft-ietf-krb-wg- general-pac-01、2011年10月。
[PAC] Brezak, J., "Utilizing the Windows 2000 Authorization Data in Kerberos Tickets for Access Control to Resources", February 2002.
[PAC] Brezak、J。、「リソースへのアクセス制御のためのKerberosチケットでのWindows 2000認証データの利用」、2002年2月。
[RFC2307] Howard, L., "An Approach for Using LDAP as a Network Information Service", RFC 2307, DOI 10.17487/RFC2307, March 1998, <http://www.rfc-editor.org/info/rfc2307>.
[RFC2307]ハワードL.、「ネットワーク情報サービスとしてLDAPを使用するためのアプローチ」、RFC 2307、DOI 10.17487 / RFC2307、1998年3月、<http://www.rfc-editor.org/info/rfc2307>。
[RFC2624] Shepler, S., "NFS Version 4 Design Considerations", RFC 2624, DOI 10.17487/RFC2624, June 1999, <http://www.rfc-editor.org/info/rfc2624>.
[RFC2624] Shepler、S。、「NFSバージョン4の設計上の考慮事項」、RFC 2624、DOI 10.17487 / RFC2624、1999年6月、<http://www.rfc-editor.org/info/rfc2624>。
[RFC4120] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, DOI 10.17487/RFC4120, July 2005, <http://www.rfc-editor.org/info/rfc4120>.
[RFC4120] Neuman、C.、Yu、T.、Hartman、S。、およびK. Raeburn、「The Kerberos Network Authentication Service（V5）」、RFC 4120、DOI 10.17487 / RFC4120、2005年7月、<http：// www.rfc-editor.org/info/rfc4120>。
[RFC5531] Thurlow, R., "RPC: Remote Procedure Call Protocol Specification Version 2", RFC 5531, DOI 10.17487/RFC5531, May 2009, <http://www.rfc-editor.org/info/rfc5531>.
[RFC5531] Thurlow、R。、「RPC：Remote Procedure Call Protocol Specification Version 2」、RFC 5531、DOI 10.17487 / RFC5531、2009年5月、<http://www.rfc-editor.org/info/rfc5531>。
[RFC5716] Lentini, J., Everhart, C., Ellard, D., Tewari, R., and M. Naik, "Requirements for Federated File Systems", RFC 5716, DOI 10.17487/RFC5716, January 2010, <http://www.rfc-editor.org/info/rfc5716>.
[RFC5716] Lentini、J.、Everhart、C.、Ellard、D.、Tewari、R。、およびM. Naik、「Federated File Systems」の要件、RFC 5716、DOI 10.17487 / RFC5716、2010年1月、<http： //www.rfc-editor.org/info/rfc5716>。
[RFC7532] Lentini, J., Tewari, R., and C. Lever, Ed., "Namespace Database (NSDB) Protocol for Federated File Systems", RFC 7532, DOI 10.17487/RFC7532, March 2015, <http://www.rfc-editor.org/info/rfc7532>.
[RFC7532] Lentini、J.、Tewari、R。、およびC. Lever、編、「フェデレーテッドファイルシステムのネームスペースデータベース（NSDB）プロトコル」、RFC 7532、DOI 10.17487 / RFC7532、2015年3月、<http：// www.rfc-editor.org/info/rfc7532>。
[RFC7533] Lentini, J., Tewari, R., and C. Lever, Ed., "Administration Protocol for Federated File Systems", RFC 7533, DOI 10.17487/RFC7533, March 2015, <http://www.rfc-editor.org/info/rfc7533>.
[RFC7533] Lentini、J.、Tewari、R。、およびC. Lever、編集、「フェデレーテッドファイルシステムの管理プロトコル」、RFC 7533、DOI 10.17487 / RFC7533、2015年3月、<http：//www.rfc- editor.org/info/rfc7533>。
[SEC-ADD] Lever, C., "Federated Filesystem Security Addendum", Work in Progress, draft-cel-nfsv4-federated-fs-security-addendum-06, October 2016.
[SEC-ADD] Lever、C。、「Federated Filesystem Security Addendum」、Work in Progress、draft-cel-nfsv4-federated-fs-security-addendum-06、2016年10月。
Acknowledgments
謝辞
Andy Adamson would like to thank NetApp, Inc., for its funding of his time on this project.
Andy Adamsonは、このプロジェクトに費やしたNetApp、Inc.に感謝します。
We thank Chuck Lever, Tom Haynes, Brian Reitz, Bruce Fields, and David Noveck for their review.
Chuck Lever、Tom Haynes、Brian Reitz、Bruce Fields、David Noveckのレビューに感謝します。
Authors' Addresses
著者のアドレス
William A. (Andy) Adamson NetApp
William A.（Andy）Adamson NetApp
Email: andros@netapp.com
Nicolas Williams Cryptonector
ニコラス・ウィリアムスのクリプトネクター
Email: nico@cryptonector.com