ニュースレターNo.30/2005年7月発行

第62回IETF

2005年3月6日(日)～3月11日(金)に米国ミネアポリスにて第62回IETF会議が開催されました。全体会議、IPv6、DNS、セキュリティ関連ワーキンググループ(以下WG)のレポートをお届けします。

1. 全体会議報告

2005年3月6日～11日まで、米国ミネアポリスのヒルトンホテルにて第62回IETF^※1が開催されました。ミーティング期間中は最高気温氷点下の日が続き、また会議期間の後半では吹雪になるなど、極寒のIETFとなりました。

このところIETFへの参加人数は減少傾向ですが、今回は1,167名(IESG^※2Plenaryにおける発表)と、前回(第61回ワシントンDC:1,311名)、前々回(第60回サンディエゴ:1,469名)に比べ、今回は更に減少してしまいました。しかしながら国別でみると前回の26国から28国に増えており、また、依然として多くの企業からの参加があることから、標準化ミーティングとしての重要性には変わりありません。なお、国別の参加人数比にはこのところそれほど変動はなく、今回は米国、日本、韓国、ドイツ、といった順番になっています。

今回のIETFでは、約110のワーキンググループ(WG)ミーティング、及びBoFが実施されました。また前回は全体会議が水曜日夜の一コマのみでしたが、今回は通例通り、水曜日の夕刻、木曜日夕刻と2コマ開催されています。

◆ IESG Plenary

IESG Plenaryミーティングは3月9日(水)に行われ、IETF参加状況報告、ネットワーク環境報告、RFCエディタやIANA^※3からの報告等が実施されました。

今回はミーティングにスポンサーがつかなかったため、ボランティアベースでネットワークの設営、運用が実施されたとのことでしたが、そのためか無線LANの基地局が落ちたり、対外通信ができなくなったりと、ネットワークのクオリティに少々難がありました(全体会議中にも通信ができなくなったことが数回ありました)。無線ネットワークに関しては、IETFでは暗号化なしのネットワークのみが提供されることが多いのですが、今回はそれに加え、固定WEP暗号通信、所謂Dynamic WEP通信の3種がサポートされていました(もっともそれに気がついていないユーザーも多かったようです)。

前回サンディエゴのミーティングからは、4つのWGが設立され、11のWGが閉鎖されています。また、約55のRFCが発行された、との報告がありました。

また、IETFの議長がHarald Alvestrand氏からBrian Carpenter氏に代わったことの紹介がありました。Harald Alvestrand氏は、2001年よりIETFの議長を務め、その間IETFの組織変更等、重大な役目を果たされました。

次回のIETFは、2005年7月31日～8月5日、フランスのパリにてフランステレコムのスポンサーのもと開催されます。

◆ IAB^※4 Plenary

IAB Plenaryは3月10日(木)に行われ、IAB議長からの報告、IRTF^※5よりHIPRG(Host Identity Protocol Research Group) からのプレゼンテーション、技術トピックとしてボーイング社のモビリティシステムの紹介がありました。

IAB議長からは、最近のIABでの話題として、DNSでの「名前」と「サービス」についての関連や、DNSを拡張する際の方式、NAT越え機構の選択などがあがっていることの報告や、IRTF、ISOC^※6、IAOC^※7に関連した活動の報告がありました。

HIPRGの報告では、現在検討を進めているHIPプロトコルについての紹介がありました。HIPは、TCP/IPスタックのネットワーク層において、現在一つとして扱われている識別子情報(Identifier)と場所情報(Locator)を分離することで、通信IP層のプロトコル独立性の確保、マルチホームや移動ノードへの対応を実現しよう、というものです。現在、テスト実装が公開されており、既存の実装やインフラストラクチャへの影響、HIPの概念そのものの検討、DDos対応、移動ネットワーク対応などの新機能の検討が進んでいるとのことです。

