RFC2623 日本語訳
2623 NFS Version 2 and Version 3 Security Issues and the NFSProtocol's Use of RPCSEC_GSS and Kerberos V5. M. Eisler. June 1999. (Format: TXT=42521 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Eisler Request for Comments: 2623 Sun Microsystems, Inc. Category: Standards Track June 1999
コメントを求めるワーキンググループM.アイスラー要求をネットワークでつないでください: 2623年のサン・マイクロシステムズ・インクカテゴリ: 標準化過程1999年6月
NFS Version 2 and Version 3 Security Issues and the NFS Protocol's
Use of RPCSEC_GSS and Kerberos V5
RPCSEC_GSSとケルベロスV5のNFSバージョン2、バージョン3安全保障問題、およびNFSプロトコルの使用
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
Abstract
要約
This memorandum clarifies various security issues involving the NFS protocol (Version 2 and Version 3 only) and then describes how the Version 2 and Version 3 of the NFS protocol use the RPCSEC_GSS security flavor protocol and Kerberos V5. This memorandum is provided so that people can write compatible implementations.
このメモは、NFSプロトコル(バージョン2とバージョン3専用)にかかわる様々な安全保障問題をはっきりさせて、次に、NFSプロトコルのバージョン2とバージョン3がどうRPCSEC_GSSセキュリティ風味プロトコルとケルベロスV5を使用するかを説明します。 人々がコンパチブル実装を書くことができるように、このメモを提供します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Overview of RPC Security Architecture . . . . . . . . . . . 3 2. Overview of NFS Security . . . . . . . . . . . . . . . . . . . 3 2.1. Port Monitoring . . . . . . . . . . . . . . . . . . . . . . 3 2.1.1. MOUNT Protocol . . . . . . . . . . . . . . . . . . . . . . 4 2.2. RPC Security Flavors . . . . . . . . . . . . . . . . . . . . 4 2.2.1. AUTH_SYS . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.2. AUTH_DH and AUTH_KERB4 . . . . . . . . . . . . . . . . . . 5 2.2.3. RPCSEC_GSS . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Authentication for NFS Procedures . . . . . . . . . . . . . 6 2.3.1. NULL Procedure . . . . . . . . . . . . . . . . . . . . . . 6 2.3.2. NFS Procedures Used at Mount Time . . . . . . . . . . . . 6 2.4. Binding Security Flavors to Exports . . . . . . . . . . . . 7 2.5. Anonymous Mapping . . . . . . . . . . . . . . . . . . . . . 7 2.6. Host-based Access Control . . . . . . . . . . . . . . . . . 8 2.7. Security Flavor Negotiation . . . . . . . . . . . . . . . . 8 2.8. Registering Flavors . . . . . . . . . . . . . . . . . . . . 9 3. The NFS Protocol's Use of RPCSEC_GSS . . . . . . . . . . . . 9
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 RPCセキュリティー体系. . . . . . . . . . . 3 2の概要。 NFSセキュリティ. . . . . . . . . . . . . . . . . . . 3 2.1の概要。 ポートモニターしている. . . . . . . . . . . . . . . . . . . . . . 3 2.1.1。 プロトコル. . . . . . . . . . . . . . . . . . . . . . 4 2.2を取り付けてください。 RPCセキュリティは.1に.42.2に風味を添えます。 AUTH_SYS. . . . . . . . . . . . . . . . . . . . . . . . . 5 2.2.2。 AUTH_DHとAUTH_KERB4. . . . . . . . . . . . . . . . . . 5 2.2.3。 RPCSEC_GSS. . . . . . . . . . . . . . . . . . . . . . . . 5 2.3。 NFS手順. . . . . . . . . . . . . 6 2.3.1のための認証。 ヌル手順. . . . . . . . . . . . . . . . . . . . . . 6 2.3.2。 NFS手順は山で時間. . . . . . . . . . . . 6 2.4を費やしました。 拘束力があるセキュリティは輸出. . . . . . . . . . . . 7 2.5に風味を添えます。 匿名のマッピング. . . . . . . . . . . . . . . . . . . . . 7 2.6。 ホストベースのアクセス制御. . . . . . . . . . . . . . . . . 8 2.7。 セキュリティ風味交渉. . . . . . . . . . . . . . . . 8 2.8。 風味. . . . . . . . . . . . . . . . . . . . 9 3を示します。 RPCSEC_GSS. . . . . . . . . . . . 9のNFSプロトコルの使用
Eisler Standards Track [Page 1] RFC 2623 NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999
アイスラー標準化過程[1ページ]のRFC2623NFSセキュリティ、RPCSEC_GSS、およびケルベロスV5 June 1999
3.1. Server Principal . . . . . . . . . . . . . . . . . . . . . 9
3.2. Negotiation . . . . . . . . . . . . . . . . . . . . . . . 9
3.3. Changing RPCSEC_GSS Parameters . . . . . . . . . . . . . . 10
3.4. Registering Pseudo Flavors and Mappings . . . . . . . . . 11
4. The NFS Protocol over Kerberos V5 . . . . . . . . . . . . . 11
4.1. Issues with Kerberos V5 QOPs . . . . . . . . . . . . . . . 12
4.2. The NFS Protocol over Kerberos V5 Pseudo Flavor
Registration Entry . . . . . . . . . . . . . . . . . . . . 13
5. Security Considerations . . . . . . . . . . . . . . . . . . 14
6. IANA Considerations [RFC2434] . . . . . . . . . . . . . . . 14
6.1. Pseudo Flavor Number . . . . . . . . . . . . . . . . . . . 14
6.2. String Name of Pseudo Flavor . . . . . . . . . . . . . . . 15
6.2.1. Name Space Size . . . . . . . . . . . . . . . . . . . . 15
6.2.2. Delegation . . . . . . . . . . . . . . . . . . . . . . . 15
6.2.3. Outside Review . . . . . . . . . . . . . . . . . . . . . 15
6.3. GSS-API Mechanism OID . . . . . . . . . . . . . . . . . . 15
6.4. GSS-API Mechanism Algorithm Values . . . . . . . . . . . . 15
6.5. RPCSEC_GSS Security Service . . . . . . . . . . . . . . . 16
References . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 19
3.1. サーバ主体. . . . . . . . . . . . . . . . . . . . . 9 3.2。 交渉. . . . . . . . . . . . . . . . . . . . . . . 9 3.3。 RPCSEC_GSSパラメタ. . . . . . . . . . . . . . 10 3.4を変えます。 疑似風味とマッピング. . . . . . . . . 11 4を示します。 NFSはケルベロスV5. . . . . . . . . . . . . 11 4.1の上で議定書を作ります。 ケルベロスV5 QOPs. . . . . . . . . . . . . . . 12 4.2の問題。 NFSはケルベロスV5疑似風味の上で登録エントリー. . . . . . . . . . . . . . . . . . . . 13 5について議定書の中で述べます。 セキュリティ問題. . . . . . . . . . . . . . . . . . 14 6。 IANA問題[RFC2434].146.1。 疑似風味No.. . . . . . . . . . . . . . . . . . . 14 6.2。 .1に疑似風味.156.2の名前を結んでください。 スペースサイズ. . . . . . . . . . . . . . . . . . . . 15 6.2を.2と命名してください。 委譲. . . . . . . . . . . . . . . . . . . . . . . 15 6.2.3。 外では、.156.3が論評します。 GSS-APIメカニズムOID. . . . . . . . . . . . . . . . . . 15 6.4。 GSS-APIメカニズムアルゴリズム値. . . . . . . . . . . . 15 6.5。 RPCSEC_GSSセキュリティー・サービス. . . . . . . . . . . . . . . 16参照. . . . . . . . . . . . . . . . . . . . . . . . . . . 16承認. . . . . . . . . . . . . . . . . . . . . . . . 17作者のアドレスの.18の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . 19
1. Introduction
1. 序論
The NFS protocol provides transparent remote access to shared file systems across networks. The NFS protocol is designed to be machine, operating system, network architecture, and security mechanism, and transport protocol independent. This independence is achieved through the use of ONC Remote Procedure Call (RPC) primitives built on top of an eXternal Data Representation (XDR). NFS protocol Version 2 is specified in the Network File System Protocol Specification [RFC1094]. A description of the initial implementation can be found in [Sandberg]. NFS protocol Version 3 is specified in the NFS Version 3 Protocol Specification [RFC1813]. A description of some initial implementations can be found in [Pawlowski].
NFSプロトコルはネットワークの向こう側に見え透いた遠隔アクセスを共有ファイルシステムに供給します。 NFSプロトコルは、マシンと、オペレーティングシステムと、ネットワークアーキテクチャと、セキュリティー対策と、トランスポート・プロトコル独立者になるように設計されています。 この独立はeXternal Data Representation(XDR)の上で築き上げられたONC Remote Procedure Call(RPC)基関数の使用で達成されます。 NFSプロトコルバージョン2はネットワークファイルシステムプロトコルSpecification[RFC1094]で指定されます。 [サンドベルイ]で初期の実装の記述を見つけることができます。 NFSプロトコルバージョン3はNFSバージョン3プロトコルSpecification[RFC1813]で指定されます。 [ポロウスキー]でいくつかの初期の実装の記述を見つけることができます。
For the remainder of this document, whenever it refers to the NFS protocol, it means NFS Version 2 and Version 3, unless otherwise stated.
このドキュメントの残りのために、NFSプロトコルを示すときはいつも、NFSバージョン2とバージョン3を意味します、別の方法で述べられない場合。
The RPC protocol is specified in the Remote Procedure Call Protocol Specification Version 2 [RFC1831]. The XDR protocol is specified in External Data Representation Standard [RFC1832].
RPCプロトコルはRemote Procedure CallプロトコルSpecificationバージョン2[RFC1831]で指定されます。 XDRプロトコルはExternal Data Representation Standard[RFC1832]で指定されます。
A new RPC security flavor, RPCSEC_GSS, has been specified [RFC2203]. This new flavor allows application protocols built on top of RPC to access security mechanisms that adhere to the GSS-API specification
新しいRPCセキュリティ風味(RPCSEC_GSS)は指定されました[RFC2203]。 この新しい風味で、RPCの上で築き上げられたアプリケーション・プロトコルはGSS-API仕様を固く守るセキュリティー対策にアクセスできます。
Eisler Standards Track [Page 2] RFC 2623 NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999
アイスラー標準化過程[2ページ]のRFC2623NFSセキュリティ、RPCSEC_GSS、およびケルベロスV5 June 1999
[RFC2078].
[RFC2078。]
The purpose of this document is to clarify NFS security issues and to specify how the NFS protocol uses RPCSEC_GSS. This document will also describe how NFS works over Kerberos V5, via RPCSEC_GSS.
このドキュメントの目的は、NFS安全保障問題をはっきりさせて、NFSプロトコルがどうRPCSEC_GSSを使用するかを指定することです。 また、このドキュメントはNFSがRPCSEC_GSSを通してケルベロスV5の上でどう働いているかを説明するでしょう。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
1.1. Overview of RPC Security Architecture
1.1. RPCセキュリティー体系の概要
The RPC protocol includes a slot for security parameters (referred to as an authentication flavor in the RPC specification [RFC1831]) on every call. The contents of the security parameters are determined by the type of authentication used by the server and client. A server may support several different flavors of authentication at once. Some of the better known flavors are summarized as follows:
RPCプロトコルはあらゆる呼び出しのときにセキュリティパラメタのためのスロットを含んでいます(RPC仕様[RFC1831]に認証特色と呼ばれます)。 セキュリティパラメタの内容はサーバとクライアントによって使用された認証のタイプによって決定されます。 サーバはすぐに、認証のいくつかの異なった風味をサポートするかもしれません。 よりよく知られている風味のいくつかが以下の通りまとめられます:
* The AUTH_NONE flavor provides null authentication, that is, no
authentication information is passed.
* AUTH_NONE風味はヌル認証を提供します、すなわち、認証情報が全く通過されません。
* The AUTH_SYS flavor provides a UNIX-style user identifier, group
identifier, and an array of supplemental group identifiers with
each call.
* AUTH_SYS風味は補足のグループ識別子のUNIX-スタイルユーザ識別子、グループ識別子、および勢ぞろいを各呼び出しに提供します。
* The AUTH_DH (sometimes referred to as AUTH_DES [RFC1057]) flavor
provides DES-encrypted authentication parameters based on a
network-wide string name, with session keys exchanged via the
Diffie-Hellman public key scheme.
* AUTH_DH(時々AUTH_DES[RFC1057]と呼ばれる)風味はネットワーク全体のストリング名に基づくDES-暗号化認証パラメタを提供します、ディフィー-ヘルマン公開鍵体系でセッションキーを交換している状態で。
* The AUTH_KERB4 flavor provides DES encrypted authentication
parameters based on a network-wide string name (the name is a
Kerberos Version 4 principal identifier) with session keys
exchanged via Kerberos Version 4 secret keys.
* AUTH_KERB4風味はネットワーク全体のストリング名に基づいている(名前はケルベロスのバージョンの4の主要な識別子である)ケルベロスバージョンで交換しているセッションキーで4個の秘密鍵をDES暗号化認証パラメタに提供します。
The NFS protocol is not limited to the above list of security flavors.
NFSプロトコルはセキュリティ風味の上記のリストに制限されません。
2. Overview of NFS Security
2. NFSセキュリティの概要
2.1. Port Monitoring
2.1. ポートモニター
Many NFS servers will require that the client send its NFS requests from UDP or TCP source ports with values < 1024. The theory is that binding to ports < 1024 is a privileged operation on the client, and so the client is enforcing file access permissions on its end. The theory breaks down because:
多くのNFSサーバが、クライアントが値<1024があるUDPかTCPソースポートからNFS要求を送るのを必要とするでしょう。 理論はクライアントがポートに付いて、<1024がクライアントにおける特権がある操作であるので終わりでファイルアクセス許容を実施しているということです。 理論が崩壊する、:
Eisler Standards Track [Page 3] RFC 2623 NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999
アイスラー標準化過程[3ページ]のRFC2623NFSセキュリティ、RPCSEC_GSS、およびケルベロスV5 June 1999
* On many operating systems, there are no constraints on what port
what user can bind to.
* 多くのオペレーティングシステムには、ユーザが付くことができるものを移植することには規制が全くありません。
* Just because the client host enforces the privilege on binding
to ports < 1024 does not necessarily mean that a non-privileged
user cannot gain access to the port binding privilege. For
example with a single-user desk-top host running a UNIX
operating system, the user may have knowledge of the root user
password. And even if he does not have that knowledge, with
physical access to the desk-top machine, root privileges are
trivially acquired.
* ただクライアントホストが特権にポートに付くのに押しつけるので、<1024は、必ず非特権ユーザが特権を縛るポートへのアクセスを得ることができないことを意味するというわけではありません。 例えば、シングルユーザーの卓上のホストがUnixオペレーティングシステムを実行している状態で、ユーザには、根のユーザパスワードに関する知識があるかもしれません。 そして、彼にその知識がなくても、卓上のマシンへの物理的なアクセスで、根の特権を些細なことに取得します。
In some rare cases, when the system administrator can be certain that the clients are trusted and under control (in particular, protected from physical attack), relying of trusted ports MAY be a reliable form of security.
信じられたポートの信用はシステム管理者がクライアントが信じられるのを確信している場合があるときのいくつかのまれなケースと手中(物理的であるのから保護されて、特に、攻撃する)、信頼できるフォームのセキュリティであるかもしれません。
In most cases, the use of privileged ports and port monitoring for security is at best an inconvenience to the attacker and SHOULD NOT be depended on.
多くの場合、特権があるポートとセキュリティのためにモニターされるポートの使用はせいぜい不便です。攻撃者とSHOULD NOTに頼っています。
To maximize interoperability:
相互運用性を最大にするために:
* NFS clients SHOULD attempt to bind to ports < 1024. In some
cases, if they fail to bind (because either the user does not
have the privilege to do so, or there is no free port < 1024),
the NFS client MAY wish to attempt the NFS operation over a port
>= 1024.
* NFSクライアントSHOULDは、ポート<1024に付くのを試みます。 いくつかの場合、彼らが付かないなら(ユーザにはそうする特権がないか、またはどんな自由なポート<も1024ないので)、NFSクライアントはポート>の上のNFS操作=1024を試みたがっているかもしれません。
* NFS servers that implement port monitoring SHOULD provide a
method to turn it off.
* ポートがモニターしているSHOULDであると実装するNFSサーバがそれをオフにするメソッドを提供します。
* Whether port monitoring is enabled or not, NFS servers SHOULD
NOT reject NFS requests to the NULL procedure (procedure number
0). See subsection 2.3.1, "NULL procedure" for a complete
explanation.
* ポートモニターが可能にされるか否かに関係なく、NFSサーバSHOULD NOTはNULL手順(手順No.0)にNFS要求を拒絶します。 完璧な説明に関して小区分2.3.1、「NULL手順」を見てください。
2.1.1. MOUNT Protocol
2.1.1. マウントプロトコル
The port monitoring issues and recommendations apply to the MOUNT protocol as well.
モニターしている問題と推薦がまた、山のプロトコルに当てはまるポート。
2.2. RPC Security Flavors
2.2. RPCセキュリティ風味
The NFS server checks permissions by taking the credentials from the RPC security information in each remote request. Each flavor packages credentials differently.
NFSサーバは、それぞれのリモート要求でRPCセキュリティ情報から資格証明書を取ることによって、許容をチェックします。 各風味は資格証明書を異なってパッケージします。
Eisler Standards Track [Page 4] RFC 2623 NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999
アイスラー標準化過程[4ページ]のRFC2623NFSセキュリティ、RPCSEC_GSS、およびケルベロスV5 June 1999
2.2.1. AUTH_SYS
2.2.1. AUTH_SYS
Using the AUTH_SYS flavor of authentication, the server gets the client's effective user identifier, effective group identifier and supplemental group identifiers on each call, and uses them to check access. Using user identifiers and group identifiers implies that the client and server either share the same identifier name space or do local user and group identifier mapping.
認証のAUTH_SYS風味を使用して、サーバは、各呼び出しに関するクライアントの実効ユーザー識別子、有効なグループ識別子、および補足のグループ識別子を得て、アクセサリーをチェックするのにそれらを使用します。 ユーザ識別子とグループ識別子を使用するのは、クライアントとサーバが同じ識別子名前スペースを共有するか、または地元のユーザとグループ識別子マッピングをするのを含意します。
For those sites that do not implement a consistent user identifier and group identifier space, NFS implementations must agree on the mapping of user and group identifiers between NFS clients and servers.
一貫したユーザ識別子とグループ識別子がスペースであると実装しないそれらのサイトに、NFS実装はNFSクライアントとサーバの間のユーザとグループ識別子に関するマッピングに同意しなければなりません。
2.2.2. AUTH_DH and AUTH_KERB4
2.2.2. AUTH_DHとAUTH_KERB4
The AUTH_DH and AUTH_KERB4 styles of security are based on a network-wide name. They provide greater security through the use of DES encryption and public keys in the case of AUTH_DH, and DES encryption and Kerberos secret keys (and tickets) in the AUTH_KERB4 case. Again, the server and client must agree on the identity of a particular name on the network, but the name to identity mapping is more operating system independent than the user identifier and group identifier mapping in AUTH_SYS. Also, because the authentication parameters are encrypted, a malicious user must know another user's network password or private key to masquerade as that user. Similarly, the server returns a verifier that is also encrypted so that masquerading as a server requires knowing a network password.
セキュリティのAUTH_DHとAUTH_KERB4スタイルはネットワーク全体の名前に基づいています。 彼らはDES暗号化の使用とAUTH_DHに関するケース、DES暗号化、およびケルベロス秘密鍵(そして、チケット)の公開鍵を通してAUTH_KERB4ケースによりすばらしいセキュリティを供給します。 一方、サーバとクライアントがネットワークで特定の名前のアイデンティティに同意しなければなりませんが、アイデンティティマッピングへの名前はAUTHで_SYSを写像するユーザ識別子とグループ識別子よりオペレーティングシステム独立者です。 また、認証パラメタが暗号化されているので、悪意あるユーザーはそのユーザのふりをするために別のユーザのネットワークパスワードか秘密鍵を知らなければなりません。 同様に、サーバはまた、サーバのふりをするのが、ネットワークパスワードを知るのを必要とするように暗号化される検証を返します。
2.2.3. RPCSEC_GSS
2.2.3. RPCSEC_GSS
The RPCSEC_GSS style of security is based on a security-mechanism- specific principal name. GSS-API mechanisms provide security through the use of cryptography. The cryptographic protections are used in the construction of the credential on calls, and in the verifiers on replies. Optionally, cryptographic protections will be in the body of the calls and replies.
セキュリティのRPCSEC_GSSスタイルはセキュリティメカニズム特有の主要な名前に基づいています。 GSS-APIメカニズムは暗号の使用でセキュリティを提供します。 暗号の保護は呼び出しの資格証明書の工事、および回答での検証で使用されます。 任意に、暗号の保護が呼び出しと回答のボディーにあるでしょう。
Note that the discussion of AUTH_NONE, AUTH_SYS, AUTH_DH, AUTH_KERB4, and RPCSEC_GSS does not imply that the NFS protocol is limited to using those five flavors.
AUTH_NONE、AUTH_SYS、AUTH_DH、AUTH_KERB4、およびRPCSEC_GSSの議論が、NFSプロトコルがそれらの5つの風味を使用するのに制限されるのを含意しないことに注意してください。
Eisler Standards Track [Page 5] RFC 2623 NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999
アイスラー標準化過程[5ページ]のRFC2623NFSセキュリティ、RPCSEC_GSS、およびケルベロスV5 June 1999
2.3. Authentication for NFS Procedures
2.3. NFS手順のための認証
2.3.1. NULL Procedure
2.3.1. ヌル手順
The NULL procedure is typically used by NFS clients to determine if an NFS server is operating and responding to requests (in other words, to "ping" the NFS server). Some NFS servers require that a client using the NULL procedure:
NULL手順は、NFSサーバが要求(言い換えれば、NFSサーバを「確認する」)に作動と応じることであるかどうか決定するのにNFSクライアントによって通常用いられます。 いくつかのNFSサーバがNULL手順を用いることでそのaクライアントを必要とします:
* send the request from TCP or UDP port < 1024. There does not
seem to be any value in this because the NULL procedure is of
very low overhead and certainly no more overhead than the cost
of processing a NULL procedure and returning an authentication
error. Moreover, by sending back an authentication error, the
server has confirmed the information that the client was
interested in: is the server operating?
* TCPから要求を送ってください。さもないと、UDPは<1024を移植します。 NULL手順が非常に低いオーバーヘッドと確かにNULL手順を処理して、認証誤りを返す費用がオーバーヘッドでないことのようなどんなオーバーヘッドのものでないのでも、少しの値もこれであるように思えません。 そのうえ、認証誤りを返送することによって、サーバはクライアントが以下に興味を持っていたという情報を確認しました。 サーバは作動していますか?
* be authenticated with a flavor stronger than AUTH_SYS. This is a
problem because the RPCSEC_GSS protocol uses NULL for control
messages.
* 風味がAUTH_SYSより強い状態で認証されてください。 RPCSEC_GSSプロトコルがコントロールメッセージにNULLを使用するので、これは問題です。
NFS servers SHOULD:
NFSサーバSHOULD:
* accept the NULL procedure ping over AUTH_NONE and AUTH_SYS, in
addition to other RPC security flavors, and
* そして他のRPCセキュリティ風味に加えてAUTH_NONEとAUTH_SYSの上にNULL手順ピングを受け入れてください。
* NOT require that the source port be < 1024 on a NULL procedure
ping.
* NOTは、ソースポートがNULL手順ピングに関する<1024であることを必要とします。
2.3.2. NFS Procedures Used at Mount Time
2.3.2. 山のTimeのときに用いられたNFS手順
Certain NFS procedures are used at the time the NFS client mounts a file system from the server. Some NFS server implementations will not require authentication for these NFS procedures. For NFS protocol Version 2, these procedures are GETATTR and STATFS. For Version 3, the procedure is FSINFO.
NFSクライアントがサーバからファイルシステムを取り付けるとき、あるNFS手順は使用されています。いくつかのNFSサーバ実装はこれらのNFS手順のための認証を必要としないでしょう。 NFSプロトコルバージョン2のために、これらの手順は、GETATTRとSTATFSです。 バージョン3のために、手順はFSINFOです。
The reason for not requiring authentication is described as follows. When the NFS client mounts a NFS server's file system, the identity of the caller on the client is typically an administrative entity (in UNIX operating systems, this is usually the "root" user). It is often the case that, for unattended operation in concert with an automounter [Callaghan], the AUTH_DH, AUTH_KERB4, or RPCSEC_GSS credentials for the administrative entity associated with an automounter are not available. If so, the NFS client will use AUTH_NONE or AUTH_SYS for the initial NFS operations used to mount a file system. While an attacker could exploit this implementation artifact, the exposure is limited to gaining the attributes of a file
認証を必要としない理由は以下の通り説明されます。 NFSクライアントがNFSサーバのファイルシステムを取り付けるとき、通常、クライアントの上の訪問者のアイデンティティは管理実体(Unixオペレーティングシステムでは、通常、これは「根」ユーザである)です。 しばしば、オートマウンタ[キャラハン]と協力して無人の操作に、オートマウンタに関連している管理実体のためのAUTH_DH、AUTH_KERB4、またはRPCSEC_GSS資格証明書が利用可能ではありません。 そうだとすれば、NFSクライアントはファイルシステムを取り付けるのに使用される初期のNFS操作にAUTH_NONEかAUTH_SYSを使用するでしょう。 攻撃者がこの実装人工物を利用できた間、暴露はファイルの属性を獲得するのに制限されます。
Eisler Standards Track [Page 6] RFC 2623 NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999
アイスラー標準化過程[6ページ]のRFC2623NFSセキュリティ、RPCSEC_GSS、およびケルベロスV5 June 1999
or a file system's characteristics. This OPTIONAL trade off favors the opportunity for improved ease of use.
または、ファイルシステムの特性。 このOPTIONALは好意で改良された使いやすさの機会を取り引きします。
2.4. Binding Security Flavors to Exports
2.4. 輸出への拘束力があるセキュリティ風味
NFS servers MAY export file systems with specific security flavors bound to the export. In the event a client uses a security flavor that is not the one of the flavors the file system was exported with, NFS server implementations MAY:
NFSサーバは輸出に縛られた特定のセキュリティ風味と共にファイルシステムをエクスポートするかもしれません。 イベントでは、クライアントはファイルシステムがエクスポートされた風味の1つでないセキュリティ風味を使用します、サーバ実装がそうするNFS:
* reject the request with an error (either an NFS error or an RPC
level authentication error), or
* または誤り(NFS誤りかRPCの平らな認証誤りのどちらか)で要求を拒絶してください。
* allow the request, but map the user's credentials to a user
other than the one the client intended. Typically the user that
is the result of this mapping is a user with limited access on
the system, such as user "nobody" on UNIX systems.
* 要求を許しなさい、ただし、クライアントが意図したもの以外のユーザにユーザの資格証明書を写像してください。 このマッピングの結果であるユーザは通常、システムの上に限られたアクセスがあるユーザです、UNIXシステムの上のユーザ「一人も」などのように。
If a client uses AUTH_NONE, the server's options are the same as the above, except that AUTH_NONE carries with it no user identity. In order to allow the request, on many operating systems the server will assign a user identity. Typically this assignment will be a user with limited access on the system, such as user "nobody" on UNIX systems.
クライアントがAUTH_NONEを使用するなら、サーバのオプションは上記で同じです、AUTH_NONEがそれと共にユーザアイデンティティを全く運ばないのを除いて。 要求を許すために、多くのオペレーティングシステムに、サーバはユーザアイデンティティを割り当てるでしょう。 システムの上にUNIXシステムの上のユーザ「一人も」などの限られたアクセスがある状態で、この課題は通常、ユーザになるでしょう。
2.5. Anonymous Mapping
2.5. 匿名のマッピング
The following passage is excerpted verbatim from RFC 1813, section 4.4 "Permission Issues" (except that "may" has been changed to "MAY"):
以下の節はRFC1813から逐語的に抜粋されます、「許可問題」というセクション4.4(“may"が「5月」に変わったのを除いて):
In most operating systems, a particular user (on UNIX, the uid 0)
has access to all files, no matter what permission and ownership
they have. This superuser permission MAY not be allowed on the
server, since anyone who can become superuser on their client
could gain access to all remote files. A UNIX server by default
maps uid 0 to a distinguished value (UID_NOBODY), as well as
mapping the groups list, before doing its access checking. A
server implementation MAY provide a mechanism to change this
mapping. This works except for NFS version 3 protocol root file
systems (required for diskless NFS version 3 protocol client
support), where superuser access cannot be avoided. Export
options are used, on the server, to restrict the set of clients
allowed superuser access.
ほとんどのオペレーティングシステムで、特定のユーザ(UNIXの上でuid0)はすべてのファイルに近づく手段を持っています、それらにどんな許可と所有権があっても。 この「スーパー-ユーザ」許可はサーバで許されないかもしれません、彼らのクライアントで「スーパー-ユーザ」になることができるだれでもすべてのリモートファイルへのアクセスを得ることができたので。 Unixサーバーはデフォルトでグループがリストアップする顕著な値(UID_NOBODY)、およびマッピングにuid0を写像します、アクセスの照合をする前に。 サーバ実装は、このマッピングを変えるためにメカニズムを提供するかもしれません。 NFSバージョン3プロトコルルートファイルシステム(ディスクレスNFSバージョン3プロトコルクライアントサポートのために、必要である)を除いて、これは働いています。そこでは、「スーパー-ユーザ」アクセスを避けることができません。 輸出オプションは、「スーパー-ユーザ」アクセサリーが許容されたクライアントのセットを制限するのにサーバで使用されます。
The issues identified as applying to NFS protocol Version 3 in the above passage also apply to Version 2.
また、上の通路のNFSプロトコルバージョン3に適用するとして特定された問題はバージョン2に適用されます。
Eisler Standards Track [Page 7] RFC 2623 NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999
アイスラー標準化過程[7ページ]のRFC2623NFSセキュリティ、RPCSEC_GSS、およびケルベロスV5 June 1999
2.6. Host-based Access Control
2.6. ホストベースのアクセスコントロール
In some NFS server implementations, a host-based access control method is used whereby file systems can be exported to lists of clients. File systems may also be exported for read-only or read- write access. Several of these implementations will check access only at mount time, during the request for the file handle via the MOUNT protocol handshake. The lack of authorization checking during subsequent NFS requests has the following consequences:
いくつかのNFSサーバ実装、クライアントのリストにファイルシステムをエクスポートすることができる使用されるホストベースのアクセス制御メソッドで。 また、ファイルシステムが書き込み禁止のためにエクスポートされるかもしれませんか、または読まれて、アクセサリーを書いてください。 これらのいくつかの実装が単にマウント時にアクセスをチェックするでしょう、山のプロトコル握手を通したファイルハンドルを求める要求の間。 その後のNFS要求の間の許可検査の不足に、以下の結果があります:
* NFS servers are not able to repudiate access to the file system
by an NFS client after the client has mounted the file system.
* クライアントがファイルシステムを取り付けた後にNFSサーバはNFSクライアントでファイルシステムへのアクセスを否認できません。
* An attacker can circumvent the MOUNT server's access control to
gain access to a file system that the attacker is not authorized
for. The circumvention is accomplished by either stealing a file
handle (usually by snooping the network traffic between an
legitimate client and server) or guessing a file handle. For
this attack to succeed, the attacker must still be able
impersonate a user's credentials, which is simple for AUTH_SYS,
but harder for AUTH_DH, AUTH_KERB4, and RPCSEC_GSS.
* 攻撃者は、攻撃者が権限を与えられないファイルシステムへのアクセスを得るために山のサーバのアクセス制御を回避できます。 欺くことは、ファイルハンドル(通常、正統のクライアントとサーバの間のネットワークトラフィックについて詮索するのによる)を横取りするか、またはファイルハンドルを推測することによって、達成されます。 この攻撃が成功するように、攻撃者はそうしなければなりません、それでも、できてください。ユーザの資格証明書をまねてください。(AUTH_SYSに簡単ですが、AUTH_DH、AUTH_KERB4、およびRPCSEC_GSSには、資格証明書は、より困難です)。
* WebNFS clients that use the public file handle lookup [RFC2054]
will not go through the MOUNT protocol to acquire initial file
handle of the NFS file system. Enforcing access control via the
MOUNT protocol is going to be a little use. Granted, some WebNFS
server implementations cope with this by limiting the use of the
public file handle to file systems exported to every client on
the Internet.
* 公共のファイルハンドルルックアップ[RFC2054]を使用するWebNFSクライアントは、NFSファイルシステムの初期のファイルハンドルを入手するために山のプロトコルに直面しないでしょう。 山のプロトコルでアクセスコントロールを実施するのは少しの使用になるでしょう。 与えて、いくつかのWebNFSサーバ実装が、インターネットのすべてのクライアントにエクスポートされたシステムをファイルするために公共のファイルハンドルの使用を制限することによって、これを切り抜けます。
Thus, NFS server implementations SHOULD check the client's authorization on each NFS request.
したがって、NFSサーバ実装SHOULDはそれぞれのNFS要求のときにクライアントの承認をチェックします。
2.7. Security Flavor Negotiation
2.7. セキュリティ風味交渉
Any application protocol that supports multiple styles of security will have the issue of negotiating the security method to be used. NFS Version 2 had no support for security flavor negotiation. It was up to the client to guess, or depend on prior knowledge. Often the prior knowledge would be available in the form of security options specified in a directory service used for the purpose of automounting.
複数のスタイルのセキュリティをサポートするどんなアプリケーション・プロトコルも使用されるべきセキュリティメソッドを交渉する問題を持つでしょう。 NFSバージョン2には、セキュリティ風味交渉のサポートが全くありませんでした。 先の知識に推測するか、またはよるのが、クライアント次第でした。 しばしば、先の知識はautomountingする目的に使用されるディレクトリサービスで指定されたセキュリティオプションの形で利用可能でしょう。
The MOUNT Version 3 protocol, associated with NFS Version 3, solves the problem by having the response to the MNT procedure include a list of flavors in the MNT procedure. Note that because some NFS servers will export file systems to specific lists of clients, with different access (read-only versus read-write), and with different
MNT手順への応答にMNT手順に風味のリストを含ませることによって、NFSバージョン3に関連している山のVersion3プロトコルは問題を解決します。 いくつかのNFSサーバがクライアント、異なったアクセス(書き込み禁止対読書して書く)、異なることで特定のリストへのファイルシステムをエクスポートするので、それに注意してください。
Eisler Standards Track [Page 8] RFC 2623 NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999
アイスラー標準化過程[8ページ]のRFC2623NFSセキュリティ、RPCSEC_GSS、およびケルベロスV5 June 1999
security flavors, it is possible a client might get back multiple security flavors in the list returned in the MNT response. The use of one flavor instead of another might imply read-only instead of read- write access, or perhaps some other degradation of access. For this reason, a NFS client SHOULD use the first flavor in the list that it supports, on the assumption that the best access is provided by the first flavor. NFS servers that support the ability to export file systems with multiple security flavors SHOULD either present the best accessing flavor first to the client, or leave the order under the control of the system administrator.
セキュリティ風味、クライアントがMNT応答で返されたリストの複数のセキュリティ風味を取り戻すのは、可能です。 別のものの代わりにある風味の使用は、読書の代わりに書き込み禁止がアクセス、または恐らくアクセサリーのある他の退行を書くのを含意するかもしれません。 この理由、NFSクライアントSHOULDがそれが最初の風味で最も良いアクセスを提供するという前提でサポートするリストにおける最初の風味を使用するので。 複数のセキュリティ風味があるファイルシステムがSHOULDであるとエクスポートする能力をサポートするNFSサーバが、風味にアクセスするベストを最初に、クライアントに提示するか、またはシステム管理者のコントロールの下にオーダーを残します。
2.8. Registering Flavors
2.8. 風味を示します。
When one develops a new RPC security flavor, iana@iana.org MUST be contacted to get a unique flavor assignment. To simplify NFS client and server administration, having a simple ASCII string name for the flavor is useful. Currently, the following assignments exist:
人が新しいRPCセキュリティ風味を開発するとき、独特の味課題を得るために iana@iana.org に連絡しなければなりません。 NFSクライアントとサーバ管理を簡素化するために、風味のための簡単なASCIIストリング名を持っているのは役に立ちます。 現在、以下の課題は存在します:
flavor string name
風味ストリング名
AUTH_NONE none
AUTH_SYS sys
AUTH_DH dh
AUTH_KERB4 krb4
AUTH_NONE、なにも、AUTH_SYS sys AUTH_DH dh AUTH_KERB4 krb4
A string name for a new flavor SHOULD be assigned. String name assignments can be registered by contacting iana@iana.org.
五弦はSHOULDを新しい風味にちなんで命名します。割り当てられます。 iana@iana.org に連絡することによって、ストリング名前課題を登録できます。
3. The NFS Protocol's Use of RPCSEC_GSS
3. RPCSEC_GSSのNFSプロトコルの使用
3.1. Server Principal
3.1. サーバ主体
When using RPCSEC_GSS, the NFS server MUST identify itself in GSS-API via a GSS_C_NT_HOSTBASED_SERVICE name type. GSS_C_NT_HOSTBASED_SERVICE names are of the form:
RPCSEC_GSSを使用するとき、NFSサーバはGSS-APIでGSS_C_NT_HOSTBASED_SERVICE名前タイプでそれ自体を特定しなければなりません。 GSS_C_NT_HOSTBASED_SERVICE名はフォームのものです:
service@hostname
service@hostname
For NFS, the "service" element is
NFSに関しては、「サービス」要素はそうです。
nfs
nfs
3.2. Negotiation
3.2. 交渉
RPCSEC_GSS is a single security flavor over which different security mechanisms can be multiplexed. Within a mechanism, GSS-API provides for the support of multiple quality of protections (QOPs), which are pairs of cryptographic algorithms. Each algorithm in the QOP consists
RPCSEC_GSSは異なったセキュリティー対策を多重送信できるただ一つのセキュリティ風味です。 メカニズムの中では、GSS-APIは保護(QOPs)の複数の品質のサポートに備えます。保護は組の暗号アルゴリズムです。QOPの各アルゴリズムは成ります。
Eisler Standards Track [Page 9] RFC 2623 NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999
アイスラー標準化過程[9ページ]のRFC2623NFSセキュリティ、RPCSEC_GSS、およびケルベロスV5 June 1999
of an encryption algorithm for privacy and a checksum algorithm for integrity. RPCSEC_GSS lets one protect the RPC request/response pair with plain header authentication, message integrity, and message privacy. Thus RPCSEC_GSS effectively supports M * Q * 3 different styles of security, where M is the number of mechanisms supported, Q is the average number of QOPs supported for each mechanism, and 3 enumerates authentication, integrity, and privacy.
プライバシーのための暗号化アルゴリズムと保全のためのチェックサムアルゴリズムについて。 RPCSEC_GSSは1つに明瞭なヘッダー認証、メッセージの保全、およびメッセージプライバシーでRPC要求/応答組を保護させます。 したがって、事実上、RPCSEC_GSSは、M*Q*が3つの異なったスタイルのセキュリティであるとサポートします、Mがサポートされたメカニズムの数であり、Qが各メカニズムのためにサポートされたQOPsの平均した数であり、3が認証、保全、およびプライバシーを列挙するところで。
Because RPCSEC_GSS encodes many styles of security, just adding RPCSEC_GSS to the list of flavors returned in MOUNT Version 3's MNT response is not going to be of much use to the NFS client.
RPCSEC_GSSが多くのスタイルのセキュリティをコード化するので、ただ山のVersion3のMNT応答で返された風味のリストにRPCSEC_GSSを追加するのはNFSクライアントの多く役に立ちません。
The solution is the creation of a concept called "pseudo flavors." Pseudo flavors are 32 bit integers that are allocated out of the same number space as regular RPC security flavors like AUTH_NONE, AUTH_SYS, AUTH_DH, AUTH_KERB4, and RPCSEC_GSS. The idea is that each pseudo flavor will map to a specific triple of security mechanism, quality of protection, and service. The service will be one of authentication, integrity, and privacy. Note that integrity includes authentication, and privacy includes integrity. RPCSEC_GSS uses constants named rpc_gss_svc_none, rpc_gss_svc_integrity, and rpc_gss_svc_privacy, for authentication, integrity, and privacy respectively.
ソリューションは「疑似風味」と呼ばれる概念の作成です。 疑似風味はAUTH_NONE、AUTH_SYS、AUTH_DH、AUTH_KERB4、およびRPCSEC_GSSのような通常のRPCセキュリティ風味と同じ数のスペースから割り当てられる32ビットの整数です。 考えはそれぞれの疑似風味にセキュリティー対策の特定の三重に写像されるということです、保護、およびサービスでは、上質です。 サービスは1であるために認証、保全、およびプライバシーを望んでいます。 保全が認証を含んでいることに注意してください。そうすれば、プライバシーは保全を含んでいます。 定数が命名したRPCSEC_GSS用途は、認証、保全、およびプライバシーのためにそれぞれ_なにもに_gss_svcをrpcして、_gss_svc_保全をrpcして、_gss_svc_プライバシーをrpcします。
Thus, instead of returning RPCSEC_GSS, a MOUNT Version 3 server will instead return one or more pseudo flavors if the NFS server supports RPCSEC_GSS and if the file system has been exported with one or more <mechanism, QOP, service> triples. See section 4, "The NFS Protocol over Kerberos V5" for an example of pseudo flavor to triple mapping.
したがって、NFSサーバが、RPCSEC_がGSSであることをサポートして、ファイルシステムが1つ以上の<メカニズムでエクスポートされたなら、RPCSEC_GSSを返すことの代わりに山のVersion3サーバは代わりに1つ以上の疑似風味を返すでしょう、QOP、サービス>三重。 セクション4は、「疑似風味に関する例がマッピングを3倍にするように、NFSはケルベロスV5"の上で議定書を作ります。」と見ます。
3.3. Changing RPCSEC_GSS Parameters
3.3. RPCSEC_GSSパラメタを変えます。
Once an RPCSEC_GSS session or context has been set up (via the RPCSEC_GSS_INIT and RPCSEC_GSS_CONTINUE_INIT control procedures of RPCSEC_GSS), the NFS server MAY lock the <mechanism, QOP, service> triple for the duration of the session. While RPCSEC_GSS allows for the use of different QOPs and services on each message, it would be expensive for the NFS server to re-consult its table of exported file systems to see if the triple was allowed. Moreover, by the time the NFS server's dispatch routine was reached, the typical RPC subsystem would already have performed the appropriate GSS-API operation, GSS_VerifyMIC() or GSS_Unwrap(), if the respective integrity or privacy services were selected. If the file system being accessed were not exported with integrity or privacy, or with the particular QOP used to perform the integrity or privacy service, then it would be possible to execute a denial of service attack, whereby the objective of the caller is to deny CPU service to legitimate users of the NFS server's machine processors.
RPCSEC_GSSセッションか文脈がいったんセットアップされると(RPCSECを通して、_GSS_INITとRPCSEC_GSS_CONTINUE_INITはRPCSEC_GSSの手順を制御します)、NFSサーバは<メカニズムをロックするかもしれません、QOP、セッションの持続時間のためのサービス>三重。 RPCSEC_GSSが各メッセージで異なったQOPsとサービスの使用を考慮する間、NFSサーバが三重が許容されたかどうか確認するためにエクスポートしているファイルシステムのテーブルに再相談するのは、高価でしょう。 そのうえ、NFSサーバの発信ルーチンに達する時までに典型的なRPCサブシステムは既に適切なGSS-API操作、GSS_VerifyMIC()またはGSS_Unwrap()を実行したでしょう、それぞれの保全かプライバシーサービスが選択されたなら。 保全かプライバシーか特定のQOPが使用されている状態でアクセスされるファイルシステムが保全かプライバシーサービスを実行するためにエクスポートされないなら、サービス不能攻撃を実行するのは可能でしょうに。(訪問者の目的はサービス不能攻撃でNFSサーバのマシンプロセッサの正統のユーザに対するCPUサービスを否定することです)。
Eisler Standards Track [Page 10] RFC 2623 NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999
アイスラー標準化過程[10ページ]のRFC2623NFSセキュリティ、RPCSEC_GSS、およびケルベロスV5 June 1999
Thus, in general, clients SHOULD NOT assume that they will be permitted to alter the <mechanism, QOP, service> triple once the data exchange phase of RPCSEC_GSS has started.
このようにして、そして、一般に、クライアントSHOULD NOTは彼らが<メカニズム、QOPを変更することが許可されて、サービス>がかつてのGSSが始動したRPCSEC_のデータ交換フェーズの3倍であると仮定します。
3.4. Registering Pseudo Flavors and Mappings
3.4. 疑似風味とマッピングを示します。
Pseudo flavor numbers MUST be registered via same method as regular RPC security flavor numbers via iana@iana.org.
iana@iana.org を通して通常のRPCセキュリティ風味番号と同じメソッドで疑似風味番号を示さなければなりません。
Once the pseudo flavor number has been assigned, registrants SHOULD register the mapping with iana@iana.org. The mapping registration MUST contain:
疑似風味番号がいったん割り当てられると、記入者SHOULDは iana@iana.org にマッピングを登録します。 マッピング登録は以下を含まなければなりません。
* the pseudo flavor number, an ASCII string name for the flavor
(for example "none" has been assigned for AUTH_NONE), and
* そして疑似風味番号、風味(AUTH_NONEのために例えば、「なにも」を割り当ててある)のためのASCIIストリング名。
* the <mechanism, algorithm(s), service> triple. As per the GSS-
API specification, the mechanism MUST be identified with a
unique ISO object identifier (OID). The reason why the second
component of the triple is not necessarily a QOP value is that
GSS-API allows mechanisms much latitude in the mapping of the
algorithm used in the default quality of protection (See
subsection 4.1, "Issues with Kerberos V5 QOPs," for a detailed
discussion). With some mechanisms, the second component of the
triple will be a QOP. Internally, on the NFS implementation, it
is expected that the triple would use a QOP for the second
component.
* <メカニズム、アルゴリズム、サービス>は3倍になります。 GSS API仕様に従って、ユニークなISOオブジェクト識別子(OID)とメカニズムを同一視しなければなりません。 三重の2番目のコンポーネントが必ずQOP値であるというわけではない理由がそのGSS-APIである理由は保護のデフォルト品質に使用されるアルゴリズムに関するマッピングの多くの緯度をメカニズムに許容します(小区分4.1、「ケルベロスV5 QOPsの問題」を見てください、詳細な論議のために)。 いくつかのメカニズムで、三重の2番目のコンポーネントはQOPになるでしょう。 内面的に、NFS実装では、三重が2番目のコンポーネントにQOPを使用すると予想されます。
The mapping registration SHOULD also contain:
また、マッピング登録SHOULDは以下を含んでいます。
* A reference to an RFC describing how the NFS protocol works
over the pseudo flavor(s), including the pseudo flavor
number(s), string name(s) for the flavor(s), and any other
issues, including how the registrant is interpreting the GSS-API
mechanism.
* NFSがどう議定書を作るかを説明するRFCの参照は風味、およびいかなる他の問題のためにも疑似風味の上で(s) 疑似風味番号を含んでいるストリング名を扱います、記入者がどうGSS-APIメカニズムを解釈しているかを含んでいて。
* A reference to the GSS-API mechanism used.
* 使用されるGSS-APIメカニズムの参照。
An example of a complete registration is provided in subsection 4.2, "The NFS Protocol over Kerberos V5 Pseudo Flavor Registration Entry."
完全な登録に関する例は小区分4.2では、「NFSはケルベロスV5疑似風味登録エントリーの上で議定書を作るかどうか」ということです。
4. The NFS Protocol over Kerberos V5
4. ケルベロスV5の上のNFSプロトコル
The NFS protocol uses Kerberos V5 security using the RPCSEC_GSS security flavor. The GSS-API security mechanism for Kerberos V5 that the NFS/RPCSEC_GSS protocol stack uses is described in the Kerberos V5 GSS-API description [RFC1964].
NFSプロトコルは、RPCSEC_GSSセキュリティ風味を使用することでケルベロスV5セキュリティを使用します。 NFS/RPCSEC_GSSプロトコル・スタックが使用するケルベロスV5のためのGSS-APIセキュリティー対策はケルベロスV5 GSS-API記述[RFC1964]で説明されます。
Eisler Standards Track [Page 11] RFC 2623 NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999
アイスラー標準化過程[11ページ]のRFC2623NFSセキュリティ、RPCSEC_GSS、およびケルベロスV5 June 1999
4.1. Issues with Kerberos V5 QOPs
4.1. ケルベロスV5 QOPsの問題
The Kerberos V5 GSS-API description defines three algorithms for integrity:
ケルベロスV5 GSS-API記述は保全のために3つのアルゴリズムを定義します:
* DES MAC MD5
* デスMac MD5
* MD2.5
* MD2.5
* DES-MAC
* デス-Mac
RFC 1964 states that MD2.5 "may be significantly weaker than DES MAC MD5." RFC 1964 also states that DES-MAC "may not be present in all implementations."
RFC1964は、MD2.5が「DES MAC MD5よりかなり弱いかもしれない」と述べます。 また、RFC1964は、DES-MACが「すべての実装では、存在していないかもしれない」と述べます。
Thus the description of operation of NFS clients and servers over Kerberos V5 is limited to the DES MAC MD5 integrity algorithm.
したがって、ケルベロスV5の上のNFSクライアントとサーバの操作の記述はDES MAC MD5保全アルゴリズムに制限されます。
NFS clients and servers operating over Kerberos V5 MUST support the DES MAC MD5 integrity algorithm. RFC 1964 lists a single algorithm for privacy: 56 bit DES. NFS clients and servers SHOULD support the 56 bit DES privacy algorithm.
ケルベロスV5 MUSTの上で手術されるNFSクライアントとサーバはDES MAC MD5保全アルゴリズムをサポートします。 RFC1964はプライバシーのためにただ一つのアルゴリズムを記載します: 56はDESに噛み付きました。 NFSクライアントとサーバSHOULDは56ビットのDESプライバシーアルゴリズムをサポートします。
GSS-API has the concept of a default QOP of zero which means different integrity and privacy algorithms to different GSS-API mechanisms. In Kerberos V5, the default QOP of zero means to use the 56 bit DES algorithm (when doing a GSS_Wrap() operation with the conf_req_flag set to 1).
GSS-APIには、異なったGSS-APIメカニズムに異なった保全とプライバシーアルゴリズムを意味するゼロのデフォルトQOPの概念があります。ケルベロスV5では、ゼロのデフォルトQOPは、56ビットのDESアルゴリズムを使用することを意味します(conf_req_旗のセットによるGSS_Wrap()操作を1にするとき)。
For Kerberos V5, the default QOP of zero means different integrity algorithms to different implementations of Kerberos V5. Furthermore, during the processing of a token in GSS_Unwrap(), and GSS_VerifyMIC(), at least one reference implementation of the Kerberos V5 GSS-API mechanism [MIT], always returns a QOP of zero, regardless of integrity algorithm encoded in the token. For such implementations, it means that the caller of GSS_Unwrap() and GSS_VerifyMIC() cannot know the actual integrity algorithm used. Given that each integrity algorithm has a different degree of security, this situation may not be acceptable to the user of GSS- API. An implementation of Kerberos V5 under GSS-API for use under NFS MUST NOT do this.
ケルベロスV5に関しては、ゼロのデフォルトQOPはケルベロスV5の異なった実装に異なった保全アルゴリズムを意味します。 その上、GSS_でのトークンの処理の間、ケルベロスV5 GSS-APIメカニズム[MIT]のUnwrap()、およびGSS_VerifyMIC()、少なくとも1つの参照実装がいつもゼロのQOPを返します、トークンでコード化された保全アルゴリズムにかかわらず。 そのような実装のために、それは、GSS_Unwrap()とGSS_VerifyMIC()の訪問者が、実際の保全アルゴリズムが使用したのを知ることができないことを意味します。 それぞれの保全アルゴリズムに異なった度合いのセキュリティがあるなら、GSS APIのユーザにとって、この状況は許容できないかもしれません。 NFS MUST NOTの下の使用のためのGSS-APIの下のV5がこれをするケルベロスの実装。
For the purposes of NFS, as a simplification, some Kerberos V5 GSS- API mechanisms MAY map QOP 0 to always mean DES MAC MD5 integrity, and when using GSS_VerifyMIC() and GSS_Unwrap(), always map the DES MAC MD5 integrity that is specified to QOP 0.
NFSの目的には、何らかのケルベロスV5 GSSのAPIメカニズム5月のいつの簡素化、いつもDES MAC MD5保全を意味する地図QOP0、GSS_VerifyMIC()を使用して、およびGSS_Unwrap()として、いつもQOP0に指定されるDES MAC MD5保全を写像してくださいか。
Eisler Standards Track [Page 12] RFC 2623 NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999
アイスラー標準化過程[12ページ]のRFC2623NFSセキュリティ、RPCSEC_GSS、およびケルベロスV5 June 1999
4.2. The NFS Protocol over Kerberos V5 Pseudo Flavor Registration Entry
4.2. ケルベロスV5疑似風味登録エントリーの上のNFSプロトコル
Here are the pseudo flavor mappings for the NFS protocol using
ここに、NFSプロトコル使用のための疑似風味マッピングがあります。
Kerberos V5 security:
ケルベロスV5セキュリティ:
columns:
コラム:
1 == number of pseudo flavor 2 == name of pseudo flavor 3 == mechanism's OID 4 == mechanism's algorithm(s) 5 == RPCSEC_GSS service
1 RPCSEC_GSS疑似風味3=メカニズムのOID4=メカニズムのアルゴリズム5=サービスの疑似風味2=名の=番号
1 2 3 4 5
-----------------------------------------------------------------------
390003 krb5 1.2.840.113554.1.2.2 DES MAC MD5 rpc_gss_svc_none
390004 krb5i 1.2.840.113554.1.2.2 DES MAC MD5 rpc_gss_svc_integrity
390005 krb5p 1.2.840.113554.1.2.2 DES MAC MD5 rpc_gss_svc_privacy
for integrity,
and 56 bit DES
for privacy.
1 2 3 4 5 ----------------------------------------------------------------------- 390003krb5、1.2 .840 .113554 .1 .2 .2 DES MAC MD5 rpc_gss_は保全のために_なにもに390004krb5i1.2.840.113554.1.2.2DES MAC MD5 rpc_gss_svc_保全390005krb5p1.2.840.113554.1.2.2DES MAC MD5 rpc_gss_svcな_プライバシーをsvcして、プライバシーのために56ビットのDESをsvcします。
An implementation of NFS over RPCSEC_GSS/GSS-API/Kerberos V5 that maps the default QOP to DES MAC MD5 (and vice versa), would implement a mapping of:
DES MAC MD5(逆もまた同様である)にデフォルトQOPを写像するRPCSEC_GSS/GSS-API/ケルベロスV5の上のNFSの実装、以下に関するマッピングを実装するでしょう。
columns:
コラム:
1 == number of pseudo flavor
2 == name of pseudo flavor
3 == mechanism's OID
4 == QOP
5 == RPCSEC_GSS service
1 RPCSEC_GSS疑似風味3=メカニズムのOID4=QOP5=サービスの疑似風味2=名の=番号
1 2 3 4 5
-----------------------------------------------------------
390003 krb5 1.2.840.113554.1.2.2 0 rpc_gss_svc_none
390004 krb5i 1.2.840.113554.1.2.2 0 rpc_gss_svc_integrity
390005 krb5p 1.2.840.113554.1.2.2 0 rpc_gss_svc_privacy
1 2 3 4 5 ----------------------------------------------------------- 390003 krb5 1.2.840.113554.1.2.2 0rpc_gss_は_なにもに390004krb5i1.2.840.113554.1.2.2 0rpc_gss_svc_保全390005krb5p1.2.840.113554.1.2.2 0rpc_gss_svc_プライバシーをsvcします。
The reference for the GSS-API mechanism with the above OID is [RFC1964].
上のOIDがあるGSS-APIメカニズムの参照は[RFC1964]です。
The reference for how the NFS protocol MUST work over Kerberos V5 is this document.
NFSプロトコルがケルベロスV5の上でどう働かなければならないか参照はこのドキュメントです。
Eisler Standards Track [Page 13] RFC 2623 NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999
アイスラー標準化過程[13ページ]のRFC2623NFSセキュリティ、RPCSEC_GSS、およびケルベロスV5 June 1999
5. Security Considerations
5. セキュリティ問題
Version 3 of the MOUNT protocol is used to negotiate the security flavor to be used by the NFS Version 3 client. If the NFS client uses a weak security flavor like AUTH_SYS to query a Version 3 MOUNT server, then the following attacks are possible by an attacker in the middle:
山のプロトコルのバージョン3は、NFSバージョンによって使用されるべきセキュリティ風味を交渉するのに使用されます。3クライアント。 NFSクライアントがバージョン3山のサーバについて質問するのにAUTH_SYSのような弱いセキュリティ風味を使用するなら、以下の攻撃は中央の攻撃者は可能です:
* The attacker in the middle can coax the NFS client into using a
weaker form of security than what the real NFS server requires.
However, once the NFS client selects a security flavor when it
sends a request to real NFS server, if the flavor is
unacceptable, the NFS client's NFS request will be rejected. So
at worst, a denial of service attack is possible. In theory, the
NFS client could contact the MOUNT server using a stronger
security flavor, but this would require that the client know in
advance what security flavors the MOUNT server supports.
* 中央の攻撃者は、NFSクライアントが実際のNFSサーバが必要とすることより弱いフォームのセキュリティを使用するようにうまく説きつけることができます。 しかしながら、実際のNFSサーバに要求を送るとき、風味が容認できないならNFSクライアントがいったんセキュリティ風味を選択すると、NFSクライアントのNFS要求は拒絶されるでしょう。 それで、最悪の場合は、サービス不能攻撃は可能です。 理論上、より強いセキュリティ風味を使用することでNFSクライアントは山のサーバに連絡できるでしょうが、これは、クライアントが、あらかじめ山のサーバがどんなセキュリティ風味をサポートするかを知っているのを必要とするでしょう。
* If the client and server support a common set of security
flavors, such that the client considers one preferable to the
other (for example, one might have privacy and other not),
unless the client uses a strong security flavor in the MOUNT
protocol query, an attacker in the middle could cause the client
to use the weaker form of security. Again, a client could
contact the MOUNT server using a stronger form of security.
* クライアントとサーバが一般的なセットのセキュリティ風味をサポートするのでクライアントが、1つがもう片方より望ましいと考える、(例えば、1つがプライバシーで他に持っているかもしれない、)、中央のどんな攻撃者もクライアントが山のプロトコル質問に強いセキュリティ風味を使用しない場合クライアントにより弱いフォームのセキュリティを使用させることができませんでした。 一方、より強いフォームのセキュリティを使用することでクライアントは山のサーバに連絡できるでしょう。
6. IANA Considerations [RFC2434]
6. IANA問題[RFC2434]
This memorandum describes how NFS Version 2 and Version 3 work over
RPC's RPCSEC_GSS security flavor. This memorandum requires that
triples of { GSS-API mechanism OID, GSS-API mechanism algorithm,
RPCSEC_GSS security service } be mapped to a unique RPC security
flavor number, which is a pseudo flavor that does not appear in an
RPC protocol header. This memorandum also encourages that an ASCII
string name be registered with the triple.
このメモはNFSバージョン2とバージョン3がRPCのRPCSEC_GSSセキュリティ風味の上でどう働いているかを説明します。 このメモは、GSS-APIメカニズムOID、GSS-APIメカニズムアルゴリズム、RPCSEC_GSSセキュリティー・サービスの三重がユニークなRPCセキュリティ風味番号に写像されるのを必要とします。(番号はRPCプロトコルヘッダーに現れない疑似風味です)。 また、このメモは、ASCIIストリング名が三重に登録されるよう奨励します。
Thus there are five different kinds of objects to consider guidelines for.
したがって、ガイドラインを考えるオブジェクトの5つの異種があります。
6.1. Pseudo Flavor Number
6.1. 疑似風味番号
The considerations of assignment, allocation, and delegation of pseudo flavor numbers are no different than that the considerations for RPC security flavors, as both are assigned from the same number space. IANA is already responsible for the assigned of RPC security flavors, and because this memorandum does not specify the RPC protocol [RFC1831], it is beyond the scope of this memorandum to guide IANA in the assignment of flavor numbers.
疑似風味番号の課題、配分、および委譲の問題はRPCセキュリティのための問題に両方として風味を添えるのが同じ数のスペースから割り当てられるほど異なっていません。 IANAは既にRPCセキュリティ風味の割り当てに責任があります、そして、このメモがRPCプロトコル[RFC1831]を指定しないのが、このメモの範囲を超えた風味番号の課題でIANAを誘導するためにはそれの理由です。
Eisler Standards Track [Page 14] RFC 2623 NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999
アイスラー標準化過程[14ページ]のRFC2623NFSセキュリティ、RPCSEC_GSS、およびケルベロスV5 June 1999
6.2. String Name of Pseudo Flavor
6.2. 疑似風味のストリング名
This memorandum introduces the concept of a string name to be associated with the RPC pseudo flavor number, and so it is within the scope of this memorandum to provide guidance to IANA.
このメモがRPC疑似風味番号に関連しているようにストリング名の概念を紹介するので、指導をIANAに供給するために、このメモの範囲の中にそれはあります。
6.2.1. Name Space Size
6.2.1. 名前スペースサイズ
There are no limits placed on the length of the unique string name by this memorandum, so the size of the name space is infinite. However, IANA may want to prevent the hoarding or reservation of names. The simplest way to do this is by requiring the registrant to provide the GSS-API mechanism OID, GSS-API quality of protection, the RPCSEC_GSS security service, and flavor number, with the request for a flavor name. If the registrant does not have a flavor number, then guidelines for flavor number assignments will indirectly limit the assignment of flavor names.
このメモによってユニークなストリング名の長さに置かれた限界が全くないので、スペースという名前のサイズは無限です。 しかしながら、IANAは名前の貯蔵か予約を防ぎたがっているかもしれません。 これをする最も簡単な方法は記入者を必要としますGSS-APIメカニズムOID、保護のGSS-API品質、RPCSEC_GSSセキュリティー・サービス、および風味番号を提供するために、風味名を求める要求で。 記入者に風味番号がないと、風味数の課題のためのガイドラインは間接的に風味名の課題を制限するでしょう。
6.2.2. Delegation
6.2.2. 委譲
The simplest way to handle delegation is to delegate portions of the RPC security flavor number space with the RPC flavor name space. The guidelines for delegation of the flavor name space are thus equivalent to guidelines for delegations of the flavor number space.
委譲を扱う最も簡単な方法はスペースというRPC風味名があるRPCセキュリティ風味数のスペースの部分を代表として派遣することです。 その結果、スペースという風味名の委譲のためのガイドラインは風味数のスペースの委譲のためのガイドラインに同等です。
6.2.3. Outside Review
6.2.3. レビューの外で
Because string names can be trademarks, IANA may want to seek legal counsel to review a proposed pseudo flavor name. Other than that, no outside review is necessary.
ストリング名が商標であるかもしれないので、IANAは提案された疑似風味名を見直すために弁護士を探したがっているかもしれません。 それ以外に、どんな外のレビューも必要ではありません。
6.3. GSS-API Mechanism OID
6.3. GSS-APIメカニズムOID
This memorandum assumes that the mechanism OID associated with the pseudo flavor has already been allocated. OIDs are allocated by the International Standards Organization and the International Telecommunication Union. Both organizations have delegated assignment authority for subsets of the OID number space to other organizations. Presumably, IANA has received authority to assign OIDs to GSS-API mechanisms. Because this memorandum does not specify the GSS-API protocol (see [RFC2078]) it is beyond the scope of this memorandum to guide IANA in the assignment of GSS-API mechanism OIDs.
このメモは、疑似風味に関連しているメカニズムOIDが既に割り当てられたと仮定します。 OIDsは国際Standards Organizationと国際電気通信連合によって割り当てられます。 両方の組織はOID数のスペースの部分集合のために課題権威を他の組織へ代表として派遣しました。 おそらく、IANAはGSS-APIメカニズムにOIDsを割り当てる権威を受けました。このメモがGSS-APIプロトコルを指定しないのが([RFC2078]を見てください)、このメモの範囲を超えたGSS-APIメカニズムOIDsの課題でIANAを誘導するためにはそれの理由です。
6.4. GSS-API Mechanism Algorithm Values
6.4. GSS-APIメカニズムアルゴリズム値
This memorandum assumes that the algorithm value for a given GSS-API mechanism has already been allocated. Algorithm values are controlled by the owner of the GSS-API mechanism, though the owner may delegate
このメモは、与えられたGSS-APIメカニズムのためのアルゴリズム値が既に割り当てられたと仮定します。 所有者は代表として派遣するかもしれませんが、アルゴリズム値はGSS-APIメカニズムの所有者によって制御されます。
Eisler Standards Track [Page 15] RFC 2623 NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999
アイスラー標準化過程[15ページ]のRFC2623NFSセキュリティ、RPCSEC_GSS、およびケルベロスV5 June 1999
assignment of algorithm values to a body such as IANA. Because this memorandum does not specify GSS-API mechanisms, such as [RFC1964], it is beyond the scope of this memorandum to guide IANA in the assignment of a mechanism's algorithm value(s).
アルゴリズムの課題はIANAとしてボディーにそのようなものを評価します。 このメモが[RFC1964]などのGSS-APIメカニズムを指定しないのが、このメモの範囲を超えたメカニズムのアルゴリズム価値の課題でIANAを誘導するためにはそれの理由です。
6.5. RPCSEC_GSS Security Service
6.5. RPCSEC_GSSセキュリティー・サービス
There are only three security services and they are enumerated and described in [RFC2203]. No guideline to IANA is necessary.
3つのセキュリティー・サービスしかなくて、それらは、[RFC2203]で数え上げられて、説明されます。 IANAへのどんなガイドラインも必要ではありません。
References
参照
[RFC1094] Sun Microsystems, Inc., "NFS: Network File System
Protocol Specification", RFC 1094, March 1989.
http://www.ietf.org/rfc/rfc1094.txt
[RFC1094]サン・マイクロシステムズ・インク、「NFS:」 「ネットワークファイルシステムプロトコル仕様」、RFC1094、3月1989日の http://www.ietf.org/rfc/rfc1094.txt
[Sandberg]
Sandberg, R., Goldberg, D., Kleiman, S., Walsh, D., Lyon,
B. (1985). "Design and Implementation of the Sun Network
Filesystem," Proceedings of the 1985 Summer USENIX
Technical Conference.
[サンドベルイ]サンドベルイ、R.、ゴールドバーグ、D.、Kleiman、S.、ウォルシュ、D.、リヨン、B.(1985。) 「Sunネットワークファイルシステムの設計と実装」、1985年の夏のUSENIXの技術的なコンファレンスの議事。
[RFC1813] Callaghan, B., Pawlowski, B. and P. Staubach, "NFS
Version 3 Protocol Specification", RFC 1813, June 1995.
http://www.ietf.org/rfc/rfc1813.txt
[RFC1813] キャラハンとB.とポロウスキーとB.とP.ストーバック、「NFSバージョン3プロトコル仕様」、RFC1813、6月1995の http://www.ietf.org/rfc/rfc1813.txt
[RFC1831] Srinivasan, R., "RPC: Remote Procedure Call Protocol
Specification Version 2", RFC 1831, August 1995.
http://www.ietf.org/rfc/rfc1831.txt
[RFC1831]Srinivasan、R.、「RPC:」 遠隔手続き呼び出しプロトコル仕様バージョン2インチ、RFC1831、8月1995日の http://www.ietf.org/rfc/rfc1831.txt
[RFC1832] Srinivasan, R., "XDR: External Data Representation
Standard", RFC 1832, August 1995.
http://www.ietf.org/rfc/rfc1832.txt
[RFC1832]Srinivasan、R.、「XDR:」 「外部データ表現規格」、RFC1832、8月1995日の http://www.ietf.org/rfc/rfc1832.txt
[Pawlowski]
Pawlowski, B., Juszczak, C., Staubach, P., Smith, C.,
Lebel, D. and D. Hitz, "NFS Version 3 Design and
Implementation", Proceedings of the USENIX Summer 1994
Technical Conference.
[ポロウスキー]ポロウスキーとB.とJuszczakとC.とストーバックとP.とスミスとC.とルベルとD.とD.Hitz、「NFSバージョン3設計と実装」、USENIX1994年夏の技術的なコンファレンスの議事。
[RFC2203] Eisler, M., Chiu, A. and L. Ling, "RPCSEC_GSS Protocol
Specification", RFC 2203, September 1997.
http://www.ietf.org/rfc/rfc2203.txt
[RFC2203] アイスラーとM.とチウとA.とL.の御柳もどき、「RPCSEC_GSSプロトコル仕様」、RFC2203、9月1997の http://www.ietf.org/rfc/rfc2203.txt
[RFC2078] Linn, J., "Generic Security Service Application
Program Interface, Version 2", RFC 2078, January 1997.
http://www.ietf.org/rfc/rfc2078.txt
[RFC2078] リン、J.、「ジェネリックセキュリティー・サービス適用業務プログラム・インタフェース、バージョン2インチ、RFC2078、1月1997日の http://www.ietf.org/rfc/rfc2078.txt 」
Eisler Standards Track [Page 16] RFC 2623 NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999
アイスラー標準化過程[16ページ]のRFC2623NFSセキュリティ、RPCSEC_GSS、およびケルベロスV5 June 1999
[RFC1057] Sun Microsystems, Inc., "RPC: Remote Procedure Call
Protocol Specification Version 2", RFC 1057, June 1988.
This RFC is being referenced for its description of the
AUTH_DH (AUTH_DES) RPC security flavor.
http://www.ietf.org/rfc/rfc1057.txt
[RFC1057]サン・マイクロシステムズ・インク、「RPC:」 遠隔手続き呼び出しプロトコル仕様バージョン2インチ、RFC1057、1988年6月。 このRFCは風味AUTH_DH(AUTH_DES)RPCセキュリティ http://www.ietf.org/rfc/rfc1057.txt の記述のために参照をつけられています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
http://www.ietf.org/rfc/rfc2119.txt
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、3月1997日の http://www.ietf.org/rfc/rfc2119.txt
[Callaghan]
Callaghan, B., Singh, S. (1993). "The Autofs Automounter,"
Proceedings of the 1993 Summer USENIX Technical Conference.
[キャラハン]キャラハン、B.、シン、S.(1993。) 「Autofsオートマウンタ」、1993年の夏のUSENIXの技術的なコンファレンスの議事。
[RFC1964] Linn, J., "The Kerberos Version 5 GSS-API
Mechanism", RFC 1964, June 1996.
http://www.ietf.org/rfc/rfc1964.txt
[RFC1964] リン、J.、「ケルベロスバージョン5GSS-APIメカニズム」、RFC1964、6月1996日の http://www.ietf.org/rfc/rfc1964.txt
[RFC2054] Callaghan, B., "WebNFS Client Specification", RFC
2054, October 1996.
http://www.ietf.org/rfc/rfc2054.txt
[RFC2054] キャラハン、B.、「WebNFSクライアント仕様」、RFC2054、10月1996日の http://www.ietf.org/rfc/rfc2054.txt
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing
an IANA Considerations Section in RFCs", BCP 26, RFC
2434, October 1998.
http://www.ietf.org/rfc/rfc2434.txt
[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434、10月1998日の http://www.ietf.org/rfc/rfc2434.txt
[MIT] Massachusetts Institute of Technology (1998). "Kerberos:
The Network Authentication Protocol." The Web site for
downloading MIT's implementation of Kerberos V5, including
implementations of RFC 1510 and RFC 1964.
http://web.mit.edu/kerberos/www/index.html
[MIT]マサチューセッツ工科大学(1998)。 「ケルベロス:」 「ネットワーク認証プロトコル。」 MITのRFC1510とRFC1964 http://web.mit.edu/kerberos/www/index.html の実装を含むケルベロスV5の実装をダウンロードするためのウェブサイト
Acknowledgments
承認
The author thanks:
作者は感謝します:
* Brent Callaghan, John Hawkinson, Jack Kabat, Lin Ling, Steve
Nahm, Joyce Reynolds, and David Robinson for their review
comments.
* 彼らのレビューコメントのためのブレント・キャラハン、ジョンHawkinson、ジャック・カバット、リンLing、スティーブ・ナム、ジョイス・レイノルズ、およびデイビッド・ロビンソン。
* John Linn, for his explanation of QOP handling in RFC 1964.
* RFC1964のQOP取り扱いに関する彼の説明のためのジョン・リン。
Eisler Standards Track [Page 17] RFC 2623 NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999
アイスラー標準化過程[17ページ]のRFC2623NFSセキュリティ、RPCSEC_GSS、およびケルベロスV5 June 1999
Author's Address
作者のアドレス
Address comments related to this memorandum to:
アドレスコメントは以下のことのためにこのメモに関連しました。
nfsv4-wg@sunroof.eng.sun.com
nfsv4-wg@sunroof.eng.sun.com
Mike Eisler Sun Microsystems, Inc. 5565 Wilson Road Colorado Springs, CO 80919
マイクアイスラーサン・マイクロシステムズ・インク5565のウィルソン・道路コロラド・スプリングス、CO 80919
Phone: 1-719-599-9026 EMail: mre@eng.sun.com
以下に電話をしてください。 1-719-599-9026 メールしてください: mre@eng.sun.com
Eisler Standards Track [Page 18] RFC 2623 NFS Security, RPCSEC_GSS, and Kerberos V5 June 1999
アイスラー標準化過程[18ページ]のRFC2623NFSセキュリティ、RPCSEC_GSS、およびケルベロスV5 June 1999
14. Full Copyright Statement
14. 完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation 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 eveloping 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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配されたimplmentationを助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準をevelopingする目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Eisler Standards Track [Page 19]
アイスラー標準化過程[19ページ]
一覧
スポンサーリンク
