idnits 2.17.1 draft-calhoun-diameter-strong-crypto-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 11 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 12 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 19 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 508 has weird spacing: '... copied and ...' == Line 509 has weird spacing: '...s, and deriv...' == Line 511 has weird spacing: '...ed, in whole...' == Line 512 has weird spacing: '...hat the above...' == Line 514 has weird spacing: '...such as by r...' == (4 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: '13' is mentioned on line 221, but not defined == Unused Reference: '2' is defined on line 429, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 436, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-11 -- Possible downref: Normative reference to a draft: ref. '1' -- 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-03 ** 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' == Outdated reference: A later version (-04) exists of draft-ietf-mobileip-aaa-reqs-01 ** Downref: Normative reference to an Informational draft: draft-ietf-mobileip-aaa-reqs (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-01 Summary: 13 errors (**), 0 flaws (~~), 17 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Pat R. Calhoun 2 Category: Standards Track Sun Microsystems, Inc. 3 Title: draft-calhoun-diameter-strong-crypto-00.txt William Bulley 4 Date: December 1999 Merit Network, Inc. 5 Stephen Farrell 6 Baltimore Technologies 8 DIAMETER Strong Security Extension 10 Status of this Memo 12 This document is an individual contribution for consideration by the 13 AAA Working Group of the Internet Engineering Task Force. Comments 14 should be submitted to the diameter@ipass.com mailing list. 16 Distribution of this memo is unlimited. 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. Internet-Drafts are working 20 documents of the Internet Engineering Task Force (IETF), its areas, 21 and its working groups. Note that other groups may also distribute 22 working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at: 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at: 35 http://www.ietf.org/shadow.html. 37 Copyright (C) The Internet Society 1999. All Rights Reserved. 39 Abstract 41 The DIAMETER base protocol defines message integrity and AVP 42 encryption using symmetric transforms to secure the communication 43 between two DIAMETER nodes. The base protocol also defines a DIAMETER 44 proxy server, that forwards requests to other servers when it detects 45 that a given request cannot be satisfied locally. 47 The ROAMOPS Working Group has defined a requirement that allows for 48 the DIAMETER servers communicating through the proxy to be able to 49 provide for end-to-end AVP integrity and confidentiality, making it 50 difficult for the proxy to be able to modify, and/or be able to view 51 sensitive information, within the message. The Mobile-IP and NASREQ 52 Working Groups have stated that strong authentication is a 53 requirement for AAA data, such as accounting records, for the 54 purposes of non-repudiation. 56 This DIAMETER extension specifies how strong AVP authentication, 57 integrity and encryption can be done using asymmetric transforms, by 58 encapsulating Cryptographic Message Syntax (CMS) data into DIAMETER 59 AVPs. The CMS data can also be used to carry X.509 certificates. 61 Table of Contents 63 1.0 Introduction 64 1.1 Certificate Requirements 65 1.2 Requirements language 66 2.0 Extended AVP Format 67 3.0 CMS-Data AVP 68 4.0 Result-Code AVP Values 69 5.0 IANA Considerations 70 6.0 Security Considerations 71 7.0 References 72 8.0 Acknowledgements 73 9.0 Author's Addresses 74 10.0 Full Copyright Statement 76 1.0 Introduction 78 The DIAMETER base protocol [1] defines message integrity and AVP 79 encryption using symmetric transforms to secure the communication 80 between two DIAMETER nodes. The base protocol also defines a DIAMETER 81 proxy server, that forwards requests to other servers when it detects 82 that a given request cannot be satisfied locally. 84 The ROAMOPS Working Group has defined a requirement in [10] that 85 allows for the DIAMETER servers communicating through the proxy to be 86 able to provide for end-to-end AVP integrity and confidentiality, 87 making it difficult for the proxy to be able to modify and see 88 sensitive information within the message. The Mobile-IP and NASREQ 89 Working Groups have stated in [6, 7, 8] that non-repudiation is a 90 requirement for AAA data, such as accounting records. 92 When a chain of proxies use hop-by-hop security, each node in the 93 proxy chain MUST recompute the Integrity-Value-Check (ICV) [1], 94 making it easy for a malicious proxy to modify information in a 95 DIAMETER message. It is virtually impossible for the rest of the 96 nodes in the proxy chain to know that the message was modified in 97 mid-stream. Figure 1 shows an example of such a network, where DIA3 98 modifies the contents of "foo" in both the request and the response. 100 (Request) (Request) (Request) 101 [AVP(foo)=x] [AVP(foo)=x] [AVP(foo)=y] 102 +------+ -----> +------+ -----> +------+ -----> +------+ 103 | | | | | | | | 104 | NASB +----------+ DIA2 +----------+ DIA3 +----------+ DIA1 | 105 | | | | | | | | 106 +------+ <----- +------+ <----- +------+ <----- +------+ 107 (Answer) (Answer) (Answer) 108 [AVP(foo)=b] [AVP(foo)=b] [AVP(foo)=a] 109 Figure 1: Proxy Chain 111 This document describes how strong authentication and encryption can 112 be provided in the DIAMETER protocol, by encapsulating CMS objects 113 [3] in AVPs. The CMS object can also be used to carry X.509 114 certificates and revocation lists. 116 In the example provided in Figure 1, the originator of the request 117 and response add a digital signature that covers a set of AVPs within 118 the message. The protected AVPs MUST NOT be changed by an 119 intermediate proxy server (DIA2, DIA3), since the signature 120 validation performed by the end server would fail. 122 The DIAMETER base protocol also allows a DIAMETER broker to provide 123 redirect services, as shown in Figure 2. The DIAMETER broker MAY 124 return information to a requesting server that would allow the 125 servers to interact directly, bypassing the broker. This optimized 126 approach reduces the complexity associated with end-to-end security. 128 +------------------+ +---------+ 129 | DIAMETER | | CRL DB/ | 130 | Broker | | OCSP | 131 +------------------+ +---------+ 132 /|\ 133 Request | Response + 134 | Result Code = 135 Local | Redirect Home 136 ISP \|/ ISP 137 +----------+ +----------+ 138 | abc.net |/ \| xyz.net | 139 | DIAMETER |--------------| DIAMETER | 140 | Server |\ /| Server | 141 +----------+ Direct +----------+ 142 Communication 143 Figure 2: DIAMETER Broker Returning Redirect Indication 145 When redirect services are used, a network layer security protocol, 146 such as IP Security, MAY be used to secure the traffic between the 147 two DIAMETER servers. However, security at the application level may 148 still be necessary in this network configuration, specifically the 149 ability to authenticate a select set of AVPs. Brokers that operate in 150 a redirect mode typically require that both DIAMETER servers sign 151 accounting records. The accounting record, signed by both parties is 152 then forwarded to the broker via the local DIAMETER server. This 153 provides the broker with some assurances that both networks agreed on 154 the accounting data, which it MAY use for settlement purposes. If the 155 underlying security protocol provides confidentiality, strong 156 encryption MAY not be necessary in the redirect case. 158 Given that asymmetric transform operations are expensive, DIAMETER 159 servers MAY wish to use them only when dealing with inter-domain 160 servers, as shown in Figure 3. This configuration is normally 161 desirable since DIAMETER entities within a given administrative 162 domain MAY inherently trust each other. Further, it is desirable to 163 move this functionality to the edges, since NASes do not necessarily 164 have the CPU power to perform expensive cryptographic operations. 166 +------------------------+ 167 | Foreign Network | 168 |+-----+ +--------+ | +--------+ +--------+ 169 || | |DIAMETER| | |DIAMETER| |DIAMETER| 170 || NAS +------+ +--------+ +--------+ Home | 171 || | | Proxy | | | Broker | | Server | 172 |+-----+ +--------+ | +--------+ +--------+ 173 | | 174 +------------------------+ 175 <------------> <--------------------------> 176 178 Figure 3: Mixed DIAMETER Security Models 180 The Extension number for this draft is two (2). This value is used in 181 the Extension-Id AVP as defined in [1]. 183 1.1 Certificate Requirements 185 Certificates used for the purposes of DIAMETER MUST conform to the 186 PKIX profile [4], and MUST also include a DIAMETER node's NAI, which 187 is typically added in the Host-Name AVP [1], as one of the values of 188 the subjectAltName extension of the Certificate. The NAI is to be 189 encoded as an rfc822Name within the subjectAltName. 191 These names are used for two purposes: 193 1. Where a DIAMETER node is verifying a signature it needs to be 194 able to compare the identity of the signer against the identity 195 in the Host-Name AVP. 197 2. Where a DIAMETER node is encrypting AVPs, it needs to be able 198 to ensure that it uses a public key for the intended recipient. 199 This requries comparing the identity in a Certificate against 200 the NAI of the intended recipient (which is assumed to be 201 known). 203 In either case, the presence of the required NAI as an rfc822Name 204 value in the subjectAltName extension of a verified public key 205 certificate satisfies the matching requirement. 207 Note that there MAY also be other values in the subjectAltName 208 extension, (either using rfc822Name or other elements of the CHOICE), 209 these can be safely ignored, but implementations MUST be able to 210 handle their presence. 212 Note also that the PKIX profile [4], section 4.1.2.6, specifies the 213 rules for the relationship between the subjectAltName extension and 214 the subject field of public key certificates. 216 1.2 Requirements language 218 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 219 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 220 described in [13]. 222 2.0 Extended AVP Format 224 This specification introduces the 'P' bit in the AVP Header, which is 225 defined in [1]. The 'P' bit, known as the protected AVP bit, is used 226 to indicate whether the AVP is protected by a digital signature. When 227 set, the AVP is protected and the contents cannot be changed by a 228 DIAMETER proxy server without detection. 230 0 1 2 3 231 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 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | AVP Code | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | AVP Length | Reserved |P|T|V|R|M| 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | Vendor ID (opt) | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Tag (opt) | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Data ... 242 +-+-+-+-+-+-+-+-+ 243 Figure 4: Extended DIAMETER AVP Header 245 Note that unless stated otherwise, the 'P' bit can be set on any 246 DIAMETER AVP. The Proxy-State and Integrity-Check-Value AVPs [1] MUST 247 NOT have the 'P' bit set. The Encrypted-Payload AVP MAY have the 'P' 248 bit set if there is no intermediate proxy server. Any additional AVPs 249 that MUST be removed, or changed, at each hop in a proxy chain MUST 250 NOT have the 'P' bit set. 252 3.0 CMS-Data AVP 254 The CMS-Data AVP (AVP Code 310) is of type data and contains the DER 255 encoding of a CMS object [3] of type ContentInfo. The profile of CMS 256 algorithm and structure usage is as specified in the S/MIME v3 257 message specification [11]. This means that where a set of AVPs is 258 protected using CMS, the set MUST first be encoded according to MIME 259 encoding rules specified below. This method of encapsulating AVPs 260 allows existing S/MIME toolkits to be used without changes in order 261 to produce strongly protected DIAMETER messages. The CMS object MAY 262 contain any of the three methods; signed-only, enveloped-only and 263 signed-and-enveloped. Optional certificates and CRLs MAY be present 264 in all three methods. 266 To package a set of AVPs as a MIME type, the AVPs are first 267 concatenated in the order in which they occur in the DIAMETER 268 message. The entire AVP MUST be input to the signing/encryption 269 process, from the first byte of the AVP code to the last byte of the 270 AVP data, including all other fields, length, reserved/flags, and 271 optional vendor IDs, tags and padding. The AVP MUST be input to the 272 signing/encryption process in network byte order. If AVPs are to be 273 enciphered, then the encryptor is free to order AVPs whatever way it 274 chooses. This value is then used as the value of a new MIME type 275 application/x-diameter-avps, which MUST be prepared in accordance 276 with the rules specified in section 3.1 of [11]. If a receiver 277 detects that the contents of the CMS-Data AVP is invalid, it SHOULD 278 return the new Result-Code AVP value defined in section 4.0. 280 Where signing only is performed, the signature is calculated over the 281 canonical encoding of the application/x-diameter-avps MIME type, but 282 the AVPs themselves are not carried within the CMS-Data AVP. Instead, 283 the digest value within the SignedData structure contains the digest 284 over the canonicalized encoding of application/x-diameter-avps. 285 Multiple DIAMETER entities MAY add their signatures to an existing 286 CMS-Data AVP using the countersignature attribute, defined in section 287 11.4 of [3]. The countersignature attribute requires that the 288 signatures occur sequentially, meaning that each node's signature 289 covers the existing signatures in the CMS object. 291 Where encryption only is performed, the encryptedContent MUST contain 292 the canonical encoding of the application/x-diameter-avps MIME type. 294 Where signing and encryption are both performed, signing MUST occur 295 first, the resulting CMS object MUST then be MIME encoded producing 296 an application/pkcs7-mime type which is then used as the content of 297 the EnvelopedData. 299 There is no need for an 'outer' MIME encoding when only signing, or 300 only encryption is applied. 302 Where AVPs are encapsulated within a CMS-Data AVP, the eContentType 303 of the EncapsulatedContentInfo MUST be id-diameterAVPs (the value of 304 this OID is TBD). 306 The signing and encryption algorithms supported MUST be those 307 specified in sections 2.2 and 2.3 of [11]. 309 Conformant implementations MUST emit a CMS-Data AVP which contains 310 only one application/x-diameter-avps MIME type. Implementations which 311 receive any other MIME type MUST indicate an error. 313 Where a CMS-Data AVP contains a set of certificates then both public 314 key certificates (Certificate) and attribute certificates 315 (AttributeCertificate) are allowed by CMS (as well as one other 316 legacy format which MUST NOT be used). Support for use of the 317 Certificate structure is REQUIRED, implementations SHOULD support use 318 of the AttributeCertificate structure as defined in the PKIX 319 attribute certificate profile [12]. This allows DIAMETER 320 implementations to include a certifiate from a trusted party that 321 they are authorized to emit the AVPs contained in the message. 323 When a SignedData object is present, the eContent field of the 324 EncapsulatedContentInfo structure MUST be absent since the 325 authentication covers data outside of the object. The signature is 326 computed over all AVPs prior to the AVP that have the 'P' bit 327 enabled. The order of the AVPs MUST be preserved and the computation 328 begins with the first AVP immediately following the DIAMETER header. 329 If the 'T' bit is set, the CMS-Data AVP covers all previous AVP with 330 the 'T' bit enabled and the same tag value as the one found in the 331 CMS-Data AVP. An Integrity-Check-Value (ICV) AVP MUST NOT preceed a 332 CMS-Data AVP containing a SignedData object. If the signature cannot 333 be verified correctly, a response with the Result-Code AVP set to 334 DIAMETER_INVALID_AUTH [1] MUST be returned. 336 When an EnvelopedData object is present, the encryptedContentInfo 337 field MUST contain the Host-Name AVP, containing the host name of the 338 encryptor, and one or more additional AVPs. 340 When a conforming implementation receives a DIAMETER message which 341 contains encrypted AVPs within a CMS EnvelopedData, then the 342 recipient MUST check to see if it is on the list of recipients 343 specified in the RecipientInfos of the EnvelopedData. If not, the 344 recipient MAY choose to process the message or indicate an error. If 345 the recipient is in the RecipientInfos and an error occurs during 346 decryption, then the recipient MUST indicate an error. 348 A CMS-Data MAY also contain a certs-only CMS structure, which is a 349 degenerate form of CMS structure containing only PKI related 350 information (see section 3.6 of [11] for details of the CMS certs- 351 only structure). This use of the CMS-Data AVP can be used to "push" 352 public key and attribute certificates and CRLs using DIAMETER, which 353 MAY be useful in environments where repositories (e.g. LDAP servers) 354 are either not used or not available (e.g. due to crossing a domain 355 boundary). Conforming implementations MUST be able to emit a certs- 356 only CMS structure which contains relevant PKI related information 357 and MUST be able to process a CMS-Data AVP which contains a certs- 358 only CMS structure. Of course, the recipient of such a certs-only CMS 359 structure SHOULD NOT use the PKI related information without first 360 verifying it, e.g. by checking that issuer's are trusted, signatures 361 verify etc. 363 When the CMS-Data AVP contains certificates in the certificates field 364 of the SignedData, a CRL [4] MAY also be provided in the crls field 365 of the SignedData, which MAY be used to assist in determining whether 366 a certificate has been revoked. Optionally, the DIAMETER server MAY 367 check the status of certificates using another mechanism, such as 368 Online Certificate Status Protocol (OCSP) [9]. 370 This AVP MUST have the 'M' bit enabled, while the 'T' bit MAY be 371 enabled if the signature covers a set of AVPs. The 'P' and 'V' bits 372 MUST NOT be enabled. 374 The following is an example of a message that includes strong 375 security and hop-by-hop security: 377 ::= 378 379 [] 380 381 [ 382 383 ] 385 4.0 Result-Code AVP Values 387 This section defines new Result-Code [1] values that MUST be 388 supported by all DIAMETER implementations that conform to this 389 specification. 391 DIAMETER_INVALID_CMS_DATA 20 392 This error code is returned when a CMS-Data AVP is received 393 with an invalid ContentInfo object. 395 5.0 IANA Considerations 397 This document introduces a new AVP, defined in section 3. The AVP 398 Code was taken from the numbering space defined in [1] and MUST NOT 399 conflict with the values specified in [1], or any other DIAMETER 400 extension. The DIAMETER Extension number defined in this document 401 MUST NOT conflict with values specified in any DIAMETER extension. 402 The Result-Code AVP number defined in section 4.0 MUST NOT conflict 403 with values specified in [1], or any other related DIAMETER 404 extension. This document also defines a new bit in the AVP Header, 405 which MUST NOT conflict with the bits defined in the base protocol 406 [1], or any other DIAMETER extension. 408 6.0 Security Considerations 410 This document describes how strong security can be achieved in the 411 DIAMETER protocol by allowing S/MIME Cryptographic Message Syntax [3] 412 objects to be carried as a DIAMETER AVP. 414 Section 3.0 states that a certificate received in a CMS-Data AVP 415 SHOULD NOT be used prior to cert verification. In most cases, the 416 verification will be according to the rules specified in [4], 417 however, some communities have indicated that they wish to be allowed 418 specify alternative certificate verification mechanisms, hence the 419 "SHOULD NOT" rather than the more typical "MUST NOT". The authors do 420 however strongly RECOMMEND that the verification procedures specified 421 in [4] are always applied, regardless of whatever other verification 422 mechanisms are in use. 424 7.0 References 426 [1] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, "DIAMETER Base 427 Protocol", draft-calhoun-diameter-11.txt (work in progress), 428 December 1999. 429 [2] Kaufman, Perlman, Speciner, "Network Security: Private 430 Communications in a Public World", Prentice Hall, March 1995, 431 ISBN 0-13-061466-1. 432 [3] R. Housley, "Cryptographic Message Syntax", RFC 2630, June 1999. 433 [4] Housley, Ford, Polk, Solo, "Internet X.509 Public Key 434 Infrastructure Certificate and CRL Profile", RFC 2459, January 435 1999. 436 [5] S. Bradner, "Key words for use in RFCs to Indicate Requirement 437 Levels", BCP 14, RFC 2119, March 1997. 438 [6] M. Beadles, "Criteria for Evaluating Network Access Server 439 Protocols", draft-ietf-nasreq-criteria-03.txt (work in 440 progress), October 1999. 441 [7] T. Hiller et al., "Cdma2000 Wireless Data Requirements for AAA", 442 draft-hiller-cdma2000-AAA-00.txt (work in progress), October 443 1999. 444 [8] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, 445 Authorization, and Accounting Requirements", draft-ietf- 446 mobileip-aaa-reqs-01.txt (work in progress), October 1999. 447 [9] Myers, Ankney, Malpani, Galperin, Adams, "X.509 Internet Public 448 Key Infrastructure Online Certificate Status Protocol (OCSP)", 449 RFC 2560, June 1999. 450 [10] Aboba, Zorn, "Criteria for Evaluating Roaming Protocols", RFC 451 2477, January 1999. 452 [11] B. Ramsdell, "S/MIME v2 Message Specification", RFC2633, June 453 1999. 454 [12] S. Farrell, R. Housley, "An Internet Attribute Certificate 455 Profile for Authorization", draft-ietf-pkix-ac509prof-01.txt 456 (work in progress), October 1999. 458 8.0 Acknowledgements 460 The authors would also like to acknowledge the following people for 461 their contribution in the development of the DIAMETER protocol: 463 Bernard Aboba, Jari Arkko, William Bulley, Daniel C. Fox, Lol Grant, 464 Ignacio Goyret, Nancy Greene, Peter Heitman, Paul Krumviede, Fergal 465 Ladley, Ryan Moats, Victor Muslin, Kenneth Peirce, Sumit Vakil, John 466 R. Vollbrecht, Jeff Weisberg and Glen Zorn 468 9.0 Author's Addresses 470 Questions about this memo can be directed to: 472 Pat R. Calhoun 473 Network and Security Research Center, Sun Labs 474 Sun Microsystems, Inc. 475 15 Network Circle 476 Menlo Park, California, 94025 477 USA 479 Phone: 1-650-786-7733 480 Fax: 1-650-786-6445 481 E-mail: pcalhoun@eng.sun.com 483 William Bulley 484 Merit Network, Inc. 485 Building One, Suite 2000 486 4251 Plymouth Road 487 Ann Arbor, Michigan, 48105-2785 488 USA 490 Phone: 1-734-764-9993 491 Fax: 1-734-647-5185 492 E-mail: web@merit.edu 494 Stephen Farrell 495 Baltimore Technologies 496 61/62 Fitzwilliam Lane 497 Dublin 2, 498 IRELAND 500 Phone: +353-1-647-7300 501 Fax: +353-1-647-7499 502 E-Mail: stephen.farrell@baltimore.ie 504 10.0 Full Copyright Statement 506 Copyright (C) The Internet Society (1999). All Rights Reserved. 508 This document and translations of it may be copied and furnished to 509 others, and derivative works that comment on or otherwise explain it 510 or assist in its implementation may be prepared, copied, published and 511 distributed, in whole or in part, without restriction of any kind, 512 provided that the above copyright notice and this paragraph are 513 included on all such copies and derivative works. However, this docu- 514 ment itself may not be modified in any way, such as by removing the 515 copyright notice or references to the Internet Society or other Inter- 516 net organizations, except as needed for the purpose of developing 517 Internet standards in which case the procedures for copyrights defined 518 in the Internet Standards process must be followed, or as required to 519 translate it into languages other than English. The limited permis- 520 sions granted above are perpetual and will not be revoked by the 521 Internet Society or its successors or assigns. This document and the 522 information contained herein is provided on an "AS IS" basis and THE 523 INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 524 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WAR- 525 RANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 526 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 527 PARTICULAR PURPOSE."