＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
    __
    /Ｐ▲           ◆ JPNIC News & Views vol.250【臨時号】2005.4.1 ◆
  _/ＮＩＣ
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ News & Views vol.250 です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

本号ではvol.249に引き続き、第62回IETFのレポートの<後編>として、DNS関連
WG報告とセキュリティ関連WG報告をお届けします。


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第62回IETF報告 <後編>
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

……………………………………………………………………………………………
1. DNS関連WG報告
                             JPNIC DNS運用健全化タスクフォースメンバー
                                             東京大学 情報基盤センター
                                                              関谷勇司
……………………………………………………………………………………………

◆dnsop (Domain Name System Operations) WG

IETF62では、dnsop WGのBoFが1コマ開催されました。今回のBoFでは、メイン
となる議題は特に存在せず、多くのWGドラフトやdnsop WGに関連する個人ドラ
フトについての進捗報告と質疑応答が行われました。

毎回中心的な話題となっているDNSSEC(*1)に関しては、今回はデプロイメント
に残された課題に関する報告のみ行われました。鍵更新の手順や、秘密鍵と署
名鍵の有効期限をどの程度に設定すればうまく運用できるか、といった点がま
だ不確定であるという報告がなされました。また、最後にDNSSECのデプロイメ
ントに関して集中的に議論を行っている、
http://www.dnssec-deployment.org/というプロジェクトも紹介されました。
DNSSECのデプロイメントに関する深い議論は、このプロジェクトにて行われて
いるようです。

他には、DNSにてグローバルに公開するゾーンには登録すべきではない情報を
提案したドラフトである、draft-durand-dnsop-dont-publish-00の発表があり
ました。例としては、IPv6 のサイトローカルアドレスやユニークローカルな
IPv6ユニキャストアドレスといったものはグローバルゾーンに登録すべきでは
ない、といった提案がなされていました。このドラフトに関しては、会場の賛
同が得られ、WGドラフトとなることが決定しました。

□dnsop WG
http://www.ietf.org/html.charters/dnsop-charter.html

□第62回 IETF dnsop WG のアジェンダ
http://www.ietf.org/ietf/05mar/dnsop.txt

◆dnsext (DNS Extensions) WG

dnsext WGのBoFでは、DNSSECに関連したプロトコルの議論が活発に行われまし
た。まず、ワイルドカードレコードがゾーン内にある場合のDNSSECによる署名
方法に関して述べたdraft-ietf-dnsext-wcard-clarify-05に関して議論がなさ
れました。また、ワイルドカードレコードというものの定義から始まり、
DNSSECにて署名された場合に、それは有効署名をもったレコードとして扱われ
るかどうかという議論もなされました。さらに、ワイルドカードレコードに対
してDNSSECの署名検証を求められた場合、NXDOMAINを返答するのか、もしくは
エラーは返さないのか、といった議論が行われました。結論はまだ出ず、引き
続き議論が行われていくことになりました。また、IETFの直前にSHA-1暗号ア
ルゴリズムの衝突をねらった攻撃に関する発表があったため、この攻撃によっ
てDNSSECが受ける影響に関する報告がありました。結論としてはほとんど影響
はない、ということでした。さらに、DNSSEC にて利用されるNSECというレコー
ドの弱点を改善すべく、NSEC3やNSECεという新たなレコードの仕様に関する
議論も行われました。総じて、dnsext WGは前回と同様、DNSSECに関する議論
に終始していました。

□dnsext WG
http://www.ietf.org/html.charters/dnsext-charter.html

□第62回 IETF dnsext WG のアジェンダ
http://www.ietf.org/ietf/05mar/dnsext.txt

(*1) DNSSEC：http://www.nic.ad.jp/ja/tech/glos-ah.html#01-DNSSEC


……………………………………………………………………………………………
2. セキュリティ関連WG報告
                        JPNIC CAとアプリケーション専門家チームメンバー
                                       富士ゼロックス株式会社　稲田 龍
……………………………………………………………………………………………

今回のIETFでは、定例となっていた日曜日のSecurity Tutorialは行われず、
代わりにRouting, Bridging and Switching: A Tutorialが開催されました。
IETFのスタンスとして、セキュリティを軽視することはありませんが、すでに
何回もSecurityが行われており、一応のレベルまで意識が高まったという判断
ではないかと思われます。

◆pki4ipsec (Profiling Use of PKI in IPSEC) WG

pki4ipsecは、IPsecにおけるPKIのプロファイルを作成することを目的とした
WGです。3月7日の15：30～17：30に行われ、約30人の参加者がありました。

