ニュースレターNo.32/2006年3月発行

第64回IETF

1. 全体会議報告

◆概要

2005年11月6日(日)～11月11日(金)、カナダのバンクーバーにあるThe Westin Bayshore Resortand Marinaにて、第64回IETFが開かれました。今回のホストはNortel社で、スポンサーはBC.NET、Symantec社、Telus社の3組織です。Symantec社を除いて、すべてカナダを拠点にしているネットワーク関連の企業や任意団体です。

IETFチェアの発表によると今回のIETFの参加登録者数は1,291名でした。前回(第63回)の1,454名よりは少ないものの、1,100名から1,500名で推移しているここ2年間では、まずまずといったところです。この時期のIETFは毎年アメリカ国内で行われてきましたが、アメリカへの入国手続きが煩雑化している国に配慮してか、今回はカナダで開催されました。参加国は40ヶ国と多かったのはその影響かも知れません。

IETFミーティングは基本的に、初日から始まるチュートリアルと2日目以降に行われるWGやBoFのセッション、4日目や5日目に行われるPlenary(全体会議)で構成されています。またIETFには含まれていませんがグローバルなインターネットの運用に関する調整を目的としたIEPG(Internet Engineeringand Planning Group) ミーティングが、おおむね毎回初日の午前に開かれています。

今回のIETFでは124のWGやBoFが開かれ、このうちBoFは14セッションでした。BoFは、WGが結成される前に活動趣意(チャーター)を決めたり、WGの必要性についてのコンセンサスを確認したりする会議です。

Plenaryの一つ目である“IETF Operations and Administration Plenary” は11月9日(水)に、二つ目の“Technical Plenary” は11月10日(木)に開かれました。

◆IETF Operations and Administration Plenary

IETF Operations and Administration Plenary は、IETFの活動全体の運営に関する報告と議論を扱う全体会議です。今回は、IETFチェアのBrianCarpenter氏によるチェア報告、ホストを務めるNortel社によるホスト報告とNOCの運用報告、IAD(IETF Administrative Director) からの報告、RFCEditor報告、IANA近況報告、PROTOチームの近況報告などが行われました。

チェア報告ではドキュメント策定状況の報告の他にPESCI(Process Evolution Committee of theIETF) が紹介されました。PESCIはIETFにおけるドキュメント策定プロセスの見直しを図るため、改善を図るべき範囲を特定し、議論を進めるためのチームです。今回のIETFで初めてのBoFが開かれ、策定プロセスを変更するにあたっての考え方を明確にする(明確化されたものはPrinciplesと呼ばれる)議論が行われました。この策定プロセスの見直しについては[1] にまとめられています。

[1]Goals and Principles for IETF Process Evolution
draft-davies-pesci-initial-considerations-00.txt

また続いて、TCP/IPの開発やIETFの創設といった貢献で有名なVinton G. Cerf氏とRobert E. Kahn氏がPresidential Medal of Freedomを受賞したことのお知らせがありました。Presidential Medal ofFreedomは米国の市民栄誉賞にあたるようです。

The Presidential Medal of Freedom
http://www.medaloffreedom.com/

IAD(IETF Administrative Director) からの報告では、IETFミーティング参加費用の値上げのお知らせがありました。ISOCからの補助額は毎年増加しており、2005年度には100万ドルを超える見込みがあるものの、RFC Editorの業務増強のための支出増加が見込まれ、参加費用の値上げに踏み切った模様です。2006年度以降に行われるIETFのミーティング参加費用は550ドルになるとのことです。

RFC Editor報告では、昨年に比べてRFC化の業務速度が向上しており、一月あたりの公開ドキュメント数が投稿される数(30程度)に近づいているとのことです。RFC Editorの編集待ちリストは以下のURLで見ることができます。

RFC Editor Queue
http://www.rfc-editor.org/queue.html

◆Technical Plenary

Technical PlenaryはIETFの活動のなかで技術的な議論を扱う全体会議です。IRTF(InternetResearch Task Force)の報告、IRTFのCFRG(Crypto Forum Research Group) のハッシュ関数の問題に関するプレゼンテーション、IABのチェア報告などが行われました。

