[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00 01 02 03                                                   
CAT Working Group                              Russell Housley (SPYRUS)
<draft-ietf-cat-ftpdsaauth-00.txt>                William A. Nace (NSA)
Updates: RFC 959                                     Peter Yee (SPYRUS)
Internet-Draft Expire in six months
July 1997


                      FTP Authentication Using DSA


Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working doc-
   uments of the Internet Engineering Task Force (IETF), its areas, and
   its working groups.  Note that other groups may also distribute work-
   ing 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 mate-
   rial or to cite them other than as ''work in progress.''

   To learn the current status of any Internet-Draft, please check the
   "1id-abstRacts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net (US East Coast), nic.nordu.net
   Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).

   Distribution of this memo is unlimited.  Please send comments to the
   <cat-ietf@mit.edu> mailing list.


Abstract

   This document defines a method to secure file transfers using the FTP
   specification RFC 959, "FILE TRANSFER PROTOCOL (FTP)" (October 1985)
   and the work in progress document "FTP Security Extensions" <Draft-
   ietf-cat-ftpsec-09.txt>[1].  This method will use the extensions pro-
   posed in the "FTP Security Extensions" Draft document along with a
   public/private digital signature.


1 Introduction

   The File Transfer Protocol (FTP) provides no protocol security except
   for a user authentication password which is transmitted in the clear.
   In addition, the protocol does not protect the file transfer session
   beyond the original authentication phase.




Housley, Nace & Yee                                             [Page 1]


INTERNET DRAFT                                             July 18, 1997


   The Internet Engineering Task Force (IETF) Common Authentication
   Technology (CAT) Working Group has specified security extensions to
   FTP.  These extensions allow the protocol to use more flexible secu-
   rity schemes, and in particular allows for various levels of protec-
   tion for the FTP command and data connections.  This document
   describes a profile for the FTP Security Extensions by which these
   mechanisms may be provisioned using the DSA[2] and SHA-1[3] algo-
   rithms.  The FTP Security Extensions do not attempt to provide for
   security when FTP is used in proxy mode.  The profile proposed in
   this document does not remove this limitation.


2 FTP Security Extensions

   The IETF CAT Working Group has produced an Internet Draft that seeks
   to improve the security of FTP.  This Internet Draft is likely to
   become a standards track RFC in 1997.  It provides:

      * user authentication -- augmenting the normal password mechanism;

      * server authentication -- normally done in conjunction with user
        authentication;

      * session parameter negotiation -- in particular, encryption keys
        and attributes;

      * command connection protection -- integrity, confidentiality, or
        both;

      * data transfer protection -- same as for command connection
        protection.

   In order to support the above security services, the two FTP entities
   negotiate a mechanism.  This process is open-ended and completes when
   both entities agree on an acceptable mechanism or when the initiating
   party (always the client) is unable to suggest an agreeable mecha-
   nism.  Once the entities agree upon a mechanism, they may commence
   authentication and/or parameter negotiation.

   Authentication and parameter negotiation occur within an unbounded
   series of exchanges.  At the completion of the exchanges, the enti-
   ties will either be authenticated (unilateral or mutually), and may
   be ready to protect FTP commands and data.

   Following the exchanges, the entities negotiate the size of the
   buffers they will use in protecting the commands and data that fol-
   low.  This process is accomplished in two steps: the client offers a
   suggested buffer size and the server may either refuse it, counter



Housley, Nace & Yee                                             [Page 2]


INTERNET DRAFT                                             July 18, 1997


   it, or accept it.

   At this point, the entities may issue protected commands within the
   bounds of the parameters negotiated through the security exchanges.
   Protected commands are issued by applying the protection services
   required to the normal commands and Base64 encoding the results. The
   encoded results are sent as the data field within a MIC (integrity).
   Base64 is an encoding for mapping binary data onto a textual charac-
   ter set that is able to pass through 7-bit systems without loss.  The
   server sends back responses in new result codes which allow the iden-
   tical protections and Base64 encoding to be applied to the results.
   Protection of the data transfers can be specified via the PROT com-
   mand which supports the same protections as those afforded the other
   FTP commands.  PROT commands may be sent on a transfer-by-transfer
   basis, however, the session parameters may not be changed within a
   session.

3 Use of Digital Signature Algorithm (DSA)

   This paper a profile in which DSA may be used to achieve certain
   security services when used in conjunction with the FTP Security
   Extensions framework.  As stated above, the reader should be familiar
   with the extensions in order to understand the protocol steps that
   follow.  In the context of the FTP Security Extensions, we use DSA
   with SHA-1 for authentication and integrity.