ボーイング社からは、現在ボーイング社が提供している航空機内インターネットについての技術解説のプレゼンテーションが実施されました。現在、航空機内でインターネットサービスを提供するために、物理層としては衛星通信を、IPの移動性を実現するためにはBGPを利用しているとのことで、航空機のような移動距離が多大になる場面ではホームネットワークとの距離のためにモバイルIP関連技術の適用が難しいこと、BGPによる移動性の実現を選んだ理由などの紹介がありました。移動時間の長い長距離路線でインターネットアクセスができることは非常に便利だと思いますが、その反面、どこにいても仕事が降ってくるようになるのはつらそうです。

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

2. IPv6関連WG報告

◆IPv6(IP version 6)WG

IPv6 WGは3月8日(火)の午後、一コマ実施されました。今回はアジェンダ数も少なく、また、従来に比べて参加者も非常に少ない印象がありました。

話し合われた主なトピックスは、・ユニークローカルIPv6ユニキャストアドレス(Unique Local Address(ULA))」について
・RFC3513(IPv6アドレス構造)、RFC2461(IPv6の近隣探索)、RFC2463(ICMPv6)の改版
・IAB IPv6アドホック委員会の紹介
・URIでのIPv6スコープの記述について
などです。

IPv6 WGで扱っている、ドキュメントの現状については、
http://www.innovationslab.net/˜brian/IETF62/IPv6/IPv6DocumentStatus.html
にまとまっています。

ULAは、廃止が決まったIPv6サイトローカルアドレスの代替となるアドレスで、その重要性からも標準化が急がれています。今回は、IESGからのDNS逆引きについての意見に対する議論がありました。IPv4のプライベートアドレスと同様、ULAは広域インターネットでの利用は許されていませんが、このアドレスに対するDNSのアドレス逆引き要求が広域インターネットに流出した場合の影響についての議論です。この問題は、主にオペレーションに関するものですが、ULAの仕様文書に、問題の指摘、及び推奨対処方法を記述することになりました。

IAB IPv6アドホック委員会は、IPv6におけるアドレス割り振り手法や、逆引きDNS移行(ip6.int廃止)などを検討し、IANA等に情報提供を実施する委員会です。この委員会は、最近増えてきたRIRからIANAへの大規模IPv6アドレス割り振り要求に対して、割り振り可否の判断のための意見が欲しいというIANAの要請によって組織されました。今後、長期的な観点からのIPv6アドレス利用について、RIRへのIPv6アドレス委譲サイズ、ISPへのIPv6アドレス割り振りサイズに関する提言を実施していく予定となっています。

URIでのIPv6スコープ記述についての議論では、URIにおいて、スコープ付きIPv6アドレスを記述する際の、スコープの記法についての問題提起です。現在はアドレス記述に、
［v6.fe80::cafe:f00d%de0］
のように'%'を利用してスコープを記述しますが、URI記法では%が別な意味を持っているため、これをどうするか、というものです。別な記号を使う、URI仕様に従った表記を使う、等が提案されましたが、メーリングリストにて継続議論となっています。

IPv6 WG: http://www.ietf.org/html.charters/ipv6-charter.html; http://playground.sun.com/pub/ipng/html/ipng-main.html
第62回 IETF IPv6 WG のアジェンダ: http://www.ietf.org/ietf/05mar/ipv6.txt

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

◆v6ops(IPv6 Operations)WG

IPv6の普及促進やIPv6ネットワークの運用技術を議論するv6ops WGは3月9日(水)に2時間30分の一コマが設けられました。前回(第61回)のワシントンDCでの会合はv6ops WGの議論の進め方について大きな転機でしたが、第62回の会合までにtc(tunnel configuration)BoFが立ち上げられ、トンネル(特にIPv4ネットワーク上でIPv6を透過させるトンネル)を使った移行技術は議論の場がv6opsWGからtc BoFへ移されました。tc BoFの初会合も今回のIETFミーティングで開催されました。その内容は別途報告します。これまでトンネル構成方法に多くの時間を費やしていたためすべての議題を消化し切れなかったり、議論の時間が十分に取れないことがしばしばありました。しかし今回の会合からは、移行に関する検討やセキュリティに関する考察など、本来v6ops WGが主要な課題として扱うべき内容に十分な時間が割かれていました。

