idnits 2.17.1 draft-ietf-aaa-diameter-cms-sec-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 34 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 35 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1510 has weird spacing: '... copied and ...' == Line 1511 has weird spacing: '...s, and deriv...' == Line 1513 has weird spacing: '...ed, in whole...' == Line 1514 has weird spacing: '...hat the above...' == Line 1515 has weird spacing: '... this parag...' == (5 more instances...) == 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 exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: The table in this section presents the AVPs defined in this document, and specifies in which Diameter messages they MAY, or MAY NOT be present. Note that AVPs that can only be present within a Grouped AVP are not represented in this table. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2001) is 8170 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) == Unused Reference: '2' is defined on line 1409, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1444, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1448, but no explicit reference was found in the text == Unused Reference: '16' is defined on line 1455, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 1458, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-aaa-diameter-08 -- Possible downref: Non-RFC (?) normative reference: ref. '2' ** Obsolete normative reference: RFC 2630 (ref. '3') (Obsoleted by RFC 3369, RFC 3370) ** Obsolete normative reference: RFC 2459 (ref. '4') (Obsoleted by RFC 3280) ** Obsolete normative reference: RFC 2559 (ref. '6') (Obsoleted by RFC 3494) ** Downref: Normative reference to an Informational RFC: RFC 3141 (ref. '7') ** Downref: Normative reference to an Informational RFC: RFC 2977 (ref. '8') ** Obsolete normative reference: RFC 2560 (ref. '9') (Obsoleted by RFC 6960) ** Downref: Normative reference to an Informational RFC: RFC 2989 (ref. '10') ** Obsolete normative reference: RFC 2633 (ref. '11') (Obsoleted by RFC 3851) -- No information found for draft-ietf-aaa-Diameter-nasreq - is the name correct? -- Possible downref: Normative reference to a draft: ref. '13' -- No information found for draft-ietf-aaa-Diameter-mobileip - is the name correct? -- Possible downref: Normative reference to a draft: ref. '14' Summary: 13 errors (**), 0 flaws (~~), 18 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 AAA Working Group Pat R. Calhoun 3 Internet-Draft Black Storm Networks 4 Category: Standards Track Stephen Farrell 5 Baltimore Technologies 6 William Bulley 7 Merit Network, Inc. 8 November 2001 10 Diameter CMS Security Application 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at: 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 The list of Internet-Draft Shadow Directories can be accessed at: 31 http://www.ietf.org/shadow.html. 33 Distribution of this memo is unlimited. 35 Copyright (C) The Internet Society 2001. All Rights Reserved. 37 Abstract 39 The Diameter base protocol leverages either IPsec or TLS for 40 integrity and confidentiality between two Diameter peers, and allows 41 the peers to communicate through relay and proxy agents. Relay agents 42 perform message routing, and other than routing AVPs, do not modify 43 Diameter messages. Proxy agents, on the other hand, implement policy 44 enforcement, and actively modify Diameter messages. 46 This Diameter application describes how a security association is 47 established by two peers through agents, and how authentication, 48 integrity, confidentiality and non-repudiation (with proof of origin) 49 are achieved using a mixture of symmetric and asymmetric transforms, 50 by encapsulating Cryptographic Message Syntax (CMS) data within AVPs. 51 CMS is also used to carry X.509 certificates. 53 Table of Contents 55 1.0 Introduction 56 1.1 Requirements language 57 1.2 Establishing Security Relationship through relay agents 58 1.3 Establishing Security Relationship through proxy agents 59 1.4 Using Redirect agents in lieu of DSA 60 1.5 When to use DSAs 61 1.6 Who can authorize users 62 1.7 Advertising application support 63 2.0 AVP Format 64 3.0 Key Management 65 3.1 Usage Scenario 66 3.2 Certificate Requirements 67 3.3 Algorithms 68 3.4 Reuse of CMS Content Encryption Keys 69 4.0 Command-Codes Values 70 4.1 Diameter-Security-Association-Request 71 4.2 Diameter-Security-Association-Answer 72 4.3 Proxy-Diameter-Security-Association-Request 73 4.4 Proxy-Diameter-Security-Association-Answer 74 5.0 Diameter Security Association Message Flow 75 6.0 Diameter Security AVPs 76 6.1 CMS-Signed-Data AVP 77 6.2 CMS-Encrypted-Data AVP 78 6.3 Example Encodings 79 6.4 Local-CA-Info AVP 80 6.4.1 CA-Name AVP 81 6.4.2 Key-Hash AVP 82 6.5 OCSP-Nonce AVP 83 6.6 AAA-Server-Certs AVP 84 6.7 OCSP-Responses AVP 85 6.8 CA-Chain AVP 86 6.9 OCSP-Request-Flags AVP 87 6.10 DSAR-Target-Realm AVP 88 6.11 DSA-TTL AVP 89 7.0 Result-Code AVP Values 90 7.1 Transient Failures 91 7.2 Permanent Failures 92 8.0 AVP Occurrence Tables 93 9.0 IANA Considerations 94 9.1 Command Codes 95 9.2 AVP Codes 96 9.3 Result-Code AVP Values 97 9.4 Application Identifier 98 9.5 OCSP-Request-Flags AVP Values 99 10.0 Security Considerations 100 11.0 References 101 12.0 Acknowledgements 102 13.0 Authors' Addresses 103 14.0 Full Copyright Statement 104 15.0 Expiration Date 106 1.0 Introduction 108 The Diameter base protocol [1] leverages either IPsec or TLS for 109 integrity and confidentiality between two Diameter peers. However, 110 the Diameter protocol also allows peers to communicate through relay 111 and proxy agents, and in such environments security information is 112 lost at each agent. 114 Relay agents perform message routing, and other than routing AVPs, do 115 not modify Diameter messages. Proxy agents, on the other hand, 116 implement policy enforcement, and actively modify Diameter messages. 117 See [1] for a more comprehensive definition of the role of relay and 118 proxy agents. 120 There are two main techniques used in this specification. Digital 121 signatures (along with digital certificates) provide authentication, 122 integrity and non-repudiation. Encryption provides confidentiality 123 (using asymmetric techniques to encrypt a content encryption key, 124 which is then used for bulk encryption). Both techniques can be used 125 simultaneously to provide all the specified security services. 127 This Diameter application makes use of Cryptographic Message Syntax 128 (CMS), which is the method used to secure MIME (S/MIME) messages. 129 This application was designed to allow for Diameter implementations 130 to use existing S/MIME toolkits in order to comply with this 131 specification. 133 This specification contains two different set of messages. The DSA 134 messages are used to establish a security assocation, while the PDS 135 messages are used to request that a security association be 136 established by a third party. The following details the necessary 137 support for both types of messages based on the type of Diameter 138 node: 139 - Diameter servers: MUST support DSA messages; MAY support PDS messages 140 - Proxy agents: MUST support DSA messages; MUST support PDS messages 141 - Diameter clients: SHOULD support DSA messages; MUST support PDS 142 messages 143 - Relay agents: MAY support DSA messages; MAY support PDS messages 144 - Redirector agents: MAY support DSA messages; MAY support PDS messages 146 1.1 Requirements language 148 In this document, the key words "MAY", "MUST", "MUST NOT", 149 "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be 150 interpreted as described in [5]. 152 1.2 Establishing Security Relationship through relay agents 154 The AAA Working Group has defined a set of requirements in [10] to 155 allow for Diameter peers to communicate securely through Relay 156 agents. This requirement calls for AVP integrity and confidentiality 157 between two peers communicating through agents. The term agent is 158 used in this specification for either a relay or a proxy agent. 159 Figure 1 provides an example of two Diameter peers establishing a 160 Diameter Security Association (DSA) through Relay agents. The 161 participants of a DSA are the peers where the DSA setup messages 162 terminate. In this example, the participants of the DSA would the NAS 163 (access device), and the Home Server. 165 mno.net mno.net xyz.net abc.com 166 +------+ <----> +------+ <----> +------+ <----> +------+ 167 | | TLS |Agent | IPSec |Agent | IPSec | Home | 168 | NAS | | | | | | | 169 | | | 1 | | 2 | |Server| 170 +------+ +------+ +------+ +------+ 171 <--------------------------------------------> 172 Diameter Security Association 174 Figure 1: Diameter Security Association 176 When one or more agents are used between two communicating Diameter 177 peers, the use of hop-by-hop security mechanisms (e.g. TLS, IPSec) 178 is unsuitable, since Diameter messages are processed at the 179 application layer at each agent. Therefore, an alternative mechanism 180 is required to protect portions of the message at the application 181 layer. 183 Allowing for a security association to be established through 184 Diameter relays allows the participants of the DSA to detect whether 185 protected AVPs have been modified en-route, and hides sensitive data 186 from intermediate agents. Furthermore, the Mobile IP and NASREQ 187 Working Groups have stated in [7, 8] that non-repudiation of Diameter 188 data, such as Accounting related AVPs, is necessary. 190 Figure 2 provides an example of a message sent by an access device 191 (NAS), through Diameter relay agents, to its intended destination, 192 the home server. In this example, Proxy 2 modifies the contents of 193 the foo AVP, perhaps due to mis-configuration, or maliciously. This 194 specification would allow the participants of the DSA to detect such 195 a problem, as long as the AVP being modified was protected. 197 (Request) (Request) (Request) 198 [AVP(foo)=x] [AVP(foo)=x] [AVP(foo)=y] 199 +------+ -----> +------+ -----> +------+ -----> +------+ 200 | | |Relay | |Proxy | | Home | 201 | NAS | | | | | | | 202 | | | 1 | | 2 | |Server| 203 +------+ <----- +------+ <----- +------+ <----- +------+ 204 (Answer) (Answer) (Answer) 205 [AVP(foo)=b] [AVP(foo)=b] [AVP(foo)=a] 207 Figure 2: Diameter agent modifying AVP 209 This document defines the Diameter commands that are used to 210 establish a DSA through Diameter agents, and specifies how 211 encapsulating CMS objects [3] in Diameter AVPs can provide 212 authentication, integrity, confidentiality and non-repudiation. The 213 CMS object MAY also be used to transport X.509 certificates and 214 revocation lists. 216 Establishing a DSA through relay agents requires that the initiator 217 issues a Diameter Security Association Request (DSAR) message. In the 218 example provided in figure 1, NAS would issue the DSAR with the 219 Destination-Realm AVP set to abc.com. The Home Server would process 220 the request, and respond by issuing a Diameter Security Association 221 Answer (DSAA) message. If the DSAA message contains a Result-Code 222 indicating success, the DSA is established between the NAS and the 223 home server. 225 Once the DSA is established, participants with private keys MAY apply 226 digital signatures to protect one or more AVP within a message. In 227 the example provided in Figure 2, the Foo AVP would be protected by 228 the digital signature, and any modification of the AVP by the relay 229 agents, would be detected when the signature validation algorithm 230 would fail by either participant. 232 1.3 Establishing Security Relationship through proxy agents 234 As previously discussed, proxy agents typically modify Diameter 235 messages to implement policy enforcement. An example of a proxy 236 server would be an aggregating server, which typically sits one 237 Diameter hop away from the access device, and enforces policy in 238 order to protect the access device from receiving AVPs that could 239 cause harm (e.g. excessive number of filters, unsupported tunneling 240 protocol). Although in theory such checks could be performed on the 241 access device, these devices are typically embedded systems, and not 242 easily configurable. The proxy agent's behavior, on the other hand, 243 is typically under control of the network operator. 245 Diameter messages between two participants of a DSA would fail 246 verification if a proxy agent were to modify any protected AVPs. 247 Therefore proxy agents either MUST NOT modify protected AVPs or else 248 MUST NOT allow the DSA to be established. In this section, we discuss 249 the capabilities provided by this Diameter application which allow 250 proxy agents to secure AVPs on behalf of an access device. The 251 following scenarios are envisioned: 253 - The access device does not have the cryptographic ability to 254 handle the security CMS functions locally, and therefore 255 requests such services from the local agent, such an an 256 aggregating relay or proxy agent. The NAS may have been 257 configured to always issue a PDSR to its local agent for CMS 258 services. In such cases, the agent MUST select the values for 259 the DSA-TTL and provide the appropriate Local-CA-Info and the 260 expected OCSP response from the DSA peer. 261 - The access device has the cryptographic ability to perform the 262 security CMS functions, but a proxy agent is in the route 263 towards the home server, and it returned a failure to the DSAR 264 messages stating that it was not willing to allow the DSA to 265 traverse through it. Such agents MAY attempt to re-use the 266 values from the initial DSAR sent by the access device. In such 267 cases,the PDSR initiator SHOULD include the Destination-Host AVP 268 to ensure that the PDSR is received by the same proxy agent. 269 - The access device may have the cryptographic ability to perform 270 CMS functions locally, but does not request a DSAR to request a 271 DSA. The local agent, however, has been configured to establish 272 DSAs with certain realms automatically, hiding the existence of 273 the DSAs from the access device. 275 In the above scenarios, the first two occur at the explicit request 276 of the access device, while the last one occurs without any messaging 277 from the access device. In the latter case, the proxy agent acts as 278 an access device of sorts and the rules in section 1.2 should be used 279 instead. 281 When a local agent receives a DSAR, it has the following options: 282 - The local agent rejects all DSARs by sending a DSAA message 283 whose Result-Code AVP is set to DIAMETER_NO_CMS_THROUGH_PROXY. 284 The DSAA SHOULD include the CMS-Signed-Data AVP, signed by the 285 proxy agent, and include its certificate to allow the access 286 device to validate the originator of the DSAA. The access device 287 can then determine whether it is willing to provide service, 288 based on its local policy. 289 - The local agent rejects all DSARs by sending a DSAA message 290 whose Result-Code AVP is set to DIAMETER_CAN_ACT_AS_CMS_PROXY, 291 informing the access device that the agent is willing to 292 establish the DSA on its behalf. The DSAA MUST include the CMS- 293 Signed-Data AVP, signed by the proxy agent, and include its 294 certificate to allow the access device to validate the 295 originator of the DSAA. If the access device is willing to use 296 the agent's services, which it could be configured to only 297 accept such DSAA messages from agents within its realm, it 298 issues a Proxy-Diameter-Security-Association-Request (PDSR) 299 which MUST contain the target realm. The local agent MAY use any 300 of the parameters provided by the access device in the previous 301 DSAR attempt when establishing the DSA. Once the DSA is 302 established, the agent MUST issue a Proxy-Diameter-Security- 303 Association-Answer (PDSA). The PDSA MUST contain the TTL setting 304 agreed by the proxy agent for its DSA. This information will 305 allow the access device to re-issue a PDSR prior to the proxy's 306 DSA if it needs the DSA to remain active. 308 Note that an access device MAY be configured to always issue a PDSR 309 to its aggregating proxy, reducing the number of round trips. 310 Similarly, an aggregating proxy MAY be configured to initiate an DSAR 311 regardless of whether a PDSR was sent by the access device. 313 mno.net mno.net xyz.net abc.com 314 +------+ +------+ +------+ +------+ 315 | | |Proxy | |Relay | | Home | 316 | NAS | | | | | | | 317 | | |Agent | |Agent | |Server| 318 +------+ +------+ +------+ +------+ 319 -------------> 320 (DSAR) Destination-Realm = abc.com 322 <------------- 323 (DSAA) Result-Code = DIAMETER_CAN_ACT_AS_CMS_PROXY 325 -------------> 326 (PDSR) DSAR-Target-Realm = abc.com 328 ----------------------------> 329 (DSAR) Destination-Realm = abc.com 331 <---------------------------- 332 (DSAA) Result-Code = DIAMETER_SUCCESS 334 <------------- 335 (PDSA) Result-Code = DIAMETER_SUCCESS 337 Figure 3: Establishing Security through Proxy Agent 339 An optimized approach also allows the PDSR to be sent by the access 340 device without the DSAR-Target-Realm AVP. This message is used to 341 inform the proxy that it MUST establish a Diameter security 342 association for all realms it will be communicating with on behalf of 343 the access device. DSAs are typically established once the first 344 request for a given realm has been recelived by the proxy agent, but 345 it MAY establish certain DSAs with known realm in advance. 347 If a DSA for a given realm cannot be established, the proxy agent 348 MUST reject the access device's request, and set the Result-Code AVP 349 to DIAMETER_NO_DSA_ESTABLISHED. Although the proxy agent MAY receive 350 many PDSRs from access devices, only one DSA per realm MUST be 351 established. Furthermore, the proxy is responsible for re- 352 establishing the DSA prior to expiration without any involvement by 353 the access device. 355 It is important to note that proxy agents establishing DSA's on 356 behalf of a client will most likely need to reorder AVPs during the 357 encryption process, in order to fit the encrypted AVPs within a CMS- 358 Encrypted-Data AVP. This is contrary to the rule established in the 359 Diameter base protocol [1], which states that proxy agents SHOULD NOT 360 reorder AVPs. 362 Allowing the first hop agent to be used to establish the DSA with the 363 home server MAY reduce the current concerns that the cryptographic 364 operations resulting from this specification MAY overburden embedded 365 access devices. 367 1.4 Using Redirect agents in lieu of DSA 369 When a redirect agent is used, allowing an access device, relay or 370 proxy agent to communicate directly with the home server, the hop-by- 371 hop security mechanisms specified in the base protocol MAY be 372 sufficient. 374 However, there are certain business models where signing of selected 375 Diameter AVPs (e.g. accounting) MAY be desired when redirect agents 376 are used. Figure 4 shows an example where the relay agent contacts 377 the redirect agent to retrieve the necessary information for it to 378 communicate directly with the home server, which MAY include the home 379 server's certificates. 381 The relay agent MAY then initiate a DSA with the home server, using 382 the certificates provided by the redirect agents. 384 +------+ 385 | | 386 | DRD | 387 | | 388 +------+ 389 ^ | 390 2. Request | | 3. Redirection 391 | | Notification 392 | v 393 +------+ ---------> +------+ <--------> +------+ 394 | | 1. Request | | 4. DSAR/DSAA | | 395 | NAS | | DRL | | HMS | 396 | | 6. Answer | | 5. Request/Answer | | 397 +------+ <--------- +------+ <--------> +------+ 398 mno.net mno.net abc.com 400 Figure 4: DSA Setup following redirect 402 The CMS specification allows for Diameter AVPs to be multiply-signed 403 (see section 6.1), which may prove useful in business models that 404 require both parties to sign accounting data in parallel. This scheme 405 provides some assurance that both parties agreed to the accounting 406 data, which MAY be used for settlement purposes. 408 1.5 When to use DSAs 410 Given that asymmetric transform operations are expensive, access 411 devices and/or Diameter agents MAY wish to restrict establishment of 412 a DSA to cases where the participants belong to a different 413 administrative domain. 415 1.6 Who can authorize users 417 In this specification, we define how a Diameter Security Association 418 is established at the application layer to secure AVPs within a 419 message. However, it is important to note that one of participants 420 of a DSA (specifically the one in the home network) MUST belong to 421 the same realm as the user being authorized (the realm portion of the 422 Network Access Identifier found in the User-Name AVP), otherwise an 423 answer is returned with the Result-Code AVP set to 424 DIAMETER_AUTHORIZATION_REJECTED. This limitation will prevent 425 bigco.com from authorizing (or rather declining authorization) for 426 users at smallco.com. The realm of the participants is found in the 427 subjectAltName field of the Diameter server's X.509 certificate. 429 1.7 Advertising application support 431 Diameter nodes conforming to this specification MAY advertise support 432 by including the value of two (2) in the Auth-Application-Id or the 433 Acct-Application-Id AVP of the Capabilities-Exchange-Request and 434 Capabilities-Exchange-Answer command [1]. 436 2.0 AVP Format 438 The Diameter base protocol [1] details the AVP header, which includes 439 the 'P' bit, but does not specify how the 'P' bit is used. The 'P' 440 bit, known as the protected AVP bit, is used to indicate whether the 441 AVP is protected by a digital signature. When set, the AVP is 442 protected and the contents cannot be changed by agents without 443 detection. 445 0 1 2 3 446 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 448 | AVP Code | 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 |V M P r r r r r| AVP Length | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | Vendor-ID (opt) | 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 454 | Data ... 455 +-+-+-+-+-+-+-+-+ 456 Figure 5: Diameter AVP Header 458 All Diameter specifications MUST specify whether the 'P' bit can be 459 set or not, as is done in section 4.6 of [1] and section 6 below. 460 For AVPs that are designed to be changed at each hop (such as the 461 Proxy-Info AVP) Diameter nodes MUST NOT allow the 'P' bit to be set. 463 Diameter implementations MUST check whether AVPs with its 'P' bit set 464 are allowed to use it. If not, an appropriate error message MUST be 465 issued containing DIAMETER_INVALID_AVP_BIT_COMBO result code. 467 3.0 Key Management 469 For DSA origin authentication, CMS itself already provides sufficient 470 key management without the need for additional specification. 471 Basically, the originating Diameter node signs and includes whatever 472 certificates are necessary for validation of the digital signature. 473 Section 3.1 provides an example of how the Diameter CMS Security 474 application is used. 476 In order to encrypt AVPs for a recipient, the originating Diameter 477 node must have a copy of the recipient's public key. There are many 478 well-known key retrieval schemes (e.g. LDAP [6]), but this 479 specification also allows for the transportation of certificates 480 within Diameter AVPs, which is expected to simplify implementations. 481 Section 3.2 describes how Diameter node names are encoded within such 482 certificates. 484 Finally, it is anticipated that the overhead of key generation for 485 each Diameter message sent to a given peer could be significant. 486 Section 3.4 specifies how CMS encryption keys may be reused for 487 multiple Diameter messages. 489 3.1 Usage Scenario 491 When a Diameter node is about to send a message, it must determine 492 whether a DSA should be established or not. We assume the Diameter 493 node knows the user's realm, perhaps through the User-Name AVP. 495 Implementations MAY cache the information required to establish a 496 DSA. However, they MUST honor time-to-live settings so that 497 certificates MUST re-validated (possibly including revocation checks) 498 once the DSA has expired. 500 Revalidations SHOULD also occur before the DSA expires according to 501 PKI policies. During the process of certificate path validation some 502 implementations will calculate a duration for which the certificate 503 path may be considered "safe". For example, if an implementation did 504 not support certificate revocation checks, then the "safe" period 505 would be from the time of initial validation until the earliest 506 notAfter time in the set of certificates in the path. An 507 implementation which does support certificate revocation checks will 508 typically be able to calculate a "safe" period based additionally on 509 the earliest nextUpdate field in a CRL or OCSP response. Basically, 510 the safe period is from the time of certificate validation to the 511 earliest value from the set of notAfter and nextUpdate fields 512 encountered during certificate validation. 514 However, implemetors should note that CAs MAY issue additional CRLs 515 before the nextUpdate period. Generally it is a matter of local PKI 516 policy as to whether an implementation will make additional checks 517 even during the calculated "safe" period. For the purposes of this 518 specification implementations are not required to make such checks 519 and MAY assume that no re-validation of certificates is required 520 during the "safe" period defined above. 522 We use Diameter Security Association Request (DSAR) and Diameter 523 Security Association Answer (DSAA) messages to establish a DSA, which 524 specifies which AVPs should be encrypted, signed or both, as well as 525 which public key(s) to use. 527 The originating node sends the DSAR message to a server in the 528 destination realm. The DSAR message contains: 530 - TTL for this DSA (seconds) 531 - the realm part of the user's NAI 532 - the list of direct trust CA's that the originating Diameter 533 node has configured into it for certificate validation. A 534 "direct trust" CA is one that the node is willing to use as the 535 "top" of a certificate chain, sometimes confusingly known as a 536 "root CA." 537 - a flag indicating whether the originating Diameter node wishes 538 to receive certificate status information using OCSP messages. 539 If this flag requires a fresh OCSP response, a nonce to be used 540 by the destination Diameter node in OCSP requests MUST also be 541 supplied. See [9] for more details on the certificate status 542 protocol and messages. 544 The destination node MUST check that the provided elements of the 545 DSAR are valid. It MUST check, at least, that: 547 - Its local policy allows the given TTL, realm, AVP protection 548 expectations, certification status, and other parameters. 549 - A common "top" of the certificate chain can be found between the 550 home and foreign domains. 552 If these conditions can not be verified, the destination node MUST 553 return a DSAA with the Result-Code AVP set to 554 DIAMETER_NO_DSA_ESTABLISHED. 556 In the event the DSAR requested OCSP validation, via the OCSP-Request 557 AVP, and OCSP is not locally supported, the DSAA MUST be returned 558 with the Result-Code AVP set to DIAMETER_OCSP_NOT_SUPPORTED. 559 Otherwise, the destination node returns the DSAA message which 560 contains: 562 - TTL for this DSA (seconds) 563 - a chain of CA certificates (possibly empty) 564 - public key certificates for the Diameter servers in the realm, 565 all of which MUST validate up to one of the CA's contained in 566 the DSAR message, via the chain of CA certificates above; 567 - (optionally, if OCSP an response was requested in the DSAR and 568 OCSP is supported) a list of OCSP responses for the 569 certificates in question. If a fresh response was required and 570 a nonce value was included, each response will contain the 571 nonce from the DSAR message 573 The originating Diameter node now has to check the response. Any 574 failure results in error messages, auditing and not sending the 575 Diameter message. 577 Checks: 579 - the certificate chain provided in the DSAA is cryptographically 580 correct, passes the (relevant parts of the) path validation 581 algorithm specified in [4] and terminates at a CA mentioned in 582 the DSAR message 583 - the name in the certificate is consistent with the rules 584 detailed in section 3.2. 585 - the DSAA message MUST include the CMS-Signed-Data AVP, the 586 signature MUST be validated and the signer's certificate chain 587 MUST terminate as a CA mentioned in the DSAR message 588 - the expiration of the TTL MUST be less or equal to the earliest 589 expiration of all certificates in the message, encoded in the 590 notAfter field. 592 If the DSA initiator's policy states that certificate status is 593 required, it MUST indicate that it requires an OCSP response from the 594 DSA peer in the DSAA message, via the OCSP-Request AVP. Further, the 595 DSA initiator MAY request that the OCSP response be fresh (non 596 cached) via the OCSP-Request and OCSP-Nonce AVPs. Upon receipt of a 597 DSAR message requesting an OCSP response, the receiver issues an OCSP 598 request and returns the response within the DSAA message's OCSP- 599 Responses AVP. The sender of the DSAA MAY included a cached OCSP 600 response, unless the requestor specifically requested a fresh 601 response. 603 The nonce value is to be (the beginning of) the nonce in the OCSP 604 response. The reason for this is that the responder MAY add 605 additional bits to the nonce, but the nonce provided in the OSCP- 606 Nonce MUST be present at the beginning of the nonce of the OSCP 607 response. 609 The DSAR message MAY include the CMS-Signed-Data AVP. If the 610 originating node has a private key, and it includes AVPs whose 'P' 611 bit set, the CMS-Signed-Data AVP MUST be present. 613 The DSAA MUST include the CMS-Signed-Data, signed by a Diameter agent 614 or server within the user's realm, to prevent an intermediate node 615 from modifying the protection expectations for AVPs. 617 Depending upon the security technique required (digital signature, 618 encryption or both), then the originating node prepares the CMS 619 related AVPs as required. 621 If certificate revocation is enabled, anytime a certificate is used 622 from the local certificate cache, a revocation check MUST be 623 performed. 625 Once the DSA is in place, any Diameter messages exchanged between the 626 two peers MUST sign any AVPs whose definition states that the 'P' bit 627 may be set. Furthermore, these peers MUST encrypt any AVPs whose 628 definition states that it may be encrypted. 630 3.2 Certificate Requirements 632 Certificates used for the purposes of Diameter MUST conform to the 633 PKIX profile [4], and MUST also include a Diameter node's FQDN, which 634 is typically added in the Origin-Host AVP [1], as one of the values 635 of the subjectAltName extension of the Certificate. The FQDN is to 636 be encoded as a dNSName within the subjectAltName. 638 For Diameter nodes (capable of acting as recipients for 639 confidentiality), the FQDN MUST be of the form 640 "Diameter-.". Other Diameter nodes MAY use this naming 641 scheme. Note that this naming constraint is for PKI purposes only, 642 and in no way restricts a Diameter's host name. 644 The naming scheme presented here is intended to: 645 - make it simple to use existing certification authorities (CAs) 646 for Diameter CMS 647 - allow CAs to ensure that only "proper" Diameter certificates are 648 accepted by Diameter nodes 649 - allow Diameter certificates to be used for other purposes where 650 that meets a CA's practices. 652 These names are used for two purposes: 654 1. Where a Diameter node is verifying a signature it needs to be 655 able to compare the identity of the signer against the identity 656 in the Origin-Host AVP. 658 2. Where a Diameter node is encrypting AVPs, it needs to be able 659 to ensure that it uses a public key for the intended recipient. 660 This requires comparing the identity in a Certificate against 661 the FQDN of the intended recipient (which is assumed to be 662 known). 664 In either case, the presence of the required FQDN as a dNSName value 665 in the subjectAltName extension of a verified public key certificate 666 satisfies the matching requirement. 668 Note that there MAY also be other values in the subjectAltName 669 extension, (either using dNSName or other elements of the CHOICE), 670 these can be safely ignored, but implementations MUST be able to 671 handle their presence. 673 Note also that the PKIX profile [4], section 4.1.2.6, specifies the 674 rules for the relationship between the subjectAltName extension and 675 the subject field of public key certificates. 677 For multiple Diameter servers within a realm that share a public key, 678 each server's identity is encoded in the subjectAltName extension. 679 This allows any server within a realm to decrypt AVPs intended for 680 that realm. 682 Note that once operational experience has been gained, a future 683 document may specify a restricted profile of [4] in order to simplify 684 implementation. 686 3.3 Algorithms 688 For all uses of CMS in this specification the mandatory to implement 689 algorithms are as follows: 691 - Hashing: 692 sha-1 (see [3] section 12.1.1) 693 - Signature (the hash algorithm is specified separately): 694 rsaEncryption (see [3] section 12.2.2) 695 - Content Encryption: 696 des-ede3-cbc (see [3] section 12.4.1) 697 - Asymmetric key transport: 698 rsaEncryption (see [3] 12.3.2.1) 699 - Symmetric key encryption (only needed in conjunction with [15]): 700 id-alg-CMS3DESwrap (see [3] section 12.3.3.1) 702 At some point in future, AES will replace 3DES. 704 3.4 Reuse of CMS Content Encryption Keys 706 This section describes an efficiency improvement which MAY be 707 supported by Diameter nodes. If a node doesn't support this feature, 708 then it MUST (and naturally will), treat all packets with re-used 709 content encryption keys as a cryptographic failure. The originating 710 node MAY then attempt to re-send the packets using asymmetric key 711 transport. If a node does support this feature, then the MUST/SHOULD 712 statements in this section apply, otherwise not. 714 Once a CMS-Encrypted-Data AVP has been exchanged between two Diameter 715 peers, then they share a symmetric cryptographic key (the content 716 encryption key) which can be used to encrypt further Diameter AVPs 717 between the peers by using the scheme specified in [15]. The peers 718 MUST first take part in an DSAR/DSAA exchange in order to distribute 719 the required asymmetric keys. 721 Although the use of symmetric encryption might be used to provide 722 integrity or confidentiality, it does not provide non-repudiation 723 with proof of origin. 725 [15] leaves open some issues, namely how to handle loss of a shared 726 secret (say following a peer re-boot) and for how long to continue to 727 use a shared secret (the maximum number of decryptions required). 729 Where a Diameter node receives a CMS-Encrypted-Data AVP, but doesn't 730 have the required shared secret, that node should return the 731 DIAMETER_KEY_UNKNOWN error message. The peer may then use the 732 DSAR/DSAA exchange to rebuild their Diameter security association. 734 In [15], the default value for the maximum number of decryptions 735 allowed (CEKMaxDecrypts) when re-using a content encryption key is 1. 736 In general this default SHOULD be used, but if a Diameter node 737 "knows" that more than one CMS-Encrypted-Data AVP will be exchanged 738 between the nodes, then the CEKMaxDecrypts setting MAY be set higher. 739 Diameter nodes MUST be able to support a maxDecrypts setting of 1000. 741 Note that the CEKMaxDecrypts value used does not affect that DSA-TTL. 742 The DSA-TTL dictates the lifetime of the DSA, while the 743 CEKMaxDecrypts dictates how often rekeying will occur within the CMS 744 protocol. A content encryption key MUST NOT be reused once the DSA 745 has expired. Implementations MUST be able to support a DSA-TTL of one 746 day, and nodes which support certificate checking (e.g. CRLs, OCSP) 747 that are re-establishing a DSA due to expiration of the TTL MUST re- 748 validate the certificate. 750 4.0 Command-Codes Values 752 This section defines new Command-Code [1] values that MUST be 753 supported by all Diameter implementations that conform to this 754 specification. The following Command Codes are currently defined in 755 this document: 757 Command-Name Abbrev. Code Reference 758 -------------------------------------------------------- 759 Diameter-Security- DSAR 304 4.1 760 Association-Request 761 Diameter-Security- DSAA 304 4.2 762 Association-Answer 763 Proxy-Diameter-Security- PDSR 305 4.3 764 Association-Request 765 Proxy-Diameter-Security- PDSA 305 4.4 766 Association-Answer 768 4.1 Diameter-Security-Association-Request 770 The Diameter-Security-Association-Request command, indicated by the 771 Command-Code field set to 304 and the 'R' bit set in the message 772 flags field, is sent by a Diameter node to establish a Diameter 773 Security Association. The DSAR message MUST NOT be used simply as a 774 convenient certificate distribution protocol without establishing a 775 DSA. The CMS-Signed-Data AVP MUST be present if any AVP in the 776 message has the 'P' bit set. 778 Message Format 780 ::= < Diameter-Header: 304, REQ, PXY > 781 { Origin-Host } 782 { Origin-Realm } 783 { Destination-Realm } 784 * { Local-CA-info } 785 { Auth-Application-Id } 786 { OCSP-Request-Flags } 787 { DSA-TTL } 788 [ Destination-Host ] 789 0*1[ CA-Chain ] 790 * [ AAA-Node-Cert ] 791 [ OCSP-Nonce ] 792 0*1[ CMS-Signed-Data ] 793 [ Origin-State-Id ] 794 * [ AVP ] 795 * [ Proxy-Info ] 796 * [ Route-Record ] 798 4.2 Diameter-Security-Association-Answer 800 The Diameter-Security-Association-Answer command, indicated by the 801 Command-Code field set to 304, with the 'R' bit in the Command Flags 802 cleared, in response to a DSAR. The CMS-Signed-Data AVP MUST be 803 present if any AVP in the message has the 'P' bit set. If the Result- 804 Code AVP indicates success, the CA-Chain, AAA-Node-Cert, DSA-TTL and 805 CMS-Signed-Data AVPs MUST be present. 807 Message Format 809 ::= < Diameter-Header: 304, PXY > 810 { Result-Code } 811 { Origin-Host } 812 { Auth-Application-Id } 813 [ Origin-Realm ] 814 * { Local-CA-info } 815 [ Error-Message ] 816 [ Error-Reporting-Host ] 817 0*1[ CA-Chain ] 818 * [ AAA-Node-Cert ] 819 [ DSA-TTL } 820 * [ OCSP-Responses ] 821 [ CMS-Signed-Data ] 822 [ Origin-State-Id ] 823 * [ AVP ] 824 * [ Proxy-Info ] 826 4.3 Proxy-Diameter-Security-Association-Request 828 The Proxy-Diameter-Security-Association-Request command, indicated by 829 the Command-Code field set to 305 and the 'R' bit set in the Command 830 Flags field, is sent by a Diameter node to request that a downstream 831 proxy establishes a Diameter Security Association with a server in a 832 given realm on its behalf. 834 Message Format 836 ::= < Diameter-Header: 305, REQ, PXY > 837 { Origin-Host } 838 { Origin-Realm } 839 { Destination-Realm } 840 { Auth-Application-Id } 841 [ DSAR-Target-Realm ] 842 [ Origin-State-Id ] 843 [ Destination-Host ] 844 * [ AVP ] 845 * [ Proxy-Info ] 846 * [ Route-Record ] 848 4.4 Proxy-Diameter-Security-Association-Answer 849 The Proxy-Diameter-Security-Association-Answer command, indicated by 850 the Command-Code field set to 305 and the 'R' bit cleared in the 851 Command Flags field, is sent by a Diameter node in response to an 852 PDSR message. 854 Message Format 856 ::= < Diameter-Header: 305, PXY > 857 { Result-Code } 858 { Origin-Host } 859 { Origin-Realm } 860 { Auth-Application-Id } 861 { DSA-TTL } 862 [ Error-Message ] 863 [ Error-Reporting-Host ] 864 [ Origin-State-Id ] 865 * [ Redirect-Host ] 866 [ Redirect-Host-Usage ] 867 [ Redirect-Max-Cache-Time ] 868 * [ AVP ] 869 * [ Proxy-Info ] 871 5.0 Diameter Security Association Message Flow 873 This section contains an example of a NAS in realm xyz.com, 874 communicating with its local relay agent, which in turn communicates 875 with a server in ABC.COM's network. In the following example, once 876 the initial capabilities exchange is complete, the NAS receives a 877 request for access from alice@abc.com, which causes the DSA setup to 878 be initiated, followed by the application-specific authentication 879 request. 881 Although the example doesn't specifically use bi-directional digital 882 signature and encryption, this feature is supported. 884 +-------+ +-------+ +---------+ 885 | NAS | | Relay | | abc.com | 886 | | | Agent | |Home Srv | 887 +-------+ +-------+ +---------+ 888 | | | 889 |CER apps 1, 2 | | 890 (a) |------------------->| | 891 |CAA apps -1 | | 892 (b) |<-------------------| | 893 | . |CER apps 1, 2 | 894 (c) | |<-------------------| 895 | |CEA apps -1 | 896 (d) | |------------------->| 897 ->| User alice@abc.com | | 898 (e) | Requests Access | | 899 | | | 900 | DSAR | | 901 | Dest-Realm=abc.com | | 902 | CMS-Cert | | 903 (f) |--------------------+------------------->| 904 | | DSAA | 905 | | Origin-Host=foo | 906 | | CMS-Cert | 907 (g) |<-------------------+--------------------| 908 | Auth-Request + | | 909 | CMS-Signed-Data | | 910 | Dest-Host=foo | | 911 (h) |--------------------+------------------->| 912 | | Auth-Answer + | 913 | | CMS-Encrypted-Data | 914 (i) |<-------------------+--------------------| 915 Figure 6: Example of a DSA Setup 917 (a) NAS sends a CER message to its relay agent indicating that it 918 supports applications 1 (NASREQ) and 2 (CMS Security). 920 (b) The relay agent sends a CEA message to the NAS indicating that 921 it is a relay supporting all Diameter applications. 923 (c) ABC.COM's Home Server sends a CER message to a relay agent 924 indicating that it supports applications 1 (NASREQ) and 2 925 (CMS Security). 927 (d) The relay agent sends a CEA message to ABC.COM's Home Server 928 indicating that it is a relay supporting all Diameter 929 applications. 931 (e) The NAS receives a request for access from a user 932 (alice@abc.com). 934 (f) The NAS issues an DSAR message, with the Destination-Realm AVP 935 set to abc.com, and its certificate in the CMS-Cert AVP. The 936 DSAR includes the set of AVPs that the NAS expects to be 937 encrypted, in the event that the home server returns messages 938 that contain these AVPs. 940 (g) ABC.COM's Home Server processes the DSAR message, and replies 941 with the DSAA message. The DSAA also includes the set of AVPs 942 that the home server is expecting to be authenticated, as well 943 as its certificate in the CMS-Cert AVP. 945 (h) The NAS issues an authentication request with the Destination- 946 Host AVP set to the value of the Origin-Host AVP in the DSAA. 947 The message includes the CMS-Signed-AVP, which authenticates 948 the AVPs that were requested by the Home Server in the DSAA. 950 (i) The Home Server successfully authenticates the user, and 951 returns a reply, which includes the CMS-Encrypted-Data AVP, 952 whose contents include the AVPs that were specified by the NAS 953 in the DSAR. 955 6.0 CMS Security AVPs 957 This section contains AVPs that are used to establish a Diameter 958 Security Association, and to transport CMS objects. The profile of 959 CMS algorithm and structure usage is as specified in the S/MIME v3 960 message specification [11]. 962 +---------------------+ 963 | AVP Flag rules | 964 |----+-----+----+-----|----+ 965 AVP Section | | |SHLD| MUST|MAY | 966 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 967 -----------------------------------------|----+-----+----+-----|----| 968 AAA-Node-Cert 351 6.6 OctetString|M,P | | | V | N | 969 CA-Chain 353 6.8 OctetString| M | P | | V | N | 970 CA-Name 349 6.4.1 UTF8String | M | P | | V | N | 971 CMS-Encrypted- 355 6.2 OctetString| M | P | | V | N | 972 Data | | | | | | 973 CMS-Signed-Data 310 6.1 OctetString| M | | | P,V | N | 974 DSA-TTL 362 6.11 Unsigned32 | M | P | | P,V | N | 975 DSAR-Target- 360 6.10 UTF8String | M | P | | V | N | 976 Realm | | | | | | 977 Key-Hash 350 6.4.2 OctetString| M | P | | V | N | 978 Local-CA-Info 348 6.4 Grouped | M | P | | V | N | 979 OCSP-Nonce 358 6.5 OctetString| M | P | | V | N | 980 OCSP-Request- 361 6.9 Enumerated | M | P | | V | N | 981 Flags | | | | | | 982 OCSP-Responses 359 6.7 OctetString| M | P | | V | N | 984 The profile of CMS algorithm and structure usage is conformant to 985 that specified in the S/MIME v3 message specification [11]. This 986 makes is simpler to base an implementation of this specification upon 987 an existing S/MIME toolkit. 989 No MIME encoding of binary data is required for this specification. 990 This is different from the use of CMS in S/MIME, but is acceptable 991 since Diameter is a binary protocol and investigation has not shown 992 this to causes problems when using existing CMS & S/MIME toolkits. 994 6.1 CMS-Signed-Data AVP 996 The CMS-Signed-Data AVP (AVP Code 310) is of type OctetString and 997 contains the Basic Encoding Rules (BER) encoding of a CMS object [3] 998 of type ContentInfo. This means that where a set of AVPs is to be 999 signed, the set of AVPs with the 'P' bit set MUST first be catenated 1000 together in the order in which they occur in the Diameter message. 1001 The result of this encoding is used as input into the signing 1002 process. 1004 Note that the AVPs themselves are not encapsulated within the CMS- 1005 Signed-Data AVP. Instead, the digest value of the AVPs produced in 1006 the signature process MUST be included in the CMS-Signed- Data AVP, 1007 as a message-digest attribute (defined in section 11.2 of [3]) in the 1008 SignerInfo value. 1010 Multiple Diameter entities MAY add their signatures to an existing 1011 CMS-Signed-Data AVP. Multiple signatures are added within the 1012 countersignature attribute (defined in section 11.4 of [3]) and not 1013 as additional SignerInfo values. The countersignature attribute 1014 requires that the signatures occur sequentially, meaning that each 1015 signature covers the existing signatures in the CMS object. 1017 The initial signature, and any additional countersignatures, MUST 1018 cover the exact same set of AVPs, in the order they are present in 1019 the message. 1021 Note that the CMS-Signed-Data AVP itself MUST NOT be used in the 1022 generation of the signature, and therefore MUST NOT have its 'P' bit 1023 set. 1025 The eContent field of the EncapsulatedContentInfo structure MUST be 1026 absent since the digital signature covers data outside of the object. 1027 The signature is computed over all AVPs with the 'P' bit enabled. The 1028 order of the AVPs MUST be preserved and the computation begins with 1029 the first AVP immediately following the Diameter header. 1031 If a receiver cannot verify correctly the signature carried by the 1032 CMS-Signed-Data AVP, it SHOULD return the DIAMETER_INVALID_AUTH 1033 Result-Code AVP value defined in section 7.1. 1035 When AVPs are to be both encrypted and signed, the CMS-Encrypted-Data 1036 AVP MUST be created first. This AVP MUST then have the 'P' bit set 1037 and be one of the inputs to the signing process as described above. 1038 (Any other processing resulting in the same output can be used.) This 1039 means that signing is "outside" encryption. 1041 No more than one CMS-Signed-Data AVP MUST be present in any given 1042 Diameter message. 1044 6.2 CMS-Encrypted-Data AVP 1046 The CMS-Encrypted-Data AVP (AVP Code 355) is of type OctetString and 1047 contains the Basic Encoding Rules (BER) encoding of a CMS object [3] 1048 of type ContentInfo. 1050 All AVPs to be encrypted are concatenated. This value is then: 1052 - encrypted according to normal CMS rules, 1053 - used as the value of the EncryptedContent field within 1054 EnvelopedData. 1056 The contentType of the EncryptedContentInfo value MUST be id- 1057 data [11]. 1059 A CMS-Encrypted-Data AVP contains exactly one EnvelopedData. 1060 Where one or more AVP would be encrypted within separate 1061 EnvelopedData structures, then separate CMS-Encrypted-Data AVPs 1062 MUST be used. 1064 Thus, implementations MUST be able to support the presence of 1065 multiple CMS-Encrypted-Data AVPs and MUST be able to decrypt any 1066 EnvelopedData for which it is a recipient, as indicated in the 1067 EnvelopedData's RecipientInfos field [3]. 1069 If the recipient is not specified in a RecipientInfo, it MAY 1070 choose to process the message or return an answer with the 1071 Result-Code AVP set to DIAMETER_NO_DSA_RECIPIENT. If the 1072 recipient is in the RecipientInfos and an error occurs during 1073 decryption, then the recipient MUST answer with the Result-Code 1074 set to DIAMETER_INVALID_AVP_VALUE. 1076 Diameter nodes SHOULD implement content encryption key reuse 1077 (see section 3.4 above). 1079 If a receiver detects that the contents of the CMS-Encrypted- 1080 Data AVP are invalid, it SHOULD answer with the Result-Code set 1081 to DIAMETER_INVALID_CMS_DATA. 1083 Zero or more CMS-Encrypted-Data AVP MAY be present in any 1084 Diameter message. 1086 6.3 Example Encodings 1088 In order to clarify the contents of and the relationships between 1089 CMS-Signed-Data and CMS-Encrypted-Data AVPs we present the following 1090 example of how these AVPs are calculated. 1092 First, some short-hand: 1094 - The "|" character represents concatenation 1095 - EnvelopedData-fnc(x,y) represents the EnvelopedData produced as 1096 output of a function with x as the to-be-encrypted-data and y as 1097 the parameters (e.g. recipient information). 1098 - SignedData (y) represents the SignedData produced as output of a 1099 function with the catenation of the 'P is set' AVPs as the 1100 to-be-digested-data (which is not part of the output!) and y 1101 as the parameters (e.g. signer information). 1103 The scenario calls for a message containing 7 AVPs s,t,e,p,h,e' and n 1104 to meet the following: 1105 AVPs s, t and e are to be encrypted for recipient P. 1106 AVPs e, p and h are to be encrypted for recipient A. 1107 AVPs s, and e' are to be signed by originator T. 1108 AVP s is to be sent to recipient A. 1109 AVP n needs neither signing nor encryption. 1111 Note that though there is no explicit requirement that AVP s be 1112 encrypted for A, since it will be encrypted for P, we also have to 1113 encrypt it for A. Implementations SHOULD NOT send the same AVP both 1114 encrypted and in clear. 1116 The resulting message will look like: 1117 AVP1='P is set', EnvelopedData-fnc(s|t|e,P) 1118 AVP2='P is set', EnvelopedData-fnc(s|e|p|h,A) 1119 AVP3='P is set', e' 1120 AVP4='P is clear', n 1121 AVP5='P is clear', SignedData(T) 1123 The result of this is that all AVPs except n are actually signed even 1124 though signing of t and e wasn't explicitly required. However, this 1125 is no harm. 1127 6.4 Local-CA-Info AVP 1129 The Local-CA-Info AVP (AVP Code 348) is of type Grouped. The Grouped 1130 Data field has the following ABNF grammar: 1132 Local-CA-Info ::= < AVP Header: 348 > 1133 { CA-Name } 1134 { Key-Hash } 1136 6.4.1 CA-Name AVP 1138 The CA-Name AVP (AVP Code 349) is of type UTF8String. The AVP 1139 contains the DN (in LDAP string syntax) of the Certificate Authority, 1140 e.g. "CN=CA;O=Baltimore Technologies;C=IE". 1142 6.4.2 Key-Hash AVP 1144 The Key-Hash AVP (AVP Code 350) is of type OctetString, and contains 1145 a SHA-1 hash of the key. 1147 The hash MUST be calculated over the representation of the CA public 1148 key which would be present in an X.509 public key certificate, 1149 specifically, the input for the hash algorithm MUST be the DER 1150 encoding of a SubjectPublicKeyInfo representation of the key. Note: 1151 This includes the AlgorithmIdentifier as well as the BIT STRING. The 1152 rules given in [4] for encoding keys MUST be followed. 1154 Since this AVP is used for indexing and not for security (since 1155 Diameter nodes SHOULD validate certificates), there is no need to 1156 support more than one hash algorithm here. 1158 6.5 OCSP-Nonce AVP 1160 The OCSP-Nonce AVP (AVP Code 358) is of type OctetString, and 1161 contains a random value (RECOMMENDED 128 bits) generated by the 1162 Diameter node. 1164 6.6 AAA-Node-Cert AVP 1166 The AAA-Node-Cert AVP (AVP Code 351) is of type OctetString and 1167 contains a public key certificate for the AAA node. Note: this AVP 1168 contains no CA certificates, just the end-entity certificate. 1169 Certificates MUST follow the naming conventions described in section 1170 3.2. 1172 6.7 OCSP-Responses AVP 1174 The OCSP-Responses AVP (AVP Code 359) is of type OctetString, and 1175 contains an OCSP response message from an OCSP responder. If the 1176 OCSP-Request-Flags AVP indicating a response was required in the 1177 corresponding request message, the OCSP-Responses AVP MUST be 1178 present. Furthermore, the OCSP-Request-Flags AVP MAY request a fresh 1179 OCSP response message, which MUST also include the OCSP-Nonce AVP. 1181 6.8 CA-Chain AVP 1183 The CA-Chain AVP (AVP Code 353) is of type OctetString, and contains 1184 a certificate chain, from one of the nominated locally trusted CAs 1185 down to the (one and only) CA which has issued the end entity 1186 certificates in the AAA-Node-Cert AVP. 1188 To produce this AVP in an DSAA message, one (and only one) of the 1189 Local-CA-info values from the corresponding DSAR message is selected 1190 (call this the "top" CA for the purposes of this description). This 1191 AVP then contains a certificate path (in order) from the "top" CA 1192 down to the (one and only) CA which has issued the end entity 1193 certificate in the AAA-Node-Cert AVP. The (typically self-signed), 1194 certificate of the "top" CA MUST NOT be included. 1196 6.9 OCSP-Request-Flags AVP 1198 The OCSP-Request-Flags AVP (AVP Code 361) is of type Enumerated, and 1199 specifies whether the sender wishes to receive an OCSP response. The 1200 following values are defined: 1202 NO_OCSP_RESPONSE 0 1203 The sender does not wish to receive an OCSP Response. 1205 OCSP_RESPONSE 1 1206 The sender wishes to receive an OCSP Response, and is willing 1207 to accept a stale response. 1209 OCSP_FRESH_RESPONSE 2 1210 The sender wishes to receive a fresh OCSP Response. When this 1211 value is set, the OCSP-Nonce AVP MUST be present. 1213 6.10 DSAR-Target-Realm AVP 1215 The DSAR-Target-Realm AVP (AVP Code 360) is of type UTF8String, and 1216 contains the Destination-Realm of the resulting DSAR sent by a non- 1217 transparent proxy. 1219 6.11 DSA-TTL AVP 1221 The DSA-TTL AVP (AVP Code 362) is of type Unsigned32, and contains 1222 the time to live (in seconds) of the Diameter Security Association. 1223 The expiration time (now+TTL) MUST NOT be greater than the earliest 1224 expiration time (NotAfter field) of all certificates included in this 1225 message accompanying this AVP. The DSA-TTL AVP in the DSAA MUST NOT 1226 be greater than the DSA-TTL AVP in the DSAR. A DSA-TTL AVP MUST also 1227 be included in the PDSA in order to provide information about the 1228 lenght of the DSA established by the proxy on behalf of the access 1229 device. Implementations MUST be able to support a DSL-TTL of one day. 1231 7.0 Result-Code AVP Values 1233 This section defines new Result-Code [1] values that MUST be 1234 supported by all Diameter implementations that conform to this 1235 specification. 1237 7.1 Transient Failures 1239 Errors that fall within the transient failures category are used to 1240 inform a peer that the request could not be satisfied at the time it 1241 was received, but MAY be able to satisfy the request in the future. 1243 DIAMETER_KEY_UNKNOWN 4008 1244 This error code is returned when a CMS-Signed-Data or CMS- 1245 Encrypted-Data AVP is received that was generated using a key 1246 that is not locally recognized. This error could be caused if 1247 one of the participants of a DSA lost a previously agreed upon 1248 key, perhaps as a result of a reboot. 1250 DIAMETER_NO_CMS_THROUGH_PROXY 4009 1251 This error code is returned when a non-transparent proxy 1252 receives an DSAR message to state that it doesn't allow a DSA 1253 through it since it plans to modify AVPs. 1255 DIAMETER_CAN_ACT_AS_CMS_PROXY 4010 1256 This error code is returned when a non-transparent proxy 1257 receives an DSAR message, and although it doesn't allow a DSA 1258 through it, it is willing to initiate a DSA on behalf of the 1259 access device. 1261 DIAMETER_OCSP_NOT_SUPPORTED 4011 1262 This error code is returned when a DSAR message is received 1263 requesting OCSP validation, and the receiver does not support 1264 OCSP. 1266 DIAMETER_INVALID_AUTH 4012 1267 The signature in the CMS-Signed-Data AVP is invalid. 1269 DIAMETER_MISSING_SIGNED_AVPS 4013 1270 Some AVPs within a Diameter message were expected to be signed. 1272 7.2 Permanent Failures 1274 Errors that fall within the permanent failures category are used to 1275 inform the peer that the request failed, and should not be attempted 1276 again. 1278 DIAMETER_INVALID_CMS_DATA 5019 1279 This error code is returned when a CMS-Data AVP is received 1280 with an invalid ContentInfo object. 1282 DIAMETER_NO_COMMON_TRUST 5020 1283 This error code is returned when a receiver receives a DSAR for 1284 which it has no common trust with the sender, which is required 1285 to establish the DSA. 1287 DIAMETER_NO_DSA_ESTABLISHED 5021 1288 A Diameter message refers to a Diameter Security Association 1289 which does not exist. 1291 DIAMETER_DSA_EXPIRED 5022 1292 A Diameter message refers to a Diameter Security Association 1293 which has expired. 1295 DIAMETER_NO_DSA_RECIPIENT 5023 1296 A Diameter message was received with encrypted data, and the 1297 local Diameter node is not a potential recipient of the 1298 EnvelopedData. 1300 8.0 AVP Occurrence Tables 1302 The table in this section presents the AVPs defined in this document, 1303 and specifies in which Diameter messages they MAY, or MAY NOT be 1304 present. Note that AVPs that can only be present within a Grouped 1305 AVP are not represented in this table. 1307 The table uses the following symbols: 1308 0 The AVP MUST NOT be present in the message. 1309 0+ Zero or more instances of the AVP MAY be present in the 1310 message. 1311 0-1 Zero or one instance of the AVP MAY be present in the 1312 message. 1313 1 One instance of the AVP MUST be present in the message. 1314 1+ At least one instance of the AVP MUST be present in the 1315 message. 1317 +-----------------------+ 1318 | Command-Code | 1319 |-----+-----+-----+-----+ 1320 Attribute Name | DSAR| DSAA| PDSR| PDSA| 1321 ------------------------------|-----+-----+-----+-----+ 1322 Auth-Application-Id | 1 | 1 | 1 | 1 | 1323 Destination-Host | 0-1 | 0 | 0 | 0 | 1324 Destination-Realm | 1 | 0 | 1 | 0 | 1325 Error-Message | 0 | 0-1 | 0 | 0-1 | 1326 Error-Reporting-Host | 0 | 0-1 | 0 | 0-1 | 1327 AAA-Node-Cert | 0-1 | 0-1 | 0 | 0 | 1328 CA-Chain | 0-1 | 0-1 | 0 | 0 | 1329 CA-Name | 0 | 0 | 0 | 0 | 1330 CMS-Cert | 0-1 | 0 | 0 | 0 | 1331 CMS-Encrypted-Data | 0 | 0 | 0 | 0 | 1332 CMS-Signed-Data | 0-1 | 0-1 | 0 | 0 | 1333 DSA-TTL | 1 | 1 | 0 | 0 | 1334 DSAR-Target-Realm | 0 | 0 | 0-1 | 0 | 1335 Local-CA-Info | 0+ | 0+ | 0 | 0 | 1336 OCSP-Nonce | 0-1 | 0 | 0 | 0 | 1337 OCSP-Request-Flags | 1 | 0 | 0 | 0 | 1338 OCSP-Responses | 0 | 1+ | 0 | 0 | 1339 Origin-Host | 1 | 1 | 1 | 1 | 1340 Origin-Realm | 1 | 1 | 1 | 1 | 1341 Original-State-Id | 0-1 | 0-1 | 0-1 | 0-1 | 1342 Proxy-Info | 0+ | 0+ | 0+ | 0+ | 1343 Redirect-Host | 0 | 0+ | 0 | 0+ | 1344 Redirect-Host-Usage | 0 | 0-1 | 0 | 0-1 | 1345 Redirect-Max-Cache-Time | 0 | 0-1 | 0 | 0-1 | 1346 Result-Code | 0 | 1 | 0 | 1 | 1347 Route-Record | 0+ | 0 | 0+ | 0 | 1348 ------------------------------|-----+-----+-----+-----| 1350 9.0 IANA Considerations 1352 This section contains the namespaces that have either been created in 1353 this specification, or the values assigned to existing namespaces 1354 managed by IANA. 1356 9.1 Command Codes 1358 This specification assigns the value 304 and 305 from the Command 1359 Code namespace defined in [1]. See section 4.0 for the assignment of 1360 the namespace in this specification. 1362 9.2 AVP Codes 1364 This specification assigns the values 348-351, 353, 355, 358-362 from 1365 the AVP Code namespace defined in [1]. See section 6.0 for the 1366 assignment of the namespace in this specification. 1368 9.3 Result-Code AVP Values 1370 This specification assigns the values 4008-4011, 5019-5023 from the 1371 Result-Code AVP (AVP Code 268) value namespace defined in [1]. See 1372 section 7.0 for the assignment of the namespace in this 1373 specification. 1375 9.4 Application Identifier 1377 This specification assigns the value two (2) to the Application 1378 Identifier namespace defined in [1]. See section 1.6 for more 1379 information. 1381 9.5 OCSP-Request-Flags AVP Values 1383 As defined in Section 6.9, the OCSP-Request-Flags AVP (AVP Code 361) 1384 defines the values 0-2. All remaining values are available for 1385 assignment via IETF Consensus [12]. 1387 10.0 Security Considerations 1389 This document describes how CMS security can be achieved in the 1390 Diameter protocol by allowing S/MIME Cryptographic Message Syntax [3] 1391 objects to be carried as a Diameter AVP. 1393 This specification does not mandate certificate revocation, however 1394 not verifying whether a given certificate has been revoked has 1395 serious implications, and MAY create a security hole. 1397 The PDSR and PDSA messages (sections 4.3 and 4.4) allow a third party 1398 proxy to establish a Diameter security association with a Diameter 1399 server in a target realm. An access device MUST ensure that the 1400 server establishing the SA on its behalf is a trusted entity, since 1401 the proxy in question could modify Diameter messages, which would be 1402 very difficult to trace. 1404 11.0 References 1405 [1] P. Calhoun, H. Akhtar, J. Arkko, E. Guttman, A. Rubens, "Diameter 1406 Base Protocol", draft-ietf-aaa-diameter-08.txt, IETF work in 1407 progress, November 2001. 1409 [2] Kaufman, Perlman, Speciner, "Network Security: Private Communica- 1410 tions in a Public World", Prentice Hall, March 1995, ISBN 1411 0-13-061466-1. 1413 [3] R. Housley, "Cryptographic Message Syntax", RFC 2630, June 1999. 1415 [4] Housley, Ford, Polk, Solo, "Internet X.509 Public Key Infrastruc- 1416 ture Certificate and CRL Profile", RFC 2459, January 1999. 1418 [5] S. Bradner, "Key words for use in RFCs to Indicate Requirement Lev- 1419 els", BCP 14, RFC 2119, March 1997. 1421 [6] Boyen, Howes, Richard, "Internet X.509 Public Key Infrastructure 1422 Operational Protocols - LDAPv2", RFC 2559, April 1999. 1424 [7] T. Hiller et al., "Cdma2000 Wireless Data Requirements for AAA", 1425 RFC 3141, June 2001. 1427 [8] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, Autho- 1428 rization, and Accounting Requirements". RFC 2977. October 2000. 1430 [9] Myers, Ankney, Malpani, Galperin, Adams, "X.509 Internet Public Key 1431 Infrastructure Online Certificate Status Protocol (OCSP)", RFC 1432 2560, June 1999. 1434 [10] Aboba et al., "Criteria for Evaluating AAA Protocols for Network 1435 Access", RFC 2989, November 2000. 1437 [11] B. Ramsdell, "S/MIME Version 3 Message Specification", RFC 2633, 1438 June 1999. 1440 [12] S. Farrell, R. Housley, "An Internet Attribute Certificate Profile 1441 for Authorization", draft-ietf-pkix-ac509prof-09.txt, IETF work in 1442 progress, June 2001. 1444 [13] P. Calhoun, W. Bulley, G. Zorn, "Diameter NASREQ Application", 1445 draft-ietf-aaa-Diameter-nasreq-08.txt, IETF work in progress, 1446 November 2001. 1448 [14] P. Calhoun, C. Perkins, "Diameter Mobile IP Application", draft- 1449 ietf-aaa-Diameter-mobileip-08.txt, IETF work in progress, November 1450 2001. 1452 [15] Farrell, Turner, "Reuse of CMS Content Encryption Keys", RFC 3185, 1453 October 2001. 1455 [16] N. Freed, N. Borenstein, " MIME Part 1: Format of Internet Message 1456 Bodies", RFC 2045, November 1996. 1458 [17] N. Freed, N. Borenstein, " MIME Part 2: Media Types", RFC 2046, 1459 November 1996. 1461 12.0 Acknowledgements 1463 The authors would also like to acknowledge the following people for 1464 their contribution in the development of this specification: 1466 Bernard Aboba, Jari Arkko, Steven Bellovin and Miguel A. Monjas 1468 Finally, Pat Calhoun would like to thank Sun Microsystems since most 1469 of the effort put into this document was done while he was in their 1470 employ. 1472 13.0 Authors' Addresses 1474 Questions about this memo can be directed to: 1476 Pat R. Calhoun 1477 Black Storm Networks 1478 250 Cambridge Avenue, Suite 200 1479 Palo Alto, California, 94306 1480 USA 1482 Phone: +1 650-617-2932 1483 Fax: +1 650-786-6445 1484 E-mail: pcalhoun@diameter.org 1486 Stephen Farrell 1487 Baltimore Technologies 1488 39 Parkgate Street, 1489 Dublin 8, 1490 IRELAND 1492 Phone: +353-1-881-6000 1493 Fax: +353-1-881-7000 1494 E-Mail: stephen.farrell@baltimore.ie 1495 William Bulley 1496 Merit Network, Inc. 1497 Building One, Suite 2000 1498 4251 Plymouth Road 1499 Ann Arbor, Michigan, 48105-2785 1500 USA 1502 Phone: +1 734-764-9993 1503 Fax: +1 734-647-5185 1504 E-mail: web@merit.edu 1506 14.0 Full Copyright Statement 1508 Copyright (C) The Internet Society (2001). All Rights Reserved. 1510 This document and translations of it may be copied and furnished 1511 to others, and derivative works that comment on or otherwise 1512 explain it or assist in its implementation may be prepared, copied, 1513 published and distributed, in whole or in part, without restric- 1514 tion of any kind, provided that the above copyright notice and 1515 this paragraph are included on all such copies and derivative 1516 works. However, this docu- ment itself may not be modified in any 1517 way, such as by removing the copyright notice or references to the 1518 Internet Society or other Inter- net organizations, except as needed 1519 for the purpose of developing Internet standards in which case 1520 the procedures for copyrights defined in the Internet Standards pro- 1521 cess must be followed, or as required to translate it into languages 1522 other than English. The limited permis- sions granted above are 1523 perpetual and will not be revoked by the Internet Society or 1524 its successors or assigns. This document and the information con- 1525 tained herein is provided on an "AS IS" basis and THE INTERNET 1526 SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WAR- 1527 RANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WAR- 1528 RANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 1529 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1530 FOR A PARTICULAR PURPOSE." 1532 15.0 Expiration Date 1534 This memo is filed as and 1535 expires in May 2002.