3.1 DSA Profile

   FTP entities may use DSA to give either unilateral or mutual authen-
   tication as well as to provide integrity services for commands and
   data transfers.  This specification follows the tokens and exchanges
   defined in FIPS PUB 196[4], including Appendix A on ASN.1 encoding of
   messages and tokens.

3.1.1  Unilateral Authentication with DSA

   A client may unilaterally authenticate its identity to a server.
   What follows are the protocol steps necessary to perform DSA authen-
   tication as specified in FIPS PUB 196 under the FTP Security Exten-
   sions framework.  Where failure modes are encountered, the return
   codes follow those specified in the Extensions.  They are not enumer-
   ated here as they are invariant among mechanisms.  FIPS PUB 196
   employs a set of exchanges which are transferred to provide authenti-
   cation.  Each exchange employs various fields and tokens, some of
   which are optional.  In addition, each token has several subfields
   that are optional.  A conformant subset of the fields and subfields
   for use with FTP have been selected.  Therefore, the exchanges below
   do not show the FIPS PUB 196 notation indicating optional fields,



Housley, Nace & Yee                                             [Page 3]


INTERNET DRAFT                                             July 18, 1997


   while only the mandatory subfields are allowed.  The tokens are ASN.1
   encoded per Appendix A of FIPS PUB 196, and each token is named to
   indicate the direction in which it flows (i.e., TokenBA flows from
   Party B to Party A).  In Figure 1, the client binds the last trans-
   mission (token identifier, certificate, and token) together as an
   ASN.1 sequence.

   The exchanges detailed below presume a knowledge of FIPS PUB 196 and
   the FTP Security Extensions.  The client is Party A, while the server
   is Party B.  The notation for concatenation is " || ".  The pseudo-
   function Sequence is used to indicate that its parameters are to be
   joined as an ASN.1 SEQUENCE.  Verification of signed data, and in
   particular certification path verification is implicitly assumed, but
   is not shown.

   ---------------------------------------------------------------------
    Client                             Server

    AUTH DSS-CLIENT-UNILATERAL     -->
                                       <-- 334 ADAT=Base64(Sequence(
                                               TokenID || TokenBA))
    ADAT Base64(Sequence(TokenID ||
        CertA || TokenAB ||
        absigValue))               -->
                                       <-- 234
   ---------------------------------------------------------------------
                                 Figure 1

   With this example, the client is now authenticated to the server.
   Additional functionality available to client and server includes the
   use of MIC protected commands and the ability to send signed data.
   The Sign function used in the figures below appends a nonce to the
   end of the parameter, and then computes a DSA with SHA-1 signature
   over the parameter followed by a nonce.  The 40 octet signature
   value, as described in FIPS PUB 186, is composed of two 20 octet val-
   ues, r followed by s.  The nonce is comprised of a two octet command
   counter and the Ra value from TokenAB.  Since both the client and
   server have the Ra value from TokenAB and both can calculate the com-
   mand counter, the nonce is not transmitted.  The command counter is
   initialized to the least significant two octets of the Ra value from
   TokenAB, and it is incremented each time the client issues a command.
   The Sign function output is composed of the 40 octet signature value
   followed by the parameter.  An example follows:








Housley, Nace & Yee                                             [Page 4]


INTERNET DRAFT                                             July 18, 1997


   ---------------------------------------------------------------------
    Client                                 Server

    MIC Base64(Sign("PBSZ 65535"))      -->
                                           <-- 200 PBSZ=32767
    MIC Base64(Sign("USER yee"))        -->
                                           <-- 331
    MIC Base64(Sign("PASS fortezza"))   -->
                                           <-- 230
    MIC Base64(Sign("PROT S"))          -->
                                           <-- 200
    MIC Base64(Sign("STOR foo.bar"))    -->
                                           <-- 150
   ---------------------------------------------------------------------
                                 Figure 2

   Data now flows from the client to the server as specified in the
   Extensions.  Specifically, the file is broken up into blocks of data
   of less than the negotiated protection buffer size (32768 bytes in
   the example exchanges).  Each protection buffer contains a safe token
   followed by file data.  A common safe token structure is used for
   unilateral and mutual authentication.  The safe token structure is
   described in section 3.1.3.