まずRFC2766(NAT-PT)をExperimental(実験的プロトコル)と位置づけ利用しない方向となったこと、及びトンネル設定に関する議論が対象外となったことを受け、チャータの見直しが行われました。実際にノウハウとして世の中で利用されることを意識し、タイムスケールやオペレーターの実経験の重視が提唱されています。

目立ったセキュリティに関する議論として、NATを使ったIPv4環境において担保されているセキュリティと、IPv6で実現されるセキュリティの比較を行い、そのギャップを考察する発表がありました。IPv6のセキュリティはIPv4のそれに比べて劣るものではありませんが、NATの有無やアドレッシング、運用形態などから差異が生じる部分もあるため分析が行われていました。IPv6への移行を達成する上でIPv4と同等かそれ以上のセキュリティを確保することは必要であり、チェアを含めて高い関心が示されていました。現在、この内容はWGの課題として扱われることが決まっています。

また第61回の会合に引き続き、WIDEプロジェクトによるIPv6Fixの活動内容が報告されました。すでにIPv6が普及を始めていますが、いくつかの不具合が報告されています。IPv6Fixは普及の阻害とならないようにこれらの問題対処する活動です。今回の発表ではonlink assumptionと呼ばれるIPv6の仕様に基づく不具合や、JPRSと共同で行った不適切な挙動を示すDNSの調査結果などが報告されていました。実践的な手法や調査結果に対して会場から高い関心が示されていました。

v6ops WG: http://www.ietf.org/html.charters/v6ops-charter.html
第62回 IETF v6ops WG のアジェンダ: http://www.ietf.org/ietf/05mar/v6ops.txt

◆tc(tunnel configuration)BoF

tc(tunnel configuration)BoFでは、IPv4インターネット上でIPv6を透過させるためのトンネルを自動設定する方式が議論されました。長らくv6ops WGにおいて扱われていたテーマでしたが、毎回議論が集中し多くの時間が割かれていたため、v6ops WGから議論を分離することになりました。今回のtc BoFはそのキックオフにあたる会合です。

IPv6 over IPv4トンネルにより接続性を提供するにあたり、想定されている利用環境は、ISPはコアネットワークがIPv6に対応したものの、カスタマエッジなどアクセスネットワークの近傍がIPv6に未対応であり、顧客に対してIPv4の接続性のみを提供している状況が仮定されています。また顧客はdual stackの端末を持ち直接接続されているケースと、NAT対応のブロードバンドルータの配下に接続されているケースが想定されています。日本国内でもIPv6ネイティブ接続サービスが提供されていないISPとその顧客の環境に合致する点も多いです。

今回のtc BoFで議論されたプロトコルや方式は、端末やブロードバンドルータが、トンネルの終端となるホストを発見するエンドポイント発見方法と、そのエンドポイントとトンネルリンクを自動設定するプロトコルです。前者のエンドポイント発見のために、well-known IPv4 unicast addressを用いる方法やDNSに新しいリソースレコード(TEP RR)を設ける方法などが提案されました。

またトンネルの自動設定プロトコルについては、v6ops WGにて議論されている当時からさまざまな手法が提案されています。今回のtc BoFでは下記の提案方式が列挙されていました。

・ISATAP(Intra-Site Automatic Tunnel Addressing Protocol)
・STEP(Simple IPv6-in-IPv4 Tunnel Establishment Procedure)
・AYIYA(Anything In Anything)
・TSP(IPv6 Tunnel Broker with the Tunnel Setup Protocol)
・L2TP(Layer2 Tunneling Protocol)

