home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / k95 / draft-fordh-ftp-ssl-firewall-01.txt < prev    next >
Text File  |  2020-01-01  |  22KB  |  780 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7.                                                     Paul Ford-Hutchinson
  8. <draft-fordh-ftp-ssl-firewall-01.txt>                         IBM UK Ltd
  9.  
  10.  
  11.  
  12. INTERNET-DRAFT (draft)
  13.  
  14.  
  15.  
  16.  
  17.  
  18.                                                          19th June, 2002
  19. This document expires on 19th December, 2002
  20.  
  21.  
  22.                        FTP/TLS Friendly Firewalls
  23.  
  24.  
  25. Status of this Memo
  26.  
  27.    This document is an Internet-Draft and is in full conformance with
  28.    all provisions of Section 10 of RFC2026.
  29.  
  30.    Internet-Drafts are working documents of the Internet Engineering
  31.    Task Force (IETF), its areas, and its working groups.  Note that
  32.    other groups may also distribute working documents as Internet-
  33.    Drafts.
  34.  
  35.    Internet-Drafts are draft documents valid for a maximum of six months
  36.    and may be updated, replaced, or obsoleted by other documents at any
  37.    time.  It is inappropriate to use Internet-Drafts as reference
  38.    material or to cite them other than as "work in progress."
  39.  
  40.    The list of current Internet-Drafts can be accessed at
  41.    http://www.ietf.org/1id-abstracts.txt
  42.  
  43.    The list of Internet-Draft Shadow Directories can be accessed at
  44.    http://www.ietf.org/shadow.html
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Ford-Hutchinson                                         FORMFEED[Page 1]
  59.  
  60.  
  61.  
  62.  
  63.  
  64. Internet-Draft        Secure FTP Friendly Firewalls      19th June, 2002
  65.  
  66.  
  67. Index
  68.       1. .......... Abstract
  69.       2. .......... Introduction
  70.       3. .......... Audience
  71.       4. .......... Problem Statement
  72.       5. .......... Technical Description
  73.       5.1. ........... Establishing a Data Connection
  74.       5.2. ........... Data connection behaviour for FTP
  75.       5.3. ........... Port numbers
  76.       6. .......... Firewalls
  77.       6.1. ........... Port Filtering Firewalls
  78.       6.2. ........... Content Aware Firewalls
  79.       6.3. ........... Network Address Translators
  80.       6.4. ........... Application Layer Gateways
  81.       7. .......... Trying to secure FTP with TLS over firewalls
  82.       7.1. ........... Port Filtering Firewalls
  83.       7.2. ........... Content Aware Firewalls
  84.       7.3. ........... Network Address Translators
  85.       7.4. ........... Application Layer Gateways
  86.       8. .......... Premature Control Termination
  87.       9. .......... midcom
  88.       10. ......... Security Considerations
  89.       11. ......... IANA Considerations
  90.       12. ......... Network Management
  91.       13. ......... Internationalization
  92.       14. ......... Scalability & Limits
  93.       15. ......... Acknowledgements
  94.       16. ......... References
  95.       17. ......... Authors' Contact Address
  96.                                    Appendix
  97.       A. .......... Firewall rule summary
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  
  118. Ford-Hutchinson                                         FORMFEED[Page 2]
  119.  
  120.  
  121.  
  122.  
  123.  
  124. Internet-Draft        Secure FTP Friendly Firewalls      19th June, 2002
  125.  
  126.  
  127. 1. Abstract
  128.  
  129.    This document discusses some of the issues with running FTP, secured
  130.    with TLS as defined in [FTP-TLS], through firewalls.  FTP is known to
  131.    be a bit of a problem for firewalls (see [RFC-1579] for a discussion
  132.    of normal FTP and firewalls).  Some of the problems have been fixed
  133.    by adding intelligence into the firewall.  With secured FTP, where
  134.    the control connection is encrypted, some of these techniques fail.
  135.  
  136.    Whilst this document confines itself to issues of FTP over TLS, the
  137.    issues will probably be relevant for most secured FTP protocols that
  138.    conform to [RFC-2228].  Some of the discussions will also be relevant
  139.    to any protocol that firewalls do clever things with.
  140.  
  141.  
  142.  
  143. 2.  Introduction
  144.  
  145.    This document is presented as a discussion of secure FTP behaviour as
  146.    viewed by a firewall.  It discusses some of the techniques that
  147.    firewalls use to provide a path for the FTP protocol and how those
  148.    are affected by layering FTP on TLS.
  149.  
  150.  
  151. 3.  Audience
  152.  
  153.    This document is aimed at designers of firewall software and people
  154.    involved in deploying firewalls in an environment where FTP over TLS
  155.    needs to traverse them.
  156.  
  157. 4. Problem Statement
  158.  
  159.    The FTP protocol has two troublesome features that cause headaches
  160.    when trying to pass over boundary firewall devices.
  161.  
  162.       - There are two distinct connections used
  163.  
  164.       - The information used to establish the second connection is
  165.       dynamically created and passed between the entities over the first
  166.       connection.
  167.  
  168.    The two connections are the Control Connection and the Data
  169.    Connection.  In practice, there is usually one Control Connection per
  170.    session and numerous Data Connections. The operation of FTP defines
  171.    that the following data transfers take place on a Data Connection:
  172.  
  173.       - File sending, using the STOR command
  174.  
  175.  
  176.  
  177.  
  178. Ford-Hutchinson                                         FORMFEED[Page 3]
  179.  
  180.  
  181.  
  182.  
  183.  
  184. Internet-Draft        Secure FTP Friendly Firewalls      19th June, 2002
  185.  
  186.  
  187.       - File retrieval, using the RETR command
  188.  
  189.       - Listings, using the NLST and LIST commands (and the MLST
  190.       command)
  191.  
  192.    Implementations usually establish a data connection for each of the
  193.    data transfers.  The protocol documentation [RFC-959] does not
  194.    specify this behaviour, but does allow for it.
  195.  
  196.    A note about Transmission Modes:  FTP [RFC-959] defines three modes
  197.    of data transfer, Stream, Block and Compressed.  In practice Stream
  198.    mode, the only one required by [RFC-1123] and the default mode, is
  199.    the most widely used.  [RFC-1123] states that clients that use Stream
  200.    mode SHOULD use a PORT command.  Stream mode data transfers are ended
  201.    by closing the data connection, effectively forcing one data
  202.    connection per data transfer.
  203.  
  204. 5. Technical Description
  205.  
  206.  
  207.    For the discussions below, assume that a Client has connected from
  208.    port 'U' to the FTP port 'L' on the Server.  (The well known port for
  209.    FTP is '21', thus, normally, 'L' is '21').  Also assume that the
  210.    transmission mode is 'Stream'.
  211.  
  212. 5.1. Establishing a Data Connection
  213.  
  214.    A Data Connection needs to be established for the data transfer
  215.    commands (STOR, RETR, NLST, LIST and MLST) to operate.  When the
  216.    server receives one of these commands, it replies with an
  217.    intermediate reply ('150') indicating that it is ready to transfer
  218.    the data. The Data Connection is established and the data transfer
  219.    happens.
  220.  
  221. 5.2. Data connection behaviour for FTP
  222.  
  223.    If no PORT or PASV command is issued, the Client should listen for a
  224.    connection from the Server on the same port as the control connection
  225.    ('U').  The Server should initiate the Data Connection from the
  226.    default Data Port, which is 'L - 1' ('20').
  227.  
  228.    If a PORT command is to be issued then the Client should obtain a
  229.    port number and pass that to the Server in the PORT command (as a
  230.    comma separated list "h1,h2,h3,h4,p1,p2" where h1 is the high order 8
  231.    bits of the internet host address.)  The Server should then establish
  232.    a connection to the Client on the Address and Port indicated, from
  233.    the Server's Default Data Port ('L - 1').  Note: This does not need
  234.    to be on the host at the other end of the Control Connection.
  235.  
  236.  
  237.  
  238. Ford-Hutchinson                                         FORMFEED[Page 4]
  239.  
  240.  
  241.  
  242.  
  243.  
  244. Internet-Draft        Secure FTP Friendly Firewalls      19th June, 2002
  245.  
  246.  
  247.    If the Client wishes to use Firewall Friendly FTP [RFC-1579] then the
  248.    Client issues a PASV command, which causes the Server to listen on a
  249.    port (not the default data port).  The Server indicates which port it
  250.    is listening on, in the 227 response to the PASV command (see
  251.    [RFC-1123]).  This time the Data Connection is initiated from a port
  252.    on the Client to the port indicated by the Server.  Note: This does
  253.    not need to be on the host at the other end of the Control
  254.    Connection.
  255.  
  256. 5.3. Port numbers
  257.  
  258.    The TCP and UDP addressing mechanism has two parts.  A Host Address
  259.    and a Port number.  In IPv4 a host address is a long integer (32
  260.    bits) and a port number is a short integer (16 bits). Each host may
  261.    use those port numbers to originate or listen to connections.  At a
  262.    'C' coding level, there are three basic ways to get a port for a
  263.    connection.
  264.  
  265.       - get a socket and then connect to a remote host
  266.  
  267.       - get a socket, bind to port 0 and then query the socket
  268.       information to find out which port number you were given.
  269.  
  270.       - get a socket and bind to a specific port number.
  271.  
  272.       The first mechanism is only really useful for obtaining a port to
  273.       originate a connection; the second two mechanisms are suitable for
  274.       obtaining a port for originating or for listening for a
  275.       connection.
  276.  
  277.    There are three ranges of port numbers:
  278.  
  279.       - Well known ports.  These are the port numbers less than 1024.
  280.       On Unix systems, it is usually a restriction that these ports are
  281.       only accessible to a process running with 'root' privilege.  It
  282.       was therefore assumed that services running in this port range
  283.       would be system services, running with the consent of the system
  284.       administrator, and therefore trustable.  With the advent of home
  285.       linux systems and Windows systems that do not have a 'root' user -
  286.       this basis of 'trust' is not reliable.  Widely used Internet
  287.       protocols will usually be on ports <1024, user processes will not
  288.       normally (even on Windows machines) be allocated ports under 1024
  289.       unless specifically requested.
  290.  
  291.       - Registered ports.  These are the port numbers in the range
  292.       1024-49151.  These are for services that do not need to be run
  293.       with root privilege, but do need to have a port number agreed by
  294.       both the client and server.
  295.  
  296.  
  297.  
  298. Ford-Hutchinson                                         FORMFEED[Page 5]
  299.  
  300.  
  301.  
  302.  
  303.  
  304. Internet-Draft        Secure FTP Friendly Firewalls      19th June, 2002
  305.  
  306.  
  307.       - Dynamic and/or Private Ports.  These are the ports from 49152
  308.       through 65535.
  309.  
  310.  
  311.  
  312. 6. Firewalls
  313.  
  314.    Simple port filters rely on the 'well known port' system that
  315.    underpins much of the establishment of TCP (and UDP) based protocol
  316.    conversations.  Each service has a well known port and a client and
  317.    server should expect to find each other on those ports.  Examples of
  318.    the common ports are: 80 for http; 443 for https; 25 for SMTP; 23 for
  319.    telnet and 21 for FTP.  Such firewalls boldly assume that machines on
  320.    either side will be well behaved and only offer the correct service
  321.    on the correct port.  In this way, they are able to filter unwanted
  322.    traffic between hosts by examining the source address/port and
  323.    destination address/port and deciding if the hosts are allowed to use
  324.    the service indicated.
  325.    For the FTP protocol, two rules must be set up in the Firewall.
  326.  
  327.    The first rule allows the client to connect to the Server for the
  328.    Control Connection.
  329.  
  330.    The second rule is for the Data Connection and will depend if Normal
  331.    or Firewall Friendly FTP is to be used (or both).
  332.  
  333.    6.1. Port Filtering Firewalls
  334.  
  335.  
  336.       The problem that simply using port filtering for FTP generates is
  337.       that the data connection rule tends to open up quite a large hole
  338.       in the Firewall and many implementors do not wish to define it.
  339.       The more general problem with simple port filtering is the issue
  340.       of port number misuse.  To fix both of these issues, a Content
  341.       Aware firewall may be deployed.
  342.  
  343.    6.2. Content Aware Firewalls
  344.  
  345.       In addition to port filtering rules, Content Aware firewalls will
  346.       also look at the content of the conversation and may perform
  347.       actions based on what they observe.  This has two impacts for the
  348.       FTP protocol.  Firstly, it allows the firewall to observe the
  349.       content of the Control Connection and make decisions based upon
  350.       it.  Secondly, it allows the firewall to open up temporary holes
  351.       for the Data Connection, based upon the content of the PORT
  352.       command and/or PASV response.
  353.       Content Aware firewalls:
  354.  
  355.  
  356.  
  357.  
  358. Ford-Hutchinson                                         FORMFEED[Page 6]
  359.  
  360.  
  361.  
  362.  
  363.  
  364. Internet-Draft        Secure FTP Friendly Firewalls      19th June, 2002
  365.  
  366.  
  367.       - may only allow certain FTP commands to be used
  368.  
  369.       - may have restrictions in the parameters to certain commands
  370.       (e.g. STOR, RETR, CWD, NLST and LIST preventing any directories
  371.       with a certain name being accessed)
  372.  
  373.       - may insist that all commands conform to some expected criteria,
  374.       such as being ended by CRLF delimiters.
  375.  
  376.       When a Content Aware firewall observes a PORT command or the 227
  377.       reply to the PASV command, it may dynamically create a rule to
  378.       allow the indicated Data Connection to pass through.  This removes
  379.       the requirement for the quite wide definitions that would
  380.       otherwise be needed to allow the data connection to be
  381.       established.
  382.  
  383.    6.3. Network Address Translators
  384.  
  385.       One step up from Content Aware firewalls are boundary devices
  386.       which allow addresses to be hidden from the outside world.  There
  387.       are two major reasons for this.  The first is to hide any network
  388.       topology information; the second is to allow the use of private
  389.       network addresses (see [RFC-1918]).  For the FTP protocol, Network
  390.       Address Translators need to read and modify PORT commands and/or
  391.       PASV responses to substitute their own address and port for those
  392.       indicated on the Control Connection.
  393.  
  394.    6.4. Application Layer Gateways
  395.  
  396.       These types of boundary devices actually understand the FTP
  397.       protocol and act as a application layer proxy between the two
  398.       hosts.  To the Client it acts as a server, to the Server it acts
  399.       as a client.
  400.  
  401. 7. Trying to secure FTP with TLS over firewalls
  402.  
  403.    If we look at our four category of devices, we can examine the effect
  404.    of deploying [FTP-SSL] secured FTP over TLS.
  405.  
  406.    7.1. Port Filtering Firewalls
  407.  
  408.       FTP over TLS will not affect the operation of the FTP protocol as
  409.       viewed by a simple port filtering firewall.  The connections and
  410.       the ports are exactly the same
  411.  
  412.    7.2. Content Aware Firewalls
  413.  
  414.       Content aware firewalls will no longer be able to understand the
  415.  
  416.  
  417.  
  418. Ford-Hutchinson                                         FORMFEED[Page 7]
  419.  
  420.  
  421.  
  422.  
  423.  
  424. Internet-Draft        Secure FTP Friendly Firewalls      19th June, 2002
  425.  
  426.  
  427.       content of the Control connection.  This means that
  428.  
  429.          - Any packet on the control connection that cannot be
  430.          inspected, must be configured to be passed through.
  431.  
  432.          - Normal port filtering firewall rules must be in place for the
  433.          Data Connection, as the firewall will not be able to open up
  434.          the pinholes, based on examination of the Control Connection.
  435.  
  436.    7.3. Network Address Translators
  437.  
  438.       NAT firewalls will not work for secure FTP if the NAT will affect
  439.       the PORT address or the PASV response address.
  440.       An FTP Client on a NATted network should be able to use secure FTP
  441.       over TLS in firewall friendly mode to a Server that has a real
  442.       Internet IP address.
  443.       An FTP Client with a real Internet IP address should be able to
  444.       use an FTP Server that is on a NATted network in normal mode
  445.       (assuming there is some mechanism for the Client to establish a
  446.       Control Connection).
  447.  
  448.    7.4. Application Layer Gateways
  449.  
  450.       In general Client-Server secured FTP will not work at all with an
  451.       ALG.  However, It may be possible to configure an ALG as one of
  452.       the endpoints of the secured FTP session as it flows over a
  453.       hostile network.
  454.  
  455. 8. Premature Control Termination
  456.  
  457.    Another issue with firewalls and FTP is connected to the problem of
  458.    timeouts.  Due to the two-connection model of FTP, there is a high
  459.    likelihood that the Control connection will have no activity during a
  460.    data transfer.  In the case that the data transfer is long, the
  461.    firewall may incorrectly assume that the Control connection is no
  462.    longer needed and close it down.  Thus, the data transfer will
  463.    complete correctly, but the 226 reply on the control connection will
  464.    no be received and the client and server will, eventually, time out
  465.    independently.
  466.  
  467. 9. midcom
  468.  
  469.    One approach to help solve the issue is the MiddleBox communications
  470.    working group.  Their aim is to create a model and set of protocols
  471.    to define a communications protocol between endpoints and boundary
  472.    devices, such as firewalls, that will allow the client or server to
  473.    request a path through the firewall without the firewall itself
  474.    needing to be able to understand the protocol that it is passing
  475.  
  476.  
  477.  
  478. Ford-Hutchinson                                         FORMFEED[Page 8]
  479.  
  480.  
  481.  
  482.  
  483.  
  484. Internet-Draft        Secure FTP Friendly Firewalls      19th June, 2002
  485.  
  486.  
  487.    through.
  488.  
  489.  
  490. 10. Security Considerations
  491.  
  492.    This document attempts to explain how the FTP protocol operates from
  493.    a firewall's perspective; how a firewall can be configured to allow
  494.    FTP (and secure FTP) to traverse it and how some of the more advanced
  495.    features of firewalls and application layer gateways can make life
  496.    hard for secured protocols.
  497.  
  498.  
  499. 11. IANA Considerations
  500.  
  501.    {FTP-PORT} - The port assigned to the FTP control connection is 21.
  502.  
  503.  
  504.  
  505. 12. Network Management
  506.  
  507.    NONE
  508.  
  509.  
  510. 13. Internationalization
  511.  
  512.    NONE
  513.  
  514.  
  515. 14. Scalability & Limits
  516.  
  517.    NONE
  518.  
  519.  
  520. 15. Acknowledgements
  521.  
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530.  
  531.  
  532.  
  533.  
  534.  
  535.  
  536.  
  537.  
  538. Ford-Hutchinson                                         FORMFEED[Page 9]
  539.  
  540.  
  541.  
  542.  
  543.  
  544. Internet-Draft        Secure FTP Friendly Firewalls      19th June, 2002
  545.  
  546.  
  547. 16. References
  548.  
  549.    [RFC-959] J. Postel, "File Transfer Protocol"
  550.       RFC 959, October 1985.
  551.  
  552.    [RFC-1579] S. Bellovin, "Firewall-Friendly FTP"
  553.       RFC 1579, February 1994.
  554.  
  555.    [RFC-2228] M. Horowitz, S. Lunt, "FTP Security Extensions"
  556.       RFC 2228, October 1997.
  557.  
  558.    [RFC-2246] T. Dierks, C. Allen, "The TLS Protocol Version 1.0"
  559.       RFC 2246, January 1999.
  560.  
  561.    [RFC-2577] M Allman, S Ostermann, "FTP Security Considerations"
  562.       RFC 2577, May 1999.
  563.  
  564.    [RFC-2817] R. Khare, S. Lawrence, "Upgrading to TLS Within HTTP/1.1"
  565.       RFC 2817, May 2000.
  566.  
  567.    [RFC-2818] E. Rescorla,  "HTTP Over TLS"
  568.       RFC 2818, May 2000.
  569.  
  570.    [FTP-EXT] R Elz, P Hethmon "Extensions to FTP"
  571.       draft-ietf-ftpext-mlst-12.txt, September 2000.
  572.  
  573.    [FTP-TLS] "Securing FTP with TLS"
  574.       draft-murray-auth-ftp-ssl-08.txt, October 2001.
  575.  
  576.  
  577.  
  578.  
  579.  
  580.  
  581.  
  582.  
  583.  
  584.  
  585.  
  586.  
  587.  
  588.  
  589.  
  590.  
  591.  
  592.  
  593.  
  594.  
  595.  
  596.  
  597.  
  598. Ford-Hutchinson                                        FORMFEED[Page 10]
  599.  
  600.  
  601.  
  602.  
  603.  
  604. Internet-Draft        Secure FTP Friendly Firewalls      19th June, 2002
  605.  
  606.  
  607. 17. Authors' Contact Address
  608.  
  609. The FTP-TLS draft information site is at http://www.ford-
  610. hutchinson.com/~fh-1-pfh/ftps-ext.html
  611.  
  612.  
  613. Please send comments to Paul Ford-Hutchinson at the address below
  614.  
  615.         Paul Ford-Hutchinson
  616.            IBM UK Ltd
  617.            PO Box 31
  618.            Birmingham Road
  619.            Warwick
  620.            United Kingdom
  621.   tel -   +44 1926 462005
  622.   fax -   +44 1926 496482
  623. email - paulfordh@uk.ibm.com
  624.  
  625.  
  626.  
  627.  
  628.  
  629.  
  630.  
  631.  
  632.  
  633.  
  634.  
  635.  
  636.  
  637.  
  638.  
  639.  
  640.  
  641.  
  642.  
  643.  
  644.  
  645.  
  646.  
  647.  
  648.  
  649.  
  650.  
  651.  
  652.  
  653.  
  654.  
  655.  
  656.  
  657.  
  658. Ford-Hutchinson                                        FORMFEED[Page 11]
  659.  
  660.  
  661.  
  662.  
  663.  
  664. Internet-Draft        Secure FTP Friendly Firewalls      19th June, 2002
  665.  
  666.  
  667.                                 Appendix
  668.  
  669. A.  Firewall rule summary
  670.  
  671.       As long Application Layer Gateways (or proxys) are not used, a
  672.       packet filtering firewall should be able to pass secured FTP.  The
  673.       following guidelines should help trying to configure one.
  674.  
  675.    Control Connection
  676.  
  677.          - Allow any port on the client to connect to port 21 on the
  678.          server
  679.  
  680.          - Disable any rules that parse and/or impose any rules on the
  681.          commands and/or responses on the control stream.  (Note - there
  682.          is one major firewall vendor who claim this is a security issue
  683.          and make it very hard for you to do this)
  684.  
  685.          - Ensure the idle timeout of the control connection is longer
  686.          than it will take to transfer the largest file on the data
  687.          connection
  688.  
  689.    Data Connection
  690.  
  691.       Normal (active or PORT) FTP
  692.  
  693.          - Allow port 20 on the server to connect to any port on the
  694.          client
  695.  
  696.       Firewall-Friendly (passive or PASV) FTP
  697.  
  698.          - Allow any port on the client to connect to any high port(*)
  699.          on the server.
  700.  
  701.             (*) This may be able to be configured on the server to be a
  702.             range of ports and not 'any high port'.
  703.  
  704.       Note: A firewall may allow both Normal and Firewall-Friendly FTP,
  705.       the choice is not exclusive.
  706.  
  707.    NAT firewalls should be able to allow Firewall friendly FTP through,
  708.    as long as these rules can be followed.
  709.  
  710.  
  711.  
  712.  
  713.  
  714.  
  715.  
  716.  
  717.  
  718. Ford-Hutchinson                                        FORMFEED[Page 12]
  719.  
  720.  
  721.  
  722.  
  723.  
  724. Internet-Draft        Secure FTP Friendly Firewalls      19th June, 2002
  725.  
  726.  
  727. Full Copyright Statement
  728.  
  729.    Copyright (C) The Internet Society (2001).  All Rights Reserved.
  730.  
  731.    This document and translations of it may be copied and furnished to
  732.    others, and derivative works that comment on or otherwise explain it
  733.    or assist in its implementation may be prepared, copied, published
  734.    and distributed, in whole or in part, without restriction of any
  735.    kind, provided that the above copyright notice and this paragraph are
  736.    included on all such copies and derivative works.  However, this
  737.    document itself may not be modified in any way, such as by removing
  738.    the copyright notice or references to the Internet Society or other
  739.    Internet organizations, except as needed for the purpose of
  740.    developing Internet standards in which case the procedures for
  741.    copyrights defined in the Internet Standards process must be
  742.    followed, or as required to translate it into languages other than
  743.    English.
  744.  
  745.    The limited permissions granted above are perpetual and will not be
  746.    revoked by the Internet Society or its successors or assigns.
  747.  
  748.    This document and the information contained herein is provided on an
  749.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  750.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  751.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  752.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  753.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  754.  
  755. This document expires on 19th December, 2002
  756.  
  757.  
  758.  
  759.  
  760.  
  761.  
  762.  
  763.  
  764.  
  765.  
  766.  
  767.  
  768.  
  769.  
  770.  
  771.  
  772.  
  773.  
  774.  
  775.  
  776.  
  777.  
  778. Ford-Hutchinson                                        FORMFEED[Page 13]
  779.  
  780.