Connection Identifiers for DTLS 1.2
voluntasConnection Identifiers for DTLS 1.2
2021-06-28 時点での DeepL Pro による翻訳。
voluntasDTLS 1.2の接続識別子
概要
本文書は，DTLS プロトコル バージョン 1.2 のコネクション ID（CID）構成を規定する。
CIDは、受信者が適切なセキュリティアソシエーションを選択するための追加情報を提供する、レコード層ヘッダに含まれる識別子である。古典的な "DTLS "では、受信するDTLSレコードのセキュリティアソシエーションの選択は、5タプルの助けを借りて行われます。もし、DTLSセッションが継続している間に、送信元IPアドレスや送信元ポートが変更された場合、受信者は正しいセキュリティ・コンテキストを見つけることができません。
また、CIDを用いた新しい暗号文レコードフォーマットは、コンテンツタイプの暗号化とレコード層のパディングを提供します。
voluntas1. はじめに
DTLS（Datagram Transport Layer Security）[RFC6347]は、UDPのようなコネクションレスのトランスポートの安全性を確保するために設計されたプロトコルです。DTLS は、TLS と同様にハンドシェイクから始まります。ハンドシェイクには計算負荷がかかる場合があります（特に公開鍵暗号を使用する場合）。ハンドシェイクに成功すると、対称鍵暗号方式を用いて、データの起源の認証、整合性、機密性の保護が行われます。このような2段階のアプローチにより、エンドポイントは最初のハンドシェイクのコストを後続のアプリケーションデータ保護で償却することができます。理想的には、アプリケーションデータを保護する第2段階が長期間続くことです。確立された鍵は、鍵の有効期限が切れたときにのみ更新する必要があるからです。
RFC 6347で規定されているDTLSでは、DTLSアソシエーションを識別するために、相手のIPアドレスとポートが使用されます。残念ながら、NATのリバインディングなどでは、これらの値では不十分な場合があります。これは、モノのインターネットにおいて、デバイスがバッテリーの寿命を延ばすために長時間のスリープ状態に入る場合に特に問題となります。NATの再結合は、接続の失敗につながり、その結果、新たなハンドシェイクのコストが発生します。
本文書では、DTLS 1.2の拡張機能として、DTLSのレコード層にコネクションID（CID）を追加することを定義しています。CIDの存在は、DTLSの拡張機能を介してネゴシエートされます。
暗号文のレコードフォーマットにCIDを追加することで、レコードフォーマットに他の変更を加える機会が得られます。TLS 1.3で確立されたベストプラクティスに従い、レコードのタイプは暗号化され、平文の長さを難読化するためのパディングを追加するメカニズムが提供されています。
voluntas- connection_id" エクステンション
このドキュメントでは、ClientHello と ServerHello メッセージで使用される "connection_id" エクステンションを定義しています。
エクステンションタイプは以下のように規定されています。
enum {
connection_id(TBD1), (65535)
} ExtensionType;
この拡張機能の extension_data フィールドは、ClientHello に含まれる場合、ConnectionId 構造体を含まなければなりません（MUST）。この構造体には、クライアントがサーバにメッセージを送信する際に使用してほしいCID値が含まれています。ゼロ長の CID 値は、クライアントが CID を使用して送信する準備はできているが、送信時にサーバーが CID を使用することを望んでいないことを示します。
struct {
opaque cid<0..2^8-1>;
} ConnectionId;
CIDの使用を希望するサーバは、ServerHelloの中に "connection_id "という拡張子をつけて応答します。この拡張子には、クライアントがメッセージを送信する際に使用して欲しいCIDが含まれています。ゼロ長の値は、サーバーがクライアントのCIDを使用して送信するが、クライアントが送信時にCIDを含めることを望まないことを示します。
各当事者は、暗号化されたレコードのCIDとして受信したい「connection_id」エクステンションの値を送信するため、エンドポイントはこのような接続識別子に配備に応じた一定の長さを使用することが可能です。これにより、例えば問題の長さをコンパイル時の定数とすることで、解析や接続の検索を容易にすることができる。このような実装でも、異なる長さのCIDを他の相手に送ることができなければなりません（MUST）。CIDの長さの情報はレコード自体に含まれていないので、可変長のCIDを使いたい実装は、受信時にその長さを判断できるようにCIDを構築する責任があります。
DTLS 1.2では、CIDはDTLSセッションの開始時にのみ交換されます。DTLS 1.2では一般的に、他のハンドシェイクを開始しないTLS 1.3スタイルのポストハンドシェイクメッセージを許可していないため、セッションの途中で新しいCIDを確立できるような専用の「CID更新」メッセージはありません。DTLSセッションが再開されたり、再交渉されたりすると、"connection_id "拡張は新たに交渉される。
DTLS ピアが CID の使用をネゴシエートしていない場合、あるいは、ある方向に対して長さゼロの CID がアドバタイズされている場合、RFC 6347 で定義されたレコードフォーマットとコンテンツタイプを使用して、指定された方向に送信しなければなりません（MUST）。
DTLS ピアが特定の方向にゼロレングスではない CID を使用することをネゴシエートした場合、暗号化が有効になると、セクション 5 で定義された新しい MAC 計算とコンテントタイプ tls12_cid を持つ、図 3 で定義されたレコードフォーマットで送信しなければなりません（MUST）。平文のペイロードでは、新しいレコード形式やCIDコンテンツタイプを使用することはありません。
受信時、tls12_cidコンテンツタイプが設定されている場合、CIDは接続とセキュリティアソシエーションの検索に使用されます。tls12_cidコンテンツタイプが設定されていない場合は、5タプルによってコネクションとセキュリティアソシエーションが検索され、ゼロ長ではないCIDが期待されているかどうかのチェックが行われなければなりません(MUST)。検索されたアソシエーションにゼロ長ではないCIDが予想される場合、[RFC6347]のセクション4.1.2.1で説明されているように、データグラムは無効として扱われなければなりません（MUST）。
tls12_cidコンテンツタイプのデータグラムを受信する際には、セクション5で定義されている新しいMAC計算が使用されなければなりません（MUST）。RFC 6347 で定義されたレコード形式のデータグラムを受信する際には、[RFC6347]の 4.1.2 節で定義された MAC 計算が使用されなければなりません（MUST）。
voluntas4. レコード層の拡張
本仕様では、DTLS 1.2のレコード層フォーマットを定義し、[I-D.ietf-tls-dtls13]では、DTLS 1.3でCIDを伝送する方法を規定しています。
受信者がレコードにCIDがあるかどうかを判断できるようにするために、この拡張をネゴシエートしたコネクションでは、識別レコードタイプtls12_cid(TBD2)を使用しています。このコンテンツタイプの使用には、以下の3つの意味があります。
- CIDフィールドが存在し、1バイト以上を含む。
- CIDフィールドが存在し、1バイト以上含まれている。MACの計算はセクション5で説明したプロセスに従う。
- 本当のコンテンツタイプは、後述するように、暗号化エンベロープの中にある。
プレーンテキストレコードは、この拡張の影響を受けません。したがって、図1に示すように、DTLSPlaintext構造のフォーマットは変更されていません。
struct {
ContentType type;
ProtocolVersion version;
uint16 epoch;
uint48 sequence_number;
uint16 length;
opaque fragment[DTLSPlaintext.length];
} DTLSPlaintext;
図1：DTLS 1.2 プレーンテキストレコードのペイロード。
CIDを使用する場合、送信するコンテンツは、まずコンテンツタイプとオプションのパディングとともに、DTLSInnerPlaintext構造体にラップされます。この新しく導入された構造体を図2に示します。
struct {
opaque content[length];
ContentType real_type;
uint8 zeros[length_of_padding];
} DTLSInner
図2：新しいDTLSInnerPlaintextペイロード構造
コンテンツ
指定された長さのフラグメントに対応します。
リアルタイプ
クリアテキストのペイロードを記述するコンテンツタイプ。
ゼロ
typeフィールドの後に、任意の長さのゼロ値のバイトが平文で現れることがある。これにより、送信者は、レコードサイズの制限内であれば、任意のDTLSレコードを任意の量で埋めることができる。詳細は、[RFC8446]のセクション5.4を参照してください。(RFC8446のTLSInnerPlaintextという用語は、本仕様ではDTLSInnerPlaintextを指すことに注意してください)。
その後、DTLSInnerPlaintextのバイト列が暗号化されます。図 3 に示す DTLSCiphertext 構造体を作成するために、CID が追加される。
struct {
ContentType outer_type = tls12_cid;
ProtocolVersion version;
uint16 epoch;
uint48 sequence_number;
opaque cid[cid_length]; // New field
uint16 length;
opaque enc_content[DTLSCiphertext.length];
} DTLSCiphertext;
図3：DTLS 1.2のCID強化された暗号文レコード。
アウタータイプ
CIDを含むDTLSCiphertextレコードのアウターコンテンツタイプは、常にtls12_cid(TBD2)に設定される。レコードの本当のコンテンツタイプは、復号後にDTLSInnerPlaintext.real_typeで求められる。
cid
拡張機能のネゴシエーション時に合意されたCID値（cid_lengthバイト長）。前述のように、各ピアは受信して接続を識別するために使用するCID値を選択するため、実装は常に固定長のCIDを受信することを選択できます。しかし、異なる長さのCIDを受信することを選択した場合、どの接続（したがって、どのCIDの長さ）が使用されているかを決定するための他のメカニズムがないため、割り当てられたCID値は自己決定されなければなりません。
enc_content
シリアル化されたDTLSInnerPlaintext構造体の暗号化された形式である。
他のすべてのフィールドは、RFC 6347 で定義されているとおりです。
voluntas5. レコードペイロードの保護
TLS および DTLS で使用するためにいくつかのタイプの暗号が定義されており、それらの暗号の MAC 計算は若干異なります。
本仕様では、コンテントタイプが tls12_cid のレコードについて、[RFC6347]と[RFC7366]で定義されている MAC 計算と、[RFC6347]で提供されている AEAD 暗号で使用される追加データの定義を修正しています。修正したアルゴリズムは、CIDを持たないレコード（コンテントタイプがtls12_cid以外のレコード）には適用してはならない（MUST NOT）。
以下のフィールドはこのドキュメントで定義されており、その他のフィールドは引用されたドキュメントで定義されています。
CID
ネゴシエートされたCIDの値（可変長）。
cid_length
交渉したCIDの長さを示す1バイトのフィールド。
長さ_of_DTLSInnerPlaintext
シリアライズされたDTLSInnerPlaintextの長さ（バイト）（2バイトの整数）。この長さは2^14を超えてはなりません。
SEQ_NUM_PLACEHOLDER
0xffの8バイト
注）「+」は連結を表す。
5.1. ブロックサイファー
以下のMACアルゴリズムは、[RFC7366]で説明されているEncrypt-then-MAC処理を使用しないブロック暗号に適用されます。
MAC(MAC_write_key,
seq_num_placeholder +
tls12_cid +
cid_length +
tls12_cid +
DTLSCiphertext.version +
epoch +
sequence_number +
cid +
length_of_DTLSInnerPlaintext +
DTLSInnerPlaintext.content +
DTLSInnerPlaintext.real_type +
DTLSInnerPlaintext.zeros
);
この構造の根拠は、接続IDを持たないDTLS用のMAC入力と、接続IDを持つMAC入力を分離するためである。前者は、常にシーケンス番号の後にtls12_cid以外のコンテンツタイプが続き、後者は、常にseq_num_placeholderの後にtls12_cidが続く。2^64-1は有効なシーケンス番号になる可能性がありますが、接続IDが使用されていない場合、tls12_cidが有効なコンテンツタイプになることはありません。さらに、epochとsequence_numberは、有線で表示されるのと同じ順番でMACに入力されるようになりました。
5.2. Encrypt-then-MAC処理を行うブロックサイファー
以下のMACアルゴリズムは、[RFC7366]で説明されているEncrypt-then-MAC処理を使用するブロック暗号に適用される。
MAC(MAC_write_key,
seq_num_placeholder +
tls12_cid +
cid_length +
tls12_cid +
DTLSCiphertext.version +
epoch +
sequence_number +
cid +
DTLSCiphertext.length +
IV +
ENC(content + padding + padding_length));
5.3. AEAD サイファー
追加データ付きの認証済み暗号を利用する暗号では、追加データの計算に以下のような変更が加えられます。
additional_data = seq_num_placeholder +
tls12_cid +
cid_length +
tls12_cid +
DTLSCiphertext.version +
epoch +
sequence_number +
cid +
length_of_DTLSInnerPlaintext;
6. ピア・アドレスの更新
DTLS接続に現在関連付けられているアドレスとは異なる送信元アドレスを持つCID付きレコードを受信した場合、以下の3つの条件が満たされない限り、受信者は相手へのレコード送信に使用しているアドレスを、受信したデータグラムに指定されている送信元アドレスに置き換えてはならない（MUST NOT）。
- 受信したデータグラムが、DTLSレコード層の処理手順を用いて暗号検証されていること。
- 受信したデータグラムが、受信した最新のデータグラムよりも（エポック番号とシーケンス番号の両方の点で）「新しい」こと。相手のアドレスが変更される前に送信された並び替えられたデータグラムは、そうでなければ、有効なアドレス変更が元に戻されてしまう可能性があります。これにより、攻撃者が再生されたデータグラムを使用して偽のアドレス変更を行うことができなくなり、サービス拒否が発生する可能性があります。攻撃者がソースアドレスを書き換えることができ、再生されたパケットがオリジナルのパケットよりも先に到着した場合、攻撃者は相手のアドレス変更に成功する可能性があります。
- 新しいピアアドレスがDTLSレコードを受信して処理できるようにするための戦略がある。本仕様では、この戦略は義務付けられていませんが、下記の注釈(*)を参照してください。
上記の条件は、アドレスが偽装されたデータグラムやリプレイされたデータグラムを利用して攻撃を仕掛ける攻撃から守るために必要である。なお、DTLS 1.2の4.1.2.6項で定義されているアンチリプレイウィンドウの仕組みを使用するための条件はありません。アンチ・リプレイ・ウィンドウ "と "newer "アルゴリズムの両方の解決策は、アドレスの更新をリプレイ攻撃から防ぎますが、後者は相手のアドレス更新にのみ適用され、前者はあらゆるアプリケーション層のトラフィックに適用されます。
なお、DTLSの暗号検証手続きを通過したものの、相手のアドレス変更のトリガーとならなかったデータグラムは、依然として有効なDTLSレコードであり、アプリケーションに渡す必要があります。
(*)注：偽装アドレスに対する保護を実装するアプリケーション・プロトコルは、必要なメカニズムを作動させるために、相手のアドレスの変更を認識することに依存しています。このようなイベントが配信された場合、アプリケーション層固有のアドレス検証メカニズムを起動することができます。例えば、相手との最小限のping-pongトラフィックの交換に成功したことに基づいたメカニズムです。また、[I-D.ietf-tls-dtls-rrc]で説明されているようなDTLS固有のメカニズムを使用することもできる。
DTLSの実装では、不正なMACを持つレコードや無効なレコードを静かに破棄しなければならない（MUST）。
voluntas7. 例
図4は、CIDがクライアントからサーバーへの一方向に使用される交換の例を示しています。connection_id」という拡張子の中に長さゼロのCIDがあることを示すために、「connection_id=empty」という表記を使用しています。
Client Server
------ ------
ClientHello -------->
(connection_id=empty)
<-------- HelloVerifyRequest
(cookie)
ClientHello -------->
(connection_id=empty)
(cookie)
ServerHello
(connection_id=100)
Certificate
ServerKeyExchange
CertificateRequest
<-------- ServerHelloDone
Certificate
ClientKeyExchange
CertificateVerify
[ChangeCipherSpec]
Finished -------->
<CID=100>
[ChangeCipherSpec]
<-------- Finished
Application Data ========>
<CID=100>
<======== Application Data
Legend:
<...> indicates that a connection id is used in the record layer
(...) indicates an extension
[...] indicates a payload other than a handshake message
図4：CIDを使ったDTLS 1.2の交換例
注：この交換例では、暗号化が有効になると、CIDがレコード層に含まれるようになります。DTLS 1.2では、Finishedメッセージという1つのハンドシェークメッセージのみが暗号化されます。この例では、クライアントからサーバーに送信されるペイロードにCIDを使用する方法を示しているため、Finishedメッセージまたはアプリケーションデータを含むレコード層のペイロードのみがCIDを含みます。
voluntas8. プライバシーへの配慮
CIDは、これまで使用されていた5タプルに代わるもので、DTLS接続の有効期間中、永続的に残る識別子を導入するものです。すべての識別子には、[RFC6973]で説明されているように、リンク可能性のリスクがあります。
DTLSクライアントとDTLSサーバ間のDTLSプロトコルの交換を観察しているオンパスアドバサリーは、観察したペイロードを、同じIDペアを持つ後続のすべてのペイロードにリンクさせることができる（双方向通信の場合）。マルチホーミングやモビリティがない場合、CIDの使用は5タプルと同じ情報を公開することになる。
マルチホーミングの場合、パッシブな攻撃者は、2つのパスの通信の相互作用を相関させることができます。DTLS 1.2にはCIDの更新機構がないため、この拡張機能は、相関関係を考慮しなければならないモビリティシナリオには不向きです。マルチホーミング環境でDTLSを使用し、これらの点を懸念する導入企業は、DTLS 1.2のCIDの使用を拒否し、CIDの更新メカニズムが提供され、シーケンス番号の暗号化が可能なDTLS 1.3に切り替えるべきである。
本仕様では、CID拡張レコード層にレコードパディングを導入しています。これは、オリジナルのDTLS 1.2仕様では利用できなかったプライバシー機能です。これは、DTLS 1.2仕様にはなかったプライバシー機能です。パディングにより、暗号文のサイズを大きくすることができるため、トラフィックの解析がより困難になります。レコードパディングの詳細については、RFC8446のセクション5.4および付録E.3に記載されています。
最後に、エンドポイントはCIDを利用して、特定の接続で受信した各レコードに、接続ごとの任意のメタデータを添付することができます。これは、接続ごとの情報をオンパスのオブザーバーに伝えるためのメカニズムとして使用できます。任意の値を含むCIDでこの問題に対処するための簡単な方法はありません。この点を懸念する実装は、CIDの使用を拒否すべきである。
voluntas9. セキュリティに関する考察
DTLSピアは、真のアドレス更新イベント（例えばNATのリバインディングによる）と悪意のあるものを区別する手段を持たないため、オンパスの敵は第三者に対してリフレクション攻撃を行うことができる。この攻撃は、リクエストが小さく、レスポンスが大きい場合に特に懸念されます。アドレスの更新については、セクション6を参照してください。
さらに、2つのDTLSピア間でやりとりされるデータトラフィックを観測できる攻撃者は、IPアドレス/ポート番号を変更したデータグラムを再生することができます。
ピアのアドレス更新の話題は、セクション6で説明します。
voluntas10. IANAに関する検討事項
本文書では、IANAに対して3つのアクションを要求しています。
10.1. TLS ExtensionType Valuesレジストリへの追加カラム
IANAは、拡張機能がDTLSにのみ適用可能かどうかを示すために、「TLS ExtensionType Values」レジストリに「DTLS-Only」という名前の追加カラムを追加し、レジストリの追加参照として本文書を含めることを要求する。
10.2. TLS ExtensionType Values」レジストリへの登録
IANAは、既存の「TLS ExtensionType Values」レジストリに、以下の表に記載されているconnection_id(TBD1)のエントリを割り当てることを要求されている。値53は、本文書の前バージョンの早期割り当てによって割り当てられていますが、本文書とは互換性がありません。本文書の公開が承認されると、早期割り当ては廃止され、本割り当てが採用されます。
Value Extension Name TLS 1.3 DTLS-Only Recommended Reference
--------------------------------------------------------------------
TBD1 connection_id CH, SH Y N [[This doc]]
レジストリに新しい列「DTLS-Only」が追加される。有効なエントリは、拡張機能がDTLSにのみ適用される場合は "Y"、それ以外は "N "である。既存のエントリにはすべて「N」という値が与えられます。
注：この拡張機能は特定のユースケースのみを想定しているため、「Recommended」欄の値「N」が設定されています。本文書では、DTLS 1.2のみに対する本拡張の動作を説明している。TLSには適用されず、DTLS 1.3での使用法は[I-D.ietf-tls-dtls13]に記載されている。
10.3. TLS ContentTypeレジストリへの登録
IANAは、「TLS ContentType」レジストリにtls12_cid(TBD2)を割り当てることを要求されている。tls12_cid ContentTypeは、DTLS 1.2にのみ適用される。