HMTFTP: HKDF-Derived TFTP with Optional AEAD Protection (v0.7)

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

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."¶

This Internet-Draft will expire on 30 September 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶

Table of Contents

3. Relationship to TFTP and Compatibility

6. TLV Encoding, Definitions, and Negotiation

7. Transfer Procedure

8. Key Derivation

HMTFTP assumes an externally provisioned PSK. Key derivation uses HKDF-SHA-256 as specified in [RFC5869]. In security mode:¶

• 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)¶

Implementations MUST use the exact info string above for interoperability.¶

9. Nonce Construction

For DATA block number n, nonce (12 octets) is:¶

nonce = iv_base[0..7] || uint32(n)¶

where uint32(n) is big-endian and n is the 16-bit DATA block number widened to 32 bits.¶

Block-number wrap MUST NOT occur within one security context. Endpoints MUST terminate transfer before 65536 DATA blocks.¶

10. AEAD Processing Rules

This section applies only when security mode is successfully negotiated.¶

• Algorithm: AEAD AES-256-GCM ([RFC5116]).¶

• AAD: 4-octet DATA header (OpCode || Block).¶

• Ciphertext length equals plaintext length.¶

• Tag length is 16 octets and is appended to ciphertext.¶

• Retransmission of a DATA block MUST retransmit identical ciphertext and tag for that block number.¶

• A valid duplicate DATA(n) (same ciphertext and tag as previously accepted for n) MUST be acknowledged with ACK(n) and MUST NOT be delivered twice to the application.¶

• If a DATA(n) authenticates but differs from the stored accepted ciphertext/tag for the same n, the endpoint MUST abort the transfer.¶

• Duplicate ACK(n) packets MAY occur and MUST be ignored if they do not advance sender state.¶

On authentication failure, receiver MUST discard the DATA block and MUST NOT acknowledge it as valid. The receiver MUST NOT emit per-packet authentication error signals.¶

Duplicate packets within the same transfer context are treated as retransmissions, not as replays. Packets from other transfer contexts (different TID and/or different negotiated key material) MUST NOT be accepted as valid for the active transfer.¶

After consecutive authentication failures or retransmission timeout exhaustion for a block, endpoint MUST terminate the transfer context. It MAY send at most one generic ERROR (ErrorCode 0) before closing.¶

BLKSIZE in security mode refers to plaintext bytes only.¶

12. Timers and Retransmissions

Endpoints SHOULD support configurable retransmission timeout (RTO), exponential backoff, and a maximum retransmission count.¶

TIMEOUT TLV (if offered and accepted) sets the initial RTO value for the transfer.¶

In AEAD mode, retransmissions MUST reuse exactly the same ciphertext and tag for a given DATA block.¶

13. Datagram Sizing and PMTU

Implementations SHOULD avoid IP fragmentation and follow UDP usage guidance from [RFC8085].¶

In AEAD mode, effective DATA datagram payload is: 4 (DATA header) + BLKSIZE + 16 (GCM tag).¶

Senders SHOULD choose BLKSIZE so resulting datagrams fit path MTU and SHOULD reduce BLKSIZE when fragmentation or Packet Too Big indications are observed.¶

14. Resource Limits and DoS Mitigations

Servers SHOULD bound pre-authentication work, rate-limit ERROR responses, and cap concurrent transfers.¶

Implementations SHOULD enforce limits for:¶

• maximum negotiated BLKSIZE;¶

• maximum transfer size and duration;¶

• maximum outstanding transfer contexts.¶

In untrusted environments, additional address-validation or cookie mechanisms may be required by deployment policy.¶

18. Security Considerations

Without security mode, HMTFTP provides no confidentiality or integrity beyond UDP checksums, consistent with baseline TFTP.¶

With security mode enabled, only DATA payloads are encrypted and authenticated. RRQ/WRQ/OACK metadata (filename, mode, TLVs) remains cleartext and observable on path.¶

Nonce reuse with AES-GCM is catastrophic. Implementations MUST enforce nonce uniqueness and MUST prevent block-number wrap in one security context.¶

Endpoints MUST treat authentication failures as potential active attacks or corruption events and MUST terminate transfer state after bounded retry limits, without exposing per-packet validity side channels.¶

Clients requiring AEAD protection MUST mark ENC_REQ as Critical and MUST abort if negotiation is downgraded or not acknowledged.¶

PSK provisioning, storage, rotation, and access control are out of scope for wire protocol definition but are critical to real security.¶

19. IANA Considerations

Appendix A. Example Negotiated RRQ Exchange (Informative)

This appendix illustrates a complete RRQ flow with TLV negotiation and AEAD mode enabled. Values are examples for implementer guidance.¶

Request context:¶

• Filename: "firmware.bin"¶

• Mode: "octet"¶

• Requested BLKSIZE: 1024¶

• Requested TIMEOUT: 3 seconds¶

• Security requested: ENC_REQ (Critical), CIPHER=0x0001¶

• CNONCE: 16 octets from CSPRNG¶

Example TLVs in RRQ (Type, Length, Value):¶

