19 January 1999
Source: ftp://ftp.ietf.org/internet-drafts/draft-ziring-nsa-tftp-security-00.txt

--------------------------------------------------------------------------------

                                                           N. Ziring
INTERNET DRAFT                                        6 January 1999
<draft-ziring-nsa-tftp-security-00.txt>         Expires 11 June 1999

              TFTP Compression and Security Options



Status of this Memo

   This document is an Internet-Draft.  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."

   To view the entire list of current Internet-Drafts, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), ftp.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

Abstract

     This draft describes a set of optional extensions to the Trivial
     File Transfer Protocol (TFTP).  Using these extensions, TFTP users
     can improve file transmission speed using compression, improve
     integrity assurance, and add confidentiality of file contents. The
     techniques are designed for simplicity and for compliance with
     existing TFTP standards as defined by RFC 1350 and RFC 2347.


















Ziring                                                  	[Page 1]

draft-tftp-security-03       TFTP Security               January 6, 1999




1. Overview and Rationale

     TFTP is a simple lock-step file transfer scheme built on top of a
     datagram packet delivery service, typically UDP.  Often used by
     network devices and small hosts to load boot files or to back up
     configuration data, TFTP was designed to be as simple as possible.

     Because TFTP is based on datagram transmission, the chance of a
     failure of a TFTP transaction increases with the number of packets
     sent.  There are two ways to reduce the number of packets sent for
     a particular file transfer: using larger blocks, as described in
     RFC 2348, or using compression as specified in this draft.  To
     support compression within the framework of existing TFTP
     standards, this draft proposes a new TFTP option using the
     structure defined by RFC 2347.  The "compress" option allows a
     client to request that a particular data compression transform be
     used.  This draft addresses compression of the file data only; file
     names, block numbers, and other parts of the TFTP protocol are not
     subject to compression.

     The current TFTP standard offers no integrity assurance for data,
     beyond any provided by the underlying datagram transport.  It also
     offers no confidentiality protection whatsoever.  Files transfered
     via TFTP are often critical to the operation of a network (e.g.
     router configuration files) and sometimes contain sensitive
     information (e.g. passwords).

     To support protection of file transfer data within the simple
     framework of the TFTP standard, this draft proposes two security
     options: the confidentiality option "sec-crypt" and the integrity
     option "sec-mac".   This draft addresses protection of file data
     only; it does not address confidentiality of TFTP file names, block
     numbers, or any other part of the protocol.  These options are
     integrated into TFTP using the extension mechanism defined in RFC
     2347.

     The security options detailed in this draft employ a very small set
     of cryptographic algorithms: the DES block cipher, SHA.1 and MD5
     message digest, and Diffie-Hellman key agreement.  These algorithms
     were selected on the basis of their wide availability,
     standardization, and well-understood properties.  The complexity of
     the security extensions is deliberately minimal, in order to comply
     with packet length and content limitations imposed by the TFTP
     standards.


2. Option Specifications

     The options described in this section fall into three feature



Ziring                                                  	[Page 2]

draft-tftp-security-03       TFTP Security               January 6, 1999




     areas: four options to support confidentiality, one to support
     integrity, and one to support compression. Compression,
     confidentiality, and integrity can all be used together or
     separately, as discussed in Section 6.

     The transaction initiator, the client, must include any desired
     compression and security options in their initial RRQ or WRQ
     packet, as specified by RFC 2347.  Also, RFC 2347 stipulates that
     TFTP option names and values shall be expressed in case-insensitive
     ASCII.  The sections below define the single compression option and
     the five security options in detail.

     2.1. Compression Option:compress

          This option defines the data compression scheme to employ.
          There is only one scheme defined in this draft: Lempel-Ziv
          compression as defined by the ZLIB specification, RFC 1950.
          The table below shows the allowed values for the compress
          option; the option values are case-insensitive.


              Value        Scheme                  Remarks
              ______________________________________________________
              zlib    ZLIB compression   As defined in RFC 1950.
              null    No compression     Data will not be compressed


          The client selects the compression scheme; the server can
          choose to accept or reject it. Acceptance consists of respond-
          ing to the initial request packet (RRQ or WRQ) with an option
          acknowlegement (OACK) packet bearing the same value for the
          compress option.  Rejection consists of either terminating the
          transaction by sending an error (ERROR) packet, or rejecting
          the option value by responding with an option acknowlegement
          (OACK) packet bearing the value 'null' for the compression
          option or missing the option entirely.  For backward compati-
          bility, a response consisting of a simple acknowlegement (ACK)
          packet must be treated as a rejection of the option value.  If
          a client does not wish to continue a transaction after receiv-
          ing a rejection of their data compression option, the client
          shall send an error packet (ERROR) with an error value of 8.

     2.2. Confidentiality Option: sec-crypt

          This option defines the confidentiality scheme to employ.
          There are four schemes: (1) DES encryption using pre-placed
          raw keys, (2) DES encryption using pre-placed passwords and
          PKCS #5 password-based encryption, (3) DES encryption using
          Diffie-Hellman key agreement, and (4) the null scheme which
          uses no encryption or keys.  The table below shows the allowed


