Internet DRAFT - draft-hiller-aaa-diamaka

draft-hiller-aaa-diamaka






  Authentication, Authorization, and Accounting                Tom Hiller 
  Internet Draft                                          Peter J. McCann 
  Document: draft-hiller-aaa-diamaka-00.txt           Lucent Technologies 
  Category: Informational                                  February, 2001 
   
   
       DIAMETER Support for Authentication and Key Agreement (AKA) 
   
   
  Status of this Memo 
   
     This document is an Internet-Draft and is in full conformance with 
     all provisions of Section 10 of RFC2026 [1].  
      
     Internet-Drafts are working documents of the Internet Engineering 
     Task Force (IETF), its areas, and its working groups. Note that 
     other groups may also distribute working documents as Internet-
     Drafts. Internet-Drafts are draft documents valid for a maximum of 
     six months and may be updated, replaced, or obsoleted by other 
     documents at any time. It is inappropriate to use Internet- Drafts 
     as reference material or to cite them other than as "work in 
     progress."  
      
     The list of current Internet-Drafts can be accessed at 
     http://www.ietf.org/ietf/1id-abstracts.txt  
      
     The list of Internet-Draft Shadow Directories can be accessed at 
     http://www.ietf.org/shadow.html. 
      
   
  1. Abstract 
      
     The Authentication and Key Agreement (AKA) protocol is a widely 
     used mechanism for authenticating mobile nodes in wireless 
     networks.  This draft proposes new DIAMETER AVPs to carry AKA 
     parameters, which will enable DIAMETER to serve as an inter-domain 
     transport mechanism for AKA messages. 
      
     Because AKA was designed for a slightly different trust 
     environment than that likely to be encountered in a DIAMETER-based 
     network, we also discuss how AKA can be deployed in a DIAMETER 
     environment to provide additional authenticity guarantees. 
      
      
  2. Conventions used in this document 
      
     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
     NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and 
     "OPTIONAL" in this document are to be interpreted as described in 
     RFC-2119 [2]. 
      
      

    
  Hiller, McCann      Informational - Expires 8/2001                   1 

                               DIAMETER AKA               February, 2001 
   
   
  3. Introduction 
      
     Authentication and Key Agreement (AKA) is a mutual authentication 
     algorithm involving a set of message exchanges between mobile node 
     (MN) and entities in the visited and home network.  The basic 
     Authentication and Key Agreement (AKA) protocol is described in 
     the 3GPP document 3G TS 33.102 [3].  A by-product of AKA operation 
     is the generation of integrity and encryption keys.  Wireless SDOs 
     such as 3GPP and 3GPP2 plan to support AKA as the primary means of 
     authenticating mobile nodes.  AKA extensions have already been 
     proposed for SIP [4]. 
      
     3GPP2 plans to support authentication and authorization via the 
     use of DIAMETER.  DIAMETER support is being considered in 3GPP. 
     This contribution proposes extensions to DIAMETER that will allow 
     it to serve as a transport for AKA parameters during the 
     authentication procedure. For ease of reading, DIAMETER augmented 
     with AKA extensions is simply referred to in this contribution as 
     ˘DIAMETER AKA÷. 
      
      
  4. Overview of AKA 
      
     AKA is a 3-party protocol that takes place between a client, a 
     service provider, and a home authentication center.  For the 
     explanation below, we assume that the service being used is basic 
     network access as in todayĂs cellular network; that the service 
     provider is a visited wireless carrier; and that the home 
     authentication center is associated with a home network.  In this 
     case the client is a mobile node (MN), which will carry out AKA 
     negotiation with a visited AAA server (VAAA), which will in turn 
     communicate with a home AAA server (HAAA).  However, the reader 
     should keep in mind that AKA is a generic authentication and key 
     agreement mechanism that could be used for other types of 
     services, as outlined in later sections of this document.  In this 
     section we assume that the protocol used to carry AKA parameters 
     between the client and service provider is some wireless link 
     layer, but in other scenarios the particular protocol used may 
     differ.  For all scenarios, we assume that DIAMETER is the 
     protocol of choice between VAAA and HAAA. 
      
     Initially, the MN is given an identity, which in cellular 
     applications is the IMSI, and a secret K that it shares with HAAA.  
     Upon connecting to the visited network, the MN transmits this 
     identity to the VAAA.  The VAAA uses the identity to locate the 
     HAAA and make an authentication data request, which returns a set 
     of authentication vectors (AVs) from the home network.  
      
     Each AV contains a set of parameters (RAND, XRES, CK, IK, AUTN).  
     RAND is a random number generated by the home network.  XRES is 
    
  Hiller, McCann      Informational - Expires 8/2001                   2 

                               DIAMETER AKA               February, 2001 
   
   
     the expected response from the MN that would indicate a successful 
     authentication.  CK and IK are the Cipher Key and Integrity Key 
     that should be used to protect the subsequent link layer data, 
     assuming authentication was successful.  The MN derives CK and IK 
     by applying a key generating function to RAND, using the shared 
     secret K known to the MN and HAAA.  Finally, AUTN is itself 
     another vector consisting of the elements (SQN+AK, AMF, MAC).  
     Here SQN+AK is a monotonically increasing sequence number SQN 
     XORed with an Anonymity Key AK, which is computed as a secure hash 
     of RAND.  AMF is a key management field that is used during re-
     synchronization procedures and for other purposes.  Finally, MAC 
     is a message authentication code computed over SQN, RAND, and AMF.  
     All secure hashes (key generating and message authentication 
     functions) are parameterized by the secret key K, so they are 
     unique to a given mobile node. 
      
     Upon receipt of the AV set, the VAAA chooses the next AV and 
     transmits (RAND, AUTN) from the AV to the MN.  Note that CK and IK 
     are not transmitted to the MN.  However, because the MN possesses 
     the secret key K, it can derive the AK from RAND and hence can 
     derive the SQN from the SQN+AK present in AUTN.  This allows the 
     MN to compute an expected value for MAC based on the inputs SQN, 
     RAND, and AMF, and to compare this to the MAC received in AUTN.  
     If the result matches, and if the sequence number SQN is in an 
     acceptable range relative to the last authentication that was 
     performed, the MN can verify that the VAAA did indeed get the AV 
     from HAAA.  This provides some assurance that the MN is 
     communicating with a legitimate visited network. 
      
     Now the MN must prove its identity to the VAAA.  It does so by 
     computing RES, which is a simple message authentication function 
     applied to RAND. It transmits this value to VAAA, which compares 
     it to XRES.  If the values match, the VAAA can assume that it is 
     communicating with a legitimate MN that is in possession of the 
     secret key K used to generate the AV. Also, it is now in agreement 
     on CK and IK that are used to encrypt and authenticate data to and 
     from the MN for the link layer session. 
      
      
  5. Trust Model Issues 
      
     The AKA protocol provides the proper guarantees for the 
     environment in which it was designed to operate: that of a fairly 
     small number of wireless operators communicating over a secure 
     network, and with a large degree of trust among the various 
     carriers.  However, as we move to an all-IP wireless network, 
     there are likely to be many more carriers supporting different 
     types of access networks, and they will be interconnected by a 
     network of brokers each of whom acts as a manager for many pair-
     wise trust relationships.  As such, there may not be a direct 
    
  Hiller, McCann      Informational - Expires 8/2001                   3 

                               DIAMETER AKA               February, 2001 
   
   
     contractual or trust relationship between the VAAA and HAAA when a 
     MN roams to a given visited network. 
      
     In particular, AKA allows the comparison of RES with XRES to be 
     performed completely in the VAAA.  This gives the HAAA no 
     assurance that a legitimate MN was actually connected to VAAA.  
     For this reason we propose that AKA authentication with DIAMETER 
     proceed in two steps, one which retrieves AUTN but does not expose 
     XRES to the VAAA, and a second round-trip where the home network 
     can actually compare RES to XRES.  Then the HAAA can return a 
     DIAMETER Access-Accept or -Reject as appropriate to the VAAA.  
     This would be in accordance with usual IETF AAA based 
     authentication models.   
      
     This extra step introduces an additional round-trip through the 
     AAA infrastructure. A potential remedy to this situation would be 
     to alter AKA protocol such that the MN includes self-contained 
     authentication credentials, based on a timestamp, sequence number, 
     and random value.  When this request is presented to the HAAA, the 
     HAAA can immediately verify the identity of the MN and release a 
     set of standard AKA AV (i.e., including XRES) to the VAAA.  The 
     VAAA then compares RES with XRES in the subsequent response from 
     the MN. This solution would have improved latency, but it implies 
     a change to the basic AKA protocol, which may not be possible in a 
     legacy environment. 
      
      
  6. Application Scenarios 
      
     Figures 1-3 identify application scenarios for DIAMETER AKA in an 
     all-IP wireless network.  
      
     Figure 1 shows a mobile using AKA for device level authentication.  
     Note that in this scenario, the keys IK and CK could be used for 
     over-the-air encryption and integrity protection of data and 
     signaling traffic.  This is because the HAAA provides CK and IK to 
     the VAAA via the Authentication Vector (AV), which, in turn, 
     passes the AV to the link layer access network element.  
      
     Figure 2 shows a legacy (circuit voice) mobile node connecting to 
     a network that supports DIAMETER AKA.  This network contains a 
     VAAA that communicates with an HAAA via DIAMETER.  The HAAA may 
     gateway the AKA parameters to a legacy HLR-based authentication 
     center to which the mobile node is homed.  
      
     Figure 3 shows a mobile with a SIP client being authenticated by a 
     SIP server. The SIP registrations contain AKA extensions. The SIP 
     server generates DIAMETER AKA messages directly.  The SIP server 
     could be in a wireless carrier network, private network, or the 
     network of a third party provider. N.B. The 3GPP and 3GPP2 SDOs 
    
  Hiller, McCann      Informational - Expires 8/2001                   4 

                               DIAMETER AKA               February, 2001 
   
   
     place the authenticating SIP server only in the home network. In 
     this case there might not be a need for an interdomain AAA 
     protocol. However, we show this scenario to cover other 
     relationships that might exist between a SIP server and the home 
     network.   
      
      











































    
  Hiller, McCann      Informational - Expires 8/2001                   5 

                               DIAMETER AKA               February, 2001 
   
   
      

                             +-------------+       +-------------+           
                             |             |       |             |           
                             |   VAAA      +-------+    HAAA                 
                             |             |       |             |           
                             +------+------+       +-------------+           
                                    |                                        
                                    |                                        
              +----------+   +------+------+                                 
              |          |   | Radio       |                                 
              | Mobile   +---+ Access      |                                 
              | Station  |   | Network     |                                 
              +----------+   +-------------+                                 

                     Figure 1: Network Access using DIAMETER-AKA


                             +-------------+       +-------------+           
                             |             |       |             |           
                             |   VAAA      +-------|HAAA/Gateway |           
                             |             |       |             |           
                             +-----+-------+       +-------\-----+           
                                   |                        \                
                                   |                  +------\------+        
              +----------+  +------+------+           |             |        
              | Mobile   |  | Radio Access|           |     HLR     |        
              | Station  +--+ Network     |           |             |        
              |          |  |             |           +-------------+        
              +----------+  +-------------+                                  
    
                    Figure 2: Network Access using Legacy HLR
                                                                             

                             +-------------+       +-------------+           
                             |             |       |             |           
                             |   VAAA      +-------+    HAAA                 
                             |             |       |             |           
                             +-----+-------+       +-------------+           
                                   |                                         
                                   |                                         
              +----------+  +------+------+                                  
              | Mobile   |  | SIP         |                                  
              | Station  +--+ Server      |                                  
              |          |  |             |                                  
              +----------+  +-------------+                                  
   
             Figure 3:  Application-layer (SIP) access using DIAMETER AKA.

    
  Hiller, McCann      Informational - Expires 8/2001                   6 

                               DIAMETER AKA               February, 2001 
   
   
      
     In all cases, the following statements apply:   
      
     - The mobile and network entity or entities involved mutually 
       authenticate each other.  
        
     - The mobile and some participating entity in the network may use 
       keys derived from AKA message exchanges (i.e., the AV) for 
       integrity or encryption purposes.  This could apply to data link 
       layer or application layer protection mechanisms.  
      
      
  7. Protocol Extensions 
      
     Section 5 outlined two approaches. The first approach requires two 
     traversals and places the RES and XRES comparison in the HAAA 
     (i.e. the HAAA does not send the XRES in the AV to the VAAA). The 
     second approach requires only one traversal but relies on a 
     challenge from the VAAA followed by a corresponding response from 
     the MN.  
      
     The AKA Request AVP is given in Figure 4. It is an optional AVP 
     for use only when the MN supports the response to a global 
     challenge in its initial request for service. If not then only the 
     NAI AVP is present in the Access Request, which may require the 
     HAAA to withhold XRES in its response, forcing a two round trip 
     authentication procedure. 
      
     The AKA Response AVP is given in Figure 5. It is used to supply 
     the VAAA with the random challenge plus authentication information 
     to be sent to the MN.  
      
     The AKA Keys AVP is given in Figure 6. It is used to supply 
     encryption and integrity keys to the VAAA after the HAAA has 
     verified the identity of the MN. It may be included in the first 
     response if the AKA Request AVP was included in the initial 
     request from the VAAA.  Otherwise it should only be included in a 
     second response to the VAAA after the HAAA has compared RES with 
     XRES.  
      
                                                                             
     The AKA Request Result AVP is given in Figure 7.  This is used
     during the two-round AKA protocol to communicate the MN's response
     to the HAAA.                                                                        






    
  Hiller, McCann      Informational - Expires 8/2001                   7 

                               DIAMETER AKA               February, 2001 
   
   
                                                   

     0                   1                   2                   3           
     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         
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|        
    |                      AVP Code                                 |        
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+        
    | AVP Length                    |Reserved             |P|R|V|R|M|        
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+        
    |                                                               |        
    +                                                               +        
    |                                                               |        
    +                           G-RAND                              +        
    |                                                               |        
    +                                                               +        
    |                                                               |        
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+        
    |                                                               |        
    +                                                               +        
    |                                                               |        
    +                           AUTHR                               +        
    |                                                               |        
    +                                                               +        
    |                                                               |        
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+        
      
                           Figure 4: AKA Request AVP 
                                                                             
                                                                             
                                                  



















    
  Hiller, McCann      Informational - Expires 8/2001                   8 

                               DIAMETER AKA               February, 2001 
   
   
                              
                                                                              
                                                                             
                                                                             

    0                   1                   2                   3            
    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          
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|         
   |                      AVP Code                                 |         
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         
   | AVP Length                    |Reserved             |P|R|V|R|M|         
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         
   |                                                               |         
   +                                                               +         
   |                                                               |         
   +                           RAND                                +         
   |                                                               |         
   +                                                               +         
   |                                                               |         
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         
   |                                                               |         
   +       SQN+AK                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         
   |                               |          AMF                  |         
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         
   |                                                               |         
   +                                                               +         
   |                                                               |         
   +                            MAC                                +         
   |                                                               |         
   +                                                               +         
   |                                                               |         
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+          

                           Figure 5: AKA Response AVP 
      
                        












    
  Hiller, McCann      Informational - Expires 8/2001                   9 

                               DIAMETER AKA               February, 2001 
   
   
                                                        

    0                   1                   2                   3            
    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          
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|         
   |                      AVP Code                                 |         
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         
   | AVP Length                    |Reserved             |P|R|V|R|M|         
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         
   |                                                               |         
   +                                                               +         
   |                                                               |         
   +                            XRES                               +         
   |                                                               |         
   +                                                               +         
   |                                                               |         
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         
   |                                                               |         
   +                                                               +         
   |                                                               |         
   +                             CK                                +         
   |                                                               |         
   +                                                               +         
   |                                                               |         
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         
   |                                                               |         
   +                                                               +         
   |                                                               |         
   +                             IK                                +         
   |                                                               |         
   +                                                               +         
   |                                                               |         
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         
      
                           Figure 6: AKA Key AVP 












    
  Hiller, McCann      Informational - Expires 8/2001                  10 

                               DIAMETER AKA               February, 2001 
   
   
                                                                             

    0                   1                   2                   3            
    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          
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|         
   |                      AVP Code                                 |         
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         
   | AVP Length                    |Reserved             |P|R|V|R|M|         
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         
   |                                                               |         
   +                                                               +         
   |                                                               |         
   +                             RES                               +         
   |                                                               |         
   +                                                               +         
   |                                                               |         
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+         

                           Figure 7: AKA Request Result AVP 
      
  8. Security Considerations 
   
     This draft provides a basic transport function for the parameters 
     of AKA, which is itself a protocol designed to authenticate the 
     identity of a mobile node and to distribute keying material to a 
     service provider.  However, we rely on the DIAMETER infrastructure 
     itself to guarantee that keying material is not exposed or 
     tampered with between the VAAA and the HAAA.  If one or more 
     intervening brokers are present on the path between VAAA and HAAA, 
     then mechanisms for end-to-end security in DIAMETER (which are 
     outside the scope of this draft) should be applied.  In any case 
     we assume that any two peer DIAMETER servers will make use of IP 
     Security mechanisms to protect data in transit. 
      
      
  8. References 
   
     1  Bradner, S., "The Internet Standards Process -- Revision 3", 
        BCP 9, RFC 2026, October 1996. 
      
     2  Bradner, S., "Key words for use in RFCs to Indicate Requirement 
        Levels", BCP 14, RFC 2119, March 1997 
      
                                                rd
     3  3G TS 33.102 version 3.4.0 Release 99; 3   Generation 
        Partnership Project; Technical Specification Group Services and 
        System Aspecs; 3G Security 
      
   

    
  Hiller, McCann      Informational - Expires 8/2001                  11 

                               DIAMETER AKA               February, 2001 
   
   
   
     4  UMTS AKA in SIP; S3-000456; 3GPP TSG SA WG3 Security; S3#14; 
        August 2-4 2000 
      
      
      
  9. Acknowledgments 
      
     Semyon Mizikovsky provided valuable review and feedback on this 
     draft. 
      
      
  10. Author's Addresses 
      
     Peter J. McCann 
     Lucent Technologies 
     Rm 2Z-305 
     263 Shuman Blvd 
     Naperville, IL  60566-7050 
     USA 
      
     Phone: +1 630 713 9359 
     FAX:   +1 630 713 4982 
     EMail: mccap@lucent.com 
      
     Tom Hiller 
     Lucent Technologies 
     Rm 2F-218 
     263 Shuman Blvd 
     Naperville, IL  60566-7050 
     USA 
      
     Phone: +1 630 979 7673 
     FAX:   +1 630 979 7673 
     EMail: tom.hiller@lucent.com 
   
   
  Intellectual Property Statement 
      
     The IETF takes no position regarding the validity or scope of any 
     intellectual property or other rights that might be claimed to 
     pertain to the implementation or use of the technology described 
     in this document or the extent to which any license under such 
     rights might or might not be available; neither does it represent 
     that it has made any effort to identify any such rights.  
     Information on the IETF's procedures with respect to rights in 
     standards-track and standards-related documentation can be found 
     in BCP-11.  Copies of claims of rights made available for 
     publication and any assurances of licenses to be made available, 
     or the result of an attempt made to obtain a general license or 
    
  Hiller, McCann      Informational - Expires 8/2001                  12 

                               DIAMETER AKA               February, 2001 
   
   
     permission for the use of such proprietary rights by implementers 
     or users of this specification can be obtained from the IETF 
     Secretariat. 
      
     The IETF invites any interested party to bring to its attention 
     any copyrights, patents or patent applications, or other 
     proprietary rights that may cover technology that may be required 
     to practice this standard.  Please address the information to the 
     IETF Executive Director. 
      
      
  Full Copyright Statement 
   

     Copyright (C) The Internet Society (2000). All Rights Reserved. 
     This document and translations of it may be copied and furnished 
     to others, and derivative works that comment on or otherwise 
     explain it or assist in its implementation may be prepared, 
     copied, published and distributed, in whole or in part, without 
     restriction of any kind, provided that the above copyright notice 
     and this paragraph are included on all such copies and derivative 
     works. However, this document itself may not be modified in any 
     way, such as by removing the copyright notice or references to the 
     Internet Society or other Internet organizations, except as needed 
     for the purpose of developing Internet standards in which case the 
     procedures for copyrights defined in the Internet Standards 
     process must be followed, or as required to translate it into 
     languages other than English. 
      
     The limited permissions granted above are perpetual and will not 
     be revoked by the Internet Society or its successors or assigns. 
      
     This document and the information contained herein is provided on 
     an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET 
     ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 
     IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 
     THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 
     WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 
   













    
  Hiller, McCann      Informational - Expires 8/2001                  13