それぞれのプロトコルの概要説明と比較が行われ、リンク確立のネゴシエーションや認証に必要なトラフィックのオーバーヘッド、またカプセル化のオーバーヘッドなどの検討を行っていました。上記のようにたくさんの方式が並立しており、今回のBoFでも議論は収束していません。すでにFreenet6^※8で利用されているTSP(Tunnel Setup Protocol)は比較的支持を集めていましたが、標準として採用するほど明確なコンセンサスが得られておらず、プロトコルの策定にはしばらく議論が続くものと思われます。

ただし会場に集まった聴衆の関心は高く、WGとなるコンセンサスは取れていたようです。WG化された場合はOPS(Operations & Management)エリアではなくINT(Internet)エリアに属することになります。

第62回 IETF tc BoF のアジェンダ: http://www.ietf.org/ietf/05mar/tc.txt

◆Multi6(Site Multihoming in IPv6)WG/
　Shim6(Site Multihoming by IPv6 InterMediation)BoF

3月8日(火)の午後のセッションにてIPv6上のマルチホーム方式を検討するMulti6 WGの会合が開かれました。Multi6として開催されるセッションは今回が最後となりクロージングを迎えます。以降は、新規に発足するShim6に検討の場が移されます。これまでMulti6ではOPS(Operations & Management)エリアのWGでした。しかしMulti6 WGでは前回の会合の段階で、マルチホーム手法の基本的な設計が終了したことと、実際にマルチホームに必要なプロトコルを策定するため、INT(Internet)エリアへ議論の場を移すことになりました。Shim6 BoFについて詳しくは後述しますが、Shim6のチェアはMulti6のチェアがそのまま留任となっています。最後の会合での議題ですが、目新しい提案はなくこれまで提案されていたドラフトのアップデートがあっただけです。failure-detection(通信パスの切断の検知方法)、hash-based address(アドレスの安全な交換方法)、Multi6方式によるマルチホームでの機能項目の分析など、後継のShim6で要素技術となる方式について議論されました。議事は淡々と進み、クロージングを迎えました。Multi6での議論の成果はShim6のインプットとして引き継がれます。

一方、Shim6はIETF会期最終日3月11日の午前のセッションにてキックオフBoFが開催されました。取り扱う内容はMulti6で検討されていたマルチホーム解法を引き継ぎ、エリアを変更してMulti6で扱う範囲を少ししぼったものとなっています。当日の議論ですが、まずShimアーキテクチャのおさらいが提示されました。ここで改めてその内容を復習すると、Shimアーキテクチャでは、レイヤ3(IPv6層)とレイヤ4(トランスポート層)の間にShim層と呼ばれるレイヤを新たに導入します。またホストを特定する指示子としてULID (upper-layeridentifier)なる概念を導入してレイヤ4以上からはこのIDを用いてホストを特定します。Shim層がULIDとレイヤ3のIPv6アドレス(Shimアーキテクチャではロケータと呼ばれる)をマッピングする役目を担います。ULID はレイヤ4以上から参照されると述べましたが、IPsecが機能するような考慮も取り込まれています。

当日の議論の様子に戻りますが、概念的なアーキテクチャの提示はあったものの切断検知や上位層との連携など具体的な要素技術やプロトコルはまだ具体化していません。参加者の中にはresearch groupでの研究が必要な段階ではないか？と意見もありました。またモビリティに関する機能を議論の対象として取り込むべきか否か意見があり議論が巻き起こりましたが、時間内に収束しませんでした。まだMulti6で積み残した課題が多数あり、標準の策定には長期化が予想されます。

しかしながら、議論を継続させることについては会場から賛同が多数得られており、WGの設立のコンセンサスは取れていると思われます。

第62回 IETF Multi6 WG のアジェンダ: http://www.ietf.org/ietf/05mar/multi6.txt
第62回 IETF Shim6 BoF のアジェンダ: http://tools.ietf.org/agenda/62/shim6.html

Shimアーキテクチャ
"Architectural Commentary on Site Multi-homing using Level 3 Shim"
http://www.ietf.org/internet-drafts/draft-huston-l3shim-arch-00.txt