Ziring                                                  	[Page 3]

draft-tftp-security-03       TFTP Security               January 6, 1999




          values for the sec-crypt option; the option values are case-
          insensitive.

      Value              Scheme                         Remarks
     _______________________________________________________________________
       des      DES, pre-placed keys        Client and server already hold
                                            keys for each-other.
     despkcs5   DES, pre-placed passwords   Client and server hold a
                                            password for each-other, they
                                            generate a key using the PKCS #5
                                            procedure and a salt supplied by
                                            the client.
        dh      DES, Diffie-Hellman         Client and server perform
                                            Diffie-Hellman key agreement
                                            using pre-defined constants.
       null     No encryption


          DES shall always be used in cipher block chaining (CBC) mode.
          Because DES is a block cipher that operates on 64-bit blocks,
          data must be padded to 8-octet boundaries to be encrypted.
          TFTP plaintext data shall be padded using the simple padding
          scheme defined in PKCS #5 and a variety of other standards:
          from one to eight octets will be appended to the data as pad-
          ding, each octet holding the value of the number of padding
          octets.

          DES in CBC mode requires an initialization vector, or IV, to
          operate. For the "despkcs5" scheme, the IV shall be derived
          from the salt value and password as defined by PKCS #5; see
          Section 2.4.  For the "des" and "dh" schemes an explicit IV
          must be supplied; see Section 2.3.

          The client selects the encryption scheme, and the server can
          choose to accept or reject it. Acceptance consists of respond-
          ing to the initial request packet (RRQ or WRQ) with an option
          acknowlegement (OACK) packet bearing the same value for the
          sec-crypt option.  Rejection consists of either terminating
          the transaction by sending an error (ERR0R) packet, or reject-
          ing the option value by responding with an option acknowlege-
          ment (OACK) packet bearing the value 'null' for the sec-crypt
          option or missing the sec-crypt option entirely.  For backward
          compatibility, a response consisting of a simple acknowlege-
          ment (ACK) packet should be treated as a rejection of the
          option value.  If a client does not wish to continue a tran-
          saction after receiving a rejection of their security options,
          the client shall send an error packet (ERROR) with an error
          value of 8.

          All sec-crypt option values, except 'null', require supporting


Ziring                                                  	[Page 4]

