HOME情報セキュリティ資料・報告書・出版物インターネットセキュリティに関する RFC65th IETF ミーティング(ダラス)インターネットセキュリティ関連情報収集の報告

本文を印刷する

情報セキュリティ

65th IETF ミーティング(ダラス)インターネットセキュリティ関連情報収集の報告

最終更新日:2006年 7月10日

独立行政法人 情報処理推進機構
セキュリティセンター
電話番号:03-5978-7501までお問い合わせください。
情報セキュリティ技術ラボラトリー

(準備中)

概要

2006年 3月19日(日曜日)から 3月24日(金曜日)まで、米国テキサス州のダラスにおいてIETF ミーティングが開催された。
主にセキュリティエリアの各セッションについて、ここに報告する。
今回、開催されたセキュリティエリアのWG の一覧は、下記のとおり。

3月20日 月曜日

3月21日 火曜日

3月22日 水曜日

3月23日 木曜日

セキュリティエリア以外にも、下記のセキュリティ関連のセッションが開催された。

Kerberos WG (krbwg)

検討課題:

  1. 文書の状況
  2. 技術的検討
  3. 計画の見直し
1. 文書の状況
  • IESGによって承認
    • - PKINIT (draft-ietf-cat-kerberos-pk-init-34.txt)
    • - PKINIT OCSP (draft-ietf-krb-wg-ocsp-for-pkinit-06.txt)
    • - Enctype Negotiation (draft-zhu-kerb-enctype-nego-04.txt)
  • 進行中
    • - PKINIT ECC (draft-zhu-pkinit-ecc-01.txt)
2. 技術的検討
  • 匿名性( draft-zhu-kerb-anon-01.txt)
  • ハッシュ関数の取替え可能性確保: SHA-256
    •  コア・プロトコルは、既にenctype 交渉をもつ。
    •  PKINITは、影響を受ける。
    •  ECCとの相性については疑問。
    •  RFC4121(Kerberos GSSAPI メカニズム)中の MD5 の利用については要修正。
  • Kerberos 拡張機能( draft-ietf-krb-wg-rfc1510ter-02.txt)
    • 言語タグと、ASN.1表記が課題
3. 計画の見直し

Long-term Archive and Notary Services WG (ltans)

検討課題:

  1. ERS に対するコメントについて
  2. LTAP についての I-D ( Blazic )
  3. Retention I-D ( Wallace )
  4. 計画の見直し
1. ERS(Evidence Record Syntax) に対するコメントについて

現行の Internet-Draft (以下、 I-D )文書バージョン 05 について、ごく僅かな修正が行われている。 WG ラストコールに向けて、バージョン 06 として準備中である。タイムスタンプに関して RFC 3161, “Time Stamp Protocol” が規定する仕様に準拠しないものについても規定した。
この仕様に基づく相互運用可能性実験が行われた。この相互運用実験は、 2月にドイツのフランホファーと OpenText の間 で行われた。現時点では ERS サンプルメッセージにおいてreducedHashtree の ASN.1 形式に誤りがあり、また暗号メカニズムについても既知の問題を抱えている。これらについては、相互運用実験においては包括されていなかった
バージョン 06 文書 ではこれらの修正の他、RFC 3161, “Time Stamp Protocol” とは異なる形式のタイムスタンプに配慮した表現が修正される予定である。

参考:
これら以外に、 XML に基づく ERS の実装があるようであり、 IBM による実装があるといわれている。(今回は不在であった。)

2. LTAP についての I-D ( Aleksej Jerman Blazic )

LTAP仕様が説明された。併せて、LTAP ( Long-term archive protocol )を利用した TAS ( Trusted Archiving Service ) のシステム構成や、必要となる AO ( Archive Object ) の定義、非同期モデルが説明された。
アーカイブデータと共にメタデータも扱う仕様となっている。このデータとメタデータの結合関係については、脅威分析を要する。
現在、LTAP ではアーカイブと確認 (ensure) のライフサイクル要件を明確化することに取り組んでおり、(ハッシュ関数や暗号化の)アルゴリズムのアジリティ(取り替え可能性)の確保については、その後に検討されることになる。