IRTFの報告では新設されたリサーチ・グループの紹介とリサーチ・グループの状況報告が行われました。新設されたリサーチ・グループは、TransportModeling Research GroupとInternet CongestionControl Research Groupの二つです。

続いてIRTF CFRGのチェアであるDavid McGrew氏から、SHA-1やMD5といった、多くのプロトコルで使われている一方向性ハッシュ関数が脆弱になっている状況と、IETFにおける対策についての説明がありました。対策としてSHA-1やMD5の利用をやめ、SHA-256を利用する等の方法が挙げられました。

最後のIABのチェア報告では、IABの役割に照らし合わせた活動報告がありました。IABにはIESGやRFC Editorのメンバーの補ほ填てんのための候補選びやIETFにおける策定プロセス遂行状況の監視といった役割があります。

Charter of the Internet Architecture Board(IAB)
http://www.ietf.org/rfc/rfc2850.txt

今回のIETFではIABの主導により、TechSpec(Technical Specification)BoFが開かれました。これはドキュメント化の要求事項を見直す活動について議論を行うためのBoFです。IETFのWGにおける議論では、しばしばドキュメント化される技術に対するrequirement(要求事項)の整理とレビューが行われます。このプロセスを促進する意味で、現行のドキュメント策定プロセスを見直す必要性が指摘されています。BoFでは特に、draft-mankin-pubreq-01[2] を元に、IETFの現行のドキュメント策定プロセスの中で、編集のタイミングを見直すことについて議論が行われました。

[2]Requirements for IETF Technical Publication Service
http://www.ietf.org/internet-drafts/draft-mankinpub-req-01.txt

Technical Plenaryの最後のオープン・マイクロホン(参加者が自由に発言できる時間)では、JPNICIRR企画策定専門家チームのメンバーである長橋賢吾氏によってIRR(Internet Routing Registry)のあり方に関する議論が行われていました。世界各地域のIPレジストリはICANN/IANAを頂点とするIPアドレスの割り振り構造に従って木構造の関係を持っており、各IPレジストリにある登録情報の整合性を保ちやすい構造になっています。一方、IRRはIPレジストリのような構造を持たずに運用されており、登録情報の正しさを実質的に担保できるような仕組みはありません。

以前より、IRRをIPレジストリで運用し、IPレジストリの割り振り／割り当て情報と照らし合わせて、正しさを確認できるようにするという考え方があります。しかし、ある程度の数のルータ管理者に利用されているIRRと、IPレジストリの両方が一つの組織によって運用されているJPNICのようなケースは少なく、その効果や実現性が理解されにくい状況があるようです。

Technical Plenaryでは、木構造にするのは危険である、IRRはRIRよりも多く必要であり、例えばヨーロッパ地域ではNIRのあるアジア地域のようにはうまくいかない、といった意見が挙っていました。またオープン・マイクロホンの場ではありませんが、IETFのプロトコル策定の場だけでなく、ルーティングのコミュニティでの議論が必要だという意見が挙っていました。

今後、IRRの登録情報に関連したプロトコルの策定と、IRRにおける登録情報の正当性に着目した議論が活発に行われていくと考えられます。

(JPNIC 技術部木村泰司)

2. DNS関連WG報告

◆dnsext WG (DNS Extensions WG)

