[secdir] draft-ietf-pim-gaap-18 ietf last call Secdir review

[Tim Hollebeek via Datatracker <[e-mail]>]

Document: draft-ietf-pim-gaap
Title: Group Address Allocation Protocol (GAAP)
Reviewer: Tim Hollebeek
Review result: Has Issues

SECDIR review of draft-ietf-pim-gaap-18

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other last call
comments.

Summary: Has issues. GAAP allocates multicast group addresses by hashing a
group name and detecting collisions via unauthenticated UDP Claim messages.
Statelessness and an unauthenticated base mode are defensible for an
Experimental, domain-scoped protocol, and -18 has improved the security text.
The issues below are mostly things Security Considerations should state more
plainly or fix.

Major

Persistent denial of allocation. The four candidate addresses for a name are
deterministic and computable by anyone who knows the name. Nothing requires a
receiver to verify that a Claim's name field hashes to the address it claims —
Section 8's guidance to ignore such Claims is a non-normative lowercase
"should." An on-network attacker can therefore contest all four candidates with
spoofed Claims bearing fabricated early timestamps; the victim yields each time
and gaap.allocate() returns None with no retry. Even against an implementation
that does enforce the Section 8 check, the cost rises only to a targeted
preimage over the masked bits (~2^22 for the IPv4 /10, ~2^32 for the IPv6 /32)
— not a barrier. Security Considerations should state that the base mode offers
no protection against an on-network attacker and is suitable only within a
trusted domain.

Timestamp arbitration is exploitable in the past direction. "Earliest wins,"
but only far-future timestamps are sanity-checked. An attacker fabricates an
old timestamp and always wins, indistinguishably from a genuine old claim (so
the "invalid timestamp → bad-actor list" mitigation can't fire — it only
triggers when an even-earlier claim exists, i.e. when the attacker loses).
Separately, the draft notes an unset post-boot clock reads far in the past —
such a node legitimately wins every collision, a robustness bug with no
attacker present. A far-past plausibility rule symmetric with the far-future
one seems warranted.

Encryption gaps. ChaCha20 alone is malleable (the Marker is a redundancy check,
not integrity); consider AEAD as MUST-when-encrypting rather than SHOULD. Nonce
management is unspecified, which is dangerous with one shared key across many
senders. The cleartext header isn't bound as AEAD associated data. Sections 4
and 8 contradict each other on whether the Marker stays cleartext (Section 4)
or is non-0xAAAAAAAA on the wire and only appears after decryption (Section 8).
And nothing requires a keyed receiver to reject plaintext Claims, permitting
trivial downgrade.

The bad-actor list can be turned into the attack. Since sources are spoofable,
an attacker can spoof misbehaving Claims from a victim's address to get the
victim blacklisted, and can inflate the list itself (state exhaustion on a
stateless protocol). Entries should be bounded and advisory.

Minor

The fallback candidates are built by string concatenation (H("foo+1") etc.), so
a legitimate primary name "foo+1" aliases foo's second candidate — reachable by
ordinary API allocation, and also by accident. Hash-level domain separation of
the attempt number would remove this; it does not, however, mitigate item 1.

Nits

Section 6 title: "Detail Protocol Operation" → "Detailed".
Section 5.1 code: mismatched parens in format(...) and a missing colon on the
callback def.