メインコンテンツへジャンプする

JPNICはインターネットの円滑な運営を支えるための組織です

ロゴ:JPNIC

WHOIS 検索 サイト内検索 WHOISとは? JPNIC WHOIS Gateway
WHOIS検索 サイト内検索
===================================
    __
    /P▲         ◆ JPNIC News & Views vol.478【臨時号】2007.8.16 ◆
  _/NIC
===================================
-------- PR -----------------------------------------------------------
━━━━━━  夢を叶えるレンタルサーバ「スマイルサーバ」━━━━━━━
★★★ 期間限定 おトクな割引キャンペーン実施中!(~9月末まで)★★★
ワンストップ対応を実現する便利なレンタルサーバです。
詳しくは…>> http://www.smileserver.ne.jp/
━━━━━━  NTTスマートコネクト(株) info@nttsmc.com  ━━━━━━
-----------------------------------------------------------------------
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ News & Views vol.478 です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

本号では、vol.470、vol.471、vol.476に続き、第69回IETFのレポート[第4弾]
として、セキュリティ関連WGの動向についてお届けします。

□第69回IETF報告 特集
○[第1弾] 全体会議報告 (vol.470)
   http://www.nic.ad.jp/ja/mailmagazine/backnumber/2007/vol470.html
○[第2弾] DNS関連WG報告 (vol.471)
   http://www.nic.ad.jp/ja/mailmagazine/backnumber/2007/vol471.html
○[第3弾] IPv6関連WG報告 (vol.476)
   http://www.nic.ad.jp/ja/mailmagazine/backnumber/2007/vol476.html

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第69回IETF報告 [第4弾]  セキュリティ関連WG報告
                                                 JPNIC 技術部 木村泰司
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

第69回IETFでは、セキュリティエリアのセッションが18開かれました。そのう
ちの一つはBoFでした。本稿では、PKI(Public-Key Infrastructure)と、リ
ソース証明書に関連するWG、並びにTAM(Trust Anchor Management) BoFについ
て、お送りいたします。

◆PKIX WG (Public-Key Infrastructure (X.509))

PKIX WGのミーティングは、5日目の2007年7月26日(木)に行われました。
PKIX WGは、電子的な認証基盤の規格であるITU-TのX.509をインターネットに
適用して、新たな規格作りを行っているWGです。アジェンダが多くなりがちな
PKIX WGにしては1時間と短く、最後に行われたWebDAVを使ったデモは、
unofficial PKIX WGという位置づけで、休憩時間を割いて行われました。

最初はドキュメント策定状況の確認です。メッセージの簡略化等を図った
Lightweight OCSPと、subjectAltName拡張フィールドにホスト名やプロトコル
名等を入れる仕様のService Name SANは、IESGよりRFC化の承認を得ました。
現在、RFC Editorの処理待ちです。オンラインの証明書検証プロトコルである
SCVP(Server-based Certificate Validation Protocol)と、RFC3280の改良版
(RFC3280bis)、それからCMC(Certificate Management over CMS)に関わる三つ
のドキュメント(下記)は、IESGのレビューを受けている最中です。

   □ Certificate Management Messages over CMS 
      draft-ietf-pkix-2797-bis-04.txt

   □ Certificate Management over CMS (CMC) Transport Protocols
      draft-ietf-pkix-cmc-trans-05.txt

   □ CMC Complience Document
      draft-ietf-pkix-cmc-compl-03.txt

いよいよRFC3280bisがIESGのレビューに入りました。Certification Path
Building(RFC4158)やAuthority Information Access Certificate Revocation
List Extension(RFC4325)など、ドキュメントは別々になっていますが、各々
のRFC化が済んでおり、証明書とCRL(Certificate Revocation List)の処理に
関する基本的な仕様が、ある程度固まる時期が来つつあるかも知れません。

