idnits 2.17.1 draft-calhoun-diameter-strong-crypto-04.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 12 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 13 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 528 has weird spacing: '... copied and ...' == Line 529 has weird spacing: '...s, and deriv...' == Line 531 has weird spacing: '...ed, in whole...' == Line 532 has weird spacing: '...hat the above...' == Line 534 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) == Unused Reference: '2' is defined on line 428, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 437, but no explicit reference was found in the text == Outdated reference: A later version (-18) exists of draft-calhoun-diameter-16 -- 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-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' == Outdated reference: A later version (-04) exists of draft-ietf-mobileip-aaa-reqs-03 ** 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-03 == Outdated reference: A later version (-06) exists of draft-calhoun-diameter-nasreq-04 -- Possible downref: Normative reference to a draft: ref. '13' == Outdated reference: A later version (-12) exists of draft-calhoun-diameter-mobileip-09 -- Possible downref: Normative reference to a draft: ref. '14' == Outdated reference: A later version (-09) exists of draft-calhoun-diameter-accounting-07 -- Possible downref: Normative reference to a draft: ref. '15' Summary: 13 errors (**), 0 flaws (~~), 19 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-04.txt William Bulley 5 Date: Jule 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 Internet-Draft and is in full conformance with 14 all provisions of Section 10 of RFC2026. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at: 26 http://www.ietf.org/ietf/1id-abstracts.txt 28 The list of Internet-Draft Shadow Directories can be accessed at: 30 http://www.ietf.org/shadow.html. 32 This document is an individual contribution for consideration by the 33 AAA Working Group of the Internet Engineering Task Force. Comments 34 should be submitted to the diameter@diameter.org mailing list. 36 Distribution of this memo is unlimited. 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 adds a digital signature that covers a set of AVPs 119 within 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 ] 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 The CMD-Data AVP defined in Section 3 is a DIAMETER AVP whose 397 identifier was allocated from the AVP numbering space [1], and 398 extended in [13], [14] and [15]. IANA should assign a value of 310 to 399 this AVP. 401 The Result-Code values defined in Section 4.0 are error codes as 402 defined in [1] and extended in [13], [14] and [15]. They correspond 403 to error values specific to the Strong Security extension. IANA 404 should record the values as defined in Section 4.0. 406 6.0 Security Considerations 408 This document describes how strong security can be achieved in the 409 DIAMETER protocol by allowing S/MIME Cryptographic Message Syntax [3] 410 objects to be carried as a DIAMETER AVP. 412 Section 3.0 states that a certificate received in a CMS-Data AVP 413 SHOULD NOT be used prior to cert verification. In most cases, the 414 verification will be according to the rules specified in [4], 415 however, some communities have indicated that they wish to be allowed 416 specify alternative certificate verification mechanisms, hence the 417 "SHOULD NOT" rather than the more typical "MUST NOT". The authors do 418 however strongly RECOMMEND that the verification procedures specified 419 in [4] are always applied, regardless of whatever other verification 420 mechanisms are in use. 422 7.0 References 424 [1] P. Calhoun, A. Rubens, H. Akhtar, E. Guttman, "DIAMETER Base 425 Protocol", draft-calhoun-diameter-16.txt, IETF work in progress, 426 July 2000. 428 [2] Kaufman, Perlman, Speciner, "Network Security: Private Communi- 429 cations in a Public World", Prentice Hall, March 1995, ISBN 0- 430 13-061466-1. 432 [3] R. Housley, "Cryptographic Message Syntax", RFC 2630, June 1999. 434 [4] Housley, Ford, Polk, Solo, "Internet X.509 Public Key Infras- 435 tructure Certificate and CRL Profile", RFC 2459, January 1999. 437 [5] S. Bradner, "Key words for use in RFCs to Indicate Requirement 438 Levels", BCP 14, RFC 2119, March 1997. 440 [6] M. Beadles, D. Mitton, "Criteria for Evaluating Network Access 441 Server Protocols", draft-ietf-nasreq-criteria-05.txt, IETF work 442 in progress, June 2000. 444 [7] T. Hiller et al., "Cdma2000 Wireless Data Requirements for AAA", 445 draft-hiller-cdma2000-AAA-00.txt, IETF work in progress, October 446 1999. 448 [8] S. Glass, S. Jacobs, C. Perkins, "Mobile IP Authentication, 449 Authorization, and Accounting Requirements", draft-ietf- 450 mobileip-aaa-reqs-03.txt, IETF work in progress, March 2000. 452 [9] Myers, Ankney, Malpani, Galperin, Adams, "X.509 Internet Public 453 Key Infrastructure Online Certificate Status Protocol (OCSP)", 454 RFC 2560, June 1999. 456 [10] Aboba, Zorn, "Criteria for Evaluating Roaming Protocols", RFC 457 2477, January 1999. 459 [11] B. Ramsdell, "S/MIME v2 Message Specification", RFC2633, June 460 1999. 462 [12] S. Farrell, R. Housley, "An Internet Attribute Certificate Pro- 463 file for Authorization", draft-ietf-pkix-ac509prof-03.txt, IETF 464 work in progress, May 2000. 466 [13] P. Calhoun, W. Bulley, "DIAMETER NASREQ Extension", draft- 467 calhoun-diameter-nasreq-04.txt, IETF work in progress, July 468 2000. 470 [14] P. Calhoun, C. Perkins, "DIAMETER Mobile IP Extensions", draft- 471 calhoun-diameter-mobileip-09.txt, IETF work in progress, July 472 2000. 474 [15] Arkko, Calhoun, Patel, Zorn, "DIAMETER Accounting Extension", 475 draft-calhoun-diameter-accounting-07.txt, IETF work in progress, 476 July 2000. 478 8.0 Acknowledgements 480 The authors would also like to acknowledge the following people for 481 their contribution in the development of the DIAMETER protocol: 483 Bernard Aboba, Jari Arkko, William Bulley, Daniel C. Fox, Lol Grant, 484 Ignacio Goyret, Nancy Greene, Peter Heitman, Paul Krumviede, Fergal 485 Ladley, Ryan Moats, Victor Muslin, Kenneth Peirce, Sumit Vakil, John 486 R. Vollbrecht, Jeff Weisberg and Glen Zorn 488 9.0 Authors' Addresses 490 Questions about this memo can be directed to: 492 Pat R. Calhoun 493 Network and Security Research Center, Sun Labs 494 Sun Microsystems, Inc. 495 15 Network Circle 496 Menlo Park, California, 94025 497 USA 499 Phone: +1 650-786-7733 500 Fax: +1 650-786-6445 501 E-mail: pcalhoun@eng.sun.com 503 William Bulley 504 Merit Network, Inc. 505 Building One, Suite 2000 506 4251 Plymouth Road 507 Ann Arbor, Michigan, 48105-2785 508 USA 510 Phone: +1 734-764-9993 511 Fax: +1 734-647-5185 512 E-mail: web@merit.edu 514 Stephen Farrell 515 Baltimore Technologies 516 61/62 Fitzwilliam Lane 517 Dublin 2, 518 IRELAND 520 Phone: +353-1-647-7300 521 Fax: +353-1-647-7499 522 E-Mail: stephen.farrell@baltimore.ie 524 10.0 Full Copyright Statement 526 Copyright (C) The Internet Society (1999). All Rights Reserved. 528 This document and translations of it may be copied and furnished to 529 others, and derivative works that comment on or otherwise explain it 530 or assist in its implementation may be prepared, copied, published and 531 distributed, in whole or in part, without restriction of any kind, 532 provided that the above copyright notice and this paragraph are 533 included on all such copies and derivative works. However, this docu- 534 ment itself may not be modified in any way, such as by removing the 535 copyright notice or references to the Internet Society or other Inter- 536 net organizations, except as needed for the purpose of developing 537 Internet standards in which case the procedures for copyrights defined 538 in the Internet Standards process must be followed, or as required to 539 translate it into languages other than English. The limited permis- 540 sions granted above are perpetual and will not be revoked by the 541 Internet Society or its successors or assigns. This document and the 542 information contained herein is provided on an "AS IS" basis and THE 543 INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL 544 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WAR- 545 RANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY 546 RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 547 PARTICULAR PURPOSE."