ニュースレターNo.36/2007年7月発行

セキュリティ関連WG報告

セキュリティに関連したトピックスを報告します。

Secure Inter-Domain Routing（SIDR）WG （3/19 13:00～17:00、参加人数：約120名）

SIDR WGでは、ドメイン間ルーティングの安全性を高めるために、AS番号の正当性を検証するメカニズムの検討を行っています。

まず、Resource CertificateプロファイルのI-Dの修正点が報告されました。そして、今後の暗号アルゴリズム拡張への対応が考慮され、SHA-256がMUSTと記述されていた部分が、Minimumに変更されました。また、CA証明書更新のためにAIA属性を利用することが記載されました。

次に、PKIXのチェアであるStephen Kent氏（BBN）からは、CP/CPSに関する三つのI-Dが提案されました。三つの内訳は、IPアドレス・AS番号に対する証明書ポリシー、インターネットレジストリ向けのCPSテンプレート、ISP向けのCPSテンプレートです。

さらに、Stephen Kent氏からアーキテクチャドキュメントが提案されました。このドキュメントでは、インターネットナンバーリソースに対するPKIの位置付け、ROA（Route Origination Authorizations）、リポジトリについて規定されています。

最後に、再度Stephen Kent氏からROA（Route Origin Attestation）プロファイルの説明が行われました。Route Origin Attestationは、バージョン番号、AS番号、IPアドレスブロックで構成され、CMSのSingned Dataを利用しています。CMSを採用した理由として、XMLよりデータサイズが小さく、CMSはOSS（例えばOpenSSL）を活用できることが挙げられています。

RTP Secure Keying（RTPSEC）BoF （3/19 15:20～17:20、参加人数：約200名）

RTPSEC BoFは、RTP（Real-time Transport Protocol）のセキュアなプロトコルを検討するBoFです。セキュアRTPとしていくつかの鍵交換メカニズムや、RTPの下位レベルにあたるセキュリティが提案されており、基本的な要件を確認しプロトコルの策定を目指しています。

今回のBoFでは、IABメンバーでもありTLS WGのチェアであるEric Rescorla氏によるDTLS-SRTP、Lakshminath Dondeti氏によるMIKEY v2、PGPの作成者であるPhil Zimmermann氏（MIT）によるZRTPの三つの鍵交換メカニズムについて議論が行われました。議論の最後にハミング投票※が行われ、今後、DTLS-STRPをベースに検討が進められることとなりました。

※ ハミング投票: 参加者がハミングを行い、その音量によってコンセンサスの成否を判断する方式。

Transport Layer Security（TLS）WG （3/20 9:00～11:30、参加人数：約120名）

TLS-WGは、TLS（Transport Layer Security）の標準化を行うWGです。既にTLS1.0/1.1の標準化を終え、現在はTLS1.2の標準化を行っています。本WGでは、以下のようにDocumentのステータス報告がありました。

□RFCとして出版されたもの

TLS1.1（RFC4346（PS））
TLS1.1 Extensions（revised）（RFC4346（PS））
Datagram Transport Layer Security（RFC4347（PS））
ECC Cipher Suites（RFC4492（PS））
Transport Layer Security（TLS）Session Resumption without Server-Side State（RFC4505（PS））
TLS User Mapping Extension（RFC4681
TLS Handshake Message for Supplemental Data（RFC4680）
Pre-Shared Key Cipher Suites with NULL Encryption for Transport Layer Security（TLS）（RFC4785）

□Last Call中

Transport Layer Security（TLS）Authorization Extensions（draft-housley-tls-authz-extns-07）

□RFC Editorの処理待ち

Using OpenPGP keys for TLS authentication（draft-ietf-tls-openpgp-keys-11）

□RFC Editorが作業中

Using SRP for TLS Authentication（draft-ietf-tls-srp-13）

□WGで作業中

AES Counter Mode Cipher Suites for TLS and DTLS（draft-ietf-tls-ctr-01.txt）
The TLS Protocol Version 1.2（draft-ietf-tls-rfc4346-bis-03.txt）

この報告の後に、TLS1.2の状況が報告されました。前回からの差分としては、公開鍵指数が3の場合、容易に電子署名を偽造できる問題（e=3問題もしくはBleichenbacher Attack）への対策と、Timing Attackへの対策が求められていること、NISTのSuite Bへの対策が引き続き行われていることなどについて修正したことが報告されました。

また、未解決な部分として、PKCS#1においてNULLパラメータを指定した際にエンコードを行うべきか否かや、電子署名時のHash Agilityの問題（DSAではSHA-1しか使えない、自分の証明書で使われているHashしか事実上使えないなど）が指摘されました。さらに、Alert Packetの扱いに関しての議論が前回に引き続き行われました。これらの問題については、MLで継続して議論することになっています。

