idnits 2.17.00 (12 Aug 2021) /tmp/idnits54667/draft-korhonen-dime-e2e-security-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 : ---------------------------------------------------------------------------- ** 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 (October 22, 2012) is 3498 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: April 25, 2013 October 22, 2012 7 Diameter End-to-End Security: Keyed Message Digests, Digital Signatures, 8 and Encryption 9 draft-korhonen-dime-e2e-security-01.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 April 25, 2013. 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. Solution description . . . . . . . . . . . . . . . . . . . . . 5 64 2.1. Integrity protection of AVPs . . . . . . . . . . . . . . . 5 65 2.2. Confidentiality protection of AVPs . . . . . . . . . . . . 8 66 2.3. Definition of the 'End Point' . . . . . . . . . . . . . . 9 67 3. AVP Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 3.1. Signed-Data AVP . . . . . . . . . . . . . . . . . . . . . 10 69 3.2. JWS-Header AVP . . . . . . . . . . . . . . . . . . . . . . 10 70 3.3. Header-Parameters AVP . . . . . . . . . . . . . . . . . . 10 71 3.4. JWS-AVP-Payload AVP . . . . . . . . . . . . . . . . . . . 10 72 3.5. JWS-Signature AVP . . . . . . . . . . . . . . . . . . . . 11 73 3.6. Encrypted-Data AVP . . . . . . . . . . . . . . . . . . . . 11 74 3.7. JWE-Header AVP . . . . . . . . . . . . . . . . . . . . . . 11 75 3.8. JWE-Enc-Key AVP . . . . . . . . . . . . . . . . . . . . . 11 76 3.9. JWE-Init-Vec AVP . . . . . . . . . . . . . . . . . . . . . 11 77 3.10. JWE-AVP-Ciphertext AVP . . . . . . . . . . . . . . . . . . 12 78 4. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . . 13 79 4.1. Transient Failures . . . . . . . . . . . . . . . . . . . . 13 80 4.2. Permanent Failures . . . . . . . . . . . . . . . . . . . . 13 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15 83 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 85 8.1. Normative References . . . . . . . . . . . . . . . . . . . 17 86 8.2. Informational References . . . . . . . . . . . . . . . . . 17 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 89 1. Introduction 91 The Diameter base protocol [I-D.ietf-dime-rfc3588bis] leverages IPsec 92 and TLS for mutual authentication between neighboring Diameter nodes 93 and for channel security offering data origin authentication, 94 integrity and confidentiality protection. The Diameter base 95 protocol, however, also defines Diameter agents, namely Relay Agents, 96 Proxy Agents, Redirect Agents, and Translation Agents. 98 Relay Agents are Diameter agents that accept requests and route 99 messages to other Diameter nodes based on information found in the 100 messages. Since Relays do not perform any application level 101 processing, they provide relaying services for all Diameter 102 applications. 104 Similarly to Relays, Proxy Agents route Diameter messages using the 105 Diameter routing table. However, they differ since they modify 106 messages to implement policy enforcement. 108 Redirect Agents do not relay messages, and only return an answer with 109 the information necessary for Diameter agents to communicate 110 directly, they do not modify messages. Redirect Agents do not have 111 negative impacts on end-to-end security and are therefore not 112 considered in this document. 114 A Translation Agent is a device that provides translation between two 115 protocols. To offer end-to-end security across different protocol 116 requires the ability to convey and process the AVPs defined in this 117 document by both end points. Since such support is very likely not 118 available this document does not cover this functionality. 120 The Diameter extension defined in this document specifies how AVP 121 authentication, integrity and confidentiality protection can be 122 offered using either symmetric or asymmetric cryptography. As a 123 solution mechanism is derived form Javascript Object Signing and 124 Encryption (JOSE). JOSE offers a simple encoding with small set of 125 features ideal for the purpose of Diameter. This document further 126 defines a binary efficient coding of JOSE objects. 128 This document focuses on protecting Diameter AVP and leaves the key 129 distribution solution to a separate specification, which most likely 130 is going to be a specific key exchange application. To offer the 131 functionality two grouped AVPs are defined: Signed-Data and 132 Encrypted-Data. The respective JOSE objects are transported within 133 these two AVPs. 135 2. Solution description 137 2.1. Integrity protection of AVPs 139 JWS represents digitally signed or HMACed content using JSON data 140 structures. The representation in [I-D.ietf-jose-json-web-signature] 141 consists of three parts: the JWS Header, the JWS Payload, and the JWS 142 Signature. The three parts are represented as the concatenation of 143 the encoded strings in that order, with the three strings being 144 separated by period ('.') characters. For the JWS Payload one would 145 define a new JSON object that contains an array of AVP code number 146 and a hash of AVP pairs. The JWS Signature then covers the all APVs 147 to be signed or HMACed. Both JWS Payload and signature MUST use the 148 same hash algorithm of the cryptographic algorithm indicated in the 149 JWS Header. 151 Although the solution relies on the JSON, the encoding into Diameter 152 AVPs differ from the text based encoding of the JSON objects. 153 Specifically, none of of the JWS Header, JWS Payload or JWS Signature 154 are not BASE64 encoded but are processed in their plaintext or binary 155 representation formats. For example, the JWS Header is encoded in 156 its plaintext format into the Header-Parameters AVP: 158 { 159 "typ":"JWT", 160 "alg":"HS256", 161 "kid":"abc123" 162 } 164 The JWS Payload and the JWS Signature hashes and AVP Code values are 165 encoded in their binary format as octets, not in textual or BASE64 166 encoded formats. Sections 3.4 and Section 3.5 describe the encodings 167 of the needed AVPs. 169 To package a set of AVPs for signing, each AVP octet representation 170 to be protected are first individually hashed and encoded into the 171 "JSON object" with its four octets AVP code number. The entire AVP 172 MUST be input to the hash calculation, from the first byte of the AVP 173 code to the last byte of the AVP data, including all other fields, 174 length, reserved/flags, and optional vendor IDs, and padding. The 175 AVP MUST be input to the hash calculation in network byte order. 177 The JWS Signature is calculated over the entire JWS Payloads and then 178 the all three JWS parts are placed in the Signed-Data AVP. There can 179 be multiple Signed-Data AVPs in a Diameter message. The AVP code in 180 the JWS Payload is to indicate which AVP this hash possibly refers 181 to. If there are multiple instances of the same AVP in the Diameter 182 message, there is no other way than make the verification against all 183 of those. It is possible that the message sender only hashed one AVP 184 of the same type and, therefore, the receiver MUST verify the hash 185 against all occurrences of the AVP of the same code number. Such 186 flexibility is added there to allow reordering of the AVPs and 187 addition or deletion of new AVPs by intermediating agents. 189 If a receiver detects errors with the processing of the Signed-Data 190 AVP it MAY return one of the errors defined in Section 4. If a 191 receiver does not find any AVP the Signed-Data AVP has a signature 192 for, it MAY also return one of the errors defined in Section 4. 194 When AVPs are to be both encrypted and signed, the Encrypted-Data AVP 195 MUST be created first. This means that signing is "outside" 196 encryption. 198 Here is an example: Imagine the following AVPs from the QoS-Resources 199 AVP in the QoS-Install Request (defined in RFC 5866 [RFC5866] message 200 shall be signed. The resulting example message has the following 201 structure: 203 ::= < Diameter Header: 327, REQ, PXY > 204 < Session-Id > 205 { Auth-Application-Id } 206 { Origin-Host } 207 { Origin-Realm } 208 { Destination-Realm } 209 { Auth-Request-Type } 210 [ Signed-Data ] 211 * [ QoS-Resources ] 212 ... 214 Example Diameter Message with Signed-Data AVP 216 The Signed-Data AVP in this example may contain a JWS Header that 217 indicates the use of the HMAC SHA-256 algorithm with the key id 218 'abc123'. The protected AVPs are Session-Id, Origin-Host and Origin- 219 Realm. The calculated HMAC SHA-256 values are for example purposes 220 only (i.e., are not real): 222 The JWS Header used in this example is: 224 {"typ":"JWT", 225 "alg":"HS256", 226 "kid":"abc123" 227 } 229 Signed-Data Grouped AVP: 231 0x00000nnn // Signed-Data code 'nnn' 232 0x000000a8 // Flags=0, Length=168 (8+49+3+28+28+28+24) 234 JWS Header encoded into the JWS-Header AVP: 236 0x00000xxx // JWS-Header code 'xxx' 237 0x00000031 // Flags=0, Length=49 238 '{"typ":"JWT","alg":"HS256","kid":"abc123"}' // 41 239 0x00,0x00,0x00 // 3 octets padding 241 JWS Payload encoded into three JWS-AVP-Payload AVPs: 243 0xca8362ed,0x69a32ffb 244 0x9092ca98,0x745239da 245 0x6960af73,0x6386bc38 246 0x407e518b,0xe4760548 248 0x00000zzz // JWS-AVP-Payload code 'zzz' <--+ 249 0x0000002c // Flags=0, Length=28 | 250 0x00000107 // 263, Session-Id, 4 octets s 251 0xca8362ed,0x69a32ffb // 256 bits hash of i 252 0x9092ca98,0x745239da // Session-id g 253 0x6960af73,0x6386bc38 n 254 0x407e518b,0xe4760548 a 255 t 256 0x00000zzz // JWS-AVP-Payload code 'zzz' u 257 0x0000002c // Flags=0, Length=28 r 258 0x00000108 // 264, Origin-Host, 4 octets e 259 0x64b52a15,0xa75a8157 // 256 bits hash of | 260 0x151993a6,0xb9839866 // Origin-Realm c 261 0x3b94afa3,0x85568552 o 262 0x46602ccc,0x3f9d9a77 v 263 e 264 0x00000zzz // JWS-AVP-Payload code 'zzz' r 265 0x0000002c // Flags=0, Length=28 a 266 0x00000128 // 296, Origin-Realm, 4 octets g 267 0x3c7c0b17,0x4a1c58d0 // 256 bits hash of e 268 0xdc2844a3,0x28580385 // Origin-Realm | 269 0x25eb08b0,0xeb20c941 // | 270 0xcd52f74c,0xf55ae9ab // <--+ 272 JWS Signature encoded into the JWS-Signature AVP: 274 0x00000yyy // JWS-Signature code 'yyy' 275 0x00000028 // Flags=0, Length=24 276 0x70ec221e,0xe0300ec1,0xb7ce968d,0x6ec6ad9e 277 0x8afbe983,0x2b0e331c,0x2e1f51ac,0xf9af0188 278 Example JWS Header, Payload and Signature 280 2.2. Confidentiality protection of AVPs 282 The Encrypted-Data AVP (AVP Code TBD) is of type OctetString and 283 contains the JSON Web Encryption (JWE) 284 [I-D.ietf-jose-json-web-encryption] data structure and consists of 285 four parts: the JWE Header, the JWE Encrypted Key, the JWE 286 Initialization Vector and the JWE Ciphertext. The four parts are 287 represented as the concatenation of the encoded strings in that 288 order, with the three strings being separated by period ('.') 289 characters. JWE does not add a content integrity check if not 290 provided by the underlying encryption algorithm. 292 Although the solution relies on the JSON, the encoding into Diameter 293 AVPs differ from the text based encoding of the JSON objects. 294 Specifically, none of of the the JWE Header, the JWE Encrypted Key, 295 the JWE Initialization Vector and the JWE Ciphertext are not BASE64 296 encoded but are processed in their plaintext or binary representation 297 formats. The concept follows what was already described in 298 Section 2.1. 300 A single AVP or an entire list of AVPs MUST be input to the 301 encryption process, from the first byte of the AVP code to the last 302 byte of the AVP data, including all other fields, length, reserved/ 303 flags, and optional vendor IDs, and padding. The AVP MUST be input 304 to the encryption process in network byte order, and the encryptor is 305 free to order AVPs whatever way it chooses. When AVPs are to be both 306 encrypted and authenticated, the Encrypted-Data AVP MUST be created 307 first. 309 Note that the usage of the Encrypted-Data AVP requires explicit 310 support by the Diameter application since a receiving Diameter node 311 must first decrypt the content of the Encrypted-Data AVP in order to 312 evaluate the AVPs carried in the message. In case that a Diameter 313 node is unable to understand the Encrypted-Data AVP and ignores the 314 AVP then two possible outcomes are possible: First, if the encrypted 315 AVPs are optional then their content is not considered by the 316 receiving Diameter server without any indication to the sender that 317 they have not been processes. Worse, in the second case when the 318 encrypted AVPs are mandatory to be processed then the receiving 319 Diameter node will return an error that may not inform the sender 320 about the failure to decrypt the Encrypted-Data AVP. Consequently, 321 the usage of the Encrypted-Data AVP may require changes to the ABNF 322 definition of a Diameter application. 324 If a receiver detects that the contents of the Encrypted-Data AVP is 325 invalid, it SHOULD return the new Result-Code AVP value defined in 326 Section 4. 328 2.3. Definition of the 'End Point' 330 Although this specification claims to introduce the end-to-end 331 security into Diameter, the definition who actually is the 'end 332 point' is not obvious. The 'end point' does not need to be the 333 original Diameter request or answer originator but the Diameter node 334 that inserts the Signed-Data or the Encrypted-Data AVPs into the 335 Diameter message. The node can be the request or answer originator 336 or a proxy agent. Use of proxy agents doing the 'end-to-end' 337 security on behalf of other nodes mimics the deployments where site- 338 to-site VPNs are used. 340 3. AVP Encoding 342 3.1. Signed-Data AVP 344 The Signed-Data AVP (AVP Code TBD1) is of type Grouped and utilizes 345 the JSON Web signature (JWS) mechanism defined in 346 [I-D.ietf-jose-json-web-signature]. The JWS payload is then encoded 347 into the Signed-Data AVP: 349 Signed-Data ::= < AVP Header: TBD1 > 350 { JWS-Header } 351 * { JWS-AVP-Payload } 352 { JWS-Signature } 353 * [ AVP ] 355 3.2. JWS-Header AVP 357 The JWS-Header AVP (AVP Code TBD2) is of type UTF8String and contains 358 the JSON Web Signature Header. The contents of the AVP follow the 359 rules for the header found in [I-D.ietf-jose-json-web-signature], 360 which implies the required IANA registries are also defined by JSON 361 documents. 363 JWS-Header ::= < AVP Header: TBD2 > 364 { Header-Parameters } 365 * [ AVP ] 367 The "alg" is the only REQUIRED Header Parameter for the signature 368 purposes. The "typ" and "kid" Header Parameters are also 369 RECOMMENDED. 371 3.3. Header-Parameters AVP 373 The Header-Parameters AVP (AVP Code TBD3) is of type UTF8String and 374 contains the JSON Header Parameter Name and its value as described in 375 [I-D.ietf-jose-json-web-signature]. The encoding (textual) also 376 follows [I-D.ietf-jose-json-web-signature]. Differing from the JSON 377 specifications the parameter names and values are not BASE64 encoded 378 but in their original UTF-8 representation format. 380 3.4. JWS-AVP-Payload AVP 382 The JWS-AVP-Payload AVP (AVP Code TBD4) is of type OctetString and 383 contains both an AVP Code and a hash of the entire AVP identified by 384 the AVP Code. The first four octets contain the AVP Code in a 385 network byte order followed by the hash octets. The length of the 386 hash octets depends on the used hash algorithm. 388 3.5. JWS-Signature AVP 390 The JWS-Signature AVP (AVP Code TBD5) is of type OctetString and 391 contains the signature calculated over the array of complete JWS-AVP- 392 Payload AVPs (including AVP header fields etc) in the order they 393 appear in the Signed-Data AVP. The length of the signature octets 394 depends on the used signature algorithm. 396 3.6. Encrypted-Data AVP 398 The Encrypted-Data AVP (AVP Code TBD6) is of type Grouped and 399 utilizes the JSON Web Encryption (JWE) mechanism defined in 400 [I-D.ietf-jose-json-web-encryption]. The JWE payload is then encoded 401 into the Encrypted-Data AVP: 403 Encrypted-Data ::= < AVP Header: TBD1 > 404 { JWE-Header } 405 { JWE-Enc-Key } 406 [ JWE-Init-Vec ] 407 { JWE-AVP-Ciphertext } 408 * [ AVP ] 410 3.7. JWE-Header AVP 412 The JWE-Header AVP (AVP Code TBD7) is of type UTF8String and contains 413 the JSON Web Encryption Header. The contents of the AVP follow the 414 rules for the header found in [I-D.ietf-jose-json-web-encryption], 415 which implies the required IANA registries are also defined by JSON 416 documents. 418 JWE-Header ::= < AVP Header: TBD7 > 419 { Header-Parameters } 420 * [ AVP ] 422 The "alg" and "enc" are the REQUIRED Header Parameter for the 423 encryption purposes. The "typ" and "kid" Header Parameters are also 424 RECOMMENDED. 426 3.8. JWE-Enc-Key AVP 428 The JWE-Enc-Key AVP (AVP Code TBD8) is of type OctetString and 429 contains the JWE Encrypted Key in its binary format. 431 3.9. JWE-Init-Vec AVP 433 The JWE-Init-Vec AVP (AVP Code TBD9) is of type OctetString and 434 contains the JWE Initialization Vector in its binary format. 436 3.10. JWE-AVP-Ciphertext AVP 438 The JWE-AVP-Ciphertext AVP (AVP Code TBD10) is of type OctetString 439 and contains the encrypted AVPs. The encrypted AVPs are first 440 concatenated into one large plaintext octet blob and then encrypted 441 as a whole. The length of the ciphertext depends on the used 442 algorithm and encrypted AVPs. The plaintext to be encrypted is never 443 BASE64 encoded but MAY be compressed if a "zip" parameter was 444 included in the JWE Header. 446 4. Result-Code AVP Values 448 This section defines new Diameter result code values for usage with 449 Diameter applications. 451 4.1. Transient Failures 453 Errors that fall within the transient failures category are used to 454 inform a peer that the request could not be satisfied at the time it 455 was received, but MAY be able to satisfy the request in the future. 457 DIAMETER_KEY_UNKNOWN (TBD11) 459 This error code is returned when a Signed-Data or an Encrypted- 460 Data AVP is received that was generated using a key that cannot be 461 found in the key store. This error may, for example, be caused if 462 one of the endpoints of an end-to-end security association lost a 463 previously agreed upon key, perhaps as a result of a reboot. To 464 recover a new end-to-end key establishment procedure may need to 465 be invoked. 467 DIAMETER_HEADER_NAME_ERROR (TBD12) 469 This error code is returned when a Header Parameter Name is not 470 understood in the JWS-Header AVP or in the JWE-Header AVP. 472 4.2. Permanent Failures 474 Errors that fall within the permanent failures category are used to 475 inform the peer that the request failed, and should not be attempted 476 again. 478 DIAMETER_DECRYPTION_ERROR (TBD13) 480 This error code is returned when an Encrypted-Data AVP is received 481 and the decryption fails for an unknown reason. 483 DIAMETER_SIGNATURE_ERROR (TBD14) 485 This error code is returned when a Signed-Data AVP is received and 486 the verification fails for an unknown reason. 488 5. IANA Considerations 490 IANA is requested to allocate AVP codes for the following AVPs: 492 +------------------------------------------------------------------+ 493 | AVP Section | 494 |AVP Name Code Defined Data Type | 495 +------------------------------------------------------------------+ 496 |Signed-Data TBD1 3.1 Grouped | 497 |JWS-Header TBD2 3.2 Grouped | 498 |JWS-AVP-Paylaod TBD3 3.4 OctetString | 499 |JSW-Signature TBD4 3.5 OctetString | 500 |Header-Parameters TBD5 3.3 UTF8String | 501 |Encrypted-Data TBD6 3.6 Grouped | 502 |JWE-Header TBD7 3.7 Grouped | 503 |JWE-Enc-Key TBD8 3.8 OctetString | 504 |JWE-Init-Vec TBD9 3.9 OctetString | 505 |JWE-AVP-Ciphertext TBD10 3.10 OctetString | 506 +------------------------------------------------------------------+ 508 This specification additionally defines a few Result-Code AVP values, 509 see Section 4. 511 6. Security Considerations 513 The purpose of this document is to offer end-to-end security 514 mechanisms for calculating keyed message digest, for signing, and for 515 encryption of Diameter AVPs. 517 An intermediate Diameter agent that for a reason or other reorders 518 the AVPs within the Signed-Data AVP may cause the signature 519 verification fail even if no AVP was actually tampered. 521 7. Acknowledgements 523 We would like to thank the authors of [I-D.ietf-aaa-diameter-e2e-sec] 524 for their work on CMS end-to-end security for Diameter. Their 525 document inspired us. 527 8. References 529 8.1. Normative References 531 [I-D.ietf-dime-rfc3588bis] 532 Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 533 "Diameter Base Protocol", draft-ietf-dime-rfc3588bis-34 534 (work in progress), June 2012. 536 [I-D.ietf-jose-json-web-encryption] 537 Jones, M., Rescorla, E., and J. Hildebrand, "JSON Web 538 Encryption (JWE)", draft-ietf-jose-json-web-encryption-06 539 (work in progress), October 2012. 541 [I-D.ietf-jose-json-web-signature] 542 Jones, M., Bradley, J., and N. Sakimura, "JSON Web 543 Signature (JWS)", draft-ietf-jose-json-web-signature-06 544 (work in progress), October 2012. 546 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 547 Requirement Levels", BCP 14, RFC 2119, March 1997. 549 8.2. Informational References 551 [I-D.ietf-aaa-diameter-e2e-sec] 552 Calhoun, P., "Diameter End-2-End Security Extension", 553 2001. 555 [RFC5866] Sun, D., McCann, P., Tschofenig, H., Tsou, T., Doria, A., 556 and G. Zorn, "Diameter Quality-of-Service Application", 557 RFC 5866, May 2010. 559 Authors' Addresses 561 Jouni Korhonen 562 Nokia Siemens Networks 563 Linnoitustie 6 564 FI-02600 Espoo 565 FINLAND 567 Email: jouni.nospam@gmail.com 569 Hannes Tschofenig 570 Nokia Siemens Networks 571 Linnoitustie 6 572 Espoo 02600 573 Finland 575 Phone: +358 (50) 4871445 576 Email: Hannes.Tschofenig@gmx.net 577 URI: http://www.tschofenig.priv.at