INTERNET DRAFT Neal Ziring Expires: 26 Dec 1999 National Security Agency draft-ziring-nsa-tftp-security-01.txt 26 May 1999 TFTP Compression and Security Options Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 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-ziring-nsa-tftp-securityTFTP Security May 25, 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 extension mechanism 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 shall not be 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. 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 primary 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. The security options are integrated into TFTP using the extension mechanism defined by RFC 2347. The security options detailed in this draft employ a very small set of fundamental cryptographic algorithms: the DES block cipher, SHA.1 and MD5 message digests, 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 standard. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are interpreted as described in RFC 2119. Ziring [Page 2] draft-ziring-nsa-tftp-securityTFTP Security May 25, 1999 2. Option Specifications The options described in this section fall into three feature areas: four options to support confidentiality, two to support integrity, and one to support compression. Compression, confidentiality, and integrity can all be used together or separately, as discussed in Section 6. If security or compression services are desired for a particular transaction, the transaction initiator, the client, must include all salient compression and security options in their initial read request (RRQ) or write request (WRQ) packet, to conform to RFC 2347. The server may reject requests that include or omit certain options, based on server capabilities, configuration, or security policy; when a server rejects a transaction based on the option setting, it must send an error packet (ERROR) with an error value of 8. RFC 2347 also stipulates that TFTP option names and values shall be expressed in case-insensitive ASCII. The sections below define the single compression option and the six 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 acknowledgment (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 acknowledgment (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 acknowledgment (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 Ziring [Page 3] draft-ziring-nsa-tftp-securityTFTP Security May 25, 1999 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 seven defined schemes: (1) DES encryption using pre-placed raw keys, (2) DES encryption using pre-placed pass- words and PKCS #5 password-based encryption (type PBES1), (3) DES encryption using Diffie-Hellman key agreement, (4) Triple-DES encryption using pre-placed raw keys, (5) Triple- DES encryption using pre-placed passwords and PKCS #5 password-based encryption (type PBES2 with SHA1-HMAC), (6) Triple-DES encryption using Diffie-Hellman key agreement, and (7) the null scheme which uses no encryption or keys. The table below shows the allowed 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 DES keys for each-other. despbes1 DES, with passwords Client and server hold a password for each-other, they generate a DES key using the PKCS #5 PBES1 procedure and a salt supplied by the client. desdh DES, Diffie-Hellman Client and server perform Diffie-Hellman key agreement using pre-defined constants, and generate a DES key. des3 3DES, pre-placed keys Client and server already hold Triple-DES keys for each-other. des3pbes2 3DES, with passwords Client and server hold a password for each-other, they generate a Triple-DES key using the PKCS #5 PBES2 procedure and a salt supplied by the client. des3dh 3DES, Diffie-Hellman Client and server perform Diffie-Hellman key agreement using pre-defined constants, and generate a Triple-DES key. 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. Triple-DES shall always be used in EDE3-CBC mode, employing a 168-bit key. Because Triple-DES is a block cipher that Ziring [Page 4] draft-ziring-nsa-tftp-securityTFTP Security May 25, 1999 operates on 64-bit blocks, data must be padded to 8-octet boundaries to be encrypted. For CBC mode, both DES and Triple-DES require an initializa- tion vector, or IV, to operate. For the "despbes1" scheme, the IV shall be derived from the salt value and password as defined by PKCS #5 PBES1 procedure; see Section 2.4. For the "des3pbes2" scheme, the IV shall be derived using the PKCS #5 PBES2 procedure and a pseudo-random function of SHA1- HMAC, as described in [11, pp. 8,9,20] and in [4]. A salt must be supplied; see Section 2.4. The PBES2 procedure shall be used to create a password-derived key value of 256 bits. Of these bits, the low-order 192 bits (24 bytes) shall be used for the Triple-DES data encryption key, by setting the parity bit of each byte as specified in [12]. The high-order 64 bits (8 bytes) shall be used as the IV. For the "des", "des3", "desdh", and "des3dh" schemes an expli- cit IV must be supplied; see Section 2.3. In all encryption schemes except the null scheme, TFTP plain- text data shall be padded using the simple padding scheme defined in PKCS #5 v2.0: from one to eight octets will be appended to the data as padding, each octet holding the value of the number of padding octets. 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 acknowledgment (OACK) packet bearing the same value for the sec-crypt option. Rejection consists of either terminating the transaction by sending an error (ERROR) packet, or reject- ing the option value by responding with an option acknowledg- 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 acknowledg- 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 options. There are three supporting options, described below. 2.3 Confidentiality Support Option: sec-iv Because the TFTP confidentiality schemes employ the DES block Ziring [Page 5] draft-ziring-nsa-tftp-securityTFTP Security May 25, 1999 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. It is an error when the party responsible for encrypting the file data omits a required sec-iv option from their RRQ, WRQ, or OACK packet, and it is an error if the IV is not 8 octets. 2.4. Confidentiality Support Option: sec-salt The PKCS #5 v2.0 specification for password-based encryption stipulates selection of a salt and an iteration count. The iteration count for all TFTP transactions using sec-crypt value "despbes1" or "des3pbes2" shall be 1020. 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 a RRQ) to generate a salt and send it as an option value to the other party. The salt shall be 8 octets in length and gen- erated at random for each transaction. The value of the 8- octet salt shall be expressed as 16 hexadecimal digits, most significant byte first. It is an error when the party responsible for encrypting the file data omits a required sec-salt option from their RRQ, WRQ, or OACK packet, and it is an error if the salt value is not 8 octets. 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 relative to the maximum TFTP packet size, this draft specifies default modulus and base values that may be used by individual installations for interoperability. Installations may choose to employ distinct sets of Diffie-Hellman parame- ters, possibly on the basis of client or server IP address, if supported by the server and client implementations. All implementations of TFTP security as defined by this draft must support the default values giving in Section 4, but may sup- port other values and site customizations at the implementors discretion. Ziring [Page 6] draft-ziring-nsa-tftp-securityTFTP Security May 25, 1999 When a client wishes to use Diffie-Hellman key agreement to set up a DES or Triple-DES encryption key for a transaction, it must select and send its public value as a sec-dh option in its initial request packet (RRQ or WRQ). The server, if it accepts the sec-crypt value of "desdh" or "des3dh" and the accompanying public value, must respond with its own public value in its options acknowledgment (OACK) packet. It is an error for a TFTP packet that includes a sec-crypt option with value "desdh" or "des3dh" 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 signi- ficant bit first. (The default Diffie-Hellman constants, given in Section 4, will result in a public value of 1024 bits. Expressed as a hexadecimal number, this will require 256 octets.) 2.6. Integrity Option: sec-mac This option defines the integrity assurance scheme to employ. There are six schemes: (1) SHA.1 message digest, (2) MD5 mes- sage digest, (3) DES message authentication code (MAC), (4) SHA.1 HMAC, (5) MD5 HMAC, and (6) the null scheme. The table below shows the allowed values for the sec-mac option; the option values are case-insensitive. Value Scheme MAC Key _____________________________________________________ sha SHA.1 message digest none md5 MD5 message digest none desmac DES message authentication encryption key shahmac SHA.1 keyed hash pre-placed key md5hmac MD5 keyed hash pre-placed key 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 acknowledg- 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 acknowledgment (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 acknowledgment (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 Ziring [Page 7] draft-ziring-nsa-tftp-securityTFTP Security May 25, 1999 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 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.8, below. The HMAC key shall be a string consisting of printable ASCII characters, from 32 to 64 characters 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.8, 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. A client must specify a non-null confidentiality scheme in conjunction with the DES-MAC integrity scheme. If DES is used for confiden- tiality, then DES-MAC key shall be the same key. If Triple- DES is used for confidentiality, then the DES-MAC key shall be computed from the Triple-DES key as the bitwise exclusive-or of the three individual DES keys that make up the Triple-DES key, and a constant mask, as shown below. K(mac) = 0xF1F1F1F1 ^ K(3des)[0..7] ^ K(3des)[8..15] ^ K(3des)[16..23] 2.7. Integrity Support Option: sec-nonce The sec-nonce option provides a means for the client or server to make a particular TFTP transaction unique; this prevents replay attacks. The form and use of the sec-nonce option is detailed below. For more information about the security rationale behind this option, see Section 5. When a TFTP client initiates a read request (RRQ) that speci- fies a non-null integrity scheme, and then the client may also include the sec-nonce option. When a TFTP server responds to a write request (WRQ) packet that specifies a non-null integrity scheme, then the server may also include the sec- Ziring [Page 8] draft-ziring-nsa-tftp-securityTFTP Security May 25, 1999 nonce option in the response (OACK) packet. Inclusion of the sec-nonce option is mandatory under any of the following situations: - If a client initiates a write request (WRQ) including a non-null value for the sec-mac option and not including the sec-dh option, then the server must include the sec-nonce option in their option acknowledgment (OACK) packet. - If a client initiates a read request (RRQ) including a non-null value for the sec-mac option and not including the sec-dh option, then the client must also include the sec-nonce option in their read request packet. The value of the sec-nonce option shall be 16 octets in length and generated at random for each transaction. The 16-octet random nonce shall be expressed as 32 hexadecimal digits. 2.8. 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. 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), Ziring [Page 9] draft-ziring-nsa-tftp-securityTFTP Security May 25, 1999 write request (WRQ), and option acknowledgment (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 acknowledge 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 option for- mat defined by RFC 2347. A server compliant with this draft, if it can support the client's options list, must respond with an option acknowledgment (OACK) packet; otherwise the server must send an error packet (ERROR). A server that does not support 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- nowledgement (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 acknowledgment (OACK) packet; otherwise the server must send an error packet. A server that does not support TFTP options as defined in RFC 2347 will respond with an ACK packet, at which time the client must make a decision about whether to continue with an unsecured transaction. After processing the option values in the OACK packet, the client must send the first data packet if it accepts the negotiation, or an error 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 This draft defines three kinds of processing that can 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. Ziring [Page 10] draft-ziring-nsa-tftp-securityTFTP Security May 25, 1999 Sender Receiver Initial Initial Negotiation-->+----------+ +---------+ Negotiation | 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 acknowledgment 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 acknowledged; 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 data packet containing the integrity check value shall be the next value in sequence from the last data packet (see Section 6). If the integrity check succeeds, then the receiving party must send an acknowledgment (ACK); if the check fails then the receiving party must send an error (ERROR) packet with error code 4. Furthermore, if the integrity check fails the receiving party must discard the transferred file. Ziring [Page 11] draft-ziring-nsa-tftp-securityTFTP Security May 25, 1999 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. 3.5 Conformance This draft specifies extensions to the TFTP; a TFTP client or server implementation need not support these extensions. If a TFTP implementation does support security, it must sup- port at least a minimal set of confidentiality and integrity schemes to be considered compliant with this draft. The table below lists the schemes that are mandatory for secure TFTP server and client implementations. Scheme Option Mandatory Recommended ___________________________________________________________ confidentiality sec-crypt des des3pbes2, des3dh integrity sec-mac desmac shahmac 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. Ziring [Page 12] draft-ziring-nsa-tftp-securityTFTP Security May 25, 1999 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 net- work manipulation. The security of various option combinations can be analyzed with respect to attackers' network capabilities. For the analysis, attackers will be distinguished by two 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 exchanges. However, a community of users may select private Diffie-Hellman parameters and employ them instead of the suggested pair given in Section 4, if the local TFTP client and server implementations sup- port 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 the 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. But, 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 error packet and (ERROR) substituting an acknowledgment (ACK). This is a form of Ziring [Page 13] draft-ziring-nsa-tftp-securityTFTP Security May 25, 1999 denial of service, because the sender will believe that the tran- saction succeeded 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 "despbes1") should avoid using the same directory for serving both 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 passwords of other hosts. If an attacker has the ability to record an entire TFTP transac- tion, then he can attempt to replicate that transaction at a later time. This kind of 'replay' attack can be very serious, depending to the application of the files transferred. To deter replay attacks, this draft specifies a mechanism that allows the file recipient to detect replay attempts: the sec-nonce option. Because the sec-nonce option makes each TFTP transaction unique, any of the integrity schemes listed in Section 2.6 can detect replay attempts by an attacker with level 1 capabilities. The keyed integrity schemes, "desmac", "shahmac", and "md5hmac", can detect replay attempts by an attacker with level 2 capabilities. In either case, the result will be an integrity check failure (see Section 3.3). The protocol described in this draft cannot detect replay attacks prior to the integrity check performed at the end of the transac- tion. 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, preferably one of the keyed schemes: "desmac", "shahmac", or "md5hmac". 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. Ziring [Page 14] draft-ziring-nsa-tftp-securityTFTP Security May 25, 1999 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 Triple-DES encryption with Diffie-Hellman key agreement, and a SHA.1 integrity check. Client Server Message ----------------------------------------------------------------- |2|r1.txt|0|octet|0|sec-crypt|0|des3dh|0|sec-mac|0|sha|0| WRQ sec-iv|0|1f43e801c2672d50|0|sec-dh|0|40{252 bytes}9f|0| --> <-- |6|sec-crypt|0|des3dh|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). Ziring [Page 15] draft-ziring-nsa-tftp-securityTFTP Security May 25, 1999 Client Server Message ----------------------------------------------------------------- |1|v2.pdf|0|octet|0| RRQ Sec-Crypt|0|despbes1|0|Blksize|0|2048|0| --> <-- |6|sec-crypt|0|despbes2|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 Example 4: Write Request with Strong Integrity In this final example, a client initiates a write request for a 1000-byte file named "r4.conf", specifying a SHA1 HMAC integrity scheme. Note that this requires a key pre-placed at the server, and the same key supplied to the client (possibly by a human user). Client Server Message ----------------------------------------------------------------- |2|r4.conf|0|octet|0|sec-mac|0|shahmac|0| --> RRQ <-- |6|sec-mac|0|shahmac|0| OACK sec-nonce|0|1ae3568e4012f1a81d02179cb43a0021|0| |3|1|512 bytes of plaintext| --> DATA <-- |4|1| ACK |3|2|488 bytes of plaintext| --> DATA <-- |4|2| ACK |3|3|20 byte SHA.1 checksum| --> DATA <-- |4|3| 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-Hashing for Message Authentication," RFC 2104, February 1997. [5] Deutsch, P., and Gailly, J-L., "ZLIB Compressed Data Format Ziring [Page 16] draft-ziring-nsa-tftp-securityTFTP Security May 25, 1999 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 Com- merce, December 1993. [8] NIST FIPS PUB 113, "Computer Data Authentication," National Institute of Standards and Technology, U.S. Department of Com- merce, 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 2.0 RSA Laboratories, March 1999. [12] American National Standard X9.52 - 1998, "Triple Data Encryption Algorithm Modes of Operation", Working draft, ASC X9, July 1998. 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 17]