Network Working Group F. Cusack INTERNET-DRAFT Google, Inc. Expires November 1, 2003 M. Forssen Appgate AB May 1, 2003 # 訳者 春山征吾 haruyama@unixuser.org Generic Message Exchange Authentication For SSH Status of this Memo This document is an Internet-Draft and is subject to 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 . The list of Internet-Draft Shadow Directories can be accessed at . This Internet-Draft will expire on November 1, 2003. Abstract 概要 SSH is a protocol for secure remote login and other secure network services over an insecure network. This document describes a general purpose authentication method for the SSH protocol, suitable for interactive authentications where the authentication data should be entered via a keyboard. The major goal of this method is to allow the SSH client to support a whole class of authentication mechanism(s) without knowing the specifics of the actual authentication mechanism(s). SSH は安全でないネットワ-ク越しの安全なリモ-トログインと 他の安全なネットワ-クサ-ビスのためにプロトコルだ. この文書では, 認証デ-タがキ-ボ-ドを使って入力される インタラクティブ認証に適した, SSH プロトコルのための多目的の認証法を記述する. この方法の主要な目的は, 実際の認証メカニズムの詳細を知ることなしに 認証メカニズムの全体を SSH クライアントがサポ-トすることを 許すことだ. F. Cusack, M. Forssen Expires November 1, 2003 [Page 1] Internet Draft SSH Generic Interactive Authentication May 1, 2003 1. Introduction 1. イントロダクション The SSH authentication protocol [SSH-USERAUTH] is a general-purpose user authentication protocol. It is intended to be run over the SSH transport layer protocol [SSH-TRANS]. The authentication protocol assumes that the underlying protocols provide integrity and confidentiality protection. SSH 認証プロトコル [SSH-USERAUTH] は 多目的のユ-ザ認証プロトコルだ. これは, SSH トランスポ-ト層プロトコル [SSH-TRANS] の上で動くことが 意図されている. 認証プロトコルは, 下にあるプロトコルが完全性と 秘密性の保護を提供することを仮定している. This document describes a general purpose authentication method for the SSH authentication protocol. This method is suitable for interactive authentication methods which do not need any special software support on the client side. Instead all authentication data should be entered via the keyboard. The major goal of this method is to allow the SSH client to have little or no knowledge of the specifics of the underlying authentication mechanism(s) used by the SSH server. This will allow the server to arbitrarily select or change the underlying authentication mechanism(s) without having to update client code. この文書では, SSH 認証プロトコルに対する 1 つの多目的な認証法を 述べる. この方法は, クライアント側でなにか特別なソフトウェアのサポ-ト をする必要がないインタラクティブな認証法に適している. 代わりに, すべての認証デ-タはキ-ボ-ドによって入力される. この方法の主要な目的は, SSH サ-バで使う 基礎となる認証メカニズムの 詳細を SSH のクライアントがほとんどないしまったく知らないようにすることである. これは, クライアントのコ-ドを更新する必要なしに 基礎となる 認証メカニズムを任意に選択したり変更することをサ-バに許す. The name for this authentication method is "keyboard-interactive". この認証法の名前は "keyboard-interactive" だ. This document should be read only after reading the SSH architecture document [SSH-ARCH] and the SSH authentication document [SSH-USERAUTH]. This document freely uses terminology and notation from both documents without reference or further explanation. この文書は SSH ア-キテクチャ文書 [SSH-ARCH] と SSH 認証文書 [SSH-USERAUTH] を読んだあとでのみ読まれるべきだ. この文書は, 参照やさらなる説明なしにこの 2 つの文書からの 用語や表記法を自由に使う. This document also describes some of the client interaction with the user in obtaining the authentication information. While this is somewhat out of the scope of a protocol specification, it is described here anyway since some aspects of the protocol are specifically designed based on user interface issues, and omitting this information may lead to incompatible or awkward implementations. この文書では, 認証情報を得るためのユ-ザによるいくつかのクライアントの やりとりについても記述する. これはプロトコル仕様の範囲のいくぶん 外にあるが, このプロトコルはある面としてユ-ザインタフェイスの問題に 基づいて特に設計されていて, この情報を省くことは非互換な, もしくは, ぶかっこうな実装を生むことになるかもしれないので, とにかくここで 記述する. 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 [RFC-2119]. この文書に出てくる "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "MAY" といった キ-ワ-ドは [RFC2119] に記述されているように解釈される. 2. Rationale 2. 概要 Currently defined authentication methods for SSH are tightly coupled with the underlying authentication mechanism. This makes it difficult to add new mechanisms for authentication as all clients must be updated to support the new mechanism. With the generic method defined here, clients will not require code changes to support new authentication mechanisms, and if a separate authentication layer is used, such as [PAM], then the server may not need any code changes either. SSH で現在定義されている認証法は, 基礎となる認証メカニズムと 強く結合している. これは新しい認証メカニズムを足すのを難しく している. すべてのクライアントが, 新しいメカニズムをサポ-トするために 更新されなければならないから. ここで定義する一般的な認証法では, クライアントは 新しい認証メカニズムをサポ-トするために コ-ドの変更が必要とならない. [PAM] のような別の認証層を使えば, サ-バもなんらコ-ドを変更する必要がなくなる. F. Cusack, M. Forssen Expires November 1, 2003 [Page 2] Internet Draft SSH Generic Interactive Authentication May 1, 2003 This presents a significant advantage to other methods, such as the "password" method (defined in [SSH-USERAUTH]), as new (presumably stronger) methods may be added "at will" and system security can be transparently enhanced. これは, ([SSH-USERAUTH] で定義されている)"password" 法などの 別の方法比べて非常な優位性を提示する. 新しい (おそらくより強い) 方法が "望むままに"に追加されて, システムのセキュリティは透過的に強化されうるからだ. Challenge-response and One Time Password mechanisms are also easily supported with this authentication method. チャレンジ-レスポンスやワンタイムパスワ-ドメカニズムも この認証法を使って容易にサポ-トされる. This authentication method is however limited to authentication mechanisms which do not require any special code, such as hardware drivers or password mangling, on the client. しかし, クライアントでのハ-ドウェアドライバやパスワ-ド マングリングのような なにか特別なコ-ドは必要するもの ではない認証メカニズムにこの認証は 制限される. 3. Protocol Exchanges 3. プロトコルの (メッセ-ジ) 交換. The client initiates the authentication with a SSH_MSG_USERAUTH_REQUEST message. The server then requests authentication information from the client with a SSH_MSG_USERAUTH_INFO_REQUEST message. The client obtains the information from the user and then responds with a SSM_MSG_USERAUTH_INFO_RESPONSE message. The server MUST NOT send another SSH_MSG_USERAUTH_INFO_REQUEST before it has received the answer from the client. クライアントは この認証を SSH_MSG_USERAUTH_REQUEST メッセ-ジで始める. そして, サ-バは SSH_MSG_USERAUTH_INFO_REQUEST メッセ-ジで クライアントからの認証情報を要求する. クライアントはユ-ザからその情報を得て, SSH_MSG_USERAUTH_INFO_RESPONSE メッセ-ジを返す. この答えをクライアントから受けとる前に, 別の SSH_MSG_USERAUTH_INFO_REQUEST をサ-バは送ってはならない. 3.1 Initial Exchange 3.1 最初の交換 The authentication starts with the client sending the following packet: 次のパケットをクライアントが送ることで認証は始まる. byte SSH_MSG_USERAUTH_REQUEST string user name (ISO-10646 UTF-8, as defined in [RFC-2279]) string service name (US-ASCII) string "keyboard-interactive" (US-ASCII) string language tag (as defined in [RFC-3066]) string submethods (ISO-10646 UTF-8) The language tag is deprecated and SHOULD be the empty string. It may be removed in a future revision of this specification. The server SHOULD instead select the language used based on the tags communicated during key exchange [SSH-TRANS]. language tag は 廃止予定で,空文字列である必要がある. この仕様の将来の版では取り除かれるかもしれない. かわりにサ-バは, 鍵交換の [SSH-TRANS] 間に通信されたタグに基づいて 言語を選択する. If the language tag is not the empty string, the server SHOULD use the specified language for any messages sent to the client as part of this protocol. The language tag SHOULD NOT be used for language selection for messages outside of this protocol. The language to be used if the server does not support the requested language is implementation-dependent. もし language tag が空文字列でなかったら, このプロトコルの部分で, クライアントに送るすべてのメッセ-ジで指定された言語を サ-バは使う必要がある. language tag はこのプロトコルの外側での メッセ-ジの言語選択には使わないほうがよい.サ-バが 要求されたメッセ-ジをサポ-トしていない場合に使われる 言語は実装依存だ. The submethods field is included so the user can give a hint of which F. Cusack, M. Forssen Expires November 1, 2003 [Page 3] Internet Draft SSH Generic Interactive Authentication May 1, 2003 actual methods he wants to use. It is a a comma-separated list of authentication submethods (software or hardware) which the user prefers. If the client has knowledge of the submethods preferred by the user, presumably through a configuration setting, it MAY use the submethods field to pass this information to the server. Otherwise it MUST send the empty string. submethods フィ-ルドは, 使いたい実際の方法のヒントをユ-ザが示す ために含まれる. ユ-ザが好む 認証の submethods (ソフトウェアないし ハ-ドウェア) のコンマ区切りリストだ. 設定を通じるなどして ユ-ザが好む submethods についてクライアントが知っているなら, クライアントは, サ-バにこの情報を submethods フィ-ルドを 使って伝えてもよい. そうでなければ, 空文字列を送らなければならない. The actual names of the submethods is something which the user and the server needs to agree upon. submethods の実際の名前は, ユ-ザとサ-バが同意する必要がある. Server interpretation of the submethods field is implementation- dependent. submethods フィ-ルドの サ-バ側の解釈は実装依存だ. One possible implementation strategy of the submethods field on the server is that, unless the user may use multiple different submethods, the server ignores this field. If the user may authenticate using one of several different submethods the server should treat the submethods field as a hint on which submethod the user wants to use this time. サ-バ側の submethods フィ-ルドの一つの可能な実装の戦略は, ユ-ザが複数の異なる submethods を使わない限り サ-バはこのフィ-ルドを無視する というものだ. ユ-ザが幾つかの異なる submethods のうちの一つを使って 認証する場合, そのときユ-ザが使いたい submethod の ヒントとして submethods フィ-ルドをサ-バは取り扱う必要がある. Note that when this message is sent to the server, the client has not yet prompted the user for a password, and so that information is NOT included with this initial message (unlike the "password" method). このメッセ-ジが送られた時, クライアントは まだ ユ-ザに パスワ-ドのためのプロンプトを出さない. ("password" 法とは異なり) その情報は 最初のメッセ-ジに含まれていないから. The server MUST reply with either a SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or SSH_MSG_USERAUTH_INFO_REQUEST message. サ-バは SSH_MSG_USERAUTH_SUCCESS, ないし SSH_MSG_USERAUTH_FAILURE, SSH_MSG_USERAUTH_INFO_REQUEST メッセ-ジの どれかを返答する必要がある. The server SHOULD NOT reply with the SSH_MSG_USERAUTH_FAILURE message if the failure is based on the user name or service name; instead it SHOULD send SSH_MSG_USERAUTH_INFO_REQUEST message(s) which look just like the one(s) which would have been sent in cases where authentication should proceed, and then send the failure message (after a suitable delay, as described below). The goal is to make it impossible to find valid usernames by just comparing the results when authenticating as different users. ユ-ザ名やサ-ビス名に基づく失敗で, サ-バは SSH_MSG_USERAUTH_FAILURE メッセ-ジを返答しないほうがよい. 代わりに, 認証が進むべきである場合に 送られるだろうもののように見える SSH_MSG_USERAUTH_INFO_REQUEST メッセ-ジ を送る必要がある. そして, (以下に示すような 適当な遅延の後で) 失敗メッセ-ジを送る必要がある. 異なるユ-ザによる認証の結果を比較する ことで 有効なユ-ザ名を探すのを不可能にするのが, この目的だ. 3.2 Information Requests 3.2 情報の要求 Requests are generated from the server using the SSH_MSG_USERAUTH_INFO_REQUEST message. SSH_MSG_USERAUTH_INFO_REQUEST メッセ-ジを使って サ-バから リクエストが生成される. The server may send as many requests as are necessary to authenticate the client; the client MUST be prepared to handle multiple exchanges. However the server MUST NOT ever have more than one SSH_MSG_USERAUTH_INFO_REQUEST message outstanding. That is, it may not send another request before the client has answered. サ-バはクライアントを認証するのに必要なだけの数のリクエストを送るだろう. クライアントは 複数の交換を扱う準備がされてなければならない. しかし , サ-バは 一つより多い未解決な SSH_MSG_USERAUTH_INFO_REQUEST メッセ-ジを持ってはならない. すなわち, クライアントが返事をする前に 別のリクエストを送らない. F. Cusack, M. Forssen Expires November 1, 2003 [Page 4] Internet Draft SSH Generic Interactive Authentication May 1, 2003 The SSH_MSG_USERAUTH_INFO_REQUEST message is defined as follows: SSH_MSG_USERAUTH_INFO_REQUEST メッセ-ジは次のように定義される. byte SSH_MSG_USERAUTH_INFO_REQUEST string name (ISO-10646 UTF-8) string instruction (ISO-10646 UTF-8) string language tag (as defined in [RFC-3066]) int num-prompts string prompt[1] (ISO-10646 UTF-8) a boolean echo[1] ... string prompt[num-prompts] (ISO-10646 UTF-8) boolean echo[num-prompts] The server SHOULD take into consideration that some clients may not be able to properly display a long name or prompt field (see next section), and limit the lengths of those fields if possible. For example, instead of an instruction field of "Enter Password" and a prompt field of "Password for user23@host.domain: ", a better choice might be an instruction field of "Password authentication for user23@host.domain" and a prompt field of "Password: ". It is expected that this authentication method would typically be backended by [PAM] and so such choices would not be possible. サ-バは, 長い name や prompt フィ-ルド (次のセクションを参照) を適切に表示できないクライアントがあることを考慮する必要がある. そして, 可能ならこれらのフィ-ルドの長さを制限する必要がある. 例えば, instruction フィ-ルドに "Enter Password" , prompt フィ-ルドに "Password for user23@host.domain: " とする かわりに, instruction フィ-ルドに "Password authentication for user23@host.domain" , prompt フィ-ルドに "Password: " とするのがよりよい選択だ. この認証法は 典型的には [PAM] によってバックエンドされているので このような選択は可能でないかもしれないことが予期される. The name and instruction fields MAY be empty strings, the client MUST be prepared to handle this correctly. The prompt field(s) MUST NOT be empty strings. name と instruction フィ-ルドは, 空文字列かもしれない. クライアントは, これを正しく扱う準備がされてなければならない. (複数の) prompt field (はいずれも) 空文字列であってはならない. The language tag SHOULD describe the language used in the textual fields. If the server does not know the language used, or if multiple languages are used, the language tag MUST be the empty string. language tag は テキストのフィ-ルドで使われる言語を記述する 必要がある. サ-バが使われている言語を知らない場合, もしくは 複数の言語が使われている場合, language tag は空文字列で なければならない. The num-prompts field may be `0', in which case there will be no prompt/echo fields in the message, but the client SHOULD still display the name and instruction fields (as described below). メッセ-ジに prompt/echo フィ-ルドがまったく含まれない場合 num-prompts フィ-ルドは '0' となる, が, クライアントは (以下に示すように) name と instruction フィ-ルドをなお表示 する必要がある. 3.3 User Interface 3.3 ユ-ザインタフェイス Upon receiving a request message, the client SHOULD prompt the user as follows: リクエストメッセ-ジを受けとると, クライアントは 次のように ユ-ザに入力を促す. A command line interface (CLI) client SHOULD print the name and instruction (if non-empty), adding newlines. Then for each prompt in turn, the client SHOULD display the prompt and read the user input. コマンドラインインタフェイス (CLI) クライアントは, 改行を追加して name と (空でないなら) instruction を表示する. そして 順番にすべての prompt に対して クライアントは prompt を表示しユ-ザの入力を読む必要がある. A graphical user interface (GUI) client has many choices on how to prompt the user. One possibility is to use the name field (possibly F. Cusack, M. Forssen Expires November 1, 2003 [Page 5] Internet Draft SSH Generic Interactive Authentication May 1, 2003 prefixed with the application's name) as the title of a dialog window in which the prompt(s) are presented. In that dialog window, the instruction field would be a text message, and the prompts would be labels for text entry fields. All fields SHOULD be presented to the user, for example an implementation SHOULD NOT discard the name field because its windows lack titles; it SHOULD instead find another way to display this information. If prompts are presented in a dialog window, then the client SHOULD NOT present each prompt in a separate window. グラフィカルユ-ザインタフェイス (GUI) クライアントは, ユ-ザに 入力を促す方法にいくつも選択肢がある. 一つの可能性は, prompt が示されているダイアログウィンドウのタイトルとして (アプリケ-ションの名前が先についているかもしれない) name フィ-ルド を使うことだ. そのダイアログウィンドウで, instruction フィ-ルドは テキストメッセ-ジであろうし, prompt は テキストエントリフィ-ルドの ラベルとなるだろう. すべてのフィ-ルドがユ-ザに示される必要がある. 例えば, 実装は, そのウィンドウがタイトルを欠いているからといって name フィ-ルドを捨てないほうがよい. この情報を表示する別の方法を 見付ける必要ががある. ダイアログウィンドウの中で prompt が示されているなら クラアントは 別々のウィンドウにそれぞれの prompt を示さないほうがよい. All clients MUST properly handle an instruction field with embedded newlines. They SHOULD also be able to display at least 30 characters for the name and prompts. If the server presents names or prompts longer than 30 characters, the client MAY truncate these fields to the length it can display. If the client does truncate any fields, there MUST be an obvious indication that such truncation has occured. The instruction field SHOULD NOT be truncated. すべてのクライアントは 改行が埋め込まれた instruction フィ-ルドを 適切に扱かわなければならない. name と prompt のために 少なくとも 30 文字 表示することができる必要もある. サ-バが 30 文字よりも 長い name や prompt を示したなら, クライアントは, それを表示できる 長さに これらのフィ-ルドを切り取ってもよい. クライアントがいずれかの フィ-ルドを切り取ったなら, その切り取りが起ったことを明白に表示 しなければならない. instruction フィ-ルドは 切り取られないほうがよい. Clients SHOULD use control character filtering as discussed in [SSH-ARCH] to avoid attacks by including terminal control characters in the fields to be displayed. 端末コントロ-ル文字を送ることによる 攻撃を避けるために,[SSH-ARCH] で議論されている コントロ-ル文字のフィルタをクライアントはする必要がある. For each prompt, the corresponding echo field indicates whether or not the user input should be echoed as characters are typed. Clients SHOULD correctly echo/mask user input for each prompt independently of other prompts in the request message. If a client does not honor the echo field for whatever reason, then the client MUST err on the side of masking input. A GUI client might like to have a checkbox toggling echo/mask. Clients SHOULD NOT add any additional characters to the prompt such as ": " (colon-space); the server is responsible for supplying all text to be displayed to the user. Clients MUST also accept empty responses from the user and pass them on as empty strings. それぞれの prompt で, 対応する echo フィ-ルドは 文字が入力された際に ユ-ザの入力を エコ-すべきかどうか を示す. クライアントは リクエストメッセ-ジ中の他の prompt とは独立にそれぞれの prompt の 入力に対してユ-ザの入力を正しくエコ-ないしマスクする必要がある. クライアントが どんな理由であれ, echo フィ-ルドを遵守しないなら, クライアントは 入力をマスクしなければならない. GUI のクライアントは エコ-/マスクをトグルするチェックボックスを持って もよい. クライアントは ": " (コロン-スペ-ス) のような追加の文字を プロンプトに追加しないほうがよい. ユ-ザに表示されるすべてのテキストの 供給は サ-バに責任がある. クライアントは user からの 空の返答を受けとらねければならない. そして, 空文字列としてそれらを 渡さなければならない. # err on the side of #~をしすぎて失敗{しっぱい}する 3.4 Information Responses 3.4 情報の返答 After obtaining the requested information from the user, the client MUST respond with a SSH_MSG_USERAUTH_INFO_RESPONSE message. ユ-ザから要求された情報を得たら, クライアントは SSH_MSG_USERAUTH_INFO_RESPONSE メッセ-ジで 返答しなければならない. The format of the SSH_MSG_USERAUTH_INFO_RESPONSE message is as follows: SSH_MSG_USERAUTH_INFO_RESPONSE メッセ-ジの形式は 次の通りだ. byte SSH_MSG_USERAUTH_INFO_RESPONSE int num-responses string response[1] (ISO-10646 UTF-8) ... string response[num-responses] (ISO-10646 UTF-8) F. Cusack, M. Forssen Expires November 1, 2003 [Page 6] Internet Draft SSH Generic Interactive Authentication May 1, 2003 Note that the responses are encoded in ISO-10646 UTF-8. It is up to the server how it interprets the responses and validates them. However, if the client reads the responses in some other encoding (e.g., ISO 8859-1), it MUST convert the responses to ISO-10646 UTF-8 before transmitting. response は ISO-10646 UTF-8 でエンコ-ドされることに注意. サ-バがどのように response を解釈し検証するかは サ-バに依存する. しかし, クライアントが 他の別のエンコ-ディング (例えば ISO 8859-1) で response を読みこんだら, クライアントは 転送する前に ISO-10646 UTF-8 に response を変換しなればならない. If the num-responses field does not match the num-prompts field in the request message, the server MUST send a failure message. num-responses フィ-ルドが リクエストメッセ-ジでの num-prompts フィ-ルドと一致しないなら, サ-バあ 失敗メッセ-ジを送らなければならない. In the case that the server sends a `0' num-prompts field in the request message, the client MUST send a response message with a `0' num-responses field. サ-バが リクエストメッセ-ジで `0' num-prompts フィ-ルド を送って来た場合, クライアントは `0` num-responses フィ-ルドを持つ レスポンスメッセ-ジ を送らなければならない. The responses MUST be ordered as the prompts were ordered. That is, response[n] MUST be the answer to prompt[n]. response は prompt が並べられてた順に並べられなければならない. すなわち, response[n] は prompt[n] に対する答えでなければならない. After receiving the response, the server MUST send either a SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, or another SSH_MSG_USERAUTH_INFO_REQUEST message. このレスポンスが受けとられると, サ-バは SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_USERAUTH_FAILURE, さらに別の SSH_MSG_USERAUTH_INFO_REQUEST メッセ-ジのいずれかを送らなければならない. If the server fails to authenticate the user (through the underlying authentication mechanism(s)), it SHOULD NOT send another request message(s) in an attempt to obtain new authentication data, instead it SHOULD send a failure message. The only time the server should send multiple request messages is if additional authentication data is needed (i.e., because there are multiple underlying authentication mechanisms that must be used to authenticate the user). サ-バが (基になる認証メカニズムを通じて) ユ-ザの認証に失敗したなら, 新しい認証デ-タを得ようとして別のリクエストメッセ-ジを送らないほうがよい. その代わり, 失敗メッセ-ジを送る必要がある. サ-バが複数のリクエスト メッセ-ジを送るべき唯一の場合は, 追加の認証が必要な場合だけだ (すなわち, ユ-ザを認証するために使われなければならない, 複数の基となる認証メカニズムがある) If the server intends to respond with a failure message, it MAY delay for an implementation-dependent time before sending to the client. It is suspected that implementations are likely to make the time delay a configurable, a suggested default is 2 seconds. サ-バが 失敗メッセ-ジで返答しようとする場合, クライアントに 送る前に実装依存の時間の間遅らせてもよい. 実装はこの時間の遅延を 設定可能にしたほうがよいと思われる. デフォルトの推奨される値は 2 秒だ. 4. Authentication Examples 4. 認証の例. Here are two example exchanges between a client and server. The first is an example of challenge/response with a handheld token. This is an authentication that is not otherwise possible with other authentication methods. 以下が クライアントとサ-バの 2 つの交換の例だ.最初は, ハンドヘルドト-クン による チャレンジ/レスポンスの例だ. これは 他の認証法では不可能な 認証だ. C: byte SSH_MSG_USERAUTH_REQUEST C: string "user23" C: string "ssh-userauth" C: string "keyboard-interactive" C: string "" C: string "" F. Cusack, M. Forssen Expires November 1, 2003 [Page 7] Internet Draft SSH Generic Interactive Authentication May 1, 2003 S: byte SSH_MSG_USERAUTH_INFO_REQUEST S: string "CRYPTOCard Authentication" S: string "The challenge is '14315716'" S: string "en-US" S: int 1 S: string "Response: " S: boolean TRUE [Client prompts user for password] C: byte SSH_MSG_USERAUTH_INFO_RESPONSE C: int 1 C: string "6d757575" S: byte SSH_MSG_USERAUTH_SUCCESS The second example is of a standard password authentication, in this case the user's password is expired. 2 番目の例は, 通常のパスワ-ド認証だが, この時 ユ-ザのパスワ-ドは 失効している. C: byte SSH_MSG_USERAUTH_REQUEST C: string "user23" C: string "ssh-userauth" C: string "keyboard-interactive" C: string "en-US" C: string "" S: byte SSH_MSG_USERAUTH_INFO_REQUEST S: string "Password Authentication" S: string "" S: string "en-US" S: int 1 S: string "Password: " S: boolean FALSE [Client prompts user for password] C: byte SSH_MSG_USERAUTH_INFO_RESPONSE C: int 1 C: string "password" F. Cusack, M. Forssen Expires November 1, 2003 [Page 8] Internet Draft SSH Generic Interactive Authentication May 1, 2003 S: byte SSH_MSG_USERAUTH_INFO_REQUEST S: string "Password Expired" S: string "Your password has expired." S: string "en-US" S: int 2 S: string "Enter new password: " S: boolean FALSE S: string "Enter it again: " S: boolean FALSE [Client prompts user for new password] C: byte SSH_MSG_USERAUTH_INFO_RESPONSE C: int 2 C: string "newpass" C: string "newpass" S: byte SSH_MSG_USERAUTH_INFO_REQUEST S: string "Password changed" S: string "Password successfully changed for user23." S: string "en-US" S: int 0 [Client displays message to user] C: byte SSH_MSG_USERAUTH_INFO_RESPONSE C: int 0 S: byte SSH_MSG_USERAUTH_SUCCESS 5. IANA Considerations 5. IANA に関する考察 The userauth type "keyboard-interactive" is used for this authentication method. ユ-ザ認証タイプ "keyboard-interactive" が この認証法のために 使われる. The following method-specific constants are used with this authentication method: 次の認証法特有の定数が この認証法で使われる. SSH_MSG_USERAUTH_INFO_REQUEST 60 SSH_MSG_USERAUTH_INFO_RESPONSE 61 6. Security Considerations 6. セキュリティに関する考察. The authentication protocol, and this authentication method, depends on the security of the underlying SSH transport layer. Without the confidentiality provided therein, any authentication data passed with this method is subject to interception. 認証プロトコルそしてこの認証法は 下にある SSH トランスポ-ト層の セキュリティに依存する. 秘密性がここで提供されないければ, この方法で渡されるどんな認証デ-タも傍受にさらされる. F. Cusack, M. Forssen Expires November 1, 2003 [Page 9] Internet Draft SSH Generic Interactive Authentication May 1, 2003 The number of client-server exchanges required to complete an authentication using this method may be variable. It is possible that an observer may gain valuable information simply by counting that number. For example, an observer may guess that a user's password has expired, and with further observation may be able to determine the frequency of a site's password expiration policy. この方法を使っての認証を完了するために必要なクライアント-サ-バ間の メッセ-ジ交換の回数は変わりうる. 単にこの数を数えるだけで, 観察者が有用な情報を得ることも可能かもしれない. 例えば, 観察者はユ-ザのパスワ-ドが失効していることを 推測するかもしれないし, さらなる観察によって サイトのパスワ-ド失効ポリシ-の適用頻度を割出すことができるかもしれない. 7. References 7.1 Normative References [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Level", BCP 14, RFC 2119, March 1997. [RFC-2279] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 10646", RFC 2279, October 1996. [RFC-3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001. [SSH-ARCH] Ylonen, T., Kivinen, T, Saarinen, M., Rinne, T., and Lehtinen, S., "SSH Protocol Architecture", work in progress, draft-ietf-secsh-architecture-13.txt, September, 2002. [SSH-CONNECT] Ylonen, T., Kivinen, T, Saarinen, M., Rinne, T., and Lehtinen, S., "SSH Connection Protocol", work in progress, draft-ietf-secsh-connect-16.txt, September, 2002. [SSH-TRANS] Ylonen, T., Kivinen, T, Saarinen, M., Rinne, T., and Lehtinen, S., "SSH Transport Layer Protocol", work in progress, draft-ietf-secsh-transport-15.txt, September, 2002. [SSH-USERAUTH] Ylonen, T., Kivinen, T, Saarinen, M., Rinne, T., and Lehtinen, S., "SSH Authentication Protocol", work in progress, draft-ietf-secsh-userauth-16.txt, September, 2002. F. Cusack, M. Forssen Expires November 1, 2003 [Page 10] Internet Draft SSH Generic Interactive Authentication May 1, 2003 7.2 Informative References [PAM] Samar, V., Schemers, R., "Unified Login With Pluggable Authentication Modules (PAM)", OSF RFC 86.0, October 1995 8. Author's Addresses Frank Cusack Google, Inc. 2400 Bayshore Parkway Mountain View, CA 94043 Email: frank@google.com Martin Forssen Appgate AB Stora Badhusgatan 18-20 SE-411 21 Gothenburg SWEDEN Email: maf@appgate.com F. Cusack, M. Forssen Expires November 1, 2003 [Page 11]