idnits 2.17.1 draft-ietf-aaa-diameter-cms-sec-00.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 999 has weird spacing: '...CA cert shoul...' == Line 1262 has weird spacing: '... copied and ...' == Line 1263 has weird spacing: '...s, and deriv...' == Line 1265 has weird spacing: '...ed, in whole...' == Line 1266 has weird spacing: '...hat the above...' == (6 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 8348 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) == Missing Reference: '24' is mentioned on line 942, but not defined == Unused Reference: '2' is defined on line 1163, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1201, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 1205, 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) == Outdated reference: A later version (-06) exists of draft-ietf-nasreq-criteria-05 ** Downref: Normative reference to an Informational draft: draft-ietf-nasreq-criteria (ref. '6') -- No information found for draft-hiller-cdma2000-AAA - is the name correct? -- Possible downref: Normative reference to a draft: 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 2477 (ref. '10') ** Obsolete normative reference: RFC 2633 (ref. '11') (Obsoleted by RFC 3851) == Outdated reference: A later version (-09) exists of draft-ietf-pkix-ac509prof-06 -- 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' == Outdated reference: A later version (-04) exists of draft-ietf-smime-rcek-02 ** Obsolete normative reference: RFC 2559 (ref. '16') (Obsoleted by RFC 3494) Summary: 13 errors (**), 0 flaws (~~), 19 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Individual Contribution 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 AVP 89 6.13 DSAR-Target-Domain AVP 90 7.0 Result-Code AVP Values 91 7.1 Transient Failures 92 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 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 ROAMOPS Working Group has defined a set of requirements in [10] 124 to 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 Relay agents. Figure 1 127 provides an example of two Diameter peers establishing a Diameter 128 Security Association (DSA) through Relay agents. The participants of 129 a DSA are the peers where the DSA setup messages terminate. In this 130 example, the participants of the DSA would the NAS (access device), 131 and the Home Server. 133 mno.net mno.net xyz.net abc.com 134 +------+ <----> +------+ <----> +------+ <----> +------+ 135 | | TLS |Relay | IPSec |Relay | IPSec | Home | 136 | NAS | | | | | | | 137 | | | 1 | | 2 | |Server| 138 +------+ +------+ +------+ +------+ 139 <--------------------------------------------> 140 Diameter Security Association 142 Figure 1: Diameter Security Association 144 When one or more agents are used between two communicating Diameter 145 peers, the use of hop-by-hop security mechanisms (e.g. TLS, IPSec) 146 is unsuitable, since Diameter messages are processed at the 147 application layer at each agent. Therefore, an alternative mechanism 148 is required to protect portions of the message at the application 149 layer. 151 Allowing for a security association to be established through 152 Diameter relays allows the participants of the DSA to detect whether 153 protected AVPs have been modified en-route, and hides sensitive data 154 from intermediate agents. Furthermore, the Mobile IP and NASREQ 155 Working Groups have stated in [6, 7, 8] that non-repudiation of 156 Diameter data, such as Accounting related AVPs, is necessary. 158 Figure 2 provides an example of a message sent by an access device 159 (NAS), through Diameter relay agents, to its intended destination, 160 the home server. In this example, Relay 2 modifies the contents of 161 the foo AVP, perhaps due to mis-configuration, or maliciously. This 162 specification would allow the participants of the DSA to detect such 163 a problem, as long as the AVP being modified was protected. 165 (Request) (Request) (Request) 166 [AVP(foo)=x] [AVP(foo)=x] [AVP(foo)=y] 167 +------+ -----> +------+ -----> +------+ -----> +------+ 168 | | |Relay | |Relay | | Home | 169 | NAS | | | | | | | 170 | | | 1 | | 2 | |Server| 171 +------+ <----- +------+ <----- +------+ <----- +------+ 172 (Answer) (Answer) (Answer) 173 [AVP(foo)=b] [AVP(foo)=b] [AVP(foo)=a] 175 Figure 2: Diameter agent modifying AVP 177 This document defines the Diameter commands that are used to 178 establish a DSA through Diameter agents, and specifies how 179 encapsulating CMS objects [3] in Diameter AVPs can provide 180 authentication, integrity and confidentiality. The CMS object MAY 181 also be used to transport X.509 certificates and revocation lists. 183 Establishing a DSA through relay agents requires that the initiator 184 issue a Diameter Security Association Request (DSAR) message. In the 185 example provided in figure 1, NAS would issue the DSAR with the 186 Destination-Realm AVP set to abc.com. The Home Server would process 187 the request, and respond by issuing a Diameter Security Association 188 Answer (DSAA) message. If the DSAA message contains a Result-Code 189 indicating success, the DSA is established between the NAS and the 190 home server. 192 Once the DSA is established, the participants MAY apply digital 193 signatures to protect one or more AVP within a message. In the 194 example provided in Figure 2, the Foo AVP would be protected by the 195 digital signature, and any modification of the AVP by the relay 196 agents, would be detected when the signature validation algorithm 197 would fail by either participant. 199 1.2 Establishing Security Relationship through proxy agents 200 As previously discussed, proxy agents typically modify Diameter 201 messages to implement policy enforcement. An example of a proxy 202 server would be an aggregating server, which typically sits one 203 Diameter hop away from the access device, and enforces policy in 204 order to protect the access device from receiving AVPs that could 205 cause harm (e.g. excessive number of filters, unsupported tunneling 206 protocol). Although in theory such checks could be performed on the 207 access device, these devices are typically embedded systems, and not 208 easily configurable. The proxy agent's behavior, on the other hand, 209 is typically under control of the network operator. 211 Diameter messages between two participants of a DSA would fail 212 authentication if a proxy agent were to modify any protected AVPs. 213 Therefore proxy agents MUST NOT permit DSAs to be established through 214 it. 216 mno.net mno.net xyz.net abc.com 217 +------+ +------+ +------+ +------+ 218 | | |Proxy | |Relay | | Home | 219 | NAS | | | | | | | 220 | | |Agent | |Agent | |Server| 221 +------+ +------+ +------+ +------+ 222 -------------> 223 (DSAR) Destination-Realm = abc.com 225 <------------- 226 (DSAA) Result-Code = DIAMETER_CAN_ACT_AS_CMS_PROXY 228 -------------> 229 (PDSR) ESSR-Target-Domain = abc.com 231 ----------------------------> 232 (DSAR) Destination-Realm = abc.com 234 <---------------------------- 235 (DSAA) Result-Code = DIAMETER_SUCCESS 237 <------------- 238 (PDSA) Result-Code = DIAMETER_SUCCESS 240 Figure 3: Establishing Security through Proxy Agent 242 When an DSAR is received by a proxy agent, it has two options. First, 243 if MAY simply deny all DSA Setup Requests (DSAR) through it by 244 responding with the DSAA Result-Code AVP set to 245 DIAMETER_NO_CMS_THROUGH_PROXY. The access device can then determine 246 whether it is willing to provide service, based on its local policy. 248 Alternatively, it MAY reject the DSAR, but set the Result-Code AVP to 249 DIAMETER_CAN_ACT_AS_CMS_PROXY, informing the initiator of the DSAR 250 that it is a proxy agent, but is willing to establish the DSA on its 251 behalf. The DSAA MUST be signed by the proxy agent, and include its 252 certificate, to allow the access device to validate the originator of 253 the DSAA. At this point, the access device MUST determine whether the 254 proxy agent is a trusted agent, and it is willing to allow the agent 255 to provide such service. For instance, the access device MAY be 256 configured to ONLY accept DSAA with this result code from proxy 257 agents within its own domain. 259 Note that an access device MAY be configured to always issue a PDSR 260 to its aggregating proxy, reducing the number of round trips. 261 Similarly, an aggregating proxy MAY be configured to initiate an DSAR 262 regardless of whether a PDSR was sent by the access device. 264 Allowing the first hop agent to use establish the DSA with the home 265 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. Figure 4 shows an 278 example where the relay agent contacts the redirect agent to retrieve 279 the necessary information for it to communicate directly with the 280 home server. The response from the redirect agent MAY include the 281 certificates of the home servers, encoded within the CMS-Cert AVP. 283 +------+ 284 | | 285 | DRD | 286 | | 287 +------+ 288 ^ | 289 2. Request | | 3. Redirection 290 | | Notification 291 | v 292 +------+ ---------> +------+ <--------> +------+ 293 | | 1. Request | | 4. DSAR/DSAA | | 294 | NAS | | DRL | | HMS | 295 | | 6. Answer | | 5. Request/Answer | | 296 +------+ <--------- +------+ <--------> +------+ 297 mno.net mno.net abc.com 299 Figure 4: DSA Setup following redirect 301 The CMS specification allows for Diameter AVPs to be countersigned, 302 which MAY prove useful in business models that require both parties 303 to sign accounting data. This scheme provides some assurance that 304 both parties agreed to the accounting data, which MAY be used for 305 settlement purposes. 307 1.4 When to use DSAs 309 Given that asymmetric transform operations are expensive, access 310 devices and/or Diameter agents MAY wish to restrict establishment of 311 a DSA to cases where the participants belong to a different 312 administrative domain. 314 1.5 Who can authorize users 316 In this specification, we define how a Diameter Security Association 317 is established at the application layer to secure AVPs within a 318 message. However, it is important to note that one of participants 319 of a DSA (specifically the one in the home network) MUST belong to 320 the same realm as the user being authorized. This limitation will 321 prevent bigco.com from authorizing (or rather declining 322 authorization) for users at smallco.com. The realm of the 323 participants is found in the subjectAltName field of the Diameter 324 server's X.509 certificate. 326 1.6 Requirements language 327 In this document, the key words "MAY", "MUST", "MUST NOT", 328 "optional", "recommended", "SHOULD", and "SHOULD NOT", are to be 329 interpreted as described in [5]. 331 1.7 Advertising application support 333 Diameter nodes conforming to this specification MAY advertise support 334 by including the value of two (2) in the Auth-Application-Id or the 335 Acct-Application-Id AVP of the Capabilities-Exchange-Request and 336 Capabilities-Exchange-Answer command [1]. 338 2.0 AVP Format 340 The Diameter base protocol [1] details the AVP header, which includes 341 the 'P' bit, but does not specify how the 'P' bit is used. The 'P' 342 bit, known as the protected AVP bit, is used to indicate whether the 343 AVP is protected by a digital signature. When set, the AVP is 344 protected and the contents cannot be changed by agents without 345 detection. 347 0 1 2 3 348 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 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 | AVP Code | 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 |V M P r r r r r| AVP Length | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | Vendor-ID (opt) | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | Data ... 357 +-+-+-+-+-+-+-+-+ 358 Figure 5: Diameter AVP Header 360 All Diameter specifications MUST specify whether the 'P' bit can be 361 set or not, as is done in section 4.5 of [1] and section 6 below. 362 AVPs that are designed to be changed at each hop (such as the Proxy- 363 Info AVP) MUST NOT allow the 'P' bit to be set. 365 3.0 Key Management 367 For DSA origin authentication, CMS itself already provides sufficient 368 key management without the need for additional specification. 369 Basically, the originating Diameter node signs and includes whatever 370 certificates are necessary for validation of the digital signature. 372 However, for encryption of AVPs more work is needed. In order to be 373 able to encrypt AVPs for a recipient, the originating Diameter node 374 must have a copy of the recipient's public key. There are many well- 375 known key retrieval schemes (e.g. using LDAP [16]), however, in order 376 to simplify Diameter implementations a specific Diameter key 377 distribution mechanism is defined here. 379 Another issue that must be addressed is how a Diameter node is to 380 "know" that certain AVPs are required to be secured within CMS 381 objects. This is communicated in the Diameter Security Association 382 Request/Answer messages, listed in section 4.0. 384 Finally, this section addresses the certificate profile to be used 385 for this Diameter application, which is a simplified profile of [4]. 387 3.1 Usage Scenario 389 When a Diameter node is about to send a message, it must determine 390 whether a DSA should be established or not. We assume the Diameter 391 node knows the user's realm, perhaps through the User-Name AVP. 393 In the present discussion we assume that the Diameter node has not 394 cached any information. Where information can be cached this is 395 noted. 397 We use Diameter Security Association Request (DSAR) and Diameter 398 Security Association Answer (DSAA) messages to establish a DSA, which 399 specifies which AVPs should be authenticated and/or encrypted, as 400 well as which public key(s) to use. 402 The originating node sends the DSAR message to a server in the 403 destination realm. The DSAR message contains: 405 - the realm part of the user's NAI 406 - the list of direct trust CA's that the originating Diameter 407 node has configured into it for certificate validation. A 408 "direct trust" CA is one that the node is willing to use as the 409 "top" of a certificate chain, sometimes confusingly known as a 410 "root CA." 411 - a list of AVPs that expected to be protected (and how) for this 412 realm 413 - (optionally) a flag indicating that the originating Diameter 414 node wishes to receive certificate status information (using 415 OCSP messages) in which case a nonce to be used by the 416 destination Diameter node in OCSP requests MAY also be 417 supplied. See [9] for details of the certificate status 418 protocol and messages. 420 The destination node returns the DSAA message which contains: 422 - TTL for this SA (seconds) 423 - a chain of CA certificates (possibly empty) 424 - public key certificates for the AAA servers in the realm, all 425 of which MUST validate up to one of the CA's contained in the 426 ESSR message, via the chain of CA certificates above; 427 - a list of AVPs that expected to be protected (and how) for this 428 realm 429 - (optionally, if nonce received and OCSP supported) a list of 430 OCSP responses for the certificates in question, each of which 431 uses the nonce from the ESSR message 433 [Issue: If one OCSP responder is used, do we need to append to the 434 nonce for each request?] 436 The originating Diameter node now has to check the response. Any 437 failure results in error messages and auditing and not sending the 438 Diameter message. 440 Checks: 442 - the certificate chain selected is cryptographically correct, 443 passes the (relevant parts of the) rfc2459 path validation 444 algorithm and terminates at a CA mentioned in the DSAR message 445 - the realm part of the user's NAI must occur as a subjectAltName 446 (with the dNSName option) in the AAA server's certificate. This 447 dNSName MUST be of the form "Diameter-." where 448 is the FQDN's domain component and can be 449 anything (e.g. "Diameter-1.baltimore.com", "Diameter- 450 west.sun.com") chosen by the AAA server administrator. 451 - the DSAA message MUST be digitally signed and the signature 452 MUST be validated and the signer's certificate chain MUST 453 terminate as a CA mentioned in the DSAR message 455 If certificate status (revocation) is an issue for the Diameter 456 node, then the DSAR message MAY contain a nonce value. The idea 457 is that the sender of the DSAA makes OCSP requests on behalf of 458 the Diameter node and returns the OCSP responses to the 459 Diameter node as part of the DSAR message. The use of the nonce 460 value ensures that the sender of the DSAA cannot return cached 461 or otherwise fake OCSP responses to the Diameter node. 463 The nonce value is to be (the beginning of) the nonce in the 464 OCSP response. 466 [Issue The reason for "beginning" above is that an OCSP 467 responder might produce an error if presented with the same 468 nonce more than once.] 470 The DSAR MAY be signed. If the originating node has a private 471 key and protection expectations for AVPs are specified, then 472 the DSAR SHOULD be signed. 474 The DSAA MUST be signed by a Diameter agent or server within 475 the user's realm, to prevent an intermediate node from 476 modifying the protection expectations for AVPs. 478 If confidentiality or digital signature is required, then the 479 originating node prepares the CMS related AVPs as required. 481 3.2 Certificate Requirements 483 Certificates used for the purposes of Diameter MUST conform to the 484 PKIX profile [4], and MUST also include a Diameter node's FQDN, which 485 is typically added in the Host-Name AVP [1], as one of the values of 486 the subjectAltName extension of the Certificate. The FQDN is to be 487 encoded as an dNSName within the subjectAltName. 489 For Diameter nodes (capable of acting as recipients for 490 confidentiality), the FQDN MUST be of the form "Diameter- 491 .". Other Diameter nodes MAY use this naming scheme. Note 492 that this naming constraint is for PKI purposes only, and in no way 493 restricts a Diameter's host name. 495 These names are used for two purposes: 497 1. Where a Diameter node is verifying a signature it needs to be 498 able to compare the identity of the signer against the identity 499 in the Host-Name AVP. 501 2. Where a Diameter node is encrypting AVPs, it needs to be able 502 to ensure that it uses a public key for the intended recipient. 503 This requires comparing the identity in a Certificate against 504 the FQDN of the intended recipient (which is assumed to be 505 known). 507 In either case, the presence of the required FQDN as an dNSName value 508 in the subjectAltName extension of a verified public key certificate 509 satisfies the matching requirement. 511 Note that there MAY also be other values in the subjectAltName 512 extension, (either using dNSName or other elements of the CHOICE), 513 these can be safely ignored, but implementations MUST be able to 514 handle their presence. 516 Note also that the PKIX profile [4], section 4.1.2.6, specifies the 517 rules for the relationship between the subjectAltName extension and 518 the subject field of public key certificates. 520 [Issue: Future versions of this draft may specify a restricted 521 profile of [4] in order to simplify implementation.] 523 3.3 Algorithms 525 For all uses of CMS in this specification the mandatory to implement 526 algorithms are as follows: 528 - Asymmetric: RSA 529 - Hashing: SHA-1 530 - Signature: RSAwithSHA1 531 - Symmetric Encryption: 3DES 533 At some point in future, AES will replace 3DES. 535 3.4 Reuse of CMS Content Encryption Keys 537 Once a CMS-Encrypted-Data AVP has been exchanged between two Diameter 538 peers, then they share a symmetric cryptographic key (the content 539 encryption key) which can be used to encrypt further Diameter AVPs 540 between the peers by using the scheme specified in [15]. The peers 541 MUST first take part in an DSAR/DSAA exchange in order to distribute 542 the required asymmetric keys. 544 Note that the use of symmetric keys does not provide "non- 545 repudiation". 547 [15] leaves open some issues, namely how to handle loss of a shared 548 secret (say following a peer re-boot) and for how long to continue to 549 use a shared secret (the maximum number of decryptions required). 551 Where a Diameter node receives a CMS-Encrypted-Data AVP, but doesn't 552 have the required shared secret, that node should return the 553 DIAMETER_KEY_UNKNOWN error message. The peer may then use the 554 DSAR/DSAA exchange to rebuild their Diameter security association. 555 [ed: removed the text on using a cached asymmetric key to re- 556 establish the SA, since it really wasn't clear how that would work] 558 In [15], the default value for the maximum number of decryptions 559 allowed (CEKMaxDecrypts) when re-using a content encryption key is 560 100. In general this default SHOULD be used, but if a Diameter node 561 "knows" that more than one CMS-Encrypted-Data AVP will be exchanged 562 between the nodes (based on the Expected-Encrypted-AVP settings 563 exchanged during the DSAR/DSAA exchange) then the CEKMaxDecrypts 564 setting MAY be set higher. Diameter nodes MUST be able to support a 565 maxDecrypts setting of 1000. 567 [Issue: Are there reasonable expectations for the highest MUST 568 support for maxDecrypts? Does the CMS protocol allow for time based 569 expiration as opposed to number of encryptions?] 571 4.0 Command-Codes Values 573 This section defines new Command-Code [1] values that MUST be 574 supported by all Diameter implementations that conform to this 575 specification. The following Command Codes are currently defined in 576 this document: 578 Command-Name Abbrev. Code Reference 579 -------------------------------------------------------- 580 Diameter-Security- DSAR 304 4.1 581 Association-Request 582 Diameter-Security- DSAA 304 4.2 583 Association-Answer 584 Proxy-Diameter-Security- PDSR 305 4.3 585 Association-Request 586 Proxy-Diameter-Security- PDSA 305 4.4 587 Association-Answer 589 4.1 Diameter-Security-Association-Request 591 The Diameter-Security-Association-Request command, indicated by the 592 Command-Code field set to 304 and the 'R' bit set in the message 593 flags field, is sent by a Diameter node to establish a Diameter 594 Security Association. 596 Message Format 597 ::= < Diameter-Header: 304, REQUEST > 598 { Origin-Host } 599 { Origin-Realm } 600 { Destination-Realm } 601 + { Local-CA-info } 602 { Auth-Application-Id } 603 * { OCSP-Request } 604 [ Destination-Host ] 605 * [ Expected-Signed-AVP ] 606 * [ Expected-Encrypted-AVP ] 607 * [ OCSP-Nonce ] 608 0*1[ CMS-Signed-Data ] 609 [ Origin-State-Id ] 610 * [ AVP ] 611 * [ Proxy-Info ] 612 * [ Route-Record ] 614 4.2 Diameter-Security-Association-Answer 616 The Diameter-Security-Association-Answer command, indicated by the 617 Command-Code field set to 304, with the 'R' bit in the Command Flags 618 cleared, in response to a DSAR. 620 Message Format 622 ::= < Diameter-Header: 304 > 623 { Origin-Host } 624 { Origin-Realm } 625 0*1{ CA-Chain } 626 + { AAA-Server-Certs } 627 * { OCSP-Responses } 628 { Destination-Host } 629 { Auth-Application-Id } 630 * [ Expected-Signed-AVP ] 631 * [ Expected-Encrypted-AVP ] 632 [ CMS-Signed-Data ] 633 [ Origin-State-Id ] 634 * [ AVP ] 635 * [ Proxy-Info ] 636 * [ Route-Record ] 638 4.3 Proxy-Diameter-Security-Assocation-Request 640 The Proxy-Diameter-Security-Association-Request command, indicated by 641 the Command-Code field set to 305 and the 'R' bit set in the Command 642 Flags field, is sent by a Diameter node to request that a downstream 643 proxy establishes an Security Association with a server in a given 644 domain on its behalf. 646 Message Format 648 ::= < Diameter-Header: 304, REQUEST > 649 { Origin-Host } 650 { Origin-Realm } 651 { Destination-Realm } 652 { Auth-Application-Id } 653 { DSAR-Target-Domain } 654 0*1[ CMS-Signed-Data ] 655 [ Origin-State-Id ] 656 * [ AVP ] 657 * [ Proxy-Info ] 658 * [ Route-Record ] 660 4.4 Proxy-Diameter-Security-Association-Answer 662 The Proxy-Diameter-Security-Association-Answer command, indicated by 663 the Command-Code field set to 305 and the 'R' bit cleared in the 664 Command Flags field, is sent by a Diameter node in response to an 665 PDSR message. 667 Message Format 669 ::= < Diameter-Header: 304 > 670 { Origin-Host } 671 { Origin-Realm } 672 { Destination-Host } 673 { Auth-Application-Id } 674 * [ Expected-Signed-AVP ] 675 * [ Expected-Encrypted-AVP ] 676 0*1[ CMS-Signed-Data ] 677 [ Origin-State-Id ] 678 * [ AVP ] 679 * [ Proxy-Info ] 680 * [ Route-Record ] 682 5.0 Diameter Security Association Message Flow 684 This section contains an example of a NAS in domain xyz.com, 685 communicating with its local relay agent, which in turn communicates 686 with a server in ABC.COM's network. In the following example, once 687 the initial capabilities exchange is complete, the NAS receives a 688 request for access from alice@abc.com, which causes the DSA setup to 689 be initiated, followed by the application-specific authentication 690 request. 692 Although the example doesn't specifically use bi-directional CMS 693 authentication and encryption, this feature is supported. 695 +-------+ +-------+ +---------+ 696 | NAS | | Relay | | abc.com | 697 | | | Agent | |Home Srv | 698 +-------+ +-------+ +---------+ 699 | | | 700 |CER apps 1, 2 | | 701 (a) |------------------->| | 702 |CAA apps -1 | | 703 (b) |<-------------------| | 704 | . |CER apps 1, 2 | 705 (c) | |<-------------------| 706 | |CEA apps -1 | 707 (d) | |------------------->| 708 ->| User alice@abc.com | | 709 (e) | Requests Access | | 710 | | | 711 | DSAR | | 712 | Dest-Realm=abc.com | | 713 | CMS-Cert | | 714 (f) |--------------------+------------------->| 715 | | DSAA | 716 | | Origin-Host=foo | 717 | | CMS-Cert | 718 (g) |<-------------------+--------------------| 719 | Auth-Request + | | 720 | CMS-Signed-Data | | 721 | Dest-Host=foo | | 722 (h) |--------------------+------------------->| 723 | | Auth-Answer + | 724 | | CMS-Encrypted-Data | 725 (i) |<-------------------+--------------------| 726 Figure 6: Example of a DSA Setup 728 (a) NAS sends a CER message to its relay agent indicating that it 729 supports applications 1 (NASREQ) and 2 (CMS Security). 731 (b) The proxy server sends a CEA message to the NAS indicating 732 that it is a relay supporting all Diameter applications. 734 (c) ABC.COM's Home Server sends a CER message to a proxy server 735 indicating that it supports applications 1 (NASREQ) and 2 (CMS 736 Security). 738 (d) The proxy server sends a CEA message to ABC.COM's Home Server 739 indicating that it is a relay supporting all Diameter 740 applications. 742 (e) The NAS receives a request for access from a user 743 (alice@abc.com). 745 (f) The NAS issues an DSAR message, with the Destination-Realm AVP 746 set to abc.com, and its certificate in the CMS-Cert AVP. The 747 DSAR includes the set of AVPs that the NAS expects to be 748 encrypted, in the event that the home server returns messages 749 that contain these AVPs. 751 (g) ABC.COM's Home Server processes the DSAR message, and replies 752 with the DSAA message. The DSAA also includes the set of AVPs 753 that the home server is expecting to be authenticated, as well 754 as its certificate in the CMS-Cert AVP. 756 (h) The NAS issues an authentication request with the 757 Destination-Host AVP set to the value of the Origin-Host AVP 758 in the DSAA. The message includes the CMS-Signed-AVP, which 759 authenticates the AVPs that were requested by the Home Server 760 in the DSAA. 762 (i) The Home Server successfully authenticates the user, and 763 returns a reply, which includes the CMS-Encrypted-Data AVP, 764 whose contents include the AVPs that were specified by the NAS 765 in the DSAR. 767 6.0 CMS Security AVPs 769 This section contains AVPs that are used to establish a Diameter 770 Security Association, and to transport CMS objects. 772 +---------------------+ 773 | AVP Flag rules | 774 |----+-----+----+-----|----+ 775 AVP Section | | |SHLD| MUST|MAY | 776 Attribute Name Code Defined Value Type |MUST| MAY | NOT| NOT|Encr| 777 -----------------------------------------|----+-----+----+-----|----| 778 AAA-Server-Certs 351 6.6 OctetString| M | P | | V | N | 779 AVP-Code 352 6.11 Unsigned32 | M | P | | V | N | 780 CA-Chain 353 6.8 OctetString| M | P | | V | N | 781 CA-Name 349 6.4.1 OctetString| M | P | | V | N | 782 CMS-Cert 354 6.3 OctetString| M | | | P,V | N | 783 CMS-Encrypted- 355 6.2 OctetString| M | P | | V | N | 784 Data | | | | | | 785 CMS-Signed-Data 310 6.1 OctetString| M | | | P,V | N | 786 Key-Hash 350 6.4.2 OctetString| M | P | | V | N | 787 DSAR-Target- 360 6.13 OctetString| M | P | | V | N | 788 Domain | | | | | | 789 Expected-Signed- 356 6.9 Grouped |M,P | | | V | N | 790 AVP | | | | | | 791 Expected- 357 6.10 Grouped |M,P | | | V | N | 792 Encrypted-AVP | | | | | | 793 Local-CA-Info 348 6.4 Grouped | M | P | | V | N | 794 OCSP-Nonce 358 6.5 OctetString| M | P | | V | N | 795 OCSP-Request 361 6.12 Unsigned32 | M | P | | V | N | 796 OCSP-Responses 359 6.7 OctetString| M | P | | V | N | 798 6.1 CMS-Signed-Data AVP 800 The CMS-Signed-Data AVP (AVP Code 310) is of type OctetString and 801 contains the Basic Encoding Rules (BER) encoding of a CMS object [3] 802 of type ContentInfo. The profile of CMS algorithm and structure usage 803 is as specified in the S/MIME v3 message specification [11]. This 804 means that where a set of AVPs is protected using CMS, the set MUST 805 first be encoded according to MIME encoding rules specified below. 806 This method of encapsulating AVPs allows existing S/MIME toolkits to 807 be used without changes in order to provide authentication within the 808 Diameter application layer. 810 To package a set of AVPs as a MIME type, AVPs with the 'P' bit are 811 first concatenated in the order in which they occur in the Diameter 812 message, including padding. The result is used as input into the 813 signing process. Note that the AVPs themselves are not encapsulated 814 within the CMS-Signed-Data AVP. Instead, the digest value within the 815 SignedData structure contains the digest produced in the signature 816 process. 818 Multiple Diameter entities MAY add their signatures to an existing 819 CMS-Signed-Data AVP using the countersignature attribute, defined in 820 section 11.4 of [3]. The countersignature attribute requires that the 821 signatures occur sequentially, meaning that each signature covers the 822 existing signatures in the CMS object. 824 The initial signature, and any additional countersignatures, MUST 825 cover the exact same set of AVPs, in the order they are present in 826 the message. 828 Note that the CMS-Signed-Data AVP MUST NOT be used in the generation 829 of the signature, and therefore MUST NOT have its 'P' bit set. 831 If a receiver detects that the contents of the CMS-Signed-Data AVP 832 are invalid, it SHOULD return the new Result-Code AVP value defined 833 in section 7.0. 835 When AVPs are to be both encrypted and signed, the CMS-Encrypted-Data 836 AVP MUST be created first. The resulting CMS object MUST then be MIME 837 encoded producing an application/pkcs7-mime MIME type which is then 838 used as the content of the EnvelopedData. This means that signing is 839 "outside" encryption. 841 The eContent field of the EncapsulatedContentInfo structure MUST be 842 absent since the authentication covers data outside of the object. 843 The signature is computed over all AVPs with the 'P' bit enabled. The 844 order of the AVPs MUST be preserved and the computation begins with 845 the first AVP immediately following the Diameter header. If the 846 signature cannot be verified correctly, a response with the Result- 847 Code AVP set to DIAMETER_INVALID_AUTH [1] MUST be returned. 849 No more than one CMS-Signed-Data AVP MUST be present in any given 850 Diameter message. 852 6.2 CMS-Encrypted-Data AVP 854 The CMS-Encrypted-Data AVP (AVP Code 355) is of type OctetString and 855 contains the Basic Encoding Rules (BER) encoding of a CMS object [3] 856 of type ContentInfo. 858 The entire AVP MUST be input to the encryption process, in network 859 byte order, including any padding. All AVPs to be encrypted are 860 concatenated, and the encryptor is free to order AVPs in whatever way 861 it chooses. The value is then encrypted and used as the value of the 862 EncryptedContent field within CMSEnvelopedData. 864 If a receiver detects that the contents of the CMS-Data AVP is 865 invalid, it SHOULD return the new Result-Code AVP value defined in 866 section 7.0. 868 When AVPs are to be both encrypted and authenticated, the CMS- 869 Encrypted-Data AVP MUST be created first. 871 Where AVPs are encapsulated within a CMS-Encrypted-Data AVP, the 872 eContentType of the EncapsulatedContentInfo MUST be id-data [11]. 874 CMS-Encrypted-Data MAY contain more than one CMS object, that is, 875 implementations MUST be able to add a new CMS-Encrypted-Data AVP 876 value and also MUST be able to decrypt all CMS-Encrypted-Data AVP 877 values which are encrypted for them. 879 When a conforming implementation receives a Diameter message which 880 contains encrypted AVPs within a CMS EnvelopedData, the recipient 881 MUST check to see if it is on the list of recipients specified in the 882 RecipientInfos of the EnvelopedData. If not, the recipient MAY choose 883 to process the message or indicate an error. If the recipient is in 884 the RecipientInfos and an error occurs during decryption, then the 885 recipient MUST indicate an error. 887 Diameter nodes SHOULD implement content encryption key re-use (see 888 section 3.4 above). 890 Zero or more CMS-Encrypted-Data AVP MAY be present in any Diameter 891 message. 893 6.3 CMS-Cert AVP 895 The CMS-Cert AVP (AVP Code 354) is of type OctetString and contains a 896 "certs-only" CMS structure which is a degenerate form of CMS 897 structure containing only PKI related information (see section 3.6 of 898 [11] for details of the CMS certs-only structure). 900 The CMS-Cert AVP contains one or more public key certificates 901 (Certificate) and MAY optionally contains attribute certificates 902 (AttributeCertificate) as allowed by CMS. Other legacy formats 903 supported by CMS MUST NOT be used. 905 Support for use of the Certificate structure is REQUIRED, while 906 implementations MAY support use of the AttributeCertificate structure 907 as defined in the PKIX attribute certificate profile [12]. The latter 908 allows Diameter implementations to include a certificate from a 909 trusted party that they are authorized to emit the AVPs contained in 910 the message. 912 This use of the CMS-Cert AVP can be used to "push" public key and 913 attribute certificates and CRLs using Diameter, which MAY be useful 914 in environments where repositories (e.g. LDAP servers) are either 915 not used or not available (e.g. due to crossing a domain boundary). 916 Conforming implementations MUST be able to emit a certs-only CMS 917 structure which contains relevant PKI related information and MUST be 918 able to process a CMS-Cert AVP which contains a certs-only CMS 919 structure. Of course, the recipient of such a certs-only CMS 920 structure SHOULD NOT use the PKI related information without first 921 verifying it, e.g. by checking that issuer's are trusted, signatures 922 verify etc. 924 A CRL [4] MAY also be provided in the crls field of the SignedData, 925 which MAY be used to assist in determining whether a certificate has 926 been revoked. Optionally, the Diameter node MAY check the status of 927 certificates using another mechanism, such as Online Certificate 928 Status Protocol (OCSP) [9]. 930 6.4 Local-CA-Info AVP 932 The Local-CA-Info AVP (AVP Code 348) is of type Grouped. The Grouped 933 Data field has the following ABNF grammar: 935 Local-CA-Info ::= < AVP Header: 348 > 936 { CA-Name } 937 { Key-Hash } 939 6.4.1 CA-Name AVP 941 The CA-Name AVP (AVP Code 349) is of type OctetString, encoded in the 942 UTF-8 [24] format. The AVP contains the DN (in LDAP string syntax) of 943 the Certificate Authority, e.g. "CN=CA;O=Baltimore 944 Technologies;C=IE". 946 6.4.2 Key-Hash AVP 948 The Key-Hash AVP (AVP Code 350) is of type OctetString, and contains 949 a SHA-1 hash of the key. 951 The hash MUST be calculated over the representation of the CA public 952 key which would be present in an X.509 public key certificate, 953 specifically, the input for the hash algorithm MUST be the DER 954 encoding of a SubjectPublicKeyInfo representation of the key. Note: 955 This includes the AlgorithmIdentifier as well as the BIT STRING. The 956 rules given in [4] for encoding keys MUST be followed. 958 Since this AVP is used for indexing and not for security (since 959 Diameter nodes SHOULD validate certificates), there is no need to 960 support more than one hash algorithm here. 962 6.5 OCSP-Nonce AVP 964 The OCSP-Nonce AVP (AVP Code 358) is of type OctetString, and 965 contains a random value (RECOMMENDED 128 bits) generated by the 966 Diameter node. 968 6.6 AAA-Server-Certs AVP 970 The AAA-Server-Certs AVP (AVP Code 351) is of type OctetString and 971 contains the certificates of the AAA Servers in the home domain. 972 Note: this AVP contains no CA certificates, just those for AAA 973 servers. 975 6.7 OCSP-Responses AVP 977 The OCSP-Responses AVP (AVP Code 359) is of type OctetString, and 978 contains an OCSP response message from an OCSP responder. If the 979 OCSP-Request AVP indicating a response was required in the 980 corresponding request message, the OCSP-Response AVP MUST be present. 981 Furthermore, the OCSP-Request AVP MAY request a fresh OCSP response 982 message, which MUST also include the OCSP-Nonce AVP. 984 6.8 CA-Chain AVP 986 The CA-Chain AVP (AVP Code 353) is of type OctetString, and contains 987 a certificate chain, from one of the nominated locally trusted CAs 988 down to the (one and only) CA which has issued the end entity 989 certificates in the AAA-Server-Certs AVP. 991 To produce this AVP in an DSAA message, one (and only one) of the 992 Local-CA-info values from the corresponding DSAR message is selected 993 (call this the "top" CA for the purposes of this description). This 994 AVP then contains a certificate path (in order) from the "top" CA 995 down to the (one and only) CA which has issued all the end entity 996 certificates in the AAA-Servers-AVP. The (typically self-signed), 997 certificate of the "top" CA MAY be included, or MAY be omitted. 999 [Issue: Whether the "top" CA cert should be included or not can be 1000 determined later.] 1002 6.9 Expected-Signed-AVP AVP 1004 The Expected-Signed-AVP AVP (AVP Code 356) is of type Grouped. The 1005 Grouped Data field has the following ABNF grammar: 1007 Expected-Signed-AVP ::= < AVP Header: 356 > 1008 { AVP-Code } 1009 [ Vendor-Id ] 1011 The Expected-Signed-AVP AVP contains an AVP code, which if sent by 1012 the peer, MUST be authenticated via the CMS-Signed-Data AVP. 1013 Vendor-Specific AVPs are represented by including the optional 1014 Vendor-Id AVP. 1016 If this AVP is present in the DSAR or DSAA, it MUST be authenticated 1017 using the CMS-Signed-Data AVP. 1019 6.10 Expected-Encrypted-AVP AVP 1021 The Expected-Encrypted-AVP AVP (AVP Code 357) is of type Grouped. 1022 The Grouped Data field has the following ABNF grammar: 1024 Expected-Encrypted-AVP ::= < AVP Header: 357 > 1025 { AVP-Code } 1026 [ Vendor-Id ] 1028 The Expected-Encrypted-AVP AVP contains an AVP code, which if sent by 1029 the peer, MUST be encrypted in the CMS-Encrypted-Data AVP. Vendor- 1030 Specific AVPs are represented by including the optional Vendor-Id 1031 AVP. 1033 If this AVP is present in the DSAR or DSAA, it MUST be authenticated 1034 using the CMS-Signed-Data AVP. 1036 6.11 AVP-Code AVP 1038 The AVP-Code AVP (AVP Code 352) is of type Unsigned32, and contains 1039 the AVP Code of the AVP that is to be authenticated or encrypted. 1041 6.12 OCSP-Request AVP 1043 The OCSP-Request AVP (AVP Code 361) is of type Unsigned32, and 1044 specifies whether the sender wishes to receive an OCSP response. The 1045 following values are defined: 1047 NO_OCSP_RESPONSE 0 1048 The sender does not wish to receive an OCSP Response. 1050 OCSP_RESPONSE 1 1051 The sender wishes to receive an OCSP Response, and is willing 1052 to accept a stale response. 1054 OCSP_FRESH_RESPONSE 2 1055 The sender wishes to receive a fresh OCSP Response. When this 1056 value is set, the OCSP-Nonce AVP MUST be present. 1058 6.13 DSAR-Target-Domain AVP 1060 The DSAR-Target-Domain AVP (AVP Code 360) is of type OctetString, and 1061 contains the Destination-Realm of the resulting DSAR sent by a non- 1062 transparent proxy. 1064 7.0 Result-Code AVP Values 1066 This section defines new Result-Code [1] values that MUST be 1067 supported by all Diameter implementations that conform to this 1068 specification. 1070 7.1 Transient Failures 1072 Errors that fall within the transient failures category are used to 1073 inform a peer that the request could not be satisfied at the time it 1074 was received, but MAY be able to satisfy the request in the future. 1076 DIAMETER_KEY_UNKNOWN 4007 1077 This error code is returned when a CMS-Signed-Data or CMS- 1078 Encrypted-Data AVP is received that was generated using a key 1079 that is not locally recognized. This error could be caused if 1080 one of the participants of a DSA lost a previously agreed upon 1081 key, perhaps as a result of a reboot. 1083 7.2 Permanent Failures 1085 Errors that fall within the permanent failures category are used to 1086 inform the peer that the request failed, and should not be attempted 1087 again. 1089 DIAMETER_INVALID_CMS_DATA 5018 1090 This error code is returned when a CMS-Data AVP is received 1091 with an invalid ContentInfo object. 1093 DIAMETER_NO_CMS_THROUGH_PROXY 5019 1094 This error code is returned when a non-transparent proxy 1095 receives an DSAR message to state that it doesn't allow a DSA 1096 through it since it plans to modify AVPs. 1098 DIAMETER_CAN_ACT_AS_CMS_PROXY 5020 1099 This error code is returned when a non-transparent proxy 1100 receives an DSAR message, and although it doesn't allow a DSA 1101 through it, it is willing to initiate a DSA on behalf of the 1102 access device. 1104 8.0 IANA Considerations 1106 This section contains the namespaces that have either been created in 1107 this specification, or the values assigned to existing namespaces 1108 managed by IANA. 1110 8.1 Command Codes 1112 This specification assigns the value 304 from the Command Code 1113 namespace defined in [1]. See section 4.0 for the assignment of the 1114 namespace in this specification. 1116 8.2 AVP Codes 1118 This specification assigns the values 348-361 from the AVP Code 1119 namespace defined in [1]. See section 6.0 for the assignment of the 1120 namespace in this specification. 1122 8.3 Result-Code AVP Values 1124 This specification assigns the values 4007, 5018-5020 from the 1125 Result-Code AVP (AVP Code 268) value namespace defined in [1]. See 1126 section 7.0 for the assignment of the namespace in this 1127 specification. 1129 8.4 Application Identifier 1131 This specification assigns the value two (2) to the Application 1132 Identifier namespace defined in [1]. See section 1.6 for more 1133 information. 1135 8.5 OCSP-Request AVP Values 1137 As defined in Section 6.12, the OCSP-Request AVP (AVP Code 361) 1138 defines the values 0-2. All remaining values are available for 1139 assignment via IETF Consensus [12]. 1141 9.0 Security Considerations 1143 This document describes how CMS security can be achieved in the 1144 Diameter protocol by allowing S/MIME Cryptographic Message Syntax [3] 1145 objects to be carried as a Diameter AVP. 1147 Section 6.3 states that a certificate received in a CMS-Cert AVP 1148 SHOULD NOT be used prior to cert verification. In most cases, the 1149 verification will be according to the rules specified in [4], 1150 however, some communities have indicated that they wish to be allowed 1151 to specify alternative certificate verification mechanisms, hence the 1152 "SHOULD NOT" rather than the more typical "MUST NOT". The authors do 1153 however strongly RECOMMEND that the verification procedures specified 1154 in [4] are always applied, regardless of whatever other verification 1155 mechanisms are in use. 1157 10.0 References 1159 [1] P. Calhoun, H. Akhtar, J. Arkko, E. Guttman, A. Rubens, "Diame- 1160 ter Base Protocol", draft-ietf-aaa-diameter-05.txt, IETF work in 1161 progress, June 2001. 1163 [2] Kaufman, Perlman, Speciner, "Network Security: Private Communi- 1164 cations in a Public World", Prentice Hall, March 1995, ISBN 0- 1165 13-061466-1. 1167 [3] R. Housley, "Cryptographic Message Syntax", RFC 2630, June 1999. 1169 [4] Housley, Ford, Polk, Solo, "Internet X.509 Public Key Infras- 1170 tructure Certificate and CRL Profile", RFC 2459, January 1999. 1172 [5] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1173 Levels", BCP 14, RFC 2119, March 1997. 1175 [6] M. Beadles, D. Mitton, "Criteria for Evaluating Network Access 1176 Server Protocols", draft-ietf-nasreq-criteria-05.txt, IETF work 1177 in progress, June 2000. 1179 [7] T. Hiller et al., "Cdma2000 Wireless Data Requirements for AAA", 1180 draft-hiller-cdma2000-AAA-02.txt, IETF work in progress, Sep- 1181 tember 2000. 1183 [8] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, 1184 Authorization, and Accounting Requirements". RFC 2977. October 1185 2000. 1187 [9] Myers, Ankney, Malpani, Galperin, Adams, "X.509 Internet Public 1188 Key Infrastructure Online Certificate Status Protocol (OCSP)", 1189 RFC 2560, June 1999. 1191 [10] Aboba, Zorn, "Criteria for Evaluating Roaming Protocols", RFC 1192 2477, January 1999. 1194 [11] B. Ramsdell, "S/MIME v2 Message Specification", RFC2633, June 1195 1999. 1197 [12] S. Farrell, R. Housley, "An Internet Attribute Certificate Pro- 1198 file for Authorization", draft-ietf-pkix-ac509prof-06.txt, IETF 1199 work in progress, January 2001. 1201 [13] P. Calhoun, W. Bulley, G. Zorn, "Diameter NASREQ Application", 1202 draft-ietf-aaa-Diameter-nasreq-05.txt, IETF work in progress, 1203 June 2001. 1205 [14] P. Calhoun, C. Perkins, "Diameter Mobile IP Application", 1206 draft-ietf-aaa-Diameter-mobileip-05.txt, IETF work in progress, 1207 June 2001. 1209 [15] Farrell, Turner, "Reuse of CMS Content Encryption Keys", draft- 1210 ietf-smime-rcek-02.txt, IETF work in progress, May 2001. 1212 [16] Boyen, Howes, Richard, "Internet X.509 Public Key Infrastructure 1213 Operational Protocols - LDAPv2", RFC 2559, April 1999. 1215 11.0 Acknowledgements 1217 The authors would also like to acknowledge the following people for 1218 their contribution in the development of this specification: 1220 Bernard Aboba, Jari Arkko and Steven Bellovin 1222 12.0 Authors' Addresses 1224 Questions about this memo can be directed to: 1226 Pat R. Calhoun 1227 Network and Security Research Center, Sun Labs 1228 Sun Microsystems, Inc. 1229 15 Network Circle 1230 Menlo Park, California, 94025 1231 USA 1233 Phone: +1 650-786-7733 1234 Fax: +1 650-786-6445 1235 E-mail: pcalhoun@eng.sun.com 1237 Stephen Farrell 1238 Baltimore Technologies 1239 39 Parkgate Street, 1240 Dublin 8, 1241 IRELAND 1243 Phone: +353-1-881-6000 1244 Fax: +353-1-881-7000 1245 E-Mail: stephen.farrell@baltimore.ie 1247 William Bulley 1248 Merit Network, Inc. 1249 Building One, Suite 2000 1250 4251 Plymouth Road 1251 Ann Arbor, Michigan, 48105-2785 1252 USA 1254 Phone: +1 734-764-9993 1255 Fax: +1 734-647-5185 1256 E-mail: web@merit.edu 1258 13.0 Full Copyright Statement 1260 Copyright (C) The Internet Society (2001). All Rights Reserved. 1262 This document and translations of it may be copied and furnished 1263 to others, and derivative works that comment on or otherwise 1264 explain it or assist in its implementation may be prepared, copied, 1265 published and distributed, in whole or in part, without restric- 1266 tion of any kind, provided that the above copyright notice and 1267 this paragraph are included on all such copies and derivative 1268 works. However, this docu- ment itself may not be modified in any 1269 way, such as by removing the copyright notice or references to the 1270 Internet Society or other Inter- net organizations, except as needed 1271 for the purpose of developing Internet standards in which case 1272 the procedures for copyrights defined in the Internet Standards pro- 1273 cess must be followed, or as required to translate it into languages 1274 other than English. The limited permis- sions granted above are 1275 perpetual and will not be revoked by the Internet Society or 1276 its successors or assigns. This document and the information con- 1277 tained herein is provided on an "AS IS" basis and THE INTERNET 1278 SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRAN- 1279 TIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WAR- 1280 RANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 1281 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1282 FOR A PARTICULAR PURPOSE." 1284 14.0 Expiration Date 1286 This memo is filed as and 1287 expires in December 2001.