idnits 2.17.1 draft-ietf-aaa-diameter-cms-sec-01.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 29 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 30 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-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1277 has weird spacing: '... copied and ...' == Line 1278 has weird spacing: '...s, and deriv...' == Line 1280 has weird spacing: '...ed, in whole...' == Line 1281 has weird spacing: '...hat the above...' == Line 1282 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 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 (June 2001) is 8350 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 1182, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1219, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1223, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-aaa-diameter-05 -- 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 draft: draft-hiller-cdma2000-aaa (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 (~~), 15 warnings (==), 7 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 Sun Microsystems, Inc. 4 Category: Standards Track Stephen Farrell 5 Baltimore Technologies 6 William Bulley 7 Merit Network, Inc. 8 June 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 and 48 confidentiality is achieved using a mixture of symmetric and 49 asymmetric transforms, by encapsulating Cryptographic Message Syntax 50 (CMS) data within AVPs. CMS is also used to carry X.509 certificates. 52 Table of Contents 54 1.0 Introduction 55 1.1 Establishing Security Relationship through relay agents 56 1.2 Establishing Security Relationship through proxy agents 57 1.3 Using Redirector agents in lieu of DSA 58 1.4 When to use DSAs 59 1.5 Who can authorize users 60 1.6 Requirements language 61 1.7 Advertising application support 62 2.0 AVP Format 63 3.0 Key Management 64 3.1 Usage Scenario 65 3.2 Certificate Requirements 66 3.3 Algorithms 67 3.4 Reuse of CMS Content Encryption Keys 68 4.0 Command-Codes Values 69 4.1 Diameter-Security-Association-Request 70 4.2 Diameter-Security-Association-Answer 71 4.3 Proxy-Diameter-Security-Association-Request 72 4.4 Proxy-Diameter-Security-Association-Answer 73 5.0 Diameter Security Association Message Flow 74 6.0 Diameter Security AVPs 75 6.1 CMS-Signed-Data AVP 76 6.2 CMS-Encrypted-Data AVP 77 6.3 CMS-Cert AVP 78 6.4 Local-CA-Info AVP 79 6.4.1 CA-Name AVP 80 6.4.2 Key-Hash AVP 81 6.5 OCSP-Nonce AVP 82 6.6 AAA-Server-Certs AVP 83 6.7 OCSP-Responses AVP 84 6.8 CA-Chain AVP 85 6.9 Expected-Signed-AVP AVP 86 6.10 Expected-Encrypted-AVP AVP 87 6.11 AVP-Code AVP 88 6.12 OCSP-Request-Flags AVP 89 6.13 DSAR-Target-Domain AVP 90 6.14 DSA-TTL AVP 91 7.0 Result-Code AVP Values 92 7.1 Transient Failures 93 7.2 Permanent Failures 94 8.0 IANA Considerations 95 8.1 Command Codes 96 8.2 AVP Codes 97 8.3 Result-Code AVP Values 98 8.4 Application Identifier 99 8.5 OCSP-Request-Flags AVP Values 100 9.0 Security Considerations 101 10.0 References 102 11.0 Acknowledgements 103 12.0 Authors' Addresses 104 13.0 Full Copyright Statement 105 14.0 Expiration Date 107 1.0 Introduction 109 The Diameter base protocol [1] leverages either IPsec or TLS for 110 integrity and confidentiality between two Diameter peers. However, 111 the Diameter protocol also allows peers to communicate through relay 112 and proxy agents, and in such environments security information is 113 lost at each agent. 115 Relay agents perform message routing, and other than routing AVPs, do 116 not modify Diameter messages. Proxy agents, on the other hand, 117 implement policy enforcement, and actively modify Diameter messages. 118 See [1] for a more comprehensive definition of the role of relay and 119 proxy agents. 121 1.1 Establishing Security Relationship through relay agents 123 The AAA Working Group has defined a set of requirements in [10] to 124 allow for Diameter peers to communicate securely through Relay 125 agents. This requirement calls for AVP integrity and confidentiality 126 between two peers communicating through agents. The term agent is 127 used in this specification for either a relay or a proxy agent. 128 Figure 1 provides an example of two Diameter peers establishing a 129 Diameter Security Association (DSA) through Relay agents. The 130 participants of a DSA are the peers where the DSA setup messages 131 terminate. In this example, the participants of the DSA would the NAS 132 (access device), and the Home Server. 134 mno.net mno.net xyz.net abc.com 135 +------+ <----> +------+ <----> +------+ <----> +------+ 136 | | TLS |Agent | IPSec |Agent | IPSec | Home | 137 | NAS | | | | | | | 138 | | | 1 | | 2 | |Server| 139 +------+ +------+ +------+ +------+ 140 <--------------------------------------------> 141 Diameter Security Association 143 Figure 1: Diameter Security Association 145 When one or more agents are used between two communicating Diameter 146 peers, the use of hop-by-hop security mechanisms (e.g. TLS, IPSec) 147 is unsuitable, since Diameter messages are processed at the 148 application layer at each agent. Therefore, an alternative mechanism 149 is required to protect portions of the message at the application 150 layer. 152 Allowing for a security association to be established through 153 Diameter relays allows the participants of the DSA to detect whether 154 protected AVPs have been modified en-route, and hides sensitive data 155 from intermediate agents. Furthermore, the Mobile IP and NASREQ 156 Working Groups have stated in [7, 8] that non-repudiation of Diameter 157 data, such as Accounting related AVPs, is necessary. 159 Figure 2 provides an example of a message sent by an access device 160 (NAS), through Diameter relay agents, to its intended destination, 161 the home server. In this example, Proxy 2 modifies the contents of 162 the foo AVP, perhaps due to mis-configuration, or maliciously. This 163 specification would allow the participants of the DSA to detect such 164 a problem, as long as the AVP being modified was protected. 166 (Request) (Request) (Request) 167 [AVP(foo)=x] [AVP(foo)=x] [AVP(foo)=y] 168 +------+ -----> +------+ -----> +------+ -----> +------+ 169 | | |Relay | |Proxy | | Home | 170 | NAS | | | | | | | 171 | | | 1 | | 2 | |Server| 172 +------+ <----- +------+ <----- +------+ <----- +------+ 173 (Answer) (Answer) (Answer) 174 [AVP(foo)=b] [AVP(foo)=b] [AVP(foo)=a] 176 Figure 2: Diameter agent modifying AVP 178 This document defines the Diameter commands that are used to 179 establish a DSA through Diameter agents, and specifies how 180 encapsulating CMS objects [3] in Diameter AVPs can provide 181 authentication, integrity and confidentiality. The CMS object MAY 182 also be used to transport X.509 certificates and revocation lists. 184 Establishing a DSA through relay agents requires that the initiator 185 issue a Diameter Security Association Request (DSAR) message. In the 186 example provided in figure 1, NAS would issue the DSAR with the 187 Destination-Realm AVP set to abc.com. The Home Server would process 188 the request, and respond by issuing a Diameter Security Association 189 Answer (DSAA) message. If the DSAA message contains a Result-Code 190 indicating success, the DSA is established between the NAS and the 191 home server. 193 Once the DSA is established, participants with private keys MAY apply 194 digital signatures to protect one or more AVP within a message. In 195 the example provided in Figure 2, the Foo AVP would be protected by 196 the digital signature, and any modification of the AVP by the relay 197 agents, would be detected when the signature validation algorithm 198 would fail by either participant. 200 1.2 Establishing Security Relationship through proxy agents 201 As previously discussed, proxy agents typically modify Diameter 202 messages to implement policy enforcement. An example of a proxy 203 server would be an aggregating server, which typically sits one 204 Diameter hop away from the access device, and enforces policy in 205 order to protect the access device from receiving AVPs that could 206 cause harm (e.g. excessive number of filters, unsupported tunneling 207 protocol). Although in theory such checks could be performed on the 208 access device, these devices are typically embedded systems, and not 209 easily configurable. The proxy agent's behavior, on the other hand, 210 is typically under control of the network operator. 212 Diameter messages between two participants of a DSA would fail 213 verification if a proxy agent were to modify any protected AVPs. 214 Therefore proxy agents either MUST NOT modify protected AVPs or else 215 MUST NOT allow the DSA to be established. When an DSAR is received 216 by a proxy agent, it has two options. First, if MAY simply deny all 217 DSA Setup Requests (DSAR) through it by responding with the DSAA 218 Result-Code AVP set to DIAMETER_NO_CMS_THROUGH_PROXY. The access 219 device can then determine whether it is willing to provide service, 220 based on its local policy. 222 Alternatively, it MAY reject the DSAR, but set the Result-Code AVP to 223 DIAMETER_CAN_ACT_AS_CMS_PROXY, informing the initiator of the DSAR 224 that it is a proxy agent, but is willing to establish the DSA on its 225 behalf. The DSAA MUST be signed by the proxy agent, and include its 226 certificate, to allow the access device to validate the originator of 227 the DSAA. At this point, the access device MUST determine whether the 228 proxy agent is a trusted agent, and whether it is willing to allow 229 the agent to provide such service. For instance, the access device 230 MAY be configured to ONLY accept DSAA with this result code from 231 proxy agents within its own domain. 233 Note that an access device MAY be configured to always issue a PDSR 234 to its aggregating proxy, reducing the number of round trips. 235 Similarly, an aggregating proxy MAY be configured to initiate an DSAR 236 regardless of whether a PDSR was sent by the access device. 238 mno.net mno.net xyz.net abc.com 239 +------+ +------+ +------+ +------+ 240 | | |Proxy | |Relay | | Home | 241 | NAS | | | | | | | 242 | | |Agent | |Agent | |Server| 243 +------+ +------+ +------+ +------+ 244 -------------> 245 (DSAR) Destination-Realm = abc.com 247 <------------- 248 (DSAA) Result-Code = DIAMETER_CAN_ACT_AS_CMS_PROXY 250 -------------> 251 (PDSR) DSAR-Target-Domain = abc.com 253 ----------------------------> 254 (DSAR) Destination-Realm = abc.com 256 <---------------------------- 257 (DSAA) Result-Code = DIAMETER_SUCCESS 259 <------------- 260 (PDSA) Result-Code = DIAMETER_SUCCESS 262 Figure 3: Establishing Security through Proxy Agent 264 Allowing the first hop agent to be used to establish the DSA with the 265 home server MAY reduce the current concerns that the cryptographic 266 operations resulting from this specification MAY overburden embedded 267 access devices. 269 1.3 Using Redirector agents in lieu of DSA 271 When a redirect agent is used, allowing the access device, or first 272 hop relay or proxy agent, to communicate directly with the home 273 server. In such configurations, the hop-by-hop security mechanisms 274 specified in the base protocol MAY be sufficient. 276 However, there are certain business models where signing of select 277 Diameter AVPS (e.g. accounting) MAY be desired when redirectors are 278 used. Figure 4 shows an example where the relay agent contacts the 279 redirect agent to retrieve the necessary information for it to 280 communicate directly with the home server, which MAY include the home 281 server's certificates. 283 The relay agent MAY then initiate a DSA with the home server, using 284 the certificates provided by the redirector. 286 +------+ 287 | | 288 | DRD | 289 | | 290 +------+ 291 ^ | 292 2. Request | | 3. Redirection 293 | | Notification 294 | v 295 +------+ ---------> +------+ <--------> +------+ 296 | | 1. Request | | 4. DSAR/DSAA | | 297 | NAS | | DRL | | HMS | 298 | | 6. Answer | | 5. Request/Answer | | 299 +------+ <--------- +------+ <--------> +------+ 300 mno.net mno.net abc.com 302 Figure 4: DSA Setup following redirect 304 The CMS specification allows for Diameter AVPs to be multiply-signed 305 (see section 6.1), which may prove useful in business models that 306 require both parties to sign accounting data in parallel. This scheme 307 provides some assurance that both parties agreed to the accounting 308 data, which MAY be used for settlement purposes. 310 1.4 When to use DSAs 312 Given that asymmetric transform operations are expensive, access 313 devices and/or Diameter agents MAY wish to restrict establishment of 314 a DSA to cases where the participants belong to a different 315 administrative domain. 317 1.5 Who can authorize users 319 In this specification, we define how a Diameter Security Association 320 is established at the application layer to secure AVPs within a 321 message. However, it is important to note that one of participants 322 of a DSA (specifically the one in the home network) MUST belong to 323 the same realm as the user being authorized. This limitation will 324 prevent bigco.com from authorizing (or rather declining 325 authorization) for users at smallco.com. The realm of the 326 participants is found in the subjectAltName field of the Diameter 327 server's X.509 certificate. 329 [editor's note: This was added as part of the security review, but 330 seems unnecessarily restrictive. Can this section be deleted?] 332 1.6 Requirements language 334 In this document, the key words "MAY", "MUST", "MUST NOT", 335 "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be 336 interpreted as described in [5]. 338 1.7 Advertising application support 340 Diameter nodes conforming to this specification MAY advertise support 341 by including the value of two (2) in the Auth-Application-Id or the 342 Acct-Application-Id AVP of the Capabilities-Exchange-Request and 343 Capabilities-Exchange-Answer command [1]. 345 2.0 AVP Format 347 The Diameter base protocol [1] details the AVP header, which includes 348 the 'P' bit, but does not specify how the 'P' bit is used. The 'P' 349 bit, known as the protected AVP bit, is used to indicate whether the 350 AVP is protected by a digital signature. When set, the AVP is 351 protected and the contents cannot be changed by agents without 352 detection. 354 0 1 2 3 355 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 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | AVP Code | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 |V M P r r r r r| AVP Length | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | Vendor-ID (opt) | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | Data ... 364 +-+-+-+-+-+-+-+-+ 365 Figure 5: Diameter AVP Header 367 All Diameter specifications MUST specify whether the 'P' bit can be 368 set or not, as is done in section 4.5 of [1] and section 6 below. 369 For AVPs that are designed to be changed at each hop (such as the 370 Proxy-Info AVP) Diameter nodes MUST NOT allow the 'P' bit to be set. 372 3.0 Key Management 374 For DSA origin authentication, CMS itself already provides sufficient 375 key management without the need for additional specification. 376 Basically, the originating Diameter node signs and includes whatever 377 certificates are necessary for validation of the digital signature. 379 However, for encryption of AVPs more work is needed. In order to be 380 able to encrypt AVPs for a recipient, the originating Diameter node 381 must have a copy of the recipient's public key. There are many well- 382 known key retrieval schemes (e.g. using LDAP [6]), however, in order 383 to simplify Diameter implementations a specific Diameter key 384 distribution mechanism is defined here. 386 Another issue that must be addressed is how a Diameter node is to 387 "know" that certain AVPs are required to be secured within CMS 388 objects. This is communicated in the Diameter Security Association 389 Request/Answer messages, listed in section 4.0. 391 This section describes how Diameter node names are encoded in 392 certificates. 394 3.1 Usage Scenario 396 When a Diameter node is about to send a message, it must determine 397 whether a DSA should be established or not. We assume the Diameter 398 node knows the user's realm, perhaps through the User-Name AVP. 400 Implementations MAY cache the information required to establish a 401 DSA, but MUST honor time-to-live settings and MUST re-validate 402 certificates (possibly including revocation checks) before using 403 cached data. 405 We use Diameter Security Association Request (DSAR) and Diameter 406 Security Association Answer (DSAA) messages to establish a DSA, which 407 specifies which AVPs should be authenticated and/or encrypted, as 408 well as which public key(s) to use. 410 The originating node sends the DSAR message to a server in the 411 destination realm. The DSAR message contains: 413 - TTL for this DSA (seconds) 414 - the realm part of the user's NAI 415 - the list of direct trust CA's that the originating Diameter 416 node has configured into it for certificate validation. A 417 "direct trust" CA is one that the node is willing to use as the 418 "top" of a certificate chain, sometimes confusingly known as a 419 "root CA." 420 - a list of AVPs that expected to be protected (and how) for this 421 realm 422 - (optionally) a flag indicating that the originating Diameter 423 node wishes to receive certificate status information (using 424 OCSP messages) in which case a nonce to be used by the 425 destination Diameter node in OCSP requests MAY also be 426 supplied. See [9] for details of the certificate status 427 protocol and messages. 429 The destination node returns the DSAA message which contains: 431 - TTL for this SA (seconds) 432 - a chain of CA certificates (possibly empty) 433 - public key certificates for the Diameter servers in the realm, 434 all of which MUST validate up to one of the CA's contained in 435 the DSAR message, via the chain of CA certificates above; 436 - a list of AVPs that expected to be protected (and how) for this 437 realm 438 - (optionally, if nonce received and OCSP supported) a list of 439 OCSP responses for the certificates in question, each of which 440 contains the nonce from the DSAR message 442 The originating Diameter node now has to check the response. Any 443 failure results in error messages and auditing and not sending the 444 Diameter message. 446 Checks: 448 - the certificate chain selected is cryptographically correct, 449 passes the (relevant parts of the) rfc2459 path validation 450 algorithm and terminates at a CA mentioned in the DSAR message 451 - the realm part of the user's NAI must occur as a subjectAltName 452 (with the dNSName option) in the AAA server's certificate. This 453 dNSName MUST be of the form "Diameter-." where 454 is the FQDN's domain component and can be 455 anything (e.g. "Diameter-1.baltimore.com", "Diameter- 456 west.sun.com") chosen by the Diameter server administrator. 457 - the DSAA message MUST be digitally signed and the signature 458 MUST be validated and the signer's certificate chain MUST 459 terminate as a CA mentioned in the DSAR message 460 - The expiration of the TTL MUST be less or equal to the earliest 461 expiration of all certificates in the message, encoded in the 462 notAfter field. 464 If certificate status (revocation) is an issue for the Diameter node, 465 then the DSAR message MAY contain a nonce value. The idea is that the 466 sender of the DSAA makes OCSP requests on behalf of the Diameter node 467 and returns the OCSP responses to the Diameter node as part of the 468 DSAR message. The use of the nonce value ensures that the sender of 469 the DSAA cannot return cached or otherwise fake OCSP responses to the 470 Diameter node. 472 The nonce value is to be (the beginning of) the nonce in the OCSP 473 response. The reason for this is that the responder MAY add 474 additional bits to the nonce, but the nonce provided in the OSCP- 475 Nonce MUST be present at the beginning of the nonce of the OSCP 476 response. 478 The DSAR MAY be signed. If the originating node has a private key and 479 protection expectations for AVPs are specified, then the DSAR SHOULD 480 be signed. 482 The DSAA MUST be signed by a Diameter agent or server within the 483 user's realm, to prevent an intermediate node from modifying the 484 protection expectations for AVPs. 486 If confidentiality or digital signature is required, then the 487 originating node prepares the CMS related AVPs as required. 489 If certificate revocation is enabled, anytime a certificate is used 490 from the local certicate cache, a revocation check MUST be performed. 492 3.2 Certificate Requirements 494 Certificates used for the purposes of Diameter MUST conform to the 495 PKIX profile [4], and MUST also include a Diameter node's FQDN, which 496 is typically added in the Host-Name AVP [1], as one of the values of 497 the subjectAltName extension of the Certificate. The FQDN is to be 498 encoded as a dNSName within the subjectAltName. 500 For Diameter nodes (capable of acting as recipients for 501 confidentiality), the FQDN MUST be of the form "Diameter- 502 .". Other Diameter nodes MAY use this naming scheme. Note 503 that this naming constraint is for PKI purposes only, and in no way 504 restricts a Diameter's host name. 506 The naming scheme presented here is intended to: 507 - make it simple to use existing certification authorities (CAs) 508 for Diamater CMS 509 - allow CAs to ensure that only "proper" Diameter certificiates 510 are accepted by Diameter nodes 511 - allow Diameter certfificates to be used for other purposes 512 where that meets a CA's practices. 514 These names are used for two purposes: 516 1. Where a Diameter node is verifying a signature it needs to be 517 able to compare the identity of the signer against the identity 518 in the Host-Name AVP. 520 2. Where a Diameter node is encrypting AVPs, it needs to be able 521 to ensure that it uses a public key for the intended recipient. 522 This requires comparing the identity in a Certificate against 523 the FQDN of the intended recipient (which is assumed to be 524 known). 526 In either case, the presence of the required FQDN as a dNSName value 527 in the subjectAltName extension of a verified public key certificate 528 satisfies the matching requirement. 530 Note that there MAY also be other values in the subjectAltName 531 extension, (either using dNSName or other elements of the CHOICE), 532 these can be safely ignored, but implementations MUST be able to 533 handle their presence. 535 Note also that the PKIX profile [4], section 4.1.2.6, specifies the 536 rules for the relationship between the subjectAltName extension and 537 the subject field of public key certificates. 539 Note that once operational experience has been gained, a future 540 document may specify a restricted profile of [4] in order to simplify 541 implementation. 543 3.3 Algorithms 545 For all uses of CMS in this specification the mandatory to implement 546 algorithms are as follows: 548 - Asymmetric: RSA 549 - Hashing: SHA-1 550 - Signature: RSAwithSHA1 551 - Symmetric Encryption: 3DES 553 At some point in future, AES will replace 3DES. 555 3.4 Reuse of CMS Content Encryption Keys 557 Once a CMS-Encrypted-Data AVP has been exchanged between two Diameter 558 peers, then they share a symmetric cryptographic key (the content 559 encryption key) which can be used to encrypt further Diameter AVPs 560 between the peers by using the scheme specified in [15]. The peers 561 MUST first take part in an DSAR/DSAA exchange in order to distribute 562 the required asymmetric keys. 564 Note that the use of symmetric keys does not provide "non- 565 repudiation". 567 [15] leaves open some issues, namely how to handle loss of a shared 568 secret (say following a peer re-boot) and for how long to continue to 569 use a shared secret (the maximum number of decryptions required). 571 Where a Diameter node receives a CMS-Encrypted-Data AVP, but doesn't 572 have the required shared secret, that node should return the 573 DIAMETER_KEY_UNKNOWN error message. The peer may then use the 574 DSAR/DSAA exchange to rebuild their Diameter security association. 576 In [15], the default value for the maximum number of decryptions 577 allowed (CEKMaxDecrypts) when re-using a content encryption key is 1. 578 In general this default SHOULD be used, but if a Diameter node 579 "knows" that more than one CMS-Encrypted-Data AVP will be exchanged 580 between the nodes (based on the Expected-Encrypted-AVP settings 581 exchanged during the DSAR/DSAA exchange) then the CEKMaxDecrypts 582 setting MAY be set higher. Diameter nodes MUST be able to support a 583 maxDecrypts setting of 1000. 585 4.0 Command-Codes Values 587 This section defines new Command-Code [1] values that MUST be 588 supported by all Diameter implementations that conform to this 589 specification. The following Command Codes are currently defined in 590 this document: 592 Command-Name Abbrev. Code Reference 593 -------------------------------------------------------- 594 Diameter-Security- DSAR 304 4.1 595 Association-Request 596 Diameter-Security- DSAA 304 4.2 597 Association-Answer 598 Proxy-Diameter-Security- PDSR 305 4.3 599 Association-Request 600 Proxy-Diameter-Security- PDSA 305 4.4 601 Association-Answer 603 4.1 Diameter-Security-Association-Request 605 The Diameter-Security-Association-Request command, indicated by the 606 Command-Code field set to 304 and the 'R' bit set in the message 607 flags field, is sent by a Diameter node to establish a Diameter 608 Security Association. 610 Message Format 611 ::= < Diameter-Header: 304, REQ, PXY > 612 { Origin-Host } 613 { Origin-Realm } 614 { Destination-Realm } 615 + { Local-CA-info } 616 { Auth-Application-Id } 617 { OCSP-Request-Flags } 618 { DSA-TTL } 619 [ Destination-Host ] 620 * [ Expected-Signed-AVP ] 621 * [ Expected-Encrypted-AVP ] 622 [ OCSP-Nonce ] 623 0*1[ CMS-Signed-Data ] 624 [ Origin-State-Id ] 625 * [ AVP ] 626 * [ Proxy-Info ] 627 * [ Route-Record ] 629 4.2 Diameter-Security-Association-Answer 631 The Diameter-Security-Association-Answer command, indicated by the 632 Command-Code field set to 304, with the 'R' bit in the Command Flags 633 cleared, in response to a DSAR. 635 Message Format 637 ::= < Diameter-Header: 304, PXY > 638 { Origin-Host } 639 { Origin-Realm } 640 0*1{ CA-Chain } 641 + { AAA-Server-Certs } 642 * { OCSP-Responses } 643 { Destination-Host } 644 { Auth-Application-Id } 645 { DSA-TTL } 646 * [ Expected-Signed-AVP ] 647 * [ Expected-Encrypted-AVP ] 648 [ CMS-Signed-Data ] 649 [ Origin-State-Id ] 650 * [ AVP ] 651 * [ Proxy-Info ] 652 * [ Route-Record ] 654 4.3 Proxy-Diameter-Security-Assocation-Request 656 The Proxy-Diameter-Security-Association-Request command, indicated by 657 the Command-Code field set to 305 and the 'R' bit set in the Command 658 Flags field, is sent by a Diameter node to request that a downstream 659 proxy establishes an Security Association with a server in a given 660 domain on its behalf. 662 Message Format 664 ::= < Diameter-Header: 305, REQ, PXY > 665 { Origin-Host } 666 { Origin-Realm } 667 { Destination-Realm } 668 { Auth-Application-Id } 669 { DSAR-Target-Domain } 670 [ Origin-State-Id ] 671 * [ AVP ] 672 * [ Proxy-Info ] 673 * [ Route-Record ] 675 4.4 Proxy-Diameter-Security-Association-Answer 677 The Proxy-Diameter-Security-Association-Answer command, indicated by 678 the Command-Code field set to 305 and the 'R' bit cleared in the 679 Command Flags field, is sent by a Diameter node in response to an 680 PDSR message. 682 Message Format 684 ::= < Diameter-Header: 305, PXY > 685 { Origin-Host } 686 { Origin-Realm } 687 { Destination-Host } 688 { Auth-Application-Id } 689 [ Origin-State-Id ] 690 * [ AVP ] 691 * [ Proxy-Info ] 692 * [ Route-Record ] 694 5.0 Diameter Security Association Message Flow 696 This section contains an example of a NAS in domain xyz.com, 697 communicating with its local relay agent, which in turn communicates 698 with a server in ABC.COM's network. In the following example, once 699 the initial capabilities exchange is complete, the NAS receives a 700 request for access from alice@abc.com, which causes the DSA setup to 701 be initiated, followed by the application-specific authentication 702 request. 704 Although the example doesn't specifically use bi-directional CMS 705 authentication and encryption, this feature is supported. 707 +-------+ +-------+ +---------+ 708 | NAS | | Relay | | abc.com | 709 | | | Agent | |Home Srv | 710 +-------+ +-------+ +---------+ 711 | | | 712 |CER apps 1, 2 | | 713 (a) |------------------->| | 714 |CAA apps -1 | | 715 (b) |<-------------------| | 716 | . |CER apps 1, 2 | 717 (c) | |<-------------------| 718 | |CEA apps -1 | 719 (d) | |------------------->| 720 ->| User alice@abc.com | | 721 (e) | Requests Access | | 722 | | | 723 | DSAR | | 724 | Dest-Realm=abc.com | | 725 | CMS-Cert | | 726 (f) |--------------------+------------------->| 727 | | DSAA | 728 | | Origin-Host=foo | 729 | | CMS-Cert | 730 (g) |<-------------------+--------------------| 731 | Auth-Request + | | 732 | CMS-Signed-Data | | 733 | Dest-Host=foo | | 734 (h) |--------------------+------------------->| 735 | | Auth-Answer + | 736 | | CMS-Encrypted-Data | 737 (i) |<-------------------+--------------------| 738 Figure 6: Example of a DSA Setup 740 (a) NAS sends a CER message to its relay agent indicating that it 741 supports applications 1 (NASREQ) and 2 (CMS Security). 743 (b) The proxy server sends a CEA message to the NAS indicating 744 that it is a relay supporting all Diameter applications. 746 (c) ABC.COM's Home Server sends a CER message to a proxy server 747 indicating that it supports applications 1 (NASREQ) and 2 (CMS 748 Security). 750 (d) The proxy server sends a CEA message to ABC.COM's Home Server 751 indicating that it is a relay supporting all Diameter 752 applications. 754 (e) The NAS receives a request for access from a user 755 (alice@abc.com). 757 (f) The NAS issues an DSAR message, with the Destination-Realm AVP 758 set to abc.com, and its certificate in the CMS-Cert AVP. The 759 DSAR includes the set of AVPs that the NAS expects to be 760 encrypted, in the event that the home server returns messages 761 that contain these AVPs. 763 (g) ABC.COM's Home Server processes the DSAR message, and replies 764 with the DSAA message. The DSAA also includes the set of AVPs 765 that the home server is expecting to be authenticated, as well 766 as its certificate in the CMS-Cert AVP. 768 (h) The NAS issues an authentication request with the 769 Destination-Host AVP set to the value of the Origin-Host AVP 770 in the DSAA. The message includes the CMS-Signed-AVP, which 771 authenticates the AVPs that were requested by the Home Server 772 in the DSAA. 774 (i) The Home Server successfully authenticates the user, and 775 returns a reply, which includes the CMS-Encrypted-Data AVP, 776 whose contents include the AVPs that were specified by the NAS 777 in the DSAR. 779 6.0 CMS Security AVPs 781 This section contains AVPs that are used to establish a Diameter 782 Security Association, and to transport CMS objects. 784 +---------------------+ 785 | AVP Flag rules | 786 |----+-----+----+-----|----+ 787 AVP Section | | |SHLD| MUST|MAY | 788 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 789 -----------------------------------------|----+-----+----+-----|----| 790 AAA-Server-Certs 351 6.6 OctetString| M | P | | V | N | 791 AVP-Code 352 6.11 Unsigned32 | M | P | | V | N | 792 CA-Chain 353 6.8 OctetString| M | P | | V | N | 793 CA-Name 349 6.4.1 OctetString| M | P | | V | N | 794 CMS-Cert 354 6.3 OctetString| M | | | P,V | N | 795 CMS-Encrypted- 355 6.2 OctetString| M | P | | V | N | 796 Data | | | | | | 797 CMS-Signed-Data 310 6.1 OctetString| M | | | P,V | N | 798 DSA-TTL 362 6.14 Unsigned32 | M | P | | P,V | N | 799 DSAR-Target- 360 6.13 OctetString| M | P | | V | N | 800 Domain | | | | | | 801 Expected-Signed- 356 6.9 Grouped |M,P | | | V | N | 802 AVP | | | | | | 803 Expected- 357 6.10 Grouped |M,P | | | V | N | 804 Encrypted-AVP | | | | | | 805 Key-Hash 350 6.4.2 OctetString| M | P | | V | N | 806 Local-CA-Info 348 6.4 Grouped | M | P | | V | N | 807 OCSP-Nonce 358 6.5 OctetString| M | P | | V | N | 808 OCSP-Request- 361 6.12 Unsigned32 | M | P | | V | N | 809 Flags | | | | | | 810 OCSP-Responses 359 6.7 OctetString| M | P | | V | N | 812 6.1 CMS-Signed-Data AVP 814 The CMS-Signed-Data AVP (AVP Code 310) is of type OctetString and 815 contains the Basic Encoding Rules (BER) encoding of a CMS object [3] 816 of type ContentInfo. The profile of CMS algorithm and structure usage 817 is as specified in the S/MIME v3 message specification [11]. This 818 means that where a set of AVPs is protected using CMS, the set MUST 819 first be encoded according to MIME encoding rules specified below. 820 This method of encapsulating AVPs allows existing S/MIME toolkits to 821 be used without changes in order to provide authentication within the 822 Diameter application layer. 824 To package a set of AVPs as a MIME type, AVPs with the 'P' bit are 825 first concatenated in the order in which they occur in the Diameter 826 message, including padding. The result is used as input into the 827 signing process. Note that the AVPs themselves are not encapsulated 828 within the CMS-Signed-Data AVP. Instead, the digest value within the 829 SignedData structure contains the digest produced in the signature 830 process. 832 Multiple Diameter entities MAY add their signatures to an existing 833 CMS-Signed-Data AVP using the countersignature attribute, defined in 834 section 11.4 of [3]. The countersignature attribute requires that the 835 signatures occur sequentially, meaning that each signature covers the 836 existing signatures in the CMS object. 838 The initial signature, and any additional countersignatures, MUST 839 cover the exact same set of AVPs, in the order they are present in 840 the message. 842 Note that the CMS-Signed-Data AVP MUST NOT be used in the generation 843 of the signature, and therefore MUST NOT have its 'P' bit set. 845 If a receiver detects that the contents of the CMS-Signed-Data AVP 846 are invalid, it SHOULD return the new Result-Code AVP value defined 847 in section 7.0. 849 When AVPs are to be both encrypted and signed, the CMS-Encrypted-Data 850 AVP MUST be created first. The resulting CMS object MUST then be MIME 851 encoded producing an application/pkcs7-mime MIME type which is then 852 used as the content of the EnvelopedData. This means that signing is 853 "outside" encryption. 855 The eContent field of the EncapsulatedContentInfo structure MUST be 856 absent since the authentication covers data outside of the object. 857 The signature is computed over all AVPs with the 'P' bit enabled. The 858 order of the AVPs MUST be preserved and the computation begins with 859 the first AVP immediately following the Diameter header. If the 860 signature cannot be verified correctly, a response with the Result- 861 Code AVP set to DIAMETER_INVALID_AUTH [1] MUST be returned. 863 No more than one CMS-Signed-Data AVP MUST be present in any given 864 Diameter message. 866 6.2 CMS-Encrypted-Data AVP 868 The CMS-Encrypted-Data AVP (AVP Code 355) is of type OctetString and 869 contains the Basic Encoding Rules (BER) encoding of a CMS object [3] 870 of type ContentInfo. 872 The entire AVP MUST be input to the encryption process, in network 873 byte order, including any padding. All AVPs to be encrypted are 874 concatenated, and the encryptor is free to order AVPs in whatever way 875 it chooses. The value is then encrypted and used as the value of the 876 EncryptedContent field within CMSEnvelopedData. 878 If a receiver detects that the contents of the CMS-Data AVP is 879 invalid, it SHOULD return the new Result-Code AVP value defined in 880 section 7.0. 882 When AVPs are to be both encrypted and authenticated, the CMS- 883 Encrypted-Data AVP MUST be created first. 885 Where AVPs are encapsulated within a CMS-Encrypted-Data AVP, the 886 eContentType of the EncapsulatedContentInfo MUST be id-data [11]. 888 CMS-Encrypted-Data MAY contain more than one CMS object, that is, 889 implementations MUST be able to add a new CMS-Encrypted-Data AVP 890 value and also MUST be able to decrypt all CMS-Encrypted-Data AVP 891 values which are encrypted for them. 893 When a conforming implementation receives a Diameter message which 894 contains encrypted AVPs within a CMS EnvelopedData, the recipient 895 MUST check to see if it is on the list of recipients specified in the 896 RecipientInfos of the EnvelopedData. If not, the recipient MAY choose 897 to process the message or indicate an error. If the recipient is in 898 the RecipientInfos and an error occurs during decryption, then the 899 recipient MUST indicate an error. 901 Diameter nodes SHOULD implement content encryption key re-use (see 902 section 3.4 above). 904 Zero or more CMS-Encrypted-Data AVP MAY be present in any Diameter 905 message. 907 6.3 CMS-Cert AVP 909 The CMS-Cert AVP (AVP Code 354) is of type OctetString and contains a 910 "certs-only" CMS structure which is a degenerate form of CMS 911 structure containing only PKI related information (see section 3.6 of 912 [11] for details of the CMS certs-only structure). 914 The CMS-Cert AVP contains one or more public key certificates 915 (Certificate) and MAY optionally contains attribute certificates 916 (AttributeCertificate) as allowed by CMS. Other legacy formats 917 supported by CMS MUST NOT be used. 919 Support for use of the Certificate structure is REQUIRED, while 920 implementations MAY support use of the AttributeCertificate structure 921 as defined in the PKIX attribute certificate profile [12]. The latter 922 allows Diameter implementations to include a certificate from a 923 trusted party that they are authorized to emit the AVPs contained in 924 the message. 926 This use of the CMS-Cert AVP can be used to "push" public key and 927 attribute certificates and CRLs using Diameter, which MAY be useful 928 in environments where repositories (e.g. LDAP servers) are either 929 not used or not available (e.g. due to crossing a domain boundary). 930 Conforming implementations MUST be able to emit a certs-only CMS 931 structure which contains relevant PKI related information and MUST be 932 able to process a CMS-Cert AVP which contains a certs-only CMS 933 structure. Of course, the recipient of such a certs-only CMS 934 structure SHOULD NOT use the PKI related information without first 935 verifying it, e.g. by checking that issuer's are trusted, signatures 936 verify etc. 938 A CRL [4] MAY also be provided in the crls field of the SignedData, 939 which MAY be used to assist in determining whether a certificate has 940 been revoked. Optionally, the Diameter node MAY check the status of 941 certificates using another mechanism, such as Online Certificate 942 Status Protocol (OCSP) [9]. 944 6.4 Local-CA-Info AVP 946 The Local-CA-Info AVP (AVP Code 348) is of type Grouped. The Grouped 947 Data field has the following ABNF grammar: 949 Local-CA-Info ::= < AVP Header: 348 > 950 { CA-Name } 951 { Key-Hash } 953 6.4.1 CA-Name AVP 955 The CA-Name AVP (AVP Code 349) is of type UTF8String. The AVP 956 contains the DN (in LDAP string syntax) of the Certificate Authority, 957 e.g. "CN=CA;O=Baltimore Technologies;C=IE". 959 6.4.2 Key-Hash AVP 961 The Key-Hash AVP (AVP Code 350) is of type OctetString, and contains 962 a SHA-1 hash of the key. 964 The hash MUST be calculated over the representation of the CA public 965 key which would be present in an X.509 public key certificate, 966 specifically, the input for the hash algorithm MUST be the DER 967 encoding of a SubjectPublicKeyInfo representation of the key. Note: 968 This includes the AlgorithmIdentifier as well as the BIT STRING. The 969 rules given in [4] for encoding keys MUST be followed. 971 Since this AVP is used for indexing and not for security (since 972 Diameter nodes SHOULD validate certificates), there is no need to 973 support more than one hash algorithm here. 975 6.5 OCSP-Nonce AVP 977 The OCSP-Nonce AVP (AVP Code 358) is of type OctetString, and 978 contains a random value (RECOMMENDED 128 bits) generated by the 979 Diameter node. 981 6.6 AAA-Server-Certs AVP 983 The AAA-Server-Certs AVP (AVP Code 351) is of type OctetString and 984 contains the certificates of the AAA Servers in the home domain. 985 Note: this AVP contains no CA certificates, just those for AAA 986 servers. Certificates MUST follow the naming conventions described in 987 section 3.2. 989 6.7 OCSP-Responses AVP 991 The OCSP-Responses AVP (AVP Code 359) is of type OctetString, and 992 contains an OCSP response message from an OCSP responder. If the 993 OCSP-Request-Flags AVP indicating a response was required in the 994 corresponding request message, the OCSP-Response AVP MUST be present. 995 Furthermore, the OCSP-Request-Flags AVP MAY request a fresh OCSP 996 response message, which MUST also include the OCSP-Nonce AVP. 998 6.8 CA-Chain AVP 1000 The CA-Chain AVP (AVP Code 353) is of type OctetString, and contains 1001 a certificate chain, from one of the nominated locally trusted CAs 1002 down to the (one and only) CA which has issued the end entity 1003 certificates in the AAA-Server-Certs AVP. 1005 To produce this AVP in an DSAA message, one (and only one) of the 1006 Local-CA-info values from the corresponding DSAR message is selected 1007 (call this the "top" CA for the purposes of this description). This 1008 AVP then contains a certificate path (in order) from the "top" CA 1009 down to the (one and only) CA which has issued all the end entity 1010 certificates in the AAA-Servers-AVP. The (typically self-signed), 1011 certificate of the "top" CA MUST NOT be included. 1013 6.9 Expected-Signed-AVP AVP 1014 The Expected-Signed-AVP AVP (AVP Code 356) is of type Grouped. The 1015 Grouped Data field has the following ABNF grammar: 1017 Expected-Signed-AVP ::= < AVP Header: 356 > 1018 { AVP-Code } 1019 [ Vendor-Id ] 1021 The Expected-Signed-AVP AVP contains an AVP code, which if sent by 1022 the peer, MUST be authenticated via the CMS-Signed-Data AVP. 1023 Vendor-Specific AVPs are represented by including the optional 1024 Vendor-Id AVP. 1026 If this AVP is present in the DSAR or DSAA, it MUST be authenticated 1027 using the CMS-Signed-Data AVP. 1029 6.10 Expected-Encrypted-AVP AVP 1031 The Expected-Encrypted-AVP AVP (AVP Code 357) is of type Grouped. 1032 The Grouped Data field has the following ABNF grammar: 1034 Expected-Encrypted-AVP ::= < AVP Header: 357 > 1035 { AVP-Code } 1036 [ Vendor-Id ] 1038 The Expected-Encrypted-AVP AVP contains an AVP code, which if sent by 1039 the peer, MUST be encrypted in the CMS-Encrypted-Data AVP. Vendor- 1040 Specific AVPs are represented by including the optional Vendor-Id 1041 AVP. 1043 If this AVP is present in the DSAR or DSAA, it MUST be authenticated 1044 using the CMS-Signed-Data AVP. 1046 6.11 AVP-Code AVP 1048 The AVP-Code AVP (AVP Code 352) is of type Unsigned32, and contains 1049 the AVP Code of the AVP that is to be authenticated or encrypted. 1051 6.12 OCSP-Request-Flags AVP 1053 The OCSP-Request-Flags AVP (AVP Code 361) is of type Enumerated, and 1054 specifies whether the sender wishes to receive an OCSP response. The 1055 following values are defined: 1057 NO_OCSP_RESPONSE 0 1058 The sender does not wish to receive an OCSP Response. 1060 OCSP_RESPONSE 1 1061 The sender wishes to receive an OCSP Response, and is willing 1062 to accept a stale response. 1064 OCSP_FRESH_RESPONSE 2 1065 The sender wishes to receive a fresh OCSP Response. When this 1066 value is set, the OCSP-Nonce AVP MUST be present. 1068 6.13 DSAR-Target-Domain AVP 1070 The DSAR-Target-Domain AVP (AVP Code 360) is of type UTF8String, and 1071 contains the Destination-Realm of the resulting DSAR sent by a non- 1072 transparent proxy. 1074 6.14 DSA-TTL AVP 1076 The DSA-TTL AVP (AVP Code 362) is of type Unsigned32, and contains 1077 the time to live (in seconds) of the Diameter Security Association. 1078 The expiration time (now+TTL) MUST NOT be greater than the earliest 1079 expiration time (NotAfter field) of all certificates included in this 1080 message accompanying this AVP. The DSA-TTL AVP in the DSAA MUST NOT 1081 be greater than the DSA-TTL AVP in the DSAR. 1083 7.0 Result-Code AVP Values 1085 This section defines new Result-Code [1] values that MUST be 1086 supported by all Diameter implementations that conform to this 1087 specification. 1089 7.1 Transient Failures 1091 Errors that fall within the transient failures category are used to 1092 inform a peer that the request could not be satisfied at the time it 1093 was received, but MAY be able to satisfy the request in the future. 1095 DIAMETER_KEY_UNKNOWN 4008 1096 This error code is returned when a CMS-Signed-Data or CMS- 1097 Encrypted-Data AVP is received that was generated using a key 1098 that is not locally recognized. This error could be caused if 1099 one of the participants of a DSA lost a previously agreed upon 1100 key, perhaps as a result of a reboot. 1102 7.2 Permanent Failures 1103 Errors that fall within the permanent failures category are used to 1104 inform the peer that the request failed, and should not be attempted 1105 again. 1107 DIAMETER_INVALID_CMS_DATA 5019 1108 This error code is returned when a CMS-Data AVP is received 1109 with an invalid ContentInfo object. 1111 DIAMETER_NO_CMS_THROUGH_PROXY 5020 1112 This error code is returned when a non-transparent proxy 1113 receives an DSAR message to state that it doesn't allow a DSA 1114 through it since it plans to modify AVPs. 1116 DIAMETER_CAN_ACT_AS_CMS_PROXY 5021 1117 This error code is returned when a non-transparent proxy 1118 receives an DSAR message, and although it doesn't allow a DSA 1119 through it, it is willing to initiate a DSA on behalf of the 1120 access device. 1122 8.0 IANA Considerations 1124 This section contains the namespaces that have either been created in 1125 this specification, or the values assigned to existing namespaces 1126 managed by IANA. 1128 8.1 Command Codes 1130 This specification assigns the value 304 and 305 from the Command 1131 Code namespace defined in [1]. See section 4.0 for the assignment of 1132 the namespace in this specification. 1134 8.2 AVP Codes 1136 This specification assigns the values 348-361 from the AVP Code 1137 namespace defined in [1]. See section 6.0 for the assignment of the 1138 namespace in this specification. 1140 8.3 Result-Code AVP Values 1142 This specification assigns the values 4008, 5019-5021 from the 1143 Result-Code AVP (AVP Code 268) value namespace defined in [1]. See 1144 section 7.0 for the assignment of the namespace in this 1145 specification. 1147 8.4 Application Identifier 1149 This specification assigns the value two (2) to the Application 1150 Identifier namespace defined in [1]. See section 1.6 for more 1151 information. 1153 8.5 OCSP-Request-Flags AVP Values 1155 As defined in Section 6.12, the OCSP-Request-Flags AVP (AVP Code 361) 1156 defines the values 0-2. All remaining values are available for 1157 assignment via IETF Consensus [12]. 1159 9.0 Security Considerations 1161 This document describes how CMS security can be achieved in the 1162 Diameter protocol by allowing S/MIME Cryptographic Message Syntax [3] 1163 objects to be carried as a Diameter AVP. 1165 This specification does not mandate certificate revocation, however 1166 not verifying whether a given certificate has been revoked has 1167 serious implications, and MAY create a security hole. 1169 The PDSR and PDSA messages (sections 4.3 and 4.4) allow a third party 1170 proxy to establish a Diameter security association with a Diameter 1171 server in a target realm. An access device MUST ensure that the 1172 server establishing the SA on its behalf is a trusted entity, since 1173 the proxy in question could modify Diameter messages, which would be 1174 very difficult to trace. 1176 10.0 References 1178 [1] P. Calhoun, H. Akhtar, J. Arkko, E. Guttman, A. Rubens, "Diame- 1179 ter Base Protocol", draft-ietf-aaa-diameter-05.txt, IETF work in 1180 progress, June 2001. 1182 [2] Kaufman, Perlman, Speciner, "Network Security: Private Communi- 1183 cations in a Public World", Prentice Hall, March 1995, ISBN 0- 1184 13-061466-1. 1186 [3] R. Housley, "Cryptographic Message Syntax", RFC 2630, June 1999. 1188 [4] Housley, Ford, Polk, Solo, "Internet X.509 Public Key Infras- 1189 tructure Certificate and CRL Profile", RFC 2459, January 1999. 1191 [5] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1192 Levels", BCP 14, RFC 2119, March 1997. 1194 [6] Boyen, Howes, Richard, "Internet X.509 Public Key Infrastructure 1195 Operational Protocols - LDAPv2", RFC 2559, April 1999. 1197 [7] T. Hiller et al., "Cdma2000 Wireless Data Requirements for AAA", 1198 draft-hiller-cdma2000-aaa-02.txt, IETF work in progress, Sep- 1199 tember 2000. 1201 [8] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, 1202 Authorization, and Accounting Requirements". RFC 2977. October 1203 2000. 1205 [9] Myers, Ankney, Malpani, Galperin, Adams, "X.509 Internet Public 1206 Key Infrastructure Online Certificate Status Protocol (OCSP)", 1207 RFC 2560, June 1999. 1209 [10] Aboba et al., "Criteria for Evaluating AAA Protocols for Network 1210 Access", RFC 2989, November 2000. 1212 [11] B. Ramsdell, "S/MIME v2 Message Specification", RFC2633, June 1213 1999. 1215 [12] S. Farrell, R. Housley, "An Internet Attribute Certificate Pro- 1216 file for Authorization", draft-ietf-pkix-ac509prof-09.txt, IETF 1217 work in progress, June 2001. 1219 [13] P. Calhoun, W. Bulley, G. Zorn, "Diameter NASREQ Application", 1220 draft-ietf-aaa-Diameter-nasreq-05.txt, IETF work in progress, 1221 June 2001. 1223 [14] P. Calhoun, C. Perkins, "Diameter Mobile IP Application", 1224 draft-ietf-aaa-Diameter-mobileip-05.txt, IETF work in progress, 1225 June 2001. 1227 [15] Farrell, Turner, "Reuse of CMS Content Encryption Keys", draft- 1228 ietf-smime-rcek-04.txt, IETF work in progress, May 2001. 1230 11.0 Acknowledgements 1232 The authors would also like to acknowledge the following people for 1233 their contribution in the development of this specification: 1235 Bernard Aboba, Jari Arkko and Steven Bellovin 1237 12.0 Authors' Addresses 1239 Questions about this memo can be directed to: 1241 Pat R. Calhoun 1242 Network and Security Research Center, Sun Labs 1243 Sun Microsystems, Inc. 1244 15 Network Circle 1245 Menlo Park, California, 94025 1246 USA 1248 Phone: +1 650-786-7733 1249 Fax: +1 650-786-6445 1250 E-mail: pcalhoun@eng.sun.com 1252 Stephen Farrell 1253 Baltimore Technologies 1254 39 Parkgate Street, 1255 Dublin 8, 1256 IRELAND 1258 Phone: +353-1-881-6000 1259 Fax: +353-1-881-7000 1260 E-Mail: stephen.farrell@baltimore.ie 1262 William Bulley 1263 Merit Network, Inc. 1264 Building One, Suite 2000 1265 4251 Plymouth Road 1266 Ann Arbor, Michigan, 48105-2785 1267 USA 1269 Phone: +1 734-764-9993 1270 Fax: +1 734-647-5185 1271 E-mail: web@merit.edu 1273 13.0 Full Copyright Statement 1275 Copyright (C) The Internet Society (2001). All Rights Reserved. 1277 This document and translations of it may be copied and furnished 1278 to others, and derivative works that comment on or otherwise 1279 explain it or assist in its implementation may be prepared, copied, 1280 published and distributed, in whole or in part, without restric- 1281 tion of any kind, provided that the above copyright notice and 1282 this paragraph are included on all such copies and derivative 1283 works. However, this docu- ment itself may not be modified in any 1284 way, such as by removing the copyright notice or references to the 1285 Internet Society or other Inter- net organizations, except as needed 1286 for the purpose of developing Internet standards in which case 1287 the procedures for copyrights defined in the Internet Standards pro- 1288 cess must be followed, or as required to translate it into languages 1289 other than English. The limited permis- sions granted above are 1290 perpetual and will not be revoked by the Internet Society or 1291 its successors or assigns. This document and the information con- 1292 tained herein is provided on an "AS IS" basis and THE INTERNET 1293 SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRAN- 1294 TIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WAR- 1295 RANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 1296 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1297 FOR A PARTICULAR PURPOSE." 1299 14.0 Expiration Date 1301 This memo is filed as and 1302 expires in December 2001.