idnits 2.17.1 draft-calhoun-diameter-strong-crypto-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 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 509 has weird spacing: '... copied and ...' == Line 510 has weird spacing: '...s, and deriv...' == Line 512 has weird spacing: '...ed, in whole...' == Line 513 has weird spacing: '...hat the above...' == Line 515 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 428, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 435, 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-01.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-data [11]. 305 The signing and encryption algorithms supported MUST be those 306 specified in sections 2.2 and 2.3 of [11]. 308 Conformant implementations MUST emit a CMS-Data AVP which contains 309 only one application/x-diameter-avps MIME type. Implementations which 310 receive any other MIME type MUST indicate an error. 312 Where a CMS-Data AVP contains a set of certificates then both public 313 key certificates (Certificate) and attribute certificates 314 (AttributeCertificate) are allowed by CMS (as well as one other 315 legacy format which MUST NOT be used). Support for use of the 316 Certificate structure is REQUIRED, implementations SHOULD support use 317 of the AttributeCertificate structure as defined in the PKIX 318 attribute certificate profile [12]. This allows DIAMETER 319 implementations to include a certifiate from a trusted party that 320 they are authorized to emit the AVPs contained in the message. 322 When a SignedData object is present, the eContent field of the 323 EncapsulatedContentInfo structure MUST be absent since the 324 authentication covers data outside of the object. The signature is 325 computed over all AVPs prior to the AVP that have the 'P' bit 326 enabled. The order of the AVPs MUST be preserved and the computation 327 begins with the first AVP immediately following the DIAMETER header. 328 If the 'T' bit is set, the CMS-Data AVP covers all previous AVP with 329 the 'T' bit enabled and the same tag value as the one found in the 330 CMS-Data AVP. An Integrity-Check-Value (ICV) AVP MUST NOT preceed a 331 CMS-Data AVP containing a SignedData object. If the signature cannot 332 be verified correctly, a response with the Result-Code AVP set to 333 DIAMETER_INVALID_AUTH [1] MUST be returned. 335 When an EnvelopedData object is present, the encryptedContentInfo 336 field MUST contain the Host-Name AVP, containing the host name of the 337 encryptor, and one or more additional AVPs. 339 When a conforming implementation receives a DIAMETER message which 340 contains encrypted AVPs within a CMS EnvelopedData, then the 341 recipient MUST check to see if it is on the list of recipients 342 specified in the RecipientInfos of the EnvelopedData. If not, the 343 recipient MAY choose to process the message or indicate an error. If 344 the recipient is in the RecipientInfos and an error occurs during 345 decryption, then the recipient MUST indicate an error. 347 A CMS-Data MAY also contain a certs-only CMS structure, which is a 348 degenerate form of CMS structure containing only PKI related 349 information (see section 3.6 of [11] for details of the CMS certs- 350 only structure). This use of the CMS-Data AVP can be used to "push" 351 public key and attribute certificates and CRLs using DIAMETER, which 352 MAY be useful in environments where repositories (e.g. LDAP servers) 353 are either not used or not available (e.g. due to crossing a domain 354 boundary). Conforming implementations MUST be able to emit a certs- 355 only CMS structure which contains relevant PKI related information 356 and MUST be able to process a CMS-Data AVP which contains a certs- 357 only CMS structure. Of course, the recipient of such a certs-only CMS 358 structure SHOULD NOT use the PKI related information without first 359 verifying it, e.g. by checking that issuer's are trusted, signatures 360 verify etc. 362 When the CMS-Data AVP contains certificates in the certificates field 363 of the SignedData, a CRL [4] MAY also be provided in the crls field 364 of the SignedData, which MAY be used to assist in determining whether 365 a certificate has been revoked. Optionally, the DIAMETER server MAY 366 check the status of certificates using another mechanism, such as 367 Online Certificate Status Protocol (OCSP) [9]. 369 This AVP MUST have the 'M' bit enabled, while the 'T' bit MAY be 370 enabled if the signature covers a set of AVPs. The 'P' and 'V' bits 371 MUST NOT be enabled. 373 The following is an example of a message that includes strong 374 security and hop-by-hop security: 376 ::= 377 378 [] 379 380 [ 381 382 ] 384 4.0 Result-Code AVP Values 386 This section defines new Result-Code [1] values that MUST be 387 supported by all DIAMETER implementations that conform to this 388 specification. 390 DIAMETER_INVALID_CMS_DATA 20 391 This error code is returned when a CMS-Data AVP is received 392 with an invalid ContentInfo object. 394 5.0 IANA Considerations 396 This document introduces a new AVP, defined in section 3. The AVP 397 Code was taken from the numbering space defined in [1] and MUST NOT 398 conflict with the values specified in [1], or any other DIAMETER 399 extension. The DIAMETER Extension number defined in this document 400 MUST NOT conflict with values specified in any DIAMETER extension. 401 The Result-Code AVP number defined in section 4.0 MUST NOT conflict 402 with values specified in [1], or any other related DIAMETER 403 extension. This document also defines a new bit in the AVP Header, 404 which MUST NOT conflict with the bits defined in the base protocol 405 [1], or any other DIAMETER extension. 407 6.0 Security Considerations 409 This document describes how strong security can be achieved in the 410 DIAMETER protocol by allowing S/MIME Cryptographic Message Syntax [3] 411 objects to be carried as a DIAMETER AVP. 413 Section 3.0 states that a certificate received in a CMS-Data AVP 414 SHOULD NOT be used prior to cert verification. In most cases, the 415 verification will be according to the rules specified in [4], 416 however, some communities have indicated that they wish to be allowed 417 specify alternative certificate verification mechanisms, hence the 418 "SHOULD NOT" rather than the more typical "MUST NOT". The authors do 419 however strongly RECOMMEND that the verification procedures specified 420 in [4] are always applied, regardless of whatever other verification 421 mechanisms are in use. 423 7.0 References 425 [1] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, "DIAMETER Base 426 Protocol", draft-calhoun-diameter-11.txt (work in progress), 427 December 1999. 428 [2] Kaufman, Perlman, Speciner, "Network Security: Private 429 Communications in a Public World", Prentice Hall, March 1995, 430 ISBN 0-13-061466-1. 431 [3] R. Housley, "Cryptographic Message Syntax", RFC 2630, June 1999. 432 [4] Housley, Ford, Polk, Solo, "Internet X.509 Public Key 433 Infrastructure Certificate and CRL Profile", RFC 2459, January 434 1999. 435 [5] S. Bradner, "Key words for use in RFCs to Indicate Requirement 436 Levels", BCP 14, RFC 2119, March 1997. 437 [6] M. Beadles, "Criteria for Evaluating Network Access Server 438 Protocols", draft-ietf-nasreq-criteria-03.txt (work in 439 progress), October 1999. 440 [7] T. Hiller et al., "Cdma2000 Wireless Data Requirements for AAA", 441 draft-hiller-cdma2000-AAA-00.txt (work in progress), October 442 1999. 443 [8] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, 444 Authorization, and Accounting Requirements", draft-ietf- 445 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 493 E-mail: web@merit.edu 495 Stephen Farrell 496 Baltimore Technologies 497 61/62 Fitzwilliam Lane 498 Dublin 2, 499 IRELAND 501 Phone: +353-1-647-7300 502 Fax: +353-1-647-7499 503 E-Mail: stephen.farrell@baltimore.ie 505 10.0 Full Copyright Statement 507 Copyright (C) The Internet Society (1999). All Rights Reserved. 509 This document and translations of it may be copied and furnished to 510 others, and derivative works that comment on or otherwise explain it 511 or assist in its implementation may be prepared, copied, published and 512 distributed, in whole or in part, without restriction of any kind, 513 provided that the above copyright notice and this paragraph are 514 included on all such copies and derivative works. However, this docu- 515 ment itself may not be modified in any way, such as by removing the 516 copyright notice or references to the Internet Society or other Inter- 517 net organizations, except as needed for the purpose of developing 518 Internet standards in which case the procedures for copyrights defined 519 in the Internet Standards process must be followed, or as required to 520 translate it into languages other than English. The limited permis- 521 sions granted above are perpetual and will not be revoked by the 522 Internet Society or its successors or assigns. This document and the 523 information contained herein is provided on an "AS IS" basis and THE 524 INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 525 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WAR- 526 RANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 527 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 528 PARTICULAR PURPOSE."