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

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

ロゴ:JPNIC

WHOIS 検索 サイト内検索 WHOISとは? JPNIC WHOIS Gateway
WHOIS検索 サイト内検索
===================================
    __
    /P▲          ◆ JPNIC News & Views vol.382【臨時号】2006.8.17 ◆
  _/NIC
===================================
---------- PR --------------------------------------------------------
◆ 日本語ドメイン名に対応したIE7が急速に広まる!?
   年内に正式版リリース!しかも6ヶ月後には自動更新開始予定!
   指定事業者による日本語JPドメイン名のキャンペーンも増加中
   キャンペーン情報等は 日本語.jp( http://nihongojp.jp ) の新着情報で
                               株式会社日本レジストリサービス(JPRS) ◆
----------------------------------------------------------------------
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ News & Views vol.382 です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

本号では、vol.376、vol.377、vol379、vol381に引き続き、第66回IETFのレポー
ト[第5弾] セキュリティ関連WGの動向についてお届けします。

□第66回IETF報告 特集
○[第1弾] 全体会議報告 (vol.376)
   http://www.nic.ad.jp/ja/mailmagazine/backnumber/2006/vol376.html
○[第2弾] DNS関連WG報告 (vol.377)
   http://www.nic.ad.jp/ja/mailmagazine/backnumber/2006/vol377.html
○[第3弾] IPv6関連WG報告 (vol.379)
   http://www.nic.ad.jp/ja/mailmagazine/backnumber/2006/vol379.html
○[第4弾] ENUM関連WG報告 (vol.381)
   http://www.nic.ad.jp/ja/mailmagazine/backnumber/2006/vol381.html

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第66回IETF報告 [第5弾]  セキュリティ関連WG報告
                                                 JPNIC 技術部 木村泰司
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

第66回IETFでは、セキュリティエリアのセッションが18行われました。BoFは
Network Endpoint Assesment BoF(*1)とHandover and Application Keying
and Pre-authentication BoF(*2)の2つでした。またPKIX WGと前回WGになった
SIDR WGとのジョイントセッションが行われました。

本稿では、PKIX WGとSIDR WG、及びインターネットの経路制御における電子証
明書の動向について報告致します。

◆SIDR WG (Secure Inter-Domain Routing WG)

第64回および第65回のIETFでBoFが開かれていたSIDRが、2006年4月18日にWGに
なりました。今回のIETFで行われるミーティングがWGとして行われる初めての
ミーティングです。

SIDRはSecure Inter-Domain Routingの略で、ネットワーク・ドメイン間の経
路制御におけるセキュリティメカニズムを開発することを目標としています。
RPSEC WGで議論されてきたセキュリティの要件にのっとり、利用や展開
(deployment)を含めて検討を行います。

今回のWGセッションでは、IPアドレスやAS番号が入った"リソース証明書"の実
験を行っているAPNICのGeoff Huston、George Michaelson両氏による、2つの
ドキュメントプレゼンテーションが行われました。また経路制御プロトコルを
より安全に利用するためのトランスポート層(TCP)のセキュリティに関するド
キュメントプレゼンテーションが行われました。
リソース証明書に関するプレゼンテーションは以下の2つです。

  "A Profile for X.509 PKIX Resource Certificates"
  draft-huston-sidr-res-certs-01.txt
  IPアドレスとAS番号の利用権を検証するための電子証明書のプロファイル
    を定めたもの。この証明書はリソース証明書と呼ばれる。

  "A Profile for Resource Certificate Repository Structure"
  draft-huston-sidr-repos-struct-00.txt
  リソース証明書を保持するリポジトリの構造を定めたもの。Subject Key 
  Identifier(SKI)やAuthority Key Identifier(AKI)を使って電子証明書を
  検索できるようにするため、Subjectにそれらのハッシュ値を含めた名前
    を使う。

APNICではこれらの仕様を前提として実装を進めているようです。主な論点は
リソース証明書のSubjectとトラストポイント(信頼点)の2つです。SKIのハッ
シュ値をSubjectに含めるのは、リソース証明書の証明書パスにおける一意性
を維持することを意図しています。本来、Subjectは電子証明書の発行対象の
識別子を入れるために使われますが、証明書を識別しやすくするために特殊な
使われ方がされているようです。

またリソース証明書に想定されるツリー構造の頂点をどうするか、トラストポ
イントをどう想定するか、といった点については議論が収束していない様子で
す。IPアドレスとAS番号の管理を行っているインターネットレジストリの構造
からすると、IANAが頂点となる認証局を運用し、RIRの認証局がその下位認証
局となって、IANAの認証局を多くの利用者がトラストポイントと位置づけるこ
とが考えられます。しかしRIRの中にはその認証局の運用可能性に疑問を持っ
ているところが多いようです。

技術の標準化の観点では、絶対的な頂点の存在よりもRelying Party(証明書検
証者)が、トラストポイントを使って必要十分なリソース証明書の検証ができ
るか、という点が重要です。そのため、頂点の認証局については、今のところ
は先に延ばせる議論ではあります。

トランスポート層のセキュリティについては以下のドキュメントに関するプレ
ゼンテーションが行われました。

  "Key Change Strategies for TCP-MD5"
  draft-bellovin-keyroll2385-00.txt
  BGPのような長期的なTCPセッションにおける、MD5オプションのための 
   鍵変更の方式です。既存の方式と互換性がありながら、片方のエンドだけ
    で実施できるようになっています。

  "Authentication for TCP-based Routing and Management Protocols"
  draft-bonica-tcp-auth-04.txt
  MD5に代わる、より強度の高い暗号アルゴリズムを使ったTCPオプション 
   の取り決めです。

  "Automated key selection extension for the TCP Authentication Option"
  draft-weis-tcp-auth-auto-ks-01.txt
  TCPのExtended Authenticationオプションのためのセッションキーの
  交換方式と、そのためのノンス(暗号文を変化させるためのランダム値)を
  使ったメッセージ認証の方式の取り決めです。

  "The TCP Simple Authentication Option"
  draft-touch-tcpm-tcp-simple-auth-01.txt 
  MD5オプションに代わる認証のためのTCPオプションです。IPsecのように
  別途の SA (Security Association)を確立する方式を提案しています。

TCPにおける認証方式の改善は、強度と運用の容易さ、既存のTCPとの互換性と
いった様々な要素が関係しています。ネットワーク・セキュリティの大家であ
るSteven Bellovin氏を中心に慎重に検討が進められているようです。

◆PKIX (Public-Key Infrastructure (X.509)) WG

PKIX WGは7月10日(月)の17時40分~21時に行われました。18時50分からはSIDR
WGとのジョイントミーティング(後述)です。約50名の参加がありました。

第65回IETF(2006年3月)以降、AC Policies Extension(RFC4476)とGOST
Cryptographic Algorithms(RFC4491)の2つがRFCになりました。RFC3280の部分
的な変更であるDirectoryStringのUTF-8の処理に関するドキュメントは、
RFC3280の改定作業とは独立して、RFC Editor's queueに入っており、RFCにな
る直前の段階にあります。

SIM(Subject Identification Method)、SCVP(Server-based Certificate
Validation Protocol)、Lightweight OCSPの3つがWG Last Callを終え、Area
Directorのレビュー中です(8月17日現在、SIMはIESGレビューを終え、RFC
Editor's queueに入っています)。SCVPのSは以前Simpleでしたが、
Server-basedに変わりました。

SIMは元々韓国のJong-Wook氏から出されたドキュメントでしたが、Tim Polk氏
が引き継ぎ、現在IESGからのコメントに対応中です。SCVPは27版になり、いよ
いよIESGによるレビューの段階に入りました。前回のIETF以降、編集上の変更
や定義づけに関する追記といった比較的軽微な変更がなされた模様です。

Lightweight OCSPは、オンラインで証明書検証処理を依頼するためのプロトコ
ルのOCSPを改良したものです。大量のやりとりに適するよう、メッセージサイ
ズを小さくしたり、返答結果のキャッシングを行うことができるようになって
います。

X.509v3形式の電子証明書の基本的なプロファイルを記述したRFC3280の後継と
なるドキュメント、通称3280bisについてはnameConstraintsフィールドのエン
コーディングに関する追記が行われています。またCRL Distribution Points 
やAIA(Authority Information Access)/SIA(Subject Information Access)と
いったフィールドで、httpsを使用することに関する注意事項の追記が行われ
ました。電子証明書の検証のためにhttpsが使われると、その処理のために更
に電子証明書の検証が必要になり、場合によっては本来の検証処理が終わらな
かったり、状態が複雑になりすぎたりします。これを避けるための注意喚起の
ための追記が行われたようです。他にも議論が収束していない点が残っていま
すが、部分的にドキュメントを分割して、3280bisの対象外とするなどして整
理を進める模様です。

◆Joint PKIX/SIDR Meeting

PKIX WGの2セッション目に、PKIX WGとSIDR WGのジョイントミーティングが行
われました。内容はSecure BGP(S-BGP)の提案者であるStephen Kent氏による
"A PKI for Internet Address Space"というプレゼンテーションです。PKIX
WGの参加者に加えて、SIDR WGのチェアであるSandra Murphy氏らが加わった形
で意見交換が行われました。

Stephen Kent氏は、IPアドレスとAS番号の使用権を示す電子証明書を使ってイ
ンターネットのルーティングプロトコルであるBGP(Border Gateway Protocol) 
の安全性の向上を図る仕組み"S-BGP"の提案をしています。これは、RFC3779に
記述されている電子証明書の拡張フィールドを使ってIPアドレスの割り振りと
AS番号の割り当てを証明し、経路情報として広告されたprefixが、所有者(利
用者)によって正しく使われていることを検証できるようにする仕組みです。
インターネットにおける経路情報の中で、誤ったIPアドレスとAS番号が使われ
ると、経路ハイジャックと呼ばれる大規模な利用不能攻撃が可能になります。
S-BGPがうまく利用されると、このような攻撃を未然に防ぐことができると考
えられています。

このセッションでは、RIRが運営する認証局を使ってこの電子証明書の発行を
行うモデルが紹介されました。電子証明書の入手にはrsyncが使われることと
なっています。

   □ rsync
     http://rsync.samba.org/

ここでもトラストポイントに関する議論も行われました。APNICやRIPE NCCか
らの参加者の間では、RIRが運用する認証局がトラストポイントとなることを
想定して議論が行われています。しかし本来、トラストポイントとはプロトコ
ルの提案者が決めるものではなく、電子証明書の検証を行う者(Relying
Party)が決めるものです。Address Space PKIの構造に含まれるとされるJPNIC 
でも、トラストポイントとして利用されることを想定した認証局を運用してい
ることから、筆者はRIRの認証局だけがトラストポイントになるわけではない
ことを会場で確認しました。これは、例えば日本国内のISPの間で経路情報の
交換を行う場合に、APNICやRIPE NCCの認証局を利用する必要はないと考えら
れるためです。

会場では、この他に割り振りを受けたアドレスブロックを使ったまま地域を移
動し、割り振り元を別のRIRに変更するケースの扱い方などについて議論が行
われました。

               ◇                ◇                ◇

IETFの会場でAPNICの方々と情報交換することでわかってきたことですが、
APNICでは、Address Space PKIに関する開発プロジェクトが2006年末の終了を
目標として進んでいるようです。既にIPアドレスとAS番号が入った電子証明書
の発行やリポジトリの設置が実験的に行われていました。今後、MyAPNICとい
う申請業務用のWebシステムに組み込まれることが考えられており、実用化に
向けた活動が今後も引き続いて行われていくことが考えられます。

(*1) Network Endpoint Assessment (NEA) (Porposed NEA WG Charter)
    http://www3.ietf.org/proceedings/06jul/agenda/nea.txt
    NEAは、ネットワークに接続するエンドポイント(ホスト等)のOSやパッチ
     の適用状況に関する情報(posture)を交換し、エンドポイントの安全性が
     確認された場合にのみ会社のネットワークへの接続を許可するといった
     仕組み構築の為に利用できます。

(*2) Handover and Application Keying and Pre-authentication (HOAKEY)
    モバイルネットワークにおけるハンドオーバーの為の、認証情報を交換
     する仕組みに関するBoFです。第65回IETFに続いて2回目です。


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

 @ 発行         社団法人 日本ネットワークインフォメーションセンター
                 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), 2006 Japan Network Information Center

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

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

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

ロゴ:JPNIC

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