━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
    __
    /Ｐ▲        ◆ JPNIC News & Views vol.1681【臨時号】2019.5.14 ◆
  _/ＮＩＣ
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
---------- PR --------------------------------------------------------
◆ Internet Week ショーケース in 仙台 ◆  https://internetweek.jp/  ◆
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◇        基調講演はジェットインターネット 晋山孝善氏               ◇
◇     地域ISPから見たインターネットの過去・現在・未来を語る！      ◇
◇    5/30(木)～31(金)＠東北大学片平さくらホール ◆ 主催：JPNIC     ◇
----------------------------------------------------------------------
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ News & Views vol.1681 です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2019年3月下旬にチェコ・プラハにて開催された第104回IETFミーティングの
レポートを、vol.1678より連載にてお届けします。連載最終回となる本号で
は、セキュリティ関連の話題について、リモート・アテステーションと呼ば
れるデバイスなどの信頼性を外部から検証するための仕組みに関する議論を
中心にご紹介します。

なお、これまでに発行した第104回IETFの各報告については、下記のURLから
バックナンバーをご覧ください。

  □第104回IETF報告
    ○[第1弾] 全体会議報告 (vol.1678)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2019/vol1678.html
    ○[第2弾] IoT関連報告 ～IoT機器の安全なライフサイクル管理～
      (vol.1680)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2019/vol1680.html

また、これまでもお伝えしているように、本プラハ会合のオンサイトでの報
告会を、今週5月17日(金)に東京・神田のエッサム神田ホールにて開催いたし
ます。こちらの報告会にも、みなさまぜひご参加ください。。

    IETF報告会(104thプラハ)開催のご案内
    https://www.nic.ad.jp/ja/topics/2019/20190509-01.html

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第104回IETF報告 [第3弾]
   リモート・アテステーション関連報告 ～RATS WG、ACME WG～
                                               株式会社東芝 安次富大介
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2019年3月にチェコ・プラハにて開催されたIETF 104で、筆者が参加したRATS
WGとACME WGの動向をご紹介します。一見すると関連性が乏しい二つのWGです
が、両者とも昨今WebやIoTのセキュリティ強化の文脈で耳にする機会が増え
た「アテステーション」に関するトピックを扱っていましたので、タイトル
を上記のようにまとめさせていただきました。


■ リモート・アテステーションとは

RATS WGについて紹介する前に、まず、リモート・アテステーションとは何な
のかについて解説しておきます。

RATSの用語定義(*1)によれば、アテステーションとは「あるオブジェクト(デ
バイス等)のプロパティに関するクレームをエビデンスとして用いて、そのオ
ブジェクトの完全性を証明すること」であり(一般的にはエビデンス自体をア
テステーションと呼ぶことも多いですが)、リモート・アテステーションとは
「(システム外の第三者が)エビデンスを取得し、検証する手続き」であると
定義しています。具体例を挙げると、デバイスがTPM (Trusted Platform
Module)等のセキュアな領域に保存された秘密鍵を用いて自身のプロパティ情
報に署名し、第三者が秘密鍵の対となる公開鍵で署名検証して、デバイスの
完全性(正規のベンダに製造されたものか、危殆化した機種・機器でないか
等々)を検証する手続きです。Web PKIにおける証明書検証と似た話と考えて
いただくとよいかもしれません。

リモート・アテステーションに関する標準化は、既に複数存在しています。
例えば、ANIMA WGが取り組んでいるIEEE802.1ARのIDevID(出荷時にデバイス
に埋め込まれたクライアント証明書)を検証する処理もそうですし、パスワー
ド無しで物理キー(認証器)ベースの認証方法を規定したW3CのWeb
Authentication (FIDO2.0)における認証器の正当性を確認する処理も典型的
なリモート・アテステーションです。

(*1) https://tools.ietf.org/html/draft-birkholz-rats-architecture-01


■ RATS (Remote ATtestation ProcedureS)

RATS(*2)は、リモート・アテステーションに関わるデータフォーマットや、
伝送プロトコルの標準化を目的としたWGで、IETF 102期間中のSecurity
Dispatch WGでの提案、前回IETF 103でのBoFを経て、2019年3月に設立されま
した。

(*2) https://datatracker.ietf.org/wg/rats/about/

前回のBoFでは、標準化のスコープをどうするかで大きな議論になりました
が、WG化を経て、「相互運用可能なアテステーションエビデンスのフォーマッ
トと、伝送プロトコルの標準化」をターゲットとすることが明確化されまし
た。今回の会合では、以下の提案が議題として取り上げられました。このう
ちArchitectureとEATは、IETF 102のSecurity Dispatch WGへの提案時に既に
存在していましたが、それ以外は新規提案です。

- Use cases for Remote Attestation common encodings
- Architecture and Reference Terminology for Remote Attestation
  Procedures
