HOME情報セキュリティ資料・報告書・出版物インターネットセキュリティに関する RFC56th IETF ミーティング(サンフランシスコ)

本文を印刷する

情報セキュリティ

56th IETF ミーティング(サンフランシスコ)

最終更新日:2003年 9月24日

情報処理振興事業協会
セキュリティセンター
電話番号:03-5978-7501までお問い合わせください。

概要

2003年 3月17日(月曜日)から21日(金曜日)まで、米国カリフォルニア州サンフランシスコにおいて IETF ミーティングが開催された。
今回の第 56 回 IETF ミーティングへの参加者は、34カ国から 325の組織で、総勢 1,640人であった。
セキュリティエリアの各 WG 等における審議状況を報告する。:

他のエリアにおけるセキュリティ関連の要素についても報告する。:

総会についても、報告する。:

Security Tutorial

本セッションは、セキュリティのエリアディレクターであるJeffrey I. Schiller氏 (MIT)とSteve M. Bellovin 氏 (ATT ラボ)により行われた。内容はセキュリティの基礎的な紹介である。本セッションにおいては、まず現在のインターネットが抱えるセキュリティ脅威としてアタック方法(受動型:盗聴,etc、能動型:tcpnice,DoS,etc)の一般的な話があり、この脅威に対抗するのが難しいことが説明された。難しさの理由は、技術面以外にもあり、エンドユーザー側の意識と理解の問題も指摘された。セキュリティは"negative deliverable"であり、Schiller氏の母親は、「買ってきた Windows の update などまずしない」と言うと会場が笑いに包まれた。

また、実際のセキュリティ脅威事例と技術的な対抗手段として、暗号化、暗号方式(DES,AES)、暗号鍵配布方法(Kerberos, IKE,PKI)、暗号の適用範囲(通信路を守るIPsec,通信データ自身を守るS/MIME)、認証モデルなどが紹介された。Schiller氏によるとセキュリティの"Perfect World"は、「すべてのユーザ/ホストが証明書を持ち、通信路はIPsec/TLSで守られ、アプリケーションは最適なセキュリティ技術を使用し、パスワードがそのまま流れないようにする」ということであった。これに対して、現状は、IPsecの適用範囲は通信路に限られかつまだ準備段階であり、証明書は普及に困難しているとした。また、名前空間にしてもX.509,DNS,E-Mail間でばらばらで、何らかの規約が必要であること、認可(authorization)に関してもクライアント/サーバーでは単純だが、複数パーティーでの権限委譲などにおいて問題があることが指摘された。

最後に、今回新しくエリアディレクターとして紹介された Russell Housley (Vigil Security)が、セキュリティの設計面での要件として大事なことは、単純さ(simplicity)であると訴えた。複雑なセキュリティは、設計、実装、利用の各段階において困難さがつきまとうためである。「バグを作りがちなセキュリティシステムは、よりハッカーに侵入される」という指摘である。

セキュリティは、IETFにおいて昨今の一番の関心事である一方、問題としても取り上げられている。後日行われた「IESG Open Plenary」においても、プロトコル設計初期段階からセキュリティ要件を満たすべく設計を行うことをエンジニアに求めていた。ただし。実情は、厳しいようである。「Open Security Area Directorate」参照。IETF 初日において Security Tutorial が独立したセッションとして最初に行われるのは、このような背景と問題意識の表れである。

参考文献
"Designing Secure Protocols" (「セキュアプロトコルを設計する」)
http://jis.mit.edu/sectutorial/  日本語仮訳 (PDF 167KB) PDFファイル

IP Security Protocol WG(ipsec)

http://www.ietf.org/html.charters/ipsec-charter.html
チェア: Barbara Fraser <電話番号:03-5978-7501までお問い合わせください。>, Theodore Ts'o <電話番号:03-5978-7501までお問い合わせください。>
7割ぐらいの入りであった。まず、ESPv2,AH v2,RFC2401 についての状況報告があった。数ヶ月前に WG ラストコールがあったが、マルチキャストにおいて問題があった。IKEv2 のコンフィギュレーションペイロードについて説明があったが、詳細は不明である。

  • DHCP over Ipsec
  • mode CFG over IKE
  • DHCP over IKE

