IETF116 直前なので「IETF ダンス」について振り返る: 1-Charter

IETF ダンスとは

DANCE とは DANE Authentication for Network Clients Everywhere のことであり，現在 IETF で DANCE WG が組織されています．「IETF ダンス」なる踊りはありません．タイトル詐欺でごめんなさい．

一連のブログポストで DANCE について書いていきます．

Charter を読む

本記事ではまず WG の設立趣意書である Charter (cahrter-ietf-dance-01)を読んでいきます．原文はこちら をご参照ください．本記事はお気持ちで翻訳であり，一部はしょっています．

本文書は執筆時点で Approved となっており，最終更新は 2022 年 3 月 23 日です．

Objective

DANCE WG は RFC6698 の DANE を拡張し，証明書もしくは生の公開鍵 (Raw Public Keys; RPK) を用いて TLS クライアント認証を提供することを目的とします．

Problem Statement

公開鍵認証における identity の信頼を確立する過程では，一般的に PKI と，公開鍵を交換するもの同士で共有された PKI の信頼の根源 (root of trust) を使用します．

一方で，DNSSEC を用いた DNS 名前空間はインターネット上で最も広範に認知される名前空間と認証付き検索メカニズムを構成します．DANE はこの上で公開鍵に基づく TLS サーバ認証を可能にしますが，TLS クライアント認証については定めていません．

異なる CA から発行された identity に対応するため，アプリケーションの所有者は，限定的な CA セットを持つプライベート PKI を埋め込む，ということを頻繁に行います．これは大きな環境のうち異なる部分では相互に通信できないというサイロ効果を生みます．その点で，DANE が使える例として SMTP 通信でのクライアント認証，TLS を用いた DNS 権威サーバ間でのゾーン転送，DNS リカーシブサーバへの認証，IoT デバイスの識別などがあります．

Scope of Work

DANCE では，DANE を用いた TLS クライアント認証の利用例と，重要なコンポーネント及び通信パターンのアーキテクチャを定義します．

DANCE では TLS WG と協力して DANE を用いた TLS クライアント認証に必要な TLS プロトコルアップデートも行います．

DANCE はまず TLS クライアント認証のみをスコープにおきます．将来的にはモノのセキュリティや他のプロトコルでの認証に使うクライアント識別子についてもスコープを拡張するかも知れません．

Deliverables

• DANCE のアーキテクチャと利用例 (IoT, SMTP クライアント，DNS サービスへの認証など) のドキュメント
• DANE クライアント認証とその公開の手法
• DANE に対応しているか，クライアントの DANE での名前はなんかを表す TLS 拡張

感想など

DANCE は DANE に基づいたプロトコルなので，まずは DANE の概要や思想，アーキテクチャのなんとなく理解しないと意味が分からないと思います．余裕があればその記事も書きます．

DANE では TLS を用いたサーバの識別・認証はできるけど，クライアント側の識別・認証はできないから，それを可能にするのが DANCE の主な目的です．個人的には，自分の研究にも関連があり Charter でも触れられている「その機器たちが DANE に対応しているとどうやって識別するの?」「DANE 非対応だったとき，DANE 認証に失敗したときってどう動作すれば良いの?」ということの解決が一番興味があります．Charter では TLS のプロトコル自体を拡張することでこの問題を解決することを目指しているようです．

実は先日の ICANN76 にて，DANCE WG の Chair である Wes Hardaker と話す機会があったのですが，そこで自分の研究について話してみるとやはりこの点に一番興味があったようでした．それを含めて 2, 3 個ほど課題点を議論したんですが，5 分かそこらで英語がズタズタの日本人学生の研究を理解してその議論に持って行けると言うのは，やっぱり専門家かなわねえなと思いました．．．

やる気が向けば，現時点で発行されている draft 3 つについても同様にブログに書くつもりです．ただ今回みたいな全訳に近いお気持ち翻訳は難しいので，かいつまんで書くと思います．