ニュースレターNo.46/2010年11月発行
セキュリティ関連WG報告～IPSECME WG、TLS WGについて～
IETFには、セキュリティ関連WGが16WG存在しています。今回は、BoFとして開催されたFEDAUTHを含む、11WGがスロットを取り、12セッションが開催されました。セキュリティ関連のWGに関するこれらのミーティングは、領域および範囲が広いため、すべてのミーティング内容を把握することが困難な状況です。そこで本稿では、会期中に議論されたセキュリティ関連セッションの中から、認証やセキュア通信に特化した内容を議論するWGである、IPSECME WGおよびTLS WGの動向について報告します。
IPSECME WG（IP Security Maintenance and Extensions WG）
IPSECME WGは、2005年にクローズされたIPSEC WGの後継WGであり、（IPSEC WG）クローズ後に必要になった仕様拡張や既存ドキュメントの明確化などの議論を行うためのWGです。このミーティングは、2010年7月26日（月）の午前9時から1時間半程度開催されました。参加者は40人程度でした。
IPSECME WGにおいて、今回の会議までにRFCとして発行されたドキュメントやRFCとして発行される直前のドキュメントに関する状況を示します。
＜RFCとして発行されたドキュメント＞
・RFC5879 Heuristics for Detecting ESP-NULL Packets
暗号化されたESPパケットからESP-NULLパケットを識別するためのヒューリスティックについて記述したドキュメントです。なお、本RFCはInformational（情報）の種別として発行されました。詳細についてご興味のある方は、下記URLをご参照ください。
URL：http://tools.ietf.org/html/rfc5879
・RFC5930 Using Advanced Encryption Standard Counter Mode
（AES-CTR）with the Internet Key Exchange version 02（IKEv2）Protocol
鍵交換プロトコルであるInternet Key Exchange version 2（IKEv2）において、AES-CTRを利用できるように仕様化したドキュメントです。なお、本RFCはInformationalの種別として発行されました。詳細についてご興味のある方は、下記URLをご参照ください。
URL：http://tools.ietf.org/html/rfc5930
＜RFCとして発行される直前のドキュメント＞
・Internet Key Exchange Protocol：IKEv2
（draft-ietf-ipsecme-ikev2bis-11）
IKEv2について記述するドキュメントです。このI-D（Internet-Draft）がRFC化されると、以前発行されたRFC4306（Internet Key Exchange（IKEv2）Protocol）とRFC4718（IKEv2 Clarifications and Implementation Guidelines）のドキュメントが廃止されることになります。なお、I-Dのステータスは、RFC Editorの編集待ちリストに掲載されている状態（RFC Editor queue）です。本I-Dは、インターネット標準化過程（Standards Track）に含まれるドキュメントとして発行される予定です。
・IPsec Cluster Problem Statement
（draft-ietf-ipsecme-ipsec-ha-09）
クラスタ上でのIKEやIPsecを実装するための要求条件や問題の提示および専門用語について定義し、また、異なるクラスタ間の相互運用を可能にするピアを許可するために存在している、仕様と実装のギャップを記述しているドキュメントです。なお、I-Dのステータスは、RFC Editor queueです。本I-Dは、Informationalに分類されるドキュメントとして発行される予定です。
・An Extension for EAP-Only Authentication in IKEv2
（draft-ietf-ipsecme-eap-mutual-05）
このドキュメントは、IKEv2において、拡張可能な応答者認証を提供するための相互認証（mutual authentication）や鍵合意（key agreement）を提供するEAP（Extensible Authentication Protocol）を仕様化するドキュメントです。なお、I-Dのステータスは、RFC Editor queueです。本I-Dは、Standards Trackのドキュメントとして発行される予定です。
・IP Security（IPsec）and Internet Key Exchange（IKE）Document Roadmap
（draft-ietf-ipsecme-roadmap-08）
IPsecやIKEに関係するRFCが多く発行され、それぞれの関係などが複雑化しており、そのドキュメントの背景や要約を記述することで整理することを目的としたドキュメントです。なお、I-Dのステータスは、IESG Evaluationです。本I-Dは、Informationalのドキュメントとして発行される予定です。このI-DがRFC化されると、以前発行されたRFC2411（IP Security Document Roadmap）は廃止されます。
＜今回議論された検討項目＞
今回のミーティングで議論された検討項目は、以下の通りです。
- IPsec-HA Recap
- Proposed IPsec HA Cluster Protocol
- Secure Failure Detection Decision Process
- Modes of Operation for SEED for Use with IPSec
（draft-seokung-ipsecme-seed-ipsec-modes-00）
今回のIPSECME WGミーティングでは、大きく分けるとIPsecHA関連の議論とIPsecに対して暗号アルゴリズムを追加する話題になりました。また、今回のIETF会合においては、通信の安全性を保つためのセキュアプロトコルに対して、暗号アルゴリズムを追加する提案について、セキュリティエリアに影響を及ぼす発表もありました。そこで、IPSECME WG内での話題ではありませんが、これに関連した、7月29日（木）のIETF Security Area Advisory Group（SAAG）での、セキュリティエリアディレクタSean Turner氏の発表「Cipher Suite Proliferation」について少し触れます。
Turner氏の発表では、現状におけるWGの状況を考慮して、Standards Trackとして発行するRFCを厳選することにより、RFC化に関係する人達の負荷を軽減しようという考えから、二つの選定ルールが提示されました。この発表資料は、以下のURLからご覧いただけますので、興味のある方はご参照ください。
- □Sean Turner氏の発表資料：
- http://www.ietf.org/proceedings/78/slides/saag-4.pdf
なお、IPSECME WGの詳細情報およびI-Dについては、 以下のURLをご参照ください。
- □IPSECME WG
- http://www.ietf.org/dyn/wg/charter/ipsecme-charter.html
- □第78回IETF IPSECME WGのアジェンダ
- http://www.ietf.org/proceedings/78/agenda/ipsecme.txt
TLS WG（Transport Layer Security WG）
TLS WGは、インターネット上で情報を暗号化して送受信するためのプロトコルであるTLS（Transport Layer Security）について、仕様の拡張や新規Cipher suiteの検討を行うWGです。今回のミーティングは、2010年7月29日（木）の午後3時10分から1時間程度開催されました。参加者は40人程度でした。
今回のミーティングで議論された検討項目は以下の通りです。
- Transport Layer Security（TLS）Cached Information Extension
（draft-ietf-tls-cached-info-09） - AES-CCM ECC Cipher Suites for TLS
（draft-mcgrew-tls-aes-ccm-ecc-00） - Prohibiting SSL Version 3.0 and Earlier
（draft-turner-ssl-must-not-01） - Representation and Verification of Domain-Based Application Service Identity in Certificates Used with Transport Layer Security
（draft-saintandre-tls-server-id-check-08）
このミーティングで、個人的に注目したい発表は、「Prohibiting SSL Version 3.0 and Earlier」です。理由としては、普段の生活の中で一般的に利用されているSSLプロトコルですが、古いバージョンのSSLプロトコルを利用してしまうと、安全性を担保するためには不十分な鍵長を使用することになってしまい、安全な通信ができない懸念があるからです。そのような状況を防ぐために、暗号アルゴリズムの危殆化※1対応（暗号アルゴリズムの世代交代）の考え方に従い、このI-Dが執筆されたと考えます。IETFにおいてセキュリティ関連を議論しているエリアなので、他のエリアに先駆けて暗号アルゴリズムの危殆化対応も行っているという印象を持ちました。このI-DがRFC化されると、RFC5246（The Transport Layer Security（TLS）Protocol Version 1.2）を更新します。
なお、TLS WGの詳細情報およびI-Dについてご興味があれば、以下のURLをご参照ください。
- □TLS WG
- http://www.ietf.org/dyn/wg/charter/tls-charter.html
- □第78回IETF TLS WGのアジェンダ
- http://www.ietf.org/proceedings/78/agenda/tls.txt
（NTTソフトウェア株式会社 菅野哲）
- ※1 暗号アルゴリズムの危殆（きたい）化
-
簡単に言えば、暗号アルゴリズムの安全性のレベルが低下した状況、または、その影響により暗号アルゴリズムが組み込まれているシステムなどの安全性が脅かされる状況を指します。詳しくは下記のURLをご覧ください。
JPNIC Newsletter No.44「インターネット10分講座：暗号アルゴリズムの危殆化」
https://www.nic.ad.jp/ja/newsletter/No44/0800.html