の選択肢の中で(3)の方法提案することが説明された。IKEv2の問題点が話された。そろそろこの問題に決着をつけることが司会から促された。議論が白熱したのは提供形式で"Suite"なのか"A la carte"なのかだったが、結論は出ない。id payload , cert payloadで紛糾した。DHCP vs. configuration payload でも紛糾した。ただし、IKEv2 は 4/15 にラストコールを行い、次回IETFミーティングまでには RFC を発行することを目標とすることがアナウンスされた。

S/MIME Mail Security WG (smime)

http://www.ietf.org/html.charters/smime-charter.html

チェア: R. Housley <電話番号:03-5978-7501までお問い合わせください。>
2,3割の聴衆。Russell Housley氏 (Vigil Security)がセキュリティエリアのエリアディレクターとなったため、WG のチェアがBlake Rambsdell氏と Sean Turner氏に変更された。
S/MIME WGは、22 の RFC を発行しており、次の文書が現在、RFC Editor の処理待ちである。

  • CMS Symmetric Key Management and Distribution (symkeydist)

次の文書が IESG のコメント待ちである旨が報告された。

  • Securing X.400 Content with S/MIME(x400wrap)
  • Transporting S/MIME Objects in X.400(x400transport)
  • Wrapping an HMAC key with a Triple-DES Key or an AES Key (hmac-key-wrap)
  • Use of the RSAES-OAEP Key Transport Algorithm in CMS (cms-rsaes-oaep)
  • Use of the AES Encryption Algorithm in CMS (aes-alg)

まず、インターネットドラフトの S/MIME v3.1 の Certificate Handling (CERT) と Message Specification (MSG) の状況報告があった。その後、CMS のインターオペラビリティテストの途中経過が報告された。どちらも特に問題は無いようであった。そして、RSA-PSS 署名対応についての報告がされた。こちらには細かな問題あるようである。そもそも RSA 暗号のバックアップなら DSA で十分なのになぜ PSS 対応を行うべきか?という質問が出たが、PKCS#1で正式にサポートされたもので対応する必要があるという回答が行われていた。

トランスポートエリアから SIP (Session Initiation Protocol) でのS/MIME利用についての説明があった。これは SIP のパケットの内容を暗号化/電子署名を行いという要望があり、フォーマットとしてS/MIME で用いているCMS (Cryptographic Message Syntax)を利用したいということである。従来、CMS は、電子メールの暗号化・デジタル署名の用途を主眼に考えられてきたが、電子メール以外で PKI を用いた暗号化/電子署名に利用する事例が増えているという事を示している。既に AAA-WGで定めたDiameterにおいても CMS の利用がオプションではあるが認められている。

日本の Kido Akira 氏 (NTT Software)から S/MIME における Camellia (128bit共通鍵暗号)対応と、NESSIE (New European Schemes for Signatures, Integrity, and Encryption)プロジェクトの紹介があった。

最後に MLA のトピックがあった。

Public-Key Infrastructure (X.509) WG (pkix)

http://www.ietf.org/html.charters/pkix-charter.html
チェア: Stephen Kent <電話番号:03-5978-7501までお問い合わせください。>, Tim Polk <電話番号:03-5978-7501までお問い合わせください。>
今回、PKIX WGは、直前4日前まで、検討課題が配信されず、開催されるか懸念されたが、5日目(3月20日)の午前中に無事開催され、76人の参加があった。

PKIX-WG の共同チェアである Tim Polk 氏より、文書の状況について説明があった。現在19本の Internet-Draft を抱えており、DPD/DPV プロトコル(RFC 3379)に選出された SCVP (Simple Certificate Validation Protocol <draft-ietf-pkix-scvp-11.txt>)および PC (Internet X.509 Public Key Infrastructure Proxy Certificate Profile <draft-ietf-pkix-proxy-04.txt>)の 2つないついて、近々に、Last Callがかかっており、RFC 化されそうであると報告された。また、pkixrep(Internet X.509 Public Key Infrastructure Repository Locator Service <draft-ietf-pkix-pkixrep-01.txt>)が Area Director に差し戻されることになった。