3. Retention I-D ( Wallace )

PKIアーティファクトを保管するためのディレクトリを使った仕組みとして提案された新規ドラフト文書について、説明されけた。具体的にはアーカイブに含まれる証明書や失効情報に関するものである。
これは、SCVP/ERSの仕様に類似する。両者とも証拠データと検証データを分離しようとしている。
こちらの仕様の中には、PKIX 仕様の準拠しない箇所がある。今後、ヒストリカル CRL に関して議論が進む場合、 PKIX WG との調整が必要となる。

4. 計画の見直し

WGマイルストーンが改訂されることになった。ノータリ仕様 について は、新たな知見が得られるまでは保留されることになった。
また、ひと通りの目標を達成した上で2007年 4月までに WG を閉じることになった。

Domain Keys Identified Mail WG(dkim)

IBE(UIdentitiy Base Encryption)技術に基づくセキュアメール仕様の策定を行う WG が形成された。

検討課題:月曜日

  1. 脅威分析文書(Fenton)
  2. 基本文書(Allman)

検討課題:水曜日

  1. SSP の論点(Fenton)
  2. 概要文書の導入部分について(Hansen)
  3. 提案の明確化(Otis)
  4. DKIM メッセージ Corpus(Hansen)
月曜日
1. 脅威分析文書(Fenton)

文書の更新状況について、バージョン 01 文書には、上位ドメイン攻撃等についての記述が追記された。バージョン 01 以降、選択文再生攻撃の流派についての記述を追加した。
現在、4 つの未解決課題があり、検討された。
ハッシュ衝突攻撃についても言及すべきとされた。サイド・チャネル攻撃についても加筆される。
その後、アカウンタビリティ(説明可能性)についての言及法について議論した。

2. 基本文書(Allman)

現在、24の未解決課題がある。それらを検討した。

水曜日
1. SSP(Sender Signing Practices)の論点(Fenton)

現在、ふたつの未解決課題がある。それらを検討した。

2. 概要文書の導入部分について(Hansen)
3. 提案の明確化(Otis)
4. DKIM メッセージ Corpus(Hansen)

Better than Nothing Security WG(btns)

検討課題:

  1. 文書の状況(チェア)
  2. 技術的検討
  3. 計画の見直し
1. 文書の状況(チェア)
2. 技術的検討
3. 計画の見直し

(準備中)

S/MIME Mail Security WG(smime)

検討課題:

  1. 文書の状況( Blake Ramsdell )
  2. 複数署名アルゴリズムについての検討( Blake Ramsdell )
  3. まとめ、会場からの質問等( Blake Ramsdell )
1. 文書の状況( Blake Ramsdell )

最近、RFC 4262, “X.509 Certificate Extension for Secure/Multipurpose Internet Mail Extensions (S/MIME) Capabilities” が、発行された。
CERT, CMS のために証明書の相互運用レポートが必要とされており、 MSG のために CERT が必要とされている。また ESS のためにMSG と CERT が必要とされている。
KEM技術については X9.44に関していくつか問題があり、この他に(仕様の問題ではなく)文書の完成度としていくつか難があるため、修正が必要である。

2. 複数署名アルゴリズムについての検討( Blake Ramsdell )

複数署名技術は、S/MIME に限定するものとはせず、 CMS のための仕様として策定される。
並列署名と入れ子署名の 2 種類を対象とし、署名について複数のエラーのレベルが想定されるため、 4 つに分類して検討している。

