idnits 2.17.1 draft-tschofenig-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 (July 15, 2013) is 3936 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) 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 Siemens Networks 4 Intended status: Standards Track J. Korhonen 5 Expires: January 16, 2014 Renesas Mobile 6 G. Zorn 7 Network Zen 8 K. Pillay 9 Oracle Communications 10 July 15, 2013 12 Diameter AVP Level Security: Scenarios and Requirements 13 draft-tschofenig-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 January 16, 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. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 5 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 59 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 60 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 62 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 63 8.2. Informative References . . . . . . . . . . . . . . . . . 7 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 66 1. Introduction 68 The Diameter Base specification [2] offers security protection 69 between neighboring Diameter peers and mandates that either TLS (for 70 TCP), DTLS (for SCTP), or IPsec is used. These security protocols 71 offer a wide range of security properties, including entity 72 authentication, data-origin authentication, integrity, 73 confidentiality protection and replay protection. They also support 74 a large number of cryptographic algorithms, algorithm negotiation, 75 and different types of credentials. 77 The need to also offer additional security protection of AVPs between 78 non-neighboring Diameter nodes was recognized very early in the work 79 on Diameter. This lead to work on Diameter security using the 80 Cryptographic Message Syntax (CMS) [3]. Due to lack of deployment 81 interest at that time (and the complexity of the developed solution) 82 the specification was, however, never completed. 84 In the meanwhile Diameter had received a lot of deployment interest 85 from the cellular operator community and because of the 86 sophistication of those deployments the need for protecting Diameter 87 AVPs between non-neighboring nodes re-surfaced. Since early 2000 88 (when the work on [3] was discontinued) the Internet community had 89 seen advances in cryptographic algorithms (for example, authenticated 90 encryption algorithms were developed) and new security building 91 blocks were developed. 93 This document collects requirements for developing a solution to 94 protect Diameter AVPs. 96 2. Terminology 98 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 99 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this 100 specification are to be interpreted as described in [1]. 102 This document re-uses terminology from the Diameter base 103 specification [2]. 105 3. Use Case 107 Consider the following use case shown in Figure 1 where a a Diameter 108 client wants to interact with its home Diameter server in the 109 example.com realm. The visited domain the Diameter client is 110 attached to makes use of a AAA interconnection provider, shown as AAA 111 Broker in our example. While both the administrators of the visited 112 as well as the home domain are likely to main a business relationship 113 with the intermediate AAA broker network they may want to ensure that 114 certain Diameter AVPs are not sent in the clear or are integrity 115 protected. Note that the security services are likely offered 116 between Diameter Proxy A and Diameter Proxy D for ease of deployment. 117 Proxy A may act on behalf of the Diameter client and Diameter Proxy D 118 acts on behalf of Diameter Server X and Y it serves. 120 +oooooooooooooooooo+ +====================+ 121 | | | | 122 | | | | 123 +--------+ +--------+ +--------+ +--------+ 124 |Diameter| |Diameter| |Diameter| |Diameter| 125 |Client +------+Proxy A +--------+Proxy B +--------+Proxy C |----+ 126 +--------+ +--------+ +--------+ +--------+ | 127 | | | | | 128 | Visited Domain | | AAA Broker | | 129 +oooooooooooooooooo+ +====================+ | 130 | 131 | 132 | 133 +\\\\\\\\\\\\\\\\\\\\+ | 134 +--------+ Example.com | | 135 |Diameter| | | 136 |Server X+--+ +--------+ | 137 +--------+ | |Diameter| | 138 +--------+ +---------+Proxy D |----+ 139 |Diameter| | +--------+ 140 |Server Y+--+ | 141 +--------+ Home Domain | 142 +////////////////////+ 144 Figure 1: Example Diameter Deployment Setup. 146 Based on Figure 1 the following use cases can be differentiated. AVP 147 refers to an unprotected AVP and {AVP}k refers to an AVP that 148 experiences security protection without further distinguishing 149 between integrity and confidentiality protection. 151 In the first scenario, shown in Figure 2, end-to-end security 152 protection is provided between the Diameter client and the Diameter 153 server. Diameter AVPs exchanged between these two Diameter nodes are 154 protected. 156 +--------+ +--------+ 157 |Diameter| AVP, {AVP}k |Diameter| 158 |Client +-----------------........... -------------------+Server | 159 +--------+ +--------+ 161 Figure 2: End-to-End Diameter AVP Security Protection. 163 In the second scenario, shown in Figure 3, a Diameter proxy acts on 164 behalf of the Diameter client with regard to security protection. It 165 applies security protection to outgoing Diameter AVPs and verifies 166 incoming AVPs. 168 +--------+ +--------+ +--------+ 169 |Diameter| AVP |Diameter| AVP, {AVP}k |Diameter| 170 |Client +-----+Proxy A +---------- .......... -----------+Server | 171 +--------+ +--------+ +--------+ 173 Figure 3: Middle-to-End Diameter AVP Security Protection. 175 In the third scenario shown in Figure 4 a Diameter proxy acts on 176 behalf of the Diameter server. 178 +--------+ +--------+ +--------+ 179 |Diameter| AVP, {AVP}k |Diameter| AVP |Diameter| 180 |Client +-----------------........... ----+Proxy D +-----+Server | 181 +--------+ +--------+ +--------+ 183 Figure 4: End-to-Middle Diameter AVP Security Protection. 185 The forth and final scenario (see Figure 5) is a combination of the 186 end-to-middle and the middle-to-end scenario shown in Figure 4 and in 187 Figure 3. From a deployment point of view this scenario is easier to 188 accomplish for two reasons: First, Diameter clients and Diameter 189 servers remain unmodified. This ensures that no modifications are 190 needed to the installed Diameter infrastructure. Second, key 191 management is also simplified since fewer number of key pairs need to 192 be negotiated and provisioned. 194 +--------+ +--------+ +--------+ +--------+ 195 |Diameter| AVP |Diameter| AVP, {AVP}k |Diameter| AVP |Diameter| 196 |Client +-----+Proxy A +-- .......... ----+Proxy D +-----+Server | 197 +--------+ +--------+ +--------+ +--------+ 199 Figure 5: Middle-to-Middle Diameter AVP Security Protection. 201 Various security threats are mitigated by selectively applying 202 security protection for individual Diameter AVPs. Without protection 203 there is the possibility for password sniffing, confidentiality 204 violation, AVP insertion, deletion or modification. Additionally, 205 applying digital signature offers non-repudiation capabilities; a 206 feature not yet available in todays Diameter deployment. 207 Modification of certain Diameter AVPs may not necessarily be the act 208 of malicious behavior but could also be the result of 209 misconfiguration. An over-aggressively configured firewalling 210 Diameter proxy may also remove certain AVPs. In most cases data 211 origin authentication and integrity protection of AVPs will provide 212 most benefits for existing deployments with minimal overhead and 213 (potentially) operating in a full-backwards compatible manner. 215 4. Requirements 217 Requirement #1: Solutions MUST support an extensible set of 218 cryptographic algorithms. 220 Motivation: Crypto-agility is the ability of a protocol to 221 adapt to evolving cryptographic algorithms and security 222 requirements. This may include the provision of a modular 223 mechanism to allow cryptographic algorithms to be updated 224 without substantial disruption to deployed implementations. 226 Requirement #2: Solutions MUST support confidentiality, integrity, 227 and data-origin authentication. Solutions for integrity 228 protection MUST work in a backwards-compatible way with existing 229 Diameter applications. 231 Requirement #3: Solutions MUST support replay protection. Any 232 Diameter node has an access to network time and thus can 233 synchronise their clocks. 235 Requirement #4: Solutions MUST support the ability to delegate 236 security functionality to another entity 238 Motivation: As described in Section 3 the ability to let a 239 Diameter proxy to perform security services on behalf of all 240 clients within the same administrative domain is important for 241 incremental deployability. The same applies to the other 242 communication side where a load balancer terminates security 243 services for the servers it interfaces. 245 Requirement #5: Solutions MUST be able to selectively apply their 246 cryptographic protection to certain Diameter AVPs. 248 Motivation: Some Diameter applications assume that certain AVPs 249 are added, removed, or modified by intermediaries. As such, it 250 may be necessary to apply security protection selectively. 252 Requirement #6: Solutions MUST recommend a mandatory-to-implement 253 cryptographic algorithm. 255 Motivation: For interoperability purposes it is beneficial to 256 have a mandatory-to-implement cryptographic algorithm specified 257 (unless profiles for specific usage environments specify 258 otherwise). 260 Requirement #7: Solutions MUST support symmetric keys and asymmetric 261 keys. 263 Motivation: Symmetric and asymmetric cryptographic algorithms 264 provide different security services. Asymmetric algorithms, 265 for example, allow non-repudiation services to be offered. 267 Requirement #8: A solution for dynamic key management has to be 268 provided. It is assumed that no "new" key management protocol 269 needs to be developed; instead existing ones are re-used, if at 270 all possible. Rekeying could be triggered by (a) management 271 actions and (b) expiring keying material. 273 Requirement #9: The ability to statically provisioned keys 274 (symmetric as well as asymmetric keys) has to be supported to 275 simplify management for small-scale deployments that typically do 276 not have a backend network management infastructure. 278 Requirement #10: Capability/Policy Discovery: This document talks 279 about selectively protecting Diameter AVPs between different 280 Diameter nodes. A Diameter node has to be configured such that it 281 applies security protection to a certain number of AVPs. A number 282 of policy related questions arise: What keying material should be 283 used so that the intended recipient is also able to verify it? 284 What AVPs shall be protected so that the result is not rejected by 285 the recipient? In case of confidentiality protection the Diameter 286 node encrypting AVPs needs to know ahead of time what other node 287 is intended to decrypt them. Should the list of integrity 288 protected AVP be indicated in the protected payload itself (or is 289 it known based on out-of-band information)? Is this policy / 290 capability information assumed to be established out-of-band 291 (manually) or is there a protocol mechanism to distribute this 292 information? 294 Requirement #11: Command-Line Support: Should solutions allow the 295 provisioning of long-term shared symmetric credentials via a 296 command-line interface / text file? This allows easier management 297 for small-scale deployments. 299 5. Security Considerations 301 This entire document focused on the discussion of new functionality 302 for securing Diameter AVPs selectively between non-neighboring nodes. 304 6. IANA Considerations 306 This document does not require actions by IANA. 308 7. Acknowledgments 310 We would like to thank Guenther Horn for his review comments. 312 8. References 314 8.1. Normative References 316 [1] Bradner, S., "Key words for use in RFCs to Indicate 317 Requirement Levels", BCP 14, RFC 2119, March 1997. 319 [2] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 320 "Diameter Base Protocol", RFC 6733, October 2012. 322 8.2. Informative References 324 [3] Calhoun, P., Farrell, S., and W. Bulley, "Diameter CMS 325 Security Application", draft-ietf-aaa-diameter-cms-sec-04 326 (work in progress), March 2002. 328 Authors' Addresses 330 Hannes Tschofenig (editor) 331 Nokia Siemens Networks 332 Linnoitustie 6 333 Espoo 02600 334 Finland 336 Phone: +358 (50) 4871445 337 Email: Hannes.Tschofenig@gmx.net 338 URI: http://www.tschofenig.priv.at 340 Jouni Korhonen 341 Renesas Mobile 342 Porkkalankatu 24 343 Helsinki 00180 344 Finland 346 Email: jouni.nospam@gmail.com 348 Glen Zorn 349 Network Zen 350 227/358 Thanon Sanphawut 351 Bang Na Bangkok 10260 352 Thailand 354 Email: glenzorn@gmail.com 356 Kervin Pillay 357 Oracle Communications 358 100 Crosby Drive 359 Bedford, Massachusettes 01730 360 USA 362 Email: kervin.pillay@oracle.com