SCEP(Simple Certificate Enrollment Protocol)については、会場で若干議論
がありました。SCEPは、いくつもの商用のソフトウェア等で利用されている、
証明書の申請等のメッセージをやり取りするためのプロトコルですが、これま
ではWGにおけるRFC化が積極的に進められていませんでした。これはCMCという
機能的に似ていながら、異なるデザインのプロトコルがあったためだと考えら
れますが、SCEPを使ったプログラムが普及しつつあることはRFC化の大きな推
進理由となります。結局Informational RFCを目指して進められることになり
ました。

今回の新たな話題として、PKI Disaster Recovery and Key Rolloverと、
WebDAV for certificate publication and revocationの二つをご紹介しま
す。これらはWG後半、Related Specificationsの時間に、プレゼンテーション
が行われました。

PKI Disaster Recovery and Key Rolloverは、実は今回新しく提案されたもの
ではなく、2001年の7月に一度作られたことのあるドキュメントです。その時
のタイトルは、"PKI Disaster Planning and Recovery"だったそうです。今回
Joel Kazin氏によって再編集されたこのドキュメントは、プライベート鍵の危
殆化や喪失といった、例外的な状況から正常な運用に復旧する方法が書かれて
います。主にCPS(Certificate Practice Statement)を記述したり、PKIに関す
るディザスターリカバリープランを立てるために役立つ、Informational RFC
にすることが目指されています。記述されているディザスターリカバリーの対
象は、エンドエンティティ、認証局、Revocation Authority、Attribute 
Authority、タイムスタンプ局(Time-stamp Authority)です。プライベート鍵
の危殆化や喪失の他には、CRLのリポジトリに対するDoS(Denial of Services)
攻撃や、認証局のキーロールオーバー(鍵の更新)についても言及されていま
す。

クイックに復旧するという言葉から想像されるような、特殊な手法が提案され
ているわけではありませんが、復旧手段が網羅的にまとめられています。認証
局の運用や設計をされる方には、とても参考になるドキュメントになっていく
と思われます。

   □ PKI Disaster Recovery and Key Rollover
      draft-pinkas-pkix-pki-dr-kr-00.txt

WebDAV for certificate publication and revocationは、証明書やCRLのリポ
ジトリへのアクセスに、WebDAVを使う手法の提案です。リポジトリにアクセス
するためのプロトコルにはLDAP(Lightweight Directory Access Protocol)が
ありますが、LDAPはファイアウォールで遮断されがちであったり、証明書や
CRLの内容を使った、証明書データやCRLデータの検索ができなかったりしま
す。この提案は、HTTPやURIのデザインに影響しているREST(Representational
State Transfer)の考え方を取り入れ、WebDAVを使った証明書データやCRLデー
タの取得や格納、さらに発行や失効手続きとの関連する処理等について提案し
ています。

   □ Representational State Transfer (REST)
      「Architectural Styles and the Design of Network-based Software 
        Architectures」の第5章
      http://roy.gbiv.com/pubs/dissertation/rest_arch_style.htm

この手法を用いると、証明書やCRLのURLは以下のように示されます。

    https://dns.name/c=jp/o=NIR%20in%20Japan/cn=Taiji%20Kimura/
    サーバdns.nameにあるC=jp, O=NIR in Japan, CN=Taiji KimuraというCN
    が入った証明書データ

    https://dns.name/c=jp/o=NIR%20in%20Japan/cn=CRLs/
    サーバdns.nameにあるC=jp, O=NIR in JapanによるCRLの全て
    (シリアル番号が一つ一つ入った形のCRLが使われる)

会場では、リソース証明書にも適用できるように、名前を示す文字列として鍵
のハッシュ値が扱えるようにして欲しい、といった意見交換が行われていまし
た。

今回ご紹介した二つのドキュメントの他にも、PRQP(PKI Resource Discovery
Protocol)などの新しい作業項目が加わりました。まだまだPKIX WGの活動は続
きそうです。

◆SIDR WG (Secure Inter-Domain Routing WG)

