9. Securing CoAP (CoAPのセキュリティ保護)
このセクションでは、CoAPのDTLSバインディングを定義します。
プロビジョニングフェーズ中に、CoAPデバイスには、キーイングマテリアルやアクセス制御リストを含む、動作に必要なセキュリティ情報が提供されます。本仕様では、Section 9.1.3.2.1でRawPublicKeyモードの設定を定義します。プロビジョニングフェーズの終わりに、デバイスは4つのセキュリティモードのいずれかになり、以下に説明するそのモードの情報を持つことになります。NoSecおよびRawPublicKeyモードは、本仕様の実装必須モードです。
NoSec: プロトコルレベルのセキュリティはありません (DTLSは無効)。適切な場合は、下位層のセキュリティを提供する代替技術を使用すべきです。IPsecの使用は [IPsec-CoAP] で議論されています。制約されたノードで使用される特定のリンク層は、リンク層セキュリティも提供し、適切な鍵管理の下で適切である場合があります。
PreSharedKey: DTLSが有効になっており、事前共有鍵 [RFC4279] のリストがあり、各鍵には、Section 9.1.3.1で説明されているように、通信に使用できるノードのリストが含まれています。極端な場合、このCoAPノードが通信する必要がある各ノードに対して1つの鍵がある場合があります (1:1ノード/鍵比率)。逆に、2つ以上のエンティティが特定の事前共有鍵を共有する場合、この鍵は、エンティティがそのグループのメンバーとして認証できるようにするだけであり、特定のピアとして認証できるようにするものではありません。
RawPublicKey: DTLSが有効になっており、デバイスには証明書なしの非対称鍵ペア (生の公開鍵) があり、Section 9.1.3.2で説明されているように、帯域外メカニズム [RFC7250] を使用して検証されます。デバイスには、公開鍵から計算されたIDと、通信できるノードのIDのリストもあります。
Certificate: DTLSが有効になっており、デバイスには、Section 9.1.3.3で説明されているように、サブジェクトにバインドし、共通のトラストルートによって署名されたX.509証明書 [RFC5280] を持つ非対称鍵ペアがあります。デバイスには、証明書の検証に使用できるルートトラストアンカーのリストもあります。
"NoSec"モードでは、システムは単にIP上の通常のUDP経由でパケットを送信します。これは"coap"スキームとCoAPデフォルトポートによって示されます。システムは、攻撃者がCoAPノードを持つネットワークからパケットを送受信できないようにすることによってのみ保護されます; このアプローチの追加の複雑さについてはSection 11.5を参照してください。
他の3つのセキュリティモードはDTLSを使用し、"coaps"スキームとDTLS保護されたCoAPデフォルトポートによって示されます。結果は、認証 (セキュリティモデルの制限内で) に使用でき、この認証に基づいて通信パートナーを承認できるセキュリティアソシエーションです。CoAP自体は、認証または承認のためのプロトコルプリミティブを提供しません; これが必要な場合は、通信セキュリティ (つまり、IPsecまたはDTLS) またはオブジェクトセキュリティ (ペイロード内) によって提供できます。一部の操作に承認を必要とするデバイスは、これら2つの形式のセキュリティのいずれかを必要とすることが期待されます。必然的に、プロキシで通信セキュリティが使用される場合、これはそのプロキシが信頼関係の一部である場合にのみ機能します。CoAPは、クライアントが中間者と持つ可能性のあるさまざまな承認レベルを、さらなる中間者またはオリジンサーバーに転送する方法を提供しません -- これはHTTPと共有される問題であり、最初の中間者がすべての承認を実行することが慣例です。
9.1. DTLS-Secured CoAP (DTLS保護されたCoAP)
HTTPがTCP上のトランスポート層セキュリティ (TLS) を使用して保護されるのと同様に、CoAPはUDP上のDatagram TLS (DTLS) [RFC6347] を使用して保護されます (図13を参照)。このセクションでは、制約された環境に適した最小限の実装必須設定とともに、CoAPのDTLSへのバインディングを定義します。バインディングは、ユニキャストCoAPへの一連の差分によって定義されます。実際、DTLSは、UDPトランスポートの信頼性のない性質を処理するための追加機能を持つTLSです。
+----------------------+
| Application |
+----------------------+
+----------------------+
| Requests/Responses |
|----------------------| CoAP
| Messages |
+----------------------+
+----------------------+
| DTLS |
+----------------------+
+----------------------+
| UDP |
+----------------------+
図 13: DTLS保護されたCoAPの抽象レイヤー
一部の制約されたノード (制限されたフラッシュおよび/またはRAM) およびネットワーク (制限された帯域幅または高いスケーラビリティ要件)、および使用される特定の暗号スイートに応じて、DTLSのすべてのモードが適用可能とは限りません。一部のDTLS暗号スイートは、セキュリティアソシエーションのセットアップに必要な初期ハンドシェイクオーバーヘッドだけでなく、実装の複雑さを大幅に増加させる可能性があります。初期ハンドシェイクが完了すると、DTLSは、初期化ベクトル/nonce (例: TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]の場合は8バイト)、整合性チェック値 (例: TLS_PSK_WITH_AES_128_CCM_8 [RFC6655]の場合は8バイト)、および暗号スイートに必要なパディングを除いて、約13バイトの限定されたデータグラムごとのオーバーヘッドを追加します。DTLSの特定のモードがCoAPベースのアプリケーションでの使用に適用可能かどうかは、適用可能な特定の暗号スイート、セッション維持がアプリケーションフローと互換性があるかどうか、および制約されたノードと追加のネットワークオーバーヘッドに十分なリソースがあるかどうかを考慮して、慎重に検討する必要があります。(DTLSを使用する一部のモードでは、本仕様は実装必須の暗号スイートを識別します; これは、これらの暗号スイートが実際に適切である場合に相互運用性を最大化するための実装要件です。アプリケーションの特定のセキュリティポリシーは、使用できる実際の暗号スイートのセットを決定する場合があります。) DTLSは、グループキーイング (マルチキャスト通信) には適用できません; ただし、将来のグループキー管理プロトコルのコンポーネントである可能性があります。
9.1.1. Endpoint Identity (エンドポイントID)
"coaps"スキームは"coap"スキームに基づいており、[RFC3986]のSection 11.1のセキュリティ上の考慮事項も適用されます。"coaps"スキームによって提供されるセキュリティは、IP層 (IPsec) またはトランスポート層 (DTLS) にあります; その結果、中間者は"coaps"メッセージを開いたり閉じたりできますが、アプリケーション層の整合性チェックの正しさを確認することはできます。これは、HTTP/CoAPクロスプロトコルプロキシにとって特に重要です (Section 10を参照)。また、グループキーはマルチキャスト通信の機密性を提供するために使用できますが、発信元を検証するために使用することはできません (Section 11.3)。
9.1.2. Security Modes (セキュリティモード)
Section 9の冒頭で説明した4つのセキュリティモードは、DTLSを使用するか、CoAPプロトコルレベルでセキュリティなしで実装されます。実装要件 (実装必須など) は、Section 9.1.6で見つけることができます。
9.1.3. Pre-Shared Keys (事前共有鍵)
9.1.3.1. PSK Mode (PSKモード)
DTLSは、事前共有鍵 (PSK) の使用をサポートしています。[RFC4279]で説明されているように、事前共有鍵を使用したDTLSは、認証と機密性を可能にします。[RFC4279]で指定されているPSKモードは、このモードを実装するDTLS対応CoAPノードによってサポートされます。
[RFC7251]でCoAPでの使用のためにプロファイルされたTLS_PSK_WITH_AES_128_CCM_8は、このモードを実装するCoAPノードの実装必須暗号スイートです。
一部のデプロイメントは、PSKの代わりに証明書、生の公開鍵、または他の認証方法を使用する必要がある場合があります。CoAP実装が最も幅広いデプロイメントで有用であることを望む場合は、定義された4つのセキュリティモードすべてをサポートする必要があります。
9.1.3.2. RawPublicKey Mode (RawPublicKeyモード)
[RFC7251]でプロファイルされたTLS_ECDHE_ECDSA_WITH_AES_128_CCM_8は、このモードを実装するCoAPノードの実装必須暗号スイートです。このモードの実装は、生の公開鍵を送受信するために [RFC7250] を使用しなければなりません。
9.1.3.2.1. Provisioning (プロビジョニング)
RawPublicKeyモードには、デバイスキーイングマテリアル (非対称鍵、トラストアンカーマテリアル) の適切なプロビジョニングが必要です。
実装は、いわゆる暗黙的プロビジョニングを介して、帯域外の方法を使用してキーイングマテリアルを決定することを選択できます。
あるいは、暗黙的プロビジョニングに加えて、実装は生の公開鍵に基づくインバンドプロビジョニングプロトコルの使用をサポートしてもかまいません。完全なインバンドプロビジョニングプロトコルは、ブートストラッププロトコルの上にのみ構築できることに注意してください。
9.1.3.3. Certificate Mode (証明書モード)
[RFC7251]でプロファイルされたTLS_ECDHE_ECDSA_WITH_AES_128_CCM_8は、このモードを実装するCoAPノードの実装必須暗号スイートです。このモードの実装は [RFC5280] をサポートしなければなりません。
証明書、および証明書チェーンの構造は、[RFC5280]で指定されているとおりです。[RFC6125]のSection 6.4.3のURI-ID識別子タイプをサポートしなければなりません。
9.1.4. Server Name Indication (サーバー名表示)
制約されたサーバーは、クライアントがどのURI (またはより一般的にどのセキュリティコンテキスト) に関心があるかを簡単に識別する方法を持っていないことがよくあります。実装は、DTLS/TLS [RFC6066] へのServer Name Indication拡張を使用して、着信リクエストを処理するためのセキュリティコンテキストを識別するのに特に役立つ場合があります。
9.1.5. New Associations (新しいアソシエーション)
各エンドポイントは、暗号スイートを含む、アプリケーションおよびシステム要件に従って使用されるセキュリティパラメータを選択します。クライアントがサーバーで新しいセッションを開くと、そのセッションがサーバーに必要なセキュリティパラメータに関連付けられることを要求します。実装必須の暗号スイートは、DTLS操作の各モードのセクション (Sections 9.1.3.1, 9.1.3.2, および9.1.3.3) で定義されています。これらのMTI暗号スイートは、すべてのアプリケーションまたはデプロイメントに適した選択ではない場合があります: それらを無効にして、より適切な可能性のある異なる暗号スイートを使用することが可能です。
9.1.6. DTLS Version (DTLSバージョン)
"PreSharedKey"、"RawPublicKey"、および"Certificate"モードの実装は、DTLSバージョン1.2 [RFC6347] をサポートしなければならず、使用を優先すべきです。実装がピア実装がDTLSバージョン1.0のみに対応していることを検出した場合、相互運用性のためにDTLS 1.0を使用してもかまいません。DTLS 1.0は、DTLS保護されたグループ通信では使用すべきではありません。
9.1.7. DTLS Connection Management (DTLS接続管理)
DTLSハンドシェイクが完了していない限り、ノードはリクエストを送信する前にハンドシェイクが完了するのを待つべきです。ただし、ハンドシェイクが失敗した場合、セキュリティハンドシェイクは失敗したと見なされるべきです。接続管理に関するいくつかの詳細がここで必要ですが、これは仕様の後のバージョンに延期されています。