Network Working Group T. Ylonen Request for Comments: 4252 SSH Communications Security Corp Category: Standards Track C. Lonvick, Ed. Cisco Systems, Inc. January 2006 セキュア シェル (SSH) 認証プロトコル このメモの位置づけ この文書は, インターネットコミュニティに対するインターネットの標準トラックプロトコルを定義している. また, 改善のための議論と示唆を求めている. このプロトコルの標準化の状態と状況は "Internet Official Protocol Standards" (STD 1) の現在の版を参照してほしい. このメモの配布は制限しない. 著作権情報 Copyright (C) The Internet Society (2006). 訳者: 春山 征吾 . 概要 セキュア シェル (SSH) プロトコルは, 安全ではないネットワーク上での安全なリモートログインや他の安全なネットワークサービスのためのプロトコルだ. この文書は, SSH認証プロトコルのフレームワークと, 公開鍵, パスワード, ホストベース認証法について記述する. 追加の認証法は別のドキュメントに記述される. SSH認証プロトコルは, SSHトランスポート層プロトコルの上で動作し, SSHコネクションプロトコルのための単一の認証されたトンネルを提供する. Ylonen & Lonvick Standards Track [Page 1] RFC 4252 SSH Authentication Protocol January 2006 目次 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 2006 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. この文書で用いる表記 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 2006 4. 認証プロトコルのフレームワーク サーバは, やりとりを続けるためにその時点でどの認証法が利用できるかクライアントに伝えることで認証を始める. クライアントは, サーバによって示された方法をどの順番で試しても構わない. これは, サーバが, もし望むならば, 認証のプロセスを完全に制御できることを意味する. 一方で, サーバから複数の方法が提供された場合に, クライアントがサポートしていたりユーザにもっとも便利な認証法を利用可能な自由度も提供する. 認証法は, [SSH-ARCH]で定義されているように, その名前で識別される. "none" は予約されている. しかし, サポートしている認証法として示してはならない. しかし, これはクライアント側から送られてもよい. サーバは, この要求を常に拒否しなければならない. ただし, クライアントが認証なしで正当なアクセスができる場合に限っては, サーバはこの要求を受け入れなければならない. この要求を送る主要な目的は, サーバからサポートしている認証法のリストを得ることだ. サーアは, 認証のタイムアウト期間を持つ必要がある. また, そのタイムアウト期間内に認証が受け入れられなかった場合に切断する必要がある. 推奨されるタイムアウト期間は, 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 2006 認証の状態を消去できない場合に, 'user_name' か 'service_name' が変更されたらサーバの実装は切断しなければならない. 'service name' は, 認証後に開始するサービスを指定する. いくつかの異なる認証されたサービスが提供されることがある. 要求されたサービスが利用可能ではない場合, サーバはすぐに切断してもよいし後のいかなる時に切断してもよい. 正当な切断メッセージを送ることが推奨される. どちらにせよ, サービスが存在しないなら, 認証を受け入れてはならない. 要求された'user_name'が存在しない場合, サーバは切断してもよいし, 'method_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 2006 '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_USERAUTH_FAILURE メッセージを送ってはならない. SSH_MSG_USERAUTH_SUCCESS は1回のみ送られなければならない. SSH_MSG_USERAUTH_SUCCESS を送ったら, その後に受け取った認証の要求は静かに無視する必要がある. SSH_MSG_USERAUTH_SUCCESS が送られた要求のあとでクライアントから送られる認証には関係のないメッセージは, このプロトコルの上で動作するサービスに渡されなければならない. メッセージは, そのメッセージ番号(6 節を参照)で識別される. Ylonen & Lonvick Standards Track [Page 6] RFC 4252 SSH Authentication Protocol January 2006 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 wrappers や似たソフトウェアを用いてバナーを表示する. 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 2006 '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 2006 秘密鍵は, しばしばクライアントのホストに暗号化されて保持される. ユーザは, 署名が生成される前にパスフレーズを提供しなければならない. もしそれがなくても, 署名の計算は多くの演算能力を必要とする. 不必要な処理とユーザとの対話を避けるため, "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 2006 '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 Latin1)でパスワードを取得したなら, 転送前にパスワードを ISO-10646 UTF-8 に変換しなければならない. また. サーバは, システムがパスワードに利用しているエンコーディングにパスワードを変換しなければならない. Ylonen & Lonvick Standards Track [Page 10] RFC 4252 SSH Authentication Protocol January 2006 国際化の立場から, パスワード認証が行なわれるときに, ユーザの使うOSやクライアントのソフトウェアに依らずに認証が行なわれることが望ましい. このために正規化が必要だ. ASCII以外のパスワードをサポートするシステムは, パスワードとユーザ名をデータベースに追加したり(ハッシュしたり,もしくはせずに)データベース内のエントリと比較する際にいつでも正規化する必要がある. パスワードを保存したり比較するSSHの実装は, 正規化に[RFC4013]を使う必要がある. 暗号化されないパスワードがパケットに含まれて転送されるが, パケット全体はトランスポート層で暗号化されることを注記しておく. サーバとクライアントは, 基盤となっているトランスポート層が機密性を提供するかどうか(すなわち, 暗号化が使われているかどうか)をチェックしなければならない. 機密性が提供されない("none" 暗号)場合は, パスワード認証は無効とされる必要がある. 機密性やMACがない場合には, パスワードの変更は無効とされる必要がある. 通常, サーバはこのメッセージに対して成功ないし失敗のメッセージで応答する. しかし, パスワードの有効期限が切れている場合, サーバは, SSH_MSG_USERAUTH_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 11] RFC 4252 SSH Authentication Protocol January 2006 サーバは, それぞれの要求のメッセージに SSH_MSG_USERAUTH_SUCCESS, SSH_MSG_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 12] RFC 4252 SSH Authentication Protocol January 2006 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 13] RFC 4252 SSH Authentication Protocol January 2006 10. IANA の考慮 この文書は, (訳注: プロトコルを定義する文書の)集合の一部分だ. [SSH-ARCH], [SSH-TRANS], [SSH-CONNECT] とこの文書で定義される SSH プロトコルに対する IANA の考慮は, [SSH-NUMBERS] で詳述されている. 11. セキュリティの考察 このプロトコルの目標は, クライアントのユーザ認証を行なうことだ. このプロトコルでは, すでにサーバマシンを認証し暗号化されたコミュニケーションチャンネルを確立しセンションのユニークな識別子を計算した, 安全なトランスポート層プロトコルの上で動くことを仮定した. トランスポート層は, パスワード認証や他の秘密の情報に依存する認証法のために forward secrecy を提供する. このプロトコルのセキュリティについての考慮のすべては, [SSH-ARCH]で提供されている. Ylonen & Lonvick Standards Track [Page 14] RFC 4252 SSH Authentication Protocol January 2006 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 15] RFC 4252 SSH Authentication Protocol January 2006 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 16] RFC 4252 SSH Authentication Protocol 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). Ylonen & Lonvick Standards Track [Page 17]