ニュースレターNo.43/2009年11月発行

セキュリティ関連WG報告

第75回のIETFは、スウェーデンのストックホルムにて、2009年7月26日から31日まで開催されました。今回の参加者は、50ヶ国1,084人でした。これは、直近のヨーロッパで開催された第72回IETF(48ヶ国1,183人)と比較すると、2ヶ国増99人減という結果です。

毎回IETFでは、セキュリティに関連した話題が多くのWG(今回は15セッション)で議論されており、幅広い領域のセッションが開催されているため、全てのセッションの内容を把握することが困難な状況です。

そこで本稿では、会期中に議論されたSecurityに関連したトピックスのうち、IPv6に特化した内容を議論するWGでの話題を中心に紹介します。

krb WG(Kerberos WG)

krb WGは、認証方式の一つである、マサチューセッツ工科大学(MIT)が開発したKerberosについて、新規仕様や実装のための検討を行うWGです。

今回のミーティングは、2009年7月31日に開催され、参加者は30人程度でした。最初にチェアから、WG文書のステータスおよび本ミーティングのアジェンダについて報告がありました。

写真:Routing Registry Training Course — IETF会場近くのホテルで行われたRIPE NCCのRouting Registry Training Course

今回のミーティングで発表された提案は、次の通りです。

Preauth framework
Kerberos hash Update
DHCPv6 Kerberos option
IA-Kerb Update

上記の四つの中から報告者が注目した提案について簡単にご紹介します。

「Kerberos hash Update」は、MIT Kerberos ConsortiumのTom Yu氏により発表が行われました。

概要としては、Kerberosで使用しているハッシュ関数に対する危殆化対策(暗号技術の世代交代)として、現在主に利用されているハッシュ関数から、より安全とされているSHA-2へ移行しようという提案でした。危殆化の流れとして、ハッシュ関数だけではなく共通鍵アルゴリズムについても、今後検討が行われるのではないかと予想されます。

また、今回のkrb WGでは「DHCPv6 Kerberos option」について、横河電機株式会社の坂根昌一氏から提案があり、ミーティングにおいて活発な議論が行われていました。

□krb WG: http://www.ietf.org/dyn/wg/charter/krb-wg-charter.html
□第75回IETF krb WGのアジェンダ: http://www3.ietf.org/proceedings/75/agenda/krb-wg.txt

tls WG(Transport Layer Security WG)

tls WGは、インターネット上で情報を暗号化して送受信するためのプロトコルであるTLS(Transport Layer Security)について、仕様の拡張や新規Cipher suiteの検討を行うWGです。

今回のミーティングは、2009年7月31日に開催され、参加者は40人程度でした。本ミーティングにおいて、冒頭でチェアから、WG文書のステータスおよびアジェンダについて報告がありました。

今回のミーティングで発表された提案は、以下の通りです。

TLS Cached Info
DTLS Heartbeat
TLS -IBE
XMPP TLS Multiplexing

上記の四つの中から、報告者が注目した提案について簡単にご紹介します。

「TLS -IBE」は、Huawei Symantec Technologies社のMin Huang氏により、発表が行われました。

IBEとはID Based Encryptionの略であり、近年、暗号業界で話題になっている基本的な暗号技術です。この提案は、IBEを利用してTLS通信を行おうというものでした。ミーティング会場では参加者同士の議論が活発に行われ、IBEをTLS通信に適用した時の課題等が多く洗い出されました。

また、第72回IETFで提案された、国産暗号のCamellia ciphersuite(rfc4132bis)について、IETF期間中にInternet-Draftのステータスが、ID-ExistからAD Evaluationに変更されました。

□tls WG: http://www.ietf.org/dyn/wg/charter/tls-charter.html
□第75回IETF tls WGのアジェンダ: http://www3.ietf.org/proceedings/75/agenda/tls.txt

(NTTソフトウェア株式会社菅野哲)

SIDR WG(Secure Inter-Domain Routing WG)

SIDR WGは、インターネットにおける経路制御のセキュリティ・アーキテクチャについて検討を行っているWGです。まだRFCになったドキュメントはなく、Internet-Draftの議論が続いています。第75回IETFでは、5日目(7月30日)の午前9時から2時間半ほどミーティングが行われました。約80名が参加しました。