3. まとめ、会場からの質問等( Blake Ramsdell )
  • ハッシュ関数の取り替え可能性確保について

    最初に、ハッシュアルゴリズムに対する攻撃として、署名技術においては具体的にどのような手法が考えられるのか分析した結果が報告された。
    その上で、代替のハッシュアルゴリズムとしてSHA-256 への移行を検討中である [1] 。移行期間に関するガイドライン作成が課題となる。
    また、ハッシュアルゴリズムをSHA-256 とする新しい ESSCertIdEx が提案されている。

  • CMS 上への IBE の実装について

    CMS上に IBE ( Identity Based Encryption )技術を用いる仕様が I-D として執筆されつつある[2] 。これを WG Draft として扱うかどうか、について議論された。
    IPR(知的財産権)問題を抱えているとされた。ただし、 CMS に関する利用については権利所有者から利用を認める旨の声明が出されており、現在、IESG において調整中である。
    会合では明確な反対はなく、ML で反対がないか確認した後に WG Draft とすることになった。

Public Key Infrastructure (X.509) WG (pkix)

チェア:

Steve Kent と Tim Polk(本ミーティングの直後に、Tim Polk がチェアを辞することを表明した。)

概況:

 このWGについては、現存する案件を処理した後に終息させることが決定している。ただし、現存する案件と密接に絡む案件が提起された場合、扱う可能性があるとされている。

検討課題:

  1. 文書の状況( Tim Polk )
  2. PKIX プロトコルの暗号技術の取り替え可能性についての調査( Tim Polk )
  3. 他の進行中の WG 文書について
  4. PKIX WG 文書のプレゼンテーション
1. 文書の状況

WG LastCall 中の文書について

SCVP( Simple Certificate Validation Protocol )( David Cooper )

SCVPの I-D バージョン 23 が仕上がり、ラストコールがかかった。
バージョン21 以降、 いくつかの変更がなされた。アルゴリズム交換可能性確保のために、シグナル機能を規定し、RFC 3379中の複雑な表への対応と 2 つの変更を実施した。

SCVP外に 2 件、ラストコールがかかっており、間もなくかかる予定のものもある。

2. PKIX プロトコルの暗号技術の取り替え可能性についての調査( Tim Polk )

PKIXプロトコルが使っている暗号アルゴリズムを取り替え可能であるかどうか、を調査した。あるアルゴリズムから他のものに移行できるかどうか、を確認した。
証明書とCRLは、アルゴリズム中立ではあるが、アルゴリズムの交換はできない。これらのデータは、ひとつの署名アルゴリズムで作成されていて、これらを移行するためには新たに署名し直す必要がある。しかし、異なるアルゴリズムを一緒に利用する方法を明らかにした文書は、存在しない。
OCSPは、サポートしていない署名アルゴリズムに対してエラーを返す。しかし、エラーレスポンスにはどのアルゴリズムをサポートしているか、が示されていない。従って、OCSPサーバ用の証明書に拡張が必要となる可能性がある。あるいは、エラーレスポンスにサポートアルゴリズムを記載する必要がある可能性がある。LightweightOCSP においては、アルゴリズムは、 SHA-1 と明記されている。
SCVPの I-D バージョン 23 においては、細かい規定によって対応を試みている。サーバーポリシーメカニズムによる。OIDによって表現されているため、アルゴリズムの鍵長を制限する方法が無い。したがって、あるサイズ以下の鍵で生成された署名は検証しない、ということはできない。
RFC4211 が規定する CRMF においては、明示的には単一のアルゴリズムを要求することができない。ただし、Policy OIDを使って、黙示的に要求することができる。 CRMFにはアルゴリズム選択する方法が無い。これらをサポートする拡張が必要である可能性がある。
CMCとCMP(証明書管理プロトコル) において は、これらに対する強い要求はない可能性がある。しかし、既存の CA/RA に対して移行のために必要となる可能性がある。現実にこのような移行経験の欠落について議論が必要かどうかを尋ねる必要がある、とされた。

3. 他の進行中の WG 文書について

3280 後継文書について( David Cooper)

我々が感心を寄せるPKI の基本文書について、現在、 整合性を考慮している他の文書には、下記の文書が含まれる。:

  • NIST FIPS 186-3
  • RFC 3276
  • RFC 4055

