idnits 2.17.1 draft-ietf-dime-e2e-sec-req-01.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 (October 21, 2013) is 3839 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, Ed. 3 Internet-Draft Nokia Solutions and Networks 4 Intended status: Informational J. Korhonen 5 Expires: April 24, 2014 Broadcom 6 G. Zorn 7 Network Zen 8 K. Pillay 9 Oracle Communications 10 October 21, 2013 12 Diameter AVP Level Security: Scenarios and Requirements 13 draft-ietf-dime-e2e-sec-req-01.txt 15 Abstract 17 This specification discusses requirements for providing Diameter 18 security at the level of individual Attribute Value Pairs. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 24, 2014. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Security Threats . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Scenarios for Diameter AVP-Level Protection . . . . . . . . . 4 58 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 6 59 6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 7 60 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 62 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 63 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 10.1. Normative References . . . . . . . . . . . . . . . . . . 8 65 10.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 lead 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 specification are to be interpreted as described in [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 follow 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 provent 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 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: Crypto-agility is the ability of a protocol to 259 adapt to evolving cryptographic algorithms and security 260 requirements. This may include the provision of a modular 261 mechanism to allow cryptographic algorithms to be updated 262 without substantial 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. Any 270 Diameter node has an access to network time and thus can 271 synchronise 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. 290 Requirement #6: Solutions MUST recommend a mandatory-to-implement 291 cryptographic algorithm. 293 Motivation: For interoperability purposes it is beneficial to 294 have a mandatory-to-implement cryptographic algorithm specified 295 (unless profiles for specific usage environments specify 296 otherwise). 298 Requirement #7: Solutions MUST support symmetric keys and asymmetric 299 keys. 301 Motivation: Symmetric and asymmetric cryptographic algorithms 302 provide different security services. Asymmetric algorithms, 303 for example, allow non-repudiation services to be offered. 305 Requirement #8: A solution for dynamic key management MUST be 306 included in the overall solution framework. However, it is 307 assumed that no "new" key management protocol needs to be 308 developed; instead existing ones are re-used, if at all possible. 309 Rekeying could be triggered by (a) management actions and (b) 310 expiring keying material. 312 Requirement #9: The ability to statically provisioned keys 313 (symmetric as well as asymmetric keys) has to be supported to 314 simplify management for small-scale deployments that typically do 315 not have a back-end network management infrastructure. 317 6. Open Issues 319 Open Issue #1: Capability/Policy Discovery: This document talks 320 about selectively protecting Diameter AVPs between different 321 Diameter nodes. A Diameter node has to be configured such that it 322 applies security protection to a certain number of AVPs. A number 323 of policy related questions arise: What keying material should be 324 used so that the intended recipient is also able to verify it? 325 What AVPs shall be protected so that the result is not rejected by 326 the recipient? In case of confidentiality protection the Diameter 327 node encrypting AVPs needs to know ahead of time what other node 328 is intended to decrypt them. Should the list of integrity 329 protected AVP be indicated in the protected payload itself (or is 330 it known based on out-of-band information)? Is this policy / 331 capability information assumed to be established out-of-band 332 (manually) or is there a protocol mechanism to distribute this 333 information? 335 Open Issue #2: Command-Line Support: Should solutions allow the 336 provisioning of long-term shared symmetric credentials via a 337 command-line interface / text file? This allows easier management 338 for small-scale deployments. 340 7. Security Considerations 342 This entire document focused on the discussion of new functionality 343 for securing Diameter AVPs selectively between non-neighboring nodes. 345 8. IANA Considerations 347 This document does not require actions by IANA. 349 9. Acknowledgments 351 We would like to thank Guenther Horn, Martin Dolly, for his review 352 comments. 354 10. References 356 10.1. Normative References 358 [1] Bradner, S., "Key words for use in RFCs to Indicate 359 Requirement Levels", BCP 14, RFC 2119, March 1997. 361 [2] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 362 "Diameter Base Protocol", RFC 6733, October 2012. 364 10.2. Informative References 366 [3] Calhoun, P., Farrell, S., and W. Bulley, "Diameter CMS 367 Security Application", draft-ietf-aaa-diameter-cms-sec-04 368 (work in progress), March 2002. 370 [4] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible 371 Authentication Protocol (EAP) Application", RFC 4072, 372 August 2005. 374 Authors' Addresses 376 Hannes Tschofenig (editor) 377 Nokia Solutions and Networks 378 Linnoitustie 6 379 Espoo 02600 380 Finland 382 Phone: +358 (50) 4871445 383 Email: Hannes.Tschofenig@gmx.net 384 URI: http://www.tschofenig.priv.at 386 Jouni Korhonen 387 Broadcom 388 Porkkalankatu 24 389 Helsinki 00180 390 Finland 392 Email: jouni.nospam@gmail.com 394 Glen Zorn 395 Network Zen 396 227/358 Thanon Sanphawut 397 Bang Na Bangkok 10260 398 Thailand 400 Email: glenzorn@gmail.com 402 Kervin Pillay 403 Oracle Communications 404 100 Crosby Drive 405 Bedford, Massachusettes 01730 406 USA 408 Email: kervin.pillay@oracle.com