更新された五つのInternet-Draftのうち四つについては、多くの議論はありませんでした。最後の一つについては、二つのプレゼンテーションがありました。

－ ROA Format - draft-ietf-sidr-roa-format-04: IPアドレスのprefixに対する経路広告元を指定(authorize)するデータ、Route Origination Authorization(ROA)の形式を定めるものです。

会場での確認の結果、ROAにおける署名アルゴリズムはdraftietf-sidr-cp-06ではなく、本ドキュメントにまとめて記述されることになりました。

－ RPKI Architecture - draft-ietf-sidr-arch-07: リソースPKI(RPKI)の全体像を述べたものです。

会場では、収束していない論点はなく著者としても書き足りないことはないことが説明され、WGメンバーにレビューが依頼されました。

－ Certificate Policy - draft-ietf-sidr-cp-06: リソース証明書の発行要件やCPSについて書かれています。

会場では、RFCの分類としてSTD(Internet Standards)ではなく、BCP(Best Current Practice)としてRFC化を目指すことが確認されました。RIPE NCCのAndrei氏がRIRで本ドキュメントのレビューを働きかけたため、あらためてNumber Resource Organization(NRO)に確認する必要がなくなりました。

－ RPSL with RPKI Signatures - draft-ietf-sidr-rpsl-sig-01: リソース証明書を使ってRPSLオブジェクトに電子署名を施す形式を定めるものです。

会場では、RPSLのオブジェクトに記述されたコンタクト先の情報が電子署名で担保されるわけではないなど、不明瞭な点があるという指摘がありました。Routing Policy Specification Security(RPSS)との関係を記述すべき、という指摘がAPNICのGeoff Huston氏(リモート参加)からありました。

以下は、RPKIに関するBGPルータの実装に関する二つのプレゼンテーションです。

－ BGP Protocol Geekiness: 　- http://archive.psg.com/090730.sidr-rpki.pdf
BGPルータにおけるRPKIを使ったOrigin ASの検証方式を検討した結果に関するプレゼンテーションです。

－ BGP Prefix Origin Validation: 　- draft-pmohapat-sidr-pfx-validate-01
BGPルータにおけるROAを使ったOrigin Validationの経路表への適用方法に関するプレゼンテーションです。

ルータベンダーやISPを交えてレビューが行われています。別のInternet-Draft(draft-ymbk-rpki-rtr-protocol-04)に基づいてプロトタイプの実装が行われていることなどが報告されました。WGのInternet-DraftにするかどうかはMLで議論することとなりました。

前回のIETF以降、RPKIとROAの用途を明文化するためのInternet-Draft、“Use Case”がICANNのTerry Manderson氏によって作成されました。このドキュメントはROAを使って、(BGPでいうところの)Originを検証する利用ケースを集めたものです。MLに引き続いて、BGPではOriginの検証よりもPathの検証の方が効果的ではないか、という議論がありました。しかし、SIDR WGとしては、Originの検証なしにはPathの検証に意味がないとされ、WGとしてはこれまで通りOriginの検証について取り組むことが確認されました。

最後に新たなトピックとして、BBNのStephen Kent氏が“TrustAnchor Management”についてプレゼンテーションされました。これはRPKIやROAを検証するRelying Party(RP;電子証明受け取り側)において、トラストアンカーとなる認証局の処理を工夫し、プライベートアドレスのプリフィクスやプライベートネットワークでもRPKIを使えるようにする提案です。アドレスの全域をカバーする、IANAにあたるトラストアンカーの証明書を生成し、その証明書の配下に有効な証明書を配置していくという内容となっていました。

写真:Mark Handly — Technical Plenaryで“Tussle in Cyberspace”の説明をするMark Handly

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

PKIX WGは、インターネットのためのPKI技術策定に取り組んでいるWGです。ミーティングは、4日目の7月29日(水)午後1時から1時間程行われました。参加者は30名程でした。

前回のIETF以降、RFCになったドキュメントはなく、三つのドキュメントがIESGのレビュー中です。

－ Update for RSAES-OAEP Algorithm Parameters: http://tools.ietf.org/id/draft-ietf-pkix-rfc4055-update-02.txt

Optimal Asymmetric Encryption Paddingという手法を用いたRSAの暗号化方式を証明書でサポートするためのRFC4055のアップデート版です。

