＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
    __
    /Ｐ▲        ◆ JPNIC News & Views vol.1184【臨時号】2014.4.2 ◆
  _/ＮＩＣ
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ News & Views vol.1184 です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2014年3月上旬にイギリスのロンドンで開催された、第89回IETFミーティング
のレポートを連載にてお届けしていますが、その第3弾は「セキュリティ関連
報告」です。セキュリティの関連は広範囲であるため、"広域で行われる通信
傍受"、"TLS関連"、"SIDR WGでの話題"に絞ってお伝えしています。

なお、すでに発行済みの全体報告およびIPv6関連WGの報告のバックナンバー
は、以下のURLからご覧ください。

□第89回IETF報告 特集
  ○[第1弾] 全体会議報告 (vol.1182)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2014/vol1182.html
  ○[第2弾] IPv6関連WG報告 (vol.1183)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2014/vol1183.html

連載の最後はDNS関連WG報告をお届けする予定です。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第89回IETF報告 [第3弾]  セキュリティ関連報告
                           JPNIC 技術部／インターネット推進部 木村泰司
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

IETFにおけるセキュリティ関連のWGは、多岐に亘っており、かつWGを超えて
関連した提案が行われていたりしています。本稿では、その中から次の通り、
話題をいくつかピックアップしてお送りします。

  ピックアップする話題

   1. 前回の第88回IETFで話題になった、"広域で行われる通信傍受"

      「Pervasive Monitoring」について、W3CとIABが開催したワークショッ
      プの様子がセキュリティエリアの会合で報告されました。また
      Pervasive Monitoringへの対策、具体的にはユーザーや組織における
      プライバシーを守るための対策技術の一つとして、IPsecのためのDNS
      を使った鍵配送技術が紹介されました。

   2. Transport Layer Security (TLS)プロトコル関連 -- TLS v1.3の方向性

      SSL/TLSのプロトコルを扱うTLS WGでは、SSL/TLSの次のバージョンで
      あるTLSバージョン1.3の議論が本格的に行われています。

   3. Secure Inter-Domain Routing (SIDR) WG -- rsyncの見直し

      PKI技術を用いてグローバルなルーティングのセキュリティを扱う
      SIDR WGでは、唯一の転送プロトコルとして使われているrsyncが、今
      後別のものに置き換わる可能性が見えてきました。ASパスに電子署名
      をつけて正しいASパスを確認できるBGPSECは、一部のプログラムで
      実装が始まっています。

以下に、それぞれの話題について詳細にご報告します


1. "広域で行われる通信傍受"に関するワークショップと対策技術

前回の第88回IETFミーティングの全体会議で取り上げられた、Pervasive
Monitoringに関して、第89回IETFの直前の2月28日から3月1日にかけて、W3C
とIABによってワークショップが開かれました。筆者はこのワークショップに
参加していませんが、セキュリティエリアの会合であるSAAG (Security Area
Advisory Group)の資料を基に紹介します。

  ■A W3C/IAB Workshop on Strengthening the Internet Against
    Pervasive Monitoring (STRINT), IETF89 saag Summary 
    (広域で行われる通信傍受に対してインターネットを強化することに関
    するW3C/IAB共催のワークショップ)
    http://www.ietf.org/proceedings/89/slides/slides-89-saag-6.pdf

      広域で行われる通信傍受を「attack」(攻撃行為)と位置付け、その脅
      威を低減させるための対策を議論するワークショップである。脅威モ
      デルの文書化や、傍受を避けることのトレードオフを整理する目的と
      して行われた。また通信のたびに使われる暗号鍵がその都度
      (opportunistic)に選ばれることで、継続的な傍受がしにくくなる技術
      が紹介されるなどしている。

このワークショップでは66もの小論文が集められ、現地では参加者同士のディ
スカッションが行われた模様です。ワークショップのWebページに小論文や写
真、議事録も掲載されています。

  ■STRINT workshop
    https://www.w3.org/2014/strint/

      W3CとIABが主催したワークショップのWebページ。小論文はダウンロー
      ドして読むことができる。

