ニュースレターNo.35/2007年3月発行
セキュリティ関連WG報告
第67回IETFではセキュリティエリアのセッションが21行われました。その中の二つがBoFで、残りの19セッションがWGでした。本稿では、この中からSIDR WGとPKIX WGを中心に報告いたします。リソース証明書についてはAPNICやRIPE NCCの動向を踏まえてお送りしたいと思います。
SIDR WG （Secure Inter-Domain Routing WG）
SIDRWGはネットワーク・ドメイン間の経路制御に適用できる新たなセキュリティの仕組みを策定・開発することを目的としたWGです。このWGは2006年4月に結成され、WGとしてのセッションが開かれるのは前回の第66回IETFに続いて今回が2回目となります。
SIDR WGでは、IPアドレスの割り振りを電子証明書で証明する認証基盤の検討が進められています。この電子証明書はリソース証明書と呼ばれ、主にルーティングの安全性向上のために使われるとされています。
セッションの最初にWGのステータスの確認が行われました。SIDR WGの趣意書で示されたマイルストーンでは、以下の三つのinitial draftが投稿される予定でした。
- inter-domain routing security
ドメイン間のルーティングセキュリティ - certificate objects
電子証明書の内容と処理手続き - securing origination of routing information
経路情報の発信元情報を安全にする手法
このうち2番目はリソース証明書の書式に関するもので、すでにAPNICのGeoff Huston氏によって進められています。1番目と3番目は、これまでに大きな取り組みがなく、今回のミーティングで活動を開始することが確認されました。またルーティングセキュリティアーキテクチャについてのInformational RFCと、セキュアオリジンメカニズムに関するProposed Standard RFCが作られることが予定されていましたが、これらは議論があまり行われてきていなかったことから、作成を取りやめる可能性がチェアによって示されました。これまでリソース証明書の議論に注力してきており、セキュアなルーティングアーキテクチャの具体化に、手が回っていなかったのが実情のようです。
- □Secure Inter-Domain Routing （sidr）
- http://www.ietf.org/html.charters/sidr-charter.html
今回のBoFでは主に四つの話題について議論されました。
- Geoff氏によるリソース証明書に関するI-Dの02版について
- Stephen Kent氏によるCPS（Certification Practice Statement）CP（Certificate Policy）に関するドラフトドキュメント
- ROA（Route Origination Authorization）のデータ形式に関する提案
- RIPEドキュメントとなっているRPSLとROAとの整合性
ここでは1と4についてご報告いたします。
一つ目のGeoff氏のリソース証明書に関するプレゼンテーションでは、何点かの改良を行った、リソース証明書に関するドラフトドキュメントの02版について説明されました。リソース証明書には全て（割り振り先の）証明書を発行するために認証局であることを示すビットが立つことが想定されていましたが、このビットが立っていないEE証明書が新たに紹介されていました。しかし複数の割り振り元があるマルチホームの状態である場合などで、これらの証明書がどのように使われるか、といった具体的な使い方が明らかになっておらず、今後も検討が進められると考えられます。
Geoff氏のプレゼンテーションの後半では、“リソース証明書の利用”と題して、電子署名のWebインターフェースのデモが行われました。このWebのプログラムは10月に行われた第53回RIPEミーティングや第18回ARINミーティングで使われたものとほとんど同じです。Webアプリケーションとして動作するもので、サーバ側にある鍵を使って電子署名が行われます。このデモについて、RIRのミーティングでは、このデモの動作の内容については特に議論されませんでしたが、SIDR WGでは運用面でさらに突っ込んだ議論になりました。結局、リソース証明書をエンドユーザー同士でどのように交換するかのガイドラインが必要になることがわかりました。
リソース証明書のモデルはシンプルですが、証明書の構造は徐々に複雑になってきました。また第53回のRIPEミーティングではルーティングセキュリティにおける効果がわからないという指摘を受けてもいます。IETFのSIDR WGとしては仕様を検討してドキュメント策定を進めることになりますが、利用モデルが見えない中で複雑化が進んでいった場合に、運用しやすいものになるのか、という懸念は残ります。
四つ目の議論は、ROAではASパスを保護できないという点についてです。ROAは経路情報の発信元がIPアドレスを利用する権利を持つことを保証します。しかし経路情報が伝播するASパスの正しさを保証することはできません。これはルーティングにおけるセキュリティの要件をまとめているRPSEC WGのドキュメントに依存する議論となりそうです。RPSEC WGでは、ASパスのセキュリティに関するドキュメント作成にも取り組んでおり、2007年の3月頃にWG last callになる見込みであるとのことです。RPSEC WGのドキュメントがまとまる頃には、SIDR WGで扱われるプロトコルが増え、ASパスの安全性向上を図るプロトコルが現れるかもしれません。
PKIX WG（Public-Key Infrastructure （X.509））
PKIXWGは電子的な認証基盤の規格であるITU-TのX.509をインターネットに適用して新たな規格作りを行っているWGです。PKIXは長寿のWGで、参加者は顔なじみの方が多いようです。
はじめにドキュメントステータスの確認が行われました。新たにRFCになったのは以下の二つです。
- －Internet X.509 Public Key Infrastructure SubjectIdentification Method (SIM) (RFC 4683)
-
http://www.ietf.org/rfc/rfc4683.txt
個人が特定できるような識別子（米国のソーシャルセキュリティナンバーなど）を直接電子証明書に載せる代わりに、一方向性ハッシュ関数の結果を入れるなどして、第三者に対して匿名性を確保する手法を提案したRFC。元々は韓国のJongwook Park氏によって提案され、後に前チェアのTim Polk氏によって引き継がれた。
- －Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile (RFC 4630)
-
http://www.ietf.org/rfc/rfc4630.txt
RFC3280に記述された、ディレクトリ文字列のエンコードに関する部分を変更したドキュメント。ディレクトリ文字列は証明書の発行元や発行先の記述のために使われる文字列で、一時期は国際化と相互運用性を図るためにUTF-8の利用が推奨された。しかし実装の現状を鑑みて、移行期限であった2003年12月31日という記述は削除された。なお、本RFCでは、UTF8StringとPrintableStringの二つが推奨されている。
IESGのレビューを受けているドキュメントは以下の六つで、これらはまだ修正のための検討の余地が残っているようです（2007年1月現在）。
- Certificate Management Messages over CMS
- Certificate Management over CMS
(CMC) Transport Protocols - CMC Complience Document
- Server-based Certificate Validation Protocol
(SCVP) - Lightweight OCSP Profile for High Volume
Environments - Internet X.509 Public Key Infrastructure Subject
Alternative Name for expression of service name
最後のSubject Alternative Name for expression of service nameは、DNSのリソースレコードに記述されたホスト名とサービス名を証明書のSubjectAltNameフィールドに載せ、ホスト認証だけでなく個々のサービスを行っているサーバの認証を行えるようにしたものです。マッチングルールを用いて、メールサーバのような同一のサービスを複数のサーバで提供している場合にもSRV RRと証明書を組み合わせて認証できるようになっています。
セッションの中で多くの議論が行われたのが、Elliptic Curve Cryptography公開鍵識別子に関するデザインチームのレポートです。アルゴリズムの識別子を定義しているRFC3280に則った方法では、楕円暗号を使った鍵交換プロトコルのEC-DHとEC-MQVを識別することができません。そこで、識別のための三つの手法を比較することになりました。議論はメーリングリストで継続されることになっています。
最後に"Certificates in CRLs"と題してMicrosoftのStefan Stantesson氏によるindividualドラフト（WGのドラフトではない個人作成のドキュメント）の紹介が行われました。このドキュメントでは、CRLの中に証明書データを入れておいて、CRLの署名検証のときに行われるパス構築（検証したい証明書と信頼されたCAまでの間の証明書のツリー構造を作ること）の補助をする仕様が提案されています。CRLを発行した認証局の鍵が変更されたときなど、そのCRLの署名を行った鍵を見つける必要がある場合には、RFC4325で定義されているCRL拡張を使って鍵の識別子を読み出して探す方法があります。しかし検証対象のCRLが古く、それを発行した認証局の証明書がネットワークを使って得られなかったり、必要な数の証明書を入手するまでに多くのネットワークアクセスを伴う可能性があります。このドキュメントでは、これらの処理を軽減させるために、CRL拡張の中に入った証明書データを使うことを提案しています。会場では、このドキュメントをWGドキュメントとするかどうかについて議論されましたが、今後メーリングリストを使って方向性が決められることになりました。
- □Internet X.509 Public Key Infrastructure
Authority Information Access Certificate Revocation
List（CRL）Extension - http://www.ietf.org/rfc/rfc4325.txt
IETFでは、議論の合理性や方向性などについて真剣に話し合われることがしばしばありますが、セッションの終了後や休憩時間には、まれにユーモラスな遊び（?）が繰り広げられていることがあります。ある方は、IETFやRIPEミーティングなどの国際会議で出会った人々と有名なテレビ番組の人形を一緒に写真におさめて、Webページにまとめています。光栄なことに私も撮っていただきました。
- □Bert meets the stars
- http://bert.secret-wg.org/Stars/
この写真を撮ってらっしゃる方は、WGのチェアやIABのメンバーなどをされていて、RIRのミーティングなどでも大変活躍をされている方です。ちなみに写真のコメント文には、それぞれの方の専門分野をからめたシャレが書かれています。私もいつか自分の専門分野についてのコメントをいただけるようになれたらと、密かに思いました。
（JPNIC 技術部 木村泰司）