draft-tftp-security-03       TFTP Security               January 6, 1999




          options.  There are three supporting options, described below.

     2.3 Confidentiality Support Option: sec-iv

          Because the TFTP confidentiality schemes employ the DES block
          cipher in CBC mode, the client and the server must share an
          initialization vector (IV); It is the responsibility of the
          party encrypting the file data (client in the case of a WRQ
          transaction, and server in the case of RRQ) to generate an IV
          and send it as an option value to the other party. The sec-iv
          option is used to transmit the IV.  The value of this option
          is an 8 octet quantity expressed as 16 hexadecimal digits,
          most significant byte first.

     2.4. Confidentiality Support Option: sec-salt

          The PKCS #5 specification for password-based encryption
          requires a salt and an iteration count.  The iteration count
          for all TFTP transactions using sec-crypt value 'despkcs5'
          shall be 20.  The salt, 8 octets, shall be selected at random
          by the client, and shall be sent as the value of the sec-salt
          option.  The value of 8-octet salt shall be expressed as 16
          hexadecimal digits, most significant byte first.  It is an
          error for a server to generate an OACK packet containing a
          value of 'despkcs5' for the sec-crypt option and not contain-
          ing a value for the sec-salt option.

     2.5. Confidentiality Support Option: sec-dh

          Performing a 2-party Diffie-Hellman key agreement requires the
          parties to agree in advance on a prime modulus and a base
          (also sometimes called a 'generator').  To perform the key
          agreement, the parties each select a public value and send it
          to the other.  Because Diffie-Hellman values tend to be fairly
          large, and TFTP packets are limited in size, this draft speci-
          fies default modulus and base values that may be used by indi-
          vidual installations for interoperability.  Installations may
          choose to employ distinct sets of Diffie-Hellman parameters,
          possibly on the basis of client or server IP address, if sup-
          ported by the server and client implementations.  All imple-
          mentations of TFTP security as defined by this draft must sup-
          port the default values giving in Section 4, and may support
          other values and site customizations.

          When a client wishes to use Diffie-Hellman key agreement to
          set up a DES key for a transaction, it must select and send
          its public value as the value of the sec-dh option in its ini-
          tial request packet (RRQ or WRQ).  The server, if it accepts
          the sec-crypt value of 'dh' and the accompanying public value,



Ziring                                                  	[Page 5]

draft-tftp-security-03       TFTP Security               January 6, 1999




          must respond with its own public value.  It is an error for a
          TFTP packet that includes a sec-crypt option with value 'dh'
          to omit the sec-dh option.  The value of the sec-dh option is
          simply the Diffie-Hellman public value expressed as a large
          integer in hexadecimal, most significant bit first.

          (The default Diffie-Hellman constants, given in Section 4,
          will result in public values of up to 1024 bits.  Expressed as
          a hexadecimal number, this will require up to 256 octets.)

     2.6. Integrity Option: sec-mac

          This option defines the integrity assurance scheme to employ.
          There are four schemes: (1) SHA.1 message digest, (2) MD5 mes-
          sage digest, (3) DES message authentication code (MAC), and
          (4) the null scheme.  The table below shows the allowed values
          for the sec-mac option; the option values are case-
          insensitive.

                    Value              Scheme             Keyed
                   ____________________________________________
                     sha     SHA.1 message digest          no
                     md5     MD5 message digest            no
                   desmac    DES message authentication    yes
                   shahmac   SHA.1 keyed hash              yes
                   md5hmac   MD5 keyed hash                yes
                    null     No integrity scheme


          If an integrity scheme is specified by the client when ini-
          tiating a transaction (RRQ or WRQ), then the server can only
          accept or reject it.  Acceptance consists of responding to the
          initial request packet (RRQ or WRQ) with an option acknowlege-
          ment (OACK) packet bearing the same value for the sec-mac
          option.  Rejection consists of either terminating the transac-
          tion by sending an error (ERROR) packet, or rejecting the
          option value by responding with an option acknowlegement
          (OACK) packet bearing the value 'null' for the sec-mac option,
          or missing the option entirely.  For backward compatibility, a
          response consisting of a simple acknowlegement (ACK) packet or
          a file data (DATA) packet should be treated as a rejection of
          the option value.  If a client does not wish to continue a
          transaction after receiving a rejection of their security
          options, the client shall send an error packet (ERROR) with an
          error value of 8.

          For the MD5 and SHA.1 integrity schemes, the message digest
          shall be computed over the concatenation of the file name,
          options, the plaintext file data bytes, as described in Sec-
          tion 2.7.  Compression and integrity may be employed in the


Ziring                                                  	[Page 6]

