ニュースレターNo.41/2009年3月発行

セキュリティ関連WG報告

本稿では、インターネット経路制御のセキュリティ・アーキテクチャ策定に取り組んでいるSIDR WG（Secure Inter-Domain Routing WG）と、認証基盤技術であるX.509を使って、インターネットで使われるPKI技術の策定に取り組んでいるPKIX WG（Public-Key Infrastructure（X.509））について報告いたします。

SIDR WG（Secure Inter-Domain Routing WG）

SIDR WGは、インターネットにおけるドメイン間（AS間）の経路制御に関して、セキュリティ・アーキテクチャの検討を行っているWGです。第73回IETFでは、2日目（11/17）の13:10から2時間ほどミーティングが開かれ、約50名の方が参加しました。

SIDR WGはまだRFCを出しておらず、Internet-Draft（以下、I-D）が10あります。今回、さらに二つのI-Dが出されました。

□BGP Prefix Origin Validation
　 http://tools.ietf.org/html/draft-pmohapat-sidr-pfx-validate-00

RPKI（Resource PKI）を背景に、BGP UPDATEメッセージの検証における有効性を提案しているドキュメントです。大手ベンダーであるCisco社やJuniper社に加え、日本のISPであるNTT Communications社やIIJ 社からの参加者が議論に参加しています。

□Securing RPSL Objects with RPKI Signatures
　 http://tools.ietf.org/html/draft-kisteleki-sidr-rpsl-sig-00

WHOISデータベースの記述言語であるRPSL（Routing Policy Specification Language）に、電子署名を加える提案です。電子署名のためにリソース証明書が使われます。RPSLを策定しているRIPE NCCの、スタッフによって提案されています。

ミーティングでは、アジェンダに従って、三つのWGドキュメントについて議論されました。

□Secure Inter-Domain Routing WG（sidr）（アジェンダ）
　 http://www.ietf.org/proceedings/08nov/agenda/sidr.html

SIDR WGにおける議論を私なりに分類すると、以下の三つに分けられます。この分類を使って、今回のSIDR WGで議論が行われた三つのI-Dを紹介したいと思います。

a. RPKIのアーキテクチャ

全体的なアーキテクチャで、このPKIの目的や信頼の構造に関する議論です。

b. RPKIの認証局

リソース証明書を発行する認証局に関する議論で、IPアドレスの管理業務との関係や、レジストリ同士の連携も関連します。

c. ROA（Route Origination Authorization）を使ったprefixの検証

リソース証明書に基づいて発行されるROAと、経路情報の関係を明確化し、目的とするセキュリティを担保するための議論です。

最初のアジェンダである“RPKI Architecture”は、aに分類されます。WGでは、経路フィルタやトラストアンカーについて、ドキュメントにどう記述するかが議論されました。最終的にどちらも具体化せずに、一般化した記述にすることになりました。五つのRIRがトラストアンカーになることを前提とするような記述は、避けられることになりました。

□RPKI Architecture
　 http://tools.ietf.org/html/draft-ietf-sidr-arch-04

二つ目の“ ROA Format”は、cに分けられます。BGPUPDATEのprefixを検査する段階で、ROA（RouteOrigination Authorization）とのオーバーラップをどのように扱うかについて議論されました。その結果、現行の記述は変更しないことになりました。

□ROA Format
　 http://tools.ietf.org/html/draft-ietf-sidr-roa-format-04

三つ目の“Certificate Policy”は、bに関連したドキュメントです。リソース証明書を発行するRPKIのCertificate Policyについて提案しています。主にRIRにコメントが求められていますが、IETFの場であることに加えて、ドキュメントの内容がビジネス判断を伴うものであったりする理由で、なかなか十分なコメントを得られていません。

□Certificate Policy
　 http://tools.ietf.org/html/draft-ietf-sidr-cp-04

WGのメーリングリストでは、bogon prefix^※1を示すROAに関する議論などが行われています。

3年前から始まったSIDR WGですが、目標としているアーキテクチャに対して、徐々にドキュメントが揃ってきた印象があります。これも2007年度にAPNIC、ARIN、RIPE NCCの三つのRIRでプロトタイプシステムが作られ、上記のbが、現実味を帯びてきたからかもしれません。

ただし、ROAとリソース証明書をBGPスピーカーがどのように経路制御に反映するのか、という大きな課題が残っています。ベンダーやISPを交えた議論が、今後も必要とされていくと思われます。

PKIX WG（Public-Key Infrastructure（X.509）

PKIX WGは、X.509を使ってインターネットで使われる、PKI技術の策定に取り組んでいるWGです。PKIX WGは新たなドキュメントを扱わず、近々クローズすると宣言されたことが4年程前にありましたが、暗号アルゴリズムの移行や、TAM（Trust Anchor Management）など、WGの活動項目が減る様子はありません。ミーティングは11/21（金）の15:20から2時間行われました。50名程の参加者がありました。

