idnits 2.17.1 draft-ietf-pppext-otp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 Internet-Drafts being working documents -- 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 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. == The 'Updates: ' line in the draft header should list only the _numbers_ of the RFCs which will be updated by this document (if approved); it should not include the word 'RFC' in the list. -- The draft header indicates that this document updates RFC2284, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 64 has weird spacing: '...ication mecha...' == Line 489 has weird spacing: '...>, and expir...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Type-Data field contains the OTP "challenge" as a displayable message in the Request. In the Response, this field is used for the 6 words from the OTP dictionary [4]. The messages MUST not be null terminated. The length of the field is derived from the Length field of the Request/Reply packet. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Type-Data field in the Request contains a displayable message greater than zero octets in length. The length of the message is determined by Length field of the Request packet. The message MUST not be null terminated. A Response MUST be sent in reply to the Request with a Type field of 6 (Generic Token Card). The Response contains data from the Token Card required for authentication. The length is of the data is determined by the Length field of the Response packet. (Using the creation date from RFC2284, updated by this document, for RFC5378 checks: 1995-03-27) -- 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 282, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 285, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 300, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 305, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 311, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 315, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 322, but no explicit reference was found in the text == Unused Reference: '17' is defined on line 342, but no explicit reference was found in the text == Unused Reference: '18' is defined on line 345, but no explicit reference was found in the text == Unused Reference: '19' is defined on line 348, but no explicit reference was found in the text == Unused Reference: '20' is defined on line 351, but no explicit reference was found in the text == Unused Reference: '21' is defined on line 354, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1700 (ref. '2') (Obsoleted by RFC 3232) ** Obsolete normative reference: RFC 1938 (ref. '4') (Obsoleted by RFC 2289) ** Obsolete normative reference: RFC 2044 (ref. '5') (Obsoleted by RFC 2279) -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' -- Possible downref: Non-RFC (?) normative reference: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' ** Obsolete normative reference: RFC 2716 (ref. '15') (Obsoleted by RFC 5216) ** Obsolete normative reference: RFC 2402 (ref. '17') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. '18') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2407 (ref. '19') (Obsoleted by RFC 4306) ** Obsolete normative reference: RFC 2401 (ref. '20') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2409 (ref. '21') (Obsoleted by RFC 4306) == Outdated reference: A later version (-10) exists of draft-ietf-pppext-rfc2284bis-00 Summary: 15 errors (**), 0 flaws (~~), 21 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPPEXT Working Group L. Blunk 3 INTERNET-DRAFT Merit Networks, Inc. 4 Category: Standards Track J. Vollbrecht 5 Interlink Networks, Inc. 6 6 October 2001 Bernard Aboba 7 Updates: RFC 2284 Microsoft 9 The One Time Password (OTP) and Generic Token Card Authentication Protocols 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. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference material 21 or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Copyright Notice 31 Copyright (C) The Internet Society (2001). All Rights Reserved. 33 Abstract 35 EAP is an authentication protocol which supports multiple authentication 36 mechanisms. EAP typically runs directly over the link layer without 37 requiring IP and therefore includes its own support for in-order 38 delivery and re-transmission. While EAP was originally developed for 39 use with PPP, it is also now in use with IEEE 802. This document defines 40 the One Time Password (OTP) and Generic Token Card EAP methods. 42 Table of Contents 44 1. Introduction .......................................... 3 45 1.1 Specification of Requirements ................... 3 46 1.2 Terminology ..................................... 3 47 2. Packet Format ......................................... 4 48 2.1 EAP Request Packet .............................. 5 49 2.2 EAP Response Packet ............................. 6 50 2.3 One-Time Password ............................... 6 51 2.4 Generic Token Card .............................. 7 52 3. References ............................................ 8 53 4. Security considerations ............................... 9 54 4.1 Packet modification attacks ........................... 10 55 4.2 Implementation dependence ............................. 10 56 4.3 Mutual authentication ................................. 10 57 4.4 Confidentiality ...................................... 11 58 ACKNOWLEDGMENTS .............................................. 11 59 AUTHORS' ADDRESSES ........................................... 11 60 Full Copyright Statement ..................................... 12 61 1. Introduction 63 EAP, defined in [22], is an authentication protocol which supports 64 multiple authentication mechanisms. EAP typically runs directly over 65 the link layer without requiring IP and therefore includes its own 66 support for in-order delivery and re-transmission. While EAP was 67 originally developed for use with PPP [1], it is also now in use with 68 IEEE 802 [7]. The encapsulation of EAP on IEEE 802 link layers is 69 defined in [13]. This document defines the One Time Password (OTP) and 70 Generic Token Card EAP methods. 72 1.1. Specification of Requirements 74 In this document, several words are used to signify the requirements of 75 the specification. These words are often capitalized. The key words 76 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD 77 NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 78 interpreted as described in RFC 2119 [6]. 80 1.2. Terminology 82 This document frequently uses the following terms: 84 Authenticator 85 The end of the link requiring the authentication. 87 Peer The other end of the point-to-point link (PPP), point-to-point 88 LAN segment (IEEE 802.1X) or 802.11 wireless link, which being 89 authenticated by the Authenticator. In IEEE 802.1X, this end 90 is known as the Supplicant. 92 Authentication Server 93 An Authentication Server is an entity that provides an 94 Authentication Service to an Authenticator. This service 95 verifies from the credentials provided by the peer, the claim 96 of identity made by the peer. 98 Port Access Entity (PAE) 99 The protocol entity associated with a physical or virtual 100 (802.11) Port. A given PAE may support the protocol 101 functionality associated with the Authenticator, peer or both. 103 Silently Discard 104 This means the implementation discards the packet without 105 further processing. The implementation SHOULD provide the 106 capability of logging the error, including the contents of the 107 silently discarded packet, and SHOULD record the event in a 108 statistics counter. 110 Displayable Message 111 This is interpreted to be a human readable string of 112 characters, and MUST NOT affect operation of the protocol. 113 The message encoding MUST follow the UTF-8 transformation 114 format [5]. 116 2. Packet Format 118 A summary of the EAP OTP and Generic Token Card Request/Response packet 119 format is shown below. The fields are transmitted from left to right. 121 0 1 2 3 122 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 123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 | Code | Identifier | Length | 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 | Type | Data... 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 Code 131 1 - Request 132 2 - Response 134 Identifier 136 The identifier field is one octet and aids in matching responses with 137 requests. 139 Length 141 The Length field is two octets and indicates the length of the EAP 142 packet including the Code, Identifier, Length, Type, and Data fields. 143 Octets outside the range of the Length field should be treated as 144 Data Link Layer padding and should be ignored on reception. 146 Type 148 5 - OTP 6 - Generic Token Card 150 Data 152 The format of the Data field is determined by the Code field. 154 2.1. EAP Request Packet 156 A summary of the EAP Request packet format is shown below. The fields 157 are transmitted from left to right. 159 0 1 2 3 160 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 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Code | Identifier | Length | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Type | Type-Data... 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 Code 169 1 171 Identifier 173 The Identifier field is one octet and aids in matching responses with 174 requests. The Identifier field MUST be changed on each Request 175 packet. 177 Length 179 The Length field is two octets and indicates the length of the EAP 180 packet including the Code, Identifier, Length, Type, and TLS Response 181 fields. 183 Type 185 5 - OTP 6 - Generic Token Card 187 Type-Data 189 The format of the Type-Data field is determined by the Code and Type 190 fields. 192 2.2. EAP Response Packet 194 A summary of the EAP OTP And Generic Token Card Response packet format 195 is shown below. The fields are transmitted from left to right. 197 0 1 2 3 198 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 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Code | Identifier | Length | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Type | Type-Data... 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 Code 207 2 209 Identifier 211 The Identifier field is one octet and MUST match the Identifier field 212 from the corresponding request. 214 Length 216 The Length field is two octets and indicates the length of the EAP 217 packet including the Code, Identifir, Length, Type, and TLS data 218 fields. 220 Type 222 5 - OTP 6 - Generic Token Card 224 Type-Data 226 The format of the Type-Data field is determined by the Code and Type 227 fields. 229 2.3. One-Time Password (OTP) 231 Description 233 The One-Time Password system is defined in "A One-Time Password 234 System" [4]. The Request contains a displayable message containing 235 an OTP challenge. A Response MUST be sent in reply to the Request. 236 The Response MUST be of Type 5 (OTP) or Type 3 (Nak). The Nak reply 237 indicates the peer's desired authentication mechanism Type. 239 Type 241 5 243 Type-Data 245 The Type-Data field contains the OTP "challenge" as a displayable 246 message in the Request. In the Response, this field is used for the 247 6 words from the OTP dictionary [4]. The messages MUST not be null 248 terminated. The length of the field is derived from the Length field 249 of the Request/Reply packet. 251 2.4. Generic Token Card 253 Description 255 The Generic Token Card Type is defined for use with various Token 256 Card implementations which require user input. The Request contains 257 an ASCII text message and the Reply contains the Token Card 258 information necessary for authentication. Typically, this would be 259 information read by a user from the Token card device and entered as 260 ASCII text. 262 Type 264 6 266 Type-Data 268 The Type-Data field in the Request contains a displayable message 269 greater than zero octets in length. The length of the message is 270 determined by Length field of the Request packet. The message MUST 271 not be null terminated. A Response MUST be sent in reply to the 272 Request with a Type field of 6 (Generic Token Card). The Response 273 contains data from the Token Card required for authentication. The 274 length is of the data is determined by the Length field of the 275 Response packet. 277 3. References 279 [1] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, 280 July 1994. 282 [2] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, 283 October 1994. 285 [3] Simpson, W., "PPP Challenge Handshake Authentication Protocol 286 (CHAP)", RFC 1994, August 1996. 288 [4] Haller, N. and C. Metz, "A One-Time Password System", RFC 1938, May 289 1996. 291 [5] Yergeau, F., "UTF-8, a transformation format of Unicode and ISO 292 10646", RFC 2044, October 1996. 294 [6] Bradner, S., "Key words for use in RFCs to Indicate Requirement 295 Levels", RFC 2119, March 1997. 297 [7] IEEE Standards for Local and Metropolitan Area Networks: Overview 298 and Architecture, ANSI/IEEE Std 802, 1990. 300 [8] ISO/IEC 10038 Information technology - Telecommunications and 301 information exchange between systems - Local area networks - Media 302 Access Control (MAC) Bridges, (also ANSI/IEEE Std 802.1D- 1993), 303 1993. 305 [9] ISO/IEC Final CD 15802-3 Information technology - Tele- 306 communications and information exchange between systems - Local and 307 metropolitan area networks - Common specifications - Part 3:Media 308 Access Control (MAC) bridges, (current draft available as IEEE 309 P802.1D/D15). 311 [10] IEEE Standards for Local and Metropolitan Area Networks: Draft 312 Standard for Virtual Bridged Local Area Networks, P802.1Q/D8, 313 January 1998. 315 [11] ISO/IEC 8802-3 Information technology - Telecommunications and 316 information exchange between systems - Local and metropolitan area 317 networks - Common specifications - Part 3: Carrier Sense Multiple 318 Access with Collision Detection (CSMA/CD) Access Method and 319 Physical Layer Specifications, (also ANSI/IEEE Std 802.3- 1996), 320 1996. 322 [12] IEEE Standards for Local and Metropolitan Area Networks: Demand 323 Priority Access Method, Physical Layer and Repeater Specification 324 For 100 Mb/s Operation, IEEE Std 802.12-1995. 326 [13] IEEE Standards for Local and Metropolitan Area Networks: Port based 327 Network Access Control, IEEE Std 802.1X-2001, June 2001. 329 [14] Information technology - Telecommunications and information 330 exchange between systems - Local and metropolitan area networks - 331 Specific Requirements Part 11: Wireless LAN Medium Access Control 332 (MAC) and Physical Layer (PHY) Specifications, IEEE Std. 333 802.11-1997, 1997. 335 [15] Aboba, B., Simon, D.,"PPP EAP TLS Authentication Protocol", RFC 336 2716, October 1999. 338 [16] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and 339 Palter, B., "Layer Two Tunneling Protocol L2TP", RFC 2661, August 340 1999. 342 [17] Kent,S., Atkinson, R., "IP Authentication Header", RFC 2402, 343 November 1998. 345 [18] Kent,S., Atkinson, R., "IP Encapsulating Security Payload (ESP)", 346 RFC 2406, November 1998. 348 [19] Piper, D., "The Internet IP Security Domain of Interpretation of 349 ISAKMP", RFC 2407, November 1998. 351 [20] Atkinson, R., Kent, S., "Security Architecture for the Internet 352 Protocol", RFC 2401, November 1998. 354 [21] Harkins, D., Carrel, D., "The Internet Key Exchange (IKE)", RFC 355 2409, November 1998. 357 [22] Blunk, L, Vollbrecht, J., Aboba, B., "Extensible Authentication 358 Protocol (EAP)", Internet draft (work in progress), draft-ietf- 359 pppext-rfc2284bis-00.txt, October 2001. 361 4. Security Considerations 363 Security issues are the primary topic of this RFC. Known security issues 364 with EAP include: 366 Packet modification attacks 367 Implementation dependence 368 Mutual authentication 369 Confidentiality 371 4.1. Packet modification attacks 373 While individual EAP methods such as [15] may provide for authentication 374 and integrity protection of material sent within the data portion of an 375 EAP message, EAP does not provide built-in support for authentication or 376 integrity protection. This means that an attacker may modify all or 377 portions of EAP messages, including Request and Response messages of 378 types Identity, Notification, Nak, OTP, and Generic Token Card and 379 Success and Failure messages. The assumption is that physical access to 380 the link is restricted, so that such attacks are unlikely. 382 Where EAP is run over IP, such as within protocols supporting PPP or 383 Ethernet tunneling [16], this assumption is no longer valid. In this 384 case, the EAP exchange MUST be authenticated and integrity protected, 385 using a mechanism such as IPsec [17]-[21]. 387 4.2. Implementation dependence 389 The interaction of authentication protocols with link layer technologies 390 such as PPP and IEEE 802 are highly implementation dependent. 392 For example, upon failure of authentication, some PPP implementations do 393 not terminate the link, instead limiting the kind of traffic in the 394 Network-Layer Protocols to a filtered subset, which in turn allows the 395 user opportunity to update secrets or send mail to the network 396 administrator indicating a problem. Similarly, while in IEEE 802.1X an 397 authentication failure will result denied access to the controlled port, 398 limited traffic may be permitted on the uncontrolled port. 400 In EAP there is no provision for retries of failed authentication. 401 However, in PPP the LCP state machine can renegotiate the authentication 402 protocol at any time, thus allowing a new attempt. Similarly, in IEEE 403 802.1X the supplicant or Authenticator can re-authenticate at any time. 404 It is recommended that any counters used for authentication failure not 405 be reset until after successful authentication, or subsequent 406 termination of the failed link. 408 4.3. Mutual authentication 410 In EAP there is no requirement that authentication be full duplex or 411 that the same protocol be used in both directions. It is perfectly 412 acceptable for different protocols to be used in each direction. This 413 will, of course, depend on the specific protocols negotiated. If a one- 414 way authentication method is negotiated, such as OTP or Generic Token 415 Card then the Authenticator's identity will not be verified. 417 For wireless media such as 802.11 [14], where physical security can no 418 longer be assumed, mutual authentication is recommended in order to 419 guard against rogue access points. 421 4.4. Confidentiality 423 Neither the OTP nor the Generic Token card methods derive session keys 424 for use with per-packet authentication, integrity protection or 425 confidentiality. Typically, this means that subsequent data traffic 426 will either utilize static session keys, or will be unprotected. If the 427 latter, then the data traffic will be vulnerable to a wide variety of 428 attacks, including traffic insertion and session hijacking. 430 Acknowledgments 432 Al Rubens (Merit) also provided valuable feedback on this document, as 433 did Glen Zorn (Cisco) and Ashwin Palekar (Microsoft). 435 Authors' Addresses 437 Larry J. Blunk 438 Merit Network, Inc. 439 4251 Plymouth Rd., Suite C 440 Ann Arbor, MI 48105 442 EMail: ljb@merit.edu 443 Phone: 734-763-6056 444 FAX: 734-647-3185 446 John R. Vollbrecht 447 Interlink Networks, Inc. 448 775 Technology Drive, Suite 200 449 Ann Arbor, MI 48108 450 USA 452 Phone: +1 734 821 1205 453 Fax: +1 734 821 1235 454 EMail: jrv@interlinknetworks.com 456 Bernard Aboba 457 Microsoft Corporation 458 One Microsoft Way 459 Redmond, WA 98052 461 EMail: bernarda@microsoft.com 462 Phone: +1 425 936 6605 463 Fax: +1 425 936 7329 464 Full Copyright Statement 466 Copyright (C) The Internet Society (2001). All Rights Reserved. 467 This document and translations of it may be copied and furnished to 468 others, and derivative works that comment on or otherwise explain it or 469 assist in its implementation may be prepared, copied, published and 470 distributed, in whole or in part, without restriction of any kind, 471 provided that the above copyright notice and this paragraph are included 472 on all such copies and derivative works. However, this document itself 473 may not be modified in any way, such as by removing the copyright notice 474 or references to the Internet Society or other Internet organizations, 475 except as needed for the purpose of developing Internet standards in 476 which case the procedures for copyrights defined in the Internet 477 Standards process must be followed, or as required to translate it into 478 languages other than English. The limited permissions granted above are 479 perpetual and will not be revoked by the Internet Society or its 480 successors or assigns. This document and the information contained 481 herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 482 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 483 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 484 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 485 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 487 Expiration Date 489 This memo is filed as , and expires 490 April 19, 2002.