Independent Submission M. Joseph Request for Comments: 7076 J. Susoy Category: Informational P6R, Inc ISSN: 2070-1721 November 2013 P6R の セキュアシェル公開鍵サブシステム 概要 セキュアシェル (SSH) 公開鍵サブシステムプロトコルは, ユーザの公開鍵を持つ SSH サーバへの提供に限られている鍵配布プロトコルを定義している. この文書は, SSH のトランスポートを用いて鍵と証明書を提供を許す RFC 4819 に定義されたプロトコルを元に作られた新しいプロトコルについて記述する. この新しいプロトコルは, サーバ上で異なる名前空間の鍵と証明書を管理するための呼び出しクライアントを許す. これらの名前空間は, サーバ上で動く任意のアプリケーション(たとえば, SSH, 鍵管理相互運用性プロトコル (KMIP), シンプルネットワーク管理プロトコル (SNMP)) を設定するクライアントを許可するために, サーバによって用いられる. この新しいプロトコルは, 公開鍵の追加/削除, 証明書の追加/削除, サーバによって知られている名前空間単位の現在の鍵と証明書の集合の列挙(たとえば SSH 名前空間のすべての公開鍵の列挙) のためのサーバに依存しない機構をクライアントに提供する. 特定の名前空間の鍵と証明書を管理する権限は, 認可されたユーザに特有のもので限定されており, サーバの実装の一部として定義される. この記述されたプロトコルは, RFC 4819 で定義された バージョン 2 と後方互換性がある. このメモの位置づけ この文書は, インターネット標準課程仕様ではない. 情報共有目的で発行される. This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741. Joseph & Susoy Informational [Page 1] RFC 7076 P6R's Secure Shell Public Key Subsystem November 2013 Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7076. 著作権情報 Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. 目次 1イントロダクション ...............................................3 2. 用語 .....................................................3 3. 公開鍵サブシステムへの拡張の概要 ..............3 3.1. 拡張されたステータスコード ......................................4 3.2. バージョンパケット .........................................4 3.3. Namespace 属性 ....................................4 4. 新しい操作 ..................................................5 4.1. 証明書の追加 .......................................5 4.2. 証明書の削除 .....................................6 4.3. 証明書の列挙 .......................................6 4.4. 名前空間の列挙 .........................................7 5. 公開鍵操作の拡張 .................................8 5.1. 公開鍵の追加 ........................................8 5.2. 公開鍵の削除 ......................................8 5.3. 公開鍵の列挙 ........................................9 6. セキュリティの考察 .........................................9 7. IANA の考慮 ............................................10 8. リファレンス .....................................................10 8.1. 標準のリファレンス ......................................10 8.2. Informative References ....................................10 Joseph & Susoy Informational [Page 2] RFC 7076 P6R's Secure Shell Public Key Subsystem November 2013 1イントロダクション この文書は, RFC 4819 で定義されたプロトルに基づく新しいプロトコルを記述する. このプロトコルは, 実装に依存しない方法で公開鍵と証明書を設定するのに利用できる. プロトコルの操作に名前空間の概念が追加される. これにより, クライアントがアプリケーションや組織構造によって鍵と証明書を管理できるようになる. P6R セキュアシェル公開鍵サブシステムは, セキュアシェルのトランスポート層 [3] とユーザ認証プロトコルの上で動作するよう設計されている. これは, クライアントに関連するサーバ上での公開鍵と証明書の管理する単純な仕組みをクライアントに提供するこれらの鍵と証明書は, サービスへのクライアントの認証に通常利用される. また, クライアントに返却する結果の暗号化にも同様に利用できる. アップロードされた鍵と証明書は, 鍵や証明書を利用するサーバ上で実行されるすべてのプロトコル(たとえば, SSH, SSL KMIP [8])とサーバ上で実行されるアプリケーションを設定できなければならない. この文書は, セキュアシェル公開鍵サブシステム [1] 文書を読んだあとにのみ読むべきだ. この文書で記述する新しいプロトコルは, [1] で記述されているプロトコルに基づいていて, 後方互換性がなければならない. 2. 用語 この文書でのキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" は, RFC 2119 [2] で記述されているように解釈される. 3. 公開鍵サブシステムへの拡張の概要 公開鍵サブシステムは, 公開鍵を追加/削除したり, サーバが知る現在の公開鍵を列挙したり, 証明書を追加/削除したり, サーバの知る現在の証明書の集合を列挙する, サーバに依存しない機構をクライアントに提供する. この安全な鍵配布機構は, "publickey@p6r.com" という名前の新しい SSH サブシステムによって実装される. Joseph & Susoy Informational [Page 3] RFC 7076 P6R's Secure Shell Public Key Subsystem November 2013 3.1. 拡張されたステータスコード 状態コードは, より機械可読な形式(ローカライズに適している)で状態を与える. 次の値を取りうる: SSH_PUBLICKEY_CERTIFICATE_NOT_FOUND 192 SSH_PUBLICKEY_CERTIFICATE_NOT_SUPPORTED 193 SSH_PUBLICKEY_CERTIFICATE_ALREADY_PRESENT 194 SSH_PUBLICKEY_ACTION_NOT_AUTHORIZED 195 SSH_PUBLICKEY_CANNOT_CREATE_NAMESPACE 196 失敗のコードの意味は, それらの名前に示されている. 失敗コード SSH_PUBLICKEY_ACTION_NOT_AUTHORIZED の利用ついてはセキュリティの考察を参照. 3.2. バージョンパケット クライアントもサーバも, 利用するプロトコルのバージョンを指定するバージョンパケットを送って接続を開始しなければならない. string "version" uint32 protocol-version-number この文書で新しいプロトコルバージョン 3 を定義する. RFC 4819 [1] で定義されたプロトコルと後方互換性を持てるように 我々ばバージョン 3 を利用する. 3.3. Namespace 属性 "namespace" 属性が, RFC 4819 で記述されたプロトコルに対して拡張として追加される. この属性の目的は, それぞれのグループがアプリケーションや組織構造を表わしているグループ群へアップロードされた鍵や証明書を管理可能にすることです. この属性は文字列で, 300文字を超えない文字で構成され UTF-8 形式 [5] で指定されなければならない. この新しいプロトコルは, SSHサーバの公開鍵の操作のために "ssh" namespace を用いる. namespace として何も与えられなかった場合, "ssh" 名前空間がデフォルトの名前空間と見なす必要がある. 慣例として, プトコロルに用いられる namespace は, プロトコルの標準の省略形の小文字の文字列だ. たとえば, "ssl" は Secure Socket Layer プロトコルに用いられる名前空間である必要がある. アプリケーションに対する namespace は プロダクトとベンダー名を含む必要がある. サーバ上にどの namescpace がすでに存在するか判断するのを助けるために, 4 節で新しい操作 "list-namespaces" が定義されている. Joseph & Susoy Informational [Page 4] RFC 7076 P6R's Secure Shell Public Key Subsystem November 2013 4. 新しい操作 P6R 公開鍵サブシステムは, RFC 4819 で定義された機能を次の操作で拡張する: add-certificate, remove-certificate, list-certificates, and list-namespaces. 4.1. 証明書の追加 クライアントが証明書を追加したいなら, クライアントは次を送る: string "add-certificate" string certificate format name string certificate blob boolean overwrite uint32 attribute-count string attrib-name string attrib-value bool critical repeated attribute-count times この要求は, 証明書をサーバがどこに保存するか知るために少なくとも "namespace" 属性を含んでいなければならない. 1つの証明書追加要求には, 1つだけの namespace 属性が利用できる. 同じユーザが同じ証明書を複数の namespace に保存できるが, それは別々の add-certificate 要求で為されなければならない. add-certificate 要求に現れる namespace がまだサーバ上に存在しないなら. この操作によって namespace が作られる. しかし, ユーザに namespace を作成する権限がなければ, サーバは SSH_PUBLICKEY_CANNOT_CREATE_NAMESPACE を返さなければならない. overwrite フィールドが false で指定された証明書が与えられた namespace にすでに存在する場合, サーバは SSH_PUBLICKEY_CERTIFICATE_ALREADY_PRESENT を返さなければならない. サーバがこれを返すとき, クライアントは ユーザに証明書を上書きするかどうかの選択を提供する必要がある. overwrite フィールドが true で指定された鍵が与えられた namespace にすでに存在しかつ上書きできない場合, サーバは SSH_PUBLICKEY_ACCESS_DENIED を返さなければならない. しかし, ユーザは指定された namespace に鍵を追加する権限がないかもしれない. ユーザが証明書を追加する権限がない場合, サーバは SSH_PUBLICKEY_ACTION_NOT_AUTHORIZED を返さなければならない. "certificate format names" が取りうる値の例: "X509", "pgp-sign-rsa", "pgp-sign-dss". 公開鍵と証明書ブロブの形式は SSH トランスポートプロトコル文書 [3] の6.6 節 "公開鍵アルゴリズム" で詳述されている. Joseph & Susoy Informational [Page 5] RFC 7076 P6R's Secure Shell Public Key Subsystem November 2013 ここで, X.509 証明書は certificate blob の中で DER 形式 [6] [7] を用いてエンコードされる. 4.2. 証明書の削除 クライアントが証明書を削除したいなら, クライアントは次を送る: string "remove-certificate" string certificate format name string certificate blob uint32 attribute-count string attrib-name string attrib-value repeated attribute-count times この要求は, 証明書をサーバがどこから削除するか知るために少なくとも "namespace" 属性を含んでいなければならない. 1つの証明書削除要求には, 1つだけの namespace 属性が利用できる. サーバは, 適切な場所から証明書の削除を試みなければならない. しかし, ユーザは指定された namespace から鍵を削除する権限がないかもしれない. ユーザが証明書を削除する権限がない場合, サーバは SSH_PUBLICKEY_ACTION_NOT_AUTHORIZED を返さなければならない. "certificate format names" が取りうる値の例: "X509", "pgp-sign-rsa", "pgp-sign-dss". 4.3. 証明書の列挙 クライアントが既知の証明書の一覧を取得したい場合, クライアントは以下を送る: string "list-certificates" サーバは, 0以上の次の応答を返す: string "certificate" string certificate format name string certificate blob uint32 attribute-count string attrib-name string attrib-value repeated attribute-count times Joseph & Susoy Informational [Page 6] RFC 7076 P6R's Secure Shell Public Key Subsystem November 2013 応答は, 特定の順序である必要はない. 実装はそれぞれ特定のオーダーで応答を返すだろうが, クライアントの実装は特定のオーダーの応答に依存しないほうがよい. この応答は, 証明書がどの名前空間にいるのかクライアントが分かるように 少なくとも "namespace" 属性を含んでいなければならない. 1つの証明書列挙要求には, 1つだけの namespace 属性が利用できる. 最後の "certificate" 応答に続いて, 状態パケットが送られなければならない. 4.4. 名前空間の列挙 クライアントがサーバ上に存在する名前空間を知りたい場合, 以下を送る: string "list-namespaces" サーバは, 0以上の次の応答を返す: string "namespace" string namespace name 認証されたユーザに対して名前空間の一部のみを公開してもよい. この場合, 応答するサーバは, 既存の名前空間のサブセットを返す. 後述のセキュリティの考察を参照のこと. 最後の "namespace" 応答に続いて, 状態パケットが送られなければならない. Joseph & Susoy Informational [Page 7] RFC 7076 P6R's Secure Shell Public Key Subsystem November 2013 5. 公開鍵操作の拡張 新しい操作の追加に加えて, この文書は RFC 4819 で定義された操作の拡張も記述する. 5.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 この要求は, クライアントが特定の名前空間に公開鍵を保存できるように 1つの "namespace" 属性を含んでいてもよい. 同じユーザに対して複数の名前空間に同じ鍵を保存することは可能だ. その場合は, 複数の追加要求が必要だ. 公開鍵の追加要求に現れる名前空間がまだサーバに存在しない場合, この操作によって作られる. しかし, ユーザに名前空間を作る権限がない場合, SSH_PUBLICKEY_CANNOT_CREATE_NAMESPACE をサーバは返さなければならない. 5.2. 公開鍵の削除 クライアントが公開鍵を削除したい場合, クライアントは以下を送る: string "remove" string public key algorithm name string public key blob uint32 attribute-count string attrib-name string attrib-value bool critical repeated attribute-count times この拡張は, 削除要求に属性を追加する. この要求は, 特定の名前空間から公開鍵をクライアントが削除するために, 1つの "namespace" 属性を含んでいてもよい. Joseph & Susoy Informational [Page 8] RFC 7076 P6R's Secure Shell Public Key Subsystem November 2013 5.3. 公開鍵の列挙 クライアントが既知の公開鍵の列挙をしたい場合, クライアントは以下を送る: string "list" uint32 attribute-count string attrib-name string attrib-value bool critical repeated attribute-count times この拡張は, 列挙要求に属性を追加する. この要求は, 特定の名前空間から公開鍵をクライアントが列挙するために, 1つの "namespace" 属性を含んでいてもよい. サーバは, 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 この応答は, 鍵が存在する名前空間をクライアントが知るために, "namespace" 属性を含んでいてもよい. 6. セキュリティの考察 このプロトコルは, 安全なチャンネル上で動作することとそのチャンネルの末端が認証されていることを前提としている. つまり, このプロトコルは, ネットワークレベルの攻撃からは非常に保護されていることを前提としている. このプロトコルは, サーバのアプリケーションに鍵と証明書をアップロードできる また 操作できる機構を提供する. 名前空間内のデータに対して特定のユーザのアクセスを制限するために必要とされるアクセス制御を実施するのは, サーバの実装の責任だ. たとえば, あるユーザが名前空間の内容を列挙できるが, その名前空間に対して鍵や証明書を追加したり削除したりできないという具合だ. サーバは, ユーザの行為が定義されたアクセス制御に反する場合は, SSH_PUBLICKEY_ACTION_NOT_AUTHORIZED を返さなければならない. Joseph & Susoy Informational [Page 9] RFC 7076 P6R's Secure Shell Public Key Subsystem November 2013 このプロトコルは, サーバが正しく実装され鍵に適用された属性を観測できるという前提をクライアントに要求している. サーバの実装エラーにより, クライアントが意図していないアクセスに対して鍵と証明書を認証に利用したり, 意図したものよりも少ない制限を適用する可能性がある. 7. IANA の考慮 3.1 節で 4 つの新しいステータスコードを定義したが, これらは [1] の 6.6.1 節 (規約) で定義された IANA の公開鍵サブシステムのステータスコードレジストリの 「私的利用」の範囲にある. この文書に対して IANA の対応は要求されていない. 8. References 8.1. Normative References [1] Galbraith, J., Van Dyke, J., and J. Bright, "Secure Shell Public Key Subsystem", RFC 4819, March 2007. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [3] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. [4] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Authentication Protocol", RFC 4252, January 2006. [5] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [6] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [7] ITU-T Recommendation X.690 (2002) | ISO/IEC 8825-1:2002, Information technology -- ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER). 8.2. Informative References [8] OASIS, "Key Management Interoperability Protocol (KMIP) 1.1", January 2013, . Joseph & Susoy Informational [Page 10] RFC 7076 P6R's Secure Shell Public Key Subsystem November 2013 Authors' Addresses Mark Joseph, PhD P6R, Inc 1840 41st Ave Suite 102-139 Capitola, CA 95010 US Phone: +1 888 452 2580 (x702) EMail: mark@p6r.com Jim Susoy P6R, Inc 1840 41st Ave Suite 102-139 Capitola, CA 95010 US Phone: +1 888 452 2580 (x701) EMail: jim@p6r.com Joseph & Susoy Informational [Page 11]