summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc7966.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc7966.txt')
-rw-r--r--doc/rfc/rfc7966.txt619
1 files changed, 619 insertions, 0 deletions
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,
+ <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>.
+
+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,
+ <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>.
+
+ [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>.
+
+ [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>.
+
+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]
+