第36回IETF報告
分岐点に立つセキュリティ基盤の標準化 インターネットの標準化を進める第36回インターネット技術者会議IETFが， 6月24日より5日間カナダのモントリオール， コンベンションセンターにて開催されました． 広域環境に広く適用可能な認証基盤を提供しようとする本協議会にとって， 国際的な相互接続性を図ろうとするIETFの活動は重要です． そこで，同会議に参加した数名の専門家に各々の分野の動向を 探ってもらいました． インターネットにおけるセキュリティ基盤がどのような形に進んでいくのか， これらのレポートからその姿が浮かび上がってきそうです． TABLE OF CONTENTS
1. Overview報告者： 菊池浩明（東海大学）第36回IETFは，6月24日より5日間カナダのモントリオール会議場で 開催された．今回はインターネットソサイティ主催のINET96との 合同開催であり，どちらの参加者も互いの会議に出席できることが 許されている．そのため，総勢3500名の通常より大規模な会議となった． 端末室もMac, Windows, Unix入り交じって300台が一室に設定され， 相互連絡や資料集めにしばしば活用されていた．何台かPower Point がインストールされたマシンとOHPシートの入ったプリンタも 提供されており，その場で発表の資料を作ることも出来る（私も お世話になった）．開催国のお国柄か，INETの全てのセッションについてフランス語の 同時通訳がサービスされていて，逆に，フランス語でのスピーチも 許されていた．ただし，これは残念ながらIETFについては行われなかった INETによるものだが，会場の一階で展示会も開かれていた． TVなどのPressが多く取材に来ていて，カナダでのインターネットの 盛り上がりを感じた．日本人も何人か捕まって取材されていた．
会場のモントリオール会議場は地下鉄の駅に併設されており交通の便が
よく，夜遅くでも安全に出歩くことが出来た．チャイナタウンや
旧市街が近く，食事にのバリエーションにも困らない．
報告者： 菊池浩明（東海大学）PKIX WGは，6月25日の午前と午後の第一セッションで開催された． 主な議題は次の通り．1. Introduction 2. ISO X.509 Update 3. PKIX Part 1 (Certificate and CRL Profiles) Review 4. PKIX Part 3 Management Protocols Review 5. DoD Management Protocols 6. Japanese PKI Report 7. ASN.1 Documentation 8. Validity Periods 9. Reference Implementations & Conformance Testing大きなニュースは３つある． 一つは，ISOで進めている公開鍵証明書X.509バージョン3(V3) の仕様がほぼ固まり，名前空間の点においてOSI離れが進んだことである． これに伴い，本WGで標準化しているプロファイルも最終段階に 来たが，ここでインターネット独自の証明書拡張が提案されたことが， 二つ目のニュースである． そして最後のニュースは， 当協議会の活動紹介と開発成果物の一部のデモが行われたことであろうか． 以後，各々について報告する． 2.1 ISO X.509 UpdateNorthan Telcomの Warwick Ford が7月1日に行われた ISO/IECの X.509標準化動向を報告した．大きな変更点の一つは，criticality-based changes と呼ばれる属性である． （常に）critical，（常に）non critical, （CAの選択により） critical/non critical の三種類が提供される．この修正に伴って， 今までのOIDも更新される点に注意がなされた． また，識別名の領域に今まではOSIのDN名しか許されていなかったのが， General Name(すなわち，URL，IPアドレス，OIDなど）を置くことが 許されるようになった．（思わず拍手がわいた） Indirect CRLもここで新しく加えられた機能である．これは， あるCAに属するユーザのCRLを他のCAが代理で発行する機能であり， CRLの発行手続きを簡略化する効果がある．しかしながら， ひとつのCRLの中に複数のCAのCRLが混在することになり， どのCAのものなのか識別するための情報が導入されることとなった． 他にも "Hold"の機構や差分CRL，名前の厳密なマッチング規則などの 修正が行われた． なお最新のドラフトは， ftp://NC-17.MA02.Bull.com/pub/OSIdirectory/Certificates にある．
2.2 PKIX Part 1 (Certificate and CRL Profiles) ReviewSpyrusのRuss HousleyによるPKIX Part 1のドラフトについての提案 と議論である．重要なのは，このドラフトがX.509の拡張のうち 13 だけを プロファイルとして採用することと，証明書について3つ， CRLについて4つのそれぞれインターネット独自の拡張をしようという ことである．前者についてはこれまで報告されたものから 今回のcriticalなどの属性の拡張が振られただけなのに対し， 後者はOSIの枠からはみ出すものである．互換性を保証しないわけで， 会場から活発な賛否両論が寄せられた． これらの Internet Extensionは，主にアクセスの方法（information Access) を記述するものであり，ほぼ OIDとGeneralNameの組で構成される． 証明書については，Subject, Authority, CA の3種類， CRLについては，Status, Retrival, Policy, Certificate の4種類が この拡張で与えられる情報である．CAとAuthorityを分けたのは， Indirect CRLをサポートするためである． ICATで提供しているホームページのCA treeで定義している 1. CA, 2. CA Policy, 3. CA cert の情報は，ここでの拡張するべきと 提案されているものにそのまま対応しており， アクセス手段の提供を重要視している点で彼らの主張と同意している． 最後に，CharのSteve Kentから，本ドラフトは既に提案の形を整えているので WGメンバーからのMLでのコメントやが要請された．
2.3 Japanese PKI ReportICATのHiroaki Kikuchiによるもの． これまでの日本のPKIに対する取り組みとして， WIDEプロジェクトのFJPEMと，ICATの目的と成果が報告された． これに対して，次に示す質問が挙げられた．・証明書発行頻度と廃止リストの頻度について ・秘密鍵の生成について ・暗号化アルゴリズムについて ・暗号タスクフォースで計画している暗号化ライブラリについて ・日本における信頼の鎖の大きさの試算についてなお，本WGに関しては次の参考資料がある．
3. IPSEC (1) (IP Security WG)報告者： 寺田真敏（日立）3.1 IP層におけるセキュリティ体系インターネットにおけるIP層のセキュリティを向上させるため、 RFC(Request For Comments)1825からRFC1829において、 IP層のセキュリティ体系、メッセージ認証、 暗号化方式の標準化が進められてきた(図1 変更前)。 今回、メッセージ認証で使用する関数取り扱いの一般化、 同じくメッセージ認証におけるリプレイ攻撃対策、 暗号化方式での完全性保持情報付加等の方式の改善、 多様化から、 体系の見直しとこれに伴うRFCの改訂作業が進められることとなった(図1 変更後)。
3.2 鍵管理方式
今回のIETF IPSecにおいてもっとも議論の対象となった項目が、
IP層セキュリティにおける鍵管理方式であり、以下の発表が行われた。
鍵管理方式の方向性については、 後日開催されたsaag(Open Security Area Directorate Meeting BOF)において、 SKIP, ISAKMPが相互に協調しながらIPSecにおける 鍵管理方式の確立を進めていくこととなった (9月に最終的な方向性が決定される模様である)。 なお、実装面ではSKIPが先行しているが、 規格としての汎用性はISAKMPが優位である (ISAKMPは、TLS(Transport Layer Security WG) における鍵管理方式としても提案されている)。 また、ISAKMPの提案元であるNSAは ISAKMPの枠組みの中でKey Escrow機構の取り扱いをも考えている模様で, インターネット上の暗号技術における主導権獲得が見え隠れしている． 報告者： 室田 真男（東芝）IPSEC-WG は 2つのセッションが行なわれ，1つのセッションが鍵管理プロトコルに関 する議論にあてられた．現在 IPSEC-WG からは，SKIP(Sun社)，ISAKMP(NSA)，Oakley(Arizona大)，ISAKMP with Oakley(CISCO社)の4方式が提案されている．このうち，ISAKMP と Oakley は統 合化が進み，実質的には SKIP(Sun社) と ISAKMP/Oakley(CISCO社) の2方式．なお， Photuris(Qualcom社)は，前回(3月)のIETF会合後 IPSEC-WGからは，はずれている． まず，各方式の概要と実装状況の簡単な紹介があった．以下に実装状況をまとめる．
その他のトピックスを以下に簡単に示す．
5. TLS WG (Transport Layer Security)報告者： 山口英（奈良先端科学技術大学）TLS WG は、前回（1996年3月）との間に設立された新しい ワーキンググループである。このワーキンググループの名前からは、TCPあるいはUDP などの既存のトランスポート層プロトコルに対してセキュリティ機能を付加する方法を 議論するワーキンググループのように思えるが、 実際にはTCPやUDPには変更せずに、 トンランスポート層の直上に付加されるセキュリティ層を考え、 その層で実現されるべき機能とプロトコルを標準化するものである。 これは、ネットスケープ社などが展開しているSSLや、 マイクロソフト社が展開を進めているPCTなどの、 トランスポート層の直上に用意されるセキュリティ層が幾つかマーケットに 登場してきたために、その標準化を行おうとする気運が高まり、 このワーキンググループが結成されたのである。今回のミーティングでは、今後の活動方針と全体のデザインが報告された。 このワーキンググループでは、 1996年末までに標準化作業を完了させることを目標としている。 今回の会議では、現在マーケットに出回っている幾つかのプロダクトの中で、 SSL Ver. 3.0をベースにして標準化を進めていく方針が発表された。 SSLは現在マーケットで広く使われており、これに現在のPCT独自の機能を 持たせるようにした方が、標準化作業後のマーケットへの標準の浸透が すばやく行える事を期待していることから、このような方針になったのである。 このため、標準化作業としては、現在のSSL Ver. 3.0に対して幾つかの拡張を 行うことになる。この拡張について幾つかの議論があった。 それ以外に関連する発表としてSSH (Secure Shell: 詳細は http://www.ssh.fiを参照) と、 IPSEC WGが開発している鍵管理機構でのプロトコル ISAKMPについての発表が行われ た。
このようなワーキンググループができプロトコルの標準化が行われる事で、現在SSLや
PCTを用いているセキュリティアプリケーションの相互操作性が増し、インターネットの
セキュリティ保全を考えた場合により良い状況になると考えられる。
報告者： 塩野崎敦（ソニーCSL）rsvp WGのミーティングは，6月24日の夜と26日の午後のセッションに開催された． 今回は， RSVP Version 1 のドラフトの完成も間近になってきたという ことから，各ドラフトの進行状況の報告，および Version 2 の発展方法に 関する議論が行われた．したがって，細かい技術的な話は少なかった． 取り上げられた主なテーマを以下に示す．
- ドラフトの状況
- 実装の状況
- 新しいWGチャータについて
- RSVP Version 2 について
まず RSVP Version 1 を proposed standard にするためには
セキュリティのサポートが必要であることが指摘され，RSVP スペック，MD5
Integrity Object スペック，RSVP IPsec スペックの3つが IESG にパッケージ
として近々提出されることが報告された．
各組織の RSVP の実装状況の報告も行われた．Bay，CISCO，IBM，Intel，Sun からの報告があり，組織によっては早くても今年の9月には製品化される予定 がたてられている．ISI からは RSVP スペックの ID12 をベースにした 4.0a4 というリリースが現在配布されている． ドラフトの現状報告としては，MIB 関係，および診断メッセージの 発表が行われた．また，RSVP Version 1 が完成しつつあるので， WGとしてはここで新たなチャータを作成する必要があると合意され， 更に診断メッセージ，トネリングサポート，アクセス制御機構およびフレームワーク， RSVP Version 2 のドラフトを作成し承認されるまでのスケジュールがたてられた． また，先行予約(近い将来のために資源予約を今行うこと)の概念もチャータの 中に含むべきか議論されたが，決定はされなかった．
二日目のセッションでは，Version 2 で取り上げるべき機能について議論された．
具体的な提案などの話は少なく項目が列挙されただけだったが，
簡単にまとめると，まず IPv6 サポートに関しては，router alert ドラフトの更新，
フローラベルの使い方， RSVP チェックサムの取り扱い，ドキュメントの構成
(IPv6 用の RSVP を別の文書にすること) などが挙げられた．
また通信経路の最大 MTU の決定方法，セッショングループ，モービリティ，
トネリング，QOSPF と RSVP との関係，アクセス制御およびアカウンティング
などについても議論が行われた．特に，アクセス制御およびアカウンティング
に関しては，ローカルポリシモジュール (LPM) を導入して取り扱う．LPM
のドラフトは，3つに分割され，今後は RSVP に必要な拡張に関するドキュメントに
重点がおかれる．拡張には，Reservation Report という新たな RSVP メッセージ
の追加，また RSVP と ポリシとのインタフェースの規定などが挙げられている．
報告者： 塩野崎敦(ソニーCSL)Internetworking over NBMA (Non Broadcast Multiple Access) WG は， 6月24日の午後に1回と25日の午後に2回と合計3つのセッションで開催された． ion WG は，同じような問題を解決するために活動してきた ipatm WG と rolc WG を合併させ，新たに作成された WG である． 今回が始めての集まりで，最初のセッションでは，現状の報告，NHRP， RFC の更新などが取り上げられ，第2セッションでは IPv6， 第3セッションではマルチキャストに関する議論が行われた．最初のミーティングでは，NHRP Rev 8 の報告，および Rev 9 に向けて必要な 変更点，サーバキャッシュ同期プロトコル (SCSP)，RFC1577 の更新， IP 用の ATM シグナリングサポート(RFC1755 アップデートに UNI4.0 を導入 すること)などが取り上げられた． 第2のセッションでは，IPv6 over NBMA の発表が主に3つ行われ， ATM における IPv6 のリンクの定義，IPv6 neighbor discovery の実現，NHRP との統合に関する議論が行われた．結論としては， 3つのドラフトは細かい所に相違があるだけで，基本的には似ている 提案なので，今後は1つのドラフトにまとめられる方向に決まった． 最後のセッションでは，MARS において複数のマルチキャストサーバを 導入する方法の提案が発表され，これを耐故障性，およびロードシェアリングに 応用する方法についても議論が行われた． また，MARS と SCSP 同一の枠組で利用する方法に関する発表も行われた． 非ATM NBMA ネットワークにおいて MARS を利用する方法に 関する議論も行われ，これは新たな ion のチャータ作成のために 利用されるかもしれない．MARS MIB に関する発表も行われた． 最後に，マルチキャストのスケーラビリティに関する問題について 議論が行われた．
報告者： 塩野崎敦(ソニーCSL)intserv WGは，6月26日の午後に開催された． intserv でも，proposed standard として用意しているドラフトスペックを 近々 RFC にするため IESG に提出する予定である．そこで今後は， 既存の proposed standard の実装経験などを活かし，レビューされるまで 新たな standard-track サービスを提案することは休止する方向であることが 明らかにされた．その後は，各ドラフトスペックの簡単な状況説明が行われ，更に 再構成された General Parameters のドキュメントに関する議論が行われた． 現存するテーマの議論は以上で終了した． 最後に，新たに committed rate service の提案が発表された． Commited rate service とは，経路上の各ネットワーク要素が 必ず要求された最低限の転送レートを提供することを約束(committ)する というサービスである．基本的には guaranteed と controlled-load の 中間に当たるサービスであり，指定した TSpec の値を越えることなく， バーストトラヒックを流す必要のないアプリケーションを対象にしている． しかし，発表後の議論では既存のサービスとの違いが明白ではないことが 指摘され，結局結論はでなかった．
9. スナップショット
|
![[HOME]](../newicons/home01.gif)
[Homepageへ戻る]