バージョン01 以降、 CRL 拡張 のために AIA ( authorityInfoAccess )が 追加され、” Appndix D ( privateKeyUsagePeriod ) ”が削除された。
また、いくつかの未解決課題であった事項が解決された。CRLDistributonList の URI が規定され 、我々が、かつて問題提起した UTF-8 文字列について、関連ドラフト文書との整合性が確保された。

  • draft-ietf-pkix-cert-utf8-utf8-02.txt

Universal Principal Name について( Stefan Santesson )

新規 I-D を書き始め、メールボックスの存在は前提としないメールアドレス形式の ID を定義している。これは多くのマイクロソフト社製品において使われており、OID が割り当てられている。 PKIX 文書が必要であるか、あるいは、 informational RFC として送るかについて議論されたが、時間不足により結論を得ていない。類似仕様が既にRFC 2486, “The Network Access Identifier” において network accerss identifier として定義されている。 RFC 2486 は、 ASCII に基づくものである。

4. PKIX WG 文書のプレゼンテーション

PKI Support in Opera - Yngve Pettersen (Opera Software)

Opera社は、ブラウザユーザに対して証明書情報 ( 組織名、国名など ) を表示する。しかし、多くの認証局(以下、 CA )が発行した証明書が信頼されないものとして表示される。
Opera社と、いくつかの団体 (WebTrust 、 Microsoft 、 ABA) は、 CA が制御可能な証明書拡張検証の記載を目的として活動している。これはCA ポリシーがベンダーや発行者により同意されていることである。しかし、ブラウザの開発社は、このポリシーの元で発行された証明書を表現する方法として異なる鍵アイコンを利用している。
トラストアンカーに対するポリシーOID のマッピングは、マイクロソフト社のセキュリティアップデート、 Opera 、 WebTrust を通して発行された更新によって管理されるべきであるという趣旨であった。

Profiling Use of PKI in IPSEC WG (pki4ipsec)

検討課題:

  1. IKECERT プロファイル(Korver)
  2. マネジメント・プロトコル・プロファイル(Turner)
  3. 計画の見直し(Gregory)
1. IKECERT プロファイル(Korver)
2. マネジメント・プロトコル・プロファイル(Turner)
  • draft-ietf-pki4ipsec-mgmt-profile-rqts-04.txt

    WG Last Call 待ち。

3. 計画の見直し(Gregory)

Multicast Security WG (msec)

検討課題:

  1. 文書の状況(Ran & Lakshminath)
  2. ハッシュ関数の取り替え可能性について(Lakshminath & Ran)
  3. GDOI の更新(Brian & Sheela)
  4. GKDP(Sheela, Lakshminath, & Jing)
  5. MSEC IPsec 拡張(Brian, Dragan, & George)
  6. MIKEY の適用可能性についての検討(Steffen & Dragan)
  7. MIKEY の更新(Bob M ほか)
  8. ALC/NORM TESLA(Vincent)
  9. SRTP-EKT(David, Flemming, & Lakshminath)
1. 文書の状況(Ran & Lakshminath)

(準備中)

2. ハッシュ関数の取り替え可能性について(Lakshminath & Ran)
3. GDOI の更新(Brian & Sheela)
4. GKDP(Sheela, Lakshminath, & Jing)
5. MSEC IPsec 拡張(Brian, Dragan, & George)
6. MIKEY の適用可能性についての検討(Steffen & Dragan)
7. MIKEY の更新(Bob M ほか)
8. ALC/NORM TESLA(Vincent)
9. SRTP-EKT(David, Flemming, & Lakshminath)

IKEv2 Mobility and Multihoming WG (mobike)

検討課題:

  1. 文書の状況
  2. draft-nikander-esp-beet-mode についてのプレゼンテーション
  3. WG の将来についての検討
1. 文書の状況

(準備中)

