Network Working Group T. Ylon en Request for Comments: 4252 SSH Communications Security Co rp Category: Standards Track C. Lonvick, E d. Cisco Systems, Inc. January 2006 セキュア シェル (SSH) 認証プロトコル このメモについて この文書は, インターネットコミュニティに対するインターネットの標準トラ ックプロトコルを定義している. また, 改善のための議論と示唆を求めている このプロトコルの標準化の状態と状況は "Internet Official Protocol Standards" (STD 1) の現在の版を参照してほしい. この メモの配布は制限しない. Copyright Notice Copyright (C) The Internet Society (2006). 訳者: 春山 征吾 概要 セキュア シェル (SSH) プロトコルは, 安全ではないネットワーク上での安全 なリモートログインや他の安全なネットワークサービスのためのプロトコルだ . この文書は, SSH認証プロトコルのフレームワークと, 公開鍵, パスワード , ホストベース認証法について記述する. 追加の認証法は別のドキュメントに記述される. SSH認証プロトコルは, SSH トランスポート層プロトコルの上で動作し, SSHコネクションプロトコルのた めの単一の認証されたトンネルを提供する. Ylonen & Lonvick Standards Track [Page 1] RFC 4252 SSH Authentication Protocol January 20 06 目次 1. イントロダクション ..........................................2 2. Contributors ....................................................3 3. Conventions Used in This Document ...............................3 4. 認証プロトコルのフレームワーク...........................4 5. 認証の要求......................................4 5.1. 認証の要求に対する返答.......................5 5.2. "none" 認証要求 ..........................7 5.3. ユーザ認証の完了 ..........................7 5.4. バナー メッセージ.......................................7 6. 認証プロトコルのメッセージ番号.........................8 7. 公開鍵認証法: "publickey" ...................8 8. パスワード認証法: "password" .....................10 9. ホストベース認証: "hostbased"........................12 10. IANA の考慮 ..............................................14 11. セキュリティの考察.......................................14 12. References ....................................................15 12.1. Normative References .....................................15 12.2. Informative References ...................................15 Authors' Addresses ................................................16 Trademark Notice ..................................................16 1. イントロダクション SSH 認証プロトコルは, 汎用のユーザ認証プロトコルだ. SSH トランスポー ト層プロトコル [SSH-TRANS] の上で動作することを想定している. このプロ トコルは, その下層のプロトコルが完全性と機密性を提供することを前提とす る. この文書は, SSHアーキテクチャ文書 [SSH-ARCH]を読んだあとに読むべきだ. この文書は, 参照や説明なしにアーキテクチャ文書から用語や表記法を自由 に利用する. このプロトコルの 'service name' は, "ssh-userauth" だ. このプロトコルが開始すると, プロトコルは下層のプロトコルからセッション 識別子(最初の鍵交換の再の交換ハッシュ H)を受け取る. セッション識別子 はユニークにセッションを識別する. これは, 公開鍵の持ち主を証明するため の署名に利用するのに適当だ. プロトコルは, 下層のプロトコルが機密性の保 護を提供するかどうかを知る必要もある. Ylonen & Lonvick Standards Track [Page 2] RFC 4252 SSH Authentication Protocol January 20 06 2. Contributors 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. 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. 3. Conventions Used in This Document 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]. 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]. プロトコルのフィールドとフィールドで取り得る値は , この文書群で定義さ れる. メッセージの定義で, プロトコルのフィールドは定義される. 例とし て, SSH_MSG_CHANNEL_DATA を次で定義する byte SSH_MSG_CHANNEL_DATA uint32 recipient channel string data この文書群では, フィールドが参照される場合には, シングルクォートで囲ま れて表記される. フィールドに入る値が参照される場合は, ダブルクォート で囲まれて表記される. 上の例を用いると, 'data' の取り得る値には, "foo " や "bar" がある. Ylonen & Lonvick Standards Track [Page 3] RFC 4252 SSH Authentication Protocol January 20 06 4. 認証プロトコルのフレームワーク サーバは, やりとりを続けるためにその時点でどの認証法が利用できるかクラ イアントに伝えることで認証を始める. クライアントは, サーバによって示 された方法をどの順番で試しても構わない. これは, サーバが, もし望むな らば, 認証のプロセスを完全に制御できることを意味する. 一方で, サーバか ら複数の方法が提供された場合に, クライアントがサポートしていたりユーザ にもっとも便利な認証法を利用可能な自由度も提供する. 認証法は, [SSH-ARCH]で定義されているように, その名前で識別される. "no ne" は予約されている. しかし, サポートしている認証法として示してはなら ない. しかし, これはクライアント側から送られてもよい. サーバは, この 要求を常に拒否しなければならない. ただし, クライアントが認証なしで正当 なアクセスができる場合に限っては, サーバはこの要求を受け入れなければな らない. この要求を送る主要な目的は, サーバからサポートしている認証法 のリストを得ることだ. サーアは, 認証のタイムアウト期間を持つ必要がある. また, そのタイムアウ ト期間内に認証が受け入れられなかった場合に切断する必要がある. タイムアウト期間の推奨は, 10分だ. 加えて, 実装はクライアントが1つのセ ッションで実行できる認証の失敗の数を制限する必要がある. (20回の試行を 推奨の制限とする)この閾値を越えた場合, サーバは切断する必要がある. 認証のタイムアウトと再試行についてのさらなる考察が [ssh-1.2.30] にある .. 5. 認証の要求 すべての認証の要求は, 次のメッセージの形式を利用しなければならない. 最初のいくつかのフィールドだけが定義されている; 残りのフィールドは認証 法に依存する. 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 'user name' と 'service name' は, すべての新しい認証の試行のたびに繰り 替えされる. もしくは, 変更されることもある. サーバの実装は, すべての メッセージを注意深く検査しなければならない. もし変更されていたら蓄積し た認証の状態を消去しなければならない. Ylonen & Lonvick Standards Track [Page 4] RFC 4252 SSH Authentication Protocol January 20 06 認証の状態を消去できない場合に, 'user_name' か 'service_name' が変更さ れたらサーバの実装は切断しなければならない. 'service name' は, 認証後に開始するサービスを指定する. いくつかの異な る認証されたサービスが提供されることがある. 要求されたサービスが利用 可能ではない場合, サーバはすぐに切断してもよいし後のいかなる時に切断し てもよい. 正当な切断メッセージを送ることが推奨される. どちらにせよ, サービスが存在しないなら, 認証を受け入れてはならない. 要求された'user_name'が存在しない場合, サーバは切断してもよいし, 'meth od_name'の値に受け入れられる認証のニセのリスト(しかし実際には受け入れ ない)を送ってもよい. これによって, サーバが, アカウントが存在するかの 情報を漏らすのを避けることができる. どちらにせよ, 'user_name' が存在 しないなら, 認証を受け入れてはならない. クライアントが, サーバが受け入れるリストに挙げていない要求を送るのは通 常意味がないが, そのような要求を送ることはエラーではない. サーバは, そ のような要求は認められないので, 単純に拒否する必要がある. 認証の要求は, さらにメッセージの交換を行なってもよい. そのようなメッ セージは, 利用する認証の 'method_name' に依存する. クライアントは, い つでも新しい SSH_MSG_USERAUTH_REQUEST を送ってよい. このとき, サーバは 以前の認証の試行を法規し新しいもので認証を継続しなければならない. 次の 'method name' の値が定義されている. "publickey" REQUIRED "password" OPTIONAL "hostbased" OPTIONAL "none" NOT RECOMMENDED 追加の 'method_name' の値が, [SSH-ARCH] や [SSH-NUMBERS] で定義される かもしれない. 5.1. 認証の要求に対する返答 サーバが認証の要求を拒否するなら, 次のメッセージで返答しなければならな い: byte SSH_MSG_USERAUTH_FAILURE name-list authentications that can continue boolean partial success Ylonen & Lonvick Standards Track [Page 5] RFC 4252 SSH Authentication Protocol January 20 06 'authentications that can continue' は, 認証のやりとりを続行できる認証 の 'method_name' の値のコンマ区切りのリストだ. サーバは, 実際に利用できる名前 'method_name' の値のみをリストに含める ことが推奨される. しかし, ユーザの認証に利用できない 'method_name'の 値を含めることは違反ではない. すでに認証が成功しているものは, リストに含めないほうがよい. ただし, な んらかの理由でもう一度実行すべき場合は除く. 'partial success' の値は, 対応する認証の要求が成功した場合に TRUE でな ければならない. 要求が失敗した場合は, FALSE でなければならない. サーバが認証を受け入れる場合, 次のメッセージで返答しなければならない; byte SSH_MSG_USERAUTH_SUCCESS 複数の方法で認証を行なう場合のそれぞれのステップで送られるのではなく, 認証が完了した場合にのみ送られることに注意. クライアントは, 前の要求の応答を待つことなしに複数の認証の要求を送って よい. サーバは, それぞれの要求を完全に処理しなければならない. また, 失敗した要求があった場合には, 次の要求を処理する前に SSH_MSG_USERAUTH_ FAILURE メッセージで通知しなければならない. メッセージの交換が何度か必要な要求は,次の要求によって中止されることが ある. クライアントは, 前の要求に対するサーバの応答を受け取っていなけれ ば, 次の要求を送ってはならない. 中止された認証法については, SSH_MSG_U SERAUTH_FAILURE メッセージを送ってはならない. SSH_MSG_USERAUTH_SUCCESS は1回のみ送られなければならない. SSH_MSG_USE RAUTH_SUCCESS を送ったら, その後に受け取った認証の要求は静かに無視する 必要がある. SSH_MSG_USERAUTH_SUCCESS が送られた要求のあとでクライアントから送られ る認証には関係のないメッセージは, このプロトコルの上で動作するサービス に渡されなければならない. メッセージは, そのメッセージ番号(6 節を参照 )で識別される.. Ylonen & Lonvick Standards Track [Page 6] RFC 4252 SSH Authentication Protocol January 20 06 5.2. "none" 認証要求 クライアントは, 認証を続行する 'method_name'の値のリストに"none"を含め てもよい. ユーザに認証が必要なければ, サーバは, SSH_MSG_USERAUTH_SUCCESS を返さ なければらなない. さもなければ, サーバは, SSH_MSG_USERAUTH_FAILURE を 返さなければならない. また, サーバは, 認証を続行する 'authentications that can continue' の値のリストに "none" を含めてもよい. サーバから送信する 'method_name' の値には, "none" を挙げてはならない. 5.3. ユーザ認証の完了 サーバが, SSH_MSG_USERAUTH_SUCCESS を返すと, 認証は完了する. このメッ セージが送信されたあとで受け取るすべての認証関係のメッセージは, 静かに 無視される必要がある. サーバは, SSH_MSG_USERAUTH_SUCCESS を送ったら, 要求されたサービスを始 める. 5.4. バナー メッセージ 法的な事情によっては, 認証の前に警告メッセージを送ることで, 法律上な保 護が得られる場合がある. 例えば, 多くのUNIXマシンは, ログインプロンプ トを表示する前に, 通常 /etc/issue からのテキストを表示したり, TCP wrap pers や似たソフトウェアを用いてバナーを表示する. SSHのサーバも, 認証プロトコルが開始してから認証が完了するまでのいつで も, SSH_MSG_USERAUTH_BANNER メッセージを送信できる. このメッセージは, 認証が試みられる前にユーザに表示されるテキストを含んでいる. 形式は以 下の通り: byte SSH_MSG_USERAUTH_BANNER string message in ISO-10646 UTF-8 encoding [RFC3629] string language tag [RFC3066] By default, the client SHOULD display the 'message' on the screen. しかしながら, 'message' はすべてのログインの試行に対して送られるだろう し, この警告のために別のウィンドウを開く必要のあるクライアントもあるだ ろう. このため, クライアントのソフトウェアは, ユーザがサーバからのバナ ーの表示を明示的に無効できるようにしてもよい. この 'message' は複数行 から構成されてもよい. 改行は CRLF のペアで示される. Ylonen & Lonvick Standards Track [Page 7] RFC 4252 SSH Authentication Protocol January 20 06 'message' 文字列を表示するなら, [SSH-ARCH]での議論のように, 端末の制御 文字を利用した攻撃を避けるために制御文字のフィルタを用いる必要がある. 6. 認証プロトコルのメッセージ番号 認証プロトコルで利用されるすべてのメッセージ番号は, 50から79の範囲にあ る. この範囲は, SSHトランスポート層プロトコルの上で動作するプロトコル のために予約された範囲の一部だ. 80以上のメッセージ番号は, 認証プロトコルのあとで動作するプロトコルのた めに予約されている. 認証が完了する前にこの範囲の番号を受けとったらそれ はエラーだ. サーバは, 切断を返答しなければならない. トラブルシューティ ングを容易にするために適切な切断メッセージをM送ることが好ましい. 認証が成功したら, これらのメッセージは高位のサービスに送られる. 以下が, 認証法に依存しない認証メッセージの番号だ. SSH_MSG_USERAUTH_REQUEST 50 SSH_MSG_USERAUTH_FAILURE 51 SSH_MSG_USERAUTH_SUCCESS 52 SSH_MSG_USERAUTH_BANNER 53 上記に加えて, 60 から 79 までの範囲のメッセージ番号は, 認証法に依存す るメッセージに予約されている. これらのメッセージはサーバからのみ送ら れる. (クライアントは,SSH_MSG_USERAUTH_REQUEST メッセージのみを送る.) 異なる認証法は, 同じメッセージ番号を再利用する. 7. 公開鍵認証法: "publickey" 唯一実装を要求されている認証の 'method_name' が "publickey" 認証だ. すべての実装は, この認証法をサポートしなければならない. しかし, すべて のユーザが公開鍵を持つ必要はない. また, 近い将来に多くのローカルなポリ シーがすべてのユーザに対して公開鍵認証を要求することはないだろう. この認証法では, 秘密鍵を所持によって認証を行なう. ユーザの秘密鍵で作 られた署名を送ることで, この認証法は動作する. サーバは, 鍵がユーザの 正当な認証情報かどうかをチェックしなければならない. また, 署名が正当か チェックしなければならない. 以上の両方が成立したら, 認証の要求は受け 入れられなければならない. さもなければ, 拒否されなければならない. 成 功した認証のあとで, サーバは追加の認証を要求してもよいことを注記してお く. Ylonen & Lonvick Standards Track [Page 8] RFC 4252 SSH Authentication Protocol January 20 06 秘密鍵は, しばしばクライアントのホストに暗号化されて保持される. ユーザ は, 署名が生成される前にパスフレーズを提供しなければならない. もしそ れがなくても, 署名の計算は多くの演算能力を必要とする. 不必要な処理と ユーザとの対話を避けるため, "publickey" 認証法を用いた認証が受け入れら れるかどうかを尋ねるために, 以下のメッセージが提供されている. 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-TRANS] で定義されて いる. 'public key blob' は, 証明書を含むかもしれない. どんな公開鍵アルゴリズムが認証のために提供されても構わない. 特に, 鍵交換の際に交渉されたリストに縛られなくてもよい. サーバがアル ゴリズムをサポートしていなければ, 要求を単に拒否しなければならない. サーバは, このメッセージに対して 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 それから, 実際の認証を行なうために, クライアントは, 秘密鍵を用いて生成 した署名を送ってもよい. クライアントは, 鍵が受け入れられるかの最初の 確認なしに直接署名を送ってもよい. 署名は, 次のパケットを用いて送られ る: 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 Ylonen & Lonvick Standards Track [Page 9] RFC 4252 SSH Authentication Protocol January 20 06 '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_SUCCESS で, 認証要求が失敗したり追加の認証が必要 な場合は SSH_MSG_USERAUTH_FAILURE で応答しなければならない. "publickey" 認証法では, 次の認証法特有のメッセージ番号が使われる. SSH_MSG_USERAUTH_PK_OK 60 8. パスワード認証法: "password" パスワード認証は次のパケットを利用する. サーバはユーザにパスワードの 変更を求める要求を送ってもよいことに注意. すべての実装は, パスワード 認証をサポートする必要がある. 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] 'plaintext password' の値は, ISO-10646 UTF-8 でエンコードされることに注意. パスワードをどう解釈しどうパスワ ードのデータベースに対して検証するかは, サーバに委ねられている. しか し, クライアントが別のエンコーディング (たとえば, ISO 8859-1 - ISO Lat in1)でパスワードを取得したなら, 転送前にパスワードを ISO-10646 UTF-8 に変換しなければならない. また. サーバは, システムがパスワードに利用し ているエンコーディングにパスワードを変換しなければならない. Ylonen & Lonvick Standards Track [Page 1 0] RFC 4252 SSH Authentication Protocol January 20 06 国際化の立場から, パスワード認証が行なわれるときに, ユーザの使うOSやク ライアントのソフトウェアに依らずに認証が行なわれることが望ましい. こ のために正規化が必要だ. ASCII以外のパスワードをサポートするシステムは , パスワードとユーザ名をデータベースに追加したり(ハッシュしたり,もしく はせずに)データベース内のエントリと比較する際にいつでも正規化する必要 がある. パスワードを保存したり比較するSSHの実装は, 正規化に[RFC4013]を 使う必要がある. 暗号化されないパスワードがパケットに含まれて転送されるが, パケット全体 はトランスポート層で暗号化されることを注記しておく. サーバとクライア ントは, 基盤となっているトランスポート層が機密性を提供するかどうか(す なわち, 暗号化が使われているかどうか)をチェックしなければならない. 機 密性が提供されない("none" 暗号)場合は, パスワード認証は無効とされる必 要がある. 機密性やMACがない場合には, パスワードの変更は無効とされる必 要がある. 通常, サーバはこのメッセージに対して成功ないし失敗のメッセージで応答す る. しかし, パスワードの有効期限が切れている場合, サーバは, SSH_MSG_U SERAUTH_PASSWD_CHANGEREQ を応答して期限切れを示す必要がある. どんな場合でも, サーバは, 期限切れのパスワードを認証に仕様してはならな い. byte SSH_MSG_USERAUTH_PASSWD_CHANGEREQ string prompt in ISO-10646 UTF-8 encoding [RFC3629] string language tag [RFC3066] このとき, クライアントは別の認証法を試してもよいしユーザに新しいパスワ ードを要求して次のメッセージでパスワード認証を再試行してもよい. クラ イアントは, サーバから要求されない場合でも通常のパスワード認証の要求の 代わりにこのメッセージを送ってもよい. 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] Ylonen & Lonvick Standards Track [Page 1 1] RFC 4252 SSH Authentication Protocol January 20 06 サーバは, それぞれの要求のメッセージに SSH_MSG_USERAUTH_SUCCESS, SSH_M SG_USERAUTH_FAILURE, もしくは SSH_MSG_USERAUTH_PASSWD_CHANGEREQ で応答 しなければならない. これらの意味は以下の通り: SSH_MSG_USERAUTH_SUCCESS - パスワードは変更された. また認証も成功し完 了した. SSH_MSG_USERAUTH_FAILURE with partial success - パスワードは変更された . さらなる認証が必要だ. SSH_MSG_USERAUTH_FAILURE without partial success - パスワードは変更さ れなかった. パスワードの変更がサポートされていないか, 古いパスワード が間違っている. もしサーバが SSH_MSG_USERAUTH_PASSWD_CHANGEREQ を送っ ていたら, サーバはパスワードの変更をサポートしているとみなされることを 注記しておく. SSH_MSG_USERAUTH_CHANGEREQ - 新しいパスワードが受け入れられない(たとえ ば, 容易に推測可能)のでパスワードが変更されなかった. パスワード認証法では, 次の認証法特有のメッセージ番号が使われる. SSH_MSG_USERAUTH_PASSWD_CHANGEREQ 60 9. ホストベース認証: "hostbased" ユーザがやってくるホストとリモートホストでのユーザ名をベースにした認証 を行ないたいサイトもある. この認証法は, 高いセキュリティを求めるサイ トには適していないが, 多くの環境で非常に便利だろう. この認証法は選択 できる. この認証法が使われる場合は, 一般ユーザがホストの秘密鍵を得ら れないようにする特別の注意が払われる必要がある. クライアントは, 次のメッセージを送ることでこの認証法を要求する. これ は, UNIXの "rhosts" と "hosts.equiv" スタイルの認証に似ている. ただし, クライアントホストの識別がより厳格にチェックされることが異なる. この認証法は, クライアントがクライアントホストの秘密鍵で作られた署名を 送りサーバがクライアントホストの公開鍵でチェックすることで動作する. 一度クライアントホストの識別が確立すると, (ユーザの)承認(これ以上認証 は行なわれない)は, サーバでのユーザ名とクライアントでのユーザ名, クラ イアントのホスト名に基づいて行なわれる. Ylonen & Lonvick Standards Track [Page 1 2] RFC 4252 SSH Authentication Protocol January 20 06 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 'public key algorithm for host key'で用いられる公開鍵アルゴリズム名は, トランスポート層の仕様 [SSH-TRANS] で定義されている. 'public host key and certificates for client host' は 証明書を含むかも しれない. '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] サーバは, 以下を検証しなければならない. ホスト鍵が本当にメッセージ中の クライアントホストに属している, クライアントホストのユーザがログインを 許可されているか, 'siggnature' の値が, ホスト鍵に対して正当かどうか. クライアントホストに対してだけ認証したい場合, サーバはクライアントの ' user name' を無視してもよい. (信用されない)ネットワークから得られたネットワークのアドレスとクライア ントのホスト名が一致するかどうかの検証を, 可能な場合いつでもサーバが追 加のチェックとして行なうことが推奨される. これは, 不正なホスト鍵を利用 した攻撃をより難しくする. これは, ファイアウォール越しに来る接続には 特別の扱いが必要となることに注意. Ylonen & Lonvick Standards Track [Page 1 3] RFC 4252 SSH Authentication Protocol January 20 06 10. IANA の考慮 この文書は, (訳注: プロトコルを定義する文書の)集合の一部分だ. [SSH-AR CH], [SSH-TRANS], [SSH-CONNECT] とこの文書で定義される SSH プロトコルに対 する IANA の考慮は, [SSH-NUMBERS] で詳述されている. 11. セキュリティの考察 このプロトコルの目標は, クライアントのユーザ認証を行なうことだ. この プロトコルでは, すでにサーバマシンを認証し暗号化されたコミュニケーショ ンチャンネルを確立しセンションのユニークな識別子を計算した, 安全なトラ ンスポート層プロトコルの上で動くことを仮定した. トランスポート層は, パスワード認証や他の秘密の情報に依存する認証法のために前方秘密性を提供 する. このプトトコルのセキュリティについての考慮のすべては, [SSH-ARCH]で提供 されている. Ylonen & Lonvick Standards Track [Page 1 4] RFC 4252 SSH Authentication Protocol January 20 06 12. References 12.1. Normative References [SSH-ARCH] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. [SSH-CONNECT] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Connection Protocol", RFC 4254, January 2006. [SSH-TRANS] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. [SSH-NUMBERS] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC3066] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005. 12.2. Informative References [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. Ylonen & Lonvick Standards Track [Page 1 5] RFC 4252 SSH Authentication Protocol January 20 06 Authors' Addresses Tatu Ylonen SSH Communications Security Corp Valimotie 17 00380 Helsinki Finland EMail: ylo@ssh.com Chris Lonvick (editor) Cisco Systems, Inc. 12515 Research Blvd. Austin 78759 USA EMail: clonvick@cisco.com Trademark Notice "ssh" is a registered trademark in the United States and/or other countries. Ylonen & Lonvick Standards Track [Page 1 6] RFC 4252 SSH Authentication Protocol January 20 06 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). Ylonen & Lonvick Standards Track [Page 1 7]