Pre-Shared-Key Object Authentication for RIFP
draft-dulaunoy-rifp-auth-00

Network Working Group                                        A. Dulaunoy
Internet-Draft              Computer Incident Response Center Luxembourg
Intended status: Experimental                            10 October 2026
Expires: 13 April 2027

             Pre-Shared-Key Object Authentication for RIFP
                      draft-dulaunoy-rifp-auth-00

Abstract

   This document defines an optional object authentication extension for
   the Radio Image Framing Protocol (RIFP).  A critical header TLV
   authenticates the compact object descriptor using HMAC-SHA-256 and a
   pre-shared key.  The descriptor binds the encoded image digest and
   decoding parameters to a session and chunk count.  The extension uses
   existing RIFP framing, fragmentation, retransmission and offline IQ
   workflows.  It does not provide confidentiality, replay protection or
   a public-key digital signature.

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 13 April 2027.

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.

Dulaunoy                  Expires 13 April 2027                 [Page 1]
Internet-Draft         RIFP Object Authentication           October 2026

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   2
   3.  Object Authentication Header TLV  . . . . . . . . . . . . . .   3
   4.  Keys and Authenticated Transcript . . . . . . . . . . . . . .   4
   5.  Sender and Receiver Processing  . . . . . . . . . . . . . . .   5
   6.  Reference Implementation and Offline Testing  . . . . . . . .   6
   7.  Test Vector . . . . . . . . . . . . . . . . . . . . . . . . .   6
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
   11. Normative References  . . . . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   The CRC-32 and SHA-256 fields in [RIFP] detect accidental corruption,
   but an attacker can replace an image and recompute both fields.  This
   extension authenticates the mandatory 56-octet OBJECT_DESCRIPTOR with
   a key shared by the sender and receiver.  After reassembly, the
   receiver checks the image against that authenticated descriptor
   before decoding or publishing it.

   Implementation and use of this extension are OPTIONAL.  Ordinary
   unsigned RIFP transfers remain valid.  Applications needing
   authenticated images MUST configure the receiver to require
   authentication; detecting a TLV alone cannot prevent an attacker from
   stripping it.

2.  Conventions and Terminology

   The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this
   document are to be interpreted as described in [RFC2119] and
   [RFC8174] when, and only when, they appear in all capitals.

   All multioctet integers use network byte order.  Concatenation means
   literal octet concatenation, without separators, alignment, text
   conversion or implicit length fields.  A tag is a message
   authentication code (MAC), not a public-key signature.  Key IDs
   identify locally provisioned keys and are not credentials or
   statements of sender identity.

Dulaunoy                  Expires 13 April 2027                 [Page 2]
Internet-Draft         RIFP Object Authentication           October 2026

3.  Object Authentication Header TLV

   This experimental draft uses Private Use base type 0x4001 from the
   RIFP Header TLV Base Types registry.  The Critical bit MUST be set,
   producing wire type 0xC001.  This is a private-use interoperability
   convention, not an IANA allocation; deployments MUST coordinate its
   use to avoid collisions.

   The TLV MUST occur exactly once on every OBJECT_DESCRIPTOR frame
   belonging to an authenticated transfer, including each retransmitted
   descriptor.  It MUST NOT occur on MANIFEST, DATA, END or CANCEL
   frames.  Descriptors for the same transfer MUST carry byte-identical
   authentication values.  The TLV Length is 35 + N, where N is the Key
   ID Length.

      +==============+===============+=============================+
      | Value offset | Size (octets) | Field                       |
      +==============+===============+=============================+
      | 0            | 1             | Extension Version: 1        |
      +--------------+---------------+-----------------------------+
      | 1            | 1             | Algorithm: 1 (HMAC-SHA-256) |
      +--------------+---------------+-----------------------------+
      | 2            | 1             | Key ID Length: N, from 1    |
      |              |               | through 32                  |
      +--------------+---------------+-----------------------------+
      | 3            | N             | Key ID                      |
      +--------------+---------------+-----------------------------+
      | 3 + N        | 32            | Authentication Tag          |
      +--------------+---------------+-----------------------------+

                                 Table 1

   Key ID consists only of ASCII letters, digits, period, underscore or
   hyphen.  It is case-sensitive.  The value MUST contain exactly the
   indicated fields; trailing octets, truncated fields, invalid Key IDs,
   duplicate TLVs and an unset Critical bit MUST be rejected.
   Unsupported extension versions or algorithms MUST be rejected, not
   treated as unsigned transfers.  Future algorithms require a separate
   specification of their key, tag and transcript semantics; algorithm
   negotiation is not defined here.

   The extension consumes 39 + N header octets including its four-octet
   TLV header.  Senders MUST respect the core 255-octet header limit
   when adding other extensions; they MUST fail rather than silently
   omit authentication.  No changes to the RIFP major or minor version,
   frame types, payload layouts, flags or radio profile are required.

Dulaunoy                  Expires 13 April 2027                 [Page 3]
Internet-Draft         RIFP Object Authentication           October 2026