(NTT情報流通プラットフォーム研究所加藤淳也)

3. DNS関連WG報告

◆dnsop(Domain Name System Operations)WG

IETF62では、dnsop WGのBoFが1コマ開催されました。今回のBoFでは、メインとなる議題は特に存在せず、多くのWGドラフトやdnsop WGに関連する個人ドラフトについての進捗報告と質疑応答が行われました。

毎回中心的な話題となっているDNSSEC^※9に関しては、今回はデプロイメントに残された課題に関する報告のみ行われました。鍵更新の手順や、秘密鍵と署名鍵の有効期限をどの程度に設定すればうまく運用できるか、といった点がまだ不確定であるという報告がなされました。また、最後にDNSSECのデプロイメントに関して集中的に議論を行っている、http://www.dnssec-deployment.org/というプロジェクトも紹介されました。DNSSECのデプロイメントに関する深い議論は、このプロジェクトにて行われているようです。他には、DNSにてグローバルに公開するゾーンには登録すべきではない情報を提案したドラフトである、draft-durand-dnsop-dont-publish-00の発表がありました。例としては、IPv6のサイトローカルアドレスやユニークローカルなIPv6ユニキャストアドレスといったものはグローバルゾーンに登録すべきではない、といった提案がなされていました。このドラフトに関しては、会場の賛同が得られ、WGドラフトとなることが決定しました。

dnsop WG: http://www.ietf.org/html.charters/dnsop-charter.html
第62回 IETF dnsop WG のアジェンダ: http://www.ietf.org/ietf/05mar/dnsop.txt

◆dnsext(DNS Extensions)WG

dnsext WGのBoFでは、DNSSECに関連したプロトコルの議論が活発に行われました。まず、ワイルドカードレコードがゾーン内にある場合のDNSSECによる署名方法に関して述べたdraft-ietf-dnsext-wcard-clarify-05に関して議論がなされました。また、ワイルドカードレコードというものの定義から始まり、DNSSECにて署名された場合に、それは有効署名を持ったレコードとして扱われるかどうかという議論もなされました。さらに、ワイルドカードレコードに対してDNSSECの署名検証を求められた場合、NXDOMAINを返答するのか、もしくはエラーは返さないのか、といった議論が行われました。結論はまだ出ず、引き続き議論が行われていくことになりました。また、IETFの直前にSHA-1暗号アルゴリズムの衝突をねらった攻撃に関する発表があったため、この攻撃によってDNSSECが受ける影響に関する報告がありました。結論としてはほとんど影響はない、ということでした。さらに、DNSSEC にて利用されるNSECというレコードの弱点を改善すべく、NSEC3やNSECεという新たなレコードの仕様に関する議論も行われました。総じて、dnsext WGは前回と同様、DNSSECに関する議論に終始していました。

dnsext WG: http://www.ietf.org/html.charters/dnsext-charter.html
第62回 IETF dnsext WG のアジェンダ: http://www.ietf.org/ietf/05mar/dnsext.txt

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

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

今回のIETFでは、定例となっていた日曜日のSecurity Tutorialは行われず、代わりにRouting, Bridging and Switching: A Tutorialが開催されました。IETFのスタンスとして、セキュリティを軽視することはありませんが、すでに何回もSecurityが行われており、一応のレベルまで意識が高まったという判断ではないかと思われます。

◆pki4ipsec(Profiling Use of PKI in IPSEC)WG

pki4ipsecは、IPsecにおけるPKIのプロファイルを作成することを目的としたWGです。3月7日の15：30～17：30に行われ、約30人の参加者がありました。

