ニュースレターNo.34/2006年11月発行
セキュリティ関連WG報告
第66回IETFでは、セキュリティエリアのセッションが18行われました。BoFはNetwork Endpoint Assessment BoF※3とHandover and Application Keyingand Pre-authentication BoF※4の二つでした。また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の略で、ネットワーク・ドメイン間の経路制御におけるセキュリティメカニズムを開発することを目標としています。具体的には、暗号技術を使ってBGP(Border Gateway Protocol)メッセージの認証を行うための仕組みの実現や、BGPで使われるTCPコネクションを保護するための仕組みの改良に取り組んでいます。
RPSEC WGで議論されてきたセキュリティの要件にのっとり、利用や展開(deployment)を含めて検討を行います。
今回のWGセッションでは、はじめにIPアドレスやAS番号が入った“リソース証明書”の実験を行っているAPNICのGeoff Huston、George Michaelson両氏による、二つのドキュメントプレゼンテーションが行われました。また経路制御プロトコルをより安全に利用するためのトランスポート層(TCP)のセキュリティに関するドキュメントプレゼンテーションが行われました。
リソース証明書に関するプレゼンテーションは以下の二つです。
- “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ではRFC化に先立ち、これらの仕様を前提として実装を進めているようです。主な論点は、リソース証明書のSubjectとトラストポイント(信頼点)の二つです。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)の二つがRFCになりました。RFC3280の部分的な変更であるDirectoryStringのUTF-8の処理に関するドキュメントは、RFC3280の改定作業とは独立して、RFC Editor's queueに入っており、RFCになる直前の段階にあります。(2006年8月、RFC4630となりました)
SIM(Subject Identification Method)、SCVP(Server-based Certificate Validation Protocol)、Lightweight OCSPの三つがWG Last Callを終え、Area Directorのレビュー中です(9月14日現在、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の安全性の向上を図る仕組み“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システムに組み込まれることが考えられており、実用化に向けた活動が今後も引き続いて行われていくことが考えられます。
(JPNIC 技術部 木村泰司)
- ※3 Network Endpoint Assessment (NEA) (Proposed NEA WG Charter)
-
http://www3.ietf.org/proceedings/06jul/agenda/nea.txt
NEAは、ネットワークに接続するエンドポイント(ホスト等)のOSやパッチの適用状況に関する情報(posture)を交換し、エンドポイントの安全性が確認された場合にのみ会社のネットワークへの接続を許可するといった仕組み構築のために利用できます。 - ※4 Handover and Application Keying and Pre-authentication (HOAKEY)
- モバイルネットワークにおけるハンドオーバーのための、認証情報を交換する仕組みに関するBoFです。第65回IETFに続いて2回目です。