3.1.2  Mutual Authentication with DSA

   The PDU flow for mutual authentication is slightly more complex, as
   shown:

   ---------------------------------------------------------------------
     Client                             Server

     AUTH DSS-MUTUAL                -->
                                        <-- 334 ADAT=Base64(Sequence(
                                                 TokenID || TokenBA1))
     ADAT Base64(Sequence(TokenID ||
          CertA || TokenAB ||
          absigValue))              -->
                                        <-- 235 ADAT=Base64(Sequence(
                                              TokenID || CertB ||
                                              TokenBA2 || ba2sigValue))
   ---------------------------------------------------------------------
                                 Figure 3

   Data retrieval and other FTP operations can now be performed with
   signature protection.  As before, the FTP entities negotiate a pro-
   tection buffer size.  Likewise, a two octet command counter combined
   with the Ra value from TokenAB is used as a nonce in the Sign



Housley, Nace & Yee                                             [Page 5]


INTERNET DRAFT                                             July 18, 1997


   function.

   ---------------------------------------------------------------------
     Client                              Server

     MIC Base64(Sign("PBSZ 65535"))      -->
                                            <-- 631 Base64(Sign
                                                  ("200 PBSZ=32767"))
     MIC Base64(Sign("USER yee"))        -->
                                            <-- 631 Base64(Sign("331"))
     MIC Base64(Sign("PASS fortezza"))   -->
                                            <-- 631 Base64(Sign("230"))
     MIC Base64(Sign("PROT S"))          -->
                                            <-- 631 Base64(Sign("200"))
     MIC Base64(Sign("RETR foo.bar"))    -->
   ---------------------------------------------------------------------
                                 Figure 4

   Data now flows from the client to the server as well as the server to
   the client as specified in the Extensions.  Specifically, the file is
   broken up into blocks of data of less than the negotiated protection
   buffer size.  Each protection buffer contains a safe token followed
   by file data.  A common safe token structure is used for unilateral
   and mutual authentication.  The safe token structure is described in
   section 3.1.3.

3.1.3  File Protection with DSA

   The next figure shows the structure of the safe token and file data.

   ---------------------------------------------------------------------
                         Signature         40 octets
                         Buffer Size       4 octets
                         Nonce             8 octets
                         File Count        2 octets
                         Buffer Count      4 octets
                         File Data Buffer  Buffer Size
   ---------------------------------------------------------------------
                                 Figure 5

   The safe token is comprised of the signature value, buffer size,
   nonce, file count, and buffer count.  The signature covers the buffer
   size, nonce, file count, buffer count, and the file data buffer.
   Buffer size is the number of octets contained in file data buffer.
   This buffer size must be less than the negotiated PBSZ value, and the
   maximum buffer size is PBSZ minus 58.  If the buffer size is not
   equal to PBSZ minus 58, then this buffer is the final buffer of the
   file.  If the file ends on a full buffer boundary, a buffer with the



Housley, Nace & Yee                                             [Page 6]


INTERNET DRAFT                                             July 18, 1997


   buffer size set to zero will be sent.  The nonce is the least signif-
   icant 64 bits of the Rb field of TokenBA1.  File count is a sequence
   counter of protected files transferred, starting at zero.  Buffer
   count is the number of protected buffers sent for this file, starting
   at zero.

4.0  Security Considerations

   This entire memo is about security mechanisms.  For DSA to provide
   the authentication discussed, the implementation must protect the
   private key from disclosure.

5.0  Acknowledgements

   I would like to thank Todd Horting for insights gained during imple-
   mentation of this specification.

6.0  References

   [1] - M. Horowitz and S. J. Lunt.  FTP Security Extensions.
         Internet-Draft <draft-ietf-cat-ftpsec-09.txt>,
         November, 1996.

   [2] - Digital Signature Standard (DSS). FIPS Pub 186.
         May 19, 1994.

   [3] - Secure Hash Standard. FIPS Pub 180-1. April 17, 1995.

   [4] - Standard for Entity Authentication Using Public Key
         Cryptography.  FIPS Pub 196. February 18, 1997.





















Housley, Nace & Yee                                             [Page 7]


INTERNET DRAFT                                             July 18, 1997


7.0  Author's Address

   Russell Housley
   SPYRUS
   PO Box 1198
   Herndon, VA 20172
   USA

   Phone: +1 703 435-7344
   Email: housley@spyrus.com


   DIRNSA
   Attn: X22 (W. Nace)
   9800 Savage Road
   Fort Meade, MD 20755-6000
   USA

   Phone: +1 410 859-4464
   Email: WANace@missi.ncsc.mil


   Peter Yee
   SPYRUS
   2460 N. First Street
   Suite 100
   San Jose, CA 95131-1023
   USA

   Phone: +1 408 432-8180
   Email: yee@spyrus.com




















Housley, Nace & Yee                                             [Page 8]