BLKSIZE: 0x0001 0x0002 0x0400
TIMEOUT: 0x0002 0x0002 0x0003
ENC_REQ: 0x8010 0x0000
CIPHER : 0x0011 0x0002 0x0001
CNONCE : 0x0012 0x0010 00112233445566778899aabbccddeeff

Server accepts request and returns OACK with negotiated values:¶

BLKSIZE: 0x0001 0x0002 0x0400
TIMEOUT: 0x0002 0x0002 0x0003
ENC_REQ: 0x8010 0x0000
CIPHER : 0x0011 0x0002 0x0001
SNONCE : 0x0013 0x0010 a0a1a2a3a4a5a6a7a8a9aaabacadaeaf

RRQ transfer sequence then proceeds:¶

1. Client -> Server: RRQ + TLVs¶

2. Server -> Client: OACK + TLVs¶

3. Client -> Server: ACK(0)¶

4. Server -> Client: DATA(1) with ciphertext length 1024 and tag length 16¶

5. Client -> Server: ACK(1)¶

6. Server -> Client: DATA(2) ...¶

7. ...¶

8. Server -> Client: final DATA(n) with plaintext length < 1024 (EOF)¶

9. Client -> Server: ACK(n)¶

For DATA block 1, nonce is computed as:¶

nonce(1) = iv_base[0..7] || 0x00000001
AAD      = DATA header (OpCode=3, Block=1)

If DATA(1) is retransmitted due to loss, ciphertext and tag are retransmitted unchanged and the receiver re-ACKs block 1 without delivering duplicate plaintext.¶

Appendix B. Reproducible Test Procedure (Informative)

<CODE BEGINS>
python3 -m venv .venv
.venv/bin/pip install -r requirements.txt
.venv/bin/pytest -q
./scripts/smoke_local.sh
# optional capture workflow (requires sudo):
sudo WAIT_SECS=10 ./scripts/capture_aead.sh \
  /tmp/hmtftp-aead-proof.pcap 192.0.2.1 6369 \
  demo-psk-32-bytes-minimum
# or:
sudo WAIT_SECS=10 ./scripts/capture_aead.sh \
  /tmp/hmtftp-aead-proof.pcap 2001:db8::1 6369 \
  demo-psk-32-bytes-minimum

<CODE ENDS>

Appendix C. Crypto / TLV Consistency Notes (Informative)

PSK    = 30313233343536373839616263646566
         30313233343536373839616263646566
CNONCE = 00112233445566778899aabbccddeeff
SNONCE = a0a1a2a3a4a5a6a7a8a9aaabacadaeaf
key    = e14c36452ca1954c3929b824ececc63d
         fa5c7e4203c75b98ee16f46a0a852cc6
iv_base= 8a5669a255600f2c7c6ae475
nonce1 = 8a5669a255600f2c00000001
aad1   = 00030001

Appendix D. Conformance Matrix (Informative)

Test ID mapping:¶

• T1 = tests/test_tlv.py function test_parse_unknown_critical_tlv_rejected¶

• T2 = tests/test_tlv.py function test_duplicate_tlv_rejected¶

• T3 = tests/test_tlv.py function test_malformed_tlv_rejected¶

• T4 = tests/test_tlv.py function test_request_forbidden_snonce_rejected¶

• T5 = tests/test_negotiation.py function test_rrq_secure_negotiation_produces_required_oack_tlvs¶

• T6 = tests/test_negotiation.py function test_cipher_mismatch_in_oack_rejected¶

• T7 = tests/test_crypto.py function test_hkdf_derivation_vector¶

• T8 = tests/test_crypto.py function test_nonce_and_aad_construction¶

• T9 = tests/test_crypto.py function test_aead_authentication_failure¶

• T10 = tests/test_integration_transfer.py function test_secure_download_with_oack¶

• T11 = tests/test_integration_transfer.py function test_secure_upload¶

• T12 = tests/test_negotiation.py function test_client_rejects_secure_downgrade_when_oack_omits_security_tlvs¶

• T13 = tests/test_session.py function test_secure_duplicate_identical_ok¶

• T14 = tests/test_session.py function test_secure_duplicate_invalid_dropped¶

• T15 = tests/test_session.py function test_secure_duplicate_valid_mismatch_aborts¶

Appendix E. Post-Quantum PSK Provisioning (Informative)

This appendix is informative and does not modify the HMTFTP wire protocol. The protocol continues to assume an externally provisioned PSK.¶

One experimental approach is to establish shared key material out of band using ML-KEM from [FIPS203], then derive and provision a PSK for HMTFTP endpoints.¶

1. Perform ML-KEM key establishment out of band.¶

2. Derive a deployment PSK from the established shared secret (policy-specific derivation outside this wire specification).¶

3. Install the resulting PSK on both peers before HMTFTP transfer.¶

This draft does not specify a tested ML-KEM tooling workflow. The appendix is limited to architectural positioning of out-of-band PSK provisioning and does not define a deployment procedure.¶

Native post-quantum handshake negotiation inside HMTFTP messages is out of scope for this document revision.¶

Acknowledgements

The author thanks David Mercier for helpful discussions and feedback.¶

Author's Address