idnits 2.17.1 draft-ietf-aaa-diameter-cms-sec-02.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 31 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 32 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 1343 has weird spacing: '... copied and ...' == Line 1344 has weird spacing: '...s, and deriv...' == Line 1346 has weird spacing: '...ed, in whole...' == Line 1347 has weird spacing: '...hat the above...' == Line 1348 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 (July 2001) is 8320 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 1250, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1286, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1290, but no explicit reference was found in the text == Outdated reference: A later version (-16) exists of draft-ietf-aaa-diameter-07 -- 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 (~~), 16 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 Sun Microsystems, Inc. 4 Category: Standards Track Stephen Farrell 5 Baltimore Technologies 6 William Bulley 7 Merit Network, Inc. 8 July 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 AVP Occurrence Tables 95 9.0 IANA Considerations 96 9.1 Command Codes 97 9.2 AVP Codes 98 9.3 Result-Code AVP Values 99 9.4 Application Identifier 100 9.5 OCSP-Request-Flags AVP Values 101 10.0 Security Considerations 102 11.0 References 103 12.0 Acknowledgements 104 13.0 Authors' Addresses 105 14.0 Full Copyright Statement 106 15.0 Expiration Date 108 1.0 Introduction 110 The Diameter base protocol [1] leverages either IPsec or TLS for 111 integrity and confidentiality between two Diameter peers. However, 112 the Diameter protocol also allows peers to communicate through relay 113 and proxy agents, and in such environments security information is 114 lost at each agent. 116 Relay agents perform message routing, and other than routing AVPs, do 117 not modify Diameter messages. Proxy agents, on the other hand, 118 implement policy enforcement, and actively modify Diameter messages. 119 See [1] for a more comprehensive definition of the role of relay and 120 proxy agents. 122 1.1 Establishing Security Relationship through relay agents 124 The AAA Working Group has defined a set of requirements in [10] to 125 allow for Diameter peers to communicate securely through Relay 126 agents. This requirement calls for AVP integrity and confidentiality 127 between two peers communicating through agents. The term agent is 128 used in this specification for either a relay or a proxy agent. 129 Figure 1 provides an example of two Diameter peers establishing a 130 Diameter Security Association (DSA) through Relay agents. The 131 participants of a DSA are the peers where the DSA setup messages 132 terminate. In this example, the participants of the DSA would the NAS 133 (access device), and the Home Server. 135 mno.net mno.net xyz.net abc.com 136 +------+ <----> +------+ <----> +------+ <----> +------+ 137 | | TLS |Agent | IPSec |Agent | IPSec | Home | 138 | NAS | | | | | | | 139 | | | 1 | | 2 | |Server| 140 +------+ +------+ +------+ +------+ 141 <--------------------------------------------> 142 Diameter Security Association 144 Figure 1: Diameter Security Association 146 When one or more agents are used between two communicating Diameter 147 peers, the use of hop-by-hop security mechanisms (e.g. TLS, IPSec) 148 is unsuitable, since Diameter messages are processed at the 149 application layer at each agent. Therefore, an alternative mechanism 150 is required to protect portions of the message at the application 151 layer. 153 Allowing for a security association to be established through 154 Diameter relays allows the participants of the DSA to detect whether 155 protected AVPs have been modified en-route, and hides sensitive data 156 from intermediate agents. Furthermore, the Mobile IP and NASREQ 157 Working Groups have stated in [7, 8] that non-repudiation of Diameter 158 data, such as Accounting related AVPs, is necessary. 160 Figure 2 provides an example of a message sent by an access device 161 (NAS), through Diameter relay agents, to its intended destination, 162 the home server. In this example, Proxy 2 modifies the contents of 163 the foo AVP, perhaps due to mis-configuration, or maliciously. This 164 specification would allow the participants of the DSA to detect such 165 a problem, as long as the AVP being modified was protected. 167 (Request) (Request) (Request) 168 [AVP(foo)=x] [AVP(foo)=x] [AVP(foo)=y] 169 +------+ -----> +------+ -----> +------+ -----> +------+ 170 | | |Relay | |Proxy | | Home | 171 | NAS | | | | | | | 172 | | | 1 | | 2 | |Server| 173 +------+ <----- +------+ <----- +------+ <----- +------+ 174 (Answer) (Answer) (Answer) 175 [AVP(foo)=b] [AVP(foo)=b] [AVP(foo)=a] 177 Figure 2: Diameter agent modifying AVP 179 This document defines the Diameter commands that are used to 180 establish a DSA through Diameter agents, and specifies how 181 encapsulating CMS objects [3] in Diameter AVPs can provide 182 authentication, integrity and confidentiality. The CMS object MAY 183 also be used to transport X.509 certificates and revocation lists. 185 Establishing a DSA through relay agents requires that the initiator 186 issue a Diameter Security Association Request (DSAR) message. In the 187 example provided in figure 1, NAS would issue the DSAR with the 188 Destination-Realm AVP set to abc.com. The Home Server would process 189 the request, and respond by issuing a Diameter Security Association 190 Answer (DSAA) message. If the DSAA message contains a Result-Code 191 indicating success, the DSA is established between the NAS and the 192 home server. 194 Once the DSA is established, participants with private keys MAY apply 195 digital signatures to protect one or more AVP within a message. In 196 the example provided in Figure 2, the Foo AVP would be protected by 197 the digital signature, and any modification of the AVP by the relay 198 agents, would be detected when the signature validation algorithm 199 would fail by either participant. 201 1.2 Establishing Security Relationship through proxy agents 202 As previously discussed, proxy agents typically modify Diameter 203 messages to implement policy enforcement. An example of a proxy 204 server would be an aggregating server, which typically sits one 205 Diameter hop away from the access device, and enforces policy in 206 order to protect the access device from receiving AVPs that could 207 cause harm (e.g. excessive number of filters, unsupported tunneling 208 protocol). Although in theory such checks could be performed on the 209 access device, these devices are typically embedded systems, and not 210 easily configurable. The proxy agent's behavior, on the other hand, 211 is typically under control of the network operator. 213 Diameter messages between two participants of a DSA would fail 214 verification if a proxy agent were to modify any protected AVPs. 215 Therefore proxy agents either MUST NOT modify protected AVPs or else 216 MUST NOT allow the DSA to be established. When an DSAR is received 217 by a proxy agent, it has two options. First, if MAY simply deny all 218 DSA Setup Requests (DSAR) through it by responding with the DSAA 219 Result-Code AVP set to DIAMETER_NO_CMS_THROUGH_PROXY. The access 220 device can then determine whether it is willing to provide service, 221 based on its local policy. 223 Alternatively, it MAY reject the DSAR, but set the Result-Code AVP to 224 DIAMETER_CAN_ACT_AS_CMS_PROXY, informing the initiator of the DSAR 225 that it is a proxy agent, but is willing to establish the DSA on its 226 behalf. The DSAA MUST be signed by the proxy agent, and include its 227 certificate, to allow the access device to validate the originator of 228 the DSAA. At this point, the access device MUST determine whether the 229 proxy agent is a trusted agent, and whether it is willing to allow 230 the agent to provide such service. For instance, the access device 231 MAY be configured to ONLY accept DSAA with this result code from 232 proxy agents within its own domain. 234 Note that an access device MAY be configured to always issue a PDSR 235 to its aggregating proxy, reducing the number of round trips. 236 Similarly, an aggregating proxy MAY be configured to initiate an DSAR 237 regardless of whether a PDSR was sent by the access device. 239 mno.net mno.net xyz.net abc.com 240 +------+ +------+ +------+ +------+ 241 | | |Proxy | |Relay | | Home | 242 | NAS | | | | | | | 243 | | |Agent | |Agent | |Server| 244 +------+ +------+ +------+ +------+ 245 -------------> 246 (DSAR) Destination-Realm = abc.com 248 <------------- 249 (DSAA) Result-Code = DIAMETER_CAN_ACT_AS_CMS_PROXY 251 -------------> 252 (PDSR) DSAR-Target-Domain = abc.com 254 ----------------------------> 255 (DSAR) Destination-Realm = abc.com 257 <---------------------------- 258 (DSAA) Result-Code = DIAMETER_SUCCESS 260 <------------- 261 (PDSA) Result-Code = DIAMETER_SUCCESS 263 Figure 3: Establishing Security through Proxy Agent 265 An optimized approach also allows the PDSR to be sent by the access 266 device without the DSAR-Target-Domain AVP. This message is used to 267 inform the proxy that it MUST establish a Diameter security 268 association for all realms it will be communicating with on behalf of 269 the access device. 271 Allowing the first hop agent to be used to establish the DSA with the 272 home server MAY reduce the current concerns that the cryptographic 273 operations resulting from this specification MAY overburden embedded 274 access devices. 276 1.3 Using Redirector agents in lieu of DSA 278 When a redirect agent is used, allowing the access device, or first 279 hop relay or proxy agent, to communicate directly with the home 280 server. In such configurations, the hop-by-hop security mechanisms 281 specified in the base protocol MAY be sufficient. 283 However, there are certain business models where signing of select 284 Diameter AVPS (e.g. accounting) MAY be desired when redirectors are 285 used. Figure 4 shows an example where the relay agent contacts the 286 redirect agent to retrieve the necessary information for it to 287 communicate directly with the home server, which MAY include the home 288 server's certificates. 290 The relay agent MAY then initiate a DSA with the home server, using 291 the certificates provided by the redirector. 293 +------+ 294 | | 295 | DRD | 296 | | 297 +------+ 298 ^ | 299 2. Request | | 3. Redirection 300 | | Notification 301 | v 302 +------+ ---------> +------+ <--------> +------+ 303 | | 1. Request | | 4. DSAR/DSAA | | 304 | NAS | | DRL | | HMS | 305 | | 6. Answer | | 5. Request/Answer | | 306 +------+ <--------- +------+ <--------> +------+ 307 mno.net mno.net abc.com 309 Figure 4: DSA Setup following redirect 311 The CMS specification allows for Diameter AVPs to be multiply-signed 312 (see section 6.1), which may prove useful in business models that 313 require both parties to sign accounting data in parallel. This scheme 314 provides some assurance that both parties agreed to the accounting 315 data, which MAY be used for settlement purposes. 317 1.4 When to use DSAs 319 Given that asymmetric transform operations are expensive, access 320 devices and/or Diameter agents MAY wish to restrict establishment of 321 a DSA to cases where the participants belong to a different 322 administrative domain. 324 1.5 Who can authorize users 326 In this specification, we define how a Diameter Security Association 327 is established at the application layer to secure AVPs within a 328 message. However, it is important to note that one of participants 329 of a DSA (specifically the one in the home network) MUST belong to 330 the same realm as the user being authorized. This limitation will 331 prevent bigco.com from authorizing (or rather declining 332 authorization) for users at smallco.com. The realm of the 333 participants is found in the subjectAltName field of the Diameter 334 server's X.509 certificate. 336 [editor's note: This was added as part of the security review, but 337 seems unnecessarily restrictive. Can this section be deleted?] 339 1.6 Requirements language 341 In this document, the key words "MAY", "MUST", "MUST NOT", 342 "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be 343 interpreted as described in [5]. 345 1.7 Advertising application support 347 Diameter nodes conforming to this specification MAY advertise support 348 by including the value of two (2) in the Auth-Application-Id or the 349 Acct-Application-Id AVP of the Capabilities-Exchange-Request and 350 Capabilities-Exchange-Answer command [1]. 352 2.0 AVP Format 354 The Diameter base protocol [1] details the AVP header, which includes 355 the 'P' bit, but does not specify how the 'P' bit is used. The 'P' 356 bit, known as the protected AVP bit, is used to indicate whether the 357 AVP is protected by a digital signature. When set, the AVP is 358 protected and the contents cannot be changed by agents without 359 detection. 361 0 1 2 3 362 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 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | AVP Code | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 |V M P r r r r r| AVP Length | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Vendor-ID (opt) | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | Data ... 371 +-+-+-+-+-+-+-+-+ 372 Figure 5: Diameter AVP Header 374 All Diameter specifications MUST specify whether the 'P' bit can be 375 set or not, as is done in section 4.5 of [1] and section 6 below. 376 For AVPs that are designed to be changed at each hop (such as the 377 Proxy-Info AVP) Diameter nodes MUST NOT allow the 'P' bit to be set. 379 3.0 Key Management 381 For DSA origin authentication, CMS itself already provides sufficient 382 key management without the need for additional specification. 383 Basically, the originating Diameter node signs and includes whatever 384 certificates are necessary for validation of the digital signature. 386 However, for encryption of AVPs more work is needed. In order to be 387 able to encrypt AVPs for a recipient, the originating Diameter node 388 must have a copy of the recipient's public key. There are many well- 389 known key retrieval schemes (e.g. using LDAP [6]), however, in order 390 to simplify Diameter implementations a specific Diameter key 391 distribution mechanism is defined here. 393 Another issue that must be addressed is how a Diameter node is to 394 "know" that certain AVPs are required to be secured within CMS 395 objects. This is communicated in the Diameter Security Association 396 Request/Answer messages, listed in section 4.0. 398 This section describes how Diameter node names are encoded in 399 certificates. 401 3.1 Usage Scenario 403 When a Diameter node is about to send a message, it must determine 404 whether a DSA should be established or not. We assume the Diameter 405 node knows the user's realm, perhaps through the User-Name AVP. 407 Implementations MAY cache the information required to establish a 408 DSA, but MUST honor time-to-live settings and MUST re-validate 409 certificates (possibly including revocation checks) before using 410 cached data. 412 We use Diameter Security Association Request (DSAR) and Diameter 413 Security Association Answer (DSAA) messages to establish a DSA, which 414 specifies which AVPs should be authenticated and/or encrypted, as 415 well as which public key(s) to use. 417 The originating node sends the DSAR message to a server in the 418 destination realm. The DSAR message contains: 420 - TTL for this DSA (seconds) 421 - the realm part of the user's NAI 422 - the list of direct trust CA's that the originating Diameter 423 node has configured into it for certificate validation. A 424 "direct trust" CA is one that the node is willing to use as the 425 "top" of a certificate chain, sometimes confusingly known as a 426 "root CA." 427 - a list of AVPs that expected to be protected (and how) for this 428 realm 429 - (optionally) a flag indicating that the originating Diameter 430 node wishes to receive certificate status information (using 431 OCSP messages) in which case a nonce to be used by the 432 destination Diameter node in OCSP requests MAY also be 433 supplied. See [9] for details of the certificate status 434 protocol and messages. 436 The destination node returns the DSAA message which contains: 438 - TTL for this SA (seconds) 439 - a chain of CA certificates (possibly empty) 440 - public key certificates for the Diameter servers in the realm, 441 all of which MUST validate up to one of the CA's contained in 442 the DSAR message, via the chain of CA certificates above; 443 - a list of AVPs that expected to be protected (and how) for this 444 realm 445 - (optionally, if nonce received and OCSP supported) a list of 446 OCSP responses for the certificates in question, each of which 447 contains the nonce from the DSAR message 449 The originating Diameter node now has to check the response. Any 450 failure results in error messages and auditing and not sending the 451 Diameter message. 453 Checks: 455 - the certificate chain selected is cryptographically correct, 456 passes the (relevant parts of the) rfc2459 path validation 457 algorithm and terminates at a CA mentioned in the DSAR message 458 - the realm part of the user's NAI must occur as a subjectAltName 459 (with the dNSName option) in the AAA server's certificate. This 460 dNSName MUST be of the form "Diameter-." where 461 is the FQDN's domain component and can be 462 anything (e.g. "Diameter-1.baltimore.com", "Diameter- 463 west.sun.com") chosen by the Diameter server administrator. 464 - the DSAA message MUST be digitally signed and the signature 465 MUST be validated and the signer's certificate chain MUST 466 terminate as a CA mentioned in the DSAR message 467 - The expiration of the TTL MUST be less or equal to the earliest 468 expiration of all certificates in the message, encoded in the 469 notAfter field. 471 If certificate status (revocation) is an issue for the Diameter node, 472 then the DSAR message MAY contain a nonce value. The idea is that the 473 sender of the DSAA makes OCSP requests on behalf of the Diameter node 474 and returns the OCSP responses to the Diameter node as part of the 475 DSAR message. The use of the nonce value ensures that the sender of 476 the DSAA cannot return cached or otherwise fake OCSP responses to the 477 Diameter node. 479 The nonce value is to be (the beginning of) the nonce in the OCSP 480 response. The reason for this is that the responder MAY add 481 additional bits to the nonce, but the nonce provided in the OSCP- 482 Nonce MUST be present at the beginning of the nonce of the OSCP 483 response. 485 The DSAR MAY be signed. If the originating node has a private key and 486 protection expectations for AVPs are specified, then the DSAR SHOULD 487 be signed. 489 The DSAA MUST be signed by a Diameter agent or server within the 490 user's realm, to prevent an intermediate node from modifying the 491 protection expectations for AVPs. 493 If confidentiality or digital signature is required, then the 494 originating node prepares the CMS related AVPs as required. 496 If certificate revocation is enabled, anytime a certificate is used 497 from the local certicate cache, a revocation check MUST be performed. 499 3.2 Certificate Requirements 501 Certificates used for the purposes of Diameter MUST conform to the 502 PKIX profile [4], and MUST also include a Diameter node's FQDN, which 503 is typically added in the Host-Name AVP [1], as one of the values of 504 the subjectAltName extension of the Certificate. The FQDN is to be 505 encoded as a dNSName within the subjectAltName. 507 For Diameter nodes (capable of acting as recipients for 508 confidentiality), the FQDN MUST be of the form "Diameter- 509 .". Other Diameter nodes MAY use this naming scheme. Note 510 that this naming constraint is for PKI purposes only, and in no way 511 restricts a Diameter's host name. 513 The naming scheme presented here is intended to: 514 - make it simple to use existing certification authorities (CAs) 515 for Diamater CMS 516 - allow CAs to ensure that only "proper" Diameter certificiates 517 are accepted by Diameter nodes 519 - allow Diameter certfificates to be used for other purposes 520 where that meets a CA's practices. 522 These names are used for two purposes: 524 1. Where a Diameter node is verifying a signature it needs to be 525 able to compare the identity of the signer against the identity 526 in the Host-Name AVP. 528 2. Where a Diameter node is encrypting AVPs, it needs to be able 529 to ensure that it uses a public key for the intended recipient. 530 This requires comparing the identity in a Certificate against 531 the FQDN of the intended recipient (which is assumed to be 532 known). 534 In either case, the presence of the required FQDN as a dNSName value 535 in the subjectAltName extension of a verified public key certificate 536 satisfies the matching requirement. 538 Note that there MAY also be other values in the subjectAltName 539 extension, (either using dNSName or other elements of the CHOICE), 540 these can be safely ignored, but implementations MUST be able to 541 handle their presence. 543 Note also that the PKIX profile [4], section 4.1.2.6, specifies the 544 rules for the relationship between the subjectAltName extension and 545 the subject field of public key certificates. 547 For multiple Diameter servers within a domain that share a public 548 key, each server's identity is encoded in the subjectAltName 549 extension. This allows any server within a domain to decrypt AVPs 550 intended for that domain. 552 Note that once operational experience has been gained, a future 553 document may specify a restricted profile of [4] in order to simplify 554 implementation. 556 3.3 Algorithms 558 For all uses of CMS in this specification the mandatory to implement 559 algorithms are as follows: 561 - Asymmetric: RSA 562 - Hashing: SHA-1 563 - Signature: RSAwithSHA1 564 - Symmetric Encryption: 3DES 566 At some point in future, AES will replace 3DES. 568 3.4 Reuse of CMS Content Encryption Keys 570 Once a CMS-Encrypted-Data AVP has been exchanged between two Diameter 571 peers, then they share a symmetric cryptographic key (the content 572 encryption key) which can be used to encrypt further Diameter AVPs 573 between the peers by using the scheme specified in [15]. The peers 574 MUST first take part in an DSAR/DSAA exchange in order to distribute 575 the required asymmetric keys. 577 Note that the use of symmetric keys does not provide "non- 578 repudiation". 580 [15] leaves open some issues, namely how to handle loss of a shared 581 secret (say following a peer re-boot) and for how long to continue to 582 use a shared secret (the maximum number of decryptions required). 584 Where a Diameter node receives a CMS-Encrypted-Data AVP, but doesn't 585 have the required shared secret, that node should return the 586 DIAMETER_KEY_UNKNOWN error message. The peer may then use the 587 DSAR/DSAA exchange to rebuild their Diameter security association. 589 In [15], the default value for the maximum number of decryptions 590 allowed (CEKMaxDecrypts) when re-using a content encryption key is 1. 591 In general this default SHOULD be used, but if a Diameter node 592 "knows" that more than one CMS-Encrypted-Data AVP will be exchanged 593 between the nodes (based on the Expected-Encrypted-AVP settings 594 exchanged during the DSAR/DSAA exchange) then the CEKMaxDecrypts 595 setting MAY be set higher. Diameter nodes MUST be able to support a 596 maxDecrypts setting of 1000. 598 4.0 Command-Codes Values 600 This section defines new Command-Code [1] values that MUST be 601 supported by all Diameter implementations that conform to this 602 specification. The following Command Codes are currently defined in 603 this document: 605 Command-Name Abbrev. Code Reference 606 -------------------------------------------------------- 607 Diameter-Security- DSAR 304 4.1 608 Association-Request 609 Diameter-Security- DSAA 304 4.2 610 Association-Answer 611 Proxy-Diameter-Security- PDSR 305 4.3 612 Association-Request 613 Proxy-Diameter-Security- PDSA 305 4.4 614 Association-Answer 616 4.1 Diameter-Security-Association-Request 618 The Diameter-Security-Association-Request command, indicated by the 619 Command-Code field set to 304 and the 'R' bit set in the message 620 flags field, is sent by a Diameter node to establish a Diameter 621 Security Association. 623 Message Format 625 ::= < Diameter-Header: 304, REQ, PXY > 626 { Origin-Host } 627 { Origin-Realm } 628 { Destination-Realm } 629 * { Local-CA-info } 630 { Auth-Application-Id } 631 { OCSP-Request-Flags } 632 { DSA-TTL } 633 [ Destination-Host ] 634 * [ Expected-Signed-AVP ] 635 * [ Expected-Encrypted-AVP ] 636 [ OCSP-Nonce ] 637 0*1[ CMS-Signed-Data ] 638 [ Origin-State-Id ] 639 * [ AVP ] 640 * [ Proxy-Info ] 641 * [ Route-Record ] 643 4.2 Diameter-Security-Association-Answer 645 The Diameter-Security-Association-Answer command, indicated by the 646 Command-Code field set to 304, with the 'R' bit in the Command Flags 647 cleared, in response to a DSAR. 649 Message Format 650 ::= < Diameter-Header: 304, PXY > 651 { Result-Code } 652 { Origin-Host } 653 { Origin-Realm } 654 0*1{ CA-Chain } 655 * { AAA-Server-Certs } 656 * { OCSP-Responses } 657 { Destination-Host } 658 { Auth-Application-Id } 659 { DSA-TTL } 660 * [ Expected-Signed-AVP ] 661 * [ Expected-Encrypted-AVP ] 662 [ CMS-Signed-Data ] 663 [ Origin-State-Id ] 664 * [ AVP ] 665 * [ Proxy-Info ] 666 * [ Route-Record ] 668 4.3 Proxy-Diameter-Security-Assocation-Request 670 The Proxy-Diameter-Security-Association-Request command, indicated by 671 the Command-Code field set to 305 and the 'R' bit set in the Command 672 Flags field, is sent by a Diameter node to request that a downstream 673 proxy establishes an Security Association with a server in a given 674 domain on its behalf. 676 Message Format 678 ::= < Diameter-Header: 305, REQ, PXY > 679 { Origin-Host } 680 { Origin-Realm } 681 { Destination-Realm } 682 { Auth-Application-Id } 683 [ DSAR-Target-Domain ] 684 [ Origin-State-Id ] 685 * [ AVP ] 686 * [ Proxy-Info ] 687 * [ Route-Record ] 689 4.4 Proxy-Diameter-Security-Association-Answer 691 The Proxy-Diameter-Security-Association-Answer command, indicated by 692 the Command-Code field set to 305 and the 'R' bit cleared in the 693 Command Flags field, is sent by a Diameter node in response to an 694 PDSR message. 696 Message Format 698 ::= < Diameter-Header: 305, PXY > 699 { Result-Code } 700 { Origin-Host } 701 { Origin-Realm } 702 { Destination-Host } 703 { Auth-Application-Id } 704 [ Origin-State-Id ] 705 * [ AVP ] 706 * [ Proxy-Info ] 707 * [ Route-Record ] 709 5.0 Diameter Security Association Message Flow 711 This section contains an example of a NAS in domain xyz.com, 712 communicating with its local relay agent, which in turn communicates 713 with a server in ABC.COM's network. In the following example, once 714 the initial capabilities exchange is complete, the NAS receives a 715 request for access from alice@abc.com, which causes the DSA setup to 716 be initiated, followed by the application-specific authentication 717 request. 719 Although the example doesn't specifically use bi-directional CMS 720 authentication and encryption, this feature is supported. 722 +-------+ +-------+ +---------+ 723 | NAS | | Relay | | abc.com | 724 | | | Agent | |Home Srv | 725 +-------+ +-------+ +---------+ 726 | | | 727 |CER apps 1, 2 | | 728 (a) |------------------->| | 729 |CAA apps -1 | | 730 (b) |<-------------------| | 731 | . |CER apps 1, 2 | 732 (c) | |<-------------------| 733 | |CEA apps -1 | 734 (d) | |------------------->| 735 ->| User alice@abc.com | | 736 (e) | Requests Access | | 737 | | | 738 | DSAR | | 739 | Dest-Realm=abc.com | | 740 | CMS-Cert | | 741 (f) |--------------------+------------------->| 742 | | DSAA | 743 | | Origin-Host=foo | 744 | | CMS-Cert | 745 (g) |<-------------------+--------------------| 746 | Auth-Request + | | 747 | CMS-Signed-Data | | 748 | Dest-Host=foo | | 749 (h) |--------------------+------------------->| 750 | | Auth-Answer + | 751 | | CMS-Encrypted-Data | 752 (i) |<-------------------+--------------------| 753 Figure 6: Example of a DSA Setup 755 (a) NAS sends a CER message to its relay agent indicating that it 756 supports applications 1 (NASREQ) and 2 (CMS Security). 758 (b) The proxy server sends a CEA message to the NAS indicating 759 that it is a relay supporting all Diameter applications. 761 (c) ABC.COM's Home Server sends a CER message to a proxy server 762 indicating that it supports applications 1 (NASREQ) and 2 (CMS 763 Security). 765 (d) The proxy server sends a CEA message to ABC.COM's Home Server 766 indicating that it is a relay supporting all Diameter 767 applications. 769 (e) The NAS receives a request for access from a user 770 (alice@abc.com). 772 (f) The NAS issues an DSAR message, with the Destination-Realm AVP 773 set to abc.com, and its certificate in the CMS-Cert AVP. The 774 DSAR includes the set of AVPs that the NAS expects to be 775 encrypted, in the event that the home server returns messages 776 that contain these AVPs. 778 (g) ABC.COM's Home Server processes the DSAR message, and replies 779 with the DSAA message. The DSAA also includes the set of AVPs 780 that the home server is expecting to be authenticated, as well 781 as its certificate in the CMS-Cert AVP. 783 (h) The NAS issues an authentication request with the 784 Destination-Host AVP set to the value of the Origin-Host AVP 785 in the DSAA. The message includes the CMS-Signed-AVP, which 786 authenticates the AVPs that were requested by the Home Server 787 in the DSAA. 789 (i) The Home Server successfully authenticates the user, and 790 returns a reply, which includes the CMS-Encrypted-Data AVP, 791 whose contents include the AVPs that were specified by the NAS 792 in the DSAR. 794 6.0 CMS Security AVPs 796 This section contains AVPs that are used to establish a Diameter 797 Security Association, and to transport CMS objects. 799 +---------------------+ 800 | AVP Flag rules | 801 |----+-----+----+-----|----+ 802 AVP Section | | |SHLD| MUST|MAY | 803 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 804 -----------------------------------------|----+-----+----+-----|----| 805 AAA-Server-Certs 351 6.6 OctetString| M | P | | V | N | 806 AVP-Code 352 6.11 Unsigned32 | M | P | | V | N | 807 CA-Chain 353 6.8 OctetString| M | P | | V | N | 808 CA-Name 349 6.4.1 OctetString| M | P | | V | N | 809 CMS-Cert 354 6.3 OctetString| M | | | P,V | N | 810 CMS-Encrypted- 355 6.2 OctetString| M | P | | V | N | 811 Data | | | | | | 812 CMS-Signed-Data 310 6.1 OctetString| M | | | P,V | N | 813 DSA-TTL 362 6.14 Unsigned32 | M | P | | P,V | N | 814 DSAR-Target- 360 6.13 OctetString| M | P | | V | N | 815 Domain | | | | | | 816 Expected-Signed- 356 6.9 Grouped |M,P | | | V | N | 817 AVP | | | | | | 818 Expected- 357 6.10 Grouped |M,P | | | V | N | 819 Encrypted-AVP | | | | | | 820 Key-Hash 350 6.4.2 OctetString| M | P | | V | N | 821 Local-CA-Info 348 6.4 Grouped | M | P | | V | N | 822 OCSP-Nonce 358 6.5 OctetString| M | P | | V | N | 823 OCSP-Request- 361 6.12 Unsigned32 | M | P | | V | N | 824 Flags | | | | | | 825 OCSP-Responses 359 6.7 OctetString| M | P | | V | N | 827 6.1 CMS-Signed-Data AVP 829 The CMS-Signed-Data AVP (AVP Code 310) is of type OctetString and 830 contains the Basic Encoding Rules (BER) encoding of a CMS object [3] 831 of type ContentInfo. The profile of CMS algorithm and structure usage 832 is as specified in the S/MIME v3 message specification [11]. This 833 means that where a set of AVPs is protected using CMS, the set MUST 834 first be encoded according to MIME encoding rules specified below. 835 This method of encapsulating AVPs allows existing S/MIME toolkits to 836 be used without changes in order to provide authentication within the 837 Diameter application layer. 839 To package a set of AVPs as a MIME type, AVPs with the 'P' bit are 840 first concatenated in the order in which they occur in the Diameter 841 message, including padding. The result is used as input into the 842 signing process. Note that the AVPs themselves are not encapsulated 843 within the CMS-Signed-Data AVP. Instead, the digest value within the 844 SignedData structure contains the digest produced in the signature 845 process. 847 Multiple Diameter entities MAY add their signatures to an existing 848 CMS-Signed-Data AVP using the countersignature attribute, defined in 849 section 11.4 of [3]. The countersignature attribute requires that the 850 signatures occur sequentially, meaning that each signature covers the 851 existing signatures in the CMS object. 853 The initial signature, and any additional countersignatures, MUST 854 cover the exact same set of AVPs, in the order they are present in 855 the message. 857 Note that the CMS-Signed-Data AVP MUST NOT be used in the generation 858 of the signature, and therefore MUST NOT have its 'P' bit set. 860 If a receiver detects that the contents of the CMS-Signed-Data AVP 861 are invalid, it SHOULD return the new Result-Code AVP value defined 862 in section 7.0. 864 When AVPs are to be both encrypted and signed, the CMS-Encrypted-Data 865 AVP MUST be created first. The resulting CMS object MUST then be MIME 866 encoded producing an application/pkcs7-mime MIME type which is then 867 used as the content of the EnvelopedData. This means that signing is 868 "outside" encryption. 870 The eContent field of the EncapsulatedContentInfo structure MUST be 871 absent since the authentication covers data outside of the object. 872 The signature is computed over all AVPs with the 'P' bit enabled. The 873 order of the AVPs MUST be preserved and the computation begins with 874 the first AVP immediately following the Diameter header. If the 875 signature cannot be verified correctly, a response with the Result- 876 Code AVP set to DIAMETER_INVALID_AUTH [1] MUST be returned. 878 No more than one CMS-Signed-Data AVP MUST be present in any given 879 Diameter message. 881 6.2 CMS-Encrypted-Data AVP 883 The CMS-Encrypted-Data AVP (AVP Code 355) is of type OctetString and 884 contains the Basic Encoding Rules (BER) encoding of a CMS object [3] 885 of type ContentInfo. 887 The entire AVP MUST be input to the encryption process, in network 888 byte order, including any padding. All AVPs to be encrypted are 889 concatenated, and the encryptor is free to order AVPs in whatever way 890 it chooses. The value is then encrypted and used as the value of the 891 EncryptedContent field within CMSEnvelopedData. 893 If a receiver detects that the contents of the CMS-Data AVP is 894 invalid, it SHOULD return the new Result-Code AVP value defined in 895 section 7.0. 897 When AVPs are to be both encrypted and authenticated, the CMS- 898 Encrypted-Data AVP MUST be created first. 900 Where AVPs are encapsulated within a CMS-Encrypted-Data AVP, the 901 eContentType of the EncapsulatedContentInfo MUST be id-data [11]. 903 CMS-Encrypted-Data MAY contain more than one CMS object, that is, 904 implementations MUST be able to add a new CMS-Encrypted-Data AVP 905 value and also MUST be able to decrypt all CMS-Encrypted-Data AVP 906 values which are encrypted for them. 908 When a conforming implementation receives a Diameter message which 909 contains encrypted AVPs within a CMS EnvelopedData, the recipient 910 MUST check to see if it is on the list of recipients specified in the 911 RecipientInfos of the EnvelopedData. If not, the recipient MAY choose 912 to process the message or indicate an error. If the recipient is in 913 the RecipientInfos and an error occurs during decryption, then the 914 recipient MUST indicate an error. 916 Diameter nodes SHOULD implement content encryption key re-use (see 917 section 3.4 above). 919 Zero or more CMS-Encrypted-Data AVP MAY be present in any Diameter 920 message. 922 6.3 CMS-Cert AVP 924 The CMS-Cert AVP (AVP Code 354) is of type OctetString and contains a 925 "certs-only" CMS structure which is a degenerate form of CMS 926 structure containing only PKI related information (see section 3.6 of 927 [11] for details of the CMS certs-only structure). 929 The CMS-Cert AVP contains one or more public key certificates 930 (Certificate) and MAY optionally contains attribute certificates 931 (AttributeCertificate) as allowed by CMS. Other legacy formats 932 supported by CMS MUST NOT be used. 934 Support for use of the Certificate structure is REQUIRED, while 935 implementations MAY support use of the AttributeCertificate structure 936 as defined in the PKIX attribute certificate profile [12]. The latter 937 allows Diameter implementations to include a certificate from a 938 trusted party that they are authorized to emit the AVPs contained in 939 the message. 941 This use of the CMS-Cert AVP can be used to "push" public key and 942 attribute certificates and CRLs using Diameter, which MAY be useful 943 in environments where repositories (e.g. LDAP servers) are either 944 not used or not available (e.g. due to crossing a domain boundary). 945 Conforming implementations MUST be able to emit a certs-only CMS 946 structure which contains relevant PKI related information and MUST be 947 able to process a CMS-Cert AVP which contains a certs-only CMS 948 structure. Of course, the recipient of such a certs-only CMS 949 structure SHOULD NOT use the PKI related information without first 950 verifying it, e.g. by checking that issuer's are trusted, signatures 951 verify etc. 953 A CRL [4] MAY also be provided in the crls field of the SignedData, 954 which MAY be used to assist in determining whether a certificate has 955 been revoked. Optionally, the Diameter node MAY check the status of 956 certificates using another mechanism, such as Online Certificate 957 Status Protocol (OCSP) [9]. 959 6.4 Local-CA-Info AVP 961 The Local-CA-Info AVP (AVP Code 348) is of type Grouped. The Grouped 962 Data field has the following ABNF grammar: 964 Local-CA-Info ::= < AVP Header: 348 > 965 { CA-Name } 966 { Key-Hash } 968 6.4.1 CA-Name AVP 970 The CA-Name AVP (AVP Code 349) is of type UTF8String. The AVP 971 contains the DN (in LDAP string syntax) of the Certificate Authority, 972 e.g. "CN=CA;O=Baltimore Technologies;C=IE". 974 6.4.2 Key-Hash AVP 976 The Key-Hash AVP (AVP Code 350) is of type OctetString, and contains 977 a SHA-1 hash of the key. 979 The hash MUST be calculated over the representation of the CA public 980 key which would be present in an X.509 public key certificate, 981 specifically, the input for the hash algorithm MUST be the DER 982 encoding of a SubjectPublicKeyInfo representation of the key. Note: 983 This includes the AlgorithmIdentifier as well as the BIT STRING. The 984 rules given in [4] for encoding keys MUST be followed. 986 Since this AVP is used for indexing and not for security (since 987 Diameter nodes SHOULD validate certificates), there is no need to 988 support more than one hash algorithm here. 990 6.5 OCSP-Nonce AVP 992 The OCSP-Nonce AVP (AVP Code 358) is of type OctetString, and 993 contains a random value (RECOMMENDED 128 bits) generated by the 994 Diameter node. 996 6.6 AAA-Server-Certs AVP 998 The AAA-Server-Certs AVP (AVP Code 351) is of type OctetString and 999 contains the certificates of the AAA Servers in the home domain. 1000 Note: this AVP contains no CA certificates, just those for AAA 1001 servers. Certificates MUST follow the naming conventions described in 1002 section 3.2. 1004 6.7 OCSP-Responses AVP 1006 The OCSP-Responses AVP (AVP Code 359) is of type OctetString, and 1007 contains an OCSP response message from an OCSP responder. If the 1008 OCSP-Request-Flags AVP indicating a response was required in the 1009 corresponding request message, the OCSP-Response AVP MUST be present. 1010 Furthermore, the OCSP-Request-Flags AVP MAY request a fresh OCSP 1011 response message, which MUST also include the OCSP-Nonce AVP. 1013 6.8 CA-Chain AVP 1015 The CA-Chain AVP (AVP Code 353) is of type OctetString, and contains 1016 a certificate chain, from one of the nominated locally trusted CAs 1017 down to the (one and only) CA which has issued the end entity 1018 certificates in the AAA-Server-Certs AVP. 1020 To produce this AVP in an DSAA message, one (and only one) of the 1021 Local-CA-info values from the corresponding DSAR message is selected 1022 (call this the "top" CA for the purposes of this description). This 1023 AVP then contains a certificate path (in order) from the "top" CA 1024 down to the (one and only) CA which has issued all the end entity 1025 certificates in the AAA-Servers-AVP. The (typically self-signed), 1026 certificate of the "top" CA MUST NOT be included. 1028 6.9 Expected-Signed-AVP AVP 1029 The Expected-Signed-AVP AVP (AVP Code 356) is of type Grouped. The 1030 Grouped Data field has the following ABNF grammar: 1032 Expected-Signed-AVP ::= < AVP Header: 356 > 1033 { AVP-Code } 1034 [ Vendor-Id ] 1036 The Expected-Signed-AVP AVP contains an AVP code, which if sent by 1037 the peer, MUST be authenticated via the CMS-Signed-Data AVP. 1038 Vendor-Specific AVPs are represented by including the optional 1039 Vendor-Id AVP. 1041 If this AVP is present in the DSAR or DSAA, it MUST be authenticated 1042 using the CMS-Signed-Data AVP. 1044 6.10 Expected-Encrypted-AVP AVP 1046 The Expected-Encrypted-AVP AVP (AVP Code 357) is of type Grouped. 1047 The Grouped Data field has the following ABNF grammar: 1049 Expected-Encrypted-AVP ::= < AVP Header: 357 > 1050 { AVP-Code } 1051 [ Vendor-Id ] 1053 The Expected-Encrypted-AVP AVP contains an AVP code, which if sent by 1054 the peer, MUST be encrypted in the CMS-Encrypted-Data AVP. Vendor- 1055 Specific AVPs are represented by including the optional Vendor-Id 1056 AVP. 1058 If this AVP is present in the DSAR or DSAA, it MUST be authenticated 1059 using the CMS-Signed-Data AVP. 1061 6.11 AVP-Code AVP 1063 The AVP-Code AVP (AVP Code 352) is of type Unsigned32, and contains 1064 the AVP Code of the AVP that is to be authenticated or encrypted. 1066 6.12 OCSP-Request-Flags AVP 1068 The OCSP-Request-Flags AVP (AVP Code 361) is of type Enumerated, and 1069 specifies whether the sender wishes to receive an OCSP response. The 1070 following values are defined: 1072 NO_OCSP_RESPONSE 0 1073 The sender does not wish to receive an OCSP Response. 1075 OCSP_RESPONSE 1 1076 The sender wishes to receive an OCSP Response, and is willing 1077 to accept a stale response. 1079 OCSP_FRESH_RESPONSE 2 1080 The sender wishes to receive a fresh OCSP Response. When this 1081 value is set, the OCSP-Nonce AVP MUST be present. 1083 6.13 DSAR-Target-Domain AVP 1085 The DSAR-Target-Domain AVP (AVP Code 360) is of type UTF8String, and 1086 contains the Destination-Realm of the resulting DSAR sent by a non- 1087 transparent proxy. 1089 6.14 DSA-TTL AVP 1091 The DSA-TTL AVP (AVP Code 362) is of type Unsigned32, and contains 1092 the time to live (in seconds) of the Diameter Security Association. 1093 The expiration time (now+TTL) MUST NOT be greater than the earliest 1094 expiration time (NotAfter field) of all certificates included in this 1095 message accompanying this AVP. The DSA-TTL AVP in the DSAA MUST NOT 1096 be greater than the DSA-TTL AVP in the DSAR. 1098 7.0 Result-Code AVP Values 1100 This section defines new Result-Code [1] values that MUST be 1101 supported by all Diameter implementations that conform to this 1102 specification. 1104 7.1 Transient Failures 1106 Errors that fall within the transient failures category are used to 1107 inform a peer that the request could not be satisfied at the time it 1108 was received, but MAY be able to satisfy the request in the future. 1110 DIAMETER_KEY_UNKNOWN 4008 1111 This error code is returned when a CMS-Signed-Data or CMS- 1112 Encrypted-Data AVP is received that was generated using a key 1113 that is not locally recognized. This error could be caused if 1114 one of the participants of a DSA lost a previously agreed upon 1115 key, perhaps as a result of a reboot. 1117 7.2 Permanent Failures 1118 Errors that fall within the permanent failures category are used to 1119 inform the peer that the request failed, and should not be attempted 1120 again. 1122 DIAMETER_INVALID_CMS_DATA 5019 1123 This error code is returned when a CMS-Data AVP is received 1124 with an invalid ContentInfo object. 1126 DIAMETER_NO_CMS_THROUGH_PROXY 5020 1127 This error code is returned when a non-transparent proxy 1128 receives an DSAR message to state that it doesn't allow a DSA 1129 through it since it plans to modify AVPs. 1131 DIAMETER_CAN_ACT_AS_CMS_PROXY 5021 1132 This error code is returned when a non-transparent proxy 1133 receives an DSAR message, and although it doesn't allow a DSA 1134 through it, it is willing to initiate a DSA on behalf of the 1135 access device. 1137 8.0 AVP Occurrence Tables 1139 The table in this section presents the AVPs defined in this document, 1140 and specifies in which Diameter messages they MAY, or MAY NOT be 1141 present. Note that AVPs that can only be present within a Grouped 1142 AVP are not represented in this table. 1144 The table uses the following symbols: 1145 0 The AVP MUST NOT be present in the message. 1146 0+ Zero or more instances of the AVP MAY be present in the 1147 message. 1148 0-1 Zero or one instance of the AVP MAY be present in the 1149 message. 1150 1 One instance of the AVP MUST be present in the message. 1151 1+ At least one instance of the AVP MUST be present in the 1152 message. 1154 +-----------------------+ 1155 | Command-Code | 1156 |-----+-----+-----+-----+ 1157 Attribute Name | DSAR| DSAA| PDSR| PDSA| 1158 ------------------------------|-----+-----+-----+-----+ 1159 Auth-Application-Id | 1 | 1 | 1 | 1 | 1160 Destination-Host | 0-1 | 1 | 0 | 1 | 1161 Destination-Realm | 1 | 0 | 1 | 0 | 1162 Error-Message | 0 | 0-1 | 0 | 0-1 | 1163 Error-Reporting-Host | 0 | 0-1 | 0 | 0-1 | 1164 AAA-Server-Certs | 0 | 1+ | 0 | 0 | 1165 AVP-Code | 0 | 0 | 0 | 0 | 1166 CA-Chain | 0 | 0-1 | 0 | 0 | 1167 CA-Name | 0 | 0 | 0 | 0 | 1168 CMS-Cert | 0 | 0 | 0 | 0 | 1169 CMS-Encrypted-Data | 0 | 0 | 0 | 0 | 1170 CMS-Signed-Data | 0-1 | 0-1 | 0 | 0 | 1171 DSA-TTL | 1 | 1 | 0 | 0 | 1172 DSAR-Target-Domain | 0 | 0 | 0-1 | 0 | 1173 Expected-Signed-AVP | 0+ | 0+ | 0 | 0 | 1174 Expected-Encrypted-AVP | 0+ | 0+ | 0 | 0 | 1175 Local-CA-Info | 0+ | 0 | 0 | 0 | 1176 OCSP-Nonce | 0-1 | 0 | 0 | 0 | 1177 OCSP-Request-Flags | 1 | 0 | 0 | 0 | 1178 OCSP-Responses | 0 | 1+ | 0 | 0 | 1179 Origin-Host | 1 | 1 | 1 | 1 | 1180 Origin-Realm | 1 | 1 | 1 | 1 | 1181 Original-State-Id | 0-1 | 0-1 | 0-1 | 0-1 | 1182 Proxy-Info | 0+ | 0+ | 0+ | 0+ | 1183 Redirect-Host | 0 | 0+ | 0 | 0+ | 1184 Redirect-Host-Usage | 0 | 0-1 | 0 | 0-1 | 1185 Redirect-Max-Cache-Time | 0 | 0-1 | 0 | 0-1 | 1186 Result-Code | 0 | 1 | 0 | 1 | 1187 Route-Record | 0+ | 0+ | 0+ | 0+ | 1188 ------------------------------|-----+-----+-----+-----| 1190 9.0 IANA Considerations 1192 This section contains the namespaces that have either been created in 1193 this specification, or the values assigned to existing namespaces 1194 managed by IANA. 1196 9.1 Command Codes 1198 This specification assigns the value 304 and 305 from the Command 1199 Code namespace defined in [1]. See section 4.0 for the assignment of 1200 the namespace in this specification. 1202 9.2 AVP Codes 1204 This specification assigns the values 348-361 from the AVP Code 1205 namespace defined in [1]. See section 6.0 for the assignment of the 1206 namespace in this specification. 1208 9.3 Result-Code AVP Values 1210 This specification assigns the values 4008, 5019-5021 from the 1211 Result-Code AVP (AVP Code 268) value namespace defined in [1]. See 1212 section 7.0 for the assignment of the namespace in this 1213 specification. 1215 9.4 Application Identifier 1217 This specification assigns the value two (2) to the Application 1218 Identifier namespace defined in [1]. See section 1.6 for more 1219 information. 1221 9.5 OCSP-Request-Flags AVP Values 1223 As defined in Section 6.12, the OCSP-Request-Flags AVP (AVP Code 361) 1224 defines the values 0-2. All remaining values are available for 1225 assignment via IETF Consensus [12]. 1227 10.0 Security Considerations 1229 This document describes how CMS security can be achieved in the 1230 Diameter protocol by allowing S/MIME Cryptographic Message Syntax [3] 1231 objects to be carried as a Diameter AVP. 1233 This specification does not mandate certificate revocation, however 1234 not verifying whether a given certificate has been revoked has 1235 serious implications, and MAY create a security hole. 1237 The PDSR and PDSA messages (sections 4.3 and 4.4) allow a third party 1238 proxy to establish a Diameter security association with a Diameter 1239 server in a target realm. An access device MUST ensure that the 1240 server establishing the SA on its behalf is a trusted entity, since 1241 the proxy in question could modify Diameter messages, which would be 1242 very difficult to trace. 1244 11.0 References 1246 [1] P. Calhoun, H. Akhtar, J. Arkko, E. Guttman, A. Rubens, "Diame- 1247 ter Base Protocol", draft-ietf-aaa-diameter-07.txt, IETF work in 1248 progress, July 2001. 1250 [2] Kaufman, Perlman, Speciner, "Network Security: Private Communi- 1251 cations in a Public World", Prentice Hall, March 1995, ISBN 0- 1252 13-061466-1. 1254 [3] R. Housley, "Cryptographic Message Syntax", RFC 2630, June 1999. 1256 [4] Housley, Ford, Polk, Solo, "Internet X.509 Public Key Infras- 1257 tructure Certificate and CRL Profile", RFC 2459, January 1999. 1259 [5] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1260 Levels", BCP 14, RFC 2119, March 1997. 1262 [6] Boyen, Howes, Richard, "Internet X.509 Public Key Infrastructure 1263 Operational Protocols - LDAPv2", RFC 2559, April 1999. 1265 [7] T. Hiller et al., "Cdma2000 Wireless Data Requirements for AAA", 1266 RFC 3141, June 2001. 1268 [8] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, 1269 Authorization, and Accounting Requirements". RFC 2977. October 1270 2000. 1272 [9] Myers, Ankney, Malpani, Galperin, Adams, "X.509 Internet Public 1273 Key Infrastructure Online Certificate Status Protocol (OCSP)", 1274 RFC 2560, June 1999. 1276 [10] Aboba et al., "Criteria for Evaluating AAA Protocols for Network 1277 Access", RFC 2989, November 2000. 1279 [11] B. Ramsdell, "S/MIME v2 Message Specification", RFC2633, June 1280 1999. 1282 [12] S. Farrell, R. Housley, "An Internet Attribute Certificate Pro- 1283 file for Authorization", draft-ietf-pkix-ac509prof-09.txt, IETF 1284 work in progress, June 2001. 1286 [13] P. Calhoun, W. Bulley, G. Zorn, "Diameter NASREQ Application", 1287 draft-ietf-aaa-Diameter-nasreq-07.txt, IETF work in progress, 1288 July 2001. 1290 [14] P. Calhoun, C. Perkins, "Diameter Mobile IP Application", 1291 draft-ietf-aaa-Diameter-mobileip-07.txt, IETF work in progress, 1292 July 2001. 1294 [15] Farrell, Turner, "Reuse of CMS Content Encryption Keys", draft- 1295 ietf-smime-rcek-04.txt, IETF work in progress, May 2001. 1297 12.0 Acknowledgements 1299 The authors would also like to acknowledge the following people for 1300 their contribution in the development of this specification: 1302 Bernard Aboba, Jari Arkko and Steven Bellovin 1304 13.0 Authors' Addresses 1306 Questions about this memo can be directed to: 1308 Pat R. Calhoun 1309 Network and Security Research Center, Sun Labs 1310 Sun Microsystems, Inc. 1311 15 Network Circle 1312 Menlo Park, California, 94025 1313 USA 1315 Phone: +1 650-786-7733 1316 Fax: +1 650-786-6445 1317 E-mail: pcalhoun@eng.sun.com 1319 Stephen Farrell 1320 Baltimore Technologies 1321 39 Parkgate Street, 1322 Dublin 8, 1323 IRELAND 1325 Phone: +353-1-881-6000 1326 Fax: +353-1-881-7000 1327 E-Mail: stephen.farrell@baltimore.ie 1329 William Bulley 1330 Merit Network, Inc. 1331 Building One, Suite 2000 1332 4251 Plymouth Road 1333 Ann Arbor, Michigan, 48105-2785 1334 USA 1335 Phone: +1 734-764-9993 1336 Fax: +1 734-647-5185 1337 E-mail: web@merit.edu 1339 14.0 Full Copyright Statement 1341 Copyright (C) The Internet Society (2001). All Rights Reserved. 1343 This document and translations of it may be copied and furnished 1344 to others, and derivative works that comment on or otherwise 1345 explain it or assist in its implementation may be prepared, copied, 1346 published and distributed, in whole or in part, without restric- 1347 tion of any kind, provided that the above copyright notice and 1348 this paragraph are included on all such copies and derivative 1349 works. However, this docu- ment itself may not be modified in any 1350 way, such as by removing the copyright notice or references to the 1351 Internet Society or other Inter- net organizations, except as needed 1352 for the purpose of developing Internet standards in which case 1353 the procedures for copyrights defined in the Internet Standards pro- 1354 cess must be followed, or as required to translate it into languages 1355 other than English. The limited permis- sions granted above are 1356 perpetual and will not be revoked by the Internet Society or 1357 its successors or assigns. This document and the information con- 1358 tained herein is provided on an "AS IS" basis and THE INTERNET 1359 SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRAN- 1360 TIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WAR- 1361 RANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 1362 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1363 FOR A PARTICULAR PURPOSE." 1365 15.0 Expiration Date 1367 This memo is filed as and 1368 expires in January 2002.