Sean Turner氏より、Chris Bonatti氏との中間ミーティングの結果を含めた報告が行われました。この中で、認証トークンとしてUTF8による国際化を行うことが合意されことが報告されました。また、認証パス構築については、AIA拡張やCRLDP拡張などを使う方法が検討されているとの報告がありました。また、Jim Schaad氏より、「CMC(Certificate Management Messages over CMS)usingCMS(Cryptographic Message Syntax)」(CMSを利用する証明書管理プロトコル)について説明がありました。また、認証プロセスにおけるリクエスト/レスポンスの内容や、証明書の更新の概念についてUpdate/Renewal/Rekeyの違いについても説明をしました。これらはEnrollment TYPEとして定義されており、議論の結果、TYPEフィールドで用いるものではない(TYPEの値はenrollment/renewalだけ)という結論に達しました。また、PKIの鍵生成機能について要件から削除すべきかどうかについては結論が出ず、メーリングリストで引き続き議論することになりました。

◆PKIX(Public-Key Infrastructure)WG

PKIX WGは、インターネットにおけるPKI(X. 509)を利用するためのプロファイルを定めることを目的としたWGです。3月8日の13：00～15：00に行われPKIX-WGは、45名ほどの参加者がいました。

▼PKIX-WGとしての発表

Document StatusがChairであるNational Institute of Standards andTechnology(NIST)のTim Polk氏より発表されました。Polk 氏によると5つドキュメントがRFC Editorの元にあり、IESGにより一つのドキュメントが承認されました。他にもいくつかのドキュメントがIESGの承認待ちです。
NISTのDavid Cooper氏よりSCVPの状況の説明がありました。SCVP(SimpleCertificate Validation Protocol)のInternet-Draft(以下、I-D)は現在、第18版であり前回のミーティングからラフコンセンサスを得るために大幅に進歩しました。デフォルト検証ポリシーの部分で仕様上の不整合がありメーリングリスト上で議論が必要とのことです。
NISTのDavid Cooper氏よりRFC 3280の後継であるRFC 3280 bisの状況の説明がありました。RFC 3280bisは、第0版が予定より遅れ2月に発行されました(当初は昨年の12月に発行の予定)。3280bisは、ISOの標準の明確化と若干の修正が含まれており、証明書のSubject/ Issuer等の名前に関する国際化文字列の比較に関しての新しい章です。アプリケーションは、国際化文字列に関してどのように扱うかに関して質問が出ました。3280bisでは、パス構築/パス検証時に国際化文字列の比較のルールに従うことが必要であるとの回答を得ました。それ以外の状況に関しては未定義であり今後の議論により状況が変わる可能性があります。
セコムIS研究所/NPO日本ネットワークセキュリティ協会(JNSA)の金岡明氏がIPA/JNSAのUTF8調査の一環として、東アジアにおける証明書のUTF8化の現状に関する発表を行いました。この発表は、独立行政法人情報処理推進機構(IPA)/JNSAがアジアPKIフォーラムを通じて行ったものであり、アジアPKIフォーラムに加入している各国の証明書のUTF8への対応状況とWindows XPの証明書リポジトリィに格納されている認証局の証明書のUTF8への対応状況を調査し報告がありました。アンケートは9カ国に送られ、3カ国(台湾、韓国および日本)、9認証局より回答がありました。いずれも政府系の認証局であり、民間CAよりの回答はありませんでした。各認証局のUTF8の対応状況はいずれもUTF8を利用し、ローカルキャラクタを表現できるようにしていますが、移行プランを用意しているものは1局に過ぎませんでした。また、Windows XPの証明書リポジトリィにある認証局は、RFC 3280で定められたUTF8Stringへの移行の期限前に発行した証明書を利用しており、いずれもUTF8Stringでのエンコードをしていないことがわかりました。結論として、政府系の認証局はUTF8Stringの利用に対してのモチベーションはあるが、民間系の認証局は移行プランがないとUTF8Stringへの移行を行うリスクを許容できないこととなるようです。UTF8 Stringでのエンコードした証明書への移行に関しての移行戦略、移行プランおよびテストケースなどを明確にしたInformational RFCが必要であるとの報告がありました。
Microsoft社のStefan Santesson氏より"CRL Signer Certificates and AIA" の説明がありました。第0版が前回のIETF後発行され、このドラフトに関しての議論がメーリングリスト上で行われ、5つの大きな問題があることがわかりました。各々の問題が適切に解決されたら新しいドラフトに反映されます。推奨されるリフェラル方式の選択方式が未解決となっています。
Soaring Hawk社のJim Schaad氏よりCRMF(Certificate Management Request Format)/CMCのアップデートが報告されました。CRMFは、RFC Editorに送られましたが、OID(Object Identifier)が2つ修正が必要となる模様。トランスポートとしてCMCベースのものを使うドキュメントは準備ができており、CMCのcomplianceドキュメントももうすぐできる見通しです。CMCのアーカイブに関してのドキュメントは解決すべき問題(鍵の預託者より複数の鍵を取得する処理)を一つ抱えていますが、このドキュメントもすぐにWG last callできる状態です。
Related Specifications & Liaison Presentations Open LDAPプロジェクトより"LDAP schema definitions"に関してKurt Zeilenga氏よりプレゼンテーションがありました。このI-Dは、個人のI-Dとして出されたものであり、PKIX-WGに対してコメントとレビュー依頼があったものです。このドキュメントは、LDAPBIS WGで行われているLDAP TSと同時に出される予定です。
Tumbleweed社のJohn Hine氏より"OCSP Data Interchange Format"の発表がありました。このプレゼンテーションは、OCSPサーバ間で情報を交換するためのフォーマットを提案したもので個人的なI-Dとして発行されました。このドラフトを書いたことで明確になった問題点に関してPKIX-WGと共同で行いたいということでした。