前回の第71回IETF以降、RFCになったドキュメントは無く、二つのドキュメントがIESGのレビューを受けている状態です。ECC Subject Public Key Informationは、2008年11月24日にレビュー状態からAD（Area Director）の最終判断を待つ状態になりました。

− ECC Subject Public Key Information

http://tools.ietf.org/html/draft-ietf-pkix-ecc-subpubkeyinfo-10

証明書にECC（Elliptic Curve Cryptography - 楕円暗号）の鍵を入れるためのパラメーターを定義しています。

− RFC4055 update

http://tools.ietf.org/html/draft-ietf-pkix-rfc4055-update-01

証明書でRSAES-OAEP（RSA Encryption Scheme - Optimal Asymmetric Encryption Padding）を使うため、暗号アルゴリズムを定義しているRFC4055を更新するための変更点を述べています。

PKIX WGには、WGで議論することになっているI-Dが11あります。このうち9のI-Dについて議論が行われました。その他に“関連する仕様やリエゾンのプレゼンテーション”として、二つのプレゼンテーションがありました。主だったドキュメントの動向を報告します。

− Other-certs extension

http://tools.ietf.org/html/draft-ietf-pkix-other-certs-01

単一のEE（End Entity - 証明書の発行対象）に発行された、複数の証明書の、証明書同士を関連付ける証明書拡張です。若干の修正の後、WG Last Callにかけられることになりました。

− PKI resource Query Protocol

http://tools.ietf.org/html/draft-ietf-pkix-prqp-01　^※2

認証局証明書とリソースID（OCSP、LDAP、CRLなど）を使って、アクセスするためのURIを問い合わせるプロトコルです。問い合わせる先のRQA（Resource Query Authority）のアドレスをクライアントにどう伝えるのか、といった議論がありました。PRQPを実装しているプロジェクトがあります。

□OpenCA Research Labs - LibPRQP Project
　 http://www.openca.org/projects/prqpd

− Attribute Certificate Profile Update

http://tools.ietf.org/html/draft-ietf-pkix-3281update-01

属性証明書を策定したRFC3281の、Errata（修正）対応です。数年来のErrataを反映し、新たなRFCとして更新しようとしています。

− Traceable Anonymous Certificates

http://tools.ietf.org/html/draft-ietf-pkix-tac-01

名称（CN）にハッシュ値を記述し、匿名性を担保しつつ、後でEEと証明書の関係を追跡できるようにした証明書です。韓国のKISA（Korea Information SecurityAgency:韓国情報保護振興院）の方々による提案です。

“関連する仕様やリエゾンのプレゼンテーション”として、OCSPにおけるハッシュアルゴリズムの移行に関する状況と、タイムスタンププロトコルに関するRFCの更新について議論が行われました。

− OCSP Algorithm Agility

http://tools.ietf.org/html/draft-hallambaker-ocspagility-02

オンラインで証明書の有効性を問い合わせるOCSP（Online Certificate Status Protocol）の、レスポンスの中で使われるアルゴリズムの移行に関する議論です。

返答する側（レスポンダー）が、問い合わせた側（リクエスター）のサポートしていない署名アルゴリズムを使ってしまうことを避けるため、アルゴリズムを選ぶ方法について議論が行われました。WGの活動項目としてMLで意見が求められることになりましたが、この議論は1年程前にも行われたことがあり、進んでいない様子がうかがわれます。

− Time-Stamp Protocol update - 3161bis

ETSIのTC ESI（Technical Committee ElectronicSignature & Infrastructure）の要望を受けて、更新するための活動が行われています。WGの活動項目に入れるかどうかの議論が行われ、ドキュメントに含まれる八つの特許についての記述を、削除することの賛否が問われました。その結果、削除するべきであるという方向になりました。

先日行われたInternet Week 2008でも、「次世代暗号アルゴリズムへの移行〜暗号の2010年問題にどう対応すべきか〜」というセッションがありました^※3。利用する暗号アルゴリズムを切り替えるには、プロトコルとして切り替えが可能になっていなければなりません。また、並行して、認証局や認証システムの対応も必要になってきます。これらの状況を踏まえ、安全性を維持しつつスムーズに移行できるよう、2009年も引き続き議論を進められればと思います。

（JPNIC 技術部/インターネット推進部 木村泰司）

※1 bogon prefix

割り振られていないIPアドレスなど、本来はインターネットの経路表に載るはずの無いprefixのこと。

※2 PKI Resource Query Protocol（PRQP）

2008年12月8日に修正版の“-02”になりました。
http://tools.ietf.org/html/draft-ietf-pkix-prqp-02

※3次世代暗号アルゴリズムへの移行〜暗号の2010年問題にどう対応すべきか〜

https://internetweek.smartseminar.jp/public/session/view/40