- Reference Interaction Model for Challenge-Response-based Remote
  Attestation
- YANG Module for Basic Challenge-Response-based Remote Attestation
  Procedures
- Time-Based Uni-Directional Attestation (TUDA)
- Attested TLS Token Binding
- The Entity Attestation Token (EAT)

以降、RATS WGの動向を俯瞰できるように、すべての提案をかいつまんで紹介
します。

〇Use cases for Remote Attestation common encodings
  https://tools.ietf.org/html/draft-richardson-rats-usecases-01

ユースケース文書です。RFC化を意図したものではなく、WG内で用いる非公式
なドキュメントの位置付けで、現状ではTCG (Trusted Computing Group)、
Android Keystore system、FIDO (Fast Identity Online) Allianceといった
既存規格が、それぞれの用語定義と共に一覧されています。

〇Architecture and Reference Terminology for Remote Attestation
  Procedures
  https://tools.ietf.org/html/draft-birkholz-rats-architecture-01

アーキテクチャと用語定義に関する提案文書です。前回のBoFでは、基本アー
キテクチャを三つのコンポーネント(Attestation Server、Device、Relying
Party)で構成していましたが、今回の提案では、ActorやRoleといった観点で
再整理したものになっています。例えばRoleとしては、Asserter(デバイスベ
ンダ)、Attester(デバイス)、 Relying Party(デバイスにアクセスする第三
者エンティティ)、Verifier(リモート・アテステーションサービス。デバイ
スベンダが兼ねるケースあり)の四つを定義しています。このうちAsserterと
のインタフェースは、標準化のスコープ外と規定しています。

〇Reference Interaction Model for Challenge-Response-based Remote
  Attestation
  https://tools.ietf.org/html/draft-birkholz-rats-reference-interaction-model-00

チャレンジ・レスポンス型のリモート・アテステーションの、インタラクショ
ンモデルを提案しています。具体的には、上記のAttesterとVerifier間の通
信フローとして、

(1) Verifierがnonceとキー識別子をAttesterに提供
(2) Attesterがnonceとクレームに、キー識別子に対応する秘密鍵で署名を付
    与
(3) Attesterが署名付きクレームをエビデンスとしてVerifierに提示
(4) Verifierが公開鍵で署名を検証

というステップを定義しています。nonceは、リプレイ攻撃防止のための乱数
であり、このチャレンジ・レスポンス型の方式は、FIDOでも用いられている
一般的なものです。

〇YANG Module for Basic Challenge-Response-based Remote Attestation
  Procedures
  https://tools.ietf.org/html/draft-birkholz-rats-basic-yang-module-00

上記のチャレンジ・レスポンス型リモート・アテステーションのための、YANG
モジュールを定義したものです。YANGを採用した理由として、既にネットワー
ク機器や仮想サービスの設定で広く普及していることを挙げています。提案
者によれば、既に実装も存在する完成度の高い提案になっているとのことで
す。

〇Time-Based Uni-Directional Attestation
  https://tools.ietf.org/html/draft-birkholz-rats-tuda-00

RFC3161で規定される、TST (Time Stamp Token)などの信頼されたタイムソー
スを利用し、nonce無しで一方向のリモート・アテステーションを実現する方
法を提案しています。上記提案と同様、既に実装もあるそうです。

〇Attested TLS Token Binding
  https://tools.ietf.org/html/draft-mandyam-tokbind-attest-07

Token Bindingにおける、プライベートキーの所有証明の信頼性を高めるた
め、Token Bindingメッセージにアテステーションエビデンスを含める拡張を
提案しています。既にToken Binding WGで2016年に提案されていたアイデア
ですが、あらためてRATSでの標準化をめざしたいとのことです。

〇EAT (The Entity Attestation Token)
  https://tools.ietf.org/html/draft-mandyam-rats-eat-00

リソース制限のあるIoTデバイスでの利用を考慮して、CWT (CBOR Web Token)
ベースの、アテステーションエビデンスのフォーマットを提案しています。
今回の会議にて、EATがリモート・アテステーションの情報モデル議論のたた
き台として採用されることが決まりました。

以上が、RATSの活動の全体像になります。


■ ACME (Automated Certificate Management Environment)

ACME(*3)は、証明書の発行・管理手続きを、自動化するプロトコルを検討し
ているWGです。TLSサーバ証明書の自動発行サービス「Let's Encrypt」で採
用され、広く利用されています。ACMEの概要については、前回IETF 103報告
の拙稿(*4)をご参照ください。

(*3) https://datatracker.ietf.org/wg/acme/about/

(*4) 第103回IETF報告 [第5弾]  ACME WG関連報告
     https://www.nic.ad.jp/ja/mailmagazine/backnumber/2018/vol1650.html

