N. Ziring INTERNET DRAFT 6 January 1999 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]