2. draft-nikander-esp-beet-mode についてのプレゼンテーション
3. WG の将来についての検討

EAP Method Update WG(emu)

検討課題:

  1. 文書の状況
  2. EAP-TLS 後継文書について
  3. 強い「共有される秘密(shared secret)」について
1. 文書の状況

(準備中)

2. EAP-TLS 後継文書について
3. 強い「共有される秘密(shared secret)」について

Integrated Security Model for SNMP WG (isms)

検討課題:

  1. 文書の状況
  2. TMSM の未解決問題についての検討
  3. SSH モデルの未解決問題についての検討
1. 文書の状況

(準備中)

2. TMSM の未解決問題についての検討
  • draft-ietf-isms-tmsm-01.txt
3. SSH モデルの未解決問題についての検討
  • draft-ietf-isms-secshell-02.txt

WGのメーリングリストが活発ではなく、仕様の検討状況は、捗っていない。この仕様を策定されようとした経緯には、現行SNMP( Simple Network Management Protocol )v3 というネットワーク管理プロトコル仕様のセキュリティモデルの複雑性が挙げられる。

Transport Layer Security WG(tls)

検討課題:

  1. ECMQV Cipher Suites for TLS
  2. TLS-DTLS AES-CTR
  3. 相互運用可能性問題についてのプレゼンテーション
  4. TLS アプリケーションに対する追加データ提供
  5. TLS 認可拡張機能
  6. draft-ietf-mmusic-rfc2326bis-12の検討
  7. RFC 4346 後継文書について   
1. ECMQV Cipher Suites for TLS(Brian Minard)
2. TLS-DTLS AES-CTR(Nagendra Modadugu)

前回の会合において提案されたAES のカウンターモードをストリーム暗号(例: RC4)のように用いるもの。(現行の WG 憲章の範囲内となった。)
前回からは、変化していない。
WG Last Call に向けてレビューが求められた。

(準備中)

3. 相互運用可能性問題についてのプレゼンテーション(Yngve Petterson)
  • http://www3.ietf.org/proceedings/06mar/slides/tls-6.pdf PDF形式

    TLS 1.0 は、SSL 3.0 との互換性を保つ建前であるが、現実の実装については、相互運用可能性が損なわれている。これから TLS 1.1 や TLS 1.2 に上げていく際に、この問題を考える必要がある。

4. TLS アプリケーションに対する追加データ提供(Russ Housley)

独立した拡張機能が、「どのデータがハンドシェイクプロトコル部分中に現れるか?」を判定するために使われる。アプリケーションに渡されるすべてのデータを、ひとつのハンドシェイクプロトコルのメッセージ内に置いているのが現状である。
複数の拡張機能について種類を設けることによって、混乱を避けてデータを渡すことができるようになる。
この提案は、支持され、Stefan Santesson が I-D を執筆することになった。

(準備中)

5. TLS 認可拡張機能(Russ Housley)

エリアディレクターによって、TLS 1.0 と TLS 1.1 の両方のハンドシェイクプロトコル中に認可( Authorization )機能拡張を設ける提案がなされた。これによって、クライアントからサーバー宛と、サーバーからクライアント宛の両方向に、認可情報を渡すことできるようになる。
「WG 文書とするか?」について、関心をもつ者が少なく、個人による I-D のまま、進めることとなった。

(準備中)

6. draft-ietf-mmusic-rfc2326bis-12の検討(Magnus Westerlund)

RTSP( Real-Time Streaming Protocol)は、ストリーミングプロトコル用のシグナリングプロトコル(リモートコントロール用)である。ストリーミングメディアは、通常、トランスポート層にUDP を使う。例外として、インターリーブモードがある。 RTSP についても、TLS によって防護されたシグナリングに用いることができるURI スキームがある。
環境によっては、プロキシを要求する。:(例)

  • ファイアウォールがメディアを通過させるようにするとき
  • メディアコンテンツをフィルタリングするとき