NSAのSuite Bへの対応については、2010年までの猶予はあるものの、Hash Agilityを考慮すると、Hash Algorithmの選択についてどう自由度を上げ、相手側とネゴシエーションするかが鍵となりそうです。

新しいWG Draftの提案として、EAPを使ってTLSの認証を行うTEEが提案されましたが、TLS WGの範疇ではないという意見が多く、また現在、前提としているEAPのモデルとの齟齬があり、EAPのコミュニティとの協力が必要であるという指摘がありました。

さらに、前回のIETFに引き続き、Microsoft社のStefan Santesson氏より、GSS-APIをTLSの認証および鍵生成に使うことが提案されていました。実質的なプレゼンテーションは行われませんでしたが、興味は持たれたようです。しかしながら、形になるにはまだ時間がかかりそうです。

Network Endpoint Assessment（NEA）WG （3/20 13:00～15:00、参加人数：約100名）

NEA WGでは、Windows Vistaで導入されたNAP（Network Access Protection）のように、ネットワークに接続している物（Endpoint）が、ネットワークに接続する要件を満たしているかどうかをクライアントから報告するとともに、サーバ側で要件を満たしているかについても監査をし、その結果により接続の許可もしくは切り離し（もしくは限定的な接続）をするための、標準としてのプロトコルを策定しようとしています。

WGのステータス報告として、まずプロトコルデザインを行うデザインチームの選任（Symantec社のPaul Sangster氏、Intel社のHormuzd Khosravi氏、Avaya社のMahalingam Mani氏、Cisco社のKaushik Narayan氏とNevis networks社のJoseph Tardo氏）報告がありました。

また、デザインチームにより、要求仕様のI-D（第0版が2007年1月10日公開、第1版が2007年3月5日公開）が公開されたことの報告がありました（4月に第2版が無事公開されたようです）。なお、この報告の際、会合に参加しているメンバーに当該I-Dを読んでいるかどうかについての確認があり、30%程度のメンバーが読んでいることがわかりました。最近はこの手のI-Dが読まれることはそれほど多くなく、関心の高さがうかがえました。

この報告の後、以下に記したWGの活動におけるマイルストーンが確認され、承認されました。

2007年3月	要求仕様I-Dの未解決部分の解決
2007年4月	第2版NEA要求仕様I-Dの提案
2007年5月	要求仕様に関しての議論
2007年6月	第3版NEA要求仕様I-Dの提案 NEA要求仕様I-DのWG Last Call実施
2007年7月	第69回IETFにてWG Last Callで判明した未解決部分の解決
2007年8月	第4版NEA要求仕様I-Dの提案 NEA要求仕様I-Dの提案をInformational RFCとするためにIESG Last Call実施

この後、NEA要求仕様I-Dの議論が行われました。

はじめに、NEA要求仕様I-Dの簡単な説明と、前回（第67回IETF）で合意されたNEAのReference Modelの確認の後、実際にPA（Posture Attribute）プロトコルで交換すべきAttribute値のタイプとストラクチャが紹介されました。この際に、クライアント/サーバ間における情報交換のユースケース紹介と、それに従ったデータのやり取りが紹介されました（この部分は、問題無く軽く流されました）。

また、未解決の問題点として、以下の4点が挙げられました。

Virtualization
Non EndpointにおけるNEA
Securityを全てのLayerで行うか否か
クライアント/サーバ間で交換すべき情報の最小化を行うべきか否か

種々の観点で議論がなされましたが、いずれもMLにおいて議論を継続するという結果となりました。

特に、（1）および（2）については、NEAの適応範囲を決めるものとなり、意見、コメントが多く寄せられました。（1）に関しては、原則としてVirtualizationを含むという意見が大勢を占めましたが、その一方でVLAN/VPNにおける扱いはどうするのかという意見が出ました。（2）に関しては、IDSのようなものは積極的にパケットを出さないし、また存在を教えたくないがその点についてどう考えるかという意見が出ました。

Public-Key Infrastructure（X.509）（PKIX）WG （3/20 17:40～18:40、参加人数：約50名）

まず、ドキュメントステータスレビューが行われました。前回のミーティングから新しいRFCは発行されておらず、SCVP、Lightweight OCSP、SAN for Service NamesがLast Callとなっていること、RFC3280bisはWGチェアによるレビュー待ちであること、CMCドキュメントはIESGからの指摘事項への対応を行っていることが報告されました。また、ECCアルゴリズムI-Dは進捗が無く、Russ Housley氏（セキュリティエリアディレクタ）からの指摘事項に対応中であること、ECDSAとDSA with SHA-2ドラフトは期限切れとなったが、FIPS 186-3として発行されることも報告されました。