今回のdnsext WGミーティングでは、NSEC3とTrust Anchor Managementに関する議論が中心となりました。NSECにしか対応していないリゾルバとの互換性問題や、DoS攻撃への根本的な対処法はあるのか、等話し合われました。Issue Tracker(http://dnssec.nominet.org.uk/nsec3) が立ち上げられ、残る問題を解決していこうと確認されました。DNSSECが普及する前にDNSSECbisの仕様が議論されていることもあり、古い実装との互換性をどこまで考えるのか、また運用的に実用に耐えるためにはopt-inの仕様を盛り込まなければならない等、まだ多くの問題が残されています。

次に、Trust Anchor Managementに関しては、Trust Anchorの更新を自動的に行う方法について議論が行われました。Trust Anchorとは、DNSSEC検証の起源となる委譲点のことであり、DNSツリー全体で検証を行う場合には、ルートDNSサーバがTrust Anchorとなります。しかし、すべての検証をルートDNSから行うのは現実的ではなく、TrustAnchorを複数設けることによって、DNSSECにおけるデータの検証に対して規模性を持たせることが可能となります。このTrust Anchorリストの自動更新をするために、いくつかのプロポーザルが出されました。まだ議論は始まったばかりで、これからさらなる議論が行われていくと思われます。

dnsext WG
http://www.ietf.org/html.charters/dnsext-charter.html

第64回IETF dnsext WGミーティングのアジェンダ
http://www3.ietf.org/proceedings/05nov/agenda/dnsext.html

◆dnsop WG (Domain Name System Operations WG)

今回のdnsop WGミーティングでは、ドラフトの確認が中心の議題となり、特に新しい議論はなされませんでした。DNS Server ID(draft-ietf-dnsopserverid)に関するドラフトはWGラストコールがかかることとなり、ようやく標準化されそうです。エニーキャストを用いたDNSサーバの負荷分散が一般的になりつつある現状で、DNS Server IDは、運用管理のために必要な機能であると考えられます。他には、draft-ietf-dnsop-inaddr-requiredやdrafthuston-6to4-reverse-dnsといったドラフトも、早くWGラストコールしようと確認されました。最後に、dnsop WGのこれからの方向に関して議論が行われました。その結果、

(1) IPv4/IPv6 DNS co-existence issue
(2) DNSSEC operation
(3) General DNS operation
(4) DNS resolver

といった項目が挙げられました。やはりIPv4/IPv6の共存環境における運用上の問題点の解決、DNSSECの運用、ならびにDNSプロトコル自体に起因するDNS 運用上の問題点の解決が、WGの目的となっていくと思われます。これは最近のdnsopWGの議論と合致する方向性であり、これからのdnsop WGの方向性が確認された形となりました。

dnsop WG
http://www.ietf.org/html.charters/dnsop-charter.html
第64回IETF dnsop WGミーティングのアジェンダ
http://www3.ietf.org/proceedings/05nov/agenda/dnsop.txt

(JPNIC DNS運用健全化タスクフォースメンバー/東京大学情報基盤センター関谷勇司)

3. IPv6関連WG報告

本稿では、第64回IETFでのIPv6に関連したトピックスとして、IPv6、v6ops、softwireの各WGの動向についてレポートします。

◆IPv6 WG (IP version 6 WG)

IPv6基本スペックや、プロトコル自身の挙動にかかわる標準を扱ってきたIPv6 WGですが、今回でface-to-faceのミーティングは最後になります。理由として、IPv6に関する標準化は、既にIPv6 WGのみでなく、IETF全般にわたって実施されていること、IPv6 WGが取り扱っている内容に、現状特に大きな問題はないこと、などが挙げられています。

さて、最後のミーティングですが、11月8日(火)の午前中、9:00～10:30に一コマ実施されました(IETF の時間割ですが、前回のパリで実施された、遅くても20:00前にはすべてのWGミーティング、プレナリが終了するという改変の評判が良かったそうで、終了時間に関しては前回と同じような形になっています)。参加者もそこそこ多く、大きめの部屋がほぼ満席になっていました。

今回の主なトピックスは、

ルータ広告のM/Oフラグの扱いについて
IAB IPv6 Ad-Hoc groupの活動状況報告
IPv6コア仕様の標準化

などとなっています。

まず、従来通り、チェアよりIPv6 WGで取り扱っているドラフトの状況について報告がありました。前回までは、チェアが独自に報告用のWebページを用意していましたが、IETFにおいても各種ツールの整備が進んでおり、公式のドラフト等ドキュメント状況管理ページが用意されました。IPv6 WGに関する情報は、http://tools.ietf.org/wg/ipv6にあります。他のWGのドキュメント状況に関しても、http://tools.ietf.org/wgからたどることができます。各IETFWGの状況をつかむのに非常に便利ですので是非ご利用ください。

さて、「ルータ広告のM/Oフラグの扱いについて」の議題は、かなり前から議論されているものです。RFC2461 Neighbor Discovery for IP Version 6 の改版の際に、両フラグの利用方法があいまいであるとの指摘から議論が始まり、別ドラフトにして議論をしてきました。今回、MフラグはアドレスをDHCPv6で取得することを示すこと、OフラグはStateless DHCPv6で情報を取得することを示すこととし、RFC2461の新版に反映することとなっています。

IAB IPv6 Ad-Hoc groupでは、下記のような、今まで実施してきた活動の紹介がありました。

IABからIPv6に関する各種諮問を受け、意見を返すというグループのミッション
IANAがRIRに対するIPv6アドレス割り振りの際に、割り振りサイズについての意見照会をIABにしたことに端を発する、という設立経緯
RFC4147として発行されたIANAのIPv6アドレス空間利用規約の整備
RFC4159のip6.int廃止

IPv6 WGのIETFでのミーティングは今回で終了ですが、引き続き現在取り組んでいる関連RFCの改版は実施していくことになっています。また、IPv6に関連する話題を扱うために、メーリングリストは継続運用されることになっています。

IPv6 WG
http://www.ietf.org/html.charters/ipv6-charter.html
http://playground.sun.com/pub/ipng/html/ipng-main.html
第64回IETF IPv6 WG ミーティングのアジェンダ
http://www.ietf.org/proceedings/05nov/agenda/ipv6.txt
第64回IETF IPv6 WG ミーティングのプレゼンテーション資料
https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=64

◆v6ops WG (IPv6 Operations WG)

IPv6のデプロイメントに関する話題を扱うv6opsWGのミーティングは、11月7日(月)の午後、13:00～15:00の2時間枠で開催されました。今回、v6opsWGのミーティングマネジメントがうまくいっていないようで、直前までアジェンダが発表されず、発表されたアジェンダもMLに流れたのみでした(通常はWebにも掲載されます)。

今回の主なトピックスは、

企業でのIPv6利用に関するドラフトについての議論
draft-ietf-v6ops-ent-analysis-03.txt
ルーティングガイドラインドラフトについての議論
draft-blanchet-v6ops-routing-guidelines-00.txt
IPv6のポートスキャンに関するドラフトについての議論
draft-chown-v6ops-port-scanningimplications-02.txt

などです。

企業でのIPv6利用に関するドラフトも、かなり長い間議論が続いています。今回、このドラフトがExperimentalステータスであるDSTMプロトコルや、標準でないプロトコルを推奨していることが問題になりました。この推奨部分について、修正文案を作成し、その後にラストコールをかけることになりました。

ルーティングガイドラインのドキュメントでは、内容が昔の6boneのルーティングガイドラインに似通っているが、6boneはIETFが実施した実験だったため、ガイドラインに従うように要求できたが、一般のISPオペレーター等にはガイドラインは強制力を持たない、つまりルーティングガイドラインはIETFで実施する内容ではなく、レジストリコミュニティやオペレーターコミュニティで実施する内容だ、という意見が出されました。一方で、このようなガイドラインは提示することは必要である、という意見もあり、メーリングリストで継続議論となっています。

ポートスキャンに関するドラフトでは、IPv6はアドレス空間が広い分、IPv4よりもポートスキャンを受けにくいとされていますが、アドレスの付け方によってはその利点が生かせないことになる、としています。ポートスキャンを受けにくいアドレスの付け方やネットワークの構築方法について述べています。このドラフトは、WGドラフトとして議論をしていくことになりました。

v6ops WG
http://www.ietf.org/html.charters/v6ops-charter.html
http://www.6bone.net/v6ops/
第64回IETF v6ops WGのアジェンダは2006年2月1日現在、IETFのWebページに未掲載
http://ops.ietf.org/lists/v6ops/v6ops.2005/msg00667.html
(MLのアーカイブ)

◆Softwire BoF (softwire WG)

v6ops WGから分離し、第62回IETFでのTunneling Configuration BoF、前回のLightweight Reachability softWires BoFに引き続き開催されたSoftwire BoFですが、ミーティング開催直前にWGとして承認され、第一回のWGミーティングを兼ねることになりました。

このWGでは、主に以下の2つの問題を取り扱うこととしています。

トンネル技術を利用したユーザーアクセス部分の提供方法「Hubs ＆ Spokes」と呼んでいます。
コアネットワークのトンネル技術を用いた実現「Mesh」と呼んでいます。

今回は、問題提起、WGのスコープに関する議論を実施することに時間を使いました。一点目については、一般ユーザーにIPv6サービスを提供するためには現状、ユーザーアクセス機器の対応状況などからIPv6をネイティブで提供することが困難であり、トンネルを使用する方が効率がよいことから、ユーザーに自動的にトンネルサービスを提供する方法を検討していく、というものです。二点目は、コアネットワークをトンネルベースで自動構成する技術に関してですが、例として挙げられていたネットワークがIPv6ピュアネットワークで、その上でトンネルを用いてIPv4サービスを提供する、というものであったため、一般的でなく議論をする意味があるのか、という質問がされていました。

今後、WGのチャーターをMLで詳細検討することになっています。

softwire WG
http://www.ietf.org/html.charters/softwirecharter.html
第64回IETF softwire BoF ミーティングのアジェンダ
http://www3.ietf.org/proceedings/05nov/agenda/softwire.txt

(JPNIC IPアドレス検討委員会メンバー/NTT情報流通プラットフォーム研究所藤崎智宏)

4. ENUM/CRISP関連WG報告

本稿では、第64回IETFでのCRISPおよびENUMの各WGの動向についてレポートします。

◆CRISP (Cross Registry Information Service Protocol) WG

レジストリデータの検索照会のためのCRISP WGでは、まずインターネットドラフト(以下、I-D)の状況について確認を行いました。いずれも大きな問題はなく小変更を加えた上でIESGに送付されることになりました。

次に、ドメイン名用のIRIS DREG(RFC 3982)発表後に提起された新たな(マイナーな)要求を盛り込むべくDREG2が提案されました。現時点ではまだI-Dとしては提出されていませんが、次回IETFまでには今回のIETF での議論を反映しドラフトとなる予定です。議論された内容は新たな要素の追加、検索時の部分一致の導入、DNSSECに関する項目およびIDNに関する項目です。

最後に、長橋賢吾氏(JPIRR企画策定専門家チームメンバー)よりCRISP for IRR(RREG)について発表がありました。現在階層構造になっていないIRRをCRISPで扱うことが議論となり、このWGから分離独立して別途BoFを開催することとなりました。

CRISP WG
http://www.ietf.org/html.charters/crisp-charter.html
第64回IETF CRISP WGミーティングのアジェンダ
http://www3.ietf.org/proceedings/05nov/agenda/crisp.txt
インターネット10分講座CRISP ＆ EPP
http://www.nic.ad.jp/ja/newsletter/No25/080.html

◆ENUM (Telephone Number Mapping) WG

DNSを用いてインターネット電話で使用される電話番号とインターネットリソースの対応付けを行うための方式であるENUMを扱う本WGでは、議題が多く2コマ続けての議論となりました。

まずチャーターの変更についての議論が行われ、キャリアENUM^※1の実装の可能性について調査することが盛り込まれました。ENUMの中核となるRFC3761は現在Proposed Standardとして標準化されていますが、相互接続での実装のための必要性から、このRFCをDraft Standardにすることも盛り込まれました。

その後、各I-Dについてレビューが行われました。キャリアENUMへの関心を反映してか、キャリアENUM関連のI-Dが2点、前回(パリでのIETF63)より引き続き議論されました。一つはキャリアENUM についての要件について、もう一つはキャリアENUMとユーザENUMを同一のDNSツリーに収めても問題ないように、e164.arpaの下にcarrierサブドメインを入れてサブツリーを作成することを提案するものです。前者ではキャリアENUMと呼ぶ代わりに、インフラストラクチャENUMと名称を変えることが合意されました。

その他に、DNSの拡張であるEDNS0をENUMに使う提案、ENUM ServiceへvCardを登録する提案、主に番号ポータビリティに使うことを想定してEnumserviceに電話網のデータのための識別子「pstn:」を登録するための提案などが議論されました。

ENUM WG
http://www.ietf.org/html.charters/enum-charter.html
第64回IETF ENUM WGミーティングのアジェンダ
http://www3.ietf.org/proceedings/05nov/agenda/enum.txt
JPNICのENUMに関するWebページ
http://www.nic.ad.jp/ja/enum/
インターネット10分講座●ENUM
http://www.nic.ad.jp/ja/newsletter/No21/080.html

(JPNIC 技術部山崎信)

5. セキュリティ関連WG報告

第64回IETFでは、セキュリティエリアのセッションが合計で18行われました。このうちBoFはDKIM BoF^※2とEMU BoF^※3の二つでした。DKIM BoFによって、2004年秋のMARID WGのクローズ以降、迷惑メール対策になる技術に関するIETF活動が再度始まったと言えます。またセキュリティエリアではありませんが、セキュリティに関連してSIDR BoFが開かれていました。

本稿では、SIDR BoFとPKIX WG、IEPGでのAS番号の枯渇と電子証明書に関する話題などについて報告致します。

◆SIDR BoF (Secure Inter-Domain Routing BoF)

これまでRPSEC WGにおいて、インターネットにおけるルーティングの仕組みについて安全上の要件をまとめる作業が行われてきました。

"Generic Threats to Routing Protocols"
draft-ietf-rpsec-routing-threats-07.txt
ルーティング・プロトコルに対する脅威を、原因・可能性・脅威となる挙動・その結果といった形でまとめたもの。
"BGP Security Requirements"
draft-ietf-rpsec-bgpsecrec-03.txt
ルーティング情報の交換プロトコルであるBGP(Border Gateway Protocol)を安全にするための要件(requirements)についてまとめたもの。ピア関係やBGPスピーカー同士、交換される経路情報の認証など複数のポイントについてまとめてある。

これらのドキュメントを通じてルーティングの安全性に関する認識が共有できるようになってきたことから、このBoFは論点を先に移して、ドメイン間ルーティングのセキュリティ・アーキテクチャについて議論し、さらにBGPの安全性の機能を定義する、といった活動を行うために開かれました。

このBoFでは、まずこの議論とドキュメント化活動がSIDRという新たなWGを設立して行われることの妥当性について議論されました。既にRPSECWGやIDR WGといったWGで、ドメイン間ルーティングのセキュリティについての議論が行われてきたためです。議論の結果、これらのWGでは安全上の要件や短期的な解決方法のドキュメント化が行われてきたのに対し、SIDRはドメイン間ルーティングのインフラストラクチャやプロトコルに着目し、経路情報の認証を行う仕組みを検討するという点で独自の趣意を持っていることが確認されました。

次にsoBGP、S-BGP、psBGPという三つのプロトコルのデザインについて紹介されました。これらは経路情報を交換するためのプロトコルであるBGPを拡張し、情報源の認証やASパスの検証といった手続きを通じて、ルーティングの安全性向上が図られたプロトコルです。

soBGPに関するI-D

draft-white-sobgp-architecture-01.txt
draft-ng-sobgp-bgp-extensions-01.txt
draft-weis-sobgp-certificates-01.txt

S-BGPの情報源

http://www.net-tech.bbn.com/sbgp/sbgpindex.html

psBGPに関するテクニカルレポート

http://www.scs.carleton.ca/research/tech_reports/2005/download/TR-05-08.pdf

いずれもIPアドレスとAS番号の偽装を防ぐために電子証明書が使われており、soBGPとS-BGPでは、その電子証明書がIPレジストリで運用される認証局によって発行されることが想定されています。IPアドレスの割り振りをIPレジストリの認証局が証明する(certificate) という意味があります。IPレジストリの認証局が発行した証明書を使うことで、経路情報に含まれているIPアドレスが正当に割り振られたものなのかどうかを判断できるようになるというわけです。

BoFでは、この証明の基盤に基づく経路情報の認証についての議論を進めることに協力するメンバーがいることが確認されました。SIDR WGが設立されると、経路情報の証明データに関するドキュメント活動が行われていくと考えられます。

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

PKIX WGのセッションは11月7日(月)の9時から行われました。約45名の参加で前回の約60名よりは減少しました。

前回の第63回IETF(2005年8月開催)から今回までの期間に、RFCになったドキュメントが三つ^※4、RFC Editorの編集待ちのドキュメントが三つ^※5という状況です。

RFC3280^※6の後継(通称RFC3280bis)の議論は、ドキュメント改定が進んでいるSCVP(SimpleCertificate Validation Protocol) への影響を避けるために一旦停止しています。PKIX WGのセッションの後に新たなドラフトの準備が行われるようです。

SCVPのI-Dは21版になりました。SCVPは電子証明書の検証を他のサーバに任せて行うためのプロトコルです。新たにSCVPのサーバが別のサーバからの返答をリレーできるようにするための拡張が行われたりしています。またSHA1等の一方向ハッシュアルゴリズムの脆弱化を受け、新たなハッシュアルゴリズムに対応できるような書式が盛り込まれることになりました。

10月に米国のNIST(National Institute of Standards and Technology：米国標準技術研究所)で行われたハッシュ・ワークショップでの議論の結果を受け、OCSP(Online Certificate Status Protocol) における新たなハッシュアルゴリズムへの対応手法について議論が行われました。OCSPはオンラインで失効状況を問い合わせるためのプロトコルで、応答の中で電子署名が使われています。ハッシュアルゴリズムの移行時期には複数の種類のハッシュアルゴリズムが使われることが考えられるため、問い合わせ側(requestor) は応答側(responder) が、どのハッシュアルゴリズムを使うのかを知っている必要があります。今のところ問い合わせ側が応答側に対し、事前に指定する方法が挙げられていますが、詳細の検討は今後行われる見込みです。

PKIX WGでは、OCSP以外のプロトコルでも新たなハッシュアルゴリズムに対応する必要性があることがわかっています。なおNISTのワークショップでは、当面2010年を目処にSHA-256というハッシュアルゴリズムへの移行が提案されており、業界全体としての移行プランの検討が始まっているようです。またSHA-256の次のハッシュアルゴリズムに関する検討も始まっているようです。

前回のIETFでプレゼンテーションが行われたdraft-ietf-pkix-srvsanはDNSのSRVレコードにあまり依存しない仕様になるようです。このドキュメントは"_ldap._tcp.domain.com"といったドメイン名のSRVレコードを使って証明書データをやり取りする手法を提案したものです。以前は、得られた証明書の中でsubjectAltNameとして指定された文字列と証明書の入手のために使われたドメイン名とが比較されることになっていました。新しい版では、問い合わせ側は予め対象のサーバのドメイン名とサービス名を知っているという前提に立ち、DNSのドメイン名ではなく、問い合わせ側でわかっている文字列(ユーザーに指定されたものなど)と比較をすることになりました。ただしこの用法の安全性は再検証される必要があると指摘されていました。

◆IEPGにおけるAS番号の枯渇と電子証明書に関する話題

IEPG(Internet Engineering and Planning Group)は主にインターネットのオペレーションに関して意見交換を行い、調整を行うためにIETFの直前に開かれている会合です。

The IEPG
http://www.iepg.org/

第64回IETFの直前に開かれたIEPGミーティングの中で、RIPE NCCのHenk氏がAS番号に関する電子証明書について紹介する場面がありましたので紹介します。

RIPE NCCのRIS^※7を使った調査によると、2005年8月1日現在、33681のAS番号が割り当てられていることがわかっています。AS番号として使える番号の総数は64511で、まだ残りがあるものの、ひと月に160前後の伸びがあるため、2013年から2024年の間に枯渇するという予測が立てられるとのことです。

枯渇を避ける方法として、AS番号のビット長を現行の16ビットから32ビットにする方法と、利用されていないAS番号を回収する方法の二つが考えられています。前者は、根本的な解決方法でありながらまだ実装がなく、移行プランも立っていません。一方後者は回収したAS番号が再び使われ始めるとAS番号の一意性が失われてしまうという問題があります。

Henk氏は後者の問題の対策として、電子証明書を使ってAS番号の利用の証明(certification) を利用する手段について紹介していました。電子証明書を利用すると有効期限を設定したり、有効期限内に失効させたりできるためです。前の利用者の電子証明書が有効かどうかを確認することでAS番号を再利用してよいかどうかの判断ができると考えられます。

このAS番号の電子証明書はRIPE NCCの2006年活動計画の中に入っているそうです。なお第20回APNICミーティングRouting SIGでも"resourcecertificate" という考え方が紹介されていました。今後、RIRで電子証明書を使ったIPアドレスやAS番号の証明(certification) がさらに検討されていくと考えられます。

(JPNIC 技術部木村泰司)

※1 キャリアENUM:

ISPや電話事業者が事業者内または事業者相互間の経路制御のために用いるENUMの形態。

※2 DKIM BoF(Domain Keys Identified Mail BoF):

迷惑メールなどの中でしばしば行われている発信元メールアドレスのドメイン部分を偽装する行為(スプーフィング)を、電子署名を使って検出できるようにする仕組みについてのBoFです。DKIMWGのチャーターでは、現在のスパムをなくすこと自体を目的にするのではなく、安全上の脅威(threats)や要求事項(requirements)をまとめ、またDKIMを使う場合と使わない場合の違いについて分析を行うといったアプローチを取っています。

※3 EMU BoF(EAP Method Update BoF):

PPPや802.11等で使われている認証の枠組みであるEAP(Extensible Authentication Protocol)方式のドキュメント整備に関するBoFです。EAP方式を使った認証プロトコルは数多く提案されていますが、RFCになっているものは少なくI-Dを元にした実装の相互運用性が確保されていない可能性があります。そこでEAP-TLS(RFC2716)のProposed Standard化進めると共に、パスワードなどの方式についてもドキュメント化を進めていくとされています。

※4 第63回IETFでRFCとなったドキュメント:

RFC4158 -Certification Path Building
http://www.ietf.org/rfc/rfc4158.txt
証明書のパス(CAの繋がり方)を見つけ、全ての証明書の有効性を確認するための方法や条件など。
RFC4210 -Certificate Management Protocol(CMP)
http://www.ietf.org/rfc/rfc4210.txt
CAと証明書を利用するクライアントプログラムの間などで証明書発行や失効のやり取りをするためのプロトコル。
RFC4211 -Certificate Request Message Format(CRMF)
http://www.ietf.org/rfc/rfc4211.txt
登録局(RA)から発行局としてのCAに証明書の発行要求をするための形式。

※5 RFC Editorの編集待ちのドキュメント:

RFC4158 -Certification Path Building
Operational Protocols: Certificate Store Access via HTTP
draft-ietf-pkix-certstore-http-09.txt
RFC4158 -Certification Path Building
Certificate Extensions and Attributes Supporting Authentication in Point-to-Point Protocol(PPP)and Wireless Local Area Networks(WLAN)
draft-ietf-pkix-rfc3770bis-03.txt
RFC4158 -Certification Path Building
Authority Information Access CRL Extension
draft-ietf-pkix-crlaia-03.txt

※6 RFC3280:

"Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List(CRL)Profile"
http://www.ietf.org/rfc/rfc3280.txt
インターネットで使われることを想定したX.509v3形式の電子証明書とX.509v2形式のCRLの、書式と意味をまとめたドキュメント。RFC2457の後継で、証明書に含めた文字列の国際化や解釈方式などに関する記述を改訂する予定になっています。

※7 RIS: Routing Information Service: