HMTFTP: HMAC-Derived TFTP with Optional AEAD Protection (v0.4)

The Trivial File Transfer Protocol (TFTP) is extremely simple but provides no built-in security properties. HMTFTP retains the TFTP operational model (UDP, numbered blocks, ACKs) while introducing (1) a compact TLV extension mechanism and (2) an optional AEAD protection mode for DATA payloads. The name "HMTFTP" reflects that cryptographic keys are derived using HKDF, a HMAC-based key derivation function . Version v0.4 adds IANA considerations for a service name and UDP port assignment and establishes registries for TLV Types and ciphersuites.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 ( and ) when, and only when, they appear in all capitals. This document uses the following terms:

PSK: pre-shared key
AEAD: authenticated encryption with associated data
AAD: additional authenticated data

HMTFTP is derived from TFTP and reuses the core message types and semantics (RRQ, WRQ, DATA, ACK, ERROR). It also reuses the concept of an explicit option acknowledgment, OACK, as introduced by TFTP option extension . HMTFTP replaces the key/value option encoding of RFC 2347 with a TLV encoding defined in this document. HMTFTP differs from baseline TFTP primarily by:

using UDP port TBD1 by default (configurable), rather than 69;
allowing TLV extensions in RRQ, WRQ, and OACK;
supporting an optional AEAD security mode for DATA payloads.

HMTFTP runs over UDP. The default server port is TBD1, but implementations MUST allow the port to be configured. As in TFTP, a transfer is conducted between a client and a server transfer address (IP, UDP port). The server MAY respond from a different UDP port than TBD1 for the remainder of the transfer, as described in .

All multi-octet fields are encoded in network byte order (big-endian). HMTFTP reuses the TFTP base message formats, with TLVs appended to RRQ, WRQ, and OACK. TLVs are not used in DATA, ACK, or ERROR in this version.

RRQ and WRQ are defined as in : RRQ/WRQ = OpCode (2) || Filename (N) || 0 || Mode (M) || 0 || [TLVs] The optional TLV sequence, when present, begins immediately after the terminating zero octet of the Mode field and continues to the end of the UDP datagram. The Mode is a NUL-terminated ASCII string (e.g., "octet").

OACK is used by the server to acknowledge and/or modify the TLVs offered in RRQ/WRQ. OACK is defined by as OpCode value 6. In HMTFTP, OACK contains only a TLV sequence: OACK = OpCode (2) || TLVs An OACK with an empty TLV sequence indicates acceptance with no negotiated parameters.

DATA and ACK are as defined in : DATA = OpCode (2) || Block (2) || Payload (0..n) ACK = OpCode (2) || Block (2) When AEAD protection is negotiated (), the DATA Payload is structured as: Ciphertext || Tag, where Tag is a 16-octet AES-GCM authentication tag. The ciphertext length is the datagram length minus 4 octets of header and minus 16 octets of tag.

ERROR is as defined in : ERROR = OpCode (2) || ErrorCode (2) || ErrMsg (string) || 0 HMTFTP endpoints SHOULD use an ERROR with ErrorCode 0 ("Not defined") for extension processing failures (e.g., unsupported critical TLV).

HMTFTP TLVs extend RRQ, WRQ, and OACK. TLVs use a compact binary encoding: TLV Format

Field	Size	Description
Type	16 bits	Type code with Critical bit in MSB
Length	16 bits	Length of Value in octets
Value	variable	Type-specific data

The most significant bit (MSB) of the Type field is the Critical bit. Bits 0-14 form the 15-bit TLV code. The Critical bit is not part of the code space recorded by IANA (see ). Processing rules:

A receiver MUST ignore unknown TLVs with Critical=0.
A receiver that encounters an unknown TLV with Critical=1 MUST reject the message by sending an ERROR (and MUST NOT proceed with the transfer).
A receiver MAY accept known TLVs in any order. If a TLV appears multiple times, a receiver SHOULD treat this as an error unless the TLV definition explicitly allows repetition.

This specification defines the following TLVs. All multi-octet values are encoded in network byte order (big-endian). Defined TLVs

Code	Name	Length	Description
0x0001	BLKSIZE	2	Requested maximum DATA payload size in octets (uint16). If offered by a client, the server MUST respond with BLKSIZE in OACK with the selected value, which MUST be less than or equal to the requested value.
0x0002	TIMEOUT	2	Requested retransmission timeout in seconds (uint16). If offered by a client, the server MUST respond with TIMEOUT in OACK with the selected value or reject the request.
0x0003	TSIZE	8	Transfer size in octets (uint64). In RRQ, a client MAY send TSIZE=0 to request that the server return the size. In WRQ, a client SHOULD send TSIZE with the size if known.
0x0010	ENC_REQ	0	Request to enable AEAD protection for DATA payloads (empty value). Clients that require security mode MUST set the Critical bit on ENC_REQ. Servers that accept security mode MUST echo ENC_REQ in OACK.
0x0011	CIPHER	2	Select ciphersuite (uint16). If omitted, the default ciphersuite is 0x0001 (AES-256-GCM).
0x0012	CNONCE	16	Client nonce (16 octets) generated by a CSPRNG. CNONCE MUST be present in RRQ/WRQ when ENC_REQ is present.
0x0013	SNONCE	16	Server nonce (16 octets) generated by a CSPRNG. SNONCE MUST be present in OACK when ENC_REQ is accepted.

The ciphersuite value 0x0001 corresponds to AEAD AES-256-GCM.

HMTFTP uses the following procedure, aligned with TFTP option negotiation :

The client sends RRQ or WRQ, optionally with TLVs.
If the server accepts the request and any offered parameters, it replies with OACK containing the negotiated TLVs (which MAY be empty). If the server does not support a critical TLV or rejects parameters, it replies with ERROR.
For RRQ: the client sends ACK(0) after receiving OACK, then the server starts with DATA(1).
For WRQ: the client starts with DATA(1) after receiving OACK, and the server acknowledges each block with ACK(n).

Apart from the OACK exchange, block numbering, retransmissions, and EOF signaling follow .

Security mode is negotiated using TLVs in RRQ/WRQ and OACK. When enabled, each DATA payload is protected with AEAD AES-256-GCM . The AEAD key and IV base are derived using HKDF-SHA-256 .

The client requests security mode by including TLV ENC_REQ in RRQ/WRQ. When ENC_REQ is present, the client MUST include CNONCE and MAY include CIPHER. If the server accepts, it includes ENC_REQ and SNONCE in OACK and MAY include (or echo) CIPHER. If the server does not support security mode, it MUST reject a Critical ENC_REQ with ERROR.

This document assumes an externally provisioned PSK (32 octets RECOMMENDED). During negotiation, the client and server exchange nonces: CNONCE and SNONCE, each 16 octets from a CSPRNG. The AEAD key material is derived as follows:

IKM = PSK
salt = CNONCE || SNONCE (32 octets)
info = "hmtftp keys v1"
OKM = HKDF-SHA-256(IKM, salt, info, 44)
key = OKM[0..31] (32 octets)
iv_base = OKM[32..43] (12 octets)

The HKDF "info" string is a protocol constant. Implementations MUST use the exact value "hmtftp keys v1" to ensure interoperability across document revisions.

The AES-GCM nonce (12 octets) for DATA block number n is: nonce = iv_base[0..7] || uint32(n) where uint32(n) is the 32-bit big-endian encoding of the DATA block number (n is the 16-bit Block field widened to 32 bits). The AEAD AAD is the 4-octet DATA header (OpCode || Block). RRQ/WRQ/OACK metadata and TLVs are not encrypted and are not included in the DATA AAD in v0.4. Retransmissions MUST retransmit the exact same ciphertext and tag for a given block number (key, nonce).

To avoid nonce reuse, endpoints MUST NOT allow the 16-bit block number to wrap within a security context. Implementations SHOULD terminate a transfer with ERROR well before wrap if it would be reached.

This section clarifies how HMTFTP remains interoperable with the operational model of TFTP while enabling extensions through TLVs. It also specifies governance rules intended to keep extensions safe, deterministic, and implementable on constrained devices.

HMTFTP reuses the TFTP message types (RRQ, WRQ, DATA, ACK, ERROR) and the OACK concept from the TFTP option extension. Implementations MUST follow the state machine of TFTP for block numbering, retransmissions, and EOF detection, except where explicitly modified by this document. When a peer does not send or accept TLVs, endpoints MUST fall back to baseline TFTP behavior as described in and MUST NOT assume that security mode is available. A client that requires security mode MUST mark ENC_REQ as Critical so that servers that do not support it reject the request rather than silently downgrading.

The TLV Type field is 16 bits on the wire. The most significant bit is the Critical bit; the remaining 15 bits are the TLV Code. New TLVs MUST be specified with clear semantics, encoding, processing rules, and interoperability expectations. To reduce collision risks, this document reserves the TLV Code range 0x7F00-0x7FFF for Private Use. Implementations MAY use Private Use TLVs in controlled environments, but such TLVs MUST NOT be used as inputs to cryptographic processing and MUST be ignored by receivers unless explicitly configured. Unknown TLVs with Critical=0 MUST be ignored. Unknown TLVs with Critical=1 MUST cause the request to be rejected with ERROR. This rule is the primary downgrade and interoperability safety mechanism for this specification.

This section provides implementer-oriented guidance intended to make independent implementations converge on compatible behavior, especially under loss, reordering, and constrained-device conditions.

Endpoints SHOULD use a configurable retransmission timeout (RTO) and exponential backoff, consistent with TFTP practice. A TIMEOUT TLV (if supported) negotiates the initial RTO. Implementations SHOULD cap the maximum number of retransmissions to bound resource usage. When security mode is enabled, retransmissions MUST retransmit the exact same ciphertext and tag for a given block number, as required to avoid nonce reuse hazards.

Implementations SHOULD avoid IP fragmentation by selecting BLKSIZE so that the resulting UDP datagram fits within the path MTU. Guidance in applies. If fragmentation or ICMP Packet Too Big indications are observed, senders SHOULD reduce BLKSIZE.

Servers SHOULD bound work performed before establishing that the client is on-path (e.g., avoid large responses to unauthenticated requests), apply rate-limiting, and cap concurrent transfers. In untrusted networks, a cookie or address-validation mechanism may be needed in a future version.

HMTFTP is designed for managed environments where provisioning and update traffic is common, but it intentionally avoids using the legacy TFTP well-known port (69/udp) to reduce operational ambiguity and accidental cross-protocol interactions. This document suggests 6369/udp as a candidate default port because it is close to the historical TFTP port and is memorable for operators. The port remains configurable and deployments MAY choose a different port when required by local policy.

Without security mode, HMTFTP provides no confidentiality or integrity beyond UDP checksums and is vulnerable to on-path modification and spoofing, as with TFTP . With security mode enabled, only DATA payloads are encrypted and authenticated. RRQ/WRQ/OACK metadata and TLVs remain in cleartext. This means filenames, modes, and negotiated parameters are observable on the wire. Deployments that require metadata confidentiality MUST avoid placing sensitive data in RRQ/WRQ/OACK and SHOULD use an external secure channel or a future extension that encrypts metadata. Nonce reuse with AES-GCM is catastrophic. Implementations MUST enforce nonce uniqueness and MUST follow the nonce construction and wrap limits described in . Implementations should also consider UDP robustness guidelines () and rate-limiting to mitigate amplification and resource-exhaustion attacks.

This section is provided for RFC 7942 compliance (). Implementations, interop notes, and known limitations will be added in subsequent versions.

IANA is requested to assign a service name and UDP port with the following values in the "Service Name and Transport Protocol Port Number Registry" (). This document suggests 6369/udp as the requested port number. Until assignment, this document uses TBD1 as the default port value. HMTFTP Service Name and Port

Service Name	Transport Protocol	Port Number	Reference
hmtftp	udp	TBD1	This document

IANA is requested to create a registry titled "HMTFTP TLV Types". The registry is for 15-bit TLV codes (0x0000-0x7FFF). The Critical bit (MSB of the 16-bit Type field on the wire) is not part of the registry. The TLV Code range 0x7F00-0x7FFF is reserved for Private Use. Private Use TLVs MUST be ignored by receivers unless explicitly configured and MUST NOT be used as inputs to cryptographic processing. Registration policy: Expert Review (). The registry records: TLV Code, Name, Description, and Reference. Initial TLV Registry Entries

Code	Name	Description	Reference
0x0000	Reserved	Reserved for future use	This document
0x0001	BLKSIZE	Block size in octets (uint16)	This document
0x0002	TIMEOUT	Retransmission timeout in seconds (uint16)	This document
0x0003	TSIZE	Transfer size in octets (uint64)	This document
0x0010	ENC_REQ	Request AEAD protection (empty value)	This document
0x0011	CIPHER	Select ciphersuite (uint16)	This document
0x0012	CNONCE	Client nonce (16 octets)	This document
0x0013	SNONCE	Server nonce (16 octets)	This document

Note: BLKSIZE/TIMEOUT/TSIZE are conceptually similar to the options in and , but use TLV encoding rather than ASCII key/value pairs.

IANA is requested to create a registry titled "HMTFTP OpCodes". Registration policy: Expert Review (). The registry records the OpCode value, name, and reference. Initial OpCode Registry Entries

Value	Name	Reference
1	RRQ	RFC1350
2	WRQ	RFC1350
3	DATA	RFC1350
4	ACK	RFC1350
5	ERROR	RFC1350
6	OACK	RFC2347

IANA is requested to create a registry titled "HMTFTP Ciphersuites". Registration policy: Expert Review (). The registry records the ciphersuite value, name, description, and reference. Initial Ciphersuite Registry Entries

Value	Name	Description	Reference
0x0000	Reserved	Reserved for future use	This document
0x0001	AES-256-GCM	AEAD AES-256-GCM	This document