続いて、Jim Schaad氏（Soaring Hawk Consulting社）より、Certificate Management Messages over CMS（CMC）の説明が行われました。三つのドキュメントがIESGによるレビューを受け、いくつかの修正要求があったことが報告されました。その指摘事項の一つは、PKCS#10をMUSTとすることを止め、CRMFをMUSTとすることですが、Microsoft社はPKCS#10を利用しているため課題が残ります。なお、Windows VistaからはCRMFも利用可能です。その他の指摘事項としては、Proof of possessionで利用されるShared Secretサイズをガイダンスとして提供すべきということです。SP 800-56A（NIST document）の最近の修正では、暗号化用途のRSA鍵をProof of possessionへの署名に利用することを許していますが、破棄リクエストへの署名に対しては使うことを許していないという矛盾を抱えています。

Tim Polk氏（NIST）からは、ECCデザインチームの報告がありました。前回のミーティングからecc-pkalgs-03の進捗は無く、デザインチームの再構築を行うことになりました。

Stefan Santesson氏（Microsoft社、PKIXチェア）からは、Subject Alternative Name for Expression of Service Nameについて、IESGからの指摘事項と、国際化の問題に関する説明があり、この問題については修正することになりました。修正後、新たなWG Last Callにかけられる予定です。また、同氏からは、国際化電子メールの説明がありました。EAI WGでは、電子メールアドレスのローカルパートに対する国際化を行っていますが、これらの名前をどのように証明書で扱うかが課題となっています。

Stephen Kent氏（BBN社、PKIXチェア）からは、Stefan Santesson氏（Microsoft社）が提案した“santesson-pkix-vccrl”をWGアイテムとして受け入れるかどうかについて説明がありました。ML上で投票を行い、その結果、賛成11票、反対22票であったため、WGアイテムからは除外されることとなりました。反対意見のいくつかは、扱っている問題を探ることには賛成だが、そのアプローチには反対という意見でした。

Denis Pinkas氏（Bull社）からのFramework on Key Compromise, Key Loss & Key Rolloverの提案については、代理でStephen Kent氏（BBN社）が行いました。CA、AA、TSAなどの計画的あるいは予定外の鍵交換に対するガイダンス（Informational RFC）を作るべきであるという提案です。より詳細に記載するとドキュメントのサイズはどんどん大きくなるとか、ETSIドキュメントとして既に存在しているのではといった質問がありました。WGアイテムとするかどうかは、MLで投票を行うことになりました。

そして、Scott Lawrence氏（Pingtel社）から、Domain Certificates in the Session Initiation Protocol（SIP）の課題報告がありました。Lawrence氏からは、TLSコネクション確立における、SIPプロキシの証明書プロファイル作成に対する協力依頼がありました。ExtendKeyUsageを利用すれば良いとか、ある目的に発行された証明書を他のアプリケーションで不適切に使うべきでないといった議論があり、これはMLで引き続き議論することになりました。

Long-Term Archive and Notary Services（LTANS）WG （3/20 18:50～19:50、参加人数：約20名）

Long-Term Archive Service RequirementsがRFC4810として公開されました。ERSはIESGレビュー中です。WGではLTAP、ERSおよびLTAPのXML化を行っており、ERS/SCVPとPKI Retentionが4月にWG Last Callとなる予定です。San Diegoで策定したマイルストーンより少々遅れていますが、2007年12月にはこのWGをクローズする予定となっています。また、draft-ietf-ltans-ltap-04が提出され、次のltap-05ではXMLに対応する予定です。ASN.1モジュールやXMLスキーマについても議論が行われ、ASN.1モジュールとして88-ASN.1の替わりに1997/2002-ASN.1モジュールを利用すべきかどうかという議論がありました。1997/2002-ASN.1に対応するフリーのコンパイラには、いくつか不具合もあるという報告が行われました。

続いて、draft-ietf-ltans-validate-01が提案されました。これは検証データの扱いについて規定している文書です。LTAサービスが、署名やタイムスタンプを無限に検証することが可能となるようにするためのメカニズムを提案しています。

また、XMLERSの紹介が簡単に行われましたが、議論はML上で引き続き行うことになりました。

Michael Herfert氏（Fraunhofer社）からは、ERSの実装について紹介がありました。Herfert氏からOpen Textとの互換性テストも完了しているとの報告があった一方で、会場からはLTAPは利用できないのかといった質問がありました。