4.  Keys and Authenticated Transcript

   Algorithm 1 uses HMAC with SHA-256 as defined in [RFC2104] and
   [RFC6234].  The full 32-octet tag is transmitted without truncation.
   The pre-shared key MUST contain exactly 32 uniformly random octets.
   Passwords MUST NOT be used directly as keys.  Provisioning, rotation
   and authorization of keys are local policy and are outside the on-air
   protocol.  The key MUST NOT be transmitted in a frame or embedded in
   a manifest.  A receiver MUST select a key from trusted local
   configuration using the Key ID; it MUST NOT retrieve a key from a
   sender-provided URL or file path.

   The authenticated transcript M is the following concatenation:

   M = Domain || AuthenticationPrefix || Context || Descriptor

   Domain = ASCII("RIFP-OBJECT-AUTH-v1") || 0x00
   AuthenticationPrefix = 0x01 || 0x01 || N || KeyID
   Context = 0x01 || 0x00 || SessionID || TotalCount
   Descriptor = the exact 56-octet OBJECT_DESCRIPTOR payload

   Tag = HMAC-SHA-256(PSK, M)

   N is one octet.  SessionID is the eight-octet Session ID from the
   descriptor frame header.  TotalCount is the four-octet Total Count
   from that header and MUST be greater than zero.  The Context prefix
   0x01 0x00 denotes RIFP 1.0 object semantics; it remains fixed for
   backward-compatible minor-version additions.  A future incompatible
   object format requires a new extension version.  The
   AuthenticationPrefix includes the version, algorithm and Key ID, but
   excludes the tag itself and the enclosing TLV header.

   The descriptor is validated according to [RIFP] before use.  Its
   reserved fields MUST be zero.  Its image encoding, pixel format,
   dimensions, chunk size, encoded size, CRC-32 and SHA-256 are
   authenticated byte for byte.  The SHA-256 digest authenticates the
   complete encoded object indirectly.  Receivers MUST still check the
   reassembled object's size, CRC-32 and SHA-256 against the
   authenticated descriptor.  A valid tag alone does not establish that
   the received DATA payloads are authentic.

Dulaunoy                  Expires 13 April 2027                 [Page 4]
Internet-Draft         RIFP Object Authentication           October 2026

   Optional JSON MANIFEST contents and other header TLVs, including
   filename, creation time, Sender ID, Content Hint and Radio Profile,
   are NOT authenticated by this extension.  Core consistency checks
   still apply.  Applications MUST NOT treat those fields as
   authenticated assertions.  Advisory retransmission flags, individual
   DATA frames and CANCEL frames are also outside the MAC; their
   manipulation can prevent delivery, but cannot produce a different
   authenticated image.  DATA need not carry the TLV, allowing existing
   reordering, repetition and recovery behavior.

5.  Sender and Receiver Processing

   A sender enabling this extension MUST compute the descriptor and
   chunk count before calculating the tag.  It MUST attach the critical
   TLV to each descriptor frame.  The existing frame CRC-32 covers the
   header, including the authentication TLV, and the payload as
   specified in [RIFP].

   A receiver supporting this extension MUST reject an authenticated
   descriptor when its key is unavailable, its Key ID is unauthorized,
   the TLV is malformed, or verification fails.  Tags MUST be compared
   in constant time.  There MUST NOT be fallback to unsigned processing
   of that descriptor.  Once an authenticated descriptor is accepted, an
   unsigned or differently authenticated descriptor for the same active
   session MUST cause the session to be abandoned.  A receiver SHOULD
   retain a bounded failure record until session expiry so repeated
   frames cannot immediately recreate an abandoned authenticated session
   as unsigned.  This record is not a replay cache.

   A receiver MAY buffer DATA before the descriptor within core resource
   limits.  It MUST NOT decode, save, display or otherwise release an
   authenticated image until BOTH descriptor MAC verification and
   complete-object integrity checks have succeeded.  This also applies
   to saving the encoded payload.  A valid unsigned descriptor MAY be
   processed only if local policy permits unsigned objects.  Receivers
   SHOULD clearly distinguish verified images from unsigned images in
   their user interface or logs.

   Applications requiring authentication MUST reject descriptors without
   this extension, independently of whether a signed descriptor has
   already been seen.  Otherwise, stripping all authentication TLVs and
   recomputing frame CRCs allows an attacker to downgrade a transfer to
   ordinary unsigned RIFP.  Requiring authentication is a receiver
   policy, not a property inferred from untrusted traffic.

Dulaunoy                  Expires 13 April 2027                 [Page 5]
Internet-Draft         RIFP Object Authentication           October 2026

   A receiver without support rejects the unknown critical TLV and
   therefore cannot accept the authenticated transfer's mandatory
   descriptor.  Such a receiver can still process ordinary unsigned RIFP
   transfers.  The critical extension is optional to implement, but
   mandatory to understand when present.