draft-tftp-security-03       TFTP Security               January 6, 1999




          same TFTP transaction, but if they are employed together the
          message digest shall be computed over the uncompressed file
          data.

          For the MD5 HMAC and SHA HMAC integrity schemes, the message
          digest shall be computed using a key pre-placed at the client
          and server.  The HMAC construction specified in RFC 2104 shall
          be used; the composition of the HMAC 'message text' is
          described in Section 2.7, below.  The HMAC key shall be a
          string consisting of printable ASCII characters, from 1 to 64
          bytes in length, padded according to RFC 2104.

          For the DES-MAC integrity scheme, the MAC shall be computed
          using DES in CBC mode with an IV of zero, as specified by FIPS
          PUB 113. The MAC input data, composed according to Section
          2.7, below, shall be padded with exactly the same padding
          scheme used for encryption/decryption.  Note that this will
          require from one to eight octets of padding.  The DES-MAC key
          shall be the key used for confidentiality.  Therefore, a
          client must specify a non-null confidentiality scheme in con-
          junction with the DES-MAC integrity scheme.  It is an error
          for the DES-MAC integrity scheme to be used without confiden-
          tiality.

     2.7. Message Digest/MAC Input Data Form

          The input data for integrity schemes consists of the following
          items: the contents of the initiating request packet, the con-
          tents of the OACK response packet, and the plaintext file
          data. If compression is employed, the uncompressed file data
          must be used as MAC input data.

          For a read request, the input data for integrity is:

                    RRQ Packet || OACK Packet || File data

          For a write request, the input data for integrity is:

                    WRQ Packet || OACK Packet || File data

     2.8. Order and Compatibility of Options

          The order in which options appear in the RRQ, WRQ, or OACK
          packets is not significant.  These options may be used in con-
          junction with any other TFTP options, including the blocksize
          option specified in RFC 2348.  As stipulated in RFC 2347, at
          most one instance of any option may appear in any TFTP packet.





Ziring                                                  	[Page 7]

draft-tftp-security-03       TFTP Security               January 6, 1999




3. Protocol Integration

     The security and compression options described in section 2 are
     designed to be added to the options list in the read request (RRQ),
     write request (WRQ), and option acknowlegement (OACK) packets, as
     described in Section 3.1.  If integrity is requested, by selecting
     one of the values described in section 2.6, then a MAC value shall
     be sent in a separate, trailing data packet.  The receiving party
     shall acknowlege the MAC data packet, as described in Section 3.3.

     3.1. Option Handling

          When making a read request, the TFTP client must specify secu-
          rity options as part of the RRQ packet, using the string
          option format of RFC 2347.  A server compliant with this
          draft, if it can support the client's options list, shall
          respond with an option acknowlegement packet; otherwise the
          server must send an error packet.  A server that does not sup-
          port RFC 2347 will respond with the first data packet, at
          which time the client must make a decision about whether to
          continue with an unsecured transaction.  Upon reviewing the
          option values in the OACK packet, the client must send an ACK
          packet if it accepts the negotiation, or an ERROR packet to
          reject the negotiated options and terminate the transaction.

          When making a write request, the TFTP client must specify
          security options as part of the WRQ packet.  A server compli-
          ant with this draft, if it can support the client's requested
          options, shall respond with an option acknowlegement (OACK)
          packet; otherwise the server must send an error (ERROR)
          packet.  A server that does not support TFTP options as
          defined in RFC 2347 should respond with an ACK packet, at
          which time the client must make a decision about whether to
          continue with an unsecured transaction.  Upon reviewing the
          option values in the OACK packet, the client must send the
          first data packet if it accepts the negotiation, or an ERR
          packet to reject the negotiated options and terminate the
          transaction.

          This specification does not define any new error types.
          Errors related to security or compression option values should
          be denoted with error code 8.  Errors raised during security
          or compression processing during data transfer should be
          denoted with error code 0.  Corruption detected after data
          transfer should be denoted with error code 4.

     3.2. Order of Processing

          The specification defines three kinds of processing that can



Ziring                                                  	[Page 8]

