RFC 9255: RPKIの「I」はアイデンティティを表すものではない
要旨
RPKIの中のインターネット番号リソース(INR)は、INRの「保有者」の現実世界のアイデンティティに関連付けられるという誤ったイメージがある。本文書は、RPKIがINRの保有者に関連付けられないことを規定する。
本文書の位置付け
本文書は、インターネット標準化過程の文書である。
この文書はInternet Engineering Task Force (IETF)の成果物である。IETFコミュニティのコンセンサスを表すものである。公開レビューを受けており、Internet Engineering Steering Group (IESG)によって公開が承認されている。インターネット標準の詳細については、RFC 7841のセクション 2を参照のこと。
本文書の現在のステータス、正誤表、および文書に対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9255 で入手できる。
著作権表示
Copyright (c) 2023 IETFトラストおよび文書の著者として特定された人物。無断転載を禁じる。
本文書は、BCP 78および文書の発行日において有効なIETF文書に関するIETFトラストの法的規定(https://trustee.ietf.org/license-info)に従うものとする。これらの文書には、本文書に関するあなたの権利と制限が記載されているため、注意深く確認して欲しい。文書から抽出されたコード・コンポーネントには、トラスト法的条項のセクション4.eに記載されている改訂BSDライセンスのテキストを含まなければならず、改訂BSDライセンスに記載されているように保証なしで提供する。
1. はじめに
リソース公開鍵基盤(RPKI)([RFC6480]を参照)は、「IPアドレス空間と自律システム(AS)番号の割り当て階層を表す」ものであり、インターネット番号リソース(INR)と総称される。最初の導入以来、RPKIは他の同様のリソースとルーティング・データ、例えばBGPsec[RFC8635]のためのルータ・キーイングを含むまでに成長した。
セキュリティ用語では、「公開鍵」という表現は、対応する秘密鍵も存在することを意味する[RFC5280]。RPKIは、INRの現在の保有者に強力な権限を与える。しかし、RPKIの秘密鍵を使用して、リソースのINR「保有者」として任意の文書に署名し、その署名が文書内容の真正性を証明するものとみなされるという不適切な期待を抱く人もいる。しかし、実際には、RPKI証明書は、明示的に識別されたINRを代弁する認可に過ぎず、INRの「保有者」の認証を意図したものではないことは明らかである。この状況は[RFC6480]のセクション2.1で強調されている。
INR保有者の署名で現実世界のビジネス取引を認証できる可能性が示唆されている。例えば、Bill's Bait and Sushi (BB&S)は、RPKIのAS保有者であることを証明する秘密鍵を使用して、BB&Sが所有するハードウェアのラックとスタックを他の当事者に依頼するための承認書(LOA)に署名することができる。残念ながら、これは技術的には可能かも知れないが、適切でも意味のあることでもない。
RPKIの「I」は実際には、「アイデンティティ」ではなく、リソース公開鍵基盤と同様に「基盤」を表す。実際、RPKIは、INRの現実世界の保有者との間の関連付けを提供しない。RPKIは、IPプレフィックスやAS番号などのインターネット番号リソース、及び自律システム・プロバイダ認可(ASPA)レコード[ASPA-PROFILE]などのデータに関してのみ、アサーションを行う権限を提供する。
要するに、RPKI 証明書をINRの委任に関連する認可の検証またはINRに関連する認証以外の目的に使用することは避ける。代わりに、これらの認可及び認証は、RPKI秘密鍵の所有者の身元に関係なく行われることを認識する。
1.1.要件言語
この文書のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すように、すべて大文字で表示される場合に限り、 BCP 14 [RFC2119] [RFC8174]の記述に従って解釈される。
2. RPKIは認可用である
RPKIは、RPKI自体の中で使用する証明書に署名するため、及びルーティングで使用する経路オリジン認証(ROA)[RFC6480]を生成するために設計及び規定された。RPKIの設計では、とりわけ、認証局(CA)が責任を負うことになるため、現実世界のアイデンティティを証明するために使用することは意図的に除外されている。
RPKIが現実世界のアイデンティティを認証しないのは、設計によるものである。もしそうしようとすれば、法的責任は別として、終了の証明がない複雑な世界になってしまうだろう。
地域インターネット・レジストリ(RIR)のようなレジストリは、WHOIS[RFC3912]及び同様のサービスを通じて、INRと現実世界のアイデンティティのマッピングを提供する。RIRは、少なくとも割り当てたINRに関しては権威があると主張する。
つまり、INRのRPKIベースの資格情報を、現実世界の文書や取引の認証に使用してはならない(MUST NOT)。これには、匿名のINR保有者が特定の文書や取引を認証できるような、何らかの正式な外部権威認証が必要かも知れない。このような外部、つまり非RPKIの権威の検証を考慮すると、RPKIベースの資格情報を使用しても真正性を追加しない。
3. ディスカッション
RPKI基本文書[RFC6480]のセクション2.1には、「このPKIの重要な特性は、証明書がサブジェクトのアイデンティティを証明しないことである」と明確に規定している。
「リソースPKI(RPKI)の証明書認証局運用規程(CPS)のテンプレート」[RFC7382]のセクション3.1では、各証明書のサブジェクト名は意味を持つものであってはならない(SHOULD NOT)と規定しており、このことについて詳しく説明している。
通常、INRの保有者は、リソースを証明(CAが行う)する秘密鍵を保持しない。INRの保有者は、CAと現実世界のビジネス関係にあり、現実世界の文書に署名している可能性が高い。
INRの保有者は、鍵材料(暗号鍵やその生成に関連するデータ)を持たないため、INRを操作するためには、おそらくCAに資格情報を提示することになる。これらの資格情報は、ユーザIDとパスワード(2要素認証を使用することを希望する)、ハードウェア・トークン、クライアント・ブラウザ証明書などである。
したがって、リソース・タグ付き証明書[RPKI-RTA]や署名済みチェックリスト[RPKI-RSC]などのスキームは、CAから関連すると思われる鍵を抽出するために、多大な労力を費やす必要がある。
ある特定のINR、例えばBill's Bait and Sushiの自律システム(AS)番号について、ネット上の誰かがBB&SのINRが登録されているCAアカウントの資格情報を持っている可能性がある。それは、BB&Sのオーナーかも知れないし、Randy's Taco Standかも知れないし、ITベンダかも知れないし、エルボニア政府のオーナーかも知れない。単純に知ることはできない。
大規模な組織では、INR管理は、INR登録処理以外の権限を持たず、細分化されていることが多い。Bill's Bait and SushiのINRマネージャーは、BB&Sの銀行取引を行う権限も、コロケーション施設にあるBB&Sのサーバへのアクセスを許可する権限さえも持っていそうにない。
次に、時間的な問題もある。ASの保有者は、文書が署名された時点ではBB&Sかも知れないが、明日はエルボニア政府かも知れない。あるいは、リソースがあるCAから別 CAに管理上移され、鍵の変更が必要になったかも知れない。もしそうなら、現実世界の文書の署名がまだ有効かどうかをどのように判断するのだろうか?
ゴーストバスター・レコード[RFC6493]は現実世界のエンティティを識別しているように見えるかも知れないが、その意味内容は完全に恣意的であり、INRの保有を証明するものではない。ゴーストバスター・レコードは、RPKIに技術的な問題が発生した場合に、運用サポートに連絡するための手がかりに過ぎない。
通常、CAは、INRを登録する前に、外部の文書及び当局を通じてINR保有の証明を要求する。CPSテンプレート[RFC7382]が、INRが実際に登録者によって保有されていることを確認するためにCAが実施しなければならない、あるいは実施する可能性のあるいかなる調査にも言及していないのは、いささか滑稽なことである。
誰かが特定のINRに署名する秘密鍵の「所有証明」を提供できたとしても、その人物がそのINRを保有する組織の有効な法的代表者だと解釈すべきではない。彼らはINRを管理する役割に就いている可能性はあるが、組織の正式な代表者ではない可能性がある。
自律システム番号は現実世界のエンティティを識別するものではない。これらは一部のネットワーク事業者が「保有」する識別子であり、ルーティングにおけるループ検出のためだけに使用する。これらには、一意性以外に固有の意味はない。
4. セキュリティに関する考慮事項
RPKI データを使用して、現実世界の文書やアイデンティティを必要とする他の成果物を認証しようとする試みは、RPKI内では暗号的に有効である可能性はあるが、真正性に関して誤解を招きかねない。
文書がRPKI証明書に関連付けられた秘密鍵で署名すると、署名者は証明書内のINR(IPアドレス空間とAS番号)を代弁することになる。これはアイデンティティではなく、認可である。リソースタグ付き証明書[RPKI-RTA]や署名済みチェックリスト[RPKI-RSC]などのスキームでは、署名済みメッセージはINRの範囲がさらに狭める。メッセージのINRは、証明書のINRのサブセットである。署名が有効であれば、メッセージの内容は、そのINRのサブセットを代弁する権限を与えられた当事者から提供されたものである。
あるエンティティのINRの管理は、INR管理者が権限を持たない取引や文書を不正に承認するために使用される可能性がある。
5. IANA に関する考慮事項
本文書にはIANAのアクションはない。
6. 参考文献
6.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC5280] 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, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480, February 2012, <https://www.rfc-editor.org/info/rfc6480>.
[RFC7382] Kent, S., Kong, D., and K. Seo, "Template for a Certification Practice Statement (CPS) for the Resource PKI (RPKI)", BCP 173, RFC 7382, DOI 10.17487/RFC7382, April 2015, <https://www.rfc-editor.org/info/rfc7382>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8635] Bush, R., Turner, S., and K. Patel, "Router Keying for BGPsec", RFC 8635, DOI 10.17487/RFC8635, August 2019, <https://www.rfc-editor.org/info/rfc8635>.
6.2.参考規格
[ASPA-PROFILE] Azimov, A., Uskov, E., Bush, R., Patel, K., Snijders, J., and R. Housley, "A Profile for Autonomous System Provider Authorization", Work in Progress, Internet-Draft, draft- ietf-sidrops-aspa-profile-07, 31 January 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-aspa-profile-07>.
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, DOI 10.17487/RFC3912, September 2004, <https://www.rfc-editor.org/info/rfc3912>.
[RFC6493] Bush, R., "The Resource Public Key Infrastructure (RPKI) Ghostbusters Record", RFC 6493, DOI 10.17487/RFC6493, February 2012, <https://www.rfc-editor.org/info/rfc6493>.
[RPKI-RSC] Snijders, J., Harrison, T., and B. Maddison, "A profile for Resource Public Key Infrastructure (RPKI) Signed Checklists (RSC)", Work in Progress, Internet-Draft, draft-ietf-sidrops-rpki-rsc-08, 26 May 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-rsc-08>.
[RPKI-RTA] Michaelson, G., Huston, G., Harrison, T., Bruijnzeels, T., and M. Hoffmann, "A profile for Resource Tagged Attestations (RTAs)", Work in Progress, Internet-Draft, draft-ietf-sidrops-rpki-rta-00, 21 January 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-rta-00>.
謝辞
著者らは、活発な議論をしてくれたジョージ・ミケルソンとジョブ・ スナイデルス、正式な文章を書いてくれたジェフ・ヒューストン、有益な提案をしてくれたタイズ・デ・コック、多くの理事会とIESGの査読者、そして最後に、Bill's Bait and Sushiを貸してくれたビフに感謝する。
著者のアドレス
ランディ・ブッシュ
Arrcus & Internet Initiative Japan Research
5147 Crystal Springs
Bainbridge Island, WA 98110
アメリカ合衆国
メール: randy@psg.com
ラス・ハウスリー
Vigil Security, LLC
516 Dranesville Road
Herndon, VA 20170
アメリカ合衆国
メール: housley@vigilsec.com
更新履歴
- 2024.5.24
Discussion