このような場合、プロキシが信頼される限り、 TLSは破綻しない。しかし、プロキシが多段になる場合や、服数のプロキシが信頼する証明書を使い分けたいときには、追加的な仕様規定が必要になるという。
少数ながら支持を得ることができ、ボランティアによってレビューされる。

(準備中)

7. RFC 4346 後継文書について(Eric Rescorla)

RFC4346(TLS1.1)は、発行待ち状態にある。MD5とSHA-1についての最近の攻撃が話題になっている。そこで、憲章を書き換え、「TLS 1.2 を策定する」としたい、という。
以下の点が変更される。

  • TLS 拡張機能と AES サイファースィート中に追加統合した。
  • どのハッシュ関数が証明書中でサポートされているか、を示すために、クライアントへの拡張。
  • 擬似乱数生成器における MD5/SHA-1 を置き換え。
  • デジタル署名された要素における MD5/SHA-1 を置き換え。

以下の方針で、まとめられる。

  • 証明書選択は、拡張機能によって行えるようにする。
  • TLS 1.2 にバージョンを上げる主な理由は、PRF(擬似乱数生成機)とデジタル署名された要素を置き換えるためである。
  • このような予防的な仕様変更を行いたい。

Open Security Area Directorate WG (SAAG)

まず、各WGチェアから進捗報告がなされ、招待講演があるのが恒例となっている。今回の会合においては、下記の4件の招待講演があった。:

1. CAPWAP のセキュリティ(Scott Kelly)

これは、HOAKEYBOF において話題になった無線アクセスポイントの仕様である。

範囲内の要件: AC<->WTP

Control And Provisioning of Wireless Access Points

  • http://www.ietf.org/html.charters/capwap-charter.html
2. Authentication for TCP-based Routing and Management Protocols (Ron Bonica)

RFC 2385,“Protection of BGP Sessions via the TCP MD5 Signature Option”中の ”TCP: Enhanced Authentication Option' についての仕様説明。

3. OATH HOTP C/R (Johan Rydell)

OATH[1] は、ネットワーク越しに強い本人認証技術を採用することを促進する企業から成るコンソーシアムである。
RFC4226, “ HOTP(An HMAC-Based One-Time Password Algorithm)” に基づいて、チャレンジ/レスポンスを改良している。

4. CT-KIP    (Dave Mitton)

‘The Cryptographic Token Key Initialization Protocol' についての仕様 [2]を策定中。

  • [1] http://www.openauthentication.org/
  • [2] http://www.ietf.org/internet-drafts/draft-nystrom-ct-kip-00.txt

(準備中)

Simple Authentication and Security Layer WG (sasl)

検討課題:

  1. 文書の状況

(準備中)

Operational Security Capabilities for IP Network Infrastructure WG (opsec)

検討課題:

  1. 文書と WG の状況 (Ross/Pat)
  2. 計画の見直し(Ross)
  3. Profiling Capabilities for Specific Environments
1. 文書と WG の状況 (Ross/Pat)
  • Framework for Operational Security Capabilities for IP Network Infrastructure
    • draft-ietf-opsec-framework-02.txt
  • Security Best Practices Efforts and Documents
    • draft-ietf-opsec-efforts-02.txt
  • Operational Security Current Practices
    • draft-ietf-opsec-current-practices-02.txt
  • Filtering Capabilities for IP Network Infrastructure
    • draft-ietf-opsec-current-practices-02.txt
      いまだに著者が不在であることが問題。

下記の文書が新規に入手可能となった。

  • Miscellaneous Capabilities for IP Network Infrastructure
    • draft-ietf-opsec-misc-cap-00.txt
  • Network Management Access Security Capabilities
    • draft-ietf-opsec-nmasc-00.txt
2. 計画の見直し(Ross)
3. Profiling Capabilities for Specific Environments

ISPの運用管理者向けのガイドライン文書が策定されつつあり、内容的には期待されるが、編集作業が、あまり進捗していない。

参考情報

(準備中)