idnits 2.17.1 draft-calhoun-diameter-strong-crypto-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 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 7 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == 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) == 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-13 -- 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 == Outdated reference: A later version (-06) exists of draft-calhoun-diameter-nasreq-02 -- Possible downref: Normative reference to a draft: ref. '13' == Outdated reference: A later version (-12) exists of draft-calhoun-diameter-mobileip-06 -- Possible downref: Normative reference to a draft: ref. '14' == Outdated reference: A later version (-09) exists of draft-calhoun-diameter-accounting-04 -- Possible downref: Normative reference to a draft: ref. '15' Summary: 13 errors (**), 0 flaws (~~), 13 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET DRAFT Pat R. Calhoun 3 Category: Standards Track Sun Microsystems, Inc. 4 Title: draft-calhoun-diameter-strong-crypto-02.txt William Bulley 5 Date: March 2000 Merit Network, Inc. 6 Stephen Farrell 7 Baltimore Technologies 9 DIAMETER Strong Security Extension 11 Status of this Memo 13 This document is an individual contribution for consideration by the 14 AAA Working Group of the Internet Engineering Task Force. Comments 15 should be submitted to the diameter@ipass.com mailing list. 17 Distribution of this memo is unlimited. 19 This document is an Internet-Draft and is in full conformance with 20 all provisions of Section 10 of RFC2026. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at: 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 The list of Internet-Draft Shadow Directories can be accessed at: 36 http://www.ietf.org/shadow.html. 38 Copyright (C) The Internet Society 1999. All Rights Reserved. 40 Abstract 42 The DIAMETER base protocol defines message integrity and AVP 43 encryption using symmetric transforms to secure the communication 44 between two DIAMETER nodes. The base protocol also defines a DIAMETER 45 proxy server, that forwards requests to other servers when it detects 46 that a given request cannot be satisfied locally. 48 The ROAMOPS Working Group has defined a requirement that allows for 49 the DIAMETER servers communicating through the proxy to be able to 50 provide for end-to-end AVP integrity and confidentiality, making it 51 difficult for the proxy to be able to modify, and/or be able to view 52 sensitive information, within the message. The Mobile-IP and NASREQ 53 Working Groups have stated that strong authentication is a 54 requirement for AAA data, such as accounting records, for the 55 purposes of non-repudiation. 57 This DIAMETER extension specifies how strong AVP authentication, 58 integrity and encryption can be done using asymmetric transforms, by 59 encapsulating Cryptographic Message Syntax (CMS) data into DIAMETER 60 AVPs. The CMS data can also be used to carry X.509 certificates. 62 Table of Contents 64 1.0 Introduction 65 1.1 Certificate Requirements 66 1.2 Requirements language 67 2.0 Extended AVP Format 68 3.0 CMS-Data AVP 69 4.0 Result-Code AVP Values 70 5.0 IANA Considerations 71 6.0 Security Considerations 72 7.0 References 73 8.0 Acknowledgements 74 9.0 Authors' Addresses 75 10.0 Full Copyright Statement 77 1.0 Introduction 79 The DIAMETER base protocol [1] defines message integrity and AVP 80 encryption using symmetric transforms to secure the communication 81 between two DIAMETER nodes. The base protocol also defines a DIAMETER 82 proxy server, that forwards requests to other servers when it detects 83 that a given request cannot be satisfied locally. 85 The ROAMOPS Working Group has defined a requirement in [10] that 86 allows for the DIAMETER servers communicating through the proxy to be 87 able to provide for end-to-end AVP integrity and confidentiality, 88 making it difficult for the proxy to be able to modify and see 89 sensitive information within the message. The Mobile-IP and NASREQ 90 Working Groups have stated in [6, 7, 8] that non-repudiation is a 91 requirement for AAA data, such as accounting records. 93 When a chain of proxies use hop-by-hop security, each node in the 94 proxy chain MUST recompute the Integrity-Value-Check (ICV) [1], 95 making it easy for a malicious proxy to modify information in a 96 DIAMETER message. It is virtually impossible for the rest of the 97 nodes in the proxy chain to know that the message was modified in 98 mid-stream. Figure 1 shows an example of such a network, where DIA3 99 modifies the contents of "foo" in both the request and the response. 101 (Request) (Request) (Request) 102 [AVP(foo)=x] [AVP(foo)=x] [AVP(foo)=y] 103 +------+ -----> +------+ -----> +------+ -----> +------+ 104 | | | | | | | | 105 | NASB +----------+ DIA2 +----------+ DIA3 +----------+ DIA1 | 106 | | | | | | | | 107 +------+ <----- +------+ <----- +------+ <----- +------+ 108 (Answer) (Answer) (Answer) 109 [AVP(foo)=b] [AVP(foo)=b] [AVP(foo)=a] 110 Figure 1: Proxy Chain 112 This document describes how strong authentication and encryption can 113 be provided in the DIAMETER protocol, by encapsulating CMS objects 114 [3] in AVPs. The CMS object can also be used to carry X.509 115 certificates and revocation lists. 117 In the example provided in Figure 1, the originator of the request 118 and response add a digital signature that covers a set of AVPs within 119 the message. The protected AVPs MUST NOT be changed by an 120 intermediate proxy server (DIA2, DIA3), since the signature 121 validation performed by the end server would fail. 123 The DIAMETER base protocol also allows a DIAMETER broker to provide 124 redirect services, as shown in Figure 2. The DIAMETER broker MAY 125 return information to a requesting server that would allow the 126 servers to interact directly, bypassing the broker. This optimized 127 approach reduces the complexity associated with end-to-end security. 129 +------------------+ +---------+ 130 | DIAMETER | | CRL DB/ | 131 | Broker | | OCSP | 132 +------------------+ +---------+ 133 ^ 134 Request | Response + 135 | Result Code = 136 Local | Redirect Home 137 ISP v ISP 138 +----------+ +----------+ 139 | abc.net | | xyz.net | 140 | DIAMETER |<------------>| DIAMETER | 141 | Server | | Server | 142 +----------+ Direct +----------+ 143 Communication 144 Figure 2: DIAMETER Broker Returning Redirect Indication 146 When redirect services are used, a network layer security protocol, 147 such as IP Security, MAY be used to secure the traffic between the 148 two DIAMETER servers. However, security at the application level may 149 still be necessary in this network configuration, specifically the 150 ability to authenticate a select set of AVPs. Brokers that operate in 151 a redirect mode typically require that both DIAMETER servers sign 152 accounting records. The accounting record, signed by both parties is 153 then forwarded to the broker via the local DIAMETER server. This 154 provides the broker with some assurances that both networks agreed on 155 the accounting data, which it MAY use for settlement purposes. If the 156 underlying security protocol provides confidentiality, strong 157 encryption MAY not be necessary in the redirect case. 159 Given that asymmetric transform operations are expensive, DIAMETER 160 servers MAY wish to use them only when dealing with inter-domain 161 servers, as shown in Figure 3. This configuration is normally 162 desirable since DIAMETER entities within a given administrative 163 domain MAY inherently trust each other. Further, it is desirable to 164 move this functionality to the edges, since NASes do not necessarily 165 have the CPU power to perform expensive cryptographic operations. 167 +------------------------+ 168 | Foreign Network | 169 |+-----+ +--------+ | +--------+ +--------+ 170 || | |DIAMETER| | |DIAMETER| |DIAMETER| 171 || NAS +------+ +--------+ +--------+ Home | 172 || | | Proxy | | | Broker | | Server | 173 |+-----+ +--------+ | +--------+ +--------+ 174 | | 175 +------------------------+ 176 <------------> <--------------------------> 177 179 Figure 3: Mixed DIAMETER Security Models 181 The Extension number for this draft is two (2). This value is used in 182 the Extension-Id AVP as defined in [1]. 184 1.1 Certificate Requirements 186 Certificates used for the purposes of DIAMETER MUST conform to the 187 PKIX profile [4], and MUST also include a DIAMETER node's NAI, which 188 is typically added in the Host-Name AVP [1], as one of the values of 189 the subjectAltName extension of the Certificate. The NAI is to be 190 encoded as an rfc822Name within the subjectAltName. 192 These names are used for two purposes: 194 1. Where a DIAMETER node is verifying a signature it needs to be 195 able to compare the identity of the signer against the identity 196 in the Host-Name AVP. 198 2. Where a DIAMETER node is encrypting AVPs, it needs to be able 199 to ensure that it uses a public key for the intended recipient. 200 This requries comparing the identity in a Certificate against 201 the NAI of the intended recipient (which is assumed to be 202 known). 204 In either case, the presence of the required NAI as an rfc822Name 205 value in the subjectAltName extension of a verified public key 206 certificate satisfies the matching requirement. 208 Note that there MAY also be other values in the subjectAltName 209 extension, (either using rfc822Name or other elements of the CHOICE), 210 these can be safely ignored, but implementations MUST be able to 211 handle their presence. 213 Note also that the PKIX profile [4], section 4.1.2.6, specifies the 214 rules for the relationship between the subjectAltName extension and 215 the subject field of public key certificates. 217 1.2 Requirements language 219 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 220 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 221 described in [13]. 223 2.0 Extended AVP Format 225 This specification introduces the 'P' bit in the AVP Header, which is 226 defined in [1]. The 'P' bit, known as the protected AVP bit, is used 227 to indicate whether the AVP is protected by a digital signature. When 228 set, the AVP is protected and the contents cannot be changed by a 229 DIAMETER proxy server without detection. 231 0 1 2 3 232 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 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | AVP Code | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | AVP Length | Reserved |P|T|V|R|M| 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Vendor ID (opt) | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | Tag (opt) | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Data ... 243 +-+-+-+-+-+-+-+-+ 244 Figure 4: Extended DIAMETER AVP Header 246 Note that unless stated otherwise, the 'P' bit can be set on any 247 DIAMETER AVP. The Proxy-State and Integrity-Check-Value AVPs [1] MUST 248 NOT have the 'P' bit set. The Encrypted-Payload AVP MAY have the 'P' 249 bit set if there is no intermediate proxy server. Any additional AVPs 250 that MUST be removed, or changed, at each hop in a proxy chain MUST 251 NOT have the 'P' bit set. 253 3.0 CMS-Data AVP 255 The CMS-Data AVP (AVP Code 310) is of type data and contains the DER 256 encoding of a CMS object [3] of type ContentInfo. The profile of CMS 257 algorithm and structure usage is as specified in the S/MIME v3 258 message specification [11]. This means that where a set of AVPs is 259 protected using CMS, the set MUST first be encoded according to MIME 260 encoding rules specified below. This method of encapsulating AVPs 261 allows existing S/MIME toolkits to be used without changes in order 262 to produce strongly protected DIAMETER messages. The CMS object MAY 263 contain any of the three methods; signed-only, enveloped-only and 264 signed-and-enveloped. Optional certificates and CRLs MAY be present 265 in all three methods. 267 To package a set of AVPs as a MIME type, the AVPs are first 268 concatenated in the order in which they occur in the DIAMETER 269 message. The entire AVP MUST be input to the signing/encryption 270 process, from the first byte of the AVP code to the last byte of the 271 AVP data, including all other fields, length, reserved/flags, and 272 optional vendor IDs, tags and padding. The AVP MUST be input to the 273 signing/encryption process in network byte order. If AVPs are to be 274 enciphered, then the encryptor is free to order AVPs whatever way it 275 chooses. This value is then used as the value of a new MIME type 276 application/x-diameter-avps, which MUST be prepared in accordance 277 with the rules specified in section 3.1 of [11]. If a receiver 278 detects that the contents of the CMS-Data AVP is invalid, it SHOULD 279 return the new Result-Code AVP value defined in section 4.0. 281 Where signing only is performed, the signature is calculated over the 282 canonical encoding of the application/x-diameter-avps MIME type, but 283 the AVPs themselves are not carried within the CMS-Data AVP. Instead, 284 the digest value within the SignedData structure contains the digest 285 over the canonicalized encoding of application/x-diameter-avps. 286 Multiple DIAMETER entities MAY add their signatures to an existing 287 CMS-Data AVP using the countersignature attribute, defined in section 288 11.4 of [3]. The countersignature attribute requires that the 289 signatures occur sequentially, meaning that each node's signature 290 covers the existing signatures in the CMS object. 292 Where encryption only is performed, the encryptedContent MUST contain 293 the canonical encoding of the application/x-diameter-avps MIME type. 295 Where signing and encryption are both performed, signing MUST occur 296 first, the resulting CMS object MUST then be MIME encoded producing 297 an application/pkcs7-mime type which is then used as the content of 298 the EnvelopedData. 300 There is no need for an 'outer' MIME encoding when only signing, or 301 only encryption is applied. 303 Where AVPs are encapsulated within a CMS-Data AVP, the eContentType 304 of the EncapsulatedContentInfo MUST be id-data [11]. 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 The CMD-Data AVP defined in Section 3 is a DIAMETER AVP whose 398 identifier was allocated from the AVP numbering space [1], and 399 extended in [13], [14] and [15]. IANA should assign a value of 310 to 400 this AVP. 402 The Result-Code values defined in Section 4.0 are error codes as 403 defined in [1] and extended in [13], [14] and [15]. They correspond 404 to error values specific to the Strong Security extension. IANA 405 should record the values as defined in Section 4.0. 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-13.txt, IETF work in progress, 427 March 2000. 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, IETF 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, IETF 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, IETF work in progress, January 2000. 446 [9] Myers, Ankney, Malpani, Galperin, Adams, "X.509 Internet Public 447 Key Infrastructure Online Certificate Status Protocol (OCSP)", 448 RFC 2560, June 1999. 449 [10] Aboba, Zorn, "Criteria for Evaluating Roaming Protocols", RFC 450 2477, January 1999. 451 [11] B. Ramsdell, "S/MIME v2 Message Specification", RFC2633, June 452 1999. 453 [12] S. Farrell, R. Housley, "An Internet Attribute Certificate 454 Profile for Authorization", draft-ietf-pkix-ac509prof-01.txt, 455 IETF work in progress, October 1999. 456 [13] P. Calhoun, W. Bulley, "DIAMETER NASREQ Extension", draft- 457 calhoun-diameter-nasreq-02.txt, IETF work in progress, March 458 2000. 459 [14] P. Calhoun, C. Perkins, "DIAMETER Mobile IP Extensions", draft- 460 calhoun-diameter-mobileip-06.txt, IETF work in progress, March 461 2000. 462 [15] Arkko, Calhoun, Patel, Zorn, "DIAMETER Accounting Extension", 463 draft-calhoun-diameter-accounting-04.txt, IETF work in progress, 464 March 2000. 466 8.0 Acknowledgements 468 The authors would also like to acknowledge the following people for 469 their contribution in the development of the DIAMETER protocol: 471 Bernard Aboba, Jari Arkko, William Bulley, Daniel C. Fox, Lol Grant, 472 Ignacio Goyret, Nancy Greene, Peter Heitman, Paul Krumviede, Fergal 473 Ladley, Ryan Moats, Victor Muslin, Kenneth Peirce, Sumit Vakil, John 474 R. Vollbrecht, Jeff Weisberg and Glen Zorn 476 9.0 Authors' Addresses 478 Questions about this memo can be directed to: 480 Pat R. Calhoun 481 Network and Security Research Center, Sun Labs 482 Sun Microsystems, Inc. 483 15 Network Circle 484 Menlo Park, California, 94025 485 USA 487 Phone: 1-650-786-7733 488 Fax: 1-650-786-6445 489 E-mail: pcalhoun@eng.sun.com 491 William Bulley 492 Merit Network, Inc. 494 Building One, Suite 2000 495 4251 Plymouth Road 496 Ann Arbor, Michigan, 48105-2785 497 USA 499 Phone: 1-734-764-9993 500 Fax: 1-734-647-5185 501 E-mail: web@merit.edu 503 Stephen Farrell 504 Baltimore Technologies 505 61/62 Fitzwilliam Lane 506 Dublin 2, 507 IRELAND 509 Phone: +353-1-647-7300 510 Fax: +353-1-647-7499 511 E-Mail: stephen.farrell@baltimore.ie 513 10.0 Full Copyright Statement 515 Copyright (C) The Internet Society (1999). All Rights Reserved. 517 This document and translations of it may be copied and furnished to 518 others, and derivative works that comment on or otherwise explain it 519 or assist in its implementation may be prepared, copied, published and 520 distributed, in whole or in part, without restriction of any kind, 521 provided that the above copyright notice and this paragraph are 522 included on all such copies and derivative works. However, this 523 document itself may not be modified in any way, such as by removing the 524 copyright notice or references to the Internet Society or other Internet 525 organizations, except as needed for the purpose of developing 526 Internet standards in which case the procedures for copyrights defined 527 in the Internet Standards process must be followed, or as required to 528 translate it into languages other than English. The limited permissions 529 granted above are perpetual and will not be revoked by the 530 Internet Society or its successors or assigns. This document and the 531 information contained herein is provided on an "AS IS" basis and THE 532 INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 533 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY 534 THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 535 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 536 PARTICULAR PURPOSE.