今回の主たる話題は、上述の DPD/DPV プロトコルの選出に関する報告と、選出された SCVP に関する現在の執筆状況の報告であった。WG セッション 2時間半のうち、30分以上をこれらに割いていた。
DPD/DPV プロトコルの選出は、今年の 1月下旬に、CVP (Certificate Validation Protocol)、DPD/DPV over OCSP、SCVP などの認証パス検証プロトコルに関するInternet-Draftに対して、PKIX メーリングリスト上で投票が行われた。この結果、SCVP は投票数の過半数を獲得したことに加え、RFC3379に最も近い仕様であり、また実装経験も十分豊富であるとの理由から選定された。

既出の Internet-Draft である PC では、新たに Proxy Certificate を考慮したパス検証アルゴリズムについて追記されており、現在 Last Call 待ちの状態にある。SIM (Internet X.509 Public Key Infrastructure Subject Identification Method<draft-ietf-pkix-sim-00.txt>)に関して、現在の執筆状況の報告があった。
SIM は、前回の Atlanta 会合において発表された Internet-Draft であり、「今までのレビュー内容を 3月末までに改訂する」とのことであった。4月 3日時点ではまだ上梓されていない。

また、今回初見の Internet-Draft である pkalgs (Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile <draft-ietf-pkix-rsa-pkalgs-00.txt>)に関しては、PKCS#1 の version1.5 で規定されている RSASSA-PSS や RSAES-OAEP などのアルゴリズムに関して、PKI の中での利用方法を示したものであり、活発な議論が交わされていた。TAP (Trusted Archive Protocol <draft-ietf-pkix-tap-00.txt>)についても発表が行われた。TAP は、TAA (Trusted Archive Authority)のトランザクションを定義し、アーカイブ情報の表記方法を示すものである。TAP については、セッション中で一度は WG ドラフトとして扱わないことになったものの、その後 PKIX のメーリングリスト上で WG ドラフトとすべきかどうかについて議論が再燃し、現在も継続中である。

これら WG で扱っている Internet-Draft に関する報告の他、リエゾンパートナーからの発表として同じく IETF の ldapbis WG から PKI に関連した問題点の報告や、EESSI (European Electronic Signature Standardization Initiative)から欧州電子署名標準化に関する活動報告が行われ、また JNSA からは、Challenge PKI 2002の活動報告およびデモンストレーションなどを稲田氏が行った。

今回の PKIX においては、JNSA も含めてリエゾンの参加が多かったことが大きな特徴である。これは PKI がインターネットにおけるインフラとして、IETF に限らず世界中の各団体や関連する技術とお互いに協調しながら展開していく大きな流れの中にあるようである。

Simple Authentication and Security Layer (SASL)

http://www.ietf.org/html.charters/sasl-charter.html
チェア: Sam Hartman <電話番号:03-5978-7501までお問い合わせください。>, Kurt Zeilenga <電話番号:03-5978-7501までお問い合わせください。>
SASL のBase Spec.を作成中であるが、著者が意欲をなくしてしまったので、新たな著者を割り当てたBase Spec.の「セキュリティについての考慮事項」が IESG のレビューに耐えられるかが疑問視されている。

Anonymous(draft-ietf-sasl-anon-00.txt)は、WGの last call 中に修正点があがりBase Spec.と共にWG MLに投稿される予定である。Sam Hartman氏がlast callでの修正点の概要を著者とレビュー後WG MLに投稿する予定である。

SASLのユーザ名/パスワードとして利用できる文字列に関してスペックを定義したSASLprep(draft-ietf-sasl-saslprep-00.txt)に問題点が提起されている。SASLprep はユーザ名として user@domain-name を扱わねばならないがドメイン名などで使われているnameprepと微妙に定義が異なりユーザ/実装者に混乱を招く点が指摘されている。

SASLprep と Kerberos で名前空間を共有できない点が指摘された。Authorization name と Authentication nameの扱いの議論が行われた。Larry Greenfield はアプリケーションは、Authorization name/Authentication name が同じであるはずと主張したが、Kurt氏は、LDAP においてはAuthorization identifiers/Authentication identifiers が違う例がある事を指摘した。そのため、SASLprep に Authorization name と Authentication name をどう扱うかに関しての考察が必要という結論となった模様である。SASL で扱う DIGEST 認証 (draft-ietf-sasl-rfc2831bis.txt)でMD5を使うことに関しての議論があった。現在、以下の 2つの問題点がある事が報告された。

