現在、マイクロソフト セキュリティ情報 MS10-090のパッチを適用したInternet
Explorer 8をお使いの方は、
JPNIC Webサイトの内容が印刷できない状態になっています。
印刷をする場合には、 Internet Explorer 8以外のブラウザを利用してください。
この不具合の詳細と、その対処方法については、
マイクロソフトのWebサイトに掲載されている以下の技術情報をご覧いただくか、
マイクロソフトのサポートセンターにお問い合わせください。
マイクロソフトの技術情報
--------- PR ---------------------------------------------------------
◆◇◆◇◆◇◆◇◆AT&Tグローバル・サービス株式会社◆◇◆◇◆◇◆
ビジネスを成功に導く最先端の企業向けネットワーク・サービスをご提供。
サービスのご紹介やネットワーク最新動向レポートはこちらから→
◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆◇◆http://www.jp.att.com/
----------------------------------------------------------------------
---------- PR --------------------------------------------------------
サ┃ー┃バ┃ア┃プ┃リ┃ケ┃ー┃シ┃ョ┃ン┃セ┃キ┃ュ┃リ┃テ┃ィ┃
━┛━┛━┛━┛━┛━┛━┛━┛━┛━┛━┛━┛━┛━┛━┛━┛━┛
開催場所：2005年10月6日(木)〜7日(金) 秋葉原コンベンションホール
詳細：http://www.nic.ad.jp/security-seminar/ お申し込み受付開始！
JPNIC・JPCERT/CC セキュリティセミナー 2005
----------------------------------------------------------------------
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
__
/Ｐ▲ ◆ JPNIC News & Views vol.286【臨時号】2005.9.2 ◆
_/ＮＩＣ
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ News & Views vol.286 です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
本号では、第63回IETF報告[第4弾]セキュリティ関連WG報告をお届けします。
vol.281からお届けしてきた本特集ですが、本号で終結です。これまでのレポー
トについては、以下のWebページよりご覧いただけますので、また振り返って
じっくりお読みください。
□第63回IETF報告
[第1弾] 全体会議報告 (vol.281)
http://www.nic.ad.jp/ja/mailmagazine/backnumber/2005/vol281.html
[第2弾] IPv6関連WG報告 (vol.282)
http://www.nic.ad.jp/ja/mailmagazine/backnumber/2005/vol282.html
[第3弾] DNS関連WG報告 (vol.285)
http://www.nic.ad.jp/ja/mailmagazine/backnumber/2005/vol285.html
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第63回IETF報告 [第4弾] セキュリティ関連WG報告
JPNIC 技術部 木村泰司
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
第63回IETFの中で、セキュリティエリアのセッションは17開かれました。その
うち4セッションが新たに開かれたBoFでした。
今回開かれたBoFは下の4つです。
−Hash BoF(One-way Hash Function BoF)
−ALIEN BoF(Anonymous Identifiers BOF)
−MASS BoF(Message Authentication Signature Standards BoF)
−SECMECH BoF(Security Mechanisms BoF)
前回までBoFが開かれていたBTNSはWGになり、初めてのWGセッションとなりま
した。
ここでは、セキュリティエリアのセッションの電子認証に関わるセッションに
ついてご報告致します。
◆One-way Hash Function BoF(一方向ハッシュ関数の脆弱性に関するBoF)
2005年8月1日(月)18:15よりハッシュ関数の脆弱性に関するBoFが開かれました。
このBoFは最近発見されたハッシュ関数の脆弱性に対して、どのように対応し
ていくかを議論するためのBoFです。話題性のある内容だけに、会場には150人
程集まり、会場の通路や前方近くに座って参加する人が多数いました。
ここでのハッシュ関数とは、任意の長さのデータに対する演算処理を何度も行
い、一定の長さの値を算出する計算処理(関数)のことです。元になるデータが
少しでも違うと算出される値が大きく変わる性質を利用して、通信路でデータ
が改変されていないかどうかを確認するときなどに使われ、X.509の電子証明
書などで使われています。
ハッシュ関数に関する研究は長年行われてきており、脆弱性を示唆する現象は
これまでにも指摘されてきました。しかし2004年中頃から2005年にかけて、こ
れまでにないほど影響が大きい研究結果がいくつかの学会で発表されていまし
た。ハッシュ関数の中に、異なるデータから同じ値が算出されるものがあるこ
とが立証されたり、同じ値が算出されるようなデータを探す方法で、効率の
良いものが発表されたりしたのです。
IETFで仕様が策定されているセキュリティ関連のプロトコルの中には、MD5や
SHA-1といった脆弱性が指摘されたハッシュ関数を使っているものが多くあり
ます。これらのハッシュ関数の耐衝突性(異なる二つのデータから同一の値が
算出されにくい性質、すなわち同じ値が算出されるような元の値の探索が難し
いという性質) は、実は想定よりも弱いことがわかってきました。
このBoFは、ハッシュ関数の脆弱性に関する現状を把握し、IETFのセキュリティ
エリアとしてどのように対応していくかを議論するために開かれました。
BoFの活動趣意やアジェンダについては下記のWebページをご覧下さい。
□One-way Hash Function BOF (hash)
http://www.ietf.org/ietf/05aug/hash.txt
このBoFでは、はじめに米国NIST(National Institute of Standards and
Technology - 米国標準技術研究所)によるワークショップの紹介がありました。
このワークショップは2005年の10月31日〜11月1日に開催が予定されており、
既存のハッシュ関数に代わるSHA-256やSHA-512といったハッシュ関数の紹介や
新しいハッシュ関数への移行方法について議論が行われる予定です。詳しくは
下のWebページをご覧下さい。
□CRYPTOGRAPHIC HASH WORKSHOP
http://www.csrc.nist.gov/pki/HashWorkshop/index.html
次に、プロトコルの工夫によって脆弱性を回避する方法がいくつか紹介されま
した。新たなハッシュ関数を開発しその強度を検証するには時間がかかるため、
これらの短期的な対策が必要になります。今回プレゼンテーションされたもの
はいずれも提案の段階で、今後どのような"短期的な対策"と"長期的な対策"が
取られていくかは、前述のワークショップでの議論を踏まえて検討されていく
と考えられます。BoFで紹介のあったハッシュ関数の現状をまとめたWebページ
と今後の議論に使われるメーリングリストの加入方法については、下記をご覧
下さい。
□Cryptographic Hashes(現状をまとめたページ)
http://www.vpnc.org/hash.html
□ハッシュ関数の脆弱性に関する議論を行うメーリングリストのWebページ
https://www1.ietf.org/mailman/listinfo/hash
◆PKIX WG
PKIX WGのセッションは、2005年8月2日(火)14:00から行われました。約60名の
参加で、近年のPKIX WGのセッションとしてはまずますの人数です。はじめに
ドキュメントステータスの報告が行われました。
前回のIETFから今回までの期間に二つのドキュメントがRFCになりました。
−Additional Algorithms and Identifiers for RSA Cryptography for
use in the Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile (RFC 4055)
−Internet X.509 Public Key Infrastructure Permanent Identifier
(RFC 4043)
前者は電子証明書とCRL(失効リスト)で、RSAのアルゴリズムに関連した署名ア
ルゴリズムと鍵共有アルゴリズム、それから一方向性関数の追加について取り
決めたものです。後者はSubject欄などではなく、恒久的な識別子を電子証明
書に入れるための拡張です。電子証明書の有効期限が切れるなどして、別の電
子証明書が発行されたときでも、同一の識別子を入れておくために使われます。
下記の4つがRFC Editorの編集待ちの状態です。これはRFCになることは決定
しており、最終的な編集を行っている段階です。
−Certification Path Building
(draft-ietf-pkix-certpathbuild)
−Warranty Certificate Extension
2005年9月1日現在、このドキュメントはRFC 4059になっています。
−Certificate Management Protocols
(draft-ietf-pkix-rfc2510bis)
−Certificate Request Message Format (CRMF)
(draft-ietf-pkix-rfc2511bis)
Certification Path BuildingがRFC Editor queueに入り、証明書の検証に関
する再度の仕様検討が徐々に片付きつつあります。あとはRFC3280の後継(通称
RFC3280bis)が残っています。こちらはまだ重い課題が残っており、検討が続
きそうです。
PKIX WGの議論としては、はじめに"SRV RR"と題してMicrosoftのStefan
Santesson氏によるプレゼンテーションがありました。これは_
ldap._tcp.domain.comといったDNSのRR(リソースレコード)を使って、電子証
明書のデータを格納／取得する方法の提案です。WGとしてのドラフトドキュメ
ントにはなっておらず、個人のドラフト
(draft-santesson-pkix-srvrr-00.txt)としてsubmitされています。
これに対し会場からは、DNSのゾーン管理がサーバ証明書の利用を許可するよ
うなモデルで問題がないかを確認する必要がある、といった指摘がありました。
一方、MLでは入手した電子証明書を検証するための信頼の設定について議論さ
れています。
SCVPについては、処理能力が低いシン・クライアントでの実装上の問題につい
て議論されました。SCVPは電子証明書の検証を、他のサーバに任せて行うため
のプロトコルです。今までに上がっている指摘は、複数の認証局証明書を検証
するときに、nameConstraints等の制約をチェックすることが負荷になる点、
検証ポリシーと検証アルゴリズムの二つのOID(Object Identifier)が必要にな
る点の二つです。後者についてポリシーとアルゴリズムをまとめたポリシー
OIDを設ける提案がなされましたが、会場ではまとまらないため、一度個別に
議論が行われることになりました。
RFC3280bisは、電子証明書とCRLの基本的な扱いを記述するドキュメントです。
様々な論点が残っています。認証局の鍵を変えるための"Root CA key update"
は、RFC2510(CMP)で言及されている古い鍵で新しい証明書に署名をする"new
with old"などを組み合わせる手法がありますが、改めて記述するようです。
この他にkeyUsageフィールドのnonRepudiationビットの解釈の仕方をはじめ、
6つほど大きな論点が残っています。ひとまず今の -01 版に対するコメントを
反映して修正し -02 版でもう一度コメントを募ることになりそうです。
恒例のLiasion Presentationでは、ETSI(European Telecommunications
Standards Institute)の立場で、Denis Pinkas氏がCAdES(CMS Advanced
Electronic Signature)の紹介を行いました。CAdESはCMS(Cryptographic
Message Syntax)を使って長期的に検証可能な電子署名を実現するための書式
です。ETSIではXMLを使った電子署名の書式であるXAdES(XML Advanced
Electronic Signatures)をETSI TS 101 901と呼ばれるドキュメントにまとめ
ており、これをCMSを使ったものに書き換えるという位置づけのようです。
同様のプロトコルにRFC3126があり、これを更新することを目標としている
ようです。ドラフトドキュメントは下記のURLから入手できます。
□CMS Advanced Electronic Signatures (CAdES)
http://www.ietf.org/internet-drafts/draft-pinkas-smime-cades-01.txt
◆SAAG (Security Area Advisory Group)
SAAGはIETFのセキュリティエリアの全体会議です。各セッションの報告や最近
の話題についてのプレゼンテーションや議論が行われます。今回のIETFでは8
月4日(木)の14:00〜16:30開催されました。
今回行われたプレゼンテーションは、"ITU-T Recommendation X.805"の紹介と
"Unicode Security Considerations"の紹介です。
ITU-T Recommendation X.805 は End-to-Endの通信を構成するシステムのセ
キュリティの側面を分類し整理したものです。盗聴やなりすまし、使用不能と
いった脅威をモデルとして、脅威を避けるための技術要素を分類しています。
分類はSecurity Dimensions、Security Layers、Security Planesと呼ばれる
三つの観点で行われています。
会場からは、三つの観点の関連性はあるのか、ある脅威に対して適した分類が
なされているのか、などの内容の正しさに関する指摘が挙がり、果たしてこの
文書が"Recommendation"(勧告)の役割を果たすのかという根本的な疑問が呈
される場面がありました。
一方、ITU-TのようなIETF以外の会議で、ネットワークのセキュリティがどの
ように捉えられているのかを知る機会になるという指摘もありました。IETFは、
IETFとして議論した結果の"仕様"を決めるミーティングなので、必ずしもIETF
における視点だけが正しいわけではないという、控えめな見方があります。
IETFにおけるWG活動とドキュメント活動は長年のノウハウもあって、とても洗
練されていますが、別の技術標準の状況を知ることによって、また新たな視点
を取り込むことができると考えることができます。
"Unicode Security Considerations(Unicode Technical Report #36)"では、
Unicodeの利用によって起こる問題点の紹介などが行われました。例えば文字
の記述方向が異なる言語を組み合わせてIDN(Internationalized Domain
Names)を使ってURLを記述すると、URLの途中で右方向に読んだり左方向に読ん
だりという、使いづらい状況ができてしまいます。このような問題に対して、
User Agent(Webブラウザ等)に必要になることなどをまとめたのがUnicode
Technical Report #36です。このドキュメントは下のWebページで読むことが
できます。
□Unicode Technical Report #36
Unicode Security Considerations
http://www.unicode.org/reports/tr36/
〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜〜
わからない用語については、【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.286 【臨時号】
＠ 発行 社団法人 日本ネットワークインフォメーションセンター
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), 2005 Japan Network Information Center