メインコンテンツへジャンプする

JPNICはインターネットの円滑な運営を支えるための組織です

ロゴ:JPNIC

WHOIS 検索 サイト内検索 WHOISとは? JPNIC WHOIS Gateway
WHOIS検索 サイト内検索
===================================
    __
    /P▲         ◆ JPNIC News & Views vol.440【臨時号】2007.4.5 ◆
  _/NIC
===================================
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ News & Views vol.440 です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

本号では、vol.436、vol.437、vol.438に続き、第68回IETFのレポート[第4弾]
として、セキュリティ関連WGの動向についてお届けします。

□第68回IETF報告 特集
○[第1弾] 全体会議報告 (vol.436)
   http://www.nic.ad.jp/ja/mailmagazine/backnumber/2007/vol436.html
○[第2弾] DNS関連WG報告 (vol.437)
   http://www.nic.ad.jp/ja/mailmagazine/backnumber/2007/vol437.html
○[第3弾] IPv6関連WG報告 (vol.438)
   http://www.nic.ad.jp/ja/mailmagazine/backnumber/2007/vol438.html

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第68回IETF報告 [第4弾]  セキュリティ関連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の三つの鍵交換メカニズムについて議論
が行われました。議論の最後にハミング投票(*1)が行われ、今後、DTLS-STRP
をベースに検討が進められることとなりました。

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


◆Transport Layer Security(TLS) WG
  (3/20 9:00~11:30、参加人数:120名くらい)

TLS-WGは、TLS(Transport Layer Security)の標準化を行うWGです。既にTLS
1.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-10)

  □RFC Editorが作業中
    - Using SRP for TLS Authentication(draft-ietf-tls-srp-12)

  □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で継続して議論すること
になっています。

NISTの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日公開)が公開されたことの報告がありました。なお、この報
告の際、会合に参加しているメンバーに当該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点が挙げられました。

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

種々の観点で議論がなされましたが、いずれも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アルゴリズムへの攻撃へ対処するため
に、複数の署名を埋め込めるようにしています。


なお、次回のIETF69ですが、2007年7月22日から27日まで、米国イリノイ州シ
カゴで開催される予定です。


     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       わからない用語については、【JPNIC用語集】をご参照ください。
             http://www.nic.ad.jp/ja/tech/glossary.html
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
___________________________________
■■■■■  JPNICの活動はJPNIC会員によって支えられています  ■■■■■
  :::::  会員リスト  :::::  http://www.nic.ad.jp/ja/member/list/
  :::: 会員専用サイト ::::  http://www.nic.ad.jp/member/(PASSWORD有)
□┓ ━━━  N e w s & V i e w s への会員広告無料掲載実施中 ━━━┏□
┗┛          お問い合わせは  jpnic-news@nic.ad.jp  まで          ┗┛
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
===================================
 JPNIC News & Views vol.440 【臨時号】 

 @ 発行         社団法人 日本ネットワークインフォメーションセンター
                 101-0047 東京都千代田区内神田2-3-4 国際興業神田ビル6F 
 @ 問い合わせ先   jpnic-news@nic.ad.jp
===================================
登録・削除・変更   http://www.nic.ad.jp/ja/mailmagazine/


■■◆                          @ Japan Network Information Center
■■◆                                     @  http://www.nic.ad.jp/
■■

Copyright(C), 2007 Japan Network Information Center


このページを評価してください

このWebページは役に立ちましたか?
ページの改良点等がございましたら自由にご記入ください。

このフォームをご利用した場合、ご連絡先の記入がないと、 回答を差し上げられません。 回答が必要な場合は、お問い合わせ先をご利用ください。

ロゴ:JPNIC

Copyright© 1996-2022 Japan Network Information Center. All Rights Reserved.