Network Working Group J. Hutzelman Request for Comments: 4462 CMU Category: Standards Track J. Salowey Cisco Systems J. Galbraith Van Dyke Technologies, Inc. V. Welch U Chicago / ANL May 2006 セキュア シェル (SSH) プロトコルのための汎用セキュリティサービスアプリケーションプログラムインタフェイス(GSS-API) 認証と鍵交換 このメモの位置づけ この文書は, インターネットコミュニティに対するインターネットの標準トラックプロトコルを定義している. また, 改善のための議論と示唆を求めている. このプロトコルの標準化の状態と状況は "Internet Official Protocol Standards" (STD 1) の現在の版を参照してほしい. このメモの配布は制限しない. 著作権情報 Copyright (C) The Internet Society (2006). 訳者: 春山 征吾 . 概要 セキュア シェル (SSH) プロトコルは, 安全ではないネットワーク上での安全なリモートログインや他の安全なネットワークサービスのためのプロトコルだ. 汎用セキュリティサービスアプリケーションプログラムインタフェイス (GSS-API) はメカニズムに依存しない形式でセキュリティサービスを呼び出し側に提供する. このメモは, SSHで認証と鍵交換のためにGSS-APIを使う方法を記述する. ユーザを認証する特定のGSS-APIメカニズムを用いるSSHユーザ認証法と Diffie-Hellman 鍵交換を認証するためにGSS-APIを用いるSSHの鍵交換法のファミリを定義する. このメモは, ホスト公開鍵の利用になにも操作が必要ではない新しいホスト公開鍵アルゴリズムも定義する. さらに, GSS-APIベースの鍵交換の副作用として生じたどの認証に対しても連携して利用できる新しいユーザ認証法も定義する. Hutzelman, et al. Standards Track [Page 1] RFC 4462 SSH GSS-API Methods May 2006 目次 1イントロダクション ....................................................3 1.1. SSH の用語 ............................................3 1.2. キーワード ..................................................3 2. GSS-API に認証された Diffie-Hellman 鍵交換 ..............3 2.1. 汎用 GSS-API 鍵交換 ...............................4 2.2. 群の交換 ............................................10 2.3. gss-group1-sha1-* .........................................11 2.4. gss-group14-sha1-* ........................................12 2.5. gss-gex-sha1-* ............................................12 2.6. その他の GSS-API 鍵交換法 ........................12 3. GSS-API ユーザ認証 ....................................13 3.1. GSS-API 認証の概要 ...........................13 3.2. GSS-API 認証の開始 .........................13 3.3. 最初のサーバの応答 ...................................14 3.4. GSS-API セッション ...........................................15 3.5. 暗号鍵の束縛 ...................................16 3.6. クライアントの確認応答 ....................................16 3.7. 完了 ................................................17 3.8. エラー状態 ..............................................17 3.9. エラートークン ...............................................18 4. GSS-API 鍵交換を利用する認証 ......................19 5. null ホスト鍵アルゴリズム ........................................20 6. メッセージ番号のまとめ .....................................21 7. GSS-API の考察 .........................................22 7.1. 命名規則 ........................................22 7.2. チャンネルの束縛 ..........................................22 7.3. SPNEGO ....................................................23 8. IANA の考慮 ............................................24 9. セキュリティの考察 ........................................24 10. Acknowledgements ..............................................25 11. References ....................................................26 11.1. Normative References .....................................26 11.2. Informative References ...................................27 Hutzelman, et al. Standards Track [Page 2] RFC 4462 SSH GSS-API Methods May 2006 1イントロダクション この文書は, GSS-APIを用いてセキュアシェルプロトコルで鍵交換とユーザ認証を行なう方法を記述する. このために, 鍵交換法のファミリと2つのユーザ認証法, 新しいホスト鍵アルゴリズムを定義する. これらの定義によって, セキュアシェルプロトコルと共に任意のGSS-APIメカニズムを利用できる. この文書は SSHプロトコルアーキテクチャ [SSH-ARCH], トランスポート層プロトコル [SSH-TRANSPORT], ユーザ認証プロトコル [SSH-USERAUTH] を読んでからのみ読むべきだ. この文書は, 参照や説明なしにアーキテクチャ文書から用語や表記法を自由に利用する. 1.1. SSHの用語 パケットで利用しているデータのタイプは, アーキテクチャ文書 [SSH-ARCH] で定義されている. 文字列の定義がバイナリの内容を許していることに注意することが特に重要だ. SSH_MSG_USERAUTH_REQUEST パケットはサービスを参照する. このサービス名は SSHのサービス名で GSS-APIのサービス名とは無関係だ. 現在, (この場面で)唯一定義されたサービス名は "ssh-connection" で, SSH コネクションプロトコル [SSH-CONNECT] を参照する. 1.2. キーワード この文書でのキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" は, [KEYWORDS] で記述されているように解釈される. 2. GSS-API に認証された Diffie-Hellman 鍵交換 この節では, [SSH-TRANSPORT]の8節の Diffie-Hellman 鍵交換とGSS-APIを用いた相互認証とを組合せた鍵交換法のクラスを定義する. この節で記述するGSS-API 鍵交換法は, 公開鍵の署名や暗号アルゴリズムの利用を必要としないので, 5節で記述する "null" アルゴリズムを含むどのホスト鍵アルゴリズムに対しても利用してもよい. Hutzelman, et al. Standards Track [Page 3] RFC 4462 SSH GSS-API Methods May 2006 2.1. 汎用 GSS-API 鍵交換 この記述では次の記号を利用する: o C はクライアントでSはサーバだ o p は安全な大きな素数で, gは GF(p)の部分群の生成器, qは部分群のオーダだ. o V_S は Sのバージョン文字列, V_C は Cのバージョン文字列だ. o I_C は C の KEXINIT メッセージ, I_S は S の KEXINIT メッセージだ. 1C は 乱数 x (1 < x < q) を生成し, e = g^x mod p を計算する. 2. C は GSS_Init_sec_context() を呼ぶ. この交換でSからもっとも最近受信した応答トークンがあれば, それを用いる. この呼び出しでは, クライアントは相互認証の実行を要求するために mutual_req_flag を "true" に設定しなければならない. また, この文脈でメッセージ単位での完全性保護のサポートを要求するため, integ_req_flag も "true" に設定しなければならない. 加えて, ユーザが求めるならば アクセスの委譲を要求するために deleg_req_flag を "true" に設定してもよい. 鍵交換プロレスはホストのみ認証するので, anon_req_flag の設定は重要ではない. クライアントが 4節で記述する "gssapi-keyex" ユーザ認証をサポートしていなかったり, 鍵交換時に確立した GSS-APIコンテクストと連携した方法を使おうとしない場合は, anon_req_flag は "true" に設定する必要がある. もしくは, クライアントがそのアイデンティティを隠そうとする場合にこのフラグを true に設定してもよい. 一度コンテクストが確立されると鍵交換プロセスは単一のトークンの交換のみ実行されるので, GSS-APIコンテクストは再送やシーケンスを外れたトークンの検出をサポートする必要はない. このため, replay_det_req_flag と sequence_req_flag はこのプロセスでは設定する必要がない. これらのフラグは "false" に設定する必要がある. * 結果の major_status コードが GSS_S_COMPLETE で mutual_state フラグが trueでなければ, 相互認証は確立していないので鍵交換は失敗しなければならない. * 結果の major_status コードが GSS_S_COMPLETE で integ_avail フラグが trueでなければ, メッセージ単位の完全性保護が利用できないので鍵交換は失敗しなければならない. * 結果の major_status コードが GSS_S_COMPLETE で mutual_state と integ_avail フラグが共に trueなら, 結果のoutput tokenをSに送る. Hutzelman, et al. Standards Track [Page 4] RFC 4462 SSH GSS-API Methods May 2006 * 結果の major_status コードが GSS_S_CONTINUE_NEEDED なら, Sに output_token を送り, Sは GSS_Init_sec_context() に提供される新しい token で応答する. * クライアントは, このプロセスでサーバに送る最初のメッセージに "e" を含めなければならない. サーバが1つより多い"e"を受けとったりまったく受け取らなかったら, 鍵交換は失敗する. * 呼び出しがサーバに送信される0でない長さのトークンを生成できなかったらエラーだ. この場合, 鍵交換は失敗しなければならない. 3. S は, Cから受け取ったトークンを用いて GSS_Accept_sec_context() を呼ぶ. * 結果の major_status コードが GSS_S_COMPLETE で mutual_state フラグが trueでなければ, 相互認証は確立していないので鍵交換は失敗しなければならない. * 結果の major_status コードが GSS_S_COMPLETE で integ_avail フラグが trueでなければ, メッセージ単位の完全性保護が利用できないので鍵交換は失敗しなければならない. * 結果の major_status コードが GSS_S_COMPLETE で mutual_state と integ_avail フラグが共に trueなら, セキュリティコンテキストが確立された. ステップ4 から処理が続けられる. * 結果の major_status コードが GSS_S_CONTINUE_NEEDED なら, Cに output トークンを送って, ステップ2から処理が続けられる. * 結果のmajor_status コードが GSS_S_COMPLETE だが 長さが0ではない応答トークンが返されたなら, そのトークンがクライアントに送られる. 4. S は乱数 y (0 < y < q) を生成し f = g^y mod p を計算する. K = e ^ y mod p, と H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K) を計算する. Hに対する GSS-API メッセージ完全性コードを得るために GSS_GetMIC() を呼ぶ. そして S は Cに f と メッセージ完全性コード(MIC)を送る. 5. (1) サーバの最後の GSS_Accept_sec_context() 呼び出しが, クライアントに送られる0でない最終応答トークンを生成し, (2) クライアントの GSS_Init_sec_context() のそれまでの呼び出しが major_status が GSS_S_COMPLETE である結果を生成しなかった場合にのみ, このステップは実行される. Hutzelman, et al. Standards Track [Page 5] RFC 4462 SSH GSS-API Methods May 2006 この状態このとき, クライアントは, 最終の応答トークンの処理に, GSS_Init_sec_context() を追加で呼び出す. この呼び出しは, 前述のとおりに行なわれる. しかし, 結果の major_status が GSS_S_COMPLETE でなかったり 0でないトークンが返されたら, これはエラーで鍵交換は失敗しなければならない. 6. K = e ^ y mod p, と H = hash(V_C || V_S || I_C || I_S || K_S || e || f || K) を Cは計算する. そして GSS_VerifyMIC() を呼び出し, Sから送られたMICが H と一致するか検証する. MIC の検証に失敗したら鍵交換は失敗しなければならない. どちらの側も [1, p-1]の範囲にない e や f の値を送ったり受け入れたりしてはならない. この条件に違反したら, 鍵交換は失敗する. GSS_Init_sec_context() や GSS_Accept_sec_context() の呼び出しで GSS_S_COMPLETE か GSS_S_CONTINUE_NEEDED 以外の major_status コードが返ったり, 他の GSS-APIの呼び出しで GSS_S_COMPLETE 以外の major_status コードが返ったら, 鍵交換は失敗する. このとき, [SSH-TRANSPORT] によって 接続を終了する前に必要に応じて相手にエラー情報を伝えるいくつかのメカニズムが提供されている. o (GSS_Accept_sec_context() によって返されるエラーを含む) サーバ側の GSS-API のエラーのために鍵交換が失敗する場合は, エラーの詳細をクライアントに知らせるメッセージをサーバは送ってもよい. この場合, エラートークンも送るならば(下記参照), このメッセージはエラートークンの前に送らなければならない. o GSS_Accept_sec_context() のサーバの呼び出しから GSS-APIエラーが返ったために鍵交換が失敗しまた"エラートークン"も返されたならば, サーバはクライアントに GSSセキュリティ交換の完了を許可するためにエラートークンを送る必要がある. o クライアントのGSS_Init_sec_context()で GSS-API エラーが返ったことによって鍵交換が失敗し"エラートークン"も返されたならあ, クライアントはサーバにGSSセキュリティ交換の完了を許可するためにエラートークンを送る必要がある. 9節で述べるように, エラーの詳細な性質の情報は隠したほうがサイトのセキュリティポリシー上望ましいかもしれない; つまり, ポリシーの問題としてこれらのメッセージを抑制する方法を実装が提供することが望ましい. これは, 次のメッセージ群で実装される. 交換ハッシュを計算するハッシュ関数は, 方法の名前で定義される. これを HASH と呼ぶ. Diffie-Hellman 鍵交換と基底にある GSS-API メカニズムで用いる群も, その方法の名前で定義される. Hutzelman, et al. Standards Track [Page 6] RFC 4462 SSH GSS-API Methods May 2006 クライナントは, 最初の GSS_Init_sec_context() の呼び出しの後で以下を送る: byte SSH_MSG_KEXGSS_INIT string output_token (from GSS_Init_sec_context()) mpint e この SSH_MSG_KEXGSS_INIT メッセージを受けとったら, サーバは, ホスト鍵をクライアントに知らせるために, 他のメッセージより前に次のメッセージを送ってもよい. byte SSH_MSG_KEXGSS_HOSTKEY string server public host key and certificates (K_S) この鍵交換法は暗号の操作でホスト鍵を利用しないので, このメッセージは選択できる. 5節で記述する "null" ホスト鍵アルゴリズムを利用する場合は, このメッセージを送ってはならない. このメッセージが送られる場合, このメッセージ中のサーバホスト鍵 と/もしくは 証明書は, 利用している公開鍵タイプで指定されたフォーマットで単一の文字列としてエンコードされる([SSH-TRANSPORT]の6.6節を参照) 伝統的なSSHの配置では, ホスト鍵は通常めったに変更されず, クライアントが事前に知らないホスト鍵を検証するためのメカニズムはないことが多い. 結果として, 既知のホストが新しいホスト鍵を用いると, 通常は中間者攻撃の指標だと考えられ, クライアントはこのような場合に強い警告を出す かつ/もしくは 接続を中断する ことが多い. 対照的に, GSS-API ベースの鍵交換が利用される場合は, SSH_MSG_KEXGSS_HOSTKEY メッセージで送られるホスト鍵は, クライアントが事前に知らない場合でも, GSS-API 鍵交換の一部として認証される. さらに, GSS-API ベースの鍵交換がよく利用される環境では, ホスト鍵は非常に頻繁に かつ/もしくは 事前の警告なしに変わる可能性がある. このため, SSH_MSG_KEXGSS_HOSTKEY メッセージで既知のホストから新しい鍵を受け取っても, GSS-APIベースの鍵交換が成功するならば, クライアントは強い警告の発行や接続の中断をしないほうがよい. ユーザの GSS-API 認証の期限が切れたあとで鍵の再交換を支援するため, クライアントの実装は, SSH_MSG_KEXGSS_HOSTKEY で受け取ったホスト鍵を, 長期間保持しない場合でも, セッションの持続中は保持する必要がある. Hutzelman, et al. Standards Track [Page 7] RFC 4462 SSH GSS-API Methods May 2006 GSS_Accept_sec_context() のサーバでの呼び出しが major_status コードとして GSS_S_CONTINUE_NEEDEDを返すたびに, サーバは次の応答をクライアントに送る: byte SSH_MSG_KEXGSS_CONTINUE string output_token (from GSS_Accept_sec_context()) GSS_Init_sec_context() が major_status コードとして GSS_S_COMPLETE を返したあとでこのメッセージをクライアントが受けとったならば, プロトコルエラーが起きており鍵交換は失敗しなければならない. クライアントは上記のメッセージを受け取る度に,GSS_Init_sec_context()をまた呼び出さなければならない. そして 以下を送る. byte SSH_MSG_KEXGSS_CONTINUE string output_token (from GSS_Init_sec_context()) GSS_Accept_sec_context() のサーバでの呼び出しで major_status コード が GSS_S_CONTINUE_NEEDED となっている限り, サーバとクライアントはこの2つのメッセージをやりとりし続ける. 呼び出しで major_status コードが GSS_S_COMPLETE となったなら, 2つの最終メッセージのうちの1つをサーバは送る. サーバの最後の (major_status コードが GSS_S_COMPLETE となった) GSS_Accept_sec_context() 呼び出しが クライアントに送るための0でない長さのトークンを返したら, サーバは以下を送る: byte SSH_MSG_KEXGSS_COMPLETE mpint f string per_msg_token (MIC of H) boolean TRUE string output_token (from GSS_Accept_sec_context()) GSS_Init_sec_context() が major_status コードとして GSS_S_COMPLETE を返したあとでこのメッセージをクライアントが受けとったならば, プロトコルエラーが起きており鍵交換は失敗しなければならない. サーバの最後の (major_status コードが GSS_S_COMPLETE となった) GSS_Accept_sec_context() 呼び出しが クライアントに送るための長さ0のトークンを返したりトークンを返さなかったら, サーバは以下を送る: byte SSH_MSG_KEXGSS_COMPLETE mpint f string per_msg_token (MIC of H) boolean FALSE Hutzelman, et al. Standards Track [Page 8] RFC 4462 SSH GSS-API Methods May 2006 GSS_Init_sec_context() の呼び出しで major_status コードが GSS_S_COMPLETE になっていないのにこのメッセージをクライアントが受けとったならば, プロトコルエラーが起きており鍵交換は失敗しなければならない. GSS_Init_sec_context() のクライアントでの呼び出しか GSS_Accept_sec_context() のサーバでの呼び出しでエラー状態が返され, ("エラートークン"と呼ばれる) 出力トークンが生成されたら, 相手側にエラー情報を伝えるために次を送る必要がある. byte SSH_MSG_KEXGSS_CONTINUE string error_token このメッセージと SSH_MSG_KEXGSS_ERROR メッセージの両方をサーバが送る場合は, エラートークンの処理の前にクアイアントがエラー情報を記録したり表示したりできるように, SSH_MSG_KEXGSS_ERROR メッセージを先に送らなければならない. エラートークンを処理するクライアントがそれ以上のメッセージを読むことなく切断できるので, これは重要だ. GSS-APIエラーがサーバで起きたら, サーバは接続の切断の前に次のメッセージを送ってもよい: byte SSH_MSG_KEXGSS_ERROR uint32 major_status uint32 minor_status string message string language tag message テキストは [UTF8] に記述されている UTF-8 エンコーディングでエンコードされてなければならない. language タグは [LANGTAG] に記述されているものだ. 注意: message text はキャリッジリターン-ラインフィード (CRLF) シーケンスで区切られた複数行を含むかもしれない. これらのメッセージを表示するアプリケーション開発者は, 複数行あるかもしれないことに注意しなければならない. ハッシュ H は, 次の連結に対する HASH の結果だ: string V_C, the client's version string (CR, NL excluded) string V_S, the server's version string (CR, NL excluded) string I_C, the payload of the client's SSH_MSG_KEXINIT string I_S, the payload of the server's SSH_MSG_KEXINIT string K_S, the host key mpint e, exchange value sent by the client mpint f, exchange value sent by the server mpint K, the shared secret Hutzelman, et al. Standards Track [Page 9] RFC 4462 SSH GSS-API Methods May 2006 この値は交換ハッシュと呼ばれる. 鍵交換を認証するのに用いられる. 交換ハッシュは秘密にする必要がある. SSH_MSG_KEXGSS_HOSTKEY メッセージがサーバから送られたりクライアントで受け取られたりしていなければ, 交換ハッシュの計算で K_S には空文字列を利用する. GSS_GetMIC の呼び出しは 元データではなく Hに対して適用されなければならない. 2.2. 群の交換 この節では， [GROUP-EXCHANGE] で記述されたものをベースにした方法を用いて利用される群を交渉して決められるようにするための， 汎用GSS-APIで認証される Diffie-Hellman 鍵交換への変更を記述する． サーバは, サーバが選択できる安全な素数のリストと対応する生成器を保持する. これらは， [GROUP-EXCHANGE]の3節で記述されているように選ばれる．クライアントはサーバから法(modulus)を, 最小値， 最大値， 推奨のサイズを指定して， 要求する． サーバは適切な法と生成器で応答する．そして交換は， 2.1節で前述したように進行する． 上記で定義したものに加えて， 次のシンボルをこの記述では用いる． o n は， クライアントがサーバから受け取りたい法 p の bit でのサイズ o min と max は クライアントが許容できる p の bit での最小値と最大値 1C は S に "min || n || max" を送り, 群のサイズの最小受容値と希望値, 最大値をbitで示す. 2. S はクライアントの要求に一番一致する群を見つけ C に "p || g" を送る. 3. そして交換は， 2.1節で前述したように， ステップ1から始まって進行する． 以下で記述する交換ハッシュの計算は除く． サーバとクライアントは, 法の長さ k が1024 <= k <= 8192 である群をサポートする必要がある. min と max の推奨値はそれぞれ 1024 と 8192 だ. 上記で定義したものに加えて， 次のメッセージをこの記述では用いる． Hutzelman, et al. Standards Track [Page 10] RFC 4462 SSH GSS-API Methods May 2006 まず, クライアントは以下を送る: byte SSH_MSG_KEXGSS_GROUPREQ uint32 min, minimal size in bits of an acceptable group uint32 n, preferred size in bits of the group the server should send uint32 max, maximal size in bits of an acceptable group サーバは以下で応答する. byte SSH_MSG_KEXGSS_GROUP mpint p, safe prime mpint g, generator for subgroup in GF(p) 2．1 節で前述したメッセージ交換が続く． ただし， 交換ハッシュ H は， 次の連結の HASH でのハッシュとして計算される． string V_C, the client's version string (CR, NL excluded) string V_S, the server's version string (CR, NL excluded) string I_C, the payload of the client's SSH_MSG_KEXINIT string I_S, the payload of the server's SSH_MSG_KEXINIT string K_S, the host key uint32 min, minimal size in bits of an acceptable group uint32 n, preferred size in bits of the group the server should send uint32 max, maximal size in bits of an acceptable group mpint p, safe prime mpint g, generator for subgroup in GF(p) mpint e, exchange value sent by the client mpint f, exchange value sent by the server mpint K, the shared secret 2.3. gss-group1-sha1-* この種類のメソッドのそれぞれは， 2．1 節で記述した SHA-1をHASHとするGSS-APIで認証される Diffie-Hellman 鍵交換 と [SSH-TRANSPORT]の8．1節で定義した群を指定します．各方法の方法名は， 文字列 "gss-group1-sha1-" と， 基底のGSS-API メカニズムオブジェクト識別子 (OID) の ASN.1Distinguished Encoding Rules (DER) エンコーディング [ASN1] の MD5 ハッシュの Base64 エンコーディングの連結Base64 エンコーディングは， [MIME] の 6．8節に記述されている． このような鍵交換法1つ1つすべてが， この指定によって暗黙的に登録される．IESG はこのすべての鍵交換法のオーナーと見なされる． これは， IESG が基底の GSS-API メカニズムのオーナーであることを意味しないことに注意． Hutzelman, et al. Standards Track [Page 11] RFC 4462 SSH GSS-API Methods May 2006 2.4. gss-group14-sha1-* この種類のメソッドのそれぞれは， 2．1 節で記述した SHA-1をHASHとするGSS-APIで認証される Diffie-Hellman 鍵交換 と [SSH-TRANSPORT]の8．2節で定義した群を指定します．各方法の方法名は， 文字列 "gss-group14-sha1-" と， 基底のGSS-API の OID の ASN.1 DER エンコーディング [ASN1] の MD5 ハッシュの Base64 エンコーディングの連結だ．Base64 エンコーディングは， [MIME] の 6．8節に記述されている． このような鍵交換法1つ1つすべてが， この指定によって暗黙的に登録される．IESG はこのすべての鍵交換法のオーナーと見なされる． これは， IESG が基底の GSS-API メカニズムのオーナーであることを意味しないことに注意． 2.5. gss-gex-sha1-* この種類のメソッドのそれぞれは， 2．2 節で記述した SHA-1をHASHとするGSS-APIで認証される Diffie-Hellman 鍵交換 を指定します．各方法の方法名は， 文字列 "gss-gex-sha1-" と， 基底のGSS-API メカニズム OID の ASN.1 DER エンコーディング [ASN1] の MD5 ハッシュの Base64 エンコーディングの連結だ． Base64 エンコーディングは， [MIME] の 6．8節に記述されている． このような鍵交換法1つ1つすべてが， この指定によって暗黙的に登録される．IESG はこのすべての鍵交換法のオーナーと見なされる． これは， IESG が基底の GSS-API メカニズムのオーナーであることを意味しないことに注意． 2.6. その他の GSS-API 鍵交換法 "gss-" で始まる鍵交換法名は， この文書に適合する鍵交換法のために予約されている． 具体的には， 異なる群 かつ/もしくは ハッシュ関数を用いるすべての将来の方法を含む 2．1節で記述した GSS-APIで認証される Diffie-Hellman 鍵交換アルゴリズムを用いるその他の方法のために予約されている．すべての将来の方法の名前が， 2．3節で用いられたものと同じように定義されることを意図している． Hutzelman, et al. Standards Track [Page 12] RFC 4462 SSH GSS-API Methods May 2006 3. GSS-API ユーザ認証 この節では， [GSSAPI]に基づく汎用の目的に利用できるユーザ認証法を記述する．SSH 認証プロトコル [SSH-USERAUTH] 上で動くことが目的だ． このプロトコルの認証法名は "gssapi-with-mic" だ. 3.1. GSS-API 認証の概要 GSS-API 認証はコンテキストを維持しなければならない．認証は， クライアントが， サポートするメカニズムのOIDを指定する SSH_MSG_USERAUTH_REQUEST を送ることで始まる． サーバが要求されたメカニズムのOIDのどれかをサポートしていたら， サーバはメカニズムのOIDを含む SSH_MSG_USERAUTH_GSSAPI_RESPONSE を返す． クライアントが SSH_MSG_USERAUTH_GSSAPI_RESPONSE を受け取ったら， 認証メカニズムが成功か失敗するまで SSH_MSG_USERAUTH_GSSAPI_TOKEN パケットをクライアントとサーバで交換する． 交換中いつでもクライアントは新しい SSH_MSG_USERAUTH_REQUEST パケットを送れる． このとき GSS-API コンテキストは完全に破棄され破壊される． 次のGSS-API認証は最初から始められなければならない． 認証が成功され空でないユーザ名がクライアントから提示されたら， SSHのサーバ実装は， GSS-API交換で交換した認証情報に基づいてユーザ名が認可されるか確認する．ユーザ名が認可されていなければ， 認証は失敗しなければならない． 3.2. GSS-API 認証の開始 GSS-API 認証法はクライアントが SSH_MSG_USERAUTH_REQUEST を送ることで開始される． byte SSH_MSG_USERAUTH_REQUEST string user name (in ISO-10646 UTF-8 encoding) string service name (in US-ASCII) string "gssapi-with-mic" (US-ASCII method name) uint32 n, the number of mechanism OIDs client supports string[n] mechanism OIDs メカニズムの OID は [ASN1] と [GSSAPI]の3．1節で記述されているように ASN.1 Distinguished Encoding Rules (DER) に従ってエンコードされる． Hutzelman, et al. Standards Track [Page 13] RFC 4462 SSH GSS-API Methods May 2006 メカニズム OID は優先順にリストされなければならない． サーバはリストの中でサポートする最初のメカニズム OID を選択しなければならない． クライアントは 非 GSS-API な認証法と同じ優先度の GSS-API メカニズム OID のみを送信する必要がある．そうでなければ， 認証法は順不同で実行されるかもしれない．つまり， クライアントは最初に ある GSS-API メカニズム についての SSH_MSG_USERAUTH_REQUEST を送り， 次に公開鍵認証を試し， そして 別の GSS-API メカニズムを試すことができる． サーバが指定された OID をどれもサポートしていなければ， SSH_MSG_USERAUTH_FAILURE パケットを送信してサーバは要求を失敗させなければならない． GSS-APIの結果からユーザ名が推定できる場合は， ユーザ名は空文字列でもよい．ユーザ名が空でなく要求されたユーザが存在しなければ， サーバは切断してもよい． もしくは 許容できる認証の偽のリスト(どの認証も受け入れられることはない)を送ってもよい．これにより， アカウントが存在するかの情報をサーバが漏らすのを避けることができる．どちらの場合でもユーザが存在しなければ， 認証の共有を受け入れてはならない． 注意： 'user name' の値は ISO-10646 UTF-8 でエンコードされる．ユーザ名がどう解釈されGSS-APIの認証情報に基づいてクライアントが認可されるかどう決定するかは， サーバ次第だ． 特に， ユーザ名のためにシステムが用いるエンコーディングは， SSHのサーバの実装の問題だ．しかし， クライアントがその他のエンコーディング(たとえば ISO 8859-1 - ISO Latin1) でユーザ名を読み取ったら， クライアントは転送前に ISO-10646 UTF-8 へユーザ名を変換しなければならない． サーバは， ユーザ名のためにシステムで利用しているエンコーディングにユーザ名を変換しなければならない． システムの要求に基づいてサーバによって行なわれる 名前の正規化や処理は SSHの範囲外だ秘密のユーザデータベースを維持するSSHの実装は [SASLPREP] に記述されているようにユーザ名を前処理しなければならない． クライアントは， いつでも 新しい SSH_MSG_USERAUTH_REQUEST を送ってよい． このとき， サーバはこれまでの認証の試行を放棄し新しいもので継続しなければならない． 3.3. 最初のサーバの応答 SSH_MSG_USERAUTH_REQUEST に対してサーバは， どのメカニズムもサポートしていない場合にSSH_MSG_USERAUTH_FAILURE を返す． そうでなければ 次の SSH_MSG_USERAUTH_GSSAPI_RESPONSE を返す． Hutzelman, et al. Standards Track [Page 14] RFC 4462 SSH GSS-API Methods May 2006 byte SSH_MSG_USERAUTH_GSSAPI_RESPONSE string selected mechanism OID メカニズムの OID は， SSH_MSG_USERAUTH_REQUEST パケットでクライアントから送られた OIDの1つでなければならない． 3.4. GSS-API セッション メカニズムのOIDが選択されたら， SSH_MSG_USERAUTH_GSSAPI_TOKEN パケットの1つないしそれ以上のペアをクライアントは交換しはじめる．これらのパケットは， 'GSS_Init_sec_context()' と 'GSS_Accept_sec_context()' の呼び出しから生成されたトークンを含む．交換されるパケットの実際の数は， 基底のGSS-API メカニズムで決定される． byte SSH_MSG_USERAUTH_GSSAPI_TOKEN string data returned from either GSS_Init_sec_context() or GSS_Accept_sec_context() この交換の間にサーバ側でエラーが起きたら， SSH_MSG_USERAUTH_FAILURE パケットをサーバは送って認証法を終了してよい．クライアント側でエラーが起きたら， 新しい SSH_MSG_USERAUTH_REQUEST パケットをクライアントが送って現在の認証法を終了してよい． クライアントがGSS_Init_sec_context() を呼ぶ際， このコンテキストでメッセージ単位の完全性保護のサポートを要求するため， integ_req_flag を "true" に設定しなければならない．加えて， ユーザが要求したら， アクセスの以上を要求するために deleg_req_flag を true に設定してもよい． ユーザ認証プロセスは， その性質上クライアントのみを認証するので，mutual_req_flag の設定はこのプロセスでは必要ない．このフラグは "false" に設定する必要がある． 一度コンテクストが確立されると鍵交換プロセスは単一のトークンの交換のみ実行されるので, コンテクストは再送やシーケンスを外れたトークンの検出をサポートする必要はない. このため, replay_det_req_flag と sequence_req_flag はこのプロセスでは設定する必要がない. これらのフラグは "false" に設定する必要がある. GSS-API ルーチンの呼び出しが0でない長さの送信トークンを生成したときのみ， 追加のSSH_MSG_USERAUTH_GSSAPI_TOKEN メッセージは送られる． GSS_S_COMPLETE と GSS_S_CONTINUE_NEEDED 以外の major status コードは失敗とする必要がある． Hutzelman, et al. Standards Track [Page 15] RFC 4462 SSH GSS-API Methods May 2006 3.5. 暗号鍵の束縛 SSHのセッションの暗号化と完全性保護に用いられ鍵にGSS-API コンテキストを束縛する正当なメッセージ完全性コード (MIC) をクライアントが送った場合にもアクセスを許可することで、 セキュリティを向上させられる場合がある. この追加のレベルの保護で, クライアントにその信頼性を確信させた"中間者攻撃"の攻撃者が, 本物のクライアントとサーバの間でユーザ認証メッセージを中継して本物のサーバのアクセス権限を得ようとすることができなくなる. 交渉済みの GSS-API コンテキストが メッセージ単位の完全性保護とサポートしている場合, つまり GSS_Init_sec_context() かGSS_Accept_sec_context() の呼び出しが成功し integ_avail フラグが設定されている場合, この追加の保護が有効になる. GSS_Init_sec_context() のクライアントの呼び出し結果が GSS_S_COMPLETE で integ_avail フラグが設定されているなら, クライアントは 次のメッセージを送ってユーザ認証の交換を成立させなければらならない. byte SSH_MSG_USERAUTH_GSSAPI_MIC string MIC GSS_Init_sec_context() が GSS_S_COMPLETE を返した場合のみ, このメッセージを送らなければならない. トークンも返された場合, SSH_MSG_USERAUTH_GSSAPI_TOKEN メッセージをこのメッセージの前に送らなければならない. MIC フィールドの内容は, ちょうど確立したばかりの GSS-API コンテキストを利用して 次に対して GSS_Get_MIC() を呼び出すことで得られる string session identifier byte SSH_MSG_USERAUTH_REQUEST string user name string service string "gssapi-with-mic" GSS-APIコンテキストが完全に確立する前にこのメッセージをサーバが受け取ったら, サーバは認証を失敗させなければならない. 交渉済みの GSS-API コンテキストが メッセージ単位の完全性保護をサポートしていない場合にこのメッセージをサーバが受け取ったら, サーバは認証を失敗させなければならない. 3.6. クライアントの確認応答 交渉済みの GSS-API コンテキストが メッセージ単位の完全性保護をサポートしていない場合でも, ユーザ認証を進めることをサーバが許可する場合がある. Hutzelman, et al. Standards Track [Page 16] RFC 4462 SSH GSS-API Methods May 2006 この場合, クライアントの最後のGSS_Init_sec_context() 呼びだしが失敗しても, GSS-API 認証法をサーバが成功で終わらせることができる. サーバが単にクライアントの部分の成功を仮定し認証サービスを終了させたら, クライアントは認証法を失敗させられる. しかし サーバがすでに認証成功としているので別の認証法を試すことはできない. これを防ぐため, クライアントは認証が完了した事を示す最後のメッセージを送る. GSS_Init_sec_context() のクライアントの呼び出し結果が GSS_S_COMPLETE で integ_avail フラグが設定されていないなら、 クライアントは 次のメッセージを送ってユーザ認証の交換を成立させなければならない. byte SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE GSS_Init_sec_context() が GSS_S_COMPLETE を返した場合のみ, このメッセージを送らなければならない. トークンも返された場合, SSH_MSG_USERAUTH_GSSAPI_TOKEN メッセージをこのメッセージの前に送らなければならない. GSS-APIコンテキストが完全に確立する前にこのメッセージをサーバが受け取ったら, サーバは認証を失敗させなければならない. 交渉済みの GSS-API コンテキストが メッセージ単位の完全性保護をサポートしている場合にこのメッセージをサーバが受け取ったら, サーバは認証を失敗させなければならない. メッセージ単位の完全性保護をサポートしないGSS-APIメカニズム と/もしくは コンテクスト を利用する認証を許可するかどうかは, サーバのサイトポリシーの問題だ. メッセージ単位の完全性保護がサポートされていない場合に, サーバは正当な gssapi-with-mic 認証を失敗させてもよい. 3.7. 完了 すべてのSSH認証法と同様に, 他の認証が必要ない場合は, 成功は SSH_MSG_USERAUTH_SUCCESS で示される. 成功したが, サーバがさらなる認証を必要とする場合は, partial success フラグが設定され たSSH_MSG_USERAUTH_FAILURE で示される. SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE パケットを受け取ったら直ちにこのパケットを送る必要がある. 3.8. エラー状態 コンテキストの確立の間にサーバで GSS-APIエラーが起きたら, SSH_MSG_USERAUTH_FAILURE メッセージを送る前に, エラーの詳細をクライアントに示すため次のメッセージをサーバは送ってもよい. Hutzelman, et al. Standards Track [Page 17] RFC 4462 SSH GSS-API Methods May 2006 byte SSH_MSG_USERAUTH_GSSAPI_ERROR uint32 major_status uint32 minor_status string message string language tag message テキストは [UTF8] に記述されている UTF-8 エンコーディングでエンコードされてなければならない. language タグは [LANGTAG] に記述されているものだ. 注意: message text はキャリッジリターン-ラインフィード (CRLF) シーケンスで区切られた複数行を含むかもしれない. これらのメッセージを表示するアプリケーション開発者は, 複数行あるかもしれないことに注意しなければならない. このメッセージを受け取ったクライアントは エラーの詳細をログに記録したり また/もしくは ユーザに詳細をレポートしたりしてもよい. このメッセージを送るすべてのサーバは, クライアントが応答として送るすべての SSH_MSG_UNIMPLEMENTED を無視しなければならない. 3.9. エラートークン コンテキスト確立の間にGSS_Init_sec_context() のクライアントでの呼び出しか GSS_Accept_sec_context() のサーバでの呼び出しが, エラー状態付きのトークンを返した場合, 結果の"エラートークン"を 次のメッセージを用いて相手に伝える必要がある. byte SSH_MSG_USERAUTH_GSSAPI_ERRTOK string error token このメッセージは, 認証が失敗しようとしていることを意味している. また, 同期を失なうことなしにエラートークンを通信できるよう定義されている. このメッセージをサーバが送るとき, 同じ認証リクエストに対して適用されるように解釈されるために, SSH_MSG_USERAUTH_FAILURE を続けて送らなければならない. このメッセージを受け取ったクライアントは, 別の認証を試そうとする前に 次の SSH_MSG_USERAUTH_FAILURE を待つ必要がある. クライアントがこのメッセージを送る場合は, 次に新しい認証の要求か接続の切断をしなければならない. メッセージを受けとったサーバは, SSH_MSG_USERAUTH_FAILURE を応答として送ってはならない. 次の認証シーケンスに対する応答だとクライアントが解釈してしまう可能性があるからだ. このメッセージを送るサーバは, クライアントから応答として送られる SSH_MSG_UNIMPLEMENTED を無視しなければならない. このメッセージと SSH_MSG_USERAUTH_GSSAPI_ERROR メッセージをサーバが両方送る場合, SSH_MSG_USERAUTH_GSSAPI_ERROR メッセージを最初に送らなければならない. エラートークンを処理する前にクライアントがエラー状態を保持する かつ/もしくは 表示できるようにするためだ. Hutzelman, et al. Standards Track [Page 18] RFC 4462 SSH GSS-API Methods May 2006 4. GSS-API 鍵交換を利用する認証 この節では, [SSH-USERAUTH] で記述されたフレームワーク上に構築するユーザ認証法を記述する. この方法は, 鍵交換で確立された既存の GSS-API コンテキストを利用してユーザ認証を行なう. このプロトコルの認証法名は "gssapi-keyex" だ. 2 節に従って定義された GSS-API ベースの鍵交換法を用いて最初の鍵交換が行なわれた場合にのみ, この方法は利用できる. この方法で利用される GSS-API コンテキストは, 最初の GSS-API ベース鍵交換で確立されたものが常に利用される. 鍵の再生成目的での鍵交換で確立したコンテキストは, この方法に利用してはならない. GSS-API ベースの鍵交換法を用いて最初の鍵交換が行なわれ, 鍵交換によりユーザの識別情報がサーバで利用可能である場合, (SSH_MSG_USERAUTH_FAILURE での) 継続可能な認証法リストに このユーザ認証法を含める必要がある. 2 節に従って定義された GSS-API ベースの鍵交換法を用いずに最初の鍵交換が行なわれたら, この認証法をサーバは含めてはならない. サーバからのこの認証法が告示され, 最初の鍵交換がGSS-APIベースの鍵交換法を用いて行なわれ, この認証法を試していない場合, クライアントは, この認証を試す必要がある. クライアントは1セッションに2回以上この方法を試さないほうがよい. 2 節に従って定義された GSS-API ベースの鍵交換法を用いずに最初の鍵交換が行なわれたら, クライアントはこの認証法を試してはならない. 2 節に従って定義された GSS-API ベースの鍵交換法を用いずに最初の鍵交換が行なわれた際に この認証法の要求をサーバが受け取ったら, SSH_MSG_USERAUTH_FAILURE を返さなければならない. この認証法は, 単一のメッセージで定義される. byte SSH_MSG_USERAUTH_REQUEST string user name string service string "gssapi-keyex" string MIC MIC フィールドの内容は, 確立した GSS-API コンテキストを利用して 次に対して GSS_GetMIC を呼び出すことで得られる. Hutzelman, et al. Standards Track [Page 19] RFC 4462 SSH GSS-API Methods May 2006 string session identifier byte SSH_MSG_USERAUTH_REQUEST string user name string service string "gssapi-keyex" GSS-API ベースの鍵交換法を用いて最初の鍵交換が行なわれた場合にこのメッセージを受け取ったら, 受け取った MIC が正当化検証するために GSS_VerifyMIC() をサーバは利用する. MIC が正当でなければ, ユーザ認証は失敗し, SSH_MSG_USERAUTH_FAILURE をサーバは返さなければならない. MIC が正当でサーバがユーザの認証情報に満足したら, 追加の認証が必要ない場合はSSH_MSG_USERAUTH_SUCCESS を返す. 追加の認証が必要な場合は, partial success フラグを設定した SSH_MSG_USERAUTH_FAILURE を返す. 5. null ホスト鍵アルゴリズム "null" ホスト鍵アルゴリズムは, 関連するホスト鍵素材を持たず, 署名や暗号化のアルゴリムを提供しない. それゆえ, 公開鍵操作が必要ではない鍵交換法とホスト鍵素材の利用が必要でない鍵交換法とともにのみ利用できる. 2 節で記述した鍵交換法が, このような方法の例だ. 設定の問題として, ホストが公開鍵を持っていないか公開鍵の利用を望まない場合に, このアルゴリムは利用される. たとえば, すべての鍵交換を Kerberos [KRB5]を用いて認証する, つまり 基底の GSS-API メカニズム として Kerberos V5 を用いる 前述の GSS-API で認証された Diffie-Hellman 交換のみを 鍵交換法として許可すると管理者がポリシーを決定した場合に, このアルゴリズムを用いることができる. このような設定では, サーバの実装は "ssh-dss" 鍵アルゴリズムをサポートしている ([SSH-TRANSPORT] で要求されている). しかし, 設定で利用を禁止できる. このときサーバはクライアントに告知する鍵交換アルゴリズムが必要だ. "null" アルゴリムはこの目的を満す. 注意: このような"null" アルゴリズムの利用は, このアルゴリズムをサポートしないクライアントとサーバが相互運用できないことを意味する. これは重大な問題ではない. 前述した設定では, GSS-API で認証された 鍵交換と Kerberos をサポートしていない実装と相互運用できないからだ. Hutzelman, et al. Standards Track [Page 20] RFC 4462 SSH GSS-API Methods May 2006 2 節に従う 鍵交換メソッドを1つでもサポートする実装は, "null" ホスト鍵アルゴリズムもサポートしなければならない. "null" ホスト鍵アルゴリズムがクライアントに告知する唯一のアルゴリズムでなければ, このアルゴリズムをサーバは告知してはならない. 6. メッセージ番号のまとめ GSS-API ベースの鍵交換法で用いるために, 次のメッセージ番号が定義されている: #define SSH_MSG_KEXGSS_INIT 30 #define SSH_MSG_KEXGSS_CONTINUE 31 #define SSH_MSG_KEXGSS_COMPLETE 32 #define SSH_MSG_KEXGSS_HOSTKEY 33 #define SSH_MSG_KEXGSS_ERROR 34 #define SSH_MSG_KEXGSS_GROUPREQ 40 #define SSH_MSG_KEXGSS_GROUP 41 30-49 の範囲の数は鍵交換特有のもので, 他の鍵交換法で再定義できる. 'gssapi-with-mic' ユーザ認証法で用いるために, 次のメッセージ番号が定義されている: #define SSH_MSG_USERAUTH_GSSAPI_RESPONSE 60 #define SSH_MSG_USERAUTH_GSSAPI_TOKEN 61 #define SSH_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE 63 #define SSH_MSG_USERAUTH_GSSAPI_ERROR 64 #define SSH_MSG_USERAUTH_GSSAPI_ERRTOK 65 #define SSH_MSG_USERAUTH_GSSAPI_MIC 66 60-79 の範囲の数はユーザ認証特有のもので, 他の鍵交換法で再定義できる. 注意: この文書で記述された方法では, メッセージ番号 62 は未使用だ. Hutzelman, et al. Standards Track [Page 21] RFC 4462 SSH GSS-API Methods May 2006 7. GSS-API の考察 7.1. 命名規則 GSS-API セキュリティコンテキストを確立するために, GSS_Init_sec_context() を呼ぶ際にサーバの識別に用いる適切な targ_name を クライアントは決定する必要がある. この目的のため, ホストベースサービスでの GSS-API メカニズムに独立な名前の形式が用いられる. [GSSAPI] の 4.1 節に記述されている. 具体的には, GSS_Init_sec_context() に渡す targ_name は, input_name_type を GSS_C_NT_HOSTBASED_SERVICE に input_name_string を "host@" にSSHサーバのホスト名を連結した文字列にしてGSS_Import_name() を呼び出すことで得られる. GSS-APIメカニズムは サーバの識別情報の認証に targ_name を用いるので, 安全な方法で決定することは重要だ. これを行なう一般的な方法として, ユーザが入力した ホスト名から targ_name を構築するものがある. 残念ながら, GSS-API メカニズムには ホスト名を正規化しないものがあるので, ユーザが完全に正規化されたホスト名を入力しない場合にこのテクニックが失敗する場合がある. それゆえ, 実装者は, 別の方法を使いたいと考えるかもしれない. このときその方法が安全なことを保証するよう注意しなければならない. たとえば, 攻撃者がマッピングを変更したりサーバになりすますことができるので, ホストエイリアスをサーバのプライマリ名にマップしたりIPアドレスをホスト名にマップする保護されていない DNS レコードに依存してはならない. この文書に従うメカニズムの実装者は, targ_name の構築に安全でないDNSクエリの結果を用いてはならない. クライアントは, ローカルな設定で提供されるマッピングを利用したり, 用いられる targ_name を決定する他の安全な方法を利用したりしてよい. クライアントシステムが, 利用する targ_name を安全に決定できないなら, このこのアルゴリズムを利用しないほうがよい. 7.2. チャンネルの束縛 コンテキストの確立の間呼出でチャンネルの束縛を指定しないほうがよいと, この文書は推奨する. チャンネル束縛として用いられる標準データをこの文書は指定しない. また, チャンネル束縛としてネットワークアドレスを利用すると, それがもっとも有用な環境において, SSHを壊してしまうかもしれない. Hutzelman, et al. Standards Track [Page 22] RFC 4462 SSH GSS-API Methods May 2006 7.3. SPNEGO Simple and Protected GSS-API Negotiation Mechanism [SPNEGO] をこの文書に記述した認証法と鍵交換法と一緒に利用する必要はなく, 望ましくない. これにより, この文書に従うメカニズムは, 基底のGSS-API メカニズムとして SPENGO を用いてはならない. SSHは自身で認証法や鍵交換法の交渉をするので, SPENGO 単独での交渉能力は利益をもたらさない. 次に記述するように, 望まれているものよりも弱い方法を用いてしまう可能性が実際にある. 通常, GSS-API メカニズムの交渉の保護に利益をもたらす. クライアントが提案したメカニズムのリストから MIC をサーバが計算して クライアントがその値をチェックすることで行なわれる. 鍵交換の場合, この保護は必要ない. ここで記述した鍵交換法は同等の操作を実行するからだ. すなわち, それぞれの側でサポートされる鍵交換メカニズムのリストを含むいくつかの要素のハッシュである SSH の交換ハッシュから MICを生成する. ユーザ認証の場合もこの保護は必要ない. 安全なチャンネルの上で交渉が行なわれ, ホストの識別情報はユーザにすでに証明されている. SPENGO なしで利用する GSS-API メカニズムと組合せて SPENGO を利用すると, 相互運用上の問題が発生しうる. たとえば, SPENGO の下で Kerberos V5 GSS-API メカニズム [KRB5-GSS] を用いる鍵交換をサポートするクライアントは,Kerberos V5 GSS-API を直接用いる鍵交換のみをサポートするサーバと, 相互運用できない. 結果として, SPENGO を利用するものと利用しないものの両方を GSS-API メカニズムとして許可するのは望ましくない. 最初に GSS-API ベースの鍵交換法 X を好み次に GSS-API でない方法 Y を好み, そして GSS-APIベースの方法を好むクライアントのポリシーでサーバが Y と Z をサポートするが X をサポートしない場合, Y が好ましい方法だが, GSS-API メカニズムの交渉のためにSPENGOを利用すると Z の利用という結果になる. 結果として, SPENGO の利用は, [SSH-TRANSPORT] の 7.1 節で記述された鍵交換法 と/もしくは [SSH-USERAUTH] で記述されたユーザ認証法の 交渉アルゴリズムを転覆させる可能性があります. Hutzelman, et al. Standards Track [Page 23] RFC 4462 SSH GSS-API Methods May 2006 8. IANA の考慮 [SSH-ARCH] の 8節と [SSH-NUMBERS] の4.6節と整合するため, この文書は次の登録を行なう. "gss-group1-sha1-" で始まり アットマーク('@')を含まないSSH 鍵交換法名のファミリで 2.3節で定義した鍵交換法を指定する. "gss-gex-sha1-" で始まり アットマーク('@')を含まないSSH 鍵交換法名のファミリで 2.5節で定義した鍵交換法を指定する. "gss-" で始まり アットマーク('＠')を含まないすべてのSSH鍵交換法名は, 2.6節で注記した, この文書に従って定義された将来の鍵交換法のために予約される. SSH ホスト公開鍵アルゴリズム名 "nulll" で, 5 節で定義した ヌルホスト鍵アルゴリズムを指定する. SSH ホスト公開鍵アルゴリズム名 "gssapi-with-mic" で, 3 節で定義した GSS-API ユーザ認証法を指定する. SSH ホスト公開鍵アルゴリズム名 "gssapi-keyex" で, 4 節で定義した GSS-API ユーザ認証法を指定する. SSH ユーザ認証法名 "gssapi" は予約される. この実装の以前のバージョンをサポートする実装との衝突を避けるためだ. SSH ユーザ認証法名 "external-keyx" は予約される. この実装の以前のバージョンをサポートする実装との衝突を避けるためだ. この文書は新しいレジストリは作成しない. 9. セキュリティの考察 この文書は認証と鍵交換プロトコルを記述している. このため, セキュリティの考慮事項は全体にわたって議論されている. このプロトコルは SSHプロトコル自体, GSS-API, 利用されるすべての基底のGSS-APIメカニズム, それらのメカニズムに依存するすべてのプロトコルに依存している. これらの要素それぞれが, 結果として生じる接続のセキュリティのある部分をになっており, それぞれが自身のセキュリティの考慮事項を持つ. Hutzelman, et al. Standards Track [Page 24] RFC 4462 SSH GSS-API Methods May 2006 2節で記述した鍵交換法は, 相互認証とメッセージ単位の完全性サービスを提供する基底の GSS-API メカニズムに依存している. 特定の GSS-API メカニズムで もしくは 特定の GSS-API メカニズムの実装で, これらの特徴のどちらかがサポートされていなかったら, 鍵交換は安全ではなく失敗しなければならない. "external-keyx" ユーザ認証法を利用するためには, 鍵交換の副作用として得られたユーザ認証情報にアクセスしなければならない. この情報が利用できなければ, 認証は失敗しなければならない. 認証失敗の理由の情報を開示することは, 本番環境では受け入れられないセキュリティリスクと考えるサイトもある. しかし, この情報は, デバッグのためには重要だ. このため,SSH_MSG_USERAUTH_GSSAPI_ERROR と SSH_MSG_USERAUTH_GSSAPI_ERRTOK, SSH_MSG_KEXGSS_ERROR, GSS-API エラートークンを含む SSH_MSG_KEXGSS_CONTINUE メッセージを送るかどうかを ポリシーの問題として制御する手段を実装が提供することが推奨される. 10. 謝辞 The authors would like to thank the following individuals for their invaluable assistance and contributions to this document: o Sam Hartman o Love Hornquist-Astrand o Joel N. Weber II o Simon Wilkinson o Nicolas Williams Much of the text describing DH group exchange was borrowed from [GROUP-EXCHANGE], by Markus Friedl, Niels Provos, and William A. Simpson. Hutzelman, et al. Standards Track [Page 25] RFC 4462 SSH GSS-API Methods May 2006 11. References 11.1. Normative References [ASN1] ISO/IEC, "ASN.1 Encoding Rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690 (1997), ISO/ IEC 8825-1:1998, November 1998. [GROUP-EXCHANGE] Friedl, M., Provos, N., and W. Simpson, "Diffie- Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol", RFC 4419, March 2006. [GSSAPI] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [LANGTAG] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001. [MD5] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992. [MIME] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [SSH-ARCH] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. [SSH-CONNECT] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Connection Protocol", RFC 4254, January 2006. [SSH-NUMBERS] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006. [SSH-TRANSPORT] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. [SSH-USERAUTH] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006. Hutzelman, et al. Standards Track [Page 26] RFC 4462 SSH GSS-API Methods May 2006 [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. 11.2. Informative References [KRB5] Neuman, C., Yu, T., Hartman, S., and K. Raeburn, "The Kerberos Network Authentication Service (V5)", RFC 4120, July 2005. [KRB5-GSS] Zhu, L., Jaganathan, K., and S. Hartman, "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2", RFC 4121, July 2005. [SASLPREP] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005. [SPNEGO] Zhu, L., Leach, P., Jaganathan, K., and W. Ingersoll, "The Simple and Protected Generic Security Service Application Program Interface (GSS-API) Negotiation Mechanism", RFC 4178, October 2005. Hutzelman, et al. Standards Track [Page 27] RFC 4462 SSH GSS-API Methods May 2006 Authors' Addresses Jeffrey Hutzelman Carnegie Mellon University 5000 Forbes Ave Pittsburgh, PA 15213 US Phone: +1 412 268 7225 EMail: jhutz+@cmu.edu URI: http://www.cs.cmu.edu/~jhutz/ Joseph Salowey Cisco Systems 2901 Third Avenue Seattle, WA 98121 US Phone: +1 206 256 3380 EMail: jsalowey@cisco.com Joseph Galbraith Van Dyke Technologies, Inc. 4848 Tramway Ridge Dr. NE Suite 101 Albuquerque, NM 87111 US EMail: galb@vandyke.com Von Welch University of Chicago & Argonne National Laboratory Distributed Systems Laboratory 701 E. Washington Urbana, IL 61801 US EMail: welch@mcs.anl.gov Hutzelman, et al. Standards Track [Page 28] RFC 4462 SSH GSS-API Methods May 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). Hutzelman, et al. Standards Track [Page 29]