SAAGでは、DNSを使ってIPsecの鍵共有に必要な鍵交換を行う仕組みが
Pervasive Monitoringの対策技術の一つとして挙げられています。

  ■IPsec "Opportunistic Encryption"
    http://www.ietf.org/proceedings/89/slides/slides-89-saag-4.pdf

      DNSでA/AAAAレコードを検索した後に、IPSECKEYレコードを検索するこ
      とでIPsecのIKEで必要な鍵を取得する。IPsecを使ったVPNの実装であ
      るlibreswanで試験的に開発されている。

  ■The Libreswan
    http://libreswan.org/

      オープンソースのIPsec VPNの実装である。


2. 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
     http://datatracker.ietf.org/wg/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)
     http://jvndb.jvn.jp/ja/contents/2012/JVNDB-2012-004393.html

会場の反応が賛成と反対とで同じくらいになってしまって方向性が見い出し
にくいものについては、今後もメーリングリストで議論されていくことにな
りました。


3. 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のトラストアンカー指定)
     http://tools.ietf.org/html/draft-ietf-sidr-rfc6490-bis-00

      RPKIを使って証明書を検証するために必要なトラストアンカーの指定
      方式であるTrust Anchor Locator (TAL)の書式を定めるドキュメント。
      複数のURLを記述できるようにすることで、FQDNの中に含まれるラベル
      を持つDNSサーバの一つに障害が起きても、トラストアンカーを取得で
      きる。

   ■rsync considered inefficient and harmful, George Michaelson
     (rsyncの非効率性と問題について)
     http://www.ietf.org/proceedings/89/slides/slides-89-sidr-6.pdf

      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の良さだと考えられます。

次回の第90回IETFは、2014年7月20日～25日、カナダのトロントで行われます。

     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
       わからない用語については、【JPNIC用語集】をご参照ください。
             https://www.nic.ad.jp/ja/tech/glossary.html
     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃     ◆◇◆◇◆   本号のご感想をお聞かせください   ◆◇◆◇◆     ┃
┃良かった                                                          ┃
┃→ http://feedback.nic.ad.jp/1184/148ad38ae4e6ae22b5a00768de485338┃
┃                                                                  ┃
┃悪かった                                                          ┃
┃→ http://feedback.nic.ad.jp/1184/aa15afe7d21be2552c4fe7be46ed3d35┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■  JPNICの活動はJPNIC会員によって支えられています  ■■■■■
  :::::  会員リスト  ::::: https://www.nic.ad.jp/ja/member/list/
  :::: 会員専用サイト :::: https://www.nic.ad.jp/member/ (PASSWORD有)
□┓ ━━━  N e w s & V i e w s への会員広告無料掲載実施中 ━━━┏□
┗┛          お問い合わせは  jpnic-news@nic.ad.jp  まで          ┗┛
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
 JPNIC News & Views vol.1184 【臨時号】

 ＠ 発行  一般社団法人 日本ネットワークインフォメーションセンター
          101-0047 東京都千代田区内神田3-6-2 アーバンネット神田ビル4F
 ＠ 問い合わせ先 jpnic-news@nic.ad.jp
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
            本メールを転載・複製・再配布・引用される際には
        https://www.nic.ad.jp/ja/copyright.html をご確認ください
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
登録・削除・変更   https://www.nic.ad.jp/ja/mailmagazine/
バックナンバー     https://www.nic.ad.jp/ja/mailmagazine/backnumber/
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■     News & ViewsはRSS経由でも配信しています！    ■■■■■
::::: https://www.nic.ad.jp/ja/mailmagazine/backnumber/index.xml :::::
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

■■◆                          ＠ Japan Network Information Center
■■◆                                     ＠  https://www.nic.ad.jp/
■■

Copyright(C), 2014 Japan Network Information Center