draft-tftp-security-03       TFTP Security               January 6, 1999




          be applied to TFTP data: compression, integrity checking, and
          encryption.  To achieve security and interoperability, these
          transforms must be applied in a particular order.  The diagram
          below shows the processing sequence for client and server.

                     Sender                        Receiver
       File                                                   File
       Name ----->+----------+                   +---------+  Name
                  | Digest   |                   | Digest  |<--'
       File ----->+----------+                   +---------+     File
       Data                                             ^        Data
         |                                              |         ^
         |        +---------+                     +--------+      |
         `------->|Compress |                     |Expand  |------'
                  +---------+                     +--------+
                         |                              ^
                         V                              |
                   +----------+                   +---------+
                   | Encrypt  |                   | Decrypt |
                   +----------+                   +---------+
                         |                              ^
                         `--------- packet stream ------'


     3.3. Transmitting Message Digests

          If a sec-mac option was accepted in the initial exchange of
          request and option acknowlegement packets, then the party
          sending the file data shall also compute and send the
          requested integrity MAC.  The MAC shall be transmitted after
          the file transfer is complete and has been acknowleged; the
          MAC shall always appear by itself in a packet of type DATA.
          The table below shows the size of the MAC sent for each sec-
          mac option value.


                          Scheme  Data Size
                          _____________________________
                                 sha          20 octets
                                 md5          16 octets
                               desmac         8 octets
                               shahmac        20 octets
                               md5hmac        16 octets


          If the integrity scheme is 'null' then no MAC shall be sent.
          The block number for the extra packet containing the integrity
          check value shall be the next value in sequence from the last
          data packet.  If the integrity check succeeds, then the
          receiving party must send an acknowlegement (ACK); if the


Ziring                                                  	[Page 9]

draft-tftp-security-03       TFTP Security               January 6, 1999




          check fails then the receiving party must send an error
          (ERROR) packet with error code 4.

     3.4 TFTP Transfer Modes

          RFC 1350 defines three transfer modes for TFTP: netascii,
          octet, and mail.  If any data compression or security options
          defined in this draft are used, the transfer mode must be
          octet; it is an error for a client to request compression or
          security when initiating a transfer of mode netascii or mail.


4. Default Constants

     For Diffie-Hellman key agreement, the default TFTP constants are
     the same as those specified by the SKIP protocol definition.  In
     hexadecimal, the prime modulus value is:

        0xF4, 0x88, 0xFD, 0x58, 0x4E, 0x49, 0xDB, 0xCD,
        0x20, 0xB4, 0x9D, 0xE4, 0x91, 0x07, 0x36, 0x6B,
        0x33, 0x6C, 0x38, 0x0D, 0x45, 0x1D, 0x0F, 0x7C,
        0x88, 0xB3, 0x1C, 0x7C, 0x5B, 0x2D, 0x8E, 0xF6,
        0xF3, 0xC9, 0x23, 0xC0, 0x43, 0xF0, 0xA5, 0x5B,
        0x18, 0x8D, 0x8E, 0xBB, 0x55, 0x8C, 0xB8, 0x5D,
        0x38, 0xD3, 0x34, 0xFD, 0x7C, 0x17, 0x57, 0x43,
        0xA3, 0x1D, 0x18, 0x6C, 0xDE, 0x33, 0x21, 0x2C,
        0xB5, 0x2A, 0xFF, 0x3C, 0xE1, 0xB1, 0x29, 0x40,
        0x18, 0x11, 0x8D, 0x7C, 0x84, 0xA7, 0x0A, 0x72,
        0xD6, 0x86, 0xC4, 0x03, 0x19, 0xC8, 0x07, 0x29,
        0x7A, 0xCA, 0x95, 0x0C, 0xD9, 0x96, 0x9F, 0xAB,
        0xD0, 0x0A, 0x50, 0x9B, 0x02, 0x46, 0xD3, 0x08,
        0x3D, 0x66, 0xA4, 0x5D, 0x41, 0x9F, 0x9C, 0x7C,
        0xBD, 0x89, 0x4B, 0x22, 0x19, 0x26, 0xBA, 0xAB,
        0xA2, 0x5E, 0xC3, 0x55, 0xE9, 0x2F, 0x78, 0xC7

     The value of the generator is 2.


