idnits 2.17.00 (12 Aug 2021) /tmp/idnits54376/draft-korhonen-dime-e2e-security-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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC2119]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2012) is 3729 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) == Outdated reference: draft-ietf-dime-rfc3588bis has been published as RFC 6733 == Outdated reference: draft-ietf-jose-json-web-encryption has been published as RFC 7516 == Outdated reference: draft-ietf-jose-json-web-signature has been published as RFC 7515 -- No information found for draft-ietf-aaa-diameter-e2e-sec - is the name correct? Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DIME J. Korhonen 3 Internet-Draft H. Tschofenig 4 Intended status: Standards Track Nokia Siemens Networks 5 Expires: September 6, 2012 March 5, 2012 7 Diameter End-to-End Security: Keyed Message Digests, Digital Signatures, 8 and Encryption 9 draft-korhonen-dime-e2e-security-00.txt 11 Abstract 13 This document defines an extension for end to end authentication, 14 integrity and confidentiality protection of Diameter Attribute Value 15 Pairs. The solutions focuses on protecting Diameter Attribute Value 16 Pairs and leaves the key distribution solution to a separate 17 specification. The integrity protection can be introduced in a 18 backward compatible manner to existing application. The 19 confidentiality protection requires an explicit support from an 20 application, thus is applicable only for newly defined applications. 22 Terminology 24 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 25 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 26 document are to be interpreted as described in RFC 2119 [RFC2119]. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on September 6, 2012. 45 Copyright Notice 47 Copyright (c) 2012 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. AVP Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 2.1. Signed-Data AVP . . . . . . . . . . . . . . . . . . . . . 5 65 2.2. Encrypted-Data AVP . . . . . . . . . . . . . . . . . . . . 8 66 3. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . . 9 67 3.1. Transient Failures . . . . . . . . . . . . . . . . . . . . 9 68 3.2. Permanent Failures . . . . . . . . . . . . . . . . . . . . 9 69 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 70 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 71 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 72 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 73 7.1. Normative References . . . . . . . . . . . . . . . . . . . 13 74 7.2. Informational References . . . . . . . . . . . . . . . . . 13 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 77 1. Introduction 79 The Diameter base protocol [I-D.ietf-dime-rfc3588bis] leverages IPsec 80 and TLS for mutual authentication between neighboring Diameter nodes 81 and for channel security offering data origin authentication, 82 integrity and confidentiality protection. The Diameter base 83 protocol, however, also defines Diameter agents, namely Relay Agents, 84 Proxy Agents, Redirect Agents, and Translation Agents. 86 Relay Agents are Diameter agents that accept requests and route 87 messages to other Diameter nodes based on information found in the 88 messages. Since Relays do not perform any application level 89 processing, they provide relaying services for all Diameter 90 applications. 92 Similarly to Relays, Proxy Agents route Diameter messages using the 93 Diameter routing table. However, they differ since they modify 94 messages to implement policy enforcement. 96 Redirect Agents do not relay messages, and only return an answer with 97 the information necessary for Diameter agents to communicate 98 directly, they do not modify messages. Redirect Agents do not have 99 negative impacts on end-to-end security and are therefore not 100 considered in this document. 102 A Translation Agent is a device that provides translation between two 103 protocols. To offer end-to-end security across different protocol 104 requires the ability to convey and process the AVPs defined in this 105 document by both end points. Since such support is very likely not 106 available this document does not cover this functionality. 108 This Diameter extension specifies how AVP authentication, integrity 109 and confidentiality protection can be offered using either symmetric 110 or asymmetric cryptography. As a solution mechanism Javascript 111 Object Signing and Encryption (JOSE) is utilized. JOSE offers a 112 simple encoding with small set of features ideal for the purpose of 113 Diameter. 115 This document focuses on protecting Diameter AVP and leaves the key 116 distribution solution to a separate specification. To offer the 117 functionality two AVPs are defined: Signed-Data and Encrypted-Data. 119 2. AVP Encoding 121 2.1. Signed-Data AVP 123 The Signed-Data AVP (AVP Code TBD) is of type OctetString and 124 utilizes the JSON Web signature (JWS) mechanism defined in 125 [I-D.ietf-jose-json-web-signature]. 127 JWS represents digitally signed or HMACed content using JSON data 128 structures. The representation in [I-D.ietf-jose-json-web-signature] 129 consists of three parts: the JWS Header, the JWS Payload, and the JWS 130 Signature. The three parts are represented as the concatenation of 131 the encoded strings in that order, with the three strings being 132 separated by period ('.') characters. For the JWS Payload we define 133 a new JSON object that contains an array of AVP code number and a 134 hash of AVP pairs. The JWS Signature then covers the all APVs to be 135 signed or HMACed. Both JWS Payload and signature MUST use the same 136 hash algorithm of the cryptographic algorithm indicated in the JWS 137 Header. 139 To package a set of AVPs for signing, each AVP octet representation 140 to be protected are first individually hashed and encoded into the 141 JSON object with its AVP code number, as shown in Figure 1: 143 { "avp": 144 [ 145 {"code" : 123, 146 "hash": "NzY0YjIwYTgyNjE1NjYzNzBkMjExZTUyZmQwNTA5Njc=" 147 }, 148 {"code" : 321, 149 "hash": "OWQ3NjMyNzViNGVmNjQzMGVmNTg4Y2JjMDRiNzU5OGY=" 150 } 151 ] 152 } 154 Figure 1: Example JWS Payload 156 The entire AVP MUST be input to the hash calculation, from the first 157 byte of the AVP code to the last byte of the AVP data, including all 158 other fields, length, reserved/flags, and optional vendor IDs, and 159 padding. The AVP MUST be input to the hash calculation in network 160 byte order. The "code" in the Figure 1 is an integer value 161 containing the AVP code number, and the "hash" is the Base64 encoded 162 hash of the AVP. 164 The JWS Signature is calculated over the entire JWS Payload and then 165 the all three JWS parts are placed in the Signed-Data AVP. There can 166 be multiple Signed-Data AVPs in a Diameter message. The AVP code in 167 the JWS Payload is to indicate which AVP this hash possibly refers 168 to. If there are multiple instances of the same AVP in the Diameter 169 message, there is no other way than make the verification against all 170 of those. It is possible that the message sender only hashed one AVP 171 of the same type and, therefore, the receiver MUST verify the hash 172 against all occurrences of the AVP of the same code number. Such 173 flexibility is added there to allow reordering of the AVPs and 174 addition or deletion of new AVPs by intermediating agents. 176 If a receiver detects errors with the processing of the Signed-Data 177 AVP it MAY return one of the errors defined in Section 3. If a 178 receiver does not find any AVP the Signed-Data AVP has a signature 179 for, it MAY also return one of the errors defined in Section 3. 181 When AVPs are to be both encrypted and signed, the Encrypted-Data AVP 182 MUST be created first. This means that signing is "outside" 183 encryption. 185 Here is an example: Imagine the following AVPs from the QoS-Resources 186 AVP in the QoS-Install Request (defined in RFC 5866 [RFC5866] message 187 shall be signed. The resulting example message has the following 188 structure: 190 ::= < Diameter Header: 327, REQ, PXY > 191 < Session-Id > 192 { Auth-Application-Id } 193 { Origin-Host } 194 { Origin-Realm } 195 { Destination-Realm } 196 { Auth-Request-Type } 197 [ Signed-Data ] 198 * [ QoS-Resources ] 199 ... 201 Example Diameter Message with Signed-Data AVP 203 The Signed-Data AVP in this example may contain a JWS Header that 204 indicates the use of the HMAC SHA-256 algorithm with the key id 205 'abc123'. The protected AVPs are Session-Id, Origin-Host and Origin- 206 Realm. The calculated HMAC SHA-256 values are for example purposes 207 only (i.e., are not real): 209 JWS Header: 211 { "typ":"JWT", 212 "alg":"HS256", 213 "kid":"abc123" 214 } 216 JWS Payload: 218 { "avp": 219 [ 220 {"code" : 263, // Session-Id 221 "hash": "OWQwZTA0OTViYThjMDMxMmI2Mjc0YzUyN2Q1MWEwNDg=" 222 }, 223 {"code" : 264, // Origin-Host 224 "hash": "MzljYTg4ZmZhYTVhNmZmOTAyOWVkOTViYTUzNGUwMjg=" 225 }, 226 {"code" : 296, // Origin-Realm 227 "hash": "MjAyNzMwYWNhNmUzYTE4MDJmNDRhNjMzZjI1MGY2ZmU=" 228 } 229 ] 230 } 232 JWS Signature: 234 "wv3yJxyrhYJkCcDjK63elFkEvAV9dsSUNBf5Cu1ref8=" 236 Combined example JWS (with line breaks for display 237 purposes only): 239 eyAgInR5cCI6IkpXVCIsDQogICAgImFsZyI6IkhTMjU2IiwNCiAgICAia2l 240 kIjoiYWJjMTIzIg0KfQ== 241 . 242 eyAiYXZwIjoNCiAgIFsNCiAgICAgeyJjb2RlIiA6IDI2MywgICAgICAvLyB 243 TZXNzaW9uLUlkDQogICAgICAiaGFzaCI6ICJPV1F3WlRBME9UVmlZVGhqTU 244 RNeE1tSTJNamMwWXpVeU4yUTFNV0V3TkRnPSINCiAgICAgfSwNCiAgICAge 245 yJjb2RlIiA6IDI2NCwgICAgICAvLyBPcmlnaW4tSG9zdA0KICAgICAgImhh 246 c2giOiAiTXpsallUZzRabVpoWVRWaE5tWm1PVEF5T1dWa09UVmlZVFV6Tkd 247 Vd01qZz0iDQogICAgIH0sDQogICAgIHsiY29kZSIgOiAyOTYsICAgICAgLy 248 8gT3JpZ2luLVJlYWxtDQogICAgICAiaGFzaCI6ICJNakF5TnpNd1lXTmhOb 249 VV6WVRFNE1ESm1ORFJoTmpNelpqSTFNR1kyWm1VPSINCiAgICAgfQ0KICAg 250 XQ0KIH0= 251 . 252 wv3yJxyrhYJkCcDjK63elFkEvAV9dsSUNBf5Cu1ref8= 254 Example JWS Header, Payload and Signature 256 2.2. Encrypted-Data AVP 258 The Encrypted-Data AVP (AVP Code TBD) is of type OctetString and 259 contains the JSON Web Encryption (JWE) 260 [I-D.ietf-jose-json-web-encryption] data structure and consists of 261 three parts: the JWE Header, the JWE Encrypted Key, and the JWE 262 Ciphertext. The three parts are represented as the concatenation of 263 the encoded strings in that order, with the three strings being 264 separated by period ('.') characters. JWE does not add a content 265 integrity check if not provided by the underlying encryption 266 algorithm. 268 A single AVP or an entire list of AVPs MUST be input to the 269 encryption process, from the first byte of the AVP code to the last 270 byte of the AVP data, including all other fields, length, reserved/ 271 flags, and optional vendor IDs, and padding. The AVP MUST be input 272 to the encryption process in network byte order, and the encryptor is 273 free to order AVPs whatever way it chooses. When AVPs are to be both 274 encrypted and authenticated, the Encrypted-Data AVP MUST be created 275 first. 277 Note that the usage of the Encrypted-Data AVP requires explicit 278 support by the Diameter application since a receiving Diameter node 279 must first decrypt the content of the Encrypted-Data AVP in order to 280 evaluate the AVPs carried in the message. In case that a Diameter 281 node is unable to understand the Encrypted-Data AVP and ignores the 282 AVP then two possible outcomes are possible: First, if the encrypted 283 AVPs are optional then their content is not considered by the 284 receiving Diameter server without any indication to the sender that 285 they have not been processes. Worse, in the second case when the 286 encrypted AVPs are mandatory to be processed then the receiving 287 Diameter node will return an error that may not inform the sender 288 about the failure to decrypt the Encrypted-Data AVP. Consequently, 289 the usage of the Encrypted-Data AVP may require changes to the ABNF 290 definition of a Diameter application. 292 If a receiver detects that the contents of the Encrypted-Data AVP is 293 invalid, it SHOULD return the new Result-Code AVP value defined in 294 Section 3. 296 3. Result-Code AVP Values 298 This section defines new Diameter result code values for usage with 299 Diameter applications. 301 3.1. Transient Failures 303 Errors that fall within the transient failures category are used to 304 inform a peer that the request could not be satisfied at the time it 305 was received, but MAY be able to satisfy the request in the future. 307 DIAMETER_KEY_UNKNOWN (TBD) 309 This error code is returned when a Signed-Data or an Encrypted- 310 Data AVP is received that was generated using a key that cannot be 311 found in the key store. This error may, for example, be caused if 312 one of the endpoints of an end-to-end security association lost a 313 previously agreed upon key, perhaps as a result of a reboot. To 314 recover a new end-to-end key establishment procedure may need to 315 be invoked. 317 3.2. Permanent Failures 319 Errors that fall within the permanent failures category are used to 320 inform the peer that the request failed, and should not be attempted 321 again. 323 DIAMETER_DECRYPTION_ERROR (TBD) 325 This error code is returned when an Encrypted-Data AVP is received 326 and the decryption fails for an unknown reason. 328 DIAMETER_SIGNATURE_ERROR (TBD) 330 This error code is returned when a Signed-Data AVP is received and 331 the verification fails for an unknown reason. 333 4. IANA Considerations 335 IANA is requested to allocate AVP codes for the following AVPs: 337 +------------------------------------------------------------------+ 338 | AVP Section | 339 |AVP Name Code Defined Data Type | 340 +------------------------------------------------------------------+ 341 |Signed-Data TBD 3.1 OctetString | 342 |Encrypted-Data TBD 3.2 OctetString | 343 +------------------------------------------------------------------+ 345 This specification additionally defines a few Result-Code AVP values, 346 see Section 3. 348 5. Security Considerations 350 The purpose of this document is to offer end-to-end security 351 mechanisms for calculating keyed message digest, for signing, and for 352 encryption of Diameter AVPs. 354 6. Acknowledgements 356 We would like to thank the authors of [I-D.ietf-aaa-diameter-e2e-sec] 357 for their work on CMS end-to-end security for Diameter. Their 358 document inspired us. 360 7. References 362 7.1. Normative References 364 [I-D.ietf-dime-rfc3588bis] 365 Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 366 "Diameter Base Protocol", draft-ietf-dime-rfc3588bis-29 367 (work in progress), August 2011. 369 [I-D.ietf-jose-json-web-encryption] 370 Hildebrand, J., Rescorla, E., and M. Jones, "JSON Web 371 Encryption (JWE)", draft-ietf-jose-json-web-encryption-00 372 (work in progress), January 2012. 374 [I-D.ietf-jose-json-web-signature] 375 Sakimura, N., Jones, M., and J. Bradley, "JSON Web 376 Signature (JWS)", draft-ietf-jose-json-web-signature-00 377 (work in progress), January 2012. 379 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 380 Requirement Levels", BCP 14, RFC 2119, March 1997. 382 7.2. Informational References 384 [I-D.ietf-aaa-diameter-e2e-sec] 385 Calhoun, P., "Diameter End-2-End Security Extension", 386 2001. 388 [RFC5866] Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A., 389 and G. Zorn, "Diameter Quality-of-Service Application", 390 RFC 5866, May 2010. 392 Authors' Addresses 394 Jouni Korhonen 395 Nokia Siemens Networks 396 Linnoitustie 6 397 FI-02600 Espoo 398 FINLAND 400 Email: jouni.nospam@gmail.com 402 Hannes Tschofenig 403 Nokia Siemens Networks 404 Linnoitustie 6 405 Espoo 02600 406 Finland 408 Phone: +358 (50) 4871445 409 Email: Hannes.Tschofenig@gmx.net 410 URI: http://www.tschofenig.priv.at