◆EAP (Extensible Authentication Protocol)WG

参加者は80名くらいで100席ほどの部屋はほぼ満員であり、数名が後ろで立ってる状態で盛況でした。

EAP Key Management Framework(draft-ietf-EAP-keying-05.txt)の説明がありいくつかの課題に対して議論されました。次に、EAP Pre-Shared Keyの説明があり、Light Weight MethodとPowerful Methodがあり、Light Weight Methodは、単一の共通鍵アルゴリズムを使う方式で、Powerful MethodはShared Secret、Secure Password Based、PKIを利用してIKEv2をベースにデザインされ、ciphersuite negotiation、variate key strength、first reconnect、active user identity confidentialの実現を目指しているようです。

◆SAAG (Security Area Advisory Group)

3月10日15:30～17:45に開催されました。Security Area Advisory Groupは、Open Security Area DirectorateとされSecurity Areaの総括と全体を見通した議論が行われ、Security Areaの各WGやBoFの進捗報告の他、トピック的に勉強会が開催されるので、Security Areaについて広く情報を得たい場合には有意義な場です。今回の勉強会は以下のトピックについて取り上げられました。

セキュリティプロトコルの評価手法の調査(AVISPA)
OATHによるOTP認証
MD5とSHA-1の現状(Eric Rescorla)

・EUによるAVISPA(Automated Validation of Internet Security Protocols and Applications)プロジェクトからは、セキュリティプロトコルの評価手法についての分析成果報告が行われました。この評価手法は実装に基づくものではなく、仕様(Protocol description)を分析しプロトコルの脆弱性評価を行います。IETFで標準化したプロトコル33を評価したところ112の脆弱性が発見されたという報告がありました。

・OATH(OpenAuTHenticatoin.org)からOTP(One Time Password)認証の新たな提案が行われました。OTPそのものの優位性について説明されたため、発表後、S/Key(RFC 2289)との違いについて質問が投げかけられました。これに対してOATHの方式ではハードウェアトークンを必要としないという回答がなされました。S/Keyもハードウェアトークンを用いていないはずであり、誤解があるものと思われます。

・IAB(Internet Architecture Board)メンバーのEric Rescorla氏が、MD5やSHA-1などのハッシュ関数の現状について報告を行いました。この話題は、2005年2月にSan Franciscoで開催されたRSA Conference 2005でSHA-1の脆弱性が報告されて以来、SAAGのメーリングリスト上で議論されてきた内容をまとめたものであり、ミーティング後もメーリングリストで議論が続いています。

