Network Working Group F. Cusack Request for Comments: 4256 savecore.net Category: Standards Track M. Forssen AppGate Network Security AB January 2006 SSHプロトコル (SSH) のための 一般メッセージ交換認証 このメモの位置づけ この文書は, インターネットコミュニティに対するインターネットの標準トラックプロトコルを定義している. また, 改善のための議論と示唆を求めている. このプロトコルの標準化の状態と状況は "Internet Official Protocol Standards" (STD 1) の現在の版を参照してほしい. このメモの配布は制限しない. 著作権情報 Copyright (C) The Internet Society (2006). 訳者: 春山 征吾 . 概要 セキュア シェル (SSH) プロトコルは, 安全ではないネットワーク上での安全なリモートログインや他の安全なネットワークサービスのためのプロトコルだ. この文書は, SSHプロトコルのための汎用の認証法を記述している. この認証法は, 認証データをキーボード(や同様の英数入力デバイス)で入力する状況でインタラクティブな認証を行なうのに適している. この方法の主な目的は, SSH クライアントが認証メカニズムの具体形な仕様を知らなくても認証メカニズムをサポートできるようにすることだ. 1イントロダクション SSH 認証プロトコル [SSH-USERAUTH] は, 汎用のユーザ認証プロトコルだ. SSH トランスポート層プロトコル [SSH-TRANS] の上で動作することを想定している. 認証プロトコルは, その下層のプロトコルが完全性と機密性を提供することを前提とする. この文書は, SSH認証プロトコルのための汎用の認証法を記述している. この方法は, クライアント側に特別なソフトウェアのサポートが必要ないインタラクティブな認証法に適している. かわりに, すべての認証データはキーボードから入力される必要がある. この方法の主な目的は, SSH サーバが使う認証メカニズムの仕様を(ほとんどないしまったく)SSHクライアントが知らなくてもよいようにすることだ. Cusack & Forssen Standards Track [Page 1] RFC 4256 SSH Generic Interactive Authentication January 2006 これは, クライアントのコードを更新する必要なしに認証メカニズムをサーバが任意に選択/変更できるということでもある この認証法の名前は, "keyboard-interactive" だ. この文書は, SSH アーキテクシャ文書 [SSH-ARCH] と SSH 認証文書 [SSH-USERAUTH] を読んでからのみ読むべきだ. この文書は, 参照や説明なしに2つの文書から用語や表記法を自由に利用する. この文書は, 認証の情報を得る際のユーザとクライアントのやりとりについても記述する. これはある意味プロトコルの仕様外の話だ. しかし, このプロトコルはユーザインタファイスの問題に基いて仕様が設計されている面がありまたこの情報を除くと互換性がなかったり不恰好な実装を埋むかもしれないので, ここで記述することになった. この文書でのキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" は, [RFC-2119] で記述されているように解釈される. 2. 原理 現在SSHのために定義されている認証法は, 基盤となっている認証メカニズムと密に結合している. これにより, 新しい認証メカニズムを追加するには, すべてのクライアントがその新しいメカニズムをサポートするために更新されなければならず, 新しいメカニズムの追加を困難にしている. ここで定義する一般的な方法を用いると, クライアントは新しい認証メカニズムをサポートするためにコードを変更する必要がなくなる. また, [PAM]のような分離された認証層を用いているなら, サーバもコードの変更が必要ないかもしれない. これは, ([SSH-USERAUTH] で定義されている) "password" 方式のような他の方法に対して非常に有利である. 新しい(おそらくより強固な)方法が "思いのままに" 追加できるので, システムのセキュリティは透過的に強化できる. チャレンジ-レスポンスとワンタイムパスワードのメカニズムは, この認証法で容易にサポートされる しかし, この認証法は, クライアントで(ハードウェアのドライバやパスワードマングリングのような)特別なコードを必要としない認証メカニズムに制限される. Cusack & Forssen Standards Track [Page 2] RFC 4256 SSH Generic Interactive Authentication January 2006 3. プロトコルのやりとり クライアントは認証を SSH_MSG_USERAUTH_REQUEST メッセージで開始する. そしてサーバは, クライアントからの認証情報を SSH_MSG_USERAUTH_INFO_REQUEST で要求する. クライアントはユーザから情報を得て, SSM_MSG_USERAUTH_INFO_RESPONSE で応答する. クライアントからの返答を受け取る前に, サーバは別の SSH_MSG_USERAUTH_INFO_REQUEST を送ってはならない. 3.1. 最初の交換 認証は, クライアントが次のパケットを送ることで始まる. byte SSH_MSG_USERAUTH_REQUEST string user name (ISO-10646 UTF-8, as defined in [RFC-3629]) string service name (US-ASCII) string "keyboard-interactive" (US-ASCII) string language tag (as defined in [RFC-3066]) string submethods (ISO-10646 UTF-8) language tag は推奨されておらず、空の文字列である必要がある. この仕様の将来のバージョンでは, 削除されるだろう. 代わりに, サーバは鍵交換時に通信されるタグに基づいて言語を選択する必要がある [SSH-TRANS]. もし, language tag が空の文字列でなかったら, サーバは, このプロトコルの一部としてクライアントへ送るすべてのメッセージに指定された言語を用いる必要がある. language tag を, このプロトコル外部のメッセージの言語選択に使わないほうがよい. サーバが要求された言語をサポートしてないなら, 利用される言語は実装依存だ. submethods フィールドは, ユーザが利用したいと望む実際の方法のヒントが含まれる. ユーザが好む認証 submethod (ソフトウェアないしハードウェア)のコンマ区切りリストだ. 設定などからクライアントがユーザの好む submethod について知っているなら, サーバにその情報を渡すために submethods フィールドを利用してもよい. そうでなければ, 空文字列を送らなければならない. submethods の実際の名前は, ユーザとサーバの間で同意が必要だ. submethods のサーバの解釈は, 実装依存だ. Cusack & Forssen Standards Track [Page 3] RFC 4256 SSH Generic Interactive Authentication January 2006 submethods フィールドのサーバ側の1つの可能な実装戦略は, ユーザが複数の異なる submethodを利用しようとも, サーバがこのフィールドを無視することだ. ユーザがいくつかの異なるsubmethodの1つを用いて認証したい時, サーバは, ユーザがここのときに利用したい submethod のヒントとして submethods を取り扱う必要がある. このメッセージがサーバに送信される時, クライアントはまだユーザにパスワードのためのプロンプトを出しておらず, ("password" 法とは異なり) この最初のメッセージにはパスワードのような情報は含まれていない. サーバは, SSH_MSG_USERAUTH_SUCCESS か, SSH_MSG_USERAUTH_FAILURE, SSH_MSG_USERAUTH_INFO_REQUEST メッセージで応答しなければならない. ユーザ名かサービス名が原因で失敗したとき, サーバは SSH_MSG_USERAUTH_FAILURE メッセージで応答しないほうがよい. 代わりに, 認証が進む場合のと同様に, SSH_MSG_USERAUTH_INFO_REQUEST メッセージを送る必要がある. そして(後述する適切な遅延の後で)失敗メッセージを送る. この目的は, 異なるユーザで認証する時の結果を比較して有効なユーザ名を探すのを困難にするためだ. サーバは, ユーザに要求された認証がない場合に SSH_MSG_USERAUTH_SUCCESS メッセージで応答してもよい. しかし, 上で議論した理由により, よりよいアプローチは, SSH_MSG_USERAUTH_INFO_REQUEST メッセージで応答して その返答を無視 (検証しない)することだろう.. 3.2. 情報の要求 SSH_MSG_USERAUTH_INFO_REQUEST メッセージを用いて, サーバから要求が生成される. サーバは, クライアントを認証するためにたくさんの要求を必要とするかもしれない. クライアントは複数の交換を処理する準備をしなければならない. しかし, サーバは, 2つ以上の未処理の SSH_MSG_USERAUTH_INFO_REQUEST メッセージを扱ってはならない.. つまり, クライアントが返答する前に別の要求を送ってはならない. Cusack & Forssen Standards Track [Page 4] RFC 4256 SSH Generic Interactive Authentication January 2006 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) boolean echo[1] ... string prompt[num-prompts] (ISO-10646 UTF-8) boolean echo[num-prompts] language tag は推奨されておらず、空の文字列である必要がある. この仕様の将来のバージョンでは, 削除されるだろう. 代わりに, サーバは鍵交換時に通信されるタグに基づいて言語を選択する必要がある [SSH-TRANS]. もし, language tag が空の文字列でなかったら, サーバは, このプロトコルの一部としてクライアントへ送るすべてのメッセージに指定された言語を用いる必要がある. language tag を, このプロトコル外部のメッセージの言語選択に使わないほうがよい. サーバが要求された言語をサポートしてないなら, 利用される言語は実装依存だ. サーバは, クライアントが長い name や prompt フィールドを適切に表示できない可能性を考慮する必要がある(次の節を参照). 可能ならばこれらのフィールドの流さを制限する必要がある. たとえば, instruction フィールドに"Enter Password", prompt フィールドに"Password for user23@host.domain: " とする代わりに, instruction フィールドに "Password authentication for user23@host.domain" , prompt フィールドに "Password: " とするのが良い選択だ.. この認証方式は, 典型的には [PAM] によって支援されるのでこのような選択は可能ではないことも予想される. name や instruction フィールドは空の文字列でもよい. クライアントはこれらを正しく処理するよう準備されなければならない. prompt フィールドは 空文字列であってはならない. num-prompts フィールドは メッセージで prompt/echo フィールドが存在しない場合に `0' の場合もある. (後述するように)その場合もクライアントは name と instruction フィールドを表示する必要がある. Cusack & Forssen Standards Track [Page 5] RFC 4256 SSH Generic Interactive Authentication January 2006 3.3. ユーザインタフェース 要求メッセージを受け付けたら, クライアントは次のようにユーザにプロンプトを出す必要がある. コマンドラインインタフェイス (CLI) クライアントは, name と instruction (空文字列でなかったら) を表示し, 改行を追加する. そして, 順番にそれぞれのpromptについて, クライアントは promptを表示しユーザの入力を読み取る必要がある. グラフィカルユーザインタフェイス (GUI) クライアントは, ユーザにプロンプトを出すためにたくさんの選択肢がある. 1つの方法は, promptの表示するダイアログウィンドウのタイトルとして, name フィールドを用いることだ(アプリケーション名を前置するかもしれない). このダイアログウィンドウで, instruction フィールドはテキストのメッセージで, prompt はテキストエントリフィールドのラベルとなるだろう. すべてのフィールドがユーザに表示される必要がある. たとえば, 実装はウィンドウにタイトルがないからといって name フィールドを破棄しないほうがよい. この情報を表示する別の方法を見つける必要がある. ダイアログウィンドウで prompt が表示される際, クライアントはそれぞれのpromptを別のwindowで表示しないほうがよい. すべてのクライアントは, 改行を含む instruction フィールドを適切に扱えなければならない. また, すべてのクライアントは, name と prompt について 少なくとも 30 文字表示できる必要がある. サーバが30文字を越える name や prompt を提供したなら, クライアントは これらのフィールドを表示できる長さに切り詰めてもよい. クライアントがフィールドを切り詰めるなら, 切り詰めが起ったことを明確に表示しなければならない. instruction フィールドは, 切り詰めないほうがよい. [SSH-ARCH} で議論されているように, 表示されるフィールドに端末制御文字が含まれる攻撃を防ぐために, クライアントは制御文字のフィルタリングをする必要がある. それぞれのpromptで, 対応する echo フィールドは, ユーザの入力を入力された文字でエコーするかどうかを指定する. クライアントは, 要求メッセージの中のpromptoごとに独立に正確にユーザの入力をエコー/マスクする必要がある. クライアントが何らかの理由で echo フィールドを尊重しない場合は, クライアントは入力を隠さなければならない. GUI クライアントは, echo/maskのトグルを行なうチェックボックスを付けてもよい. クライアントは, ": " (コロン-スペース)のような追加の文字を prompt に足さないほうがよい. サーバは, ユーザの表示されるすべての文字列を提供する責任がある. クライアントは, ユーザからの空の応答を受け付け空の文字列として扱わなければならない. Cusack & Forssen Standards Track [Page 6] RFC 4256 SSH Generic Interactive Authentication January 2006 3.4. 情報の応答 ユーザから要求された情報を得たら, クライアントは, SH_MSG_USERAUTH_INFO_RESPONSE メッセージで応答する. 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) response は ISO-10646 UTF-8 でエンコードされることに注意. response をどう解釈し検証するかは サーバ次第だ. ただし, クライアントが他のエンコーディング(例: ISO 8859-1) で応答を読んだ場合でも, クライアントは転送の前に ISO-10646 UTF-8 に変換しなければならない. 国際化の観点から, ユーザが応答を入力する際, 認証のプロセスはユーザが用いるOSやクライアントソフトウェアに関係なく動くことが望ましい. このために正規化が必要だ. ASCII以外のパスワードをサポートするシステムは, パスワードとユーザ名をデータベースに追加したり(ハッシュしたり,もしくはせずに)データベース内のエントリと比較する際にいつでも正規化する必要がある. パスワードを保存したり比較するSSHの実装は, 正規化に [SASLPREP] を使う必要がある. num-responses フィールドが 要求メッセージの num-prompts フィールドと一致しない場合, サーバは, 失敗メッセージを送らなければならない. サーバが 要求メッセージで `0' な num-prompts フィールドを送った場合, クライアントは, 交換を完了するために '0' な num-responses フィールドで 応答メッセージを送らなければならない. responses は, prompts の順番で並んでなければならない. つまり, response[n] は, prompt[n] の応答でなければならない. 応答を受け取ったら, サーバは, SSH_MSG_USERAUTH_SUCCESS か, SSH_MSG_USERAUTH_FAILURE, さらにもう1つの SSH_MSG_USERAUTH_INFO_REQUEST メッセージで応答しなければならない. (基盤となっている認証メカニズムを通して) サーバがユーザの認証に失敗したなら, 新しい認証データを得ようとして 別の要求メッセージを送らないほうがよい. 代わりに 失敗メッセージを送る必要がある. 追加の認証データが必要な場合のみ, サーバは複数の要求メッセージを送る必要がある. Cusack & Forssen Standards Track [Page 7] RFC 4256 SSH Generic Interactive Authentication January 2006 (つまり, ユーザを認証するのに使われなければならない基盤となる認証メカニズムが複数ある場合だ). サーバが失敗メッセージで応答しようとする場合, クライアントに送信する前に実装依存の時間送らせてもよい. 実装はこの遅延を設定可能にするかもしれない. 推奨されるデフォルトは 2秒だ. 4. 認証の例 クライアントとサーバの間の交換を2例挙げる. 最初は, ハンドヘルドトークンによるチャレンジ/レスポンスの例だ. これは, 他の認証法では不可能な認証だ. C: byte SSH_MSG_USERAUTH_REQUEST C: string "user23" C: string "ssh-userauth" C: string "keyboard-interactive" C: string "" C: string "" 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 Cusack & Forssen Standards Track [Page 8] RFC 4256 SSH Generic Interactive Authentication January 2006 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" 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 Cusack & Forssen Standards Track [Page 9] RFC 4256 SSH Generic Interactive Authentication January 2006 [Client displays message to user] C: byte SSH_MSG_USERAUTH_INFO_RESPONSE C: int 0 S: byte SSH_MSG_USERAUTH_SUCCESS 5. IANA の考慮 userauth のタイプ "keyboard-interactive" がこの認証法のために使われる. 次の認証法特有の定数がこの認証法で使われる. SSH_MSG_USERAUTH_INFO_REQUEST 60 SSH_MSG_USERAUTH_INFO_RESPONSE 61 6. セキュリティの考察 認証プロトコルとこの認証法は, 基盤となっているSSHトランスポート層のセキュリティに依存する. 秘匿性が提供されないと, この方法で転送されるすべての認証データは傍受されます. この方法で認証を完了するために必要なクライアント-サーバの交換の数は変化するかもしれない. この斯うを数えるだけで意味のある情報を得られる観察者がいるかもしれない. たとえば, 観察者は, ユーザのパスワードが期限切れかどうか推測できるかもしれない. さらなる観察により, サーバのパスワード期限ポリシーで決められたパスワードの生存期間を決定できるかもしれない. 7. References 7.1. Normative References [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC-3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC-3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001. Cusack & Forssen Standards Track [Page 10] RFC 4256 SSH Generic Interactive Authentication January 2006 [SSH-ARCH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. [SSH-USERAUTH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006. [SSH-TRANS] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. [SASLPREP] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005. 7.2. Informative References [PAM] Samar, V., Schemers, R., "Unified Login With Pluggable Authentication Modules (PAM)", OSF RFC 86.0, October 1995. Authors' Addresses Frank Cusack savecore.net EMail: frank@savecore.net Martin Forssen AppGate Network Security AB Otterhallegatan 2 SE-411 18 Gothenburg SWEDEN EMail: maf@appgate.com Cusack & Forssen Standards Track [Page 11] RFC 4256 SSH Generic Interactive Authentication January 2006 Full Copyright Statement 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. 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. 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. 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. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Cusack & Forssen Standards Track [Page 12]