Sean Turner氏より、Chris Bonatti氏との中間ミーティングの結果を含めた報
告が行われました。この中で、認証トークンとしてUTF8による国際化を行うこ
とが合意されことが報告されました。また、認証パス構築については、AIA拡
張やCRLDP拡張などを使う方法が検討されているとの報告がありました。また、
Jim Schaad氏より、「CMC(Certificate Management Messages over CMS)using
CMS(Cryptographic Message Syntax)」(CMSを利用する証明書管理プロトコル) 
について説明がありました。また、認証プロセスにおけるリクエスト/レスポ
ンスの内容や、証明書の更新の概念についてUpdate/Renewal/Rekeyの違いにつ
いても説明をしました。これらはEnrollment TYPEとして定義されており、議
論の結果、TYPEフィールドで用いるものではない(TYPEの値は
enrollment/renewalだけ)という結論に達しました。また、PKIの鍵生成機能に
ついて要件から削除すべきかどうかについては結論が出ず、メーリングリスト
で引き続き議論することになりました。

◆PKIX (Public-Key Infrastructure) WG

PKIX WGは、インターネットにおけるPKI(X.509)を利用するためのプロファイ
ルを定めることを目的としたWGです。3月8日の13：00～15：00に行われ
PKIX-WGは、45名ほどの参加者がいました。

▼PKIX-WGとしての発表

・Document StatusがChairであるNational Institute of Standards and
  Technology(NIST)のTim Polk氏より発表されました。Polk 氏によると5 つ
  ドキュメントがRFC Editorの元にあり、IESGにより1つのドキュメントが承
  認されました。他にもいくつかのドキュメントがIESGの承認待ちです。

・NISTのDavid Cooper氏よりSCVPの状況の説明がありました。SCVP(Simple
  Certificate Validation Protocol)のInternet-Draft(以下、I-D)は現在、
  第18版であり前回のミーティングからラフコンセンサスを得るために大幅に
  進歩しました。デフォルト検証ポリシーの部分で仕様上の不整合がありメー
  リングリスト上で議論が必要とのことです。

・NISTのDavid Cooper氏よりRFC 3280の後継であるRFC 3280bisの状況の説明
  がありました。RFC 3280bisは、第0版が予定より遅れ2月に発行されました
  (当初は昨年の12月に発行の予定)。3280bisは、ISOの標準の明確化と若干の
  修正が含まれており、証明書のSubject/Issuer等の名前に関しての国際化文
  字列の比較に関しての新しい章です。アプリケーションは、国際化文字列に
  関してどのように扱うかに関して質問が出ました。3280bisでは、パス構築/
  パス検証時に国際化文字列の比較のルールに従うことが必要であるとの回答
  を得ました。それ以外の状況に関しては未定義であり今後の議論により状況
  が変わる可能性があります。

・セコムIS研究所/NPO日本ネットワークセキュリティ協会(JNSA)の金岡明氏が
  IPA/JNSAのUTF8調査の一環として、東アジアにおける証明書のUTF8化の現状
  に関しての発表を行いました。この発表は、独立行政法人情報処理推進機構
  (IPA)/JNSAがアジアPKIフォーラムを通じて行ったものであり、アジアPKI
  フォーラムに加入している各国の証明書のUTF8の対応状況とWindows XPの証
  明書リポジトリィに格納されている認証局の証明書のUTF8への対応状況を調
  査し報告がありました。
  アンケートは9カ国に送られ、3カ国(台湾、韓国および日本)、9認証局より
  回答がありました。いずれも政府系の認証局であり、民間CAよりの回答はあ
  りませんでした。各認証局のUTF8の対応状況はいずれもUTF8を利用し、ロー
  カルキャラクタを表現できるようにしていますが、移行プランを用意してい
  るものは1局に過ぎませんでした。また、Windows XPの証明書リポジトリィ
  にある認証局は、RFC 3280で定められたUTF8Stringへの移行の期限前に発行
  した証明書を利用しており、いずれもUTF8Stringでのエンコードをしていな
  いことがわかりました。
  結論として、政府系の認証局はUTF8Stringの利用に対してのモチベーション
  はあるが、民間系の認証局は移行プランがないとUTF8Stringへの移行を行う
  リスクを許容できないこととなるようです。UTF8Stringでのエンコードした
  証明書への移行に関しての移行戦略、移行プランおよびテストケースなどを
  明確にしたInformational RFCが必要であるとの報告がありました。

・Microsoft社のStefan Santesson氏より"CRL Signer Certificates and AIA" 
  の説明がありました。第0版が前回のIETF後発行され、このドラフトに関し
  ての議論がメーリングリスト上で行われ、5つの大きな問題があることがわ
  かりました。各々の問題が適切に解決されたら新しいドラフトに反映されま
  す。推奨されるリフェラル方式の選択方式が未解決となっています。

・Soaring Hawk社のJim Schaad氏よりCRMF(Certificate Management Request
  Format)/CMCのアップデートが報告されました。CRMFは、RFC Editorに送ら
  れましたが、OID(Object Identifier)が2つ修正が必要となる模様。トラン
  スポートとしてCMCベースのものを使うドキュメントは準備ができており、
  CMCのcomplianceドキュメントももうすぐできる見通しです。CMCのアーカイ
  ブに関してのドキュメントは解決すべき問題(鍵の預託者より複数の鍵を取
  得する処理)を一つ抱えていますが、このドキュメントもすぐにWG last
  callできる状態です。

