ニュースレターNo.57/2014年8月発行
セキュリティ関連報告
IETFにおけるセキュリティ関連のWGは、多岐に亘っており、かつWGを超えて関連した提案が行われていたりしています。本稿では、その中から次の通り、話題をいくつかピックアップしてお送りします。
ピックアップする話題
-
前回の第88回IETFで話題になった、“広域で行われる通信傍受”
「Pervasive Monitoring」について、W3CとIABが開催したワークショップの様子がセキュリティエリアの会合で報告されました。またPervasive Monitoringへの対策、具体的にはユーザーや組織におけるプライバシーを守るための対策技術の一つとして、IPsecのためのDNSを使った鍵配送技術が紹介されました。
-
Transport Layer Security(TLS)プロトコル関連 -- TLS v1.3の方向性
SSL/TLSのプロトコルを扱うTLS WGでは、SSL/TLSの次のバージョンであるTLSバージョン1.3の議論が本格的に行われています。
-
Secure Inter-Domain Routing(SIDR)WG -- rsyncの見直し
PKI技術を用いてグローバルなルーティングのセキュリティを扱うSIDR WGでは、唯一の転送プロトコルとして使われているrsyncが、今後別のものに置き換わる可能性が見えてきました。ASパスに電子署名をつけて正しいASパスを確認できるBGPSECは、一部のプログラムで実装が始まっています。
次に、それぞれの話題について詳細にご報告します。
“広域で行われる通信傍受”に関するワークショップと対策技術
前回の第88回IETFミーティングの全体会議で取り上げられた、Pervasive Monitoringに関して、今回第89回IETFの直前の2月28日から3月1日にかけて、W3CとIABによってワークショップが開かれました。筆者はこのワークショップに参加していませんが、セキュリティエリアの会合であるSAAG(Security Area Advisory Group)の資料を基に紹介します。
広域で行われる通信傍受を「attack」(攻撃行為)と位置付け、その脅威を低減させるための対策を議論するワークショップである。脅威モデルの文書化や、傍受を避けることのトレードオフを整理する目的として行われた。また通信のたびに使われる暗号鍵がその都度(opportunistic)に選ばれることで、継続的な傍受がしにくくなる技術が紹介されるなどしている。
このワークショップでは66もの小論文が集められ、現地では参加者同士のディスカッションが行われた模様です。ワークショップのWebページに小論文や写真、議事録も掲載されています。
W3CとIABが主催したワークショップのWebページ。小論文はダウンロードして読むことができる。
SAAGでは、DNSを使ってIPsecの鍵共有に必要な鍵交換を行う仕組みがPervasive Monitoringの対策技術の一つとして挙げられています。
IPsec “Opportunistic Encryption”
DNSでA/AAAAレコードを検索した後に、IPSECKEYレコードを検索することでIPsecのIKEで必要な鍵を取得する。IPsecを使ったVPNの実装であるlibreswanで試験的に開発されている。
オープンソースのIPsec VPNの実装である。
Transport Layer Security(TLS)プロトコル関連 -- TLS v1.3の方向性
Transport Layer Security(TLS)は、Webページの閲覧で使われるHTTPの他、電子メールの通信プロトコルであるPOPやIMAPなどでも使われているセキュリティのプロトコルです。IETFのTLS WGは1996年に設立され、TLSプロトコルの機能向上や改善のためのバージョンアップが行われてきました。現在のTLSの最新バージョンは1.2です。TLS v1.2はInternet ExplorerやGoogle Chrome、FirefoxやOperaといったWebブラウザをはじめ、iPhoneやAndroid付属のWebブラウザでも使われています。
現在のTLS WGは、次のバージョンであるv1.3の仕様策定を目的としています。
Transport Layer Security(tls) - charter
第89回IETFのTLS WG会合では、まずTLSで使われる暗号とメッセージ認証処理について議論されました。ストリーム暗号ChaChaのTLSでの採用については、Googleの一部のサーバで実装されているという意見がある一方で、プロトコルにはさらにレビューが必要であるという形になりました。後半はTLS v1.3の詳細議論です。仕様の方向性に関する、会場での反応をいくつか紹介します。
TLS v1.3ではServer Name Indication(SNI)を暗号化するか
SNIは、一つのIPアドレスで複数のホスト名が設定されているサーバ、例えば1台で複数のWebサーバをホスティングしている環境で使われる文字列です。クライアントがどのサーバ(FQDN)にアクセスしたいのかを指定するために使われます。TLS v1.3で、このFQDNを暗号化の範囲に含めるべきかどうかという点についてチェアから参加者に問われました。ハミングの結果、会場では多くが賛成、反対も少数ながらいました。
TLS v1.3で圧縮をサポートするか
TLSプロトコルの圧縮機能については、会場での参加者の多くがサポートしない方に賛意を示していました。反対はいませんでした。なおTLSの圧縮機能はCRIME攻撃(下記)の対象になっていました。
複数の製品で使用されるTLSプロトコルにおける平文のHTTPヘッダを取得される脆弱性(JVNDB-2012-004393)
会場の反応が賛成と反対とで同じくらいになってしまって方向性が見い出しにくいものについては、今後もメーリングリストで議論されていくことになりました。
Secure Inter-Domain Routing(SIDR)WG -- rsyncの見直し
RPKI(Resource Public-key Infrastructure)を使ってBGPによるルーティングのセキュリティの仕組みを検討しているSIDR WGでは、Internet-Draftの数が増えてきて、議題も増えてきました。今回は、RPKIの単一障害点となり得るTrust Anchor Locatorを、複数設けられるようにする提案が復活したり、RPKIで唯一の転送プロトコルとして指定されてきたrsyncの脆弱性や性能の問題が指摘されたりしていました。
Resource Certificate PKI(RPKI) Trust Anchor Locator(リソースPKIのトラストアンカー指定)
RPKIを使って証明書を検証するために必要なトラストアンカーの指定方式であるTrust Anchor Locator (TAL)の書式を定めるドキュメント。複数のURLを記述できるようにすることで、FQDNの中に含まれるラベルを持つDNSサーバの一つに障害が起きても、トラストアンカーを取得できる。
rsync considered inefficient and harmful, George Michaelson(rsyncの非効率性と問題について)
rsyncのプログラムが行っているブロックごとのチェックサムの計算によって、一つ一つのデータサイズが小さいRPKIの場合に非効率になっている点の指摘。さらに、不適切なrsyncクライアントによってrsyncサーバの負荷と使用メモリが増大してしまう問題が指摘されている。サーバとクライアントの間がネットワーク的に離れていて、RTTが大きい場合に著しく転送効率が下がることについても説明されている。
会場ではrsyncは暫定的に使っているプロトコルで、今後変わる可能性があるため、今の段階で改良に注力しなくてもよいといった意見が複数挙がりました。
ASごとに証明書が発行され、ASパスの正しさを確認できるBGPSECについてはInternet-Draftの更新が少しずつ行われているものの、あまり議論が行われていません。ただし、BGP-SRxを実装している米国国立標準技術研究所(NIST)の開発者によると、AS番号の入った証明書を扱う、基本的なプログラムの実装は始まっている模様です。
IETFではここ数年、インターネットに関わる時事問題の取り上げ方が定着してきたようです。はじめにIETF会場で行われるプレナリー(全体会議)で取り上げ、次にワークショップを行い、その結果をIABメンバーが中心となってRFC化して残していくという形です。IETFはRFCの作成を通じたプロトコル策定を行うWGの集合ではありますが、参加者の知恵を生かして議論を整理し、文書化していくというIABの活動は素晴らしいと思います。Pervasive Monitoringについてもそうですが、具体策を提案してRFC化していけるところもIETFの良さだと考えられます。
(JPNIC 技術部／インターネット推進部 木村泰司)
