idnits 2.17.00 (12 Aug 2021) /tmp/idnits39036/draft-ietf-dime-e2e-sec-req-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (June 8, 2016) is 2166 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 5246 (ref. '6') (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DIME H. Tschofenig 3 Internet-Draft ARM Limited 4 Intended status: Informational J. Korhonen, Ed. 5 Expires: December 10, 2016 Broadcom Limited 6 G. Zorn 7 Network Zen 8 K. Pillay 9 Internet Solutions 10 June 8, 2016 12 AVP Level Security for Non-neighboring Diameter Nodes: Scenarios and 13 Requirements 14 draft-ietf-dime-e2e-sec-req-05.txt 16 Abstract 18 This specification specifies requirements for providing Diameter 19 security at the level of individual Attribute-Value Pairs. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on December 10, 2016. 38 Copyright Notice 40 Copyright (c) 2016 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Security Threats . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Scenarios for Diameter AVP-Level Protection . . . . . . . . . 5 59 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 7 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 62 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 63 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 9.1. Normative References . . . . . . . . . . . . . . . . . . 9 65 9.2. Informative References . . . . . . . . . . . . . . . . . 9 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 68 1. Introduction 70 The Diameter base protocol specification [2] defines security 71 protection between neighboring Diameter peers. The Diameter mandates 72 that peer connections must be protected by TLS (for TCP) [6], DTLS 73 (for SCTP) [7] or using security mechanisms that are independent of 74 Diameter such as IPsec [5]. These security protocols offer a wide 75 range of security properties, including entity authentication, data- 76 origin authentication, integrity, confidentiality protection and 77 replay protection. They also support a large number of cryptographic 78 algorithms, algorithm negotiation, and different types of 79 credentials. It should be understood that TLS/DTLS/IPsec in Diameter 80 context does not provide end-to-end security unless the Diameter 81 nodes are direct peers i.e., neighboring Diameter nodes. The current 82 Diameter security is realized hop-by-hop. 84 The need to also offer additional security protection of Attribute 85 Value Pairs (AVP) between non-neighboring Diameter nodes was 86 recognized very early in the work on Diameter. This led to work on 87 Diameter security using the Cryptographic Message Syntax (CMS) [3]. 88 Due to lack of deployment interest at that time (and the complexity 89 of the developed solution) the specification was, however, never 90 completed. 92 In the meanwhile Diameter had received a lot of deployment interest 93 from the cellular operator community and because of the 94 sophistication of those deployments the need for protecting Diameter 95 AVPs between non-neighboring nodes re-surfaced. Since early 2000 96 (when the work on [3] was discontinued) the Internet community had 97 seen advances in cryptographic algorithms (for example, authenticated 98 encryption algorithms) and new security building blocks were 99 developed. 101 This document specifies requirements for developing a solution to 102 protect Diameter AVPs between non-neighboring Diameter nodes. 104 2. Terminology 106 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 107 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this 108 documents are to be interpreted as described in RFC 2119 [1]. 110 This document re-uses terminology from the Diameter base 111 specification [2]. 113 In the figures below Attribute Value Pair (AVP) refers to an 114 unprotected AVP and {AVP}k refers to an AVP that experiences security 115 protection (using key "k") without further distinguishing between 116 integrity and confidentiality protection. 118 The following terms are also used in this document: 120 AAA Broker 122 An entity that manages AAA traffic between roaming partner 123 networks. 125 AAA Broker Network 127 A network operated by an AAA Broker, which consists of necessary 128 AAA functions to provide AAA brokering services for its customer 129 AAA networks. 131 Diameter Firewall 133 A Diameter firewall is a proxy (or a relay) agent that acts 134 similarly to conventional IP traffic firewalls but only at the 135 Diameter AVP and command level. A Diameter firewall may, for 136 example, discard security policy offending AVPs from traversing 137 through it. The Diameter firewall may even discard entire 138 Diameter messages based on the security policy. 140 3. Security Threats 142 The following description aims to illustrate various security threats 143 that raise the need for protecting Diameter Attribute-Value Pairs 144 (AVPs). Figure 1 illustrates an example of Diameter based roaming 145 architecture in which Diameter clients within the visited networks 146 need to interact with Diameter servers in the home domain. AAA 147 domains are interconnected using a Diameter-based AAA interconnection 148 network labeled as AAA Broker. 150 +oooooooooooooooooo+ +====================+ 151 | Example.net | | | 152 | | | | 153 +--------+ +--------+ +--------+ +--------+ 154 |Diameter| |Diameter+--------+Diameter| |Diameter| 155 |Client 1| |Proxy A1| |Proxy B | |Proxy C | 156 | (NAS) +------+ | +------+ +--------+ |----+ 157 +--------+ +--------+ | +--------+ +--------+ | 158 | | | | | | 159 | Visited Domain 1 | | | AAA Broker Network | | 160 +oooooooooooooooooo+ | +====================+ | 161 | | 162 | | 163 | | 164 | +\\\\\\\\\\\\\\\\\\\\+ | 165 | +--------+ Example.com | | 166 | |Diameter| | | 167 +oooooooooooooooooo+ | |Server X+--+ +--------+ | 168 | Example.org | | +--------+ | |Diameter| | 169 | | | +--------+ +---------+Proxy D |-+ 170 +--------+ +--------+ | |Diameter| | +--------+ 171 |Diameter| |Diameter| | |Server Y+--+ | 172 |Client 2+------+Proxy A2+-+ +--------+ Home Domain | 173 | (NAS) | | | +////////////////////+ 174 +--------+ +--------+ 175 | | 176 | Visited Domain 2 | 177 +oooooooooooooooooo+ 179 Figure 1: Example Diameter Deployment. 181 Eavesdropping: Some Diameter applications carry information that is 182 only intended for consumption by end points, either by the 183 Diameter client or by the Diameter server but not by 184 intermediaries. As an example, consider the Diameter EAP 185 application [4] that allows the transport of keying material 186 between the Diameter server to the Diameter client (using the EAP- 187 Master-Session-Key AVP) for the protection of the air interface 188 (i.e., the wireless link) between the end device (such as a mobile 189 phone; not shown in the figure) and the Network Access Server 190 (NAS). The content of the EAP-Master-Session-Key AVP should 191 benefit from protection against eavesdropping by intermediaries. 192 Other AVPs, for example those listed in Section 13.3 of [2], might 193 also carry sensitive personal data that, when collected by 194 intermediaries, allow for traffic analysis. 196 In context of the deployment shown in Figure 1 the adversary 197 could, for example, be in the AAA broker network. 199 Injection and Manipulation: The Diameter base protocol specification 200 mandates security protection between neighboring nodes but 201 Diameter agents may be compromised or misconfigured and inject or 202 manipulate AVPs. To detect such actions additional security 203 protection needs to be applied at the Diameter layer. 205 Nodes that could launch such an attack are any Diameter agents 206 along the end-to-end communication path. 208 Impersonation: Imagine a case where a Diameter message from 209 Example.net contains information claiming to be from Example.org. 210 This would either require strict verification at the edge of the 211 AAA broker network or cryptographic assurance at the Diameter 212 layer to prevent a successful impersonation attack. 214 Any Diameter realm could launch such an attack aiming for 215 financial benefits or to disrupt service availability. 217 4. Scenarios for Diameter AVP-Level Protection 219 This scenario outlines a number of cases for deploying security 220 protection of individual Diameter AVPs. 222 In the first scenario, shown in Figure 2, end-to-end security 223 protection is provided between the Diameter client and the Diameter 224 server with any number of intermediate Diameter agents. Diameter 225 AVPs exchanged between these two Diameter nodes may be protected end- 226 to-end (notation '{AVP}k') or unprotected (notation 'AVP'). 228 +--------+ +--------+ 229 |Diameter| AVP, {AVP}k |Diameter| 230 |Client +-----------------........... -------------------+Server | 231 +--------+ +--------+ 233 Figure 2: End-to-End Diameter AVP Security Protection. 235 In the second scenario, shown in Figure 3, a Diameter proxy acts on 236 behalf of the Diameter client with regard to security protection. It 237 applies security protection to outgoing Diameter AVPs and verifies 238 incoming AVPs. Typically, the proxy enforcing the security 239 protection belongs to the same domain as the Diameter client/server 240 without end-to-end security features. 242 +--------+ +--------+ +--------+ 243 |Diameter| AVP |Diameter| AVP, {AVP}k |Diameter| 244 |Client +-----+Proxy A +---------- .......... -----------+Server | 245 +--------+ +--------+ +--------+ 247 Figure 3: Middle-to-End Diameter AVP Security Protection. 249 In the third scenario shown in Figure 4 a Diameter proxy acts on 250 behalf of the Diameter server. 252 +--------+ +--------+ +--------+ 253 |Diameter| AVP, {AVP}k |Diameter| AVP |Diameter| 254 |Client +-----------------........... ----+Proxy D +-----+Server | 255 +--------+ +--------+ +--------+ 257 Figure 4: End-to-Middle Diameter AVP Security Protection. 259 The fourth and the final scenario (see Figure 5) is a combination of 260 the end-to-middle and the middle-to-end scenario shown in Figure 4 261 and in Figure 3. From a deployment point of view this scenario is 262 easier to accomplish for two reasons: First, Diameter clients and 263 Diameter servers remain unmodified. This ensures that no 264 modifications are needed to the installed Diameter infrastructure, 265 except for the security enabled proxies obviously. Second, the key 266 management is also simplified since fewer number of keys need to be 267 negotiated and provisioned. The assumption here is that the number 268 of security enabled proxies would be significantly less than 269 unprotected Diameter nodes in the installed base. 271 +--------+ +--------+ +--------+ +--------+ 272 |Diameter| AVP |Diameter| AVP, {AVP}k |Diameter| AVP |Diameter| 273 |Client +-----+Proxy A +-- .......... ----+Proxy D +-----+Server | 274 +--------+ +--------+ +--------+ +--------+ 276 Figure 5: Middle-to-Middle Diameter AVP Security Protection. 278 5. Requirements 280 Requirement #1: The solution MUST support an extensible set of 281 cryptographic algorithms. 283 Motivation: Solutions MUST be able to evolve to adapt to 284 evolving cryptographic algorithms and security requirements. 285 This may include the provision of a modular mechanism to allow 286 cryptographic algorithms to be updated without substantial 287 disruption to deployed implementations. 289 Requirement #2: The solution MUST support confidentiality, 290 integrity, and data-origin authentication. Solutions for 291 integrity protection MUST work in a backwards-compatible way with 292 existing Diameter applications and therefore be able to traverse 293 legacy proxy and relay agents. 295 Requirement #3: The solution MUST support replay protection. 297 Requirement #4: The solution MUST support the ability to delegate 298 security functionality to another entity 300 Motivation: As described in Section 4 the ability to let a 301 Diameter proxy to perform security services on behalf of all 302 clients within the same administrative domain is important for 303 incremental deployability. The same applies to the other 304 communication side where a load balancer terminates security 305 services for the servers it interfaces. 307 Requirement #5: The solution MUST be able to selectively apply their 308 cryptographic protection to certain Diameter AVPs. 310 Motivation: Some Diameter applications assume that certain AVPs 311 are added, removed, or modified by intermediaries. As such, it 312 must be possible to apply security protection selectively. 313 Furthermore, there are AVPs that must not be confidentiality 314 protected but may still be integrity protected such as those 315 required for Diameter message routing. 317 Requirement #6: The solution MUST define a mandatory-to-implement 318 cryptographic algorithm. 320 Motivation: For interoperability purposes it is beneficial to 321 have a mandatory-to-implement cryptographic algorithm specified 322 (unless profiles for specific usage environments specify 323 otherwise). 325 Requirement #7: The solution MUST support symmetric keys and 326 asymmetric keys. 328 Motivation: Symmetric and asymmetric cryptographic algorithms 329 provide different security services. Asymmetric algorithms, 330 for example, allow non-repudiation services to be offered. 332 Requirement #8: A solution for dynamic key management MUST be 333 included in the overall solution framework. 335 However, it is assumed that no "new" key management protocol 336 needs to be developed; instead existing ones are re-used, if at 337 all possible. Rekeying could be triggered by (a) management 338 actions and (b) expiring keying material. 340 6. Security Considerations 342 This entire document focused on the discussion of new functionality 343 for securing Diameter AVPs selectively between non-neighboring nodes. 345 Various security threats are mitigated by selectively applying 346 security protection for individual Diameter AVPs. Without protection 347 there is the possibility for password sniffing, confidentiality 348 violation, AVP insertion, deletion or modification. Additionally, 349 applying digital signature offers non-repudiation capabilities; a 350 feature not yet available in today's Diameter deployment. 351 Modification of certain Diameter AVPs may not necessarily be the act 352 of malicious behavior but could also be the result of 353 misconfiguration. An over-aggressively configured firewalling 354 Diameter proxy may also remove certain AVPs. In most cases data 355 origin authentication and integrity protection of AVPs will provide 356 the most benefits for existing deployments with minimal overhead and 357 (potentially) operating in a full-backwards compatible manner. 359 7. IANA Considerations 361 This document does not require actions by IANA. 363 8. Acknowledgments 365 We would like to thank Guenther Horn, Martin Dolly, Steve Donovan, 366 Lionel Morand and Tom Taylor (rest in peace Tom) for their review 367 comments. 369 The authors also thank Qin Wu, Christer Holmberg, Ben Campbell and 370 Radia Perlman who provided additional reviews during the Last Call. 372 9. References 374 9.1. Normative References 376 [1] Bradner, S., "Key words for use in RFCs to Indicate 377 Requirement Levels", BCP 14, RFC 2119, 378 DOI 10.17487/RFC2119, March 1997, 379 . 381 [2] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn, 382 Ed., "Diameter Base Protocol", RFC 6733, 383 DOI 10.17487/RFC6733, October 2012, 384 . 386 9.2. Informative References 388 [3] Calhoun, P., Farrell, S., and W. Bulley, "Diameter CMS 389 Security Application", draft-ietf-aaa-diameter-cms-sec-04 390 (work in progress), March 2002. 392 [4] Eronen, P., Ed., Hiller, T., and G. Zorn, "Diameter 393 Extensible Authentication Protocol (EAP) Application", 394 RFC 4072, DOI 10.17487/RFC4072, August 2005, 395 . 397 [5] Kent, S. and K. Seo, "Security Architecture for the 398 Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, 399 December 2005, . 401 [6] Dierks, T. and E. Rescorla, "The Transport Layer Security 402 (TLS) Protocol Version 1.2", RFC 5246, 403 DOI 10.17487/RFC5246, August 2008, 404 . 406 [7] Tuexen, M., Seggelmann, R., and E. Rescorla, "Datagram 407 Transport Layer Security (DTLS) for Stream Control 408 Transmission Protocol (SCTP)", RFC 6083, 409 DOI 10.17487/RFC6083, January 2011, 410 . 412 Authors' Addresses 414 Hannes Tschofenig 415 ARM Limited 416 Austria 418 Email: Hannes.tschofenig@gmx.net 419 URI: http://www.tschofenig.priv.at 420 Jouni Korhonen (editor) 421 Broadcom Limited 422 3151 Zanker Rd. 423 San Jose, CA 95134 424 USA 426 Email: jouni.nospam@gmail.com 428 Glen Zorn 429 Network Zen 430 227/358 Thanon Sanphawut 431 Bang Na Bangkok 10260 432 Thailand 434 Email: glenzorn@gmail.com 436 Kervin Pillay 437 Internet Solutions 438 South Africa 440 Email: kervin.pillay@gmail.com