Network Working Group J. Galbraith Request for Comments: 4819 J. Van Dyke Category: Standards Track VanDyke Software J. Bright Silicon Circus March 2007 セキュアシェル公開鍵サブシステム このメモの位置づけ この文書は, インターネットコミュニティに対するインターネットの標準トラックプロトコルを定義している. また, 改善のための議論と示唆を求めている. このプロトコルの標準化の状態と状況は "Internet Official Protocol Standards" (STD 1) の現在の版を参照してほしい. このメモの配布は制限しない. 著作権情報 Copyright (C) The IETF Trust (2007). 概要 セキュアシェルは公開鍵の基づくユーザ認証アルゴリズムを定義しているが, 鍵配布のメカニズムは定義していない. 現在の実装では, 共通の鍵管理ソリューションは存在しない. この文書では, 実装に依存しない形で公開鍵を設定するのに利用できるプロトコルを定義する. この設定に対する負担はクライアントソフトウェアが引き受ける. この公開鍵サブシステムは, 公開鍵を追加したり削除したりサーバが知っている現在の公開鍵の一覧を取得する, サーバに依存しないメカニズムをクライアントに提供する. 公開鍵を管理する権限は, 認証されたユーザに特有で制限される. 公開鍵を, コマンドやサブシステムの強制を含む様々な制限に関連付けることができる. Galbraith, et al. Standards Track [Page 1] RFC 4819 Secure Shell Public Key Subsystem March 2007 目次 1導入 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. 用語 . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. 公開鍵サブシステムの概要 . . . . . . . . . . . . . . . . 3 3.1. 公開鍵サブシステムの開始 . . . . . . . . . . . . . 4 3.2. 要求と応答 . . . . . . . . . . . . . . . . . . 5 3.3. 状態メッセージ . . . . . . . . . . . . . . . . . . . . 5 3.3.1. 状態コード . . . . . . . . . . . . . . . . . . . . . 5 3.4. バージョンパケット . . . . . . . . . . . . . . . . . . . . 6 4. 公開鍵サブシステムの操作 . . . . . . . . . . . . . . . 7 4.1. 公開鍵の追加 . . . . . . . . . . . . . . . . . . . 7 4.2. 公開鍵の削除 . . . . . . . . . . . . . . . . . . 10 4.3. 公開鍵の一覧の取得 . . . . . . . . . . . . . . . . . . . 10 4.4. サーバ機能の一覧の取得 . . . . . . . . . . . . . . . 10 5. セキュリティの考察 . . . . . . . . . . . . . . . . . . . 11 6. IANA の考察 . . . . . . . . . . . . . . . . . . . . . 12 6.1. 登録 . . . . . . . . . . . . . . . . . . . . . . 12 6.2. 名前 . . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.2.1. 命名規則 . . . . . . . . . . . . . . . . 12 6.2.2. 将来の名前の割り当て . . . . . . . . . . . . . 13 6.3. 公開鍵サブシステムの要求名 . . . . . . . . . . . . 13 6.4. 公開鍵サブシステムの応答名 . . . . . . . . . . . 13 6.5. 公開鍵サブシステムの属性名 . . . . . . . . . . . 13 6.6. 公開鍵サブシステムの状態コード . . . . . . . . . . . . 14 6.6.1. 規約 . . . . . . . . . . . . . . . . . . . . . 14 6.6.2. 初期の割り当て . . . . . . . . . . . . . . . . . 14 6.6.3. 将来の割り当て . . . . . . . . . . . . . . . . . . 15 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.1. Normative References . . . . . . . . . . . . . . . . . . . 15 7.2. Informative References . . . . . . . . . . . . . . . . . . 15 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 Galbraith, et al. Standards Track [Page 2] RFC 4819 Secure Shell Public Key Subsystem March 2007 1イントロダクション セキュアシェル (SSH) は, 安全ではないネットワーク上での安全なリモートログインや他の安全なネットワークサービスのためのプロトコルだ. セキュアシェルは公開鍵の基づくユーザ認証アルゴリズムを定義しているが, 鍵配布のメカニズムは定義していない. 一度パスワード認証で認証しサーバに公開鍵を転送するのが一般的な方法だ. しかし, 公開鍵の利用の設定で, 別々の実装で同じメカニズムを利用する例は今のところない. この文書は, 実装に依存しない形で公開鍵を設定するためのサブシステムを記述する. このアプリートでは, クライアントソフトウェアがこの設定に対する負担を引き受ける. この公開鍵サブシステムプロトコルは, 非常に簡単に実装できるよう設計されている. これは, X.509 証明書ベースの公開鍵基盤 (PKIX) の代替を意図していない. セキュアシェル公開鍵サブシステムは, セキュアシェルトランスポート層 [2] と ユーザ認証 [3] プロトコルの上で動作するように設計されている. サーバ上の公開鍵を管理するクライアントのための簡単なメカニズムを提供する. この文書は, セキュアシェルアーキテクチャ [1] と セキュアシェルコネクション [4] 文書を読んだあとに読むべきだ. このプロトコルは, セキュアシェルコネクションプロトコル [4] の, "「シェルまたはコマンドの開始」 節に記述されている, サブシステムから利用されることを意図している. このプロトコルで用いられるサブシステム名は "publickey" だ. このプロトコルは, ユーザが利用する前に何らかの形でユーザを認証できる必要がある. パスワード認証が使える場合, 最初の公開鍵が追加された後でパスワード認証の利用を無効にする設定項目をサーバは提供する必要がある. 2. 用語 この文書でのキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" は, RFC 2119 [5] で記述されているように解釈される. 3. 公開鍵サブシステムの概要 この公開鍵サブシステムは, 公開鍵を追加したり削除したりサーバが知っている現在の公開鍵の一覧を取得する, サーバに依存しないメカニズムをクライアントに提供する. サブシステム名は "publickey" だ. Galbraith, et al. Standards Track [Page 3] RFC 4819 Secure Shell Public Key Subsystem March 2007 このプロトコルを用いて公開鍵を追加, 削除, 一覧の取得をするのは, 認証されたユーザの公開鍵に特定され制限される. 認証されたユーザの公開鍵の追加や削除, 一覧の取得の操作は, サーバに送られる要求パケットで実行される. サーバは応答パケットを送信して, 成功か失敗を示し応答に特有のデータを提供する. 公開鍵ブロブの形式は SSH トランスポートプロトコル文書 [2] の 6.6 節 「公開鍵アルゴリズム」 に詳述されている. 3.1. 公開鍵サブシステムの開始 公開鍵サブシステムは, すでに開始されているセッションチャンネル上で SSH_MSG_CHANNEL_REQUEST をクライアントが送ることで開始される. どのようにセッションを開始するかの詳細は, SSH コネクションプロトコル文書 [4] の 「セッションの開始」 節に記述されている. 公開鍵サブシステムを開始するためにクライアントは以下を送る: byte SSH_MSG_CHANNEL_REQUEST uint32 recipient channel string "subsystem" boolean want reply string "publickey" クライアントの実装はこの要求を拒否する必要がある. これは通常クライアントからのみ送られる. want reply が TRUE の場合, 公開鍵サブシステムの開始に成功したら SSH_MSG_CHANNEL_SUCCESS をサーバは返さなければならない. 公開鍵サブシステムの開始に失敗したりサポートしていなければ SSH_MSG_CHANNEL_FAILURE サーバは返さなければならない. (たとえば制限された公開鍵でユーザが認証したため) 公開鍵サブシステムにアクセスをユーザが許されていない場合も, SSH_MSG_CHANNEL_FAILUREをサーバは返す必要がある.The server SHOULD respond with SSH_MSG_CHANNEL_FAILURE if the user is not allowed access to the Public Key Subsystem (for example, because the user authenticated with a restricted public key). クライアントがこの要求で応答を要求し検査するのを推奨する. Galbraith, et al. Standards Track [Page 4] RFC 4819 Secure Shell Public Key Subsystem March 2007 3.2. 要求と応答 すべての公開鍵サブシステムの要求と応答は次の形式で送られる. uint32 length string name ... request/response specific data follows length フィールドは name フィールドと request/response-specific data の長さを表す. length フィールド自体の長さは含まない. クライアントは, 新しい要求を送る前にそれぞれの要求の確認応答(状態メッセージ)を受け取らなければならない. (3.4節で記述する)バージョンパケットと4節で記述する要求と応答では, 'name' フィールドとパケットのデータ部を記述している. 3.3. 状態メッセージ 要求は 状態パケットを送ることで確認応答される. 要求に対するデータが送られる場合は, すべてのデータが送られたあとで状態パケットが送られる. string "status" uint32 status code string description [7] string language tag [6] 状態メッセージは, どのような認識されないパケットに対しても送られなければならない. 対応する要求はサブシステムを終了しないほうがよい. 3.3.1. 状態コード 状態コードは, より機械可読な形式(ローカライズに適している)で状態を与える. 次の値を取りうる: SSH_PUBLICKEY_SUCCESS 0 SSH_PUBLICKEY_ACCESS_DENIED 1 SSH_PUBLICKEY_STORAGE_EXCEEDED 2 SSH_PUBLICKEY_VERSION_NOT_SUPPORTED 3 SSH_PUBLICKEY_KEY_NOT_FOUND 4 SSH_PUBLICKEY_KEY_NOT_SUPPORTED 5 SSH_PUBLICKEY_KEY_ALREADY_PRESENT 6 SSH_PUBLICKEY_GENERAL_FAILURE 7 SSH_PUBLICKEY_REQUEST_NOT_SUPPORTED 8 SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED 9 Galbraith, et al. Standards Track [Page 5] RFC 4819 Secure Shell Public Key Subsystem March 2007 要求が正常に完了したら, 状態コード SSH_PUBLICKEY_SUCCESS をサーバは送らなければならない. 失敗のコードの意味は, それらの名前に示されている. 3.4. バージョンパケット クライアントもサーバも, 利用するプロトコルのバージョンを指定するバージョンパケットを送って接続を開始しなければならない. string "version" uint32 protocol-version-number この文書はプロトコルバージョン 2 を記述している. この文書の初期のドラフトで, バージョン1が使われていた. 状態パケットの処理に変更があったのでバージョン番号が増えた. クライアントもサーバも, 実装しているもっとも高いバージョンを送る. 低いほうのバージョン番号が, 利用されるプロトコルのバージョンとなる. もう一方が低いバージョンをサポートしていなければ, サブシステムを終了させ, SSH_MSG_CHANNEL_CLOSE を送って相手側に通知しなければならない. サブシステムを終了する前に,状態が SSH_PUBLICKEY_VERSION_NOT_SUPPORTED な状態メッセージを送る必要がある. 注意: 通常状態メッセージは(クライアントからの要求への応答として)サーバからのみ送られる. これは, クライアントが状態メッセージを送る唯一の場合だ. どちらの側も続行する前にこのバージョンを受け取るために待たなければならない. この "version" パケットは, 最初の交換の後で再び送ってはならない. SSH_PUBLICKEY_VERSION_NOT_SUPPORTED 状態コードは, 他の要求への応答として送られてはならない. 実装は, ([4] の6.5 節で記述しているように) ユーザのシェルからの誤った出力を処理するのを避けるために, バージョンパケットの最初の15バイトに "magic cookie" を利用してもよい. このバイト列は常に以下だ: 0x00 0x00 0x00 0x0F 0x00 0x00 0x00 0x07 0x76 0x65 0x72 0x73 0x69 0x6F 0x6E Galbraith, et al. Standards Track [Page 6] RFC 4819 Secure Shell Public Key Subsystem March 2007 4. 公開鍵サブシステムの操作 公開鍵サブシステムは4つの操作を現在定義している: 追加, 削除, 一覧の取得, サーバの属性の取得だ. 4.1. 公開鍵の追加 クライアントが公開鍵を追加したい場合, クライアントは以下を送る: string "add" string public key algorithm name string public key blob boolean overwrite uint32 attribute-count string attrib-name string attrib-value bool critical repeated attribute-count times サーバは, 以降の公開鍵認証で公開鍵が利用可能になる適切な場所にユーザの公開鍵を保存しようと試みなければならない. overwrite フィールドが false で指定された鍵がすでに存在したら, サーバは SSH_PUBLICKEY_KEY_ALREADY_PRESENT を返さなければならない. サーバがこれを返したら, クライアントはユーザに鍵を上書きするかの選択を提供する必要がある. overwrite フィールドが true で指定された鍵が存在し, 鍵を上書きできない場合は, サーバは SSH_PUBLICKEY_ACCESS_DENIED を返さなければならない. [1] のアルゴリズム名のために示されたのと同じ方式に従ってアルゴリズム名は定義される. サーバが criticalな属性をサポートしない場合は, 状態コード SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED で追加に失敗しなければならない. critical な属性の目的を充たすためには, 単なる属性の保存では十分ではない. サーバは属性の意図を理解し実装していなけばならない. 現在次の属性が定義されている: "comment" comment 属性の値は, 公開鍵についてユーザが指定したテキストだ. サーバは, この値を保持しその後の一覧取得操作で鍵とともに返すためにあらゆる努力をする必要がある. サーバは, comment フィールドの内容について, どのようなやり方でも解釈しようとしてはいけないし, またどのようなやり方でも内容に基づいて行動しようとしてはいけない. comment 属性は UTF-8 形式 [7] で指定しなければならない. Galbraith, et al. Standards Track [Page 7] RFC 4819 Secure Shell Public Key Subsystem March 2007 comment は, 指紋の比較を頼らずにユーザが鍵を特定するのに有効だ. この属性は critical にしないほうがよい. "comment-language" この属性が指定されているなら, "comment" 属性がすぐ次に続かなければならない. また, その "comment" 属性の言語を指定しなければならない [6]. クライアントは, それぞれのコメントに異なる言語を指定するなら, 1つ以上のコメントを指定してよい. サーバは, その言語属性付きでコメントを保存するように試みる必要がある. この属性は critical にしないほうがよい. "command-override" "command-override" は, この鍵が使われるときに実行されるコマンドを指定する. クライアントから "exec" か "shell" の要求があった場合に, その要求の結果として他では実行される(要求で指定された)コマンドやシェルの変わりに, ("command-override" で)指定されたコマンドはサーバで実行される必要がある. このコマンド文字列が空なら, "exec" と "shell" の要求は禁止される必要がある. "command-override" 属性が指定されなければ, すべての "exec" と "shell" 要求は許可される必要がある (サーバが行なう他のセキュリティや認証の検査を満している限り). この属性は critical にする必要がある. "subsystem" "subsystem" は, この鍵を利用する場合に ("subsystem" 要求を用いて) 開始できる サブシステムのカンマ区切りリストを指定する. この属性は critical にする必要がある. この値が空なら, どんなサブシステムも開始できない. "subsystem" 属性が指定されていなければ, この鍵を用いて認証した際に開始できるサブシステムに制限はない. "x11" "x11" はこの鍵を用いるとX11転送が実行されないことを指定する. この属性の値は, 空の必要がある. この属性は critical にする必要がある. "shell" "shell" は, この鍵を用いるとセッションチャンネルの "shell" 要求が拒否されることを指定する. この属性の値は, 空の必要がある. この属性は critical にする必要がある. Galbraith, et al. Standards Track [Page 8] RFC 4819 Secure Shell Public Key Subsystem March 2007 "exec" "exec" は, この鍵を用いるとセッションチャンネルの "exec" 要求が拒否されることを指定する. この属性の値は, 空の必要がある. この属性は critical にする必要がある. "agent" "agent" は, この鍵を用いるとセッションチャンネルの "auth-agent-req" 要求が拒否されることを指定する. この属性の値は, 空の必要がある. この属性は critical にする必要がある. "env" "env" は, この鍵を用いるとセッションチャンネルの "env" 要求が拒否されることを指定する. この属性の値は, 空の必要がある. この属性は critical にする必要がある. "from" "from" は 鍵がそこから使われるホストのカンマ区切りリストを指定する. このリストに含まれないホストが認証目的でこの鍵を利用しようとしたら, 認証の試行は拒否されなければならない. サーバは, これに関するログを残す必要がある. サーバは, このリスト中に特定のホストの出現を認めないための管理者用の方法を提供してもよい. たとえば, IPベースのネットワークでIPアドレスをチェックしたり DNS逆引きを実行するなど, その環境に適したホストを特定する方法をサーバは利用する必要がある. IPベースのネットワークでは, "from" パラメータの要素は, 特定のIPアドレスかホスト名の形式となるのが予想される. "port-forward" "port-forward" は, この属性の値として与えられたカンマ区切りリストで指定されたホストへのものを除いて, "direct-tcpip" 要求が受けいれられないことを指定する. この属性の値が空なら, この鍵を用いるすべての "direct-tcpip" 要求は拒否される必要がある. この属性は critical にする必要がある. "reverse-forward" "reverse-forward" は, この属性の値として与えられたカンマ区切りリストで指定されたホストへのものを除いて, "tcpip-forward" 要求が受けいれられないことを指定する. この属性の値が空なら, この鍵を用いるすべての "tcpip-forward" 要求は拒否される必要がある. この属性は critical にする必要がある. Galbraith, et al. Standards Track [Page 9] RFC 4819 Secure Shell Public Key Subsystem March 2007 クライアントで指定された属性に加えて特定の属性を強制するための, 管理者用の方法をサーバは提供してもよい. 4.2. 公開鍵の削除 クライアントが公開鍵を削除したい場合, クライアントは以下を送る: string "remove" string public key algorithm name string public key blob サーバは, 以降の公開鍵認証で公開鍵が利用不可能になるよう適切な場所からユーザの公開鍵を削除しようと試みなければならない. 4.3. 公開鍵の列挙 クライアントが既知の公開鍵の列挙をしたい場合, クライアントは以下を送る: string "list" サーバは, 0以上の次の応答を返す: string "publickey" string public key algorithm name string public key blob uint32 attribute-count string attrib-name string attrib-value repeated attribute-count times 応答は, 特定の順序である必要はない. 実装はそれぞれ特定のオーダーで応答を返すだろうが, クライアントの実装は特定のオーダーの応答に依存しないほうがよい. 最後の "publickey" 応答に続いて, 状態パケットが送られなければならない. 実装は, この要求をサポートする必要がある. 4.4. サーバ機能の一覧の取得 クライアントがサーバのサポートする鍵の属性を知りたい場合, 以下を送る: string "listattributes" Galbraith, et al. Standards Track [Page 10] RFC 4819 Secure Shell Public Key Subsystem March 2007 サーバは, 0以上の次の応答を返す: string "attribute" string attribute name boolean compulsory "compulsory" フィールドは, サーバの管理の設定のため, 追加されるどの鍵にも(クライアントがこの属性を指定しているかに関係なく)この属性が強制的に追加されることを示している. サーバがこの管理の設定をサポートしていないなら, compulsory フィールドは false を返さなければならない. "compulsory" 属性の利用の例として, ユーザのシェルアクセスを拒否する指定が設定ファイルにあるサーバを挙げる. このとき, "compulsory" がtrue な "shell" 属性をサーバは返す. ユーザがその後鍵をサーバに適用する際に要求する属性がどのようなものでも, ユーザのシェルの利用を禁止するため "shell" 属性もサーバは適用する 最後の "attribute" 応答に続いて, 状態パケットが送られなければならない. 実装は, この要求をサポートしないことを選択してもよい. 5. セキュリティの考察 このプロトコルは, 安全なチャンネル上で動作することとそのチャンネルの末端が認証されていることを前提としている. つまり, このプロトコルは, ネットワークレベルの攻撃からは非常に保護されていることを前提としている. このプロトコルは, クライアントの認証データをアップロードし操作できるメカニズムを提供する. (このプロトコルの外部, 特に SSHユーザ認証プロトコル [3] を用いてユーザを認証して) 特定のユーザにアクセスを制限するために必要なアクセス制御を実施するのはサーバの実装の責任だ. 特に, このプロトコルを用いて, 以前の制限よりも小さい制限を指定してサーバ上の既存の鍵をユーザが上書きできる. これを行なう際サーバは注意する必要がある. クライアントはサーバの管理者の事前設定を上書きできない. このプロトコルは, サーバが正しく実装され鍵に適用された属性を観測できるという前提をクライアントに要求している. サーバの実装エラーにより, クライアントが意図していないアクセスに対して鍵を認証に利用したり, 意図したものよりも少ない制限を適用する可能性がある. Galbraith, et al. Standards Track [Page 11] RFC 4819 Secure Shell Public Key Subsystem March 2007 6. IANA の考慮 この節は, 名前空間を命名規約や, レジストリの初期状態, 将来の割り当てに対する指示を含んでいる. 6.1. 登録 [8] の 4.9.5節と整合するため, この文書は次の登録を行なう: The subsystem name "publickey". 6.2. 名前 次の節では, 名前空間の値はテキストだ. この節には, 規約と, 将来の割り当てについてのIANAへの指示がある. 初期の割り当ては, それぞれの節で与えられる. 6.2.1. 命名規約 以降の節のIANAによって登録されるすべての名前は, 表示可能なUS-ASCIIの文字列で,アットマーク("@"), コンマ (","), スペース, 制御文字(ASCIIコード 32以下) を含んではならない. 名前は大文字小文字が区別され, 64文字以下でなければならない. ローカルに拡張可能な名前についての準備が次のようにされている. IANAは, アットマークを含む名前を登録しないし管理しない. アットマークを含む名前は, "name@domainname" (ダブルクォーテーションを除く) という形式だ. アットマークに先行する部分が(狭い意味での)名前だ. アットマークの前の部分の形式は指定されていない; しかし, 表示可能な US-ASCIIの文字列で, コンマ (","), スペース, 制御文字(ASCIIコード 32以下) を含んではならない. アットマークに続く部分は, 名前を定義する個人ないし組織で管理されている有効な完全に記述したドメイン名 [10]でなければならない. 名前は大文字小文字が区別され, 64文字以下でなければならない. ローカルな名前空間をどう管理するかは, それぞれのドメイン次第だ. この名前が, STD 11 [9]のメールアドレスと似ていることを明記しておく. これは, 単なる偶然でありSTD 11 [9]とは関係ない. ローカルに定義される名前の例の1つは, "our-attribute@example.com" (ダブルクォーテーションを除く) だ. Galbraith, et al. Standards Track [Page 12] RFC 4819 Secure Shell Public Key Subsystem March 2007 6.2.2. 名前の将来の割り当て 新しい名前の割り当ての要求は, [11] に記述されている IETF CONSENSUS によってされなければならない. 6.3. 公開鍵サブシステムの要求名 次の表で, 公開鍵サブシステムの要求名の初期の割り当てを示す. Request Name ------------- version add remove list listattributes 6.4. 公開鍵サブシステムの応答名 次の表で, 公開鍵サブシステムの応答名の初期の割り当てを示す. Response Name -------------- version status publickey attribute 6.5. 公開鍵サブシステムの属性名 属性は, 公開鍵の性質や制限を定義するのに用いられる. 次の表で, 公開鍵サブシステムの属性名の初期の割り当てを示す. Galbraith, et al. Standards Track [Page 13] RFC 4819 Secure Shell Public Key Subsystem March 2007 Attribute Name --------------- comment comment-language command-override subsystem x11 shell exec agent env from port-forward reverse-forward 6.6. 公開鍵サブシステムの状態コード 状態コードはバイトの値で, 要求の状態を記述する. 6.6.1. 規約 状態の応答は 0から255までの状態コードを持つ. 次のように番号が割り当てられる. このうち, 192から 255 はローカルでプライベートな拡張での利用のため予約されている. 6.6.2. 初期の割り当て 次の表で, 公開鍵サブシステムの状態コードの値の初期の割り当てを示す. Status code Value Reference ------------ ----- --------- SSH_PUBLICKEY_SUCCESS 0 SSH_PUBLICKEY_ACCESS_DENIED 1 SSH_PUBLICKEY_STORAGE_EXCEEDED 2 SSH_PUBLICKEY_VERSION_NOT_SUPPORTED 3 SSH_PUBLICKEY_KEY_NOT_FOUND 4 SSH_PUBLICKEY_KEY_NOT_SUPPORTED 5 SSH_PUBLICKEY_KEY_ALREADY_PRESENT 6 SSH_PUBLICKEY_GENERAL_FAILURE 7 SSH_PUBLICKEY_REQUEST_NOT_SUPPORTED 8 SSH_PUBLICKEY_ATTRIBUTE_NOT_SUPPORTED 9 Galbraith, et al. Standards Track [Page 14] RFC 4819 Secure Shell Public Key Subsystem March 2007 6.6.3. 将来の割り当て 0から191の範囲に新たな状態コードを割り当てる要求は, [11] に記述されている IETF CONSENSUS によってされなければならない. IANAは, 192 から 255 の範囲のメッセージ番号は制御しない. この範囲は, プライベートな利用用だ. 7. References 7.1. Normative References [1] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. [2] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. [3] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006. [4] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Connection Protocol", RFC 4254, January 2006. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [6] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 4646, September 2006. [7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. 7.2. Informative References [8] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006. [9] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982. [10] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [11] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Galbraith, et al. Standards Track [Page 15] RFC 4819 Secure Shell Public Key Subsystem March 2007 8. 謝辞 Brent McClure contributed to the writing of this document. Authors' Addresses Joseph Galbraith VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US Phone: +1 505 332 5700 EMail: galb@vandyke.com Jeff P. Van Dyke VanDyke Software 4848 Tramway Ridge Blvd Suite 101 Albuquerque, NM 87111 US Phone: +1 505 332 5700 EMail: jpv@vandyke.com Jon Bright Silicon Circus 24 Jubilee Road Chichester, West Sussex PO19 7XB UK Phone: +49 172 524 0521 EMail: jon@siliconcircus.com Galbraith, et al. Standards Track [Page 16] RFC 4819 Secure Shell Public Key Subsystem March 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). 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, THE IETF TRUST 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 currently provided by the Internet Society. Galbraith, et al. Standards Track [Page 17]