(1) AES暗号への対応
AES対応をマンダトリィにするか否かの判断は、セキュリティ分析後に行うことになった。セキュリティ分析の結果はWGのMLに投稿される。

(2) SASLprepにDIGEST-MD5を入れる必要がある
SASLで扱うCRAM(Challenge-Response Authentication Mechanism)にMD5を使う件に関しては、DIGEST-MD5 同様にSASLprepにCRAM-MD5を入れる必要がある事が報告された。

GSSAPI の定義に関して、Base Spec.ドラフトの last call 後に GSSAPI のドラフトを last call する旨が報告された。
Individual submissions (SRP) に関しては、Sam Hartman 氏が OID を含んだ構造体定義をすることにより GSSAPI に基づく利用が可能となるという発言を行っていた。

Extended Incident Handling (INCH)

http://www.ietf.org/html.charters/inch-charter.html
チェア: Roman Danyliw <電話番号:03-5978-7501までお問い合わせください。>
40人ほどの出席者。Incident Handlingの重要性を説いた draft-ietf-inch-requirements-00.txt に対してWG内での合意が取られ、要求事項に関しての要求も合意に達した。この Internet-Drafts は、draft-glenn-inch-req-00.txtとdraft-ietf-inch-iodef-rfc3067bis-requirements-0.txtを統合した位置づけのものになる。Data Modelに関してのドラフトは前回のアトランタでのミーティングとウプスラで行われたIntermediateミーティングとの指摘事項を修正したバージョンのドラフトを3月中に submit の予定。今後の(攻撃的な)予定が発表された。

  • APR 03 Initial I-D of the implementation guidelines document
  • SEP 03 Submit requirements I-D to the IESG as Informational
  • SEP 03 Submit incident data language specification I-D to the IESG as Proposed Standard
  • NOV 03 Submit implementation guidelines I-D to the IESG as Informational

日本からの Glenn Mansfield Keeni 氏と Yuri Demchenko 氏の両氏より、FINE (Format for INcident data Exchange)に対する要求事項の提案の発表があった。発表に用いられたスライドは、http://www.ietf.org/proceedings/03mar/slides/inch-1/index.htmlに公開されている。

両氏の発表は、FINEのフレームワークとオペレーションモデルに対する要求事項の提案であり、SNMPのMIBに基づいている。FINE の実装である IODEF に関して同様にデータフォーマットの説明と XML のセキュリティ機構を使ってIODEFのデータの機密性/完全性を行うべきであるという趣旨の発表があった。この中でもXMLの電子署名の話題が取り上げられており(XMLの電子署名はPKIの電子署名を使う)、この影響でIODEFのデータフォーマットの一部を変更すべきという意見であった。XMLの電子署名は、RFC3275 に記述がある。

Open Security Area Directorate

http://sec.ietf.org/

セキュリティエリア全体の会合として、新しくエリアディレクターとなった Russell Housley氏(元 RSA Data Security 社、現Vigil Security) の紹介および各 WG から状況報告があった。

その後、インターネットエリアからの EAP (Extensible Authentication Protocol)のコンパウンド認証の問題が説明された。問題は、EAP がクライアント<-->認証サーバーの間でトンネリングするとき"Man-in-the-middle"アタックが発生し、認証サーバーからのトンネル鍵が盗まれる可能性があるということである。この問題を解決するための手段として、トンネルの出入り口を暗号バインドすることで盗聴を検知し、盗聴があった場合には認証サーバーからトンネル鍵を渡さなくするという方法が提案された。出席者からトンネル自体をなくし、直接やりとりを行えば?という質問があったが、市場で使われている RADIUS 認証が簡単にはなくならないだろうということから、このようなハイブリッドな認証を行う必要があることが説明された。

公開討論において、セキュリティエリアの問題点がいくつか指摘された。