・Related Specifications & Liaison Presentations
  Open LDAPプロジェクトより"LDAP schema definitions"に関してKurt
  Zeilenga氏よりプレゼンテーションがありました。このI-Dは、個人のI-Dと
  して出されたものであり、PKIX-WGに対してコメントとレビュー依頼があっ
  たものです。このドキュメントは、LDAPBIS WGで行われているLDAP TSと同
  時に出される予定です。

・Tumbleweed社のJohn Hine氏より"OCSP Data Interchange Format"の発表が
  ありました。このプレゼンテーションは、OCSPサーバ間で情報を交換するた
  めのフォーマットを提案したもので個人的なI-Dとして発行されました。こ
  のドラフトを書いたことで明確になった問題点に関してPKIX-WGと共同で行
  いたいということでした。


◆eap (Extensible Authentication Protocol) WG

参加者は80名くらいで100席ほどの部屋はほぼ満員であり、数名が後ろで立っ
てる状態で盛況でした。
EAP Key Management Framework(draft-ietf-eap-keying-05.txt)の説明があり
いくつかの課題に対して議論されました。次に、EAP Pre-Shared Keyの説明が
あり、Light Weight MethodとPowerful Methodがあり、Light Weight Method 
は単一の共通鍵アルゴリズムを使う方式で、Powerful MethodはShared Secret、
Secure Password Based、PKIを利用してIKEv2をベースにデザインされ、
ciphersuite negotiation、variate key strength、first reconnect、active
user identity confidentialの実現を目指しているようです。


◆SAAG (Security Area Advisory Group)

3月10日 15:30～17:45に開催されました。Security Area Advisory Groupは、
Open Security Area DirectorateとされSecurity Areaの総括と全体を見通し
た議論が行われ、Security Areaの各WGやBoFの進捗報告の他、トピック的に勉
強会が開催されるので、Security Areaについて広く情報を得たい場合には有
意義な場です。今回の勉強会は以下のトピックについて取り上げられました。

    セキュリティプロトコルの評価手法の調査(AVISPA)
    OATHによるOTP認証
    MD5とSHA-1の現状(Eric Rescorla)

・EUによるAVISPA(Automated Validation of Internet Security Protocols
  and Applications)プロジェクトからは、セキュリティプロトコルの評価手
  法についての分析成果報告が行われました。この評価手法は実装に基づくも
  のではなく、仕様(Protocol description)を分析しプロトコルの脆弱性評価
  を行います。IETFで標準化したプロトコル33を評価したところ112の脆弱性
  が発見されたという報告がありました。

・OATH(OpenAuTHenticatoin.org)からOTP(One Time Password)認証の新たな提
  案が行われました。OTPそのものの優位性について説明されたため、発表後
  S/Key(RFC 2289)との違いについて質問が投げかけられました。これに対し
  てOATHの方式ではハードウェアトークンを必要としないという回答がなされ
  ました。S/Keyもハードウェアトークンを用いていないはずであり、誤解が
  あるものと思われます。

・IAB(Internet Architecture Board)メンバーのEric Rescorla氏が、MD5や
  SHA-1などのハッシュ関数の現状について報告を行いました。この話題は、
  2005年2月にSan Franciscoで開催されたRSA Conference 2005でSHA-1の脆弱
  性が報告されて以来、SAAGのメーリングリスト上で議論されてきた内容をま
  とめたものであり、ミーティング後もメーリングリストで議論が続いていま
  す。

  主に報告されている点は以下のとおりです。

  - 2の80乗の強度を持つSHA-1の強度が2の69乗へ低下していること、
  - しかしながらハッシュから原文を計算することはまだ不可能であること
  - 変更可能なビットの位置は限定されていること
  - PRF、SSL/IPsec/SSH、HMACなど認証系のプロトコルにはあまり影響がない
    こと
  - 証明書発行、タイムスタンプなどには影響があるかもしれないこと
  - 証明書では、いくつかフィールドを工夫すれば衝突攻撃を妨害できる方法
    があること

 また、今後の対応についても以下のような考察が述べられています。

  - SHA-224など現行のものよりビット数を多くした新しいハッシュ関数が必
    要となるだろう
  - アルゴリズム識別子パラメータに乱数を与えられるハッシュアルゴリズム
    が必要
  - 対症療法として、証明書はserialNumberフィールドにランダムな値を入れ
    ることが必要となる

これに対して、serialNumber以外にもvalidityやsubjectDNのいくつかのフィー
ルドを使ってランダムな値を埋め込むことは可能だろう、NISTは2010年までに
80bit以上の強度を持つアルゴリズムへ移行することを望んでいる、などのコ
メントがつけられました。


     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
       わからない用語については、【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.250 【臨時号】 

 ＠ 発行         社団法人 日本ネットワークインフォメーションセンター
                 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