－ Attribute Certificate Profile - 3281bis: http://tools.ietf.org/id/draft-ietf-pkix-3281update-05.txt

属性証明書(Attribute Certificate)を定めたRFC3281の修正版です。

策定内容に主だった変更はないものの、参照先のRFCの番号をアップデートするなどのerrata(誤字)を修正しました。

－ Traceable Anonymous Certificate: http://tools.ietf.org/id/draft-ietf-pkix-tac-04.txt

証明書のSubject欄に匿名の識別子を入れる方式で、匿名の識別子を作成する役割を証明書とは別にすることで、特殊な場合でなければ実際のIDと匿名の証明書とのマッピングができない仕組みを提案したドキュメントです。

WGで議論することになっているInternet-Draftは九つあります。このうち七つのInternet-Draftについてプレゼンテーションが行われました。

Trust Anchor Management(TAM)は、トラストアンカーである認証局証明書をオンラインで管理できるようにする仕組みで、三つのInternet-Draftが出されています。それぞれWG Last Callに近づいています。実装も行われており、WindowsのCAPIを使ったアプリケーション用のインタフェースを備えたプログラムを、SourceForgeにて公開する予定とのことです。

－本プロトコルの要件: http://tools.ietf.org/id/draft-ietf-pkix-ta-mgmt-reqs-03.txt
－トラストアンカーストア(格納場所)を転送するプロトコル: http://tools.ietf.org/id/draft-ietf-pkix-tamp-03.txt
－トラストアンカーの表現形式: http://tools.ietf.org/id/draft-ietf-pkix-ta-format-03.txt

OCSP Agility(draft-ietf-pkix-ocspagility-01)は、証明書検証用のオンラインプロトコルであるOCSPで、SHA-1以外のハッシュアルゴリズムを使えるようにする提案です。特に議論はなく、何かある場合にはMLで議論されることになりました。

Time Stamp Protocol 3161 update(draft-ietf-pkixrfc3161bis-01)は、ESSCertIDv2のオプションを追加するための書き直しを行ったものです。RFC3161bis(RFC3161の後継)とするには、用語を大幅に書き換える必要があり、それは適切ではないため、本ドキュメントは先に進めないことになりました。

Certificate Image(draft-ietf-pkix-certimage-00.txt)は、証明書の中に画像データを入れられるようにする拡張フィールドの提案です。何の証明書であるのか、発行元(Issuer)、発行対象(Subject)を示す画像データを入れることができ、画像の形式はPDF(Portable Document Format)、SVG(Scalable VectorGraphics)、PNG(Portable Network Graphics)の三つが提案されています。

最後に、毎回恒例の“Related specifications and Liaison Presentations”(関連する標準と関連団体のプレゼンテーション)として二つのプレゼンテーションが行われました。

－ Certificate Information Expression, Stefan Santesson

EUでは、PEPS(ID提供機能の代理機能)において、証明書のID情報をマッピングする仕組みがあります。認証処理ならばこれで認証情報の交換が適切にできますが、電子署名を検証する処理の場合は交換できません。ETSI(欧州電気通信標準化機構)のESI(電子署名および基盤に関する技術評議委員会)で、証明書にID情報を含める提案が承認されたため、テクニカルレポートの作成を2009年秋に開始予定です。

－ Local Management of Trust Anchor for RPKI, Steve Kent

SIDR WGでも提案されている、RPKIのためのRelying Partyにおけるトラストアンカーの処理方式です。全ての範囲が入ったIANAのリソース証明書に代わるRPの証明書を作る方式が提案されています。

会場では、BGPを使った相互接続に関係して、RP毎に証明書のツリーが変わってしまい、有効とみなされるプリフィクスが異なる可能性がある、といった懸念が出ていました。

5日目のTechnical Plenaryで行われたIRTF報告で、PublicKey Next-Generation Research Group (PKNG)という新しいリサーチグループが設置されたことが報告されました。PKIXに代わる公開鍵暗号を使った新たな公開鍵サービスを検討しており、証明書フォーマットやセマンティクスを検討しているようです。チェアは、古参で、セキュリティエリアのWGで鋭い洞察力を発揮しているPaul Hoffman氏です。どのような議論が行われていくのかが楽しみです。