主に報告されている点は以下のとおりです。

2の80乗の強度を持つSHA-1の強度が2の69乗へ低下していること
しかしながらハッシュから原文を計算することはまだ不可能であること
変更可能なビットの位置は限定されていること
PRF、SSL/IPsec/SSH、HMACなど認証系のプロトコルにはあまり影響がないこと
証明書発行、タイムスタンプなどには影響があるかもしれないこと
証明書では、いくつかフィールドを工夫すれば衝突攻撃を妨害できる方法があること

また、今後の対応についても以下のような考察が述べられています。

SHA-224など現行のものよりビット数を多くした新しいハッシュ関数が必要となるだろう
アルゴリズム識別子パラメータに乱数を与えられるハッシュアルゴリズムが必要
対症療法として、証明書はserialNumberフィールドにランダムな値を入れることが必要となる

これに対して、serialNumber以外にもvalidityやsubjectDNのいくつかのフィールドを使ってランダムな値を埋め込むことは可能だろう、NISTは2010年までに80bit以上の強度を持つアルゴリズムへ移行することを望んでいる、などのコメントがつけられました。

(JPNIC CAとアプリケーション専門家チームメンバー／富士ゼロックス株式会社　稲田龍)

※1　IETF：Internet Engineering Task Force: インターネット技術の標準化を推進する任意団体。設立当初は非公式に存在していたが、1986年にIABによって正式に設置された。IETFにおける技術仕様は、RFC(Request For Comments)という名前で文書化、保存され、広くインターネットを通じて参照することができるようになっている。
※2　IESG：Internet Engineering Steering Group: IETFの活動と標準化プロセスの、技術的な側面についての責任を担っているグループ。IESGのメンバーは、IETFの複数のWorking Groupで文書のレビューを行ったり、WGの方向性について助言を行っているArea Directorで構成されている。
※3　IANA：Internet Assigned Numbers Authority: カリフォルニア大学情報科学研究所(ISI)のJon Postel教授が中心となって始めたプロジェクトグループで、ドメイン名、IPアドレス、プロトコル番号など、インターネット資源のグローバルな管理を行っていた。2000年2月に、ICANN、南カリフォルニア大学、及びアメリカ政府の三者の合意により、IANAが行っていた各種資源のグローバルな管理の役割はICANNに引き継がれることになり、現在、IANAはICANNにおける資源管理、調整機能の名称として使われている。
※4　IAB：Internet Architecture Board: インターネットの技術コミュニティ全体の方向性やインターネット全体のアーキテクチャについての議論を行う技術者の集団。ISOCの技術理事会(Technical Advisory Group)としても機能し、インターネットを支える多くの重要な活動を監督している。
※5　IRTF：Internet Research Task Force: インターネットに関する将来の革新的な技術に関する検討を行うグループ。技術を長期的な観点から考え、小人数による議論を行う。通常、IRTFでの議論・検討の結果、IETFでの検討や標準化が必要と認識されると、 IETFに提案され、標準化に向けた議論検討が開始される。
※6　ISOC：Internet Society: 非営利の国際組織で、インターネット技術およびシステムに関する標準化、教育、ポリシーに関する課題や問題を解決あるいは議論することを目的としている。
※7　IAOC：IETF Administrative Oversight Committee: IETFの運営をサポートするIAD(Internet Administrative Director)の活動に対し指揮・監督・承認を行い、IETFの運営のサポート機能(IASA:The IETFAdministrative Support Activity)を監視する組織。具体的には、IADの活動計画や契約、予算の提案について、IETFの運営上の要望に沿っているかといった確認を行う。
※8　Freenet6：Hexago社が提供するIPv6アドレスへの接続性実証サービス: http://www.freenet6.net/
※9　DNSSEC：: DNSに関するセキュリティの強化を行うための拡張機能。DNSで提供する情報に電子署名を付加し、DNSを使って得られた情報と発信元にある情報との同一性を保証する。