From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc7966.txt | 619 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 619 insertions(+) create mode 100644 doc/rfc/rfc7966.txt (limited to 'doc/rfc/rfc7966.txt') diff --git a/doc/rfc/rfc7966.txt b/doc/rfc/rfc7966.txt new file mode 100644 index 0000000..a891ce6 --- /dev/null +++ b/doc/rfc/rfc7966.txt @@ -0,0 +1,619 @@ + + + + + + +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 + +Abstract + + This specification specifies requirements for providing Diameter + security at the level of individual Attribute-Value Pairs (AVPs). + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + 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. + + 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. + + + + + + + + + + + + + + + + + +Tschofenig, et al. Informational [Page 1] + +RFC 7966 Diameter AVP-Level Security September 2016 + + +Copyright Notice + + Copyright (c) 2016 IETF Trust and the persons identified as the + document authors. All rights reserved. + + 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. + +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 + + + + + + + + + + + + + + + + + + + + + + + +Tschofenig, et al. Informational [Page 2] + +RFC 7966 Diameter AVP-Level Security September 2016 + + +1. Introduction + + 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. + + 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. + + 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. + + This document specifies requirements for developing a solution to + protect Diameter AVPs between non-neighboring Diameter nodes. + + + + + + + + + + + + + + + +Tschofenig, et al. Informational [Page 3] + +RFC 7966 Diameter AVP-Level Security September 2016 + + +2. Terminology + + 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]. + + This document reuses terminology from the Diameter base specification + [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. + + 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 broker network + + A network operated by a AAA broker, which consists of necessary + AAA functions to provide AAA brokering services for its customer + AAA networks. + + Diameter firewall + + 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. + + + + + + + + + + + + + + + +Tschofenig, et al. Informational [Page 4] + +RFC 7966 Diameter AVP-Level Security September 2016 + + +3. Security Threats + + 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". + + + +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 + + 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 + + + +Tschofenig, et al. Informational [Page 5] + +RFC 7966 Diameter AVP-Level Security September 2016 + + + 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. + + In the context of the deployment shown in Figure 1, the adversary + could, for example, be in the AAA broker network. + + 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. + + Nodes that could launch such an attack are any Diameter agents + along the end-to-end communication path. + + 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. + + Any Diameter realm could launch such an attack aiming for + financial benefits or to disrupt service availability. + + + + + + + + + + + + + + + + + + + + +Tschofenig, et al. Informational [Page 6] + +RFC 7966 Diameter AVP-Level Security September 2016 + + +4. Scenarios for Diameter AVP-Level Protection + + This scenario outlines a number of cases for deploying security + protection of individual Diameter AVPs. + + 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'). + + +--------+ +--------+ + |Diameter| AVP, {AVP}k |Diameter| + |Client +-----------------........... -------------------+Server | + +--------+ +--------+ + + Figure 2: End-to-End Diameter AVP Security Protection + + 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. + + +--------+ +--------+ +--------+ + |Diameter| AVP |Diameter| AVP, {AVP}k |Diameter| + |Client +-----+Proxy A +---------- .......... -----------+Server | + +--------+ +--------+ +--------+ + + Figure 3: Middle-to-End Diameter AVP Security Protection + + In the third scenario, shown in Figure 4, a Diameter proxy acts on + behalf of the Diameter server. + + +--------+ +--------+ +--------+ + |Diameter| AVP, {AVP}k |Diameter| AVP |Diameter| + |Client +-----------------........... ----+Proxy D +-----+Server | + +--------+ +--------+ +--------+ + + Figure 4: End-to-Middle Diameter AVP Security Protection + + 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 + + + +Tschofenig, et al. Informational [Page 7] + +RFC 7966 Diameter AVP-Level Security September 2016 + + + 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. + + +--------+ +--------+ +--------+ +--------+ + |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. Requirements + + Requirement #1: The solution MUST support an extensible set of + cryptographic algorithms. + + 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. + + Requirement #3: The solution MUST support replay protection. + + Requirement #4: The solution MUST support the ability to delegate + security functionality to another entity. + + 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. + + Requirement #5: The solution MUST be able to selectively apply its + cryptographic protection to certain Diameter AVPs. + + 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. + + + +Tschofenig, et al. Informational [Page 8] + +RFC 7966 Diameter AVP-Level Security September 2016 + + + Furthermore, there are AVPs that must not be confidentiality + protected but may still be integrity protected, such as those + required for Diameter message routing. + + Requirement #6: The solution MUST define a mandatory-to-implement + cryptographic algorithm. + + 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. + + 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. + + 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. + +6. Security Considerations + + This entire document focuses on the discussion of new functionality + for securing Diameter AVPs selectively between non-neighboring nodes. + + 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. + + + + + +Tschofenig, et al. Informational [Page 9] + +RFC 7966 Diameter AVP-Level Security September 2016 + + +7. References + +7.1. Normative References + + [1] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [2] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, + Ed., "Diameter Base Protocol", RFC 6733, + DOI 10.17487/RFC6733, October 2012, + . + +7.2. Informative References + + [3] Calhoun, P., Farrell, S., and W. Bulley, "Diameter CMS + Security Application", Work in Progress, + draft-ietf-aaa-diameter-cms-sec-04, March 2002. + + [4] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter + Extensible Authentication Protocol (EAP) Application", + RFC 4072, DOI 10.17487/RFC4072, August 2005, + . + + [5] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, + December 2005, . + + [6] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, + DOI 10.17487/RFC5246, August 2008, + . + + [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, + . + +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. + + The authors also thank Qin Wu, Christer Holmberg, Ben Campbell, and + Radia Perlman, who provided additional reviews during the Last Call. + + + +Tschofenig, et al. Informational [Page 10] + +RFC 7966 Diameter AVP-Level Security September 2016 + + +Authors' Addresses + + Hannes Tschofenig + Hall in Tirol 6060 + Austria + + 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 + + Email: jouni.nospam@gmail.com + + + Glen Zorn + Network Zen + 227/358 Thanon Sanphawut + Bang Na, Bangkok 10260 + Thailand + + Email: glenzorn@gmail.com + + + Kervin Pillay + Internet Solutions + South Africa + + Email: kervin.pillay@gmail.com + + + + + + + + + + + + + + + + + + +Tschofenig, et al. Informational [Page 11] + -- cgit v1.2.3