[要約] 要約：RFC 7966は、非隣接するDiameterノード間の属性値ペア（AVP）レベルのセキュリティに関するシナリオと要件について説明しています。 目的：このRFCの目的は、Diameterプロトコルのセキュリティを向上させ、非隣接するノード間でのAVPレベルの攻撃を防ぐためのガイドラインを提供することです。
Internet Engineering Task Force (IETF) H. Tschofenig
Request for Comments: 7966
Category: Informational J. Korhonen, Ed.
ISSN: 2070-1721 Broadcom Limited
G. Zorn
Network Zen
K. Pillay
Internet Solutions
September 2016
Security at the Attribute-Value Pair (AVP) Level for Non-neighboring Diameter Nodes: Scenarios and Requirements
非隣接Diameterノードの属性値ペア（AVP）レベルでのセキュリティ：シナリオと要件
Abstract
概要
This specification specifies requirements for providing Diameter security at the level of individual Attribute-Value Pairs (AVPs).
この仕様は、個々の属性値ペア（AVP）のレベルでDiameterセキュリティを提供するための要件を指定します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7966.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7966で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2016 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Security Threats . . . . . . . . . . . . . . . . . . . . . . 5
4. Scenarios for Diameter AVP-Level Protection . . . . . . . . . 7
5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
The Diameter base protocol specification [2] defines security protection between neighboring Diameter peers. Diameter mandates that peer connections must be protected by Transport Layer Security (TLS) [6] for TCP, by Datagram TLS (DTLS) [7] for the Stream Control Transmission Protocol (SCTP), or by security mechanisms that are independent of Diameter (such as IPsec [5]). These security protocols offer a wide range of security properties, including entity authentication, data-origin authentication, integrity protection, confidentiality protection, and replay protection. They also support a large number of cryptographic algorithms, algorithm negotiation, and different types of credentials. It should be understood that TLS/DTLS/IPsec in the Diameter context does not provide end-to-end security unless the Diameter nodes are direct peers, i.e., neighboring Diameter nodes. The current Diameter security is realized hop by hop.
Diameter基本プロトコル仕様[2]は、隣接するDiameterピア間のセキュリティ保護を定義しています。 Diameterは、ピア接続をTCPのトランスポート層セキュリティ（TLS）[6]、ストリーム制御伝送プロトコル（SCTP）のデータグラムTLS（DTLS）[7]、またはDiameterとは独立したセキュリティメカニズム（ IPsec [5]など）。これらのセキュリティプロトコルは、エンティティ認証、データオリジン認証、完全性保護、機密性保護、リプレイ保護など、幅広いセキュリティプロパティを提供します。また、多数の暗号化アルゴリズム、アルゴリズムネゴシエーション、さまざまな種類の資格情報もサポートしています。 DiameterコンテキストのTLS / DTLS / IPsecは、Diameterノードが直接のピア、つまり隣接するDiameterノードでない限り、エンドツーエンドのセキュリティを提供しないことを理解する必要があります。現在のDiameterセキュリティは、ホップバイホップで実現されています。
The need to also offer additional security protection of AVPs between non-neighboring Diameter nodes was recognized very early in the work on Diameter. This led to work on Diameter security using the Cryptographic Message Syntax (CMS) [3]. However, due to the lack of deployment interest at that time (and the complexity of the developed solution), the specification was never completed.
隣接しないDiameterノード間のAVPの追加のセキュリティ保護も提供する必要性は、Diameterの作業の非常に早い段階で認識されていました。これにより、Cryptographic Message Syntax（CMS）[3]を使用してDiameterのセキュリティに取り組みました。ただし、その時点ではデプロイメントへの関心が欠けていたため（および開発されたソリューションが複雑であるため）、仕様が完成することはありませんでした。
In the meanwhile, Diameter had received a lot of deployment interest from the cellular operator community, and because of the sophistication of those deployments, the need for protecting Diameter AVPs between non-neighboring nodes resurfaced. Since the early 2000s (when the work on [3] was discontinued), the Internet community has seen advances in cryptographic algorithms (for example, authenticated encryption algorithms), and new security building blocks have been developed.
その間、Diameterは携帯電話事業者のコミュニティから多くの導入の関心を集めていました。それらの導入が洗練されていたため、非隣接ノード間のDiameter AVPを保護する必要性が再浮上しました。 2000年代初頭（[3]の作業が中止されたとき）以来、インターネットコミュニティは暗号化アルゴリズム（たとえば、認証された暗号化アルゴリズム）の進歩を目の当たりにし、新しいセキュリティ構成要素が開発されました。
This document specifies requirements for developing a solution to protect Diameter AVPs between non-neighboring Diameter nodes.
このドキュメントでは、隣接しないDiameterノード間のDiameter AVPを保護するソリューションを開発するための要件を指定します。
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this document are to be interpreted as described in RFC 2119 [1].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [1]で説明されているように解釈されます。
This document reuses terminology from the Diameter base specification [2].
このドキュメントでは、Diameter基本仕様[2]の用語を再利用しています。
In the figures below, AVP refers to an unprotected AVP, and {AVP}k refers to an AVP that experiences security protection (using key "k") without further distinguishing between integrity and confidentiality protection.
以下の図では、AVPは保護されていないAVPを指し、{AVP} kは整合性と機密保護を区別せずに（キー "k"を使用して）セキュリティ保護を経験するAVPを指します。
The following terms are also used in this document:
このドキュメントでは、次の用語も使用されています。
AAA broker
私は仲介します
An entity that manages Authentication, Authorization, and Accounting (AAA) traffic between roaming partner networks.
ローミングパートナーネットワーク間の認証、承認、およびアカウンティング（AAA）トラフィックを管理するエンティティ。
AAA broker network
AAAブローカーネットワーク
A network operated by a AAA broker, which consists of necessary AAA functions to provide AAA brokering services for its customer AAA networks.
AAAブローカーが運営するネットワーク。顧客のAAAネットワークにAAAブローカーサービスを提供するために必要なAAA機能で構成されます。
Diameter firewall
Diameterファイアウォール
A Diameter firewall is a proxy (or a relay) agent that acts similarly to conventional IP traffic firewalls but only at the Diameter AVP and command level. A Diameter firewall may, for example, discard AVPs that violate security policy, thus preventing them from traversing the firewall. The Diameter firewall may even discard entire Diameter messages based on the security policy.
Diameterファイアウォールは、従来のIPトラフィックファイアウォールと同様に機能するプロキシ（またはリレー）エージェントですが、Diameter AVPおよびコマンドレベルでのみ機能します。たとえば、Diameterファイアウォールは、セキュリティポリシーに違反するAVPを破棄し、ファイアウォールを通過できないようにします。 Diameterファイアウォールは、セキュリティポリシーに基づいて、Diameterメッセージ全体を破棄することもできます。
This section describes various security threats that raise the need for protecting Diameter Attribute-Value Pairs (AVPs). Figure 1 illustrates an example of a Diameter-based roaming architecture in which Diameter clients within the visited networks need to interact with Diameter servers in the home domain. AAA domains are interconnected using a Diameter-based AAA interconnection network labeled as "AAA broker network".
このセクションでは、Diameterの属性と値のペア（AVP）を保護する必要があるさまざまなセキュリティの脅威について説明します。図1は、訪問先ネットワーク内のDiameterクライアントがホームドメインのDiameterサーバーと対話する必要があるDiameterベースのローミングアーキテクチャの例を示しています。 AAAドメインは、「AAAブローカーネットワーク」というラベルの付いたDiameterベースのAAA相互接続ネットワークを使用して相互接続されます。
+oooooooooooooooooo+ +====================+
| Example.net | | |
| | | |
+--------+ +--------+ +--------+ +--------+
|Diameter| |Diameter+--------+Diameter| |Diameter|
|Client 1| |Proxy A1| |Proxy B | |Proxy C |
| (NAS) +------+ | +------+ +--------+ |----+
+--------+ +--------+ | +--------+ +--------+ |
| | | | | |
| Visited Domain 1 | | | AAA Broker Network | |
+oooooooooooooooooo+ | +====================+ |
| |
| |
| |
| +\\\\\\\\\\\\\\\\\\\\+ |
| +--------+ Example.com | |
| |Diameter| | |
+oooooooooooooooooo+ | |Server X+--+ +--------+ |
| Example.org | | +--------+ | |Diameter| |
| | | +--------+ +---------+Proxy D |-+
+--------+ +--------+ | |Diameter| | +--------+
|Diameter| |Diameter| | |Server Y+--+ |
|Client 2+------+Proxy A2+-+ +--------+ Home Domain |
| (NAS) | | | +////////////////////+
+--------+ +--------+
| |
| Visited Domain 2 |
+oooooooooooooooooo+
Figure 1: Example Diameter Deployment
図1：Diameterデプロイメントの例
Eavesdropping: Some Diameter applications carry information that is only intended for consumption by end points, either by the Diameter client or by the Diameter server but not by intermediaries. As an example, consider the Diameter Extensible Authentication Protocol (EAP) application [4] that allows the
盗聴：一部のDiameterアプリケーションは、エンドポイントによる消費のみを目的とした情報を伝達します。これは、DiameterクライアントまたはDiameterサーバーによるもので、仲介者によるものではありません。例として、Diameter Extensible Authentication Protocol（EAP）アプリケーション[4]を検討してください。
transport of keying material between the Diameter server to the Diameter client (using the EAP-Master-Session-Key AVP) for the protection of the air interface (i.e., the wireless link) between the end device (such as a mobile phone; not shown in the figure) and the Network Access Server (NAS). The content of the EAP-Master-Session-Key AVP should benefit from protection against eavesdropping by intermediaries. Other AVPs (for example, those listed in Section 13.3 of [2]) might also carry sensitive personal data that, when collected by intermediaries, allow for traffic analysis.
（EAP-Master-Session-Key AVPを使用して）DiameterサーバーからDiameterクライアントにキーイングマテリアルを転送し、エンドデバイス（携帯電話など）間のエアインターフェイス（つまり、ワイヤレスリンク）を保護します。図に示されています）およびネットワークアクセスサーバー（NAS）。 EAP-Master-Session-Key AVPのコンテンツは、仲介者による盗聴からの保護の恩恵を受けるはずです。他のAVP（たとえば、[2]のセクション13.3にリストされているもの）も、仲介者が収集したときにトラフィック分析を可能にする機密の個人データを運ぶ可能性があります。
In the context of the deployment shown in Figure 1, the adversary could, for example, be in the AAA broker network.
図1に示されている展開のコンテキストでは、たとえば、攻撃者はAAAブローカーネットワークにいる可能性があります。
Injection and Manipulation: The Diameter base protocol specification mandates security protection between neighboring nodes, but Diameter agents may be compromised or misconfigured and inject or manipulate AVPs. To detect such actions, additional security protection needs to be applied at the Diameter layer.
インジェクションと操作：Diameter基本プロトコル仕様では、隣接ノード間のセキュリティ保護が義務付けられていますが、Diameterエージェントが危険にさらされたり、誤構成されたりして、AVPが挿入または操作される可能性があります。このようなアクションを検出するには、Diameterレイヤーで追加のセキュリティ保護を適用する必要があります。
Nodes that could launch such an attack are any Diameter agents along the end-to-end communication path.
このような攻撃を開始する可能性のあるノードは、エンドツーエンドの通信パスに沿った任意のDiameterエージェントです。
Impersonation: Imagine a case where a Diameter message from Example.net contains information claiming to be from Example.org. This would either require strict verification at the edge of the AAA broker network or cryptographic assurance at the Diameter layer to prevent a successful impersonation attack.
なりすまし：Example.netからのDiameterメッセージに、Example.orgからのものであると主張する情報が含まれているケースを想像してください。これには、なりすまし攻撃の成功を防ぐために、AAAブローカーネットワークのエッジでの厳密な検証、またはDiameterレイヤーでの暗号保証が必要です。
Any Diameter realm could launch such an attack aiming for financial benefits or to disrupt service availability.
Diameterのどのレルムでも、金銭的な利益を目的として、またはサービスの可用性を混乱させることを目的として、このような攻撃を仕掛けることができます。
This scenario outlines a number of cases for deploying security protection of individual Diameter AVPs.
このシナリオでは、個々のDiameter AVPのセキュリティ保護を展開するためのいくつかのケースについて概説します。
In the first scenario, shown in Figure 2, end-to-end security protection is provided between the Diameter client and the Diameter server with any number of intermediate Diameter agents. Diameter AVPs exchanged between these two Diameter nodes may be protected end to end (notation '{AVP}k') or unprotected (notation 'AVP').
図2に示す最初のシナリオでは、DiameterクライアントとDiameterサーバーの間にエンドツーエンドのセキュリティ保護が提供され、任意の数の中間Diameterエージェントが提供されます。これら2つのDiameterノード間で交換されるDiameter AVPは、エンドツーエンドで保護される（「{AVP} k」という表記）か、保護されない（「AVP」という表記）場合があります。
+--------+ +--------+
|Diameter| AVP, {AVP}k |Diameter|
|Client +-----------------........... -------------------+Server |
+--------+ +--------+
Figure 2: End-to-End Diameter AVP Security Protection
図2：エンドツーエンドのDiameter AVPセキュリティ保護
In the second scenario, shown in Figure 3, a Diameter proxy acts on behalf of the Diameter client with regard to security protection. It applies security protection to outgoing Diameter AVPs and verifies incoming AVPs. Typically, the proxy enforcing the security protection belongs to the same domain as the Diameter client/server without end-to-end security features.
図3に示す2番目のシナリオでは、セキュリティ保護に関して、DiameterプロキシがDiameterクライアントに代わって機能します。発信Diameter AVPにセキュリティ保護を適用し、着信AVPを検証します。通常、セキュリティ保護を実施するプロキシは、エンドツーエンドのセキュリティ機能のないDiameterクライアント/サーバーと同じドメインに属します。
+--------+ +--------+ +--------+
|Diameter| AVP |Diameter| AVP, {AVP}k |Diameter|
|Client +-----+Proxy A +---------- .......... -----------+Server |
+--------+ +--------+ +--------+
Figure 3: Middle-to-End Diameter AVP Security Protection
図3：ミドルエンドのDiameter AVPセキュリティ保護
In the third scenario, shown in Figure 4, a Diameter proxy acts on behalf of the Diameter server.
図4に示す3番目のシナリオでは、DiameterプロキシがDiameterサーバーの代わりに機能します。
+--------+ +--------+ +--------+
|Diameter| AVP, {AVP}k |Diameter| AVP |Diameter|
|Client +-----------------........... ----+Proxy D +-----+Server |
+--------+ +--------+ +--------+
Figure 4: End-to-Middle Diameter AVP Security Protection
図4：End-to-middle Diameter AVPセキュリティ保護
The fourth and the final scenario (see Figure 5) is a combination of the middle-to-end and the end-to-middle scenarios shown in Figures 3 and 4. From a deployment point of view, this scenario is easier to accomplish for two reasons. First, Diameter clients and Diameter servers remain unmodified. This ensures that no modifications are needed to the installed Diameter infrastructure, except for the security-enabled proxies, obviously. Second, the key management is also simplified since a fewer number of keys need to be negotiated and provisioned. The assumption here is that the number of security-enabled proxies would be significantly less than unprotected Diameter nodes in the installed base.
4番目と最後のシナリオ（図5を参照）は、図3と4に示すミドルツーエンドとエンドツーミドルのシナリオを組み合わせたものです。展開の観点から見ると、このシナリオは2つの理由。まず、DiameterクライアントとDiameterサーバーは変更されません。これにより、明らかにセキュリティが有効なプロキシを除いて、インストールされているDiameterインフラストラクチャを変更する必要がなくなります。第2に、ネゴシエーションとプロビジョニングが必要な鍵の数が少ないため、鍵の管理も簡素化されます。ここでの前提は、セキュリティが有効なプロキシの数が、インストールベースの保護されていないDiameterノードよりも大幅に少ないことです。
+--------+ +--------+ +--------+ +--------+
|Diameter| AVP |Diameter| AVP, {AVP}k |Diameter| AVP |Diameter|
|Client +-----+Proxy A +-- .......... ----+Proxy D +-----+Server |
+--------+ +--------+ +--------+ +--------+
Figure 5: Middle-to-Middle Diameter AVP Security Protection
図5：中程度から中程度の直径のAVPセキュリティ保護
Requirement #1: The solution MUST support an extensible set of cryptographic algorithms.
要件＃1：ソリューションは、暗号化アルゴリズムの拡張可能なセットをサポートする必要があります。
Motivation: Solutions MUST be able to evolve to adapt to evolving cryptographic algorithms and security requirements. This may include the provision of a modular mechanism to allow cryptographic algorithms to be updated without substantial disruption to deployed implementations.
動機：ソリューションは、進化する暗号アルゴリズムとセキュリティ要件に適応するように進化できる必要があります。これには、実装された実装を実質的に中断することなく暗号アルゴリズムを更新できるようにするモジュール式メカニズムの提供が含まれる場合があります。
Requirement #2: The solution MUST support confidentiality, integrity, and data-origin authentication. Solutions for integrity protection MUST work in a backwards-compatible way with existing Diameter applications and therefore be able to traverse legacy proxy and relay agents.
要件＃2：ソリューションは、機密性、整合性、およびデータ発信元認証をサポートする必要があります。整合性保護のソリューションは、既存のDiameterアプリケーションと下位互換性のある方法で機能する必要があるため、レガシープロキシおよびリレーエージェントを通過できる必要があります。
Requirement #3: The solution MUST support replay protection.
要件＃3：ソリューションはリプレイ保護をサポートする必要があります。
Requirement #4: The solution MUST support the ability to delegate security functionality to another entity.
要件＃4：ソリューションは、セキュリティ機能を別のエンティティに委任する機能をサポートする必要があります。
Motivation: As described in Section 4, the ability to let a Diameter proxy perform security services on behalf of all clients within the same administrative domain is important for incremental deployability. The same applies to the other communication side where a load balancer terminates security services for the servers it interfaces.
動機：セクション4で説明したように、Diameterプロキシが同じ管理ドメイン内のすべてのクライアントに代わってセキュリティサービスを実行できるようにする機能は、段階的な導入可能性にとって重要です。ロードバランサーがインターフェイスするサーバーのセキュリティサービスを終了する他の通信側にも同じことが当てはまります。
Requirement #5: The solution MUST be able to selectively apply its cryptographic protection to certain Diameter AVPs.
要件＃5：ソリューションは、特定のDiameter AVPに暗号保護を選択的に適用できる必要があります。
Motivation: Some Diameter applications assume that certain AVPs are added, removed, or modified by intermediaries. As such, it must be possible to apply security protection selectively.
動機：一部のDiameterアプリケーションは、特定のAVPが仲介者によって追加、削除、または変更されることを前提としています。そのため、セキュリティ保護を選択的に適用できる必要があります。
Furthermore, there are AVPs that must not be confidentiality protected but may still be integrity protected, such as those required for Diameter message routing.
さらに、Diameterメッセージルーティングに必要なものなど、機密性を保護する必要はないが、完全性は保護されるAVPがあります。
Requirement #6: The solution MUST define a mandatory-to-implement cryptographic algorithm.
要件＃6：ソリューションは、実装に必須の暗号アルゴリズムを定義する必要があります。
Motivation: For interoperability purposes, it is beneficial to have a mandatory-to-implement cryptographic algorithm specified (unless profiles for specific usage environments specify otherwise).
動機：相互運用性の目的で、実装に必須の暗号化アルゴリズムを指定することは有益です（特定の使用環境のプロファイルが別の方法で指定しない限り）。
Requirement #7: The solution MUST support symmetric keys and asymmetric keys.
要件＃7：ソリューションは対称鍵と非対称鍵をサポートする必要があります。
Motivation: Symmetric and asymmetric cryptographic algorithms provide different security services. Asymmetric algorithms, for example, allow non-repudiation services to be offered.
動機：対称暗号アルゴリズムと非対称暗号アルゴリズムは、異なるセキュリティサービスを提供します。たとえば、非対称アルゴリズムにより、否認防止サービスを提供できます。
Requirement #8: A solution for dynamic key management MUST be included in the overall solution framework.
要件＃8：動的キー管理のソリューションは、全体的なソリューションフレームワークに含まれている必要があります。
However, it is assumed that no "new" key management protocol needs to be developed; instead, existing ones are reused, if at all possible. Rekeying could be triggered by (a) management actions and (b) expiring keying material.
ただし、「新しい」鍵管理プロトコルを開発する必要はないと想定されています。可能であれば、既存のものが再利用されます。鍵更新は、（a）管理アクションと（b）鍵情報の期限切れによってトリガーされます。
This entire document focuses on the discussion of new functionality for securing Diameter AVPs selectively between non-neighboring nodes.
このドキュメント全体では、非隣接ノード間で選択的にDiameter AVPを保護するための新機能の説明に焦点を当てています。
Various security threats are mitigated by selectively applying security protection for individual Diameter AVPs. Without protection, there is the possibility for password sniffing, confidentiality violation, and AVP insertion, deletion, or modification. Additionally, applying a digital signature offers non-repudiation capabilities, a feature not yet available in today's Diameter deployment. Modification of certain Diameter AVPs may not necessarily be the act of malicious behavior but could also be the result of misconfiguration. An over-aggressively configured firewalling Diameter proxy may also remove certain AVPs. In most cases, data-origin authentication and integrity protection of AVPs will provide the most benefits for existing deployments with minimal overhead and (potentially) operate in a full-backwards compatible manner.
個々のDiameter AVPにセキュリティ保護を選択的に適用することにより、さまざまなセキュリティの脅威が軽減されます。保護しないと、パスワードの盗聴、機密性の侵害、AVPの挿入、削除、または変更が行われる可能性があります。さらに、デジタル署名を適用すると、否認防止機能が提供されます。これは、現在のDiameterデプロイメントではまだ利用できない機能です。特定のDiameter AVPの変更は、必ずしも悪意のある行為であるとは限りませんが、設定ミスの結果である可能性もあります。過度に設定されたファイアウォールDiameterプロキシも、特定のAVPを削除する場合があります。ほとんどの場合、AVPのデータオリジン認証と整合性保護は、オーバーヘッドを最小限に抑えて既存の展開に最大の利点を提供し、完全に下位互換性のある方法で動作する可能性があります。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[1] Bradner、S.、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。
[2] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, Ed., "Diameter Base Protocol", RFC 6733, DOI 10.17487/RFC6733, October 2012, <http://www.rfc-editor.org/info/rfc6733>.
[2] Fajardo、V.、Ed。、Arkko、J.、Loughney、J.、and G. Zorn、Ed。、 "Diameter Base Protocol"、RFC 6733、DOI 10.17487 / RFC6733、October 2012、<http：// www。 rfc-editor.org/info/rfc6733>。
[3] Calhoun, P., Farrell, S., and W. Bulley, "Diameter CMS Security Application", Work in Progress, draft-ietf-aaa-diameter-cms-sec-04, March 2002.
[3] Calhoun、P.、Farrell、S。、およびW. Bulley、「Diameter CMS Security Application」、Work in Progress、draft-ietf-aaa-diameter-cms-sec-04、2002年3月。
[4] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter Extensible Authentication Protocol (EAP) Application", RFC 4072, DOI 10.17487/RFC4072, August 2005, <http://www.rfc-editor.org/info/rfc4072>.
[4] Eronen、P.、Ed。、Hiller、T.、and G. Zorn、 "Diameter Extensible Authentication Protocol（EAP）Application"、RFC 4072、DOI 10.17487 / RFC4072、August 2005、<http：//www.rfc-editor .org / info / rfc4072>。
[5] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[5] Kent、S。およびK. Seo、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 4301、DOI 10.17487 / RFC4301、2005年12月、<http://www.rfc-editor.org/info/rfc4301>。
[6] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <http://www.rfc-editor.org/info/rfc5246>.
[6] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<http://www.rfc-editor.org/info/rfc5246> 。
[7] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram Transport Layer Security (DTLS) for Stream Control Transmission Protocol (SCTP)", RFC 6083, DOI 10.17487/RFC6083, January 2011, <http://www.rfc-editor.org/info/rfc6083>.
[7] Tuexen、M.、Seggelmann、R。、およびE. Rescorla、「Stream Control Transmission Protocol（SCTP）のデータグラムトランスポート層セキュリティ（DTLS）」、RFC 6083、DOI 10.17487 / RFC6083、2011年1月、<http：// www .rfc-editor.org / info / rfc6083>。
Acknowledgments
謝辞
We would like to thank Guenther Horn, Martin Dolly, Steve Donovan, Lionel Morand, and Tom Taylor (rest in peace, Tom) for their review comments.
レビューコメントについて、Guenther Horn、Martin Dolly、Steve Donovan、Lionel Morand、Tom Taylor（安心してトム）に感謝します。
The authors also thank Qin Wu, Christer Holmberg, Ben Campbell, and Radia Perlman, who provided additional reviews during the Last Call.
著者は、ラストコール中に追加のレビューを提供してくれたQin Wu、Christer Holmberg、Ben Campbell、Radia Perlmanにも感謝します。
Authors' Addresses
著者のアドレス
Hannes Tschofenig Hall in Tirol 6060 Austria
Hannes Tschofenig Hall in Tirol 6060オーストリア
Email: Hannes.tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Jouni Korhonen (editor) Broadcom Limited 3151 Zanker Rd. San Jose, CA 95134 United States of America
Jouni Korhonen（編集者）Broadcom Limited 3151 Zanker Rd。サンノゼ、CA 95134アメリカ合衆国
Email: jouni.nospam@gmail.com
Glen Zorn Network Zen 227/358 Thanon Sanphawut Bang Na, Bangkok 10260 Thailand
Glen Zorn Network Zen 227/358 Thanon Sanphawut Bang Na、Bangkok 10260 Thailand
Email: glenzorn@gmail.com
Kervin Pillay Internet Solutions South Africa
Kervin Pillay Internet Solutions南アフリカ
Email: kervin.pillay@gmail.com