[要約] RFC 4252は、セキュアシェル（SSH）認証プロトコルに関する文書で、SSH接続中のユーザー認証機構を定義しています。このプロトコルは、パスワード認証、公開鍵認証、およびホストベース認証など、複数の認証方法をサポートしています。SSHは主にリモートコンピューターへの安全なアクセスやファイル転送に利用されます。関連するRFCにはRFC 4251（SSHプロトコルアーキテクチャ）、RFC 4253（SSHトランスポート層プロトコル）、RFC 4254（SSH接続プロトコル）などがあります。これらの文書は、SSHプロトコルの様々な側面を詳細に説明しています。
Network Working Group T. Ylonen
Request for Comments: 4252 SSH Communications Security Corp
Category: Standards Track C. Lonvick, Ed.
Cisco Systems, Inc.
January 2006
The Secure Shell (SSH) Authentication Protocol
セキュアシェル（SSH）認証プロトコル
Status of This 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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（C）The Internet Society（2006）。
Abstract
概要
The Secure Shell Protocol (SSH) is a protocol for secure remote login and other secure network services over an insecure network. This document describes the SSH authentication protocol framework and public key, password, and host-based client authentication methods. Additional authentication methods are described in separate documents. The SSH authentication protocol runs on top of the SSH transport layer protocol and provides a single authenticated tunnel for the SSH connection protocol.
セキュアシェルプロトコル（SSH）は、安全でないリモートログインおよびその他の安全なネットワークサービスを安全でないネットワーク上で行うためのプロトコルです。このドキュメントでは、SSH認証プロトコルフレームワークと公開鍵、パスワード、およびホストベースのクライアント認証方法について説明します。追加の認証方法は、別のドキュメントで説明されています。 SSH認証プロトコルは、SSHトランスポート層プロトコルの上で実行され、SSH接続プロトコルに単一の認証済みトンネルを提供します。
Table of Contents
目次
1. Introduction ....................................................2
2. Contributors ....................................................3
3. Conventions Used in This Document ...............................3
4. The Authentication Protocol Framework ...........................4
5. Authentication Requests .........................................4
5.1. Responses to Authentication Requests .......................5
5.2. The "none" Authentication Request ..........................7
5.3. Completion of User Authentication ..........................7
5.4. Banner Message .............................................7
6. Authentication Protocol Message Numbers .........................8
7. Public Key Authentication Method: "publickey" ...................8
8. Password Authentication Method: "password" .....................10
9. Host-Based Authentication: "hostbased" .........................12
10. IANA Considerations ...........................................14
11. Security Considerations .......................................14
12. References ....................................................15
12.1. Normative References .....................................15
12.2. Informative References ...................................15
Authors' Addresses ................................................16
Trademark Notice ..................................................16
The SSH authentication protocol is a general-purpose user authentication protocol. It is intended to be run over the SSH transport layer protocol [SSH-TRANS]. This protocol assumes that the underlying protocols provide integrity and confidentiality protection.
SSH認証プロトコルは、汎用のユーザー認証プロトコルです。これは、SSHトランスポート層プロトコル[SSH-TRANS]で実行することを目的としています。このプロトコルは、基礎となるプロトコルが整合性と機密保護を提供することを前提としています。
This document should be read only after reading the SSH architecture document [SSH-ARCH]. This document freely uses terminology and notation from the architecture document without reference or further explanation.
このドキュメントは、SSHアーキテクチャドキュメント[SSH-ARCH]を読んだ後にのみ読む必要があります。このドキュメントでは、アーキテクチャドキュメントの用語と表記を自由に使用し、参照や詳細な説明はありません。
The 'service name' for this protocol is "ssh-userauth".
このプロトコルの「サービス名」は「ssh-userauth」です。
When this protocol starts, it receives the session identifier from the lower-level protocol (this is the exchange hash H from the first key exchange). The session identifier uniquely identifies this session and is suitable for signing in order to prove ownership of a private key. This protocol also needs to know whether the lower-level protocol provides confidentiality protection.
このプロトコルが開始すると、下位レベルのプロトコルからセッション識別子を受け取ります（これは最初の鍵交換からの交換ハッシュHです）。セッション識別子はこのセッションを一意に識別し、秘密鍵の所有権を証明するための署名に適しています。このプロトコルは、下位レベルのプロトコルが機密保護を提供するかどうかも知る必要があります。
The major original contributors of this set of documents have been: Tatu Ylonen, Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH Communications Security Corp), and Markku-Juhani O. Saarinen (University of Jyvaskyla). Darren Moffat was the original editor of this set of documents and also made very substantial contributions.
このドキュメントセットの主要な元の貢献者は、Tatu Ylonen、Tero Kivinen、Timo J. Rinne、Sami Lehtinen（SSH Communications Security Corpのすべて）、およびMarkku-Juhani O. Saarinen（Jyvaskyla大学）です。ダレンモファットは、この一連のドキュメントの最初の編集者であり、非常に大きな貢献もしました。
Many people contributed to the development of this document over the years. People who should be acknowledged include Mats Andersson, Ben Harris, Bill Sommerfeld, Brent McClure, Niels Moller, Damien Miller, Derek Fawcus, Frank Cusack, Heikki Nousiainen, Jakob Schlyter, Jeff Van Dyke, Jeffrey Altman, Jeffrey Hutzelman, Jon Bright, Joseph Galbraith, Ken Hornstein, Markus Friedl, Martin Forssen, Nicolas Williams, Niels Provos, Perry Metzger, Peter Gutmann, Simon Josefsson, Simon Tatham, Wei Dai, Denis Bider, der Mouse, and Tadayoshi Kohno. Listing their names here does not mean that they endorse this document, but that they have contributed to it.
このドキュメントの開発には、長年にわたって多くの人々が貢献してくれました。認められるべき人には、マット・アンダーソン、ベン・ハリス、ビル・ソマーフェルト、ブレント・マクルーア、ニールス・モラー、ダミアン・ミラー、デレク・フォーカス、フランク・カザック、ヘイッキ・ノイシャイネン、ジェイコブ・シュリター、ジェフ・ヴァン・ダイク、ジェフリー・アルトマン、ジェフリー・ハッツェルマン、ジョン・ブライト、ジョセフガルブレイス、ケンホーンスタイン、マーカスフリードル、マーティンフォーセン、ニコラスウィリアムズ、ニールスプロボス、ペリーメッツガー、ピーターグトマン、サイモンジョセフソン、サイモンタサム、ウェイダイ、デニスビダー、マウス、デアマウス、河野忠義。ここに彼らの名前をリストすることは、彼らがこの文書を支持することを意味するのではなく、彼らがそれに貢献したことを意味します。
All documents related to the SSH protocols shall use the keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe requirements. These keywords are to be interpreted as described in [RFC2119].
SSHプロトコルに関連するすべてのドキュメントは、キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」を使用するものとします。要件を説明する「オプション」。これらのキーワードは、[RFC2119]で説明されているように解釈されます。
The keywords "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in this document when used to describe namespace allocation are to be interpreted as described in [RFC2434].
このドキュメントに表示されるキーワード「プライベート使用」、「階層割り当て」、「ファーストカムファーストサーブド」、「エキスパートレビュー」、「仕様が必要」、「IESG承認」、「IETFコンセンサス」、および「標準アクション」名前空間の割り当てを説明するために使用されるものは、[RFC2434]で説明されているように解釈されます。
Protocol fields and possible values to fill them are defined in this set of documents. Protocol fields will be defined in the message definitions. As an example, SSH_MSG_CHANNEL_DATA is defined as follows.
プロトコルフィールドと、フィールドに入力できる値は、この一連のドキュメントで定義されています。プロトコルフィールドはメッセージ定義で定義されます。例として、SSH_MSG_CHANNEL_DATAは次のように定義されます。
byte SSH_MSG_CHANNEL_DATA uint32 recipient channel string data
バイトSSH_MSG_CHANNEL_DATA uint32受信者チャネル文字列データ
Throughout these documents, when the fields are referenced, they will appear within single quotes. When values to fill those fields are referenced, they will appear within double quotes. Using the above example, possible values for 'data' are "foo" and "bar".
これらのドキュメント全体で、フィールドが参照されている場合、フィールドは一重引用符で囲まれています。それらのフィールドを満たす値が参照される場合、それらは二重引用符で囲まれて表示されます。上記の例を使用すると、「data」の可能な値は「foo」と「bar」です。
The server drives the authentication by telling the client which authentication methods can be used to continue the exchange at any given time. The client has the freedom to try the methods listed by the server in any order. This gives the server complete control over the authentication process if desired, but also gives enough flexibility for the client to use the methods it supports or that are most convenient for the user, when multiple methods are offered by the server.
サーバーは、いつでも交換を継続するために使用できる認証方法をクライアントに通知することにより、認証を駆動します。クライアントは、サーバーによってリストされたメソッドを任意の順序で試すことができます。これにより、サーバーは必要に応じて認証プロセスを完全に制御できますが、サーバーが複数のメソッドを提供している場合、クライアントがサポートするメソッドやユーザーにとって最も便利なメソッドをクライアントが使用するのに十分な柔軟性も提供します。
Authentication methods are identified by their name, as defined in [SSH-ARCH]. The "none" method is reserved, and MUST NOT be listed as supported. However, it MAY be sent by the client. The server MUST always reject this request, unless the client is to be granted access without any authentication, in which case, the server MUST accept this request. The main purpose of sending this request is to get the list of supported methods from the server.
認証方法は、[SSH-ARCH]で定義されているように、名前で識別されます。 「none」メソッドは予約されており、サポート対象としてリストされていてはなりません。ただし、クライアントによって送信される場合があります。クライアントが認証なしでアクセスを許可されない限り、サーバーは常にこの要求を拒否する必要があります。その場合、サーバーはこの要求を受け入れなければなりません（MUST）。このリクエストを送信する主な目的は、サポートされているメソッドのリストをサーバーから取得することです。
The server SHOULD have a timeout for authentication and disconnect if the authentication has not been accepted within the timeout period. The RECOMMENDED timeout period is 10 minutes. Additionally, the implementation SHOULD limit the number of failed authentication attempts a client may perform in a single session (the RECOMMENDED limit is 20 attempts). If the threshold is exceeded, the server SHOULD disconnect.
サーバーは認証のためのタイムアウトがあり、タイムアウト期間内に認証が受け入れられなかった場合は切断する必要があります（SHOULD）。推奨されるタイムアウト期間は10分です。さらに、実装では、クライアントが1つのセッションで実行できる認証試行の失敗回数を制限する必要があります（推奨制限は20回です）。しきい値を超えた場合、サーバーは切断する必要があります（SHOULD）。
Additional thoughts about authentication timeouts and retries may be found in [ssh-1.2.30].
認証のタイムアウトと再試行に関する追加の考えは、[ssh-1.2.30]にあります。
All authentication requests MUST use the following message format. Only the first few fields are defined; the remaining fields depend on the authentication method.
すべての認証要求は、次のメッセージ形式を使用する必要があります。最初の数フィールドのみが定義されています。残りのフィールドは認証方法によって異なります。
byte SSH_MSG_USERAUTH_REQUEST
string user name in ISO-10646 UTF-8 encoding [RFC3629]
string service name in US-ASCII
string method name in US-ASCII
.... method specific fields
The 'user name' and 'service name' are repeated in every new authentication attempt, and MAY change. The server implementation MUST carefully check them in every message, and MUST flush any accumulated authentication states if they change. If it is unable to flush an authentication state, it MUST disconnect if the 'user name' or 'service name' changes.
「ユーザー名」と「サービス名」は、新しい認証を試行するたびに繰り返され、変更される場合があります。サーバーの実装は、すべてのメッセージでそれらを注意深くチェックしなければならず、変更された場合、蓄積された認証状態をすべてフラッシュしなければなりません。認証状態をフラッシュできない場合、「ユーザー名」または「サービス名」が変更されたときに切断する必要があります。
The 'service name' specifies the service to start after authentication. There may be several different authenticated services provided. If the requested service is not available, the server MAY disconnect immediately or at any later time. Sending a proper disconnect message is RECOMMENDED. In any case, if the service does not exist, authentication MUST NOT be accepted.
「サービス名」は、認証後に開始するサービスを指定します。いくつかの異なる認証サービスが提供される場合があります。要求されたサービスが利用できない場合、サーバーはすぐにまたは後で切断することができます。適切な切断メッセージを送信することをお勧めします。いずれの場合でも、サービスが存在しない場合は、認証を受け入れてはなりません（MUST NOT）。
If the requested 'user name' does not exist, the server MAY disconnect, or MAY send a bogus list of acceptable authentication 'method name' values, but never accept any. This makes it possible for the server to avoid disclosing information on which accounts exist. In any case, if the 'user name' does not exist, the authentication request MUST NOT be accepted.
要求された「ユーザー名」が存在しない場合、サーバーは切断するか、または受け入れ可能な認証「メソッド名」値の偽のリストを送信してもかまいませんが、何も受け入れません。これにより、サーバーは、存在するアカウントに関する情報の開示を回避できます。いずれの場合でも、「ユーザー名」が存在しない場合、認証要求は受け入れられてはいけません。
While there is usually little point for clients to send requests that the server does not list as acceptable, sending such requests is not an error, and the server SHOULD simply reject requests that it does not recognize.
通常、クライアントがサーバーが受け入れ可能としてリストしていない要求を送信することはほとんどありませんが、そのような要求の送信はエラーではなく、サーバーは、認識できない要求を単に拒否する必要があります（SHOULD）。
An authentication request MAY result in a further exchange of messages. All such messages depend on the authentication 'method name' used, and the client MAY at any time continue with a new SSH_MSG_USERAUTH_REQUEST message, in which case the server MUST abandon the previous authentication attempt and continue with the new one.
認証要求は、メッセージのさらなる交換をもたらすかもしれません。そのようなすべてのメッセージは、使用される認証「メソッド名」に依存し、クライアントはいつでも新しいSSH_MSG_USERAUTH_REQUESTメッセージを続行できます。その場合、サーバーは前の認証試行を放棄して新しいものを続行する必要があります。
The following 'method name' values are defined.
以下の「メソッド名」の値が定義されています。
"publickey" REQUIRED "password" OPTIONAL "hostbased" OPTIONAL "none" NOT RECOMMENDED
"publickey"必須 "password"オプション "hostbased"オプション "none"非推奨
Additional 'method name' values may be defined as specified in [SSH-ARCH] and [SSH-NUMBERS].
[SSH-ARCH]および[SSH-NUMBERS]で指定されているように、追加の「メソッド名」の値を定義できます。
If the server rejects the authentication request, it MUST respond with the following:
サーバーが認証要求を拒否した場合、サーバーは次のように応答する必要があります。
byte SSH_MSG_USERAUTH_FAILURE name-list authentications that can continue boolean partial success
ブールの部分的な成功を継続できるバイトSSH_MSG_USERAUTH_FAILURE名前リスト認証
The 'authentications that can continue' is a comma-separated name-list of authentication 'method name' values that may productively continue the authentication dialog.
「続行できる認証」は、認証ダイアログを継続的に続行できる認証「メソッド名」の値のコンマ区切りの名前リストです。
It is RECOMMENDED that servers only include those 'method name' values in the name-list that are actually useful. However, it is not illegal to include 'method name' values that cannot be used to authenticate the user.
サーバーは、実際に役立つ名前リストに「メソッド名」の値のみを含めることをお勧めします。ただし、ユーザーの認証に使用できない「メソッド名」の値を含めることは違法ではありません。
Already successfully completed authentications SHOULD NOT be included in the name-list, unless they should be performed again for some reason.
何らかの理由で再度実行する必要がない限り、すでに正常に完了した認証は名前リストに含めるべきではありません（SHOULD NOT）。
The value of 'partial success' MUST be TRUE if the authentication request to which this is a response was successful. It MUST be FALSE if the request was not successfully processed.
これが応答である認証要求が成功した場合、「部分的な成功」の値はTRUEでなければなりません。リクエストが正常に処理されなかった場合は、FALSEでなければなりません。
When the server accepts authentication, it MUST respond with the following:
サーバーが認証を受け入れると、サーバーは次のように応答する必要があります。
byte SSH_MSG_USERAUTH_SUCCESS
バイトSSH_MSG_USERAUTH_SUCCESS
Note that this is not sent after each step in a multi-method authentication sequence, but only when the authentication is complete.
これはマルチメソッド認証シーケンスの各ステップの後に送信されるのではなく、認証が完了したときにのみ送信されることに注意してください。
The client MAY send several authentication requests without waiting for responses from previous requests. The server MUST process each request completely and acknowledge any failed requests with a SSH_MSG_USERAUTH_FAILURE message before processing the next request.
クライアントは、以前のリクエストからの応答を待たずに、いくつかの認証リクエストを送信できます（MAY）。サーバーは各リクエストを完全に処理し、次のリクエストを処理する前にSSH_MSG_USERAUTH_FAILUREメッセージで失敗したリクエストを確認する必要があります。
A request that requires further messages to be exchanged will be aborted by a subsequent request. A client MUST NOT send a subsequent request if it has not received a response from the server for a previous request. A SSH_MSG_USERAUTH_FAILURE message MUST NOT be sent for an aborted method.
さらにメッセージを交換する必要がある要求は、後続の要求によって中止されます。前のリクエストに対するサーバーからの応答を受け取っていない場合、クライアントは後続のリクエストを送信してはなりません（MUST NOT）。打ち切られたメソッドに対してSSH_MSG_USERAUTH_FAILUREメッセージを送信してはなりません（MUST NOT）。
SSH_MSG_USERAUTH_SUCCESS MUST be sent only once. When SSH_MSG_USERAUTH_SUCCESS has been sent, any further authentication requests received after that SHOULD be silently ignored.
SSH_MSG_USERAUTH_SUCCESSは1回だけ送信する必要があります。 SSH_MSG_USERAUTH_SUCCESSが送信された後、それ以降に受信された認証要求は、黙って無視されるべきです（SHOULD）。
Any non-authentication messages sent by the client after the request that resulted in SSH_MSG_USERAUTH_SUCCESS being sent MUST be passed to the service being run on top of this protocol. Such messages can be identified by their message numbers (see Section 6).
SSH_MSG_USERAUTH_SUCCESSが送信される結果となった要求の後にクライアントによって送信された非認証メッセージは、このプロトコル上で実行されているサービスに渡される必要があります。このようなメッセージは、メッセージ番号で識別できます（セクション6を参照）。
A client may request a list of authentication 'method name' values that may continue by using the "none" authentication 'method name'.
クライアントは、「なし」の認証「メソッド名」を使用して続行できる認証「メソッド名」値のリストを要求できます。
If no authentication is needed for the user, the server MUST return SSH_MSG_USERAUTH_SUCCESS. Otherwise, the server MUST return SSH_MSG_USERAUTH_FAILURE and MAY return with it a list of methods that may continue in its 'authentications that can continue' value.
ユーザーの認証が不要な場合、サーバーはSSH_MSG_USERAUTH_SUCCESSを返す必要があります。それ以外の場合、サーバーはSSH_MSG_USERAUTH_FAILUREを返さなければならず（MUST）、その「継続可能な認証」の値で続行できるメソッドのリストを返す場合があります（MAY）。
This 'method name' MUST NOT be listed as supported by the server.
この「メソッド名」は、サーバーでサポートされているものとしてリストされていてはなりません。
Authentication is complete when the server has responded with SSH_MSG_USERAUTH_SUCCESS. All authentication related messages received after sending this message SHOULD be silently ignored.
サーバーがSSH_MSG_USERAUTH_SUCCESSで応答すると、認証が完了します。このメッセージを送信した後に受信したすべての認証関連のメッセージは、黙って無視されるべきです（SHOULD）。
After sending SSH_MSG_USERAUTH_SUCCESS, the server starts the requested service.
SSH_MSG_USERAUTH_SUCCESSを送信した後、サーバーは要求されたサービスを開始します。
In some jurisdictions, sending a warning message before authentication may be relevant for getting legal protection. Many UNIX machines, for example, normally display text from /etc/issue, use TCP wrappers, or similar software to display a banner before issuing a login prompt.
一部の管轄区域では、認証の前に警告メッセージを送信することが法的保護を取得するために適切である場合があります。たとえば、多くのUNIXマシンは通常、/ etc / issueからのテキストを表示し、TCPラッパーまたは同様のソフトウェアを使用して、ログインプロンプトを発行する前にバナーを表示します。
The SSH server may send an SSH_MSG_USERAUTH_BANNER message at any time after this authentication protocol starts and before authentication is successful. This message contains text to be displayed to the client user before authentication is attempted. The format is as follows:
SSHサーバーは、この認証プロトコルが開始してから認証が成功するまでの間、いつでもSSH_MSG_USERAUTH_BANNERメッセージを送信できます。このメッセージには、認証が試行される前にクライアントユーザーに表示されるテキストが含まれています。形式は次のとおりです。
byte SSH_MSG_USERAUTH_BANNER string message in ISO-10646 UTF-8 encoding [RFC3629] string language tag [RFC3066]
ISO-10646 UTF-8エンコーディングのバイトSSH_MSG_USERAUTH_BANNER文字列メッセージ[RFC3629]文字列言語タグ[RFC3066]
By default, the client SHOULD display the 'message' on the screen. However, since the 'message' is likely to be sent for every login attempt, and since some client software will need to open a separate window for this warning, the client software may allow the user to explicitly disable the display of banners from the server. The 'message' may consist of multiple lines, with line breaks indicated by CRLF pairs.
デフォルトでは、クライアントは画面に「メッセージ」を表示する必要があります（SHOULD）。ただし、「メッセージ」はログインのたびに送信される可能性が高く、一部のクライアントソフトウェアではこの警告のために別のウィンドウを開く必要があるため、クライアントソフトウェアはユーザーがサーバーからのバナーの表示を明示的に無効にすることを許可する場合があります。 「メッセージ」は複数行で構成され、CRLFペアで改行が示されます。
If the 'message' string is displayed, control character filtering, discussed in [SSH-ARCH], SHOULD be used to avoid attacks by sending terminal control characters.
「メッセージ」文字列が表示される場合は、[SSH-ARCH]で説明されている制御文字フィルタリングを使用して、端末制御文字を送信することにより攻撃を回避する必要があります（SHOULD）。
All message numbers used by this authentication protocol are in the range from 50 to 79, which is part of the range reserved for protocols running on top of the SSH transport layer protocol.
この認証プロトコルで使用されるすべてのメッセージ番号は、50〜79の範囲にあります。これは、SSHトランスポート層プロトコル上で実行されるプロトコル用に予約された範囲の一部です。
Message numbers of 80 and higher are reserved for protocols running after this authentication protocol, so receiving one of them before authentication is complete is an error, to which the server MUST respond by disconnecting, preferably with a proper disconnect message sent to ease troubleshooting.
80以上のメッセージ番号は、この認証プロトコルの後に実行されるプロトコル用に予約されているため、認証が完了する前にそれらのいずれかを受信するとエラーが発生し、サーバーは切断して応答する必要があります。
After successful authentication, such messages are passed to the higher-level service.
認証に成功すると、そのようなメッセージは上位レベルのサービスに渡されます。
These are the general authentication message codes:
これらは、一般的な認証メッセージコードです。
SSH_MSG_USERAUTH_REQUEST 50 SSH_MSG_USERAUTH_FAILURE 51 SSH_MSG_USERAUTH_SUCCESS 52 SSH_MSG_USERAUTH_BANNER 53
SSH_MSG_USERAUTH_REQUEST 50 SSH_MSG_USERAUTH_FAILURE 51 SSH_MSG_USERAUTH_SUCCESS 52 SSH_MSG_USERAUTH_BANNER 53
In addition to the above, there is a range of message numbers (60 to 79) reserved for method-specific messages. These messages are only sent by the server (client sends only SSH_MSG_USERAUTH_REQUEST messages). Different authentication methods reuse the same message numbers.
上記に加えて、メソッド固有のメッセージ用に予約されているメッセージ番号の範囲（60から79）があります。これらのメッセージはサーバーによってのみ送信されます（クライアントはSSH_MSG_USERAUTH_REQUESTメッセージのみを送信します）。異なる認証方法は同じメッセージ番号を再利用します。
The only REQUIRED authentication 'method name' is "publickey" authentication. All implementations MUST support this method; however, not all users need to have public keys, and most local policies are not likely to require public key authentication for all users in the near future.
唯一必要な認証「メソッド名」は「公開鍵」認証です。すべての実装でこのメソッドをサポートする必要があります。ただし、すべてのユーザーが公開キーを持つ必要があるわけではなく、ほとんどのローカルポリシーでは、近い将来、すべてのユーザーに対して公開キー認証を要求することはほとんどありません。
With this method, the possession of a private key serves as authentication. This method works by sending a signature created with a private key of the user. The server MUST check that the key is a valid authenticator for the user, and MUST check that the signature is valid. If both hold, the authentication request MUST be accepted; otherwise, it MUST be rejected. Note that the server MAY require additional authentications after successful authentication.
この方法では、秘密鍵の所有が認証として機能します。この方法は、ユーザーの秘密鍵で作成された署名を送信することで機能します。サーバーは、キーがユーザーの有効なオーセンティケーターであることを確認する必要があり、署名が有効であることを確認する必要があります。両方が成立する場合、認証要求を受け入れる必要があります。それ以外の場合は、拒否する必要があります。認証に成功した後、サーバーは追加の認証を要求する場合があることに注意してください。
Private keys are often stored in an encrypted form at the client host, and the user must supply a passphrase before the signature can be generated. Even if they are not, the signing operation involves some expensive computation. To avoid unnecessary processing and user interaction, the following message is provided for querying whether authentication using the "publickey" method would be acceptable.
秘密鍵は多くの場合、クライアントホストで暗号化された形式で保存され、ユーザーは署名を生成する前にパスフレーズを入力する必要があります。そうでない場合でも、署名操作にはいくつかの高価な計算が含まれます。不要な処理とユーザーの操作を回避するために、「公開鍵」方式を使用した認証が受け入れられるかどうかを問い合わせる次のメッセージが提供されます。
byte SSH_MSG_USERAUTH_REQUEST string user name in ISO-10646 UTF-8 encoding [RFC3629] string service name in US-ASCII string "publickey" boolean FALSE string public key algorithm name string public key blob
バイトSSH_MSG_USERAUTH_REQUEST文字列ISO-10646 UTF-8エンコードのユーザー名[RFC3629]文字列US-ASCII文字列 "publickey"ブールFALSE文字列公開鍵アルゴリズム名文字列公開鍵blob
Public key algorithms are defined in the transport layer specification [SSH-TRANS]. The 'public key blob' may contain certificates.
公開鍵アルゴリズムは、トランスポート層仕様[SSH-TRANS]で定義されています。 「公開鍵blob」には証明書が含まれる場合があります。
Any public key algorithm may be offered for use in authentication. In particular, the list is not constrained by what was negotiated during key exchange. If the server does not support some algorithm, it MUST simply reject the request.
認証に使用するために、任意の公開鍵アルゴリズムを提供できます。特に、このリストは、鍵交換中に交渉されたものによって制約されません。サーバーが何らかのアルゴリズムをサポートしていない場合は、単に要求を拒否する必要があります。
The server MUST respond to this message with either SSH_MSG_USERAUTH_FAILURE or with the following:
サーバーは、SSH_MSG_USERAUTH_FAILUREまたは次のいずれかでこのメッセージに応答する必要があります。
byte SSH_MSG_USERAUTH_PK_OK string public key algorithm name from the request string public key blob from the request
バイトSSH_MSG_USERAUTH_PK_OK文字列リクエストの公開鍵アルゴリズム名文字列リクエストの公開鍵blob
To perform actual authentication, the client MAY then send a signature generated using the private key. The client MAY send the signature directly without first verifying whether the key is acceptable. The signature is sent using the following packet:
実際の認証を実行するために、クライアントは秘密鍵を使用して生成された署名を送信してもよい（MAY）。クライアントは、最初にキーが受け入れ可能かどうかを確認せずに、署名を直接送信する場合があります。署名は次のパケットを使用して送信されます。
byte SSH_MSG_USERAUTH_REQUEST string user name string service name string "publickey" boolean TRUE string public key algorithm name string public key to be used for authentication string signature
バイトSSH_MSG_USERAUTH_REQUEST文字列ユーザー名文字列サービス名文字列 "publickey"ブール値TRUE文字列公開鍵アルゴリズム名文字列認証文字列の署名に使用される公開鍵
The value of 'signature' is a signature by the corresponding private key over the following data, in the following order:
「signature」の値は、次のデータに対する次の順序での、対応する秘密鍵による署名です。
string session identifier byte SSH_MSG_USERAUTH_REQUEST string user name string service name string "publickey" boolean TRUE string public key algorithm name string public key to be used for authentication
文字列セッション識別子バイトSSH_MSG_USERAUTH_REQUEST文字列ユーザー名文字列サービス名文字列 "publickey"ブール値TRUE文字列公開鍵アルゴリズム名文字列認証に使用される公開鍵
When the server receives this message, it MUST check whether the supplied key is acceptable for authentication, and if so, it MUST check whether the signature is correct.
サーバーはこのメッセージを受信すると、提供されたキーが認証に受け入れられるかどうかをチェックする必要があり、受け入れ可能な場合は、署名が正しいかどうかをチェックする必要があります。
If both checks succeed, this method is successful. Note that the server may require additional authentications. The server MUST respond with SSH_MSG_USERAUTH_SUCCESS (if no more authentications are needed), or SSH_MSG_USERAUTH_FAILURE (if the request failed, or more authentications are needed).
両方のチェックが成功した場合、このメソッドは成功します。サーバーでは追加の認証が必要になる場合があることに注意してください。サーバーは、SSH_MSG_USERAUTH_SUCCESS（認証が不要な場合）、またはSSH_MSG_USERAUTH_FAILURE（要求が失敗した場合、またはより多くの認証が必要な場合）で応答する必要があります。
The following method-specific message numbers are used by the "publickey" authentication method.
次のメソッド固有のメッセージ番号は、「公開鍵」認証メソッドで使用されます。
SSH_MSG_USERAUTH_PK_OK 60
SSH_MSG_USERAUTH_PK_OK 60
Password authentication uses the following packets. Note that a server MAY request that a user change the password. All implementations SHOULD support password authentication.
パスワード認証は以下のパケットを使用します。サーバーはユーザーがパスワードを変更することを要求してもよいことに注意してください。すべての実装はパスワード認証をサポートする必要があります（SHOULD）。
byte SSH_MSG_USERAUTH_REQUEST string user name string service name string "password" boolean FALSE string plaintext password in ISO-10646 UTF-8 encoding [RFC3629]
バイトSSH_MSG_USERAUTH_REQUEST文字列ユーザー名文字列サービス名文字列 "password"ブールFALSE文字列ISO-10646 UTF-8エンコードのプレーンテキストパスワード[RFC3629]
Note that the 'plaintext password' value is encoded in ISO-10646 UTF-8. It is up to the server how to interpret the password and validate it against the password database. However, if the client reads the password in some other encoding (e.g., ISO 8859-1 - ISO Latin1), it MUST convert the password to ISO-10646 UTF-8 before transmitting, and the server MUST convert the password to the encoding used on that system for passwords.
「平文パスワード」の値はISO-10646 UTF-8でエンコードされていることに注意してください。パスワードをどのように解釈し、パスワードデータベースと照合して検証するかは、サーバー次第です。ただし、クライアントが他のエンコーディング（ISO 8859-1-ISO Latin1など）でパスワードを読み取る場合、送信前にパスワードをISO-10646 UTF-8に変換する必要があり、サーバーは使用するエンコーディングにパスワードを変換する必要があります。そのシステムのパスワード。
From an internationalization standpoint, it is desired that if a user enters their password, the authentication process will work regardless of what OS and client software the user is using. Doing so requires normalization. Systems supporting non-ASCII passwords SHOULD always normalize passwords and user names whenever they are added to the database, or compared (with or without hashing) to existing entries in the database. SSH implementations that both store the passwords and compare them SHOULD use [RFC4013] for normalization.
国際化の観点からは、ユーザーが自分のパスワードを入力した場合、ユーザーが使用しているOSおよびクライアントソフトウェアに関係なく、認証プロセスが機能することが望まれます。そのためには正規化が必要です。非ASCIIパスワードをサポートするシステムは、パスワードとユーザー名がデータベースに追加されるか、またはデータベース内の既存のエントリと（ハッシュありまたはなしで）比較される場合は常に、パスワードとユーザー名を常に正規化する必要があります。パスワードの保存と比較の両方を行うSSH実装は、正規化に[RFC4013]を使用する必要があります（SHOULD）。
Note that even though the cleartext password is transmitted in the packet, the entire packet is encrypted by the transport layer. Both the server and the client should check whether the underlying transport layer provides confidentiality (i.e., if encryption is being used). If no confidentiality is provided ("none" cipher), password authentication SHOULD be disabled. If there is no confidentiality or no MAC, password change SHOULD be disabled.
クリアテキストのパスワードがパケットで送信されても、パケット全体がトランスポート層によって暗号化されることに注意してください。サーバーとクライアントの両方で、基になるトランスポート層が機密性を提供するかどうかを確認する必要があります（つまり、暗号化が使用されている場合）。機密性が提供されない場合（ "none"暗号）、パスワード認証を無効にする必要があります（SHOULD）。機密性またはMACがない場合は、パスワード変更を無効にする必要があります（SHOULD）。
Normally, the server responds to this message with success or failure. However, if the password has expired, the server SHOULD indicate this by responding with SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. In any case, the server MUST NOT allow an expired password to be used for authentication.
通常、サーバーはこのメッセージに成功または失敗で応答します。ただし、パスワードの有効期限が切れている場合、サーバーはSSH_MSG_USERAUTH_PASSWD_CHANGEREQで応答することによってこれを示す必要があります（SHOULD）。いずれの場合も、サーバーは、有効期限が切れたパスワードを認証に使用することを許可してはなりません。
byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ string prompt in ISO-10646 UTF-8 encoding [RFC3629] string language tag [RFC3066]
ISO-10646 UTF-8エンコーディングのバイトSSH_MSG_USERAUTH_PASSWD_CHANGEREQ文字列プロンプト[RFC3629]文字列言語タグ[RFC3066]
In this case, the client MAY continue with a different authentication method, or request a new password from the user and retry password authentication using the following message. The client MAY also send this message instead of the normal password authentication request without the server asking for it.
この場合、クライアントは別の認証方法を続行するか、ユーザーに新しいパスワードを要求して、次のメッセージを使用してパスワード認証を再試行する場合があります。クライアントは通常のパスワード認証要求の代わりにこのメッセージを送信してもよく（MAY）、サーバーは要求しません。
byte SSH_MSG_USERAUTH_REQUEST string user name string service name string "password" boolean TRUE string plaintext old password in ISO-10646 UTF-8 encoding [RFC3629] string plaintext new password in ISO-10646 UTF-8 encoding [RFC3629]
バイトSSH_MSG_USERAUTH_REQUEST文字列ユーザー名文字列サービス名文字列 "password"ブール値TRUE文字列プレーンテキストISO-10646 UTF-8エンコードの古いパスワード[RFC3629]文字列ISO-10646 UTF-8エンコードのプレーンテキスト新しいパスワード[RFC3629]
The server must reply to each request message with SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another SSH_MSG_USERAUTH_PASSWD_CHANGEREQ. The meaning of these is as follows:
サーバーは、SSH_MSG_USERAUTH_SUCCESS、SSH_MSG_USERAUTH_FAILURE、または別のSSH_MSG_USERAUTH_PASSWD_CHANGEREQを使用して、各要求メッセージに応答する必要があります。これらの意味は次のとおりです。
SSH_MSG_USERAUTH_SUCCESS - The password has been changed, and authentication has been successfully completed.
SSH_MSG_USERAUTH_SUCCESS-パスワードが変更され、認証が正常に完了しました。
SSH_MSG_USERAUTH_FAILURE with partial success - The password has been changed, but more authentications are needed.
SSH_MSG_USERAUTH_FAILURE（一部成功）-パスワードは変更されましたが、さらに認証が必要です。
SSH_MSG_USERAUTH_FAILURE without partial success - The password has not been changed. Either password changing was not supported, or the old password was bad. Note that if the server has already sent SSH_MSG_USERAUTH_PASSWD_CHANGEREQ, we know that it supports changing the password.
SSH_MSG_USERAUTH_FAILURE（部分的な成功なし）-パスワードは変更されていません。パスワードの変更がサポートされていなかったか、古いパスワードが不適切でした。サーバーがすでにSSH_MSG_USERAUTH_PASSWD_CHANGEREQを送信している場合は、パスワードの変更がサポートされていることがわかります。
SSH_MSG_USERAUTH_CHANGEREQ - The password was not changed because the new password was not acceptable (e.g., too easy to guess).
SSH_MSG_USERAUTH_CHANGEREQ-新しいパスワードが受け入れられなかった（たとえば、簡単に推測できる）ため、パスワードは変更されませんでした。
The following method-specific message numbers are used by the password authentication method.
次のメソッド固有のメッセージ番号は、パスワード認証メソッドで使用されます。
SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 60
SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 60
Some sites wish to allow authentication based on the host that the user is coming from and the user name on the remote host. While this form of authentication is not suitable for high-security sites, it can be very convenient in many environments. This form of authentication is OPTIONAL. When used, special care SHOULD be taken to prevent a regular user from obtaining the private host key.
一部のサイトでは、ユーザーの送信元のホストとリモートホストのユーザー名に基づいて認証を許可したいと考えています。この認証形式はセキュリティの高いサイトには適していませんが、多くの環境で非常に便利です。この認証形式はオプションです。使用する場合、通常のユーザーがプライベートホストキーを取得できないように特別な注意を払う必要があります。
The client requests this form of authentication by sending the following message. It is similar to the UNIX "rhosts" and "hosts.equiv" styles of authentication, except that the identity of the client host is checked more rigorously.
クライアントは、次のメッセージを送信して、この形式の認証を要求します。これは、クライアントのホストのIDがより厳密にチェックされることを除いて、UNIXの「rhosts」および「hosts.equiv」スタイルの認証に似ています。
This method works by having the client send a signature created with the private key of the client host, which the server checks with that host's public key. Once the client host's identity is established, authorization (but no further authentication) is performed based on the user names on the server and the client, and the client host name.
この方法は、クライアントがクライアントホストの秘密キーで作成された署名を送信するように働き、サーバーはそのホストの公開キーでチェックします。クライアントホストのIDが確立されると、サーバーとクライアントのユーザー名、およびクライアントホスト名に基づいて承認（ただし、それ以上の認証は行われません）が実行されます。
byte SSH_MSG_USERAUTH_REQUEST string user name string service name string "hostbased" string public key algorithm for host key string public host key and certificates for client host string client host name expressed as the FQDN in US-ASCII string user name on the client host in ISO-10646 UTF-8 encoding [RFC3629] string signature
バイトSSH_MSG_USERAUTH_REQUEST文字列ユーザー名文字列サービス名文字列 "ホストベース"文字列ホスト鍵の公開鍵アルゴリズム文字列公開ホスト鍵およびクライアントホスト文字列の証明書US-ASCIIのFQDNとして表されるクライアントホスト名ISO-のクライアントホストのユーザー名10646 UTF-8エンコード[RFC3629]文字列署名
Public key algorithm names for use in 'public key algorithm for host key' are defined in the transport layer specification [SSH-TRANS]. The 'public host key and certificates for client host' may include certificates.
「ホスト鍵の公開鍵アルゴリズム」で使用する公開鍵アルゴリズム名は、トランスポート層仕様[SSH-TRANS]で定義されています。 「クライアントホストの公開ホストキーと証明書」には、証明書が含まれる場合があります。
The value of 'signature' is a signature with the private host key of the following data, in this order:
「signature」の値は、次のデータのプライベートホストキーをこの順序で使用した署名です。
string session identifier byte SSH_MSG_USERAUTH_REQUEST string user name string service name string "hostbased" string public key algorithm for host key string public host key and certificates for client host string client host name expressed as the FQDN in US-ASCII string user name on the client host in ISO-10646 UTF-8 encoding [RFC3629]
文字列セッション識別子バイトSSH_MSG_USERAUTH_REQUEST文字列ユーザー名文字列サービス名文字列 "ホストベース"文字列ホスト鍵の公開鍵アルゴリズム文字列公開ホスト鍵とクライアントホストの証明書文字列クライアントホスト名US-ASCIIのFQDNとして表されるクライアントホスト名文字列ISO-10646 UTF-8エンコーディング[RFC3629]
The server MUST verify that the host key actually belongs to the client host named in the message, that the given user on that host is allowed to log in, and that the 'signature' value is a valid signature on the appropriate value by the given host key. The server MAY ignore the client 'user name', if it wants to authenticate only the client host.
サーバーは、ホストキーがメッセージで指定されたクライアントホストに実際に属していること、そのホストの指定されたユーザーがログインを許可されていること、および「署名」値が指定された適切な値の有効な署名であることを確認する必要がありますホストキー。サーバーは、クライアントホストのみを認証したい場合、クライアントの「ユーザー名」を無視してもよい（MAY）。
Whenever possible, it is RECOMMENDED that the server perform additional checks to verify that the network address obtained from the (untrusted) network matches the given client host name. This makes exploiting compromised host keys more difficult. Note that this may require special handling for connections coming through a firewall.
可能な限り、サーバーが追加のチェックを実行して、（信頼されていない）ネットワークから取得したネットワークアドレスが指定のクライアントホスト名と一致することを確認することをお勧めします。これにより、侵害されたホストキーの悪用がより困難になります。これには、ファイアウォールを通過する接続に対して特別な処理が必要になる場合があることに注意してください。
This document is part of a set. The IANA considerations for the SSH protocol, as defined in [SSH-ARCH], [SSH-TRANS], [SSH-CONNECT], and this document, are detailed in [SSH-NUMBERS].
このドキュメントはセットの一部です。 [SSH-ARCH]、[SSH-TRANS]、[SSH-CONNECT]、およびこのドキュメントで定義されている、SSHプロトコルに関するIANAの考慮事項は、[SSH-NUMBERS]で詳しく説明されています。
The purpose of this protocol is to perform client user authentication. It assumed that this runs over a secure transport layer protocol, which has already authenticated the server machine, established an encrypted communications channel, and computed a unique session identifier for this session. The transport layer provides forward secrecy for password authentication and other methods that rely on secret data.
このプロトコルの目的は、クライアントのユーザー認証を実行することです。これは、サーバーマシンを既に認証し、暗号化された通信チャネルを確立し、このセッションの一意のセッション識別子を計算した、セキュアなトランスポート層プロトコル上で実行されることを想定しています。トランスポート層は、パスワード認証や、秘密データに依存するその他の方法に前方機密を提供します。
Full security considerations for this protocol are provided in [SSH-ARCH].
このプロトコルの完全なセキュリティの考慮事項は、[SSH-ARCH]で提供されています。
[SSH-ARCH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[SSH-ARCH] Ylonen、T。およびC. Lonvick、編、「The Secure Shell（SSH）Protocol Architecture」、RFC 4251、2006年1月。
[SSH-CONNECT] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Connection Protocol", RFC 4254, January 2006.
[SSH-CONNECT] Ylonen、T。およびC. Lonvick、編、「The Secure Shell（SSH）Connection Protocol」、RFC 4254、2006年1月。
[SSH-TRANS] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.
[SSH-TRANS] Ylonen、T。およびC. Lonvick、編、「The Secure Shell（SSH）Transport Layer Protocol」、RFC 4253、2006年1月。
[SSH-NUMBERS] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006.
[SSH-NUMBERS] Lehtinen、S。およびC. Lonvick、編、「Secure Shell（SSH）Protocol Assigned Numbers」、RFC 4250、2006年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[RFC3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[RFC3066] Alvestrand、H。、「言語の識別のためのタグ」、BCP 47、RFC 3066、2001年1月。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、2003年11月。
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[RFC4013] Zeilenga、K。、「SASLprep：Stringprep Profile for User Names and Passwords」、RFC 4013、2005年2月。
[ssh-1.2.30] Ylonen, T., "ssh-1.2.30/RFC", File within compressed tarball ftp://ftp.funet.fi/pub/unix/security/login/ ssh/ssh-1.2.30.tar.gz, November 1995.
[ssh-1.2.30] Ylonen、T。、「ssh-1.2.30 / RFC」、圧縮tarball内のファイルftp://ftp.funet.fi/pub/unix/security/login/ ssh / ssh-1.2。 30.tar.gz、1995年11月。
Authors' Addresses
著者のアドレス
Tatu Ylonen SSH Communications Security Corp Valimotie 17 00380 Helsinki Finland
Tatu Ylonen SSH Communications Security Corp Valimotie 17 00380 Helsinkiフィンランド
EMail: ylo@ssh.com
Chris Lonvick (editor) Cisco Systems, Inc. 12515 Research Blvd. Austin 78759 USA
Chris Lonvick（編集者）Cisco Systems、Inc. 12515 Research Blvd.オースティン78759アメリカ
EMail: clonvick@cisco.com
Trademark Notice
商標に関する通知
"ssh" is a registered trademark in the United States and/or other countries.
「ssh」は、米国およびその他の国における登録商標です。
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2006).
Copyright（C）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントは、BCP 78に含まれる権利、ライセンス、および制限の対象であり、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または（もしあれば）組織、インターネットエンジニアリングおよびインターネットエンジニアリングタスクフォースは、すべての保証を明示的または明示的に提供します。ここに含まれる情報の使用により、商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害されないという保証を含みますが、これに限定されるものではありません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。
Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に対して行われたIPR開示のコピー、および利用可能になるライセンスの保証、または一般ライセンスを取得しようとした試み、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得した結果を取得できます。 http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポート活動（IASA）によって提供されます。