idnits 2.17.1 draft-ietf-roamops-cert-01.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 106: '...described in [12]. The local RADIUS server MUST support EAP and RADIUS...' RFC 2119 keyword, line 108: '...such as EAP-TLS, described in [11]. The client MUST support EAP as well...' RFC 2119 keyword, line 113: '... the trust chain MUST provide Certific...' RFC 2119 keyword, line 188: '...ion process, the local ISP MAY wish to...' RFC 2119 keyword, line 205: '...lient's EAP type MUST be made based on...' (8 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 29 has weird spacing: '...t>, and expir...' == Line 536 has weird spacing: '...t>, and expir...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (1 April 1999) is 9128 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 458 looks like a reference -- Missing reference section? '8' on line 479 looks like a reference -- Missing reference section? '12' on line 493 looks like a reference -- Missing reference section? '6' on line 473 looks like a reference -- Missing reference section? '2' on line 461 looks like a reference -- Missing reference section? '9' on line 483 looks like a reference -- Missing reference section? '11' on line 489 looks like a reference -- Missing reference section? '7' on line 476 looks like a reference -- Missing reference section? '3' on line 464 looks like a reference -- Missing reference section? '5' on line 471 looks like a reference -- Missing reference section? '10' on line 486 looks like a reference -- Missing reference section? '4' on line 467 looks like a reference Summary: 8 errors (**), 0 flaws (~~), 3 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 ROAMOPS Working Group Bernard Aboba 2 INTERNET-DRAFT Microsoft 3 Category: Best Current Practice 4 5 1 April 1999 7 Certificate-Based roaming 9 1. Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other groups 16 may also distribute working documents as Internet-Drafts. Internet- 17 Drafts are draft documents valid for a maximum of six months and may be 18 updated, replaced, or obsoleted by other documents at any time. It is 19 inappropriate to use Internet-Drafts as reference material or to cite 20 them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 To view the list Internet-Draft Shadow Directories, see 26 http://www.ietf.org/shadow.html. 28 The distribution of this memo is unlimited. It is filed as , and expires October 1, 1999. Please send 30 comments to the authors. 32 2. Copyright Notice 34 Copyright (C) The Internet Society (1999). All Rights Reserved. 36 3. Abstract 38 This document describes how scalable, secure roaming can be supported 39 based on public key certificates, the Extensible Authentication Protocol 40 (EAP), and the RADIUS protocol. The practices described in this 41 document eliminate the use of intermediate proxies, improving 42 scalability and security. They are compliant with the evaluation 43 criteria described in RFC 2477. 45 4. Introduction 47 As noted in [1], existing roaming implementations have largely been 48 based on the concept of proxy chaining, where packets are forwarded 49 between the NAS and home server through a series of proxies. 51 As described in [8], roaming implementations based on proxy chaining 52 typically provide only hop-by-hop authentication and integrity 53 protection. These security weaknesses make proxy-based roaming 54 vulnerable to attack as well as susceptible to misconfiguration. 55 Security threats, described in [8] include theft of service as well as 56 misuse of hidden attributes (such as PAP passwords) by untrusted 57 proxies. Misconfiguration issues include policy implementation and 58 attribute editing, support for RADIUS extensions as described in [12], 59 shared secret maintenance and routing. 61 Note that providing end-to-end security within a proxying scheme further 62 increases the complexity of the system and introduces its own set of 63 issues. For example, in order to allow the end systems to verify message 64 authenticity and integrity, a keyed MAC such as that described in [6] 65 can be used. Alternatively, the packet may be digitally signed. Signing 66 each packet in a AAA exchange is computationally intensive, particularly 67 if EAP authentication is involved. On the other hand, a keyed MAC 68 requires an automated key-exchange mechanism in order to permit 69 deployment on a large scale, and introduces complications with respect 70 to policy implementation. 72 In order to implement policy, it is necessary to permit a proxy to send 73 an Accept-Reject to the NAS in cases where an Access-Accept has been 74 sent by the home server. As described in [8], the home server is 75 notified of this by having the proxy send an Accounting-Request to the 76 home server with Acct-Status=Proxy-Stop. However, with end-to-end 77 security, such policies cannot be implemented, since the NAS cannot 78 accept an Access-Reject that is not authenticated by the end-system 79 (home server). Similarly, the home accounting server cannot accept a 80 non-authenticated Accounting-Request from the proxy, notifying it of the 81 policy action. 83 In addition to security and policy issues, there are performance 84 problems with proxy-based roaming. The introduction of proxy forwarding 85 multiplies the number of packets that must be sent in order to 86 authenticate and authorize the user, increasing login time and 87 increasing the likelihood of a timeout. This problem is particularly 88 severe when EAP authentication is used. 90 For these reasons, as noted in [8], proxy-based roaming is not 91 appropriate for wide-scale use on the Internet. 93 This document describes an alternative to proxy-based roaming which is 94 based on the use of public key certificates and EAP authentication. 95 Since public key authentication allows the local RADIUS server to verify 96 the identity of the client without the need to proxy the authentication, 97 the use of proxies is eliminated while still permitting the local proxy 98 to implement policy. The result is that certificate-based roaming is 99 simpler and easier to implement operationally than proxy-based roaming, 100 as well as being more secure. As a result, certificate-based roaming is 101 ableto meet the criteria outlined in [2] without requiring the 102 development of a new AAA protocol. 104 In order to implement the practices described in this document, the NAS 105 MUST support EAP, described in [9], as well as RADIUS extensions, 106 described in [12]. The local RADIUS server MUST support EAP and RADIUS 107 extensions as well as a public-key authentication authentication method 108 such as EAP-TLS, described in [11]. The client MUST support EAP as well 109 as a public-key authentication method such as EAP-TLS. While there is no 110 requirement that the home server implement EAP, EAP-TLS or even RADIUS, 111 it is necessary for the local RADIUS server to determine that the 112 certificate presented by the client remains valid. As a result, the 113 entities involved in the trust chain MUST provide Certificate Revocation 114 Lists (CRLs). 116 5. Requirements language 118 In this document, the key words "MAY", "MUST, "MUST NOT", "optional", 119 "recommended", "SHOULD", and "SHOULD NOT", are to be interpreted as 120 described in [7]. 122 6. Overview 124 In certificate-based roaming, the client authenticates to the NAS using 125 a public-key certificate-based authentication protocol running over EAP, 126 such as EAP-TLS, described in [11]. In order to permit the NAS to handle 127 a variety of authentication protocols without understanding the details, 128 in EAP [9] the NAS acts as a "pass through" device, forwarding EAP 129 packets between the client and the local ISP RADIUS server, using the 130 RADIUS extensions documented in [12]. 132 A diagram of the authentication, authorization and accounting process is 133 shown below: 135 +------------+ 136 | | 137 | Client | 138 | | 139 +------------+ 140 | 141 PPP | 142 EAP | 143 V 144 +------------+ +------------+ +------------+ 145 | | RADIUS | Local ISP | | Certificate| 146 | NAS |<------>| Auth |<------>| Revocation | 147 | | | Server | | List | 148 +------------+ +------------+ +------------+ 149 | 150 RADIUS | 151 | 152 V 153 +------------+ +------------+ 154 | Local | | Roaming | 155 | ISP | Accounting | Consortium | 156 | Accounting |----------------------------->| Billing | 157 | Server | Data | Server | 158 +------------+ +------------+ 160 Through use of certificate-based authentication, it is possible for the 161 local ISP RADIUS server to verify the user's identity without the need 162 to proxy the authentication to the home server. The use of public key 163 certificates makes this possible, since the local ISP server is capable 164 of verifying that the user has access to the private key corresponding 165 to the public key included on the user's certificate. Note however, that 166 as part of the authentication process, the local ISP server will need to 167 check for revocation of the certificates in the trust chain. Depending 168 on the trust model, one or more Certificate Revocation List (CRL) 169 servers may be contacted.These may include CRL server within the home 170 domain or that of the roaming consortium. 172 Since the home server is not involved in the RADIUS 173 authentication/authorization conversation, the authorization attributes 174 are determined by the local ISP, based on information provided in the 175 authentication process. For example, the local ISP could determine the 176 authorization profile based on the realm included in the Network Access 177 Identifer (NAI) described in [3], or based on the Certifying Authority 178 (CA) included in the user certificate. Today, the most frequently 179 provided roaming service is PPP access to the Internet, so that realm or 180 CA-based authorization is adequate in most cases. Note that per-user 181 authorizations can be supported within certificate-based roaming without 182 requiring the local RADIUS server to proxy the request back to the home 183 server. This can be acomplished via use of attribute certificates. 185 In certificate-based roaming, accounting services can be provided either 186 via session records or in real time via RADIUS Accounting, described in 187 [5]. Note that since the home server is not involved in the 188 authentication and authorization process, the local ISP MAY wish to 189 provide the roaming consortia or home organization a means to audit the 190 accounting information. One possible means of demonstrating the 191 authenticity of the accounting data is to include credentials supplied 192 by the user. 194 6.1. Authentication 196 6.1.1. Authentication conversation 198 As noted in [9], the EAP conversation between the client and NAS 199 typically begins with the NAS sending an EAP-Request/Identity message to 200 the client. The NAS then sends a RADIUS Access-Request to the local ISP 201 RADIUS server, containing an EAP-Message attribute. Based on the Access- 202 Request, the local ISP RADIUS server determines the EAP method to be 203 used, and sends an Access-Challenge containing an EAP-Response attribute 204 to the NAS. Since certificate-based roaming does not involve proxies, 205 the determination of the client's EAP type MUST be made based on the 206 Network Access Identifier (NAI) supplied by the client, as described in 207 [3]. For example, the local ISP RADIUS server MAY be configured to use a 208 given EAP authentication type for all members of a given realm, or it 209 MAY implement a default type. However, since the client certificate has 210 not yet been presented to the local RADIUS server, information on the 211 certificate such as the certificate authority, or other attributes 212 cannot be taken into account in determining the EAP authentication 213 method to be used to authenticate the client. 215 The EAP conversation between the local ISP RADIUS server and the client 216 continues as described in [12] with the NAS serving as a passthrough 217 device until the NAS receives an EAP-Success or EAP-Failure message. 219 In order to implement certificate-based roaming, the client MUST support 220 a certificate-based EAP authentication method such as EAP-TLS, described 221 in [11]. EAP-TLS, which is based on the TLS protocol described in [10], 222 supports mutual authentication as well as key derivation. As a result, 223 it permits the client to authenticate the RADIUS server as well as for 224 the RADIUS server to authenticate the client. Note that since the client 225 is not yet online, it is not possible for it to check for revocation of 226 the server's certificate. However, the client MAY check for server 227 certificate revocation after access has been granted. Since the RADIUS 228 server has Internet connectivity, it MUST check whether the client's 229 certificate has been revoked prior to granting access. 231 6.1.2. Trust models 233 In proxy-based roaming, the home server demonstrates willingness to pay 234 by responding to the proxied Access-Request with an Access-Accept. In 235 certificate-based roaming, the home server is not involved in the 236 authentication/authorization conversation, so that another approach is 237 needed. 239 In order for the local ISP to be willing to grant the client access to a 240 Point of Presence (POP), it is necessary for a chain of trust to be 241 established between the client and the local ISP. In the simplest case 242 this can be accomplished by having the client present a certificate 243 signed by a trusted third party, such as a roaming association to which 244 the local ISP belongs. Note that in order to verify that the client 245 certificate remains valid, the local authentication server MUST check 246 the Certificate Revocation List (CRL) maintained by the certificate 247 authority. For the simple case, this implies that the roaming 248 association would issue and revoke roaming certificates itself. 250 However, rather than dealing with end-users, the roaming association may 251 prefer to only issue roaming certificates to participating ISPs or 252 customers such as BIGCO. This allows the roaming association to 253 delegate roaming certificate issuance and maintenance to other trusted 254 entities. In this case, it is necessary for the client to submit a 255 certificate chain, providing not only the roaming certificate issued by 256 an ISP or company, but also the company or ISP roaming certificate 257 issued by the roaming association. The combination of these roaming 258 certificates then establishes the required chain of trust. 260 Note that the local ISP RADIUS server MUST check for revocation of each 261 certificate presented in the certificate chain. Thus, the local ISP 262 needs to check not only that the user certificate has not been revoked 263 by the home ISP or company, but also that the home ISP or company's 264 certificate has not been revoked by the roaming association. 266 6.2. Authorization and policy 268 Once the client has authenticated, it is necessary for the local RADIUS 269 server to formulate the authorization attributes to be returned to the 270 NAS. These attributes can be determined by information provided during 271 the authentication, such from the NAI realm or the certificate 272 authority, as well as by policy. For example, the local ISP could 273 provide a default set of attributes for all non-local realms, or for all 274 users whose chain of trust includes a given roaming association. It is 275 also possible for the local RADIUS server to modify the attribute set 276 based on policy, i.e. to return a smaller Session-Time when twenty or 277 more users are logged in from a given realm. 279 Note that without attribute certificates it is not possible to support 280 per-user authorizations. For example, if Bob and Jane have certificates 281 signed by the same CA, and if it is desired to treat bob@bigco.com and 282 jane@bigco.com differently, then this cannot be accomplished based 283 solely on the NAI and the certifying authority. Some other information 284 must be brought into play. Since in certificate-based roaming proxying 285 back to the home server is not acceptable, the required input is 286 supplied as part of the user's certificate. 288 6.3. Accounting 290 Once the client has been authenticated and authorized, the local ISP 291 will be interested in obtaining compensation for the use of network 292 resources. In order to accomplish this, the local ISP can use either 293 real-time or batch accounting. 295 When batch accounting is used, the local ISP will transmit session 296 record batches to the settlement agent. In real-time accounting, an 297 Accounting-Request is sent to the settlement agent. As discussed in [8], 298 the settlement agent MAY respond to the request directly, or MAY proxy 299 it to other parties on the roaming relationship path. 301 Note that with certificate-based roaming, the situation differs from the 302 proxy approach in that the systems along the roaming relationship path 303 have not previously participated in a proxied 304 authentication/authorization conversation prior to receiving accounting 305 data. 307 This has several implications. Firstly, the systems receiving the 308 accounting data do not have a means to correlate the accounting 309 information received with a previous authentication event. In the proxy 310 approach, the use of a unique session-ID allows accounting records to be 311 matched up with the corresponding authentication/authorization request. 312 While in certificate-based roaming the local ISP will have contacted the 313 relevant Certificate Revocation List (CRL) servers in order to check for 314 certificate revocation, no session-ID is generated in this conversation 315 that would allow linking to the relevant accounting record. 317 Secondly, using the session-ID, in proxy roaming a home server receiving 318 an accounting record is able to link this back to an authentication 319 conversation in which the user credentials were verified. As a result, 320 barring replay attacks, it is possible to audit whether the accounting 321 data corresponds to an Access-Accept sent by the home server. This 322 provides some degree of protection against fraudulent submission of 323 accounting data on non-existent sessions. 325 To provide equivalent protection in certificate-based roaming, it is 326 necessary for the local ISP to supply user credentials in the accounting 327 data. This permits parties on the roaming relationship path to verify 328 that a valid authentication occurred. In the case of EAP-TLS, this can 329 be accomplished by including the Nonce sent by the server, along with 330 the signed response sent by the client, using the private key. Given 331 these two pieces of information, and access to the client certificate, 332 it is possible for a third party to verify that the client was 333 authenticated. 335 7. RFC 2477 Compliance 337 Certificate-based roaming complies with the evaluation criteria 338 specified in RFC 2477. 340 Connection Management 341 Certificate-based roaming supports PPP, as well as IP and non-IP 342 protocols. 344 Identification 345 Certificate-based roaming supports the NAI as described in [3]. 347 Authentication types 348 Certificate-based roaming is based on EAP and certificate-based 349 authentication protocols such as EAP-TLS. PAP and CHAP are not 350 supported. 352 Scalability 353 Certificate-based roaming is sufficiently scalable to allow the 354 formation of roaming associations with thousands of ISP members. 356 RADIUS Support 357 Certificate-based roaming is compatible with RADIUS-enabled devices 358 implementing EAP [9] and RADIUS extensions [12]. 360 NAS Configuration/Authorization 361 Since in certificate-based roaming authorization parameters are 362 determined by the local RADIUS server, a wide range of 363 authorization profiles and policies may be implemented. 365 Address assignment/routing 366 Certificate-based roaming supports dynamic address assignment. 367 Static address assignment may also be supported via layer 2 or 368 layer 3 tunneling. 370 Layer 2 tunneling protocols 371 Certificate-based roaming is compatible with layer-2 tunneling. 372 Note that without attribute certificates, per-user tunneling cannot 373 be supported. Thus compulsory tunnels may only be brought up based 374 on on information obtained in the authentication, i.e. realm or 375 CA-based tunneling. 377 Layer 3 tunneling protocols 378 Certificate-based roaming is compatible with Mobile IP. 380 Security analysis 381 Certificate-based roaming addresses fraud prevention and detection 382 issues through inclusion of credentials within the accounting 383 packet. 385 Hop by hop security 386 Certificate-based roaming supports hop-by-hop integrity protection 387 and confidentiality via use of IPSEC. 389 End-to-end security 390 As certificate-based roaming does not involve proxies, the 391 authentication conversation occurs solely between the local NAS and 392 the RADIUS server. As a result, policy implementation is supported 393 while eliminating attacks by rogue proxies. 395 8. Security issues 397 The following security threats have been identified in roaming systems: 399 Rogue proxies 400 Theft of passwords 401 Theft of accounting data 402 Replay attacks 403 Connection hijacking 404 Fraudulent accounting 406 Certificate-based roaming reduces or eliminates each of these threats. 408 8.1. Rogue proxies 410 In certificate-based roaming, authentication and authorization 411 terminates at the local ISP RADIUS server. As a result, the risk of 412 rogue proxies is eliminated. 414 8.2. Theft of passwords or keys 416 Since certificate-based roaming only supports certificate-based 417 authentication without proxies, in no circumstance will the local ISP 418 proxy have access to PAP passwords. 420 While a key is generated as part of the EAP-TLS authentication, this can 421 be communicated between the local RADIUS server and the NAS without 422 passing through a proxy. In order to protect the key, IPSEC ESP SHOULD 423 be used between the RADIUS server and the NAS. 425 8.3. Integrity and confidentiality of accounting data 427 Since certificate-based roaming does not involve proxies, integrity and 428 confidentiality of accounting data can be provided via IPSEC. 430 8.4. Connection hijacking 432 Since certificate-based roaming avoids proxying of authentication and 433 authorization, the risk of connection hijacking is reduced. 435 8.5. Fraudulent accounting and replay attacks 437 In order to prevent the local ISP from requesting payment for non- 438 existent sessions, it is desirable for the accounting record to include 439 proof of authentication. This can be provided by including the 440 credentials supplied by the client within the accounting record. For 441 example, in the case of EAP-TLS, the accounting record can include the 442 Nonce supplied by the server, as well as the signature returned by the 443 client that proves the client's possession of the private key 444 corresponding to the client certificate. 446 Since the Nonce will vary with each authentication, it is not possible 447 for the local ISP to replay the authentication. This therefore limits 448 the local ISP's ability to fraudulently claim payment for non-existent 449 sessions. 451 Through use of a signed Nonce, certificate-based roaming prevents 452 accounting for non-existent sessions. Note that as with proxy roaming, 453 no protection is provided against submission of exaggerated session 454 times for actual sessions. 456 9. References 458 [1] Aboba, B., Lu J., Alsop J.,Ding J., and W. Wang, "Review of Roaming 459 Implementations", RFC 2194, September 1997. 461 [2] Aboba, B., and G. Zorn, "Criteria for Evaluating Roaming 462 Protocols", RFC 2477, January 1999. 464 [3] Aboba, B., and M. Beadles, "The Network Access Identifier", 465 RFC 2486, January 1999. 467 [4] Rigney, C., Rubens, A., Simpson, W., Willens, S., "Remote 468 Authentication Dial In User Service (RADIUS)", RFC 2138, April, 469 1997. 471 [5] Rigney, C., "RADIUS Accounting", RFC 2139, April 1997. 473 [6] Rivest, R., Dusse, S., "The MD5 Message-Digest Algorithm", RFC 474 1321, April 1992. 476 [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement 477 Levels", BCP 14, RFC 2119, March 1997. 479 [8] Aboba, B., Vollbrecht, J.R., "Proxy Chaining and Policy 480 Implementation in Roaming", Internet draft (work in progress), 481 draft-ietf-roamops-auth-10.txt, February 1998. 483 [9] Blunk, L., Vollbrecht, J., "PPP Extensible Authentication Protocol 484 (EAP)", RFC 2284, March 1998. 486 [10] Dierks, T., Allen, C., "The TLS Protocol Version 1.0", RFC 2246, 487 November 1998. 489 [11] Aboba, B., Simon, D., "PPP EAP TLS Authentication Protocol", draft- 490 ietf-pppext-eaptls-05.txt, Internet Draft (work in progress), 491 January 1999. 493 [12] Rigney, C., Willens, S., Calhoun, P., "RADIUS Extensions", draft- 494 ietf-radius-ext-03.txt, Internet Draft (work in progress), January 495 1999. 497 10. Acknowledgments 499 Thanks to Ashwin Palekar of Microsoft for useful discussions of this 500 problem space. 502 11. Authors' Addresses 504 Bernard Aboba 505 Microsoft Corporation 506 One Microsoft Way 507 Redmond, WA 98052 509 Phone: 206-936-6605 510 EMail: bernarda@microsoft.com 512 12. Full Copyright Statement 514 Copyright (C) The Internet Society (1999). All Rights Reserved. 515 This document and translations of it may be copied and furnished to 516 others, and derivative works that comment on or otherwise explain it or 517 assist in its implmentation may be prepared, copied, published and 518 distributed, in whole or in part, without restriction of any kind, 519 provided that the above copyright notice and this paragraph are included 520 on all such copies and derivative works. However, this document itself 521 may not be modified in any way, such as by removing the copyright notice 522 or references to the Internet Society or other Internet organizations, 523 except as needed for the purpose of developing Internet standards in 524 which case the procedures for copyrights defined in the Internet 525 Standards process must be followed, or as required to translate it into 526 languages other than English. The limited permissions granted above are 527 perpetual and will not be revoked by the Internet Society or its 528 successors or assigns. This document and the information contained 529 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 530 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 531 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 532 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 533 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 534 13. Expiration Date 536 This memo is filed as , and expires 537 October 1, 1999.