「暗号や認証・認可に関する設計がなされるが、その後のアクセス制御についてはアプリケーションまかせになりがちであり、結果として問題が残るのでは?」という指摘があった。また、プロトコル設計においてセキュリティを考慮することが指示されているが、他のエリアの WG では技術的・時間的に彼らのみでは行えず、セキュリティエリアのエンジニアの援助を求めている。これに対しては、以前よりセキュリティアドバイザーを置く、個人レベルのボランティアが行われてきてはいるが、本業の WG の課題もあるなか限界があることが訴えられた。何らかのオペレーションが望まれるが、絶対的なセキュリティエンジニア不足が根底にあるため早急な解決策はなさそうであった。

また、PKI は技術的な優劣はともかくとして、PKI は敷居が高く、利用しにくいので何とかしてほしい(例えば個人で Web サーバーにサイト証明書を使うのにベリサインに年間 $300 も払うのでは利用できないなど)という要望が出された。micro-PKI, lightweight-PKI なるものがあればいい、実装上の問題として処理できるのでは?など意見が出されたが、PKIX にディレクターの Tim Polk 氏(NIST)からも明確な回答はなく、今後の課題問題として残された。

Internet Area: PANA (Protocol for carrying Authentication for Network Access)

http://www.ietf.org/html.charters/pana-charter.html
チェア: Basavaraj Patil <電話番号:03-5978-7501までお問い合わせください。>, Alper Yegin <電話番号:03-5978-7501までお問い合わせください。>
PANAの仕様が変更されたことにより議論が活発に行われた。今までの使用では、認証の初期段階において認証/認可手続きのみが可能なIPアドレスを配布し、その上で認証/認可手続きを行った後に利用制限がないIPアドレスを配布することとしていた。これは 802.1X が認証した後に IP アドレスを配布するために無線アクセスポイントなどではアクセスポイント自身が802.1X に対応する必要があるという問題回避のためとしていた。このことに対して議論が紛糾したが、すでにMLで議論されてきたことの繰り返しとなるということで、話が紛糾していた。また、コネクション切断などにより認証を再度行う場合についての説明がされたが、紛糾した。

Internet Area: Secure Neighbor Discovery (SEND)

http://www.ietf.org/html.charters/send-charter.html
チェア: Pekka Nikander <電話番号:03-5978-7501までお問い合わせください。>, James Kempf <電話番号:03-5978-7501までお問い合わせください。>
SEND-WGは、IPv6においてルータを検索するための基本となるプロトコルであるNeighbor Discoveryにおいて、偽ルータをデフォルトルータとして選択してしまうと、この偽ルータによりパケットの盗聴、利用不能に陥る可能性があり、それをどう排除するかを主眼にしたWGである。特に、IPv6ではIPsecが含まれているためIPsecでセキュリティ上安全にするためには何らかの安全なNeighbor Discoveryが必要となる。

draft-ietf-send-psreq.txt に関して、last call時にいくつかのマイナーな問題の他に 2つの大きな問題があった事が報告された。1つ目は”trust”という言葉の使い方で、この言葉が各所に別のコンテキストで使われているため混乱を招くということであった。結局、コンテキストに合わせて"delegation"、 "authorized"などの適切な言葉に変更することになった。コンテキストにあわせた適切な言葉の候補をBill Sommerfeld氏が3/28までにあげることとなった。2つ目は、SENDが採用した解決策以外の解決策をドラフト上に残すか否かであり、これはドラフト上に解決策例として残すこととなった。Cryptographically generated IPv6 addresses (CGA) において自己署名証明書をどう使うかという議論があった。このアイデア自身は、Ericsson/Microsoftの知的財産となっているがChairがMicrosoftと交渉中であると報告された。

技術的な観点から言えば、IPv6のアドレスにハッシュ値を入れる場合、62 bit までしか入れられず安全なハッシュ値とは言えない事が指摘されている。draft-aura-cga-00.txtではこの制限をなくすためsecurity parameterとsecond hashを提案している。この提案により、アドレス生成のコストはかかるが、攻撃のコストも同様に上がり安全性が保てるという事が報告された。ちなみに、アドレスの検証のコストは一定でありこの提案を入れたことによる実害はない。

