idnits 2.17.1 draft-tschofenig-dime-e2e-sec-req-00.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 (February 18, 2013) is 4085 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: August 22, 2013 Renesas Mobile 6 G. Zorn 7 Network Zen 8 February 18, 2013 10 Diameter AVP Level Security: Requirements and Scenarios 11 draft-tschofenig-dime-e2e-sec-req-00.txt 13 Abstract 15 This specification discusses requirements for providing Diameter 16 security at the level of individual Attribute Value Pairs. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on August 22, 2013. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 57 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 58 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 59 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 60 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 61 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 64 1. Introduction 66 The Diameter Base specification [1] offers security protection 67 between neighboring Diameter peers and mandates that either TLS (for 68 TCP), DTLS (for SCTP), or IPsec is used. These security protocols 69 offer a wide range of security properties, including entity 70 authentication, data-origin authentication, integrity, 71 confidentiality protection and replay protection. They also support 72 a large number of cryptographic algorithms, algorithm negotiation, 73 and different types of credentials. 75 The need to also offer additional security protection of AVPs between 76 non-neighboring Diameter nodes was recognized very early in the work 77 on Diameter. This lead to work on Diameter security using the 78 Cryptographic Message Syntax (CMS) [3]. Due to lack of deployment 79 interest at that time (and the complexity of the developed solution) 80 the specification was, however, never completed. 82 In the meanwhile Diameter had received a lot of deployment interest 83 from the cellular operator community and because of the 84 sophistication of those deployments the need for protecting Diameter 85 AVPs between non-neighboring nodes re-surfaced. Since early 2000 86 (when the work on [3] was discontinued) the Internet community had 87 seen advances in cryptographic algorithms (for example, authenticated 88 encryption algorithms were developed) and new requirements emerged. 90 This document collects requirements for developing a solution to 91 protect Diameter AVPs. 93 2. Terminology 95 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 96 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY', and 'OPTIONAL' in this 97 specification are to be interpreted as described in [2]. 99 This document re-uses terminology from the Diameter base 100 specification [1]. 102 3. Use Case 104 Consider the following use case shown in Figure 1. A Diameter client 105 interacts with a Diameter server through two Diameter proxies. The 106 Diameter client and the Diameter Proxy A belong to the same realm, 107 example.com. 109 **************************** 110 * 111 Realm: Example.com * 112 +--------+ +--------+ * +--------+ +--------+ 113 |Diameter| |Diameter| * |Diameter| |Diameter| 114 |Client +------+Proxy A +-*------+Proxy B +--------+Server | 115 +--------+ +--------+ * +--------+ +--------+ 116 ^ * ^ 117 . End-to-End * Security Protection . 118 +......................*.............................+ 119 * 120 **************************** 122 Figure 1: Example Diameter Deployment Setup. 124 The Diameter AVPs are protected end-to-end, from the Diameter client 125 to the Diameter server, as shown in Figure 1 with the dotted line. 127 Other use cases are possible as well. For example, Diameter Proxy A 128 could act on behalf of the Diameter clients in the example.com realm. 129 In a general case, however, encryption of AVPs between arbitrary 130 Diameter nodes can be challenging since it is upfront not know what 131 Diameter nodes a message will traverse. 133 QUESTION: Which scenarios should be supported? Should the focus 134 be on the protection of selected Diameter AVPs between the 135 Diameter client to the Diameter server only? 137 4. Requirements 139 Requirement #1: Solutions MUST support an extensible set of 140 cryptographic algorithms. 142 Motivation: Crypto-agility is the ability of a protocol to 143 adapt to evolving cryptographic algorithms and security 144 requirements. This may include the provision of a modular 145 mechanism to allow cryptographic algorithms to be updated 146 without substantial disruption to deployed implementations. 148 Requirement #2: Solutions MUST support confidentiality, integrity, 149 and data-origin authentication. 151 QUESTION: Should solutions for integrity protection work in a 152 backwards-compatible way with existing Diameter applications? 153 Should the list of integrity protected AVP be indicated in the 154 protected payload itself? 156 Requirement #3: Solutions MUST support replay protection. 158 QUESTION: Should replay protection be based on timestamps 159 (i.e., assume synchronized clocks in Diameter networks)? 161 Requirement #4: Solutions MUST be able to selectively apply their 162 cryptographic protection to certain Diameter AVPs. 164 Requirement #5: Solutions MUST recommend a mandatory-to-implement 165 cryptographic algorithm. 167 Requirement #6: QUESTION: Should we support symmetric keys and / or 168 also asymmetric keys? 170 Requirement #7: QUESTION: Should requirements for dynamic key 171 management be included in this document as well? 173 Requirement #8: QUESTION: Should statically provisioned keys be 174 supported? 176 Requirement #9: QUESTION: Should solutions allow the provisioning 177 of long-term shared symmetric credentials via a command-line 178 interface / text file? 180 5. Security Considerations 182 This entire document focused on the discussion of new functionality 183 for securing Diameter AVPs end-to-end. 185 6. IANA Considerations 187 This document does not require actions by IANA. 189 7. Acknowledgments 191 We would like to thank Guenther Horn for his review comments. 193 8. References 195 8.1. Normative References 197 [1] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, "Diameter 198 Base Protocol", RFC 6733, October 2012. 200 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 201 Levels", BCP 14, RFC 2119, March 1997. 203 8.2. Informative References 205 [3] Calhoun, P., Farrell, S., and W. Bulley, "Diameter CMS Security 206 Application", draft-ietf-aaa-diameter-cms-sec-04 (work in 207 progress), March 2002. 209 Authors' Addresses 211 Hannes Tschofenig (editor) 212 Nokia Siemens Networks 213 Linnoitustie 6 214 Espoo 02600 215 Finland 217 Phone: +358 (50) 4871445 218 Email: Hannes.Tschofenig@gmx.net 219 URI: http://www.tschofenig.priv.at 221 Jouni Korhonen 222 Renesas Mobile 223 Porkkalankatu 24 224 Helsinki 00180 225 Finland 227 Email: jouni.nospam@gmail.com 229 Glen Zorn 230 Network Zen 231 227/358 Thanon Sanphawut 232 Bang Na Bangkok 10260 233 Thailand 235 Email: glenzorn@gmail.com