6.  Reference Implementation and Offline Testing

   The Python implementation uses only the standard library for
   cryptography.  Both tools accept --auth-key-file PATH for a file
   containing exactly 32 raw key bytes, and --auth-key-id ID for a
   public identifier (default default).  The receiver additionally
   accepts --require-auth.  Without that option, unsigned transfers
   remain permitted even when a verification key is loaded.
   Authenticated descriptors without a matching configured key are
   rejected.  In IQ-file mode, --require-auth returns a nonzero exit
   status if no authenticated image completes.

   An example from the repository root, with a securely provisioned PSK
   file:

  python3 radiofax_sender.py example/input-formats/telefunken-rifp.png \
    --preset small --codec group4 --bits 1 \
    --packet-repeats 1 --manifest-repeats 1 --duty-cycle 1 \
    --auth-key-file /secure/rifp.psk --auth-key-id station-1 \
    --iq-output /tmp/authenticated.cf32

  python3 radiofax_receiver.py --iq-input /tmp/authenticated.cf32 \
    --auth-key-file /secure/rifp.psk --auth-key-id station-1 \
    --require-auth --output-dir /tmp/authenticated-images

  python3 -m unittest -v test_rifp_auth.py

   Conformance testing covers signed and unsigned IQ loopbacks, valid
   frame CRCs on tampered data, recomputed unkeyed image integrity
   values, wrong or missing keys, unknown Key IDs, authentication
   stripping, descriptor/session binding, malformed and duplicate TLVs,
   repeated and reordered frames, and legacy critical-extension
   rejection.  The existing codec/preset fixture tests remain applicable
   because authentication does not change image encoding.

7.  Test Vector

   The following public test key MUST NOT be used in deployments.
   Hexadecimal strings have no embedded whitespace; displayed line
   breaks are for readability.

Dulaunoy                  Expires 13 April 2027                 [Page 6]
Internet-Draft         RIFP Object Authentication           October 2026

   PSK = 000102030405060708090a0b0c0d0e0f
         101112131415161718191a1b1c1d1e1f
   Key ID = "test-key" (8 ASCII octets)
   Session ID = 7
   Total Count = 1
   Encoded image = 78 (one grayscale pixel, value 120)

   Descriptor =
   01050400000100010001000000000000000000018cdc1683
   2d711642b726b04401627ca9fbac32f5c8530fb1903cc4db02258717921a4881

   TLV Type = c001
   TLV Length = 002b
   TLV Value =
   010108746573742d6b6579
   e23c131f627f7d83f5e784d653971c53eff32049da2176dddf2a0fff2ec3d3d3

   The tag has also been checked independently using OpenSSL HMAC-SHA-
   256.

8.  Security Considerations

   This extension provides image integrity and proof of possession of a
   shared key.  Any party holding the key, including a receiver, can
   forge a valid transfer.  It provides neither nonrepudiation nor proof
   of a unique sender.  Different authorization groups SHOULD use
   different keys.  Keys MUST be stored with appropriate access controls
   and rotated following compromise.  Key IDs and image contents remain
   visible; stable IDs can enable tracking.

   Binding the session ID prevents transplantation of a descriptor's tag
   into a different session.  It does not prevent replay of the complete
   original session and image.  Deployments needing freshness MUST add
   an independently specified replay/freshness mechanism or external
   policy.  Merely generating random session IDs or retaining sessions
   temporarily is not replay protection.

   An adversary can still jam, delete, reorder or inject frames, spoof
   cancellation or modify unauthenticated metadata.  Such attacks can
   deny service.  Resource limits, safe image decoders and all core
   hostile-input checks remain required.  A MAC authenticates bytes from
   a key holder, not the safety of decoding them.

   No confidentiality, encrypted key exchange, public-key algorithm,
   certificates or downgrade-resistant capability negotiation are
   defined.  Authentication stripping is addressed by explicitly
   requiring authentication at the receiver.

Dulaunoy                  Expires 13 April 2027                 [Page 7]
Internet-Draft         RIFP Object Authentication           October 2026

9.  IANA Considerations

   This document makes no IANA registration request.  Base type 0x4001
   is in the core registry's Private Use range.  An interoperable public
   allocation would require a later revision and the core Specification
   Required procedure; it MUST NOT be represented as assigned by this
   experimental draft.

10.  References

11.  Normative References

   [RFC2104]  Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
              Hashing for Message Authentication", RFC 2104,
              DOI 10.17487/RFC2104, February 1997,
              <https://www.rfc-editor.org/info/rfc2104>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and SHA-based HMAC and HKDF)", RFC 6234,
              DOI 10.17487/RFC6234, May 2011,
              <https://www.rfc-editor.org/info/rfc6234>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RIFP]     Dulaunoy, A., "Radio Image Framing Protocol (RIFP)", Work
              in Progress, Internet-Draft, draft-dulaunoy-rifp-00, July
              2026,
              <https://datatracker.ietf.org/doc/draft-dulaunoy-rifp/>.

Author's Address

   Alexandre Dulaunoy
   Computer Incident Response Center Luxembourg
   Email: alexandre.dulaunoy@circl.lu

Dulaunoy                  Expires 13 April 2027                 [Page 8]