5. Security Considerations

     For the raw key and password-based encryption options, and for the
     HMAC integrity options, the client and server must agree on key
     values and/or passwords in advance.  These values must be handled
     securely, or the TFTP transactions using them could be subject to
     compromise.

     These security options can provide protection against attackers
     with a certain range of capabilities.  In particular, this specifi-
     cation can offer security only if the attackers are limited to



Ziring                                                 	[Page 10]

draft-tftp-security-03       TFTP Security               January 6, 1999




     network manipulation.

     The security of various option combinations can be analyzed with
     respect to attackers' network capabilities.  For the analysis,
     attackers will be distinguished by three capability levels.

          Level 1. Attacker can intercept all packets (passive sniffing)

          Level 2. Attacker can intercept packets, transmit packets, and
          also modify or delete any packet (full control)

     Against potential attackers with Level 1 capabilities, any of the
     confidentiality schemes may be used to ensure privacy of transmit-
     ted file data.  Any integrity scheme may be used to ensure
     integrity of the file data against accidental network corruption.

     Against potential attackers with Level 2 capabilities, confiden-
     tiality requires pre-placed keys of some sort.  Diffie-Hellman key
     agreement (sec-crypt option value 'dh') is not secure against an
     attacker than can completely control all of the data exchange. How-
     ever, a community of users may select private Diffie-Hellman param-
     eters, and employ them instead of the suggested pair given in Sec-
     tion 4 (if the local TFTP client and server implementations custom
     D-H constants).  Assuming that the selected parameters can be kept
     secret, then the members of the community can employ the Diffie-
     Hellman confidentiality scheme without fear of man-in-the-middle
     attacks by non-members.

     An attacker with any ability to inject or modify network packets
     can corrupt an encrypted data stream; corruption can even be intro-
     duced by the network.  If an integrity option is used, then network
     corruption will normally be detected and the fault handled in an
     implementation-dependent fashion; the corrupted file should be dis-
     carded and an audit event logged. However, an attacker with full
     Level 2 capabilities can corrupt data without detection of the
     sender, or cause good data to be discarded, simply by sending an
     incorrect integrity check value, then deleting the resulting ERR
     packet and substituting an ACK.  This is a form of denial of ser-
     vice, because the sender will believe that the transaction suc-
     ceeded when in fact it did not.  This weakness cannot be corrected
     within the scope of the TFTP.

     As a matter of policy, server hosts supporting encryption with
     pre-placed password (sec-crypt option value 'despkcs5') should
     avoid using the same directory for serving read requests and write
     requests from different hosts.  If the same directory were used,
     malicious users with legitimate access to one host could employ a
     sequence of steps to perform a dictionary attack against the pass-
     words of other hosts.



Ziring                                                 	[Page 11]

draft-tftp-security-03       TFTP Security               January 6, 1999




     In general, if confidentiality is employed, then integrity should
     also be employed.  At a minimum, whenever a request includes a
     non-null confidentiality scheme, it should include a non-null
     integrity scheme, and preferably one of the keyed schemes: DES-MAC,
     SHA HMAC, or MD5 HMAC.


6. Examples

     The examples below illustrate the option structure and packet con-
     tent for two TFTP transfers.

     Example 1: Read Request with Compression and Encryption

          In this example, a client initiates a read request for a
          2000-byte binary file named "f1.dat", specifying ZLIB-
          compliant compression and DES encryption using pre-placed raw
          keys.


      Client                                  Server        Message
  -----------------------------------------------------------------
  |1|f1.dat|0|octet|0|compress|0|zlib|0|                       RRQ
   sec-crypt|0|des|0|sec-mac|0|null|0| -->
             <-- |6|compress|0|zlib|0|sec-crypt|0|des|0|       OACK
                  sec-iv|0|1f43e801c2672d50|0|sec-mac|0|null|0|
  |4|0| -->                                                    ACK
                <-- |3|1|512 bytes of compressed ciphertext|   DATA
  |4|1| -->                                                    ACK
                <-- |3|2|512 bytes of compressed ciphertext|   DATA
  |4|2| -->                                                    ACK
        <-- |3|3|136 bytes compressed ciphertext w/ padding|   DATA
  |4|3| -->                                                    ACK

     Example 2: Write request with D-H key generation and a MAC

          In this example, a client initiates a write request to upload
          a 1149-byte text file named "r1.txt", specifying DES encryp-
          tion with Diffie-Hellman key agreement, and a SHA.1 integrity
          check.












