>>IETF インターネットセキュリティに関する情報収集の報告のトップページ
最終更新日：2002年 6月 6日
情報処理振興事業協会
セキュリティセンター
概要
2002年 3月17日より 22日まで、アメリカ合衆国ミネソタ州ミネアポリスでミーティングが開催された。
PKI および暗号実装技術の動向調査を目的に IETF のセキュリティエリアのワーキンググループを中心に参加した。
今回の参加者は同時テロの影響があった前回と同様に参加者が少なく、アメリカ、日本、イギリス、フランス、韓国、ドイツをはじめとして33ヶ国 1,756名であった。 暗号関連の動きとしては、TLS-WG などにおけるブロック暗号の利用モードのひとつである CBC(Cipher Block Chaining) Mode に対する選択平文攻撃の問題から Ctr(Counter) Mode への移行提案、SMIME-WG における RSA-OAEP の代わりにRSA-KEM を採用する提案などがあった。 PKIX WG の暗号技術として SHA-256etc、DSA-2、NtrU などが検討議題になっていたが、NISTや SAAG(IETF Security Area Advisory Group)の動きを待って検討を再開することになった。
3月20日夜に開催された総会において WIDE プロジェクト代表 村井 純氏がプレゼンテーションを行い、今年7月14日から19日まで開催される第54回 IETF meeting 会場の日本(横浜)について紹介があった。
Open Security Area Directorate Meeting（saag）/Jeffrey I. Schiller（MIT）
今回から、Steven M. Bellovin(AT&T)が Chair として参加することになった。
今回開催の WG/BOF は次の通り(開催順)：
MSEC - Multicast Security
WG
SACRED - Securely Available Credentials WG
IPSP - IP Security Policy WG
SECSH- Secure Shell
SMIME - S/MIME Mail Security WG
KRB - Kerberos WG
TLS-Transport Layer Security WG
PKIX - Public-Key Infrastructure (X.509) WG
IPSEC - IP Security Protocol
INCH Extended Incident Handling BOF
IDWG (Intrusion Detection Exchange Format) WG は、開催されなかった。
IETF の活動において、セキュリティ技術は各エリアにおいても重要であることから、Security Area Directorate を設置することが Jeffrey I. Schiller（MIT）より説明があった。
Public-Key Infrastructure (X.509) WG(PKIX)
PKIX WG の活動状況/Tim Polk (NIST, US)
現在の Internet-Drafts 数は28。
14 RFC
3 RFC editors queue
I-Ds
(Certificate Profile, Public Key Algorithms, and Attribute Certificate Profile)
3 WG last call
PKIX WG に関連する LDAP の動向として以下の状況が報告された。 LDAP (v3) Revision WG の進展状況を踏まえて、PKIX-WG の Drafts を見直す必要がでてきた。 LDAPv3 RFC2559 であるLDAP v2(Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2)は今年中に historic に移行する予定である。 RFC2587 である Schema Internet(X.509 Public Key Infrastructure LDAPv2 Schema)は特に変更なし。 その他 LDAP 関連でバージョンの記述見直しなどを出来るだけ早急に実施予定とのこと。
PKI実装暗号アルゴリズムに関しては、現在検討が中断している。 検討が中断している理由は、 NISTがより鍵サイズの大きい DSA-2や SHA-256/384/512 の OID などを決定していないこと、また Security Area として、lattice ベースの暗号について判断をしていないことである。
TSP Interoperability Testing/Denis Pinkas (Integris)
Time-Stamp Protocol (TSP -RFC3161)の実装実験の準備を進めており、現在 9ヶ所から連絡があったとのこと。
| イタリア4社 | C&A experimental TSA service SIA Computer and Network Security Group(CNSG), Innovery True Time |
|---|---|
| フランス1社 | Edelweb |
| ニュージーランド1社 | Cryptographic Appliances |
| オーストリア1社 | GrazUniversity of Technology |
| 日本1社 | NEC |
| スペイン1社 | UPC |
イタリアが積極的に参加しているのは、イタリアのデジタル署名法に Time-Stamp の規定があるためと思われる。 相互運用可能性テストは Drafts の shall,must,should の項目について予定しており、TSP クライアントとしては21項目 TSP サーバーとしては55項目になりそうとのこと。
OCSP Update - Ambarish Malpani (ValiCert)
インターオペラビリティテストにより、マイナーな修正点が明らかになった。従来 DSA であった実装必須暗号を RSA に変更する。
DPV/DPD Requirements Status/Denis Pinkas (Integris)
本 Drafts は WG last の状態である。 現在寄せられている約25のコメントの対応について発表があった。
OCKID/ Paul Hoffman (IMC/VPNC)
本 Drafts は今回新たに提案されたもので証明書の内容確認を利用者に簡単に出来るようにする方法を提案している。 具体的には、公開鍵の値を100ビットのハッシュ値に変換して Base32 コンバージョン変換(0とo、1とlは間違いやすいので使っていない)している。 本提案については、特許権の問題がありそうなため、調査の上メーリングリストで検討することになった。
S/MIME Mail Security WG（SMIME）
これまで16件 RFC になっている。
- Cryptographic Message Syntax (RFC 2630)
- S/MIME Version 3 Message Specification (RFC 2633)
- S/MIME Version 3 Certificate Handling (RFC 2632)
- Diffie-Hellman Key Agreement Method (RFC 2631)
- Enhanced Security Services for S/MIME (RFC 2634)
- Methods for Avoiding the 'Small-Subgroup' Attacks on the Diffie-Hellman Key Agreement Method for S/MIME (RFC 2785) Informational
- Use of the KEA and SKIPJACK Algorithms in CMS (RFC 2876) Informational
- Use of the CAST-128 Encryption Algorithm in S/MIME (RFC 2984)
- Incorporation of IDEA encryption algorithm in S/MIME (RFC 3058) Informational
- Electronic Signature Policies (RFC 3125) Experimental;
- Electronic Signature Formats for long term electronic signature (RFC 3126)Informational
- Domain Security Services using S/MIME (RFC 3183) Experimental
- Reuse of CMS Content Encryption Keys (RFC 3185)
- Password-based Encryption for S/MIME (RFC 3211)
- Triple-DES and RC2 Key Wrapping (RFC 3217) Informational
- Preventing the Million Message Attack on CMS (RFC 3218)Informational
現在 RFC Editor で確認中の Internets-Draft
- Implementing Company Classification Policy with the S/MIME Security Label (draft-ietf-smime-seclabel)
- Elliptic Curve S/MIME (draft-ietf-smime-ecc)
- Compressed Data Content Type for S/MIME (draft-ietf-smime-compression)
現在 IESG で確認中の Internets-Draft
- Securing X.400 Content with S/MIME (draft-ietf-smime-x400wrap)
- Transporting S/MIME Objects in X.400 (draft-ietf-smime-x400transport)
- Cryptographic Message Syntax (draft-ietf-smime-rfc2630bis)
- Cryptographic Message Syntax (draft-ietf-smime-cmsalg )
- S/MIME Symmetric Key Distribution (draft-ietf-smime-symkeydist)
- AES Key Wrap Algorithm (draft-ietf-smime-aes-keywrap)
Draft Standard は Proposed Standard RFC や Experimental を参照できないため、PKIX-WG の Son of RFC2459 参照 Draft が Draft Standard に移行できなかったが、IESGが Son of RFC2459 を承認したので障害がなくなった。
Cryptographic Message Syntax /R.Housley(RSA)
(draft-ietf-smime-rfc2630bis-07 and
draft-ietf-smime-cmsalg-08)
IESG のコメントに対応済みの状況である。
S/MIME 実装における必須暗号アルゴリズム以下の通り
Signature Verification DSAandRSA(PKCS#1)
Signature Generation DSAorRSA(PKCS#1)
One-way
Hash Function SHA-1
Key Management RSA(PKCS#1)
Encryption Triple-DES
Key Encapsulation A New Paradigm for Public-key Encryption/R.Housley(RSA)
S/MIME の暗号を新しいモデルの暗号に移行したい旨の提案がなされた。新しいモデルは Shoup氏らが研究している鍵カプセル化技術(key encapsulation)である。 公開鍵レイヤー(Public-key layer)共通鍵レイヤー(Symmetric-key layer)を独立させ、公開鍵レイヤーでランダムな共通鍵を設定して、共通鍵レイヤーでは設定された鍵によりデータの暗号化をする特徴がある。 現在、鍵カプセル化技術に関する標準は多くあるが、鍵カプセル化技術の名称しては使われていないのが現状であると説明している。
鍵カプセル化の関連標準
| DH | RSA | |
|---|---|---|
| ANSI X9F1 | 有 | 有 |
| IEEE P1363 | 有 | 提案予定 |
| ISO/IEC 18033-2 | 有 | 有 |
| PKCS#1 | 不明 | 提案予定 |
| S/MIME | 有 | 今回提案 |
| SSL/TLS | 有 | 有 |
関連する研究内容
- Zheng-Seberry,Bellare-Rogaway proposed RSA-based Schemes with two layers (early 1990s)
- Bellare and Rogaway:DH scheme (mid-1990s)
- Okamoto and Pointcheval:REACT transformation(2001)
- Shoup:KEM for ISO proposal (2001)
- Handschuh et al.:GEM (2002)
Use of the AES Encryption Algorithm and RSA-OAEP Key Transport in CMS(draft-ietf-smime-aes-alg)Drafts で利用する RSA-OAEP を RSA-KEM に変更して、Standard Track RFC とすることを提案している。 過去の RSA-OAEP 関連 I-D は、「歴史的（Historical）」RFC としたい意向である。
Transport Layer SecurityWG (TLS)
現在4つの RFC があるが、RFC2246 の更新が主たる議題である。
- The TLS Protocol Version 1.0 (RFC 2246)
- Addition of Kerberos Cipher Suites to Transport Layer Security (TLS) (RFC 2712)
- Upgrading to TLS Within HTTP/1.1 (RFC 2817)
- HTTP Over TLS (RFC 2818)
TLS CBC mode issue/ Eric Rescorla
本プレゼンテーションは CBC モードに対する選択平文攻撃(Adaptive chosen plaintext attack on CBC)に関する研究に対応して、暗号利用モードについて見直しの提案である。 クレジット決済の商店とクレジット会社のサーバ間通信を例に攻撃可能性を説明していたが、proxy や VPN によりほとんどの場合攻撃を防止できるかもしれないとも説明していた。 対応としては、攻撃可能性の警告を記載する、プロトコルの拡張部による対応、新しい暗号や暗号利用モード(CounterモードとOFBモードが候補になっていた)にするなどを提案していた。
RFC2246bis/ Eric Rescorla
本 Draft が Draft Standard に向け残された論点は、以下の通りである。
1 PMS のバージョンチェックを should or must サーバー側はチェックすることが可能であるが、クライアント側は PMS のバージョンをセットするだけで negotiate しないばず
2 record header のバージョン
TLS のクライアントが SSL3.0 サーバーと通信する際には、SSL3.0 のメッセージを使うが、これを Client Hello だけでなく、record header にも適用するかどうか
3 TLS SSLv3 との rehandshake
TLS 実装暗号アルゴリズム/ Win Treese (WG Chair)
WG の chair は、「情報提供（Informational）」にすると説明していたが、各暗号の OID の調整など必要と思われる。 TLS 実装暗号アルゴリズムとして MISTY1、Camellia、EPOC、PSEC,、NTRU などの提案がなされている。
以上
