ニュースレターNo.59/2015年3月発行

第91回IETF報告　セキュリティ関連WG報告

Transport Layer Security（TLS） v1.3の議論

TLS WGでは、SSL/TLSの次のバージョンである1.3の策定に向けて、検討が活発に行われています。前回の第90回IETFミーティングに続いて、今回もミーティング期間以外に開催されるInterim（中間）ミーティングが開かれていました。

TLS 1.3に関しては、TLSの通信を始める前の、暗号アルゴリズムを選択したり暗号化に使う鍵を決めたりする重要なやり取りである「ハンドシェイク」に議論が集まっています。v1.3のハンドシェイクの案に対して、ハンドシェイク中にやり取りされるメッセージそのものを暗号化したり、メッセージの改ざんを検知するのに役立つ電子署名を加えたりする案が挙げられています。WGミーティングでは、ハンドシェイクが通信の安全性を大きく左右するため、拙速にコンセンサスを取るのではなく、慎重に議論を進めることになりました。

またハンドシェイクを簡素化し、オーバーヘッドを少なくする0-RTTと呼ばれる方式も提案されています。議論されているハンドシェイクの候補は、次の資料で見ることができます。

TLS 1.3のハンドシェイク候補の議論に使われたスライド
http://www.ietf.org/proceedings/91/slides/slides-91-tls-2.pdf

なおSSL/TLSの圧縮機能は、BEAST（Browser Exploit Against SSL/TLS）やCRIME（Compression Ratio Info-Leak Made Easy/Compression Ratio Info-Leak Mass Exploitation）といった攻撃手法が生まれたことを背景として、TLS 1.3では盛り込まれないことになっています。

I2NSF（Interface to Network Security Functions） BoF

I2NSFは、ファイアウォールやユーザー認証サーバといったネットワークセキュリティ機能を、ネットワークの仮想化機能VNF（Virtualized Network Functions）の環境内や、ホスティングの環境において、設置したり設定したりすることができるプロトコル、そしてデータモデルを検討するグループです。第91回ミーティングで1回目のBoFが開かれました。

本グループの設立に向けた意図をまとめたInternet-Draftによると、近年におけるネットワーク仮想化技術の発展に伴って、以下のようなニーズが高まっているとしています。

• 複数の拠点に分かれた企業のネットワークのために必要最小限のネットワークセキュリティ機能を運用する
• クラウド型のデータセンターで稼動させながら、クライアントにネットワークセキュリティ機能を提供する
• 多数のサイトやユーザー、もしくは低電力のセンサーネットワークに対して一貫したセキュリティポリシーを適用する

これらに対して、本グループでは、仮想化環境で稼動するセキュリティ機能を“仮想ネットワークセキュリティ機能”
- Virtual Security Functionと呼んで、クラウド型のデータセンターでの提供や従来の機器との共存がしやすいように標準化することを目標としています。

Interface to Network Security Functions Problem Statement
https://tools.ietf.org/html/draft-dunbar-i2nsf-problem-statement-01

I2NSF BoFには80名ほどが集まりました。IETFで行われる1回目のBoFとしては人数は多くない方ですが、アジェンダやプレゼンテーションの内容は、ある程度練られたもので、アイデア段階で開かれるBoFとは様子が違っていました。このBoFでは、WG化に向けて趣意書を作成するためというよりは、取り組む課題を明確化するために議論されていました。

本グループのInternet-Draftには、課題の明文化の他に、データセンターなどを挙げて利用ケースを説明したものがあります。まだWGではありませんが、次のページが設けられ、まとめられています。

Interface to Network Security Functions（i2nsf） - Documents
https://datatracker.ietf.org/wg/i2nsf/documents/

BGPSEC - Origin ValidationとPath Validationの分離

SIDR WGは、PKI技術を使ったBGPルーティングのセキュリティの仕組みを検討しているWGです。大きな動きとして二つ挙げられます。

一つはBGPSEC（Border Gateway Protocol Security Extension）において、Origin Validation（経路情報のAS番号を確認する方式）とPath Validation（経路情報のASパス情報を確認する方式）が独立した扱いになったことです。これまではPath Validationが行われる際には、必ずOrigin Validationが行われるという位置づけでした。今後、RPKIキャッシュやBGPルータの実装において、おのおのが独立してvalid（有効である）やinvalid（無効である）という扱いに変わってくると考えられます。

もう一つは、リソース証明書やROA（Route Origin Authorization）といったデータファイルの取得に使われていたrsyncに代わるプロトコルが、本格的に検討されていることです。第91回IETFミーティング期間中に、複数のプロトタイプの実装同士を突き合わせる作業も行われていた模様です。このプロトコルは、RPKI Repository（またはRetrieval） Delta Protocol - RRDPと呼ばれています。まだ個人ドラフトですが、rsyncは処理が重く、またRTT（往復遅延時間）の大きい環境で伝送効率が下がることが分かっていることから、注目されています。

RPKI Repository Delta Protocol（Internet-Draft）
https://tools.ietf.org/html/draft-tbruijnzeels-sidr-delta-protocol

SIDR WGでは、ルーティング技術者の観点でBGPSECに関する意見収集を行う目的で、Inter-Domain Routing（IDR） WGとの合同でミーティングが開かれました。第91回IETFミーティング期間中に行われた合同ミーティングでは、BGPSECの仕組みに関する質疑応答を通じて理解が深められた様子です。長いASパスが不正に生成されることによってコンバージェンスの時間が長くなり、ルーティングに支障が出るような行為ができてしまうのではないかといった、運用の観点ならではの意見交換も行われています。

この他に、RPKIの認証局によるROAの失効に気付けるような新たな署名付きオブジェクトの提案や、不正な証明書を見つけやすくするためのCertificate Transparencyに似たアイデアが提案されていました。これらを含めて、RPKIについて活発に研究が行われている、ボストン大学の研究グループによる論文が次のURLで公開されています。

Hardening the RPKI Against Faulty or Misbehaving Authorities, BUSEC: Boston University Security Group
http://www.cs.bu.edu/~goldbe/papers/RPKImanip.html

---

第88回IETFミーティング以降、大規模な通信傍受（pervasive monitoring）への対策として、さまざまなWGで通信プロトコルに暗号化機能を持たせることが検討されています。第90回IETFミーティングで初めてWGの会合が開かれたTCPINC（TCP Increased Security） WGでは、インターネットのほとんどの通信で使われているプロトコルであるTCP（Transport Control Protocol）に、認証なしの暗号化機能を持たせることが検討されています。

TCP Increased Security（tcpinc）
https://datatracker.ietf.org/wg/tcpinc/charter/

2014年11月14日には、IAB（Internet Architecture Board）から「インターネットの機密性に関する声明」が出されました。通信相手の認証を行わなくても、通信を暗号化することは大規模な通信傍受に対して有効であり、プロトコルの検討の際には、基本的な考え方として暗号化の機能を盛り込むことが推奨される、としています。

IAB Statement on Internet Confidentiality
https://www.iab.org/2014/11/14/iab-statement-on-internet-confidentiality/

インターネットプロトコル（IP）が生まれて以降、インターネットにおけるプロトコルには「シンプルさ」が求められてきたと言えますが、社会情勢に応じて、変化が起きているように感じられます。

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