Secure Shell Working Group J. Galbraith Internet-Draft J. Van Dyke Expires: March 15, 2004 B. McClure VanDyke Software J. Bright Silicon Circus September 15, 2003 # 訳者 春山征吾 haruyama@unixuser.org Secure Shell Public-Key Subsystem draft-ietf-secsh-publickey-subsystem-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 15, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract 概要 SECSH defines an authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. No common key management solution exists in current implementations. This document describes a protocol that can be used to configure public keys in an implementation-independent fashion, allowing client software to take on the burden of this configuration. SECSHは公開鍵に基づく認証メカニズムを定義しているが, 鍵配布については どんなメカニズムも定義していない. 現在の実装には 共通の鍵配布 ソリューションは存在しない. この文書は, クライアントソフトウェアに公開鍵の設定の責任を与えて 実装非依存の方法でこの設定するために使われるプロトコルを記述する. This protocol is intended to be used from the Secure Shell Connection Protocol [4] as a subsystem, as described in Section ``Starting a Galbraith, et al. Expires March 15, 2004 [Page 1] Internet-Draft Secure Shell Public-Key Subsystem September 2003 Shell or a Command''. The subsystem name used with this protocol is "publickey". このプロトコルは, Secure Shell Connection Protocol [4] の ``Starting a Shell or a Command'' セクションで記述されているように サブシステムとして Secure Shell Connection Protocol から 使われることを意図している. このプロトコルと共に使われる このサブシステムの名前は "publickey" だ. The public-key subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. Rights to manage public keys are specific and limited to the authenticated user. public-key サブシステムは, クライアントが公開鍵を追加する削除し サーバが現在知っている公開鍵のリストアップする, サーバに依存しない機構を提供する. 公開鍵を管理する権限は, 認証されたユーザに限定される. A public key may also be associated with various restrictions, including a mandatory command or subsystem. 公開鍵は 必須のコマンドやサブシステムに含まれる, 様々な制限 とも関連する. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Public-Key Subsystem Overview . . . . . . . . . . . . . . . 4 2.1 Opening the Public-Key Subsystem . . . . . . . . . . . . . . 4 2.2 Requests . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3 Responses . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3.1 The Status Response . . . . . . . . . . . . . . . . . . . . 5 3. Public-Key Subsystem Operations . . . . . . . . . . . . . . 7 3.1 Version Packet . . . . . . . . . . . . . . . . . . . . . . . 7 3.2 Adding a public key . . . . . . . . . . . . . . . . . . . . 7 3.3 Removing a public key . . . . . . . . . . . . . . . . . . . 10 3.4 Listing public keys . . . . . . . . . . . . . . . . . . . . 10 3.5 Listing server capabilities . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . 12 Normative References . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . 15 Galbraith, et al. Expires March 15, 2004 [Page 2] Internet-Draft Secure Shell Public-Key Subsystem September 2003 1. Introduction 1. イントロダクション SECSH is a protocol for secure remote login and other secure network services over an insecure network. SECSH defines an authentication mechanism that is based on public keys, but does not define any mechanism for key distribution. Common practice is to authenticate once with password authentication and transfer the public key to the server. However, to date no two implementations use the same mechanism to configure a public key for use. SECSH は 安全でないネットワーク越しの安全なリモートログインや他の 安全なネットワークサービスのためのプロトコルだ. SECSH は SECSHは公開鍵に基づく認証メカニズムを定義しているが, 鍵配布については どんなメカニズムも定義していない. 一般に行なわれているのは, 一度パスワード認証を行ない, サーバに公開鍵を転送することだ. しかし, 現在まで, 公開鍵を設定するために共通のメカニズムを使う実装はない. This document describes a subsystem that can be used to configure public keys in an implementation-independent fashion. This approach allows client software to take on the burden of this configuration. The public-key subsystem protocol is designed for extreme simplicity in implementation. It is not intended as a PKIX replacement. この文書は, 実装非依存の方法で公開鍵を設定するために使われる サブシステムを定義する. このアプローチは, この設定の責任を クライアントソフトウェアに委ねる. public-key サブシステムは 実装が非常に単純になるよう設計されている. PKIX を置換しようと するものではない. The Secure Shell Public-Key subsystem has been designed to run on top of the SECSH transport layer [2] and user authentication protocols [3]. It provides a simple mechanism for the client to manage public keys on the server. Secure Shell Public-Key subsystemは, SECSH トランスポート層と ユーザ認証プロトコルの上で動くために設計されている. サーバ上の公開鍵を管理するクライアントのための単純なメカニズムを 提供する. This document should be read only after reading the SECSH architecture [1] and SECSH connection [4] documents. この文書は SECSH architecture [1] と SECSH connection [4] 文書を 読んだあとでのみ読まれるべきだ. This protocol requires that the user be able to authenticate in some fashion before it can be used. If password authentication is used, servers SHOULD provide a configuration option to disable the use of password authentication after the first public key is added. このプロトコルは, これを使う前に, なんらかの方法でユーザを認証できる ことが必要となる. パスワード認証が使われるなら, サーバは最初の鍵が追加された後でパスワード認証の使用を無効にする 設定の選択肢を提供する必要がある. Galbraith, et al. Expires March 15, 2004 [Page 3] Internet-Draft Secure Shell Public-Key Subsystem September 2003 2. Public-Key Subsystem Overview 2. Public-Key サブシステムの概要 The public-key subsystem provides a server-independent mechanism for clients to add public keys, remove public keys, and list the current public keys known by the server. The subsystem name is "publickey". public-key サブシステムは, クライアントが公開鍵を追加する削除し サーバが現在知っている公開鍵のリストをリストアップする, サーバに依存しない機構を提供する. サブシステムの名前は "publickey" だ. The public keys added, removed, and listed using this protocol are specific and limited to those of the authenticated user. このプロトコルで使われる 追加され削除されリストアップされる 公開鍵は, 認証されたユーザのものに制限される. The operations to add, remove and list the authenticated user's public keys are performed as request packets sent to the server. The server sends response packets that indicate success or failure as well as provide specific response data. 認証されたユーザの公開鍵の追加, 削除, リストの操作は サーバに送られるリクエストパケットによって実行される. サーバは 成功失敗を示し固有のレスポンスデータを提供する レスポンスパケットを 送信する. The format of public-key blobs are detailed in the SSH Transport Protocol document [2]. public-key blob のフォーマットは SSH Transport Protocol 文書 [2] に 詳述されている. 2.1 Opening the Public-Key Subsystem 2.1 Public-Key サブシステムの開始 The public-key subsystem is opened when the clients sends a SSH_MSG_CHANNEL_REQUEST over an existing session. public-key サブシステムは, クライアントがすでにあるセッション越しに SSH_MSG_CHANNEL_REQUEST を送ることで開始される. The details of how a session is opened are described in the SSH Connection Protocol document [4] in the section "Opening a Session". どのようにセッションを開始するかの詳細は, SSH Connection Protocol document [4] の "Opening a Session" セクションに記述されている. To open the public-key subsystem, the client sends: public-key サブシステムを開始するには, クライアントは次のものを送る. byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "subsystem" boolean want reply string "publickey" Client implementations SHOULD reject this request; it is normally only sent by the client. クライアントの実装はこのリクエストを拒否する必要がある. これは通常クライアントからのみ送られる. If want reply is TRUE, the server MUST respond with SSH_MSG_CHANNEL_SUCCESS if the public-key subsystem was successfully started or SSH_MSG_CHANNEL_FAILURE if the server failed to start or does not support the public-key subsystem. want reply が TRUE なら, サーバは, public-key サブシステム成功裏に始められたなら SSH_MSG_CHANNEL_SUCCESS public-key サブシステムの開始に失敗したり このサブシステムをサポート していない場合は SSH_MSG_CHANNEL_FAILURE を返さなければならない. The server SHOULD respond with SSH_MSG_CHANNEL_FAILURE if the user authenticated with a restricted public key that does not allow access to the publickey subsystem. ユーザがpublickey サブシステムへのアクセスを許されていない 制限された公開鍵 で認証された場合, サーバは SSH_MSG_CHANNEL_FAILURE を返す必要がある. It is RECOMMENDED that clients request and check the reply for this request. クライアントはこのリクエストに対する返答を要求し検査することが推奨される. Galbraith, et al. Expires March 15, 2004 [Page 4] Internet-Draft Secure Shell Public-Key Subsystem September 2003 2.2 Requests 2.2 リクエスト All public-key subsystem requests are sent in the following form: すべての public-key サブシステムのリクエストは 次の形式で送られる. uint32 length string request-name ... request specific data follows The length field describes the length of the request-name field and the request-specific data, but not of the length field itself. The client MUST receive acknowledgement of each request prior to sending a new request. length フィールドは request-name フィールドと request-specific データの 長さを記述する. length フィールド自身は含まない All requests described in Section 3 are a description of the 'request-name' and 'data' portion of the packet. Section 3で すべてのリクエストについて このパケットの 'request-name' と 'data' 部分を記述する. 2.3 Responses 2.3 レスポンス All public-key subsystem responses are sent in the following form: すべての public-key サブシステムのリスポンスは 次の形式で送られる. uint32 length string response-name ... response specific data follows 2.3.1 The Status Response 2.3.1 ステータス レスポンス A request is acknowledged by sending a status packet. If there is data in response to the request, the status packet is sent after all data has been sent. status パケットを送ることで リクエストが認められる. リクエストへのレスポンスのデータがあるなら, status パケットは すべてのデータが送られてから送られる. string "status" uint32 status code string description [RFC-2279] string language tag [RFC-1766] A status message MUST be sent for any unrecognized packets and the request SHOULD NOT close the subsystem. ステータスメッセージは どんな認識できないパケットに対しても 送られなければならないし, リクエストは サブシステムを終了しなほうがよい. 2.3.1.1 Status Codes 2.3.1.1 ステータスコード The status code gives the status in a more machine-readable format (suitable for localization), and can have the following values: ステータスコードは, よりマシンが可読な (localization に適した) 形式でステータスを与える. 次の値を持ちうる: SSH_PUBLICKEY_SUCCESS 0 SSH_PUBLICKEY_ACCESS_DENIED 1 SSH_PUBLICKEY_STORAGE_EXCEEDED 2 SSH_PUBLICKEY_VERSION_NOT_SUPPORTED 3 Galbraith, et al. Expires March 15, 2004 [Page 5] Internet-Draft Secure Shell Public-Key Subsystem September 2003 SSH_PUBLICKEY_KEY_NOT_FOUND 4 SSH_PUBLICKEY_KEY_NOT_SUPPORTED 5 SSH_PUBLICKEY_KEY_ALREADY_PRESENT 6 SSH_PUBLICKEY_GENERAL_FAILURE 7 SSH_PUBLICKEY_REQUEST_NOT_SUPPORTED 8 Galbraith, et al. Expires March 15, 2004 [Page 6] Internet-Draft Secure Shell Public-Key Subsystem September 2003 3. Public-Key Subsystem Operations 3. Public-Key サブシステムの操作 The public-key subsystem currently defines four operations: add, remove, list, and command. public-key サブシステムは 現在4つの操作を定義している: add, remove, list , command. 3.1 Version Packet 3.1 Version パケット Both sides MUST start by sending a version packet that indicates the version of the protocol they are using. クライアントもサーバも 利用しているプロトコルのバージョンを 示す version パケットをまず最初に送らなければならない. string "version" uint32 protocol-version-number The version of the protocol described by this document is version 2. この文書で記述されるプロトコルのバージョンは version 2 だ. Both sides send the highest version that they implement. The lower of the version numbers is the version of the protocol to use. If either side can't support the lower version, it should close the subsystem and notify the other side by sending an SSH_MSG_CHANNEL_CLOSE message. Before closing the subsystem, a status message with the status SSH_PUBLICKEY_VERSION_NOT_SUPPORTED SHOULD be sent. どちらの側も実装してる最高のバージョンを送る. バージョン番号が小さいほうが 利用されるプロトコルのバージョンとなる. 小さい番号のバージョンを 一方がサポートしていないなら, subsystem を終え, SSH_MSG_CHANNEL_CLOSE メッセージを送ることでもう一方に通知しなければ ならない. subsystem を終える前に, SSH_PUBLICKEY_VERSION_NOT_SUPPORTED ステータスを持つ status メッセージが送られる必要がある. Both sides MUST wait to receive this version before continuing. どちらの側も, 続行する前にこの version の受取を待たなければならない. 3.2 Adding a public key 3.2 公開鍵の追加 If the client wishes to add a public key, the client sends: クライアントが公開鍵を追加しようとする場合, クライアントは次のものを送る: string "add" string public-key algorithm name string public-key blob boolean overwrite uint32 attribute-count string attrib-name string attrib-value bool mandatory repeated attribute-count times The server MUST attempt to store the public key for the user in the appropriate location so the public key can be used for subsequent public-key authentications. If the overwrite field is false and the specified key already exists, the server MUST return SSH_PUBLICKEY_KEY_ALREADY_PRESENT. If the server returns this, the client SHOULD provide an option to the user to overwrite the key. If the overwrite field is true and the specified key already exists but cannot be overwritten, the server MUST return SSH_PUBLICKEY_ACCESS_DENIED この公開鍵を次の公開鍵認証で使われることができるような 適切な場所にユーザのために公開鍵をサーバは保存しようとしなければならない. overwrite フィールドが false で 指定された鍵がすでに存在するなら, サーバは SSH_PUBLICKEY_KEY_ALREADY_PRESENT を返さなければならない. サーバがこれを返したら, クライアントは鍵を上書きするかどうか ユーザに選択肢を提供する必要がある. overwrite フィールドが true で指定されたかぎがすでに存在するが上書き不可能であったら, サーバは SSH_PUBLICKEY_ACCESS_DENIED を返さなければならない. Galbraith, et al. Expires March 15, 2004 [Page 7] Internet-Draft Secure Shell Public-Key Subsystem September 2003 Attribute names are defined following the same scheme laid out for algorithm names in [1]. If the server does not implement a mandatory attribute, it MUST fail the add. For the purposes of a mandatory attribute, storage of the attribute is not sufficient, but requires that the server understand and implement the intent of the attribute. 属性の名前は 次のような[1]のアルゴリズムの名前で割当てられるのと同じ体系で 定義される. サーバが mandatory が true の属性を実装していないなら, 追加を失敗にしなければならない. mandatory が true である属性においては 属性が保存されるだけでは十分ではなく, サーバが属性の意図を理解し実装することを必要とする. The following attributes are currently defined: 次の属性が現在定義されている. "comment" The value of the comment attribute contains user-specified text about the public key. The server SHOULD make every effort to preserve this value and return it with the key during any subsequent list operation. The server MUST NOT attempt to interpret or act upon the content of the comment field in any way. The comment attribute must be specified in UTF-8 format [6]. comment 属性の値は, 公開鍵についてのユーザが指定したテキストが 含まれる. サーバは この値を保存するあらゆる努力する必要があり, 以後のどのリスト操作でも鍵とともに返す必要がある. サーバは comment フィールドの中身をどのような方法でも 解釈したり影響を与えたりしてはならない. comment 属性は UTF-8 フォーマット [6] で指定される. The comment field is useful so the user can identify the key without resorting to comparing its fingerprint. This attribute SHOULD NOT be mandatory. ユーザがその指紋の比較に頼らずにユーザが鍵を同定するのに comment フィールドは役立つ. この属性は mandatory としないほうがよい. "comment-language" If this attribute is specified, it MUST immediately follow a "comment" attribute and specifies the language for that attribute [5]. The client MAY specify more than comment if it additionally specifies a different language for each of those comments. The server SHOULD attempt to store each comment, together with that comment's lanuage attribute. This attribute SHOULD NOT be mandatory. この属性が指定されたら, すぐに次に "comment" 属性が続く必要がある. この属性は "comment"属性の言語を指定する [5]. クライアントは これらの comment それぞれに対して異なる言語をさらに指定するなら 1つより多い comment を指定してもよい. サーバは, この comment の 言語属性と共にそれぞれのコメントを保存しようとする必要がある. この属性は mandatory としないほうがよい. "command-override" "command-override" specifies a command to be executed when this key is in use. The command should be executed by the server when it receives an "exec" or "shell" request from the client, in place of the command or shell which would otherwise have been executed as a result of that request. If the command string is empty, both "exec" and "shell" requests should be denied. If no "command-override" attribute is specified, all "exec" and "shell" requests should be permitted (as long as they satisfy other security or authorisation checks the server may perform). This attribute SHOULD be mandatory. "command-override" は この鍵が使われる場合に実行されるコマンドを 指定する. クライアントから "exec" ないし "shell" リクエストを 受け取ったなら, リクエストの結果として実行されるはずの コマンドやシェルの代りにこのコマンドがサーバによって 実行されなければならない. コマンド文字列が空なら, "exec"と"shell" リクエストは拒否されなければならない. "command-override" 属性が指定されなければ, すべての "exec" と "shell" リクエストは許可されなければならない(サーバが実行する他のセキュリティと 認証のチェックを満たす限り). この属性は mandatory とする必要がある. "subsystem" "subsystem" specifies a comma-separated list of subsystems that may be started (using a "subsystem" request) when this key is in use. This attribute SHOULD be mandatory. If the value is empty, no subsystems may be started. "subsystem" はこの鍵が使われる際に( "subsystem" リクエストを使って) 開始されるサブシステムのカンマ区切りリストを指定する. この属性は mandatory とする必要がある. この値が空なら サブシステムは開始されない. Galbraith, et al. Expires March 15, 2004 [Page 8] Internet-Draft Secure Shell Public-Key Subsystem September 2003 "x11" "x11" specifies that X11 forwarding may not be performed when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be mandatory. "x11" は この鍵が使われる際に X11 転送を行なわないことを指定する. attribute-value フィールドはこの属性では空である必要がある. この属性は mandatory とする必要がある. "shell" "shell" specifies that session channel "shell" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be mandatory. "shell" は この鍵が使われる際に セッションチャンネル の "shell" リクエストが拒否されべきであることを指定する. attribute-value フィールドはこの属性では空である必要がある. この属性は mandatory とする必要がある. "exec" "exec" specifies that session channel "exec" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be mandatory. "exec" は この鍵が使われる際に セッションチャンネル の "exec" リクエストが拒否されべきであることを指定する. attribute-value フィールドはこの属性では空である必要がある. この属性は mandatory とする必要がある. "agent" "agent" specifies that session channel "auth-agent-req" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be mandatory. "agent" は この鍵が使われる際に セッションチャンネル の "auth-agent-req" リクエストが拒否されべきであることを指定する. attribute-value フィールドはこの属性では空である必要がある. この属性は mandatory とする必要がある. "env" "env" specifies that session channel "env" requests should be denied when this key is in use. The attribute-value field SHOULD be empty for this attribute. This attribute SHOULD be mandatory. "env" は この鍵が使われる際に セッションチャンネル の "env" リクエストが拒否されべきであることを指定する. attribute-value フィールドはこの属性では空である必要がある. この属性は mandatory とする必要がある. "from" "from" specifies a comma-separated list of hosts from which the key may be used. If a host not in this list attempts to use this key for authorisation purposes, the authorisation attempt MUST be denied. The server SHOULD make a log entry regarding this. "from" は, 鍵が使われるかもしれないホストのカンマ区切りリストを 指定する. このリストにないホストが認証の目的でこの鍵を使おうと した際は, 認証の試みは拒否されなければならない. サーバは これに関するログのエントリを作る必要がある. "port-forward" "port-forward" specifies that no "direct-tcpip" requests should be accepted, except to those hosts specified in the comma-separated list supplied as a value to this attribute. If the value of this attribute is empty, all "direct-tcpip" requests should be refused when using this key. This attribute SHOULD be mandatory. "port-forward" は, この属性の値として与えられたコンマ区切りリストで 指定されたホストを除いて "direct-tcpip" リクエストを受けいれないことを 指定する. この属性が空なら, この鍵の使用時のすべての "direct-tcpip" リクエストが拒否される必要がある. この属性は mandatory とする必要がある. "reverse-forward" Galbraith, et al. Expires March 15, 2004 [Page 9] Internet-Draft Secure Shell Public-Key Subsystem September 2003 "reverse-forward" specifies that no "tcpip-forward" requests should be accepted, accept for the port numbers in the comma-separated list supplied as a value to this attribute. If the value of this attribute is empty, all "tcpip-forward" requests should be refused when using this key. This attribute SHOULD be mandatory. "reverse-forward" は, この属性の値として与えられたコンマ区切りリストで 指定されたホストを除いて "tcpip-forward" リクエストを受けいれないことを 指定する. この属性が空なら, この鍵の使用時のすべての "tcpip-forward" リクエストが拒否される必要がある. この属性は mandatory とする必要がある. In addition to the attributes specified by the client, the server MAY provide a method for administrators to compulsorily enforce certain attributes. クライアントによって指定される属性に加えて,サーバは 管理者に特定の属性を強要する方法を提供してもよい. 3.3 Removing a public key 3.3 公開鍵の削除 If the client wishes to remove a public key, the client sends: クライアントが公開鍵を削除したいと望む場合, クライアントは次の物を送る: string "remove" string public-key algorithm name string public-key blob The server MUST attempt to remove the public key for the user from the appropriate location, so that the public key cannot be used for subsequent authentications. サーバは, その後の認証でこの公開鍵が使えないように 適当な場所からユーザの公開鍵を削除しようと試みなければ ならない. 3.4 Listing public keys 3.4 公開鍵のリストアップ If the client wishes to list the known public keys, the client sends: クライアントが知られている公開鍵をリストアップしようと望む場合, クライアントは次の物を送る: string "list" The server will respond with zero or more of the following responses: サーバは ゼロか次のレスポンスを1つ以上送る. string "publickey" string public-key algorithm name string public-key blob uint32 attribute-count string attrib-name string attrib-value repeated attribute-count times Following the last "publickey" response, a status packet MUST be sent. 最後の "publickey" レスポンスに続いて, status パケットが 送られなければならない. An implementation MAY choose not to support this request. 実装はこのリクエストをサポートしないことを選択してもよい. 3.5 Listing server capabilities 3.5. サーバの機能のリストアップ If the client wishes to know which key attributes the server supports, it sends: クライアントがサーバがサポートする鍵属性を知ろうとする場合, これを送る: Galbraith, et al. Expires March 15, 2004 [Page 10] Internet-Draft Secure Shell Public-Key Subsystem September 2003 string "listattributes" The server will respond with zero or more of the following responses: サーバは ゼロか次のレスポンスを1つ以上送る. string "attribute" string attribute name boolean compulsory The "compulsory" field indicates whether this attribute will be compulsorily applied to any added keys (irrespective of whether the attribute has been specified by the client) due to administrative settings on the server. If the server does not support administrative settings of this nature, it MUST return false in the compulsory field. "compulsory" フィールドは, サーバ上の管理の設定のために, あらゆる追加される鍵に(属性がクライアントによって指定されるかどうかに 関わらず)強制的にこの属性が適用されるかどうかを示す. サーバがこの手の管理の設定をサポートしないなら, compulsory フィールドに false を返さなければならない. Following the last "attribute" response, a status packet MUST be sent. 最後の "attribute" レスポンスに続いて, status パケットが 送られなければならない. An implementation MAY choose not to support this request. 実装はこのリクエストをサポートしないことを選択してもよい. Galbraith, et al. Expires March 15, 2004 [Page 11] Internet-Draft Secure Shell Public-Key Subsystem September 2003 4. Security Considerations 4. セキュリティに関する考察 This protocol assumes that it is run over a secure channel and that the endpoints of the channel have been authenticated. Thus, this protocol assumes that it is externally protected from network-level attacks. このプロトコルは, 安全なチャンネルの上で動くことと チャンネルのエンドポイント同士が認証されていることを仮定する それゆえ, このプロトコルは, ネットワークレベルの攻撃から 外部から保護されていることを仮定する. This protocol provides a mechanism that allows client authentication data to be uploaded and manipulated. It is the responsibility of the server implementation to enforce any access controls that may be required to limit the access allowed for any particular user (the user being authenticated externally to this protocol, typically using the SSH User Authentication Protocol [3]). In particular, it is possible for users to overwrite an existing key on the server with this protocol, whilst at the same time specifying fewer restrictions for the new key than were previously present. Servers should take care that when doing this, clients are not able to override presets from the server's administrator. このプロトコルは, クライアント認証のデータがアップロードされ操作される ことを許すメカニズムを提供する. (このプロトコルに対して外部で, 典型的には SSH ユーザ認証プロトコル [3]を使って, 認証される) どんなユーザに対しても許されているアクセスを制限することが必要とされる アクセス制御を実施することがサーバ実装の責任である. とりわけ, このプロトコルでサーバ上のすでに存在する鍵を 新しい鍵に対してすでにあったものより少ない制限を指定して ユーザが上書きすることが可能だ. サーバは, これが行われてもクライアントは サーバの管理者からプリセットされた属性を上書きできないようにするように 配慮する必要がある. This protocol requires the client to assume that the server will correctly implement and observe attributes applied to keys. Implementation errors in the server could cause clients to authorise keys for access they were not intended to have, or to apply fewer restrictions than were intended. このプロトコルは, サーバが鍵に適用される属性を 正しく実装し観察することをクライアントが仮定することを必要とする. サーバでの実装のエラーは, クライアントに 意図されていなかったアクセスで鍵を認証したり, 意図されたものよりも少ない制限を適用することを 引き起こす可能性がある. Galbraith, et al. Expires March 15, 2004 [Page 12] Internet-Draft Secure Shell Public-Key Subsystem September 2003 Normative References [1] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. Lehtinen, "SSH Protocol Architecture", draft-ietf-secsh-architecture-13 (work in progress), January 2002. [2] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. Lehtinen, "SSH Transport Layer Protocol", draft-ietf-secsh-transport-15 (work in progress), March 2002. [3] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. Lehtinen, "SSH Authentication Protocol", draft-ietf-secsh-userauth-16 (work in progress), February 2002. [4] Ylonen, T., Kivinen, T., Saarinen, M., Rinne, T. and S. Lehtinen, "SSH Connection Protocol", draft-ietf-secsh-connect-16 (work in progress), January 2002. [5] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995. [6] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. Authors' Addresses Joseph Galbraith VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US Phone: +1 505 332 5700 EMail: galb-list@vandyke.com Jeff P. Van Dyke VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US Phone: +1 505 332 5700 EMail: jpv@vandyke.com Galbraith, et al. Expires March 15, 2004 [Page 13] Internet-Draft Secure Shell Public-Key Subsystem September 2003 Brent McClure VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US Phone: +1 505 332 5700 EMail: bdm@vandyke.com Jon Bright Silicon Circus 24 Jubilee Road Chichester, West Sussex PO19 7XB UK Phone: +49 172 524 0521 EMail: jon@siliconcircus.com Galbraith, et al. Expires March 15, 2004 [Page 14] Internet-Draft Secure Shell Public-Key Subsystem September 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. 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 Galbraith, et al. Expires March 15, 2004 [Page 15] Internet-Draft Secure Shell Public-Key Subsystem September 2003 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. Galbraith, et al. Expires March 15, 2004 [Page 16]