idnits 2.17.00 (12 Aug 2021) /tmp/idnits56171/draft-tschofenig-dime-keying-database-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 date (February 18, 2013) is 3372 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) == Missing Reference: 'I-D.tschofenig-dime-e2e-sec-req' is mentioned on line 88, but not defined == Outdated reference: draft-farrell-decade-ni has been published as RFC 6920 == Outdated reference: draft-ietf-karp-crypto-key-table has been published as RFC 7210 Summary: 0 errors (**), 0 flaws (~~), 4 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 February 18, 2013 5 Expires: August 22, 2013 7 A Keying Database for Diameter End-to-End Security 8 draft-tschofenig-dime-keying-database-00.txt 10 Abstract 12 The Diameter Base specification offers security protection between 13 neighboring Diameter peers using TLS, DTLS, and IPsec. The 14 development of a solution to protect Diameter Attribute Value Pairs 15 between non-neighboring nodes is currently work in progress. 17 Diameter nodes maintain different types of databases, depending on 18 their functions. Examples include the peer table and the realm-based 19 routing table. This document describes a conceptual model for a 20 keying database as it would be used by a Diameter node to determine 21 what AVPs to protect, and what keys / algorithms to use. On the 22 receiving side it allows the receiving node to select the appropriate 23 security association for verifying the protected AVPs. The design is 24 similar to IPsec and inspired by the routing protocol security key 25 table. 27 Status of this Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on August 22, 2013. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Conceptual Keying Database . . . . . . . . . . . . . . . . . . 5 64 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 67 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 68 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 69 8.1. Normative References . . . . . . . . . . . . . . . . . . . 13 70 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 1. Introduction 75 The Diameter Base specification [RFC6733] offers security protection 76 between neighboring Diameter peers and mandates that either TLS (for 77 TCP), DTLS (for SCTP), or IPsec is used. These security protocols 78 offer a wide range of security properties, including entity 79 authentication, data-origin authentication, integrity, 80 confidentiality protection and replay protection. They also support 81 a large number of cryptographic algorithms, algorithm negotiation, 82 and different types of credentials. 84 In the meanwhile Diameter had received a lot of deployment interest 85 and the need for protecting Diameter AVPs between non-neighboring 86 nodes has been created. The requirements for Diameter end-to-end 87 security at the level of individual AVPs is provided in 88 [I-D.tschofenig-dime-e2e-sec-req]. 90 This document describes a conceptual model for a keying database as 91 it would be used by a Diameter node to determine what AVPs to 92 protect, what keys and algorithms to use. On the receiving side it 93 allows the receiving node to select the appropriate security 94 association for verifying the protected AVPs. The design is similar 95 to IPsec [RFC4301] and inspired by the routing protocol security key 96 table [I-D.ietf-karp-crypto-key-table]. 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 [RFC2119]. 104 3. Conceptual Keying Database 106 Diameter nodes maintain different types of databases, depending on 107 their functions. Examples include the peer table and the realm-based 108 routing table. The usage of the end-to-end security mechanisms 109 described in this document adds another database to those nodes 110 supporting this functionality. 112 We describe the keying database in a conceptual way as a table, where 113 each row represents a single symmetric or asymmetric key. 115 The columns that the table consists of are listed as follows: 117 KeyName: The KeyName is a string identifying the key. On the 118 sender-side it provides information about what key to use for 119 applying integrity and/or confidentiality protection. On the 120 receiver-side this value provides information about the key to use 121 for verification. 123 DestinationRealm: The DestinationRealm provides information for the 124 sending host to decide what messages to protect. This selector 125 field contains information about the designation realm. The 126 format of a DiameterIdentity. This field may be empty. 128 DestinationHost: The DestinationHost provides information for the 129 sending host to decide what messages to protect. This selector 130 field contains information about the destination host. The format 131 of a DiameterIdentity. This field may be empty. 133 ApplicationID: The ApplicationID provides information for the 134 sending host to decide what messages to protect. This field 135 contains a list of comma separated application id values. This 136 field may be empty. The value "*" refers to all application ids 137 that match the DestinationRealm and/or DestinationHost field. 139 AVPCodeList: The AVPCodeList provides information for the sending 140 host to decide what AVPs need to experience integrity, and 141 optionally confidentiality protection. This selector field 142 contains a list of AVP codes. The value "*" indicates that the 143 protection covers all AVP fields included in the message. 145 KDF: The KDF field indicates which key derivation function is used 146 to generate short-lived keys from a long-lived symmetric key in 147 the Key field. For symmetric keys, when the long-lived shared key 148 is intended for direct use, the KDF field is set to "none". This 149 document re-used the KDF algorithm registry established in 150 [I-D.ietf-karp-crypto-key-table]. The protocol indicates what (if 151 any) KDFs are valid. For asymmetric algorithm the KDF is left 152 empty. 154 AlgID: The AlgID field indicates the cryptographic algorithm used 155 with the security protocol. The algorithm may be an encryption 156 algorithm and mode (such as AES-128-CBC), an authentication 157 algorithm (such as HMAC-SHA1-96 or AES-128-CMAC), or an algorithm 158 applicable to asymmetric cryptography (such as RS256 indicating 159 RSA with SHA-256). If the KDF field contains "none", then a long- 160 lived shared secret key is used directly with this algorithm, 161 otherwise the derived short-lived symmetric key is used with this 162 algorithm. When the long-lived key is used to generate a set of 163 short-lived keys for use with the security protocol, the AlgID 164 field identifies a ciphersuite rather than a single cryptographic 165 algorithm. 167 KeyType: The KeyType provides information about the type of key 168 found in the Key field. Two values are possible: "SymmetricKey" 169 and "AsymmetricKey". 171 Key: The Key field contains a symmetric or an asymmetric key. A 172 lower-case hexadecimal string is used for representing a symmetric 173 key. For asymmetric keys the NI URI format 174 [I-D.farrell-decade-ni] is used. The size of the Key field 175 depends on the type of key, the selected KDF, and the AlgID. For 176 instance, a KDF=none and AlgID=AES128 requires a 128-bit symmetric 177 key, which is represented by 32 hexadecimal digits. 179 Direction: The Direction field indicates whether this key may be 180 used for inbound traffic, outbound traffic, both, or whether the 181 key has been disabled and may not currently be used at all. The 182 supported values are "in", "out", "both", and "disabled", 183 respectively. 185 SendNotBefore: The NotBefore field specifies the earliest date and 186 time in Universal Coordinated Time (UTC) at which this key should 187 be considered for use. The format is YYYYMMDDHHSSZ, where four 188 digits specify the year, two digits specify the month, two digits 189 specify the day, two digits specify the hour, two digits specify 190 the minute, and two digits specify the second. The "Z" is 191 included as a clear indication that the time is in UTC. This 192 field is empty if the key is for immediate use. If the Direction 193 field indicates that the key is used not used for outbound traffic 194 then this field is ignored. 196 SendNotAfter: The SendNotAfter field specifies the latest date and 197 time at which this key should be considered for use when sending 198 messages. The format is the same as the SendNotBefore field. If 199 the Direction field indicates that the key is used not used for 200 outbound traffic then this field is ignored. 202 RcvNotBefore: The RcvNotBefore field specifies the earliest date and 203 time in Universal Coordinated Time (UTC) at which this key should 204 be considered for use when processing received messages. The 205 format is YYYYMMDDHHSSZ, where four digits specify the year, two 206 digits specify the month, two digits specify the day, two digits 207 specify the hour, two digits specify the minute, and two digits 208 specify the second. The "Z" is included as a clear indication 209 that the time is in UTC. This field is empty if there is no 210 restriction regarding the use of the key when processing received 211 messages. If the Direction field indicates that the key is used 212 not used for inbound traffic then this field is ignored. 214 RcvNotAfter: The RcvNotAfter field specifies the latest date and 215 time at which this key should be considered for use when 216 processing received traffic. The format of this field is 217 identical to the format of NotBefore. If the Direction field 218 indicates that the key is used not used for inbound traffic then 219 this field is ignored. 221 KeyManagement: Specifies whether a entry was statically configured 222 or dynamically discovered. This field may help to create a new 223 key when the existing key is expired. An empty field indicates a 224 statically configured key. Values are reserved for automated key 225 management protocols. 227 4. Examples 229 This section gives a few examples. For editorial reasons (i.e., the 230 per-line character limit of Internet drafts) a list representation is 231 used instead of a table. 233 +----------------+ +----------------+ 234 | | +----------+ | | 235 | Diameter | | | | Diameter | 236 | Client | | Diameter | | Server | 237 | |---------->| Proxy |--------->| | 238 | | | | | | 239 +----------------+ +----------+ +----------------+ 241 client.example.com proxy.example.com server.example.com 243 Figure 1: Example Diameter Deployment Setup. 245 The first example illustrates an entry in the key table at a Diameter 246 client. 248 KeyName: abc123 249 DestinationRealm: 250 DestinationHost: server.example.com 251 ApplicationID: * 252 AVPCodeList: * 253 KDF: none 254 AlgID: HMAC-SHA1-96 255 KeyType: SymmetricKey 256 Key: 617CAA833BEF64D88E45 257 Direction: out 258 SendNotBefore: 259 SendNotAfter: 201302142000Z 260 RcvNotBefore: 261 RcvNotAfter : 262 KeyManagement: 264 The second example illustrates the entries of the key database for an 265 asymmetric key as stored at the Diameter client. 267 KeyName: abc123 268 DestinationRealm: 269 DestinationHost: server.example.com 270 ApplicationID: * 271 AVPCodeList: * 272 KDF: none 273 AlgID: RS256 274 KeyType: AsymmetricKey 275 Key: ni:///sha-256;UyaQV-Ev4rdLoHyJJWCi11OHfrYv9E1aGQAlMO2X_-Q 276 Direction: both 277 SendNotBefore: 278 SendNotAfter: 201302142000Z 279 RcvNotBefore: 280 RcvNotAfter : 201302142000Z 281 KeyManagement: 283 5. Security Considerations 285 This document focuses on the description of a keying database for 286 usage with Diameter to protect AVPs end-to-end. 288 It has been recognized in [RFC4107] that automated key management is 289 not viable in multiple scenarios. The conceptual database specified 290 in this document is designed to accommodate both manual key 291 management and automated key management. A future specification to 292 automatically populate rows in the database is envisioned. 294 Designers should recognize the warning provided in [RFC4107]: 296 "Automated key management and manual key management provide very 297 different features. In particular, the protocol associated with 298 an automated key management technique will confirm the liveness of 299 the peer, protect against replay, authenticate the source of the 300 short-term session key, associate protocol state information with 301 the short-term session key, and ensure that a fresh short-term 302 session key is generated. Moreover, an automated key management 303 protocol can improve the interoperability by including negotiation 304 mechanisms for cryptographic algorithms. These valuable features 305 are impossible or extremely cumbersome to accomplish with manual 306 key management." 308 6. IANA Considerations 310 [Editor's Note: An IANA consideration section will be provided in a 311 future version of this document.] 313 7. Acknowledgments 315 I would like to thank the authors of [I-D.ietf-karp-crypto-key-table] 316 for their work. This document is inspired by their writeup. 318 8. References 320 8.1. Normative References 322 [I-D.farrell-decade-ni] 323 Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., 324 Keraenen, A., and P. Hallam-Baker, "Naming Things with 325 Hashes", draft-farrell-decade-ni-10 (work in progress), 326 August 2012. 328 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 329 Requirement Levels", BCP 14, RFC 2119, March 1997. 331 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 332 "Diameter Base Protocol", RFC 6733, October 2012. 334 8.2. Informative References 336 [I-D.ietf-karp-crypto-key-table] 337 Housley, R., Polk, T., Hartman, S., and D. Zhang, 338 "Database of Long-Lived Symmetric Cryptographic Keys", 339 draft-ietf-karp-crypto-key-table-05 (work in progress), 340 February 2013. 342 [RFC4107] Bellovin, S. and R. Housley, "Guidelines for Cryptographic 343 Key Management", BCP 107, RFC 4107, June 2005. 345 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 346 Internet Protocol", RFC 4301, December 2005. 348 Author's Address 350 Hannes Tschofenig (editor) 351 Nokia Siemens Networks 352 Linnoitustie 6 353 Espoo 02600 354 Finland 356 Phone: +358 (50) 4871445 357 Email: Hannes.Tschofenig@gmx.net 358 URI: http://www.tschofenig.priv.at