SIDR WGは5日目の朝、9時から10時45分まで行われました。SIDR WGは、イン
ターネットにおけるドメイン間(AS間)の経路制御を、セキュアに行う仕組みを
検討しているWGです。今回のWGでは、主にドキュメントの更新に関する議論が
行われました。

現在、SIDR WGで行われている議論は大きく分けて三つあります。一つ目は、
RFC3779を使って、セキュアなルーティングを実現するアーキテクチャを、ド
キュメント化するための議論です。二つ目は、リソース証明書を発行する認証
局のCP(Certificate Policies)とCPSに関する議論で、Stephen Kent氏を中心
に議論が進められています。三つ目は、ROA(Route Origination 
Authorization)の書式と取り扱いに関する議論です。

SIDRのアーキテクチャについては、継続して行われている議論がいくつもあり
ます。まず、経路集約が可能な隣接するIPアドレスのリソース証明書を、どの
ように扱うかという議論があります。単一のISPに対して、レジストリが複数
のIPアドレスブロックを割り当てている場合、ISPは集約(route aggregation)
された経路を広告することが考えられます。しかし、リソース証明書は割り振
りブロックを含んだ形で発行されるので、広告される経路情報とリソース証明
書が一対一に対応しません。すると、集約されたプリフィックスの正しさを検
証できないことになってしまいます。この件については会場ではあまり議論さ
れず、MLで継続して議論が行われることになりました。他に「リソース証明書
とCRLを示すURLで、rsyncをプロトコルとして使うことが提案されているが、
書式上認められるのか」という議論も進行中で、今は作業を担当する人を探し
ている段階です。WGのマイルストーンによると、アーキテクチャは2007年3月
にはRFC化が目指される予定でしたが、大幅に遅れてしまっているようです。
ちなみに、4バイトAS番号については既に対応済みです。

   □ An Infrastructure to Support Secure Internet Routing
      draft-ietf-sidr-arch-01.txt

CPとCPSについては、本ドキュメントの策定における、時間的な制約に関する
議論が行われました。提案者であるStephen Kent氏によると、本ドキュメント
は、リソース証明書を発行する認証局が構築され始める頃には必ず必要になり
ますが、Internet-Draftの有効期限は6ヶ月であり、この期限内で有意義な議
論を進めることができるかという疑問が、Stephen Kent氏自身にもあるそうで
す。議論の結果、今後、ドキュメントの位置づけを明確化することが課題にな
りました。

ROAについては、ROAに含まれるprefixと、検証の対象であるBGP Updateに含ま
れる、NLRIとの比較ルールについて議論が行われました。前回のSIDR WGで
は、ROAに内包されるprefixが、NLRIに含まれるのであればよい、という方向
になっていましたが、前述の経路集約の問題があり、ROAとして比較ルールを
定めることは難しいことがわかってきました。ひとまずROAのドキュメントで
は比較ルールを記述しないことになりました。

   □ A Profile for Route Origin Authorizations (ROAs)
      draft-ietf-sidr-res-certs-08.txt

最後に、"Private AS space"というタイトルで、チェアのSandra Murphy氏よ
りプレゼンテーションがありました。これは、AS内のプライベートな経路制御
のためにユニークローカルアドレス(RFC4193)を使う場合、リソース証明書を
どこが発行すればよいのか、という疑問の投げかけです。これは、リソース証
明書のトラストアンカー(trust anchor - 信頼点)として何を想定すべきか、
という議論に発展しました。IANAをトラストアンカーとして想定すると、RIR
への追加割り振りがあった場合に、ユーザー環境のトラストアンカー証明書を
入れ替える必要がなく、手続きは簡単です。また、本来、トラストアンカーは
RP(Relying Party - 証明書検証者)によって選ばれることが望ましくもありま
す。しかし、現在のIANAが果たすとされている機能の中に、認証局が定義され
ておらず、RIRの認証局で対応せざるを得ないのが現状であるようです。

