最終更新日:2005年 5月 6日
独立行政法人 情報処理推進機構
セキュリティセンター
情報セキュリティ技術ラボラトリー
(準備中)
2005年 3月 6日(日曜日)から13日(金曜日)まで、米国のミネアポリスにおいて IETF ミーティングが開催された。総参加者数は、1,167名であったので、前回と比較して減少している。地元米国からの参加者が、過半数を占めた。(内訳: USA(53%)、日本(10%)、 大韓民国(5%)、ドイツ、フランス…。)
主にセキュリティエリアの各セッションに参加したので、ここに報告する。
今回、開催されたセキュリティエリアの
WG の一覧は、下記のとおり(時系列)。
セキュリティエリア以外にも、下記のセキュリティ関連のセッションが開催された。
移動体通信におけるセキュリティプロトコル設計案件のひとつ。 IPsec との組み合わせを想定して、現行の鍵交換プロトコル仕様である IKEv2 を拡張する。ホスト (multihoming, SCTP) あたり複数の IP アドレスがある場合、もしくは、 IP アドレスがその IPsec ホストのコントロールにおいて変化する場合 (mobility や roaming) に利用できるようにするために要求される IKEv2 プロトコルについての拡張に注力する。
今回の会合においては、プロトコル設計についての02版のインターネットドラフトに基づいて検討した。 用語法や例示のようなエディトリアルな事項が相当にあるが、内容(技術)面で、まだ、オープンな論点が残っている。基本アプローチとして、 "Initiator decides" アプローチ(始めた側が決めるアプローチ)を採用することをようやくコンセンサスとしつつある。このほか、プロトコル自身が行うテスト仕様についても、接続前テストを仕様化する方向になった。 しかし、NATと呼ばれるアドレス変換技術との共存に関して求められる事項については、様々な対応すべき局面についてのシナリオが考えられるわけであるが、「どこまでサポートするか?」議論が尽くされていない。引き続き、メーリングリスト上で、意見交換を通じてコンセンサスの形成が模索される。
Samuel Weiler
現行の IPsec プロトコルは、「 all-or-nothing 」のような選択になっている。既存のプロトコルは、可能性ある広範な脅威からの防護を提供するが、しばしば、配備されていない。その理由には、鍵管理インフラの必要性、設定の煩雑さ、性能への影響等がある。 そこで、この提案されている WG は、既存の IPsec プロトコルに対して、事前の鍵共有や、鍵管理インフラストラクチャの必要性を低減して、性能を向上する、要件を緩和された拡張の仕様を策定する。これらの緩和された流派は、現行 IPsec 仕様と比べて、より弱いセキュリティ粒度しか提供しないが、限られた環境における利用のためには、十分であるはずであるとする案件。 BCP (ベスト・カレント・プラクティス:要件、フレームワーク、設定)として、あるいは、スタンダードトラック文書(プロトコル仕様)として、標準化活動をしたい、という。
今回の会合においては、WG 憲章として書く目標・作業項目をレビューし、その結果、概ね作業項目が定まった。
IPsec は、過去 5 年間以上にわたって標準化が行われてきた。同じ期間、 X.509 証明書の利用についても定められてきた。しかし、証明書を利用する IPsec の採用事例は少ない。その理由のひとつは、 X.509 証明書の IPsec における利用についての明快な文書の欠如である。 また、 IPsecシステムについて、証明書の入手等、証明書に関するライフサイクル運用について単純明確に規定された方法論の欠如も理由である。
今回の会合においては、開催されたインターリム会合について報告がなされたほか、ここでも国際化文字コード問題について意見が交わされた。また、CMC プロトコルとの関係について、その仕様の著者から説明され、関連づけが検討された。
(準備中)
Steve Kent と Tim Polk
このWGについては、現存する案件を処理した後に終息させることが決定している。ただし、現存する案件と密接に絡む案件が提起された場合、扱う可能性があるとされている。
PKI 技術についての基本的な技術仕様を策定してきたこの WG については、改訂中の基本仕様を発行後に終息させることが決定している。その改訂内容には、我々が関心を持つ国際化対応文字コードの扱い方が含まれている。
今回の会合においては、我々は、今年度実施してきたサーベイに基づいて発表してきた。X.509 デジタル証明書上に記載される DN という項目は、誰に発行されたかを記すものであるが、人間が読むためだけの項目ではなく、システムが信用の連鎖を自動処理する際に用いられる項目である。それについての統一的な比較検証法についての技術仕様の確定が求められているところである。今回、我々は、この部分に貢献できたものと自負している。ただし、課題は残る。移行法についての国際的なガイドラインは存在してない。今般の我々の調査の中で考案したものを、再びこの IETF の場で標準化していくことが可能であると考えている。
SASL は、数多くのアプリケーション・プロトコル( BEEP, IMAP, LDAP, POP, SMTP 等)に共通に重要なセキュリティ機能(認証)を提供するメカニズムである。(ただし、日本の開発者で、SASL を意識しているのは、一部のメーラー開発者のみのように見受けられる。)この WG は、インターネット標準化過程を通じてSASL メカニズムの選択を含む SASL 関連事項を扱っている。
今回の会合においては、この WG は、これまでのすべての作業文書を既に G における最終工程であるラストコールにかけて、 WG をたたむか、憲章を改訂する段階になっている。エディトリアルな残案件処理の段階にある。しかし、最近のデジタル署名アルゴリズム一般についての衝突問題については、この SASL も、その影響を受ける。もう一度、基本文書( RFC 2222 後継)について、見直し・確認がなされることになりそうである。
サービスの利用者が、利用するサービスについてのクレデンシャル(アクセス権)を取得するために、サービスプロバイダーにコンタクトする必要があるような場合が多くある。(登録:enroll )この最初のコンタクトの部分には、ユーザとプロバイダーが相互に身元を検証することが含められる可能性がある。この WG は、本人認証に暗号技術が使われる場合に着目する。ユーザのプロバイダーに対するエンロールを行うとき、一定の情報が提供されるか、あるいは、作成される必要がある。
これらのデータ要素は、下記の通り。:
この WG は、これらについてのフレームワークを規定しようとしている。
今回の会合までのメーリングリストにおける議論も、会合における議論も活発ではなかったが、初夏までには、仕様としての形式は整いそうである。
GSSAPI [RFC 2743, RFC 2744] は、アプリケーションに、メッセージ単位のセキュリティサービスを提供する API を提供する。 Kitten WG は、コア GSSAPI 仕様についての拡張と改善と、 10 年来の懸案である言語のバインディングについて、標準化作業を行う。拡張類は、個別のドラフト、あるいは、 GSSAPI v3 に含まれるものとして発行される可能性がある。 GSSAPI v2 が明確化される一方、下位互換性は確保する。
今回の会合においては、存在する他の仕様との関係を意識した議論がなされた。潜在的には、共通的なセキュリティフレームワークとしては SASL が在るし、 SSH も多機能化しているので、競合する状態になっている。
(準備中)
Kerberos は、MIT において考案された共通鍵暗号技術に基づくネットワーク越しの認証・認可を行う仕様である。数年来、 Kerberos は、すべてのOSに移植されてきた。少なくとも、2つのオープンソース版、これに基づく数多くの商用版、そして、他のプロプライエタリな実装がある。Kerberosの発展は、その間も続き、相互運用可能性が問題となってきている。数多くのドラフト提案が、新しく拡張れた機能に関して発行されてきた。この WG は、セキュリティを向上しつつ、これらのシステム間における相互運用可能性を向上することに取り組んでいる。
今回の会合においては、仕様の明確化に関連して、ASN.1表記の仕様が、「人間が読むためのものであるのか、システムに処理させるためのものであるのか?」という哲学論争に根ざした議論が再現した。ある程度、人間が読めるものであることを保つ努力がなされる方向にある。
オープンソースプロジェクトであるOpenSSHは、システム管理者が利用するリモートアクセスソフトウェアのデファクトとなっているので、実装の方が先行しているものの仕様を標準化する案件である。前回のワシントン DC 会合までの 1 年間、 1 度もセッションが開催されずに「たなざらし」となっていた WGである。前回、臨時のエディターが立って、ようやく進捗し始めた、知的財産権(IPR )の問題を抱えている。
今回の会合においても、案件が WG の上位の IESG レビューで止まったままの状態にあり、早急に進める努力がなされることとなった。
まず、各 WG チェアから進捗報告がなされ、招待講演があるのが恒例となっている。今回の会合においては、下記の招待講演があった。
MD5 セキュアハッシュ関数の衝突は、容易に起こる。SHA-1 の衝突は、相当に困難ではあるが、影響を受ける事例もある。
最後に、恒例の「オープンマイクロフォン」の時間が設けられたが、最後のSHA-1 の衝突問題に意見が集中した。
IPsec プロトコルにおける公開鍵の交換プロトコルとしては、IKE (RFC 2409) が在るが、この代替手段として、共通鍵暗号技術を応用している Kerberosシステムを利用する中央集中的な鍵管理を行う標準プロトコルを策定することを憲章として掲げている。 合理化された高速で管理しやすく、暗号技術的に堅牢なプロトコルを策定しようとしている。これは、公開鍵暗号技術の操作を要求せず、現在と将来の Kerberos インフラストラクチャと互換性を保つものとする。
今回の会合においては、日本から、鎌田 健一 氏が、数多くの技術的な問題点を指摘した。
(準備中)