idnits 2.17.00 (12 Aug 2021) /tmp/idnits49721/draft-ietf-dime-e2e-sec-req-03.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 17, 2015) is 2530 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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 19, 2015 Broadcom Corporation 6 G. Zorn 7 Network Zen 8 K. Pillay 9 Oracle Communications 10 June 17, 2015 12 Diameter AVP Level Security End-to-End Security: Scenarios and 13 Requirements 14 draft-ietf-dime-e2e-sec-req-03.txt 16 Abstract 18 This specification discusses 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 19, 2015. 38 Copyright Notice 40 Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 9.1. Normative References . . . . . . . . . . . . . . . . . . 8 65 9.2. Informative References . . . . . . . . . . . . . . . . . 8 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 68 1. Introduction 70 The Diameter Base specification [2] offers security protection 71 between neighboring Diameter peers and mandates that either TLS (for 72 TCP), DTLS (for SCTP), or IPsec is used. These security protocols 73 offer a wide range of security properties, including entity 74 authentication, data-origin authentication, integrity, 75 confidentiality protection and replay protection. They also support 76 a large number of cryptographic algorithms, algorithm negotiation, 77 and different types of credentials. 79 The need to also offer additional security protection of AVPs between 80 non-neighboring Diameter nodes was recognized very early in the work 81 on Diameter. This led to work on Diameter security using the 82 Cryptographic Message Syntax (CMS) [3]. Due to lack of deployment 83 interest at that time (and the complexity of the developed solution) 84 the specification was, however, never completed. 86 In the meanwhile Diameter had received a lot of deployment interest 87 from the cellular operator community and because of the 88 sophistication of those deployments the need for protecting Diameter 89 AVPs between non-neighboring nodes re-surfaced. Since early 2000 90 (when the work on [3] was discontinued) the Internet community had 91 seen advances in cryptographic algorithms (for example, authenticated 92 encryption algorithms) and new security building blocks were 93 developed. 95 This document collects requirements for developing a solution to 96 protect Diameter AVPs. 98 2. Terminology 100 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 101 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this 102 documents are to be interpreted as described in RFC 2119 [1]. 104 This document re-uses terminology from the Diameter base 105 specification [2]. 107 In the figures below we use the symbols 'AVP' and '{AVP}k'. AVP 108 refers to an unprotected AVP and {AVP}k refers to an AVP that 109 experiences security protection (using key "k") without further 110 distinguishing between integrity and confidentiality protection. 112 3. Security Threats 114 The following description aims to illustrate various security threats 115 that raise the need for protecting Diameter Attribute Value Pairs 116 (AVPs). Figure 1 illustrates an example Diameter topology where a 117 Diameter clients want to interact with the example.com home domain. 118 To interconnect the two visited networks a AAA interconnection 119 provider, labeled as AAA Broker, is used. 121 +oooooooooooooooooo+ +====================+ 122 | Example.net | | | 123 | | | | 124 +--------+ +--------+ +--------+ +--------+ 125 |Diameter| |Diameter+--------+Diameter| |Diameter| 126 |Client 1+------+Proxy A1| +------+Proxy B +--------+Proxy C |----+ 127 +--------+ +--------+ | +--------+ +--------+ | 128 | | | | | | 129 | Visited Domain 1 | | | AAA Broker | | 130 +oooooooooooooooooo+ | +====================+ | 131 | | 132 | | 133 | | 134 | +\\\\\\\\\\\\\\\\\\\\+ | 135 | +--------+ Example.com | | 136 | |Diameter| | | 137 +oooooooooooooooooo+ | |Server X+--+ +--------+ | 138 | Example.org | | +--------+ | |Diameter| | 139 | | | +--------+ +---------+Proxy D |-+ 140 +--------+ +--------+ | |Diameter| | +--------+ 141 |Diameter| |Diameter| | |Server Y+--+ | 142 |Client 2+------+Proxy A2+-+ +--------+ Home Domain | 143 +--------+ +--------+ +////////////////////+ 144 | | 145 | Visited Domain 2 | 146 +oooooooooooooooooo+ 148 Figure 1: Example Diameter Deployment. 150 Eavesdropping: Some Diameter applications carry information that is 151 only intended for consumption by end points, either by the 152 Diameter client or by the Diameter server but not by 153 intermediaries. As an example, consider the Diameter EAP 154 application [4] that allows keying material for the protection of 155 air interface between the end device and the network access server 156 to be carried from the Diameter server to the Diameter client 157 (using the EAP-Master-Session-Key AVP). The content of the EAP- 158 Master-Session-Key AVP would benefit from protection against 159 eavesdropping by intermediaries. Other AVPs might also carry 160 sensitive personal data that, when collected by intermediaries, 161 allow for traffic analysis. 163 In context of the deployment shown in Figure 1 the adversary 164 could, for example, be in the AAA broker network. 166 Injection and Manipulation: The Diameter base specification mandates 167 security protection between neighboring nodes but Diameter agents 168 may be compromised or misconfigured and inject/manipulate AVPs. 169 To detect such actions additional security protection needs to be 170 applied at the Diameter layer. 172 Nodes that could launch such an attack are any Diameter agents 173 along the end-to-end communication path. 175 Impersonation: Imagine a case where a Diameter message from 176 Example.net contains information claiming to be from Example.org. 177 This would either require strict verification at the edge of the 178 AAA broker network or cryptographic assurance at the Diameter 179 layer to prevent a successful impersonation attack. 181 Any Diameter realm could launch such an attack aiming for 182 financial benefits or to disrupt service availability. 184 4. Scenarios for Diameter AVP-Level Protection 186 This scenario outlines a number of cases for deploying security 187 protection of individual Diameter AVPs. 189 In the first scenario, shown in Figure 2, end-to-end security 190 protection is provided between the Diameter client and the Diameter 191 server. Diameter AVPs exchanged between these two Diameter nodes are 192 protected. 194 +--------+ +--------+ 195 |Diameter| AVP, {AVP}k |Diameter| 196 |Client +-----------------........... -------------------+Server | 197 +--------+ +--------+ 199 Figure 2: End-to-End Diameter AVP Security Protection. 201 In the second scenario, shown in Figure 3, a Diameter proxy acts on 202 behalf of the Diameter client with regard to security protection. It 203 applies security protection to outgoing Diameter AVPs and verifies 204 incoming AVPs. 206 +--------+ +--------+ +--------+ 207 |Diameter| AVP |Diameter| AVP, {AVP}k |Diameter| 208 |Client +-----+Proxy A +---------- .......... -----------+Server | 209 +--------+ +--------+ +--------+ 211 Figure 3: Middle-to-End Diameter AVP Security Protection. 213 In the third scenario shown in Figure 4 a Diameter proxy acts on 214 behalf of the Diameter server. 216 +--------+ +--------+ +--------+ 217 |Diameter| AVP, {AVP}k |Diameter| AVP |Diameter| 218 |Client +-----------------........... ----+Proxy D +-----+Server | 219 +--------+ +--------+ +--------+ 221 Figure 4: End-to-Middle Diameter AVP Security Protection. 223 The fourth and the final scenario (see Figure 5) is a combination of 224 the end-to-middle and the middle-to-end scenario shown in Figure 4 225 and in Figure 3. From a deployment point of view this scenario is 226 easier to accomplish for two reasons: First, Diameter clients and 227 Diameter servers remain unmodified. This ensures that no 228 modifications are needed to the installed Diameter infrastructure. 229 Second, key management is also simplified since fewer number of key 230 pairs need to be negotiated and provisioned. 232 +--------+ +--------+ +--------+ +--------+ 233 |Diameter| AVP |Diameter| AVP, {AVP}k |Diameter| AVP |Diameter| 234 |Client +-----+Proxy A +-- .......... ----+Proxy D +-----+Server | 235 +--------+ +--------+ +--------+ +--------+ 237 Figure 5: Middle-to-Middle Diameter AVP Security Protection. 239 Various security threats are mitigated by selectively applying 240 security protection for individual Diameter AVPs. Without protection 241 there is the possibility for password sniffing, confidentiality 242 violation, AVP insertion, deletion or modification. Additionally, 243 applying digital signature offers non-repudiation capabilities; a 244 feature not yet available in today's Diameter deployment. 245 Modification of certain Diameter AVPs may not necessarily be the act 246 of malicious behavior but could also be the result of 247 misconfiguration. An over-aggressively configured firewalling 248 Diameter proxy may also remove certain AVPs. In most cases data 249 origin authentication and integrity protection of AVPs will provide 250 the most benefits for existing deployments with minimal overhead and 251 (potentially) operating in a full-backwards compatible manner. 253 5. Requirements 255 Requirement #1: Solutions MUST support an extensible set of 256 cryptographic algorithms. 258 Motivation: Solutions MUST be able to evolve to adapt to 259 evolving cryptographic algorithms and security requirements. 260 This may include the provision of a modular mechanism to allow 261 cryptographic algorithms to be updated without substantial 262 disruption to deployed implementations. 264 Requirement #2: Solutions MUST support confidentiality, integrity, 265 and data-origin authentication. Solutions for integrity 266 protection MUST work in a backwards-compatible way with existing 267 Diameter applications. 269 Requirement #3: Solutions MUST support replay protection. All 270 Diameter nodes have access to network time and thus can 271 synchronize their clocks. 273 Requirement #4: Solutions MUST support the ability to delegate 274 security functionality to another entity 276 Motivation: As described in Section 4 the ability to let a 277 Diameter proxy to perform security services on behalf of all 278 clients within the same administrative domain is important for 279 incremental deployability. The same applies to the other 280 communication side where a load balancer terminates security 281 services for the servers it interfaces. 283 Requirement #5: Solutions MUST be able to selectively apply their 284 cryptographic protection to certain Diameter AVPs. 286 Motivation: Some Diameter applications assume that certain AVPs 287 are added, removed, or modified by intermediaries. As such, it 288 MUST be possible to apply security protection selectively. 289 Furthermore, there are AVPs that MUST NOT be confidentiality 290 protected but MAY still be integrity protected such as those 291 required for Diameter message routing. 293 Requirement #6: Solutions MUST recommend a mandatory-to-implement 294 cryptographic algorithm. 296 Motivation: For interoperability purposes it is beneficial to 297 have a mandatory-to-implement cryptographic algorithm specified 298 (unless profiles for specific usage environments specify 299 otherwise). 301 Requirement #7: Solutions MUST support symmetric keys and asymmetric 302 keys. 304 Motivation: Symmetric and asymmetric cryptographic algorithms 305 provide different security services. Asymmetric algorithms, 306 for example, allow non-repudiation services to be offered. 308 Requirement #8: A solution for dynamic key management MUST be 309 included in the overall solution framework. However, it is 310 assumed that no "new" key management protocol needs to be 311 developed; instead existing ones are re-used, if at all possible. 312 Rekeying could be triggered by (a) management actions and (b) 313 expiring keying material. 315 6. Security Considerations 317 This entire document focused on the discussion of new functionality 318 for securing Diameter AVPs selectively between non-neighboring nodes. 320 7. IANA Considerations 322 This document does not require actions by IANA. 324 8. Acknowledgments 326 We would like to thank Guenther Horn, Martin Dolly, Steve Donovan and 327 Tom Taylor for their review comments. 329 9. References 331 9.1. Normative References 333 [1] Bradner, S., "Key words for use in RFCs to Indicate 334 Requirement Levels", BCP 14, RFC 2119, March 1997. 336 [2] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 337 "Diameter Base Protocol", RFC 6733, October 2012. 339 9.2. Informative References 341 [3] Calhoun, P., Farrell, S., and W. Bulley, "Diameter CMS 342 Security Application", draft-ietf-aaa-diameter-cms-sec-04 343 (work in progress), March 2002. 345 [4] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 346 Authentication Protocol (EAP) Application", RFC 4072, 347 August 2005. 349 Authors' Addresses 351 Hannes Tschofenig 352 ARM Limited 353 Austria 355 Email: Hannes.tschofenig@gmx.net 356 URI: http://www.tschofenig.priv.at 358 Jouni Korhonen (editor) 359 Broadcom Corporation 360 3151 Zanker Rd. 361 San Jose, CA 95134 362 USA 364 Email: jouni.nospam@gmail.com 366 Glen Zorn 367 Network Zen 368 227/358 Thanon Sanphawut 369 Bang Na Bangkok 10260 370 Thailand 372 Email: glenzorn@gmail.com 374 Kervin Pillay 375 Oracle Communications 376 100 Crosby Drive 377 Bedford, Massachusettes 01730 378 USA 380 Email: kervin.pillay@oracle.com