なお、RFC3161（TimeStamp）を利用しないERSについては、議論が行われる予定でしたが、これについてはMLで議論を行うことになりました。

IPsec FAilover and REdundancy（IFARE）BoF （3/21 9:00～11:30、参加人数：約60名）

IFARE BoFは、モバイルIPのためのIPsecフェイルオーバーについて検討することを目的としたBoFです。

どの程度の規模を対象としているのか、単にプロビジョニングの問題なのではないか、どこが課題なのかといった白熱した議論が行われ、これらの点について継続した議論をMLで行うことを確認して終了しました。

また、三つのドキュメントがIESGによるレビューを受けたものの、IESGからいくつかの修正要求を受けたことが報告されました。その指摘事項の一つは、PKIX WGのところでも述べた通り、PKCS#10のサポートをMUSTではなくし、その替わりにCRMFをMUSTとすることです。しかし、Microsoft社はCRMFではなくPKCS#10を利用しており、この提案は解決になっていません。

その他の指摘事項としては、POPで利用されるShared Secretのサイズをガイダンスとして提供すべきということです。Jim Schaad氏は、これに対する公開されたスタンダードがないため、いくつかの数を揃える（make up some numbers）ことになると思われます。

また、SP 800-56A（NIST document）の最近の修正では、暗号化用途のRSAをPOPのメッセージ署名のためだけに利用することを許しています。しかし、このドキュメントは、破棄リクエストへの署名に対しては鍵を使うことを許していません。これもまたミスマッチとなっています。

IETF Operations and Administration Plenary （3/21 17:00～19:30、参加人数：多数）

第68回IETFの参加状況、収支報告、スポンサー紹介などが行われました。その中で、新たなIETFチェアとしてセキュリティエリアディレクタであるRuss Housley氏（Vigil Security社）の就任が報告されました。

Russ Housley氏は米国空軍のデータセンター勤務後、RSA laboratoriesでPKI関連の研究開発に従事し、現在ではVigil Security社を運営しています。彼は、IETFにおいてセキュリティエリアで主に活動し、複数のRFC/I-Dを書き、種々のプロトコルのセキュリティ設計を行ってきた人物です。特にPEM（Privacy Enhanced Mail、S/MIMEの前身）の開発と、PEMからS/MIMEへの移行に関して多くの貢献をしました。ここ数年はセキュリティエリアディレクタとしてセキュリティエリアにおける複数のWGについて方向性を定め、インターネットプロトコルの安全性を高める活動を行ってきました。

また、新たなセキュリティエリアディレクタとして、元PKIX WGチェアのTim Polk氏（NIST）の就任が報告されました。Tim Polk氏はNISTにおけるPKI活動の中心人物の一人であり、米国政府におけるPKIの推進役でもあります。FPKI/PIVなどの活動に関する負荷が高くなり、一度、PKIX WGのチェアを退きましたが、Russ Housley氏のIETF Chairへの就任に伴い、セキュリティエリアディレクタとして活動を行うことになりました。

彼ら二人の昇格は、ともにインターネットプロトコルに対するセキュリティ分野での彼らの貢献と、今後さらに広くセキュリティ（特にPKIなどの公開鍵暗号系の認証技術）を広めることを期待されていると見るべきでしょう。

Provisioning of Symmetric Keys（KEYPROV）WG （3/22 13:00～15:00、参加人数：約50名）

前回のSan Diego会議ではBoFとしての開催でしたが、今回はWGとして開催されました。SecureIDのようなワンタイムパスワード機能は、携帯電話にも搭載される見通しですが、このWGではこれらの共通鍵暗号の共有鍵を前もってシェアする方法、プロトコルの策定を目指しています。

今回のWGでは、パーソナルドラフトとして提案されている、Extensions to CT-KIP to support one- and two-pass key initialization、Cryptographic Token Key Initialization Protocol（CT-KIP） Web Service、Dynamic Symmetric Key Provisioning Protocol、Portable Symmetric Key Containerについての説明があり、その方向性について議論が行われました。

S/MIME Mail Security（SMIME）WG （3/22 15:10～16:10、参加人数：約20名）

ドキュメントステータスレビューの後、Russ Housley氏（Vigil Security社）から、CMS Authenticated-Enveloped-Data Content Typeの説明がありました。認証された暗号化を達成するための提案で、内容としては、Enveloped DataとAuthenticated Dataを足して2で割ったものです。

SMIMEチェアのSean Turner氏（IECA）からは、Multiple Signature Attributeの説明がありました。HashやSignatureアルゴリズムへの攻撃へ対処するために、複数の署名を埋め込めるようにしています。

（富士ゼロックス株式会社稲田龍）