Ziring                                                 	[Page 12]

draft-tftp-security-03       TFTP Security               January 6, 1999




      Client                                  Server        Message
  -----------------------------------------------------------------
  |2|r1.txt|0|octet|0|sec-crypt|0|dh|0|sec-mac|0|sha|0|        WRQ
   sec-iv|0|1f43e801c2672d50|0|sec-dh|0|40{252 bytes}9f|0| -->
                <--   |6|sec-crypt|0|dh|0|sec-mac|0|sha|0|     OACK
                       sec-dh|0|73{252 bytes}8d|0|
  |3|1|512 bytes of ciphertext| -->                            DATA
                                    <-- |4|1|                  ACK
  |3|2|512 bytes of ciphertext| -->                            DATA
                                    <-- |4|2|                  ACK
  |3|3|128 bytes ciphertext w/ padding| -->                    DATA
                                    <-- |4|3|                  ACK
  |3|4|20 byte SHA.1 checksum|  -->                            DATA
                                    <-- |4|4|                  ACK

     Example 3: Read Request with Encryption and Large Blocks

          In this final example, a client initiates a read request for a
          1904-byte file named "v2.pdf", specifying 2048-byte blocks,
          and password-based encryption.  Note that this requires a
          password pre-placed at the server, and the same password sup-
          plied to the client (possibly by a human user).



      Client                                  Server        Message
  -----------------------------------------------------------------
  |1|v2.pdf|0|octet|0|                                          RRQ
   Sec-Crypt|0|Despkcs5|0|Blksize|0|2048|0| -->
              <-- |6|sec-crypt|0|despkcs5|0|blksize|0|2048|0|  OACK
                   sec-salt|0|1e5840f1a81d0217|0|
  |4|0| -->                                                     ACK
              <-- |3|1|1912 bytes ciphertext w/ padding|       DATA
  |4|1| -->                                                     ACK



7. References

       [1]   Sollins, K., "The TFTP Protocol (Revision 2)," STD 33, RFC
             1350, October 1992.

       [2]   Malkin, G., and A. Harkin, "TFTP Option Extension," RFC
             2347, May 1998.

       [3]   Malkin, G., and A. Harkin, "TFTP Blocksize Option," RFC
             2348, May 1998.

       [4]   Krawczyk, H., M. Bellare, and R. Canetti, "HMAC: Keyed-



Ziring                                                 	[Page 13]

draft-tftp-security-03       TFTP Security               January 6, 1999




             Hashing for Message Authentication," RFC 2104, February
             1997.

       [5]   Deutsch, P., and Gailly, J-L., "ZLIB Compressed Data Format
             Specification version 3.3," RFC 1950, May 1996.

       [6]   Rivest, R., "The MD5 Message-Digest Algorithm," RFC 1321,
             April 1992.

       [7]   NIST FIPS PUB 46-2, "Data Encryption Standard (DES),"
             National Institute of Standards and Technology, U.S.
             Department of Commerce, December 1993.

       [8]   NIST FIPS PUB 113, "Computer Data Authentication," National
             Institute of Standards and Technology, U.S. Department of
             Commerce, May 1985.

       [9]   NIST FIPS PUB 180-1, "Secure Hash Standard," National
             Institute of Standards and Technology, U.S. Department of
             Commerce, April 1995.

       [10]  "PKCS #3: Diffie-Hellman Key Agreement Standard", Version
             1.4, RSA Laboratories, November 1993.

       [11]  "PKCS #5: Password-Based Encryption Standard", Version 1.5,
             RSA Laboratories, November 1993.


8. Author's Address

     Neal Ziring
     Organization C43
     National Security Agency
     9800 Savage Rd
     Ft. Meade, MD, 20755-6704

     Phone: (410) 854-6191

     EMail: nziring@thematrix.ncsc.mil













Ziring                                                 	[Page 14]