draft-ietf-send-ipsec-00.txt に関しては、現在、デザインチームが考えていることのスナップショットが説明された。このドラフトは巨大なものとなる事が予想されており、いくつかのパートに分けるべきとの意見が出た。Chair の判断により CGA の部分は分けることになった。transition scheme に関していくつかの未解決部分がある事が確認された。技術的な問題は、ここ数ヶ月中にデザインチームが解決することになると報告された。

Applications Open Area: Applications Open Area

http://www.apps.ietf.org/
本セッションは、アプリケーションエリア全体での問題を話し合う目的で召集されたものである。今回は議論の大半が、IPv6 からのサイトローカルのアドレス解決の問題点が説明された。

IPv6のユニキャストには、リンクローカル、サイトローカル、グリーバルの 3レベルがあるが、サイトローカルについては定義が不明確ということであった。サイトローカルではアドレス情報がサイト境界にて失われてしまうことに伴い、end-to-end での通信で支障をきたす場合がある。IPv6 のWG内でこのサイトローカル問題を解決する議論されており、サイトローカルのアドレス解決を制限することが紹介された。ただし、この方法によるとサイトローカルアドレスを識別するためのZoneIDというものが必要になり、アプリケーションにはこの ZoneID を管理するためのUIが新たに必要になること、サイトローカルアドレスが漏れないような対策が必要なことが指摘された。

参加者であるアプリケーションエリアのエンジニアには、解決手法の有効性、弊害、別の解決方法について意見が求められたが、彼ら自身問題をよく理解できていない様子であった。ただし、UIの変更は既存アプリケーションへの影響、エンドユーザーの混乱、本来トランスポートレベルで解決すべき問題であると、否定的な意見が支配的であった。

IESG Open Plenary

http://www.ietf.org/iesg.html
IETF チェアの Harald Alvestrand 氏から、今回の参加者の報告、NOMCOM、表彰が行われた後、IETF の財政状況についての報告がされた。

「現状は赤字で、貯金で維持を行っているが、3年後には貯金も底を尽きてしまうのでどうしたらよいか?」について、意見が募集された。聴衆から、様々な意見が出た。スポンサーを探すべき、ライセンス料を取るべき、経費節減すべき、等。T シャツ販売ビジネスなどの冗談もあった。これは今回の IETF ミーティングがスポンサー無しのミーティングであるため、恒例の T シャツが配られなかったことに対しての皮肉も含まれている。IETF ミーティングの参加費用の値上げ(現在の $450から$700へ)についてアンケートが取られたが、大多数は値上げしても参加することを表明していた。

またプライバシー問題について説明があり、プロトコル設計者にプライバシー問題を考慮してほしい旨が説明された。プライバシー侵害は、セキュリティ技術面での問題がなくとも起こりうることが説明された。例えば、プロトコル上問題がなくとも、実装上ローカルに保存されたプライバシーデータなどから漏れる可能性がある。また、ユーザ自身が保存するデータの保護についてはユーザ任せで保護が不足しがちになることが指摘された。プロトコル設計者には、プライバシー問題が発生しないよう、設計段階の初期からプライバシー保護を念頭におくことが望まれた。

最後に、IETF 自身の問題が討議された。組織は大きくなっているが、WG メンバーの質が低下していることを指摘する声が多く寄せられた。例えば、WGミーティング参加者の中で提案文書を読んでいる人がほとんどいない、等。また、この問題に関連し、発行される RFC 自体の品質も悪くなっており、品質管理をどのように行うのか?また成功事例の共有などがうまく行えていないこと、等が問題として挙げられた。

Open IAB Plenary (オープン IAB 総会)

http://www.iab.org/iab/
IIJ 技術研究所の萩野純一郎氏が IAB メンバーに就任した。日本人として、慶應義塾大学の村井純教授に続いて 2人目である。萩野氏の、IPv6 の設計・開発における功績が認められたと考えられるとともに、IETF が今後も IPv6 の開発とインターネットへの配備を進めていくことを示していると考えられる。

謝辞

本報告においては、富士ゼロックス株式会社の稲田龍氏、セコムトラストネット株式会社の島岡政基氏、NPO 日本ネットワークセキュリティ協会の安田直義氏、富士ゼロックス情報システム株式会社の増田健作氏らの協力を得た。彼らの協力に感謝する。