[Dime] Proposed security section for DRMP
Steve Donovan <srdonovan@usdonovans.com> Mon, 01 February 2016 16:30 UTC
Return-Path: <srdonovan@usdonovans.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD7DC1B3228 for <dime@ietfa.amsl.com>; Mon, 1 Feb 2016 08:30:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.579
X-Spam-Level: *
X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JF3UryG5ZEEr for <dime@ietfa.amsl.com>; Mon, 1 Feb 2016 08:30:13 -0800 (PST)
Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.250]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AFE2B1B321F for <dime@ietf.org>; Mon, 1 Feb 2016 08:30:13 -0800 (PST)
Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:58451 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:RC4-SHA:128) (Exim 4.85) (envelope-from <srdonovan@usdonovans.com>) id 1aQHMf-000Glu-DB for dime@ietf.org; Mon, 01 Feb 2016 08:30:13 -0800
To: "dime@ietf.org" <dime@ietf.org>
From: Steve Donovan <srdonovan@usdonovans.com>
Message-ID: <56AF8811.5030106@usdonovans.com>
Date: Mon, 01 Feb 2016 10:30:09 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - usdonovans.com
X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com
Archived-At: <http://mailarchive.ietf.org/arch/msg/dime/_NqoHTJEBbgsOGZyGUqMSXlxiiY>
Subject: [Dime] Proposed security section for DRMP
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Feb 2016 16:30:15 -0000
All, Here's the proposed security section for DRMP. It is based heavily on Ben's words in the Diameter Overload RFC. Regards, Steve ----- 11. Security Considerations DRMP gives Diameter nodes the ability to influence which requests are are throttled during overload scenarios. Improper use of the DRMP mechanism could result in the malicious Diameter node gaining preferential treatment, by reducing the probability of its requests being throttled, over other Diameter nodes. This would be achieved by the malicious node inserting artificially high priority values. Diameter does not include features to provide end-to-end authentication, integrity protection, or confidentiality. This opens the possibility that agents in the path of a request could modify the DRMP AVP to reflect a priority different than that asserted by the sender of the request. 11.1. Potential Threat Modes The Diameter protocol involves transactions in the form of requests and answers exchanged between clients and servers. These clients and servers may be peers, that is, they may share a direct transport (e.g., TCP or SCTP) connection, or the messages may traverse one or more intermediaries, known as Diameter Agents. Diameter nodes use TLS, DTLS, or IPsec to authenticate peers, and to provide confidentiality and integrity protection of traffic between peers. Nodes can make authorization decisions based on the peer identities authenticated at the transport layer. When agents are involved, this presents an effectively transitive trust model. That is, a Diameter client or server can authorize an agent for certain actions, but it must trust that agent to make appropriate authorization decisions about its peers, and so on. Since confidentiality and integrity protection occurs at the transport layer, agents can read, and perhaps modify, any part of a Diameter message, including the DRMP AVP. There are several ways an attacker might attempt to exploit the DRMP mechanism. A malicious or compromised Diameter node might insert invalid priority values resulting in either preferential treatment, Donovan Expires July 4, 2016 [Page 13] Internet-Draft DOIC January 2016 resulting from higher values, or degraded treatment resulting from lower values, for that node. A similar attack involves a malicious or compromised Diameter agent changing the priority value resulting in the sending Diameter node getting either preferential or degraded service. The DRMP mechanism can be used to aid in overload throttling decisions. When this is the case then the above attacks are limited in scope to when one or more Diameter nodes are in an overloaded state. The DRMP mechanism can also be used to influence the order in which Diameter messages are handled by Diamter nodes. The above attacks have a potentially greater impact in this scenario as the priority indication impacts the handling of all requests at all times, independent of the overload status of Diameter nodes in the Diameter network. 11.2. Denial of Service Attacks The DRMP mechanism does not open direct denial of service attack vectors. Rather, it introduces a mechanism where a node can gain unwarranted preferential treatment. It also introduces a mechanism where a node can get degrated service in the scenario where a rogue agent changes the priority value included in messages. 11.3. End-to End-Security Issues The lack of end-to-end integrity features makes it difficult to establish trust in DRMP AVPs received from non-adjacent nodes. Any agents in the message path may insert or modify DRMP AVPs. Nodes must trust that their adjacent peers perform proper checks on overload reports from their peers, and so on, creating a transitive- trust requirement extending for potentially long chains of nodes. Network operators must determine if this transitive trust requirement is acceptable for their deployments. Nodes supporting DRMP MUST give operators the ability to select which peers are trusted to deliver DRMP AVPs, and whether they are trusted to forward the DRMP AVPs from non-adjacent nodes. Diameter nodes MUST strip DRMP AVPs from messages received from peers that are not trusted for DRMP purposes. It is expected that work on end-to-end Diameter security might make it easier to establish trust in non-adjacent nodes for DRMP purposes. Readers should be reminded, however, that the DRMP mechanism allows Diameter agents to modify AVPs in existing messages that are originated by other nodes. If end-to-end security is enabled, there is a risk that such modification could violate integrity protection. Donovan Expires July 4, 2016 [Page 14] Internet-Draft DOIC January 2016 The details of using any future Diameter end-to-end security mechanism with DRMP will require careful consideration, and are beyond the scope of this document.
- [Dime] Proposed security section for DRMP Steve Donovan