◆TAM BoF (Trust Anchor Management BoF)

電子証明書がVPNの機器などで使われるようになるにつれ、証明書検証で使わ
れるトラストアンカーとなる認証局証明書を管理することの重要性は、一層増
してきています。TAMは、Webブラウザや電子証明書の技術を使うVPN機器など
にある、トラストアンカー証明書を格納する領域をモデル化して"トラストア
ンカーストア"と呼び、トラストアンカーの取り扱いが標準化されていない状
況を改善する目的で開かれました。TAMは第69回IETFの最終日である7月27日
(金)の午前に行われたにも関わらず、70名以上の参加者がありました。

はじめに、トラストアンカーに関する課題点をまとめたCarl Wallace氏から、
課題点と解決策のあり方に関するプレゼンテーションが行われました。

  目標
   -トラストアンカーストアを管理するプロトコルを標準化する
    (トラストアンカー証明書の追加/削除/検索)
   -out-of-bandの信頼メカニズムへの依存を減らす

  機能要件
   -トランスポート(伝送路)との独立
   -トラストアンカーをユーザーが意識しない、または意識させない
    デバイスなどをサポート
   など

Carl Wallace氏がまとめたドキュメントを以下に示します。

   □ Trust Anchor Management Problem Statement
      draft-wallace-ta-mgmt-problem-statement-01

会場では、Webブラウザをこの議論に含めるべきかどうかについて、意見交換
が行われました。また、リソース証明書における、この議論の重要性に関する
指摘もありました。しかし、このBoFをWGにするかどうかは決まらず、MLを通
じてこの議論の目的と意義を議論することになりました。その後、状況に応じ
て趣意書を作ることになりそうです。

               ◇                ◇                ◇

IETFチェアにRuss Housley氏が、そしてセキュリティエリアのエリアディレク
ターにTim Polk氏が就任し、PKIX WGでお会いしていた方々が、IETF全体で活
躍されるようになりました。また、IABチェアには、RIPEミーティングでいつ
もユーモラスなプレゼンテーションをされていた、Olaf Kolkman氏が就任され
ました。

私にはIETFが少し身近に感じられる一方、彼らが発言の度に慎重に言葉を選
び、そしてミーティング中も忙しそうにされている様子が、少し気の毒に思え
ます。今の私には、体調を壊されないよう応援する以外にできることが少なそ
うです。


     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       わからない用語については、【JPNIC用語集】をご参照ください。
            http://www.nic.ad.jp/ja/tech/glossary.html
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
___________________________________
■■■■■  JPNICの活動はJPNIC会員によって支えられています  ■■■■■
  :::::  会員リスト  :::::  http://www.nic.ad.jp/ja/member/list/
  :::: 会員専用サイト ::::  http://www.nic.ad.jp/member/(PASSWORD有)
□┓ ━━━  N e w s & V i e w s への会員広告無料掲載実施中 ━━━┏□
┗┛          お問い合わせは  jpnic-news@nic.ad.jp  まで          ┗┛
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
===================================
 JPNIC News & Views vol.478 【臨時号】

 @ 発行         社団法人 日本ネットワークインフォメーションセンター
                 101-0047 東京都千代田区内神田2-3-4 国際興業神田ビル6F
 @ 問い合わせ先   jpnic-news@nic.ad.jp
===================================
登録・削除・変更   http://www.nic.ad.jp/ja/mailmagazine/


■■◆                          @ Japan Network Information Center
■■◆                                     @  http://www.nic.ad.jp/
■■

Copyright(C), 2007 Japan Network Information Center

このページを評価してください

このWebページは役に立ちましたか?
ページの改良点等がございましたら自由にご記入ください。

このフォームをご利用した場合、ご連絡先の記入がないと、 回答を差し上げられません。 回答が必要な場合は、お問い合わせ先をご利用ください。

ロゴ:JPNIC

Copyright© 1996-2022 Japan Network Information Center. All Rights Reserved.