IETF 104では、ACMEプロトコル(メイン仕様)のRFC化がアナウンスされまし
た。IESGレビュー後、2018年9月に後方互換性のない大幅な変更(POST-as-GET
の導入)が加えられる(*3)など紆余曲折を経て、2019年3月にRFC8555として発
行されました。余談ですが、Let's Encryptで使われているACMEのオープン
ソース実装Boulderは、既にPOST-as-GETに対応しており、2019年後半に必須
化すると宣言しています。Let's Encryptを用いて証明書自動更新を行ってい
る場合には、必須化される前にクライアントをアップデートする必要があり
ます。

今回の会合では、以下のトピックが議題として取り上げられました。

- STAR Certificates in ACME
- Third-Party Device Attestation for ACME (新規提案)
- ACME Client Extension (新規提案)
- ACME Challenges Using an Authority Token

本稿では、新たに提案された2件について紹介します。

〇Third-Party Device Attestation for ACME
  https://tools.ietf.org/html/draft-yusef-acme-3rd-party-device-attestation-01

デバイス・アテステーションを前提とした、証明書発行方法に関する提案で
す。Device Authorityという、ACMEサーバとあらかじめ信頼関係をもったデ
バイスベンダの存在を前提としています。デバイスは証明書を取得する際に、
まずDevice Authorityにアクセスし、デバイス認証を前提にトークン(JWT形
式)を取得します。ACMEサーバは、デバイスから(正確には、証明書発行対象
ドメインを管理するACMEクライアントを経由して)トークンとCSRを受け取る
と、トークンを検証し、Device Authorityが発行したものであることが確認
できれば証明書を発行します。

本提案は、用語定義などあいまいな点が多々あるため、今回のWGアイテムへ
の採用は見送られました。今後のブラッシュアップを待って、採用か否かが
再度検討されることになりました。

〇ACME Client Extension
  https://tools.ietf.org/html/draft-moriarty-acme-client-00

ACMEが、クライアント証明書、エンドユーザー証明書、コード署名証明書に
使えるのか？あるいは何らかの拡張が必要か？という、問題提起に近い提案
でした。主だったコメントを紹介すると、クライアント証明書について、
RFC8555は一見するとWebサーバ向けの証明書発行のみを対象にしているよう
に読めるが、証明書内のEKU (Extended Key Usage)にクライアント認証を含
めるかどうかにすぎず、基本的には現仕様の枠内で対応できるのではないか、
という意見が出ました。その他、コード署名証明書について、emailやSMSを
併用した、より厳密な事前認証の仕組みが必要ではないか？という提案者の
問題提起に対して、そもそもemailやSMSを用いることの危険性を指摘する声
や、EV証明書の発行管理の厳密さはACMEが対象とする自動発行の仕組みにそ
ぐわないのではないか、という疑問が呈されました。

現状の提案文書をブラッシュアップした上で、引き続きメーリングリスト上
で、クライアント証明書等の発行に向けて拡張が必要か否かを検討していく
ことになりました。


■ 終わりに

既述の通り、RATSが扱うリモート・アテステーションは、昨今のWebやIoTに
おけるセキュリティ強化の文脈で注目度が高まっている技術です。一方で、
既に他の標準化団体(TCG、FIDO、W3Cなど)や、特定企業(GoogleのAndroid
Keystoreなど)によって、規格化・プラットフォーム開発が進められてきた技
術でもあります。このタイミングでRATSが作られた背景には、相互運用性へ
の要望の高まりがあるのでしょう。RATSによって、既存プラットフォームの
独自フォーマット・検証方式に都度対応しなければならない現状が改善され
ていくことを期待しつつ、今後も動向ウォッチを続けていきたいと思います。


     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
          まわりの方にもぜひNews & Viewsをオススメください！
      転送にあたっての注意や新規登録については文末をご覧ください。
                  ◇              ◇              ◇
       わからない用語については、【JPNIC用語集】をご参照ください。
             https://www.nic.ad.jp/ja/tech/glossary.html
     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃     ◆◇◆◇◆   本号のご感想をお聞かせください   ◆◇◆◇◆     ┃
┃良かった                                                          ┃
┃  http://feedback.nic.ad.jp/1681/6c729c883e0fc521f1ab6950c08ddb7b ┃
┃                                                                  ┃
┃悪かった                                                          ┃
┃  http://feedback.nic.ad.jp/1681/666ea4088475d1946ccdee952bae8964 ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■  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.1681 【臨時号】

 ＠ 発行  一般社団法人 日本ネットワークインフォメーションセンター
          101-0047 東京都千代田区内神田3-6-2 アーバンネット神田ビル4F
 ＠ 問い合わせ先 jpnic-news@nic.ad.jp
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
            本メールを転載・複製・再配布・引用される際には
        https://www.nic.ad.jp/ja/copyright.html をご確認ください
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
   ◇ JPNIC Webにも掲載していますので、情報共有にご活用ください ◇
登録・削除・変更   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), 2019 Japan Network Information Center