RFC 5709 - OSPFv2 HMAC-SHA Cryptographic Authentication

Overview

Positive

what Ze has

Neutral

measures that are neither good news nor bad

The 8 shares marked as a part above are the whole of the 14 gated MUSTs: they add to 100%. Proven by a recorded break is a share of TAGGED UNITS, a different population, so it is not one of them.

At a glance

Enrolment

Enrolled: OSPFv2 HMAC-SHA Cryptographic Authentication (AuType 2), including key selection, digest construction and receive verification. RFC 7474 uses the same Sign/Verify backend with extended sequence numbers, source-bound Apad and a protocol-ID key suffix.

What the public ledger says

Status: Experimental

What the ledger says is covered:

What the ledger says remains:

Coverage

Positive and negative tests (13): RFC5709-3-1, RFC5709-3.1-1, RFC5709-3.1-2, RFC5709-3.1-3, RFC5709-3.1-4, RFC5709-3.3-1, RFC5709-3.3-2, RFC5709-3.3-3, RFC5709-3.3-4, RFC5709-3.4-1, RFC5709-3.4-2, RFC5709-3.2-1, RFC5709-3.2-2

Annotated (including scoped evidence) (1): RFC5709-3-5

Requirements

Gaps and untested MUSTs

RFC 5709 declares no gap, and every gated MUST it carries has a test bound to it.

Proof state

A tagged unit reads unproven where no discrimination record exists for it: nothing in this tree has been observed to break it, so the claim its tag makes is unproven.

RFC5709-3-1

Of the above, implementations of this specification MUST include support for at least: HMAC-SHA-256 (§3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. (a) forbidden: an implementation without a correct HMAC-SHA-256; (b) TestOSPFAuthSignVerifyCrypto/hmac-sha-256 asserts Sign succeeds and the trailer equals rfc5709ReferenceDigest, an independent test-side HMAC-SHA-256 construction, and that Verify accepts it; the negative rejects a wrong-key digest

RFC5709-3-5

An implementation of this specification MUST allow network operators to configure ANY authentication algorithm supported by that implementation for use with ANY given KeyID value that is configured into that OSPFv2 router. (Section 3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. TestRFC5709AnyAlgorithmUnderAnyKeyID drives operator config: five key-chain texts rotate md5 and hmac-sha-1/256/384/512 over Key IDs 1,77,200,254,255 through parseOSPFConfig, validateConfig and the running engine's verifyPacket, auth failures 0. Judge overlay fixing the algorithm per Key ID in resolveChainKeys turns every shift red; Key ID 0 (not sampled) also passes under a judge overlay. {single-polarity: positive} on the row; record observed red on resolveChainKeys.

RFC5709-3.1-1

Second, set the Authentication Type to Cryptographic Authentication (§3.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. (a) forbidden: sending an HMAC-SHA packet whose Authentication Type is not Cryptographic Authentication (2); (b) TestEngineSignPacketCrypto asserts the on-wire AuType of eng.signPacket output equals AuTypeCryptographic; negative TestOSPFAuthStoreSignVerify asserts a non-crypto AuType packet is refused under crypto config

RFC5709-3.1-2

set the Authentication Data Length field to the length (measured in bytes, not bits) of the cryptographic hash that will be used. When any NIST SHS algorithm is used in HMAC mode with OSPFv2 Cryptographic Authentication, the Authentication Data Length is equal to the normal hash output length (measured in bytes) for the specific NIST SHS algorithm in use. (§3.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. c23 re-judge (independent judge). Positive: TestRFC5709AuthDataLengthIsHashOutputLength signs AuType 2 under HMAC-SHA-1/256/384/512 and asserts af[3] == the literal 20/32/48/64 (not the production table), the trailer is that many octets and equals rfc5709ReferenceDigest (independent Ko, Apad and HMAC); overlay authDigestLen SHA-256 -> 31 reds it (scratch/c23/a1). Negative (owner ruling 2, handling of a peer packet with the wrong field): TestRFC5709WrongAuthDataLengthRejected presents an HMAC-SHA-1 packet with af[3]=32 whose 20-octet digest is computed independently over that very header, so only the length field differs from the verifying control (af[3]=20); Verify refuses it. Overlay removing Verify's int(af[3]) != l guard reds only this unit while TestOSPFAuthSignVerifyCrypto and TestOSPFAuthCryptoRejectsExtraTrailerBytes stay green (a2), closing the earlier finding. Observed-red records on authDigestLen and Verify. HEAD units supplementary.

RFC5709-3.1-3

Third, the 32-bit cryptographic sequence number is set in accordance with the procedures in RFC 2328, Appendix D that are applicable to the Cryptographic Authentication type. (§3.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-09-30 (continuation 7, judge): the weak finding (no sender-side sequence assertion) is closed. TestRFC5709CryptoSequenceNonDecreasingOnInterface signs five Hellos through eng.signPacket on eth0 and reloads the key from Key ID 1 to 2 before the fourth; each packet's 32-bit sequence (auth offset 4) is not below the previous one (RFC 2328 D.4.3 (5): non-decreasing), Key ID checked per packet. Positive revert record on signKey re-recorded by the judge after continuation 8 changed signKey, observed red. Negative: TestOSPFAuthReplay-side replayedSequence refusal (revert record observed red). The packet-level round-trip positive in packet/auth_verify_test.go has no record (pre-existing).

RFC5709-3.1-4

Fourth, the message digest is then calculated and appended to the OSPF packet, as described below in Section 3.3. (§3.1)

Audit verdict: enforced (the tests do what the requirement demands), fresh. (a) forbidden: a digest not appended after the OSPF packet (e.g. inside the 8-byte auth field or counted in Packet Length); (b) TestOSPFAuthSignVerifyCrypto asserts Packet Length == plen, len(signed) == plen+L and signed[plen:] equals the independent reference digest over signed[:plen]; negative TestOSPFAuthCryptoRejectsExtraTrailerBytes rejects a trailer that is not exactly the appended digest

RFC5709-3.3-1

First, the OSPFv2 packet's Authentication Trailer (which is the appendage described in RFC 2328, Section D.4.3, Page 233, items (6)(a) and (6)(d)) is filled with the value Apad, and the Authentication Type field is set to 2. (§3.3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. (a) forbidden: hashing with a trailer not filled with Apad, or with the AuType field not 2; (b) TestOSPFAuthSignVerifyCrypto asserts the trailer equals rfc5709ReferenceDigest, which fills literal 0x878FE1F3 x L/4 over the AuType-2 packet; TestRFC5709ReceiveRejectsWrongHashConstruction/zero-apad asserts Verify rejects a zero-filled-trailer digest

RFC5709-3.3-2

In this application, Ko is always L octets long. If the Authentication Key (K) is L octets long, then Ko is equal to K. If the Authentication Key (K) is more than L octets long, then Ko is set to H(K). If the Authentication Key (K) is less than L octets long, then Ko is set to the Authentication Key (K) with zeros appended to the end of the Authentication Key (K), such that Ko is L octets long. (§3.3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. (a) forbidden: Ko not equal to K at L, not H(K) above L, not zero-padded below L; (b) TestRFC5709ReceiveIndependentDigest asserts Sign equals an independent construction and Verify accepts for SHA-256 keys of 31, 32 and 33 octets, TestOSPFAuthSignVerifyCrypto covers a 28-octet key hashed for SHA-1; TestRFC5709ReceiveRejectsWrongHashConstruction/underived-long-key asserts the raw 33-octet key (standard HMAC, B=64) is rejected

RFC5709-3.3-3

Then, a First-Hash, also known as the inner hash, is computed as follows: First-Hash = H(Ko XOR Ipad || (OSPFv2 Packet)) Implementation Notes: Note that the First-Hash above includes the Authentication Trailer containing the Apad value, as well as the OSPF packet, as per RFC 2328, Section D.4.3. The definition of Apad (above) ensures it is always the same length as the hash output. This is consistent with RFC 2328. The "(OSPFv2 Packet)" mentioned in the First-Hash (above) does include the OSPF Authentication Trailer. The digest length for SHA-1 is 20 bytes; for SHA-256, 32 bytes; for SHA-384, 48 bytes; and for SHA-512, 64 bytes. (3) SECOND-HASH Then a Second-Hash, also known as the outer hash, is computed as follows: Second-Hash = H(Ko XOR Opad || First-Hash) (§3.3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. (a) forbidden: a digest other than H(Ko XOR Opad || H(Ko XOR Ipad || packet-with-Apad-trailer)), or of the wrong length; (b) TestOSPFAuthSignVerifyCrypto asserts the trailer equals hmacWithPad (test-side Ipad/Opad construction) for all four SHA algorithms, fixing the 20/32/48/64 lengths; TestRFC5709ReceiveRejectsWrongHashConstruction/inner-hash-only asserts an inner hash alone is rejected

RFC5709-3.3-4

The resulting Second-Hash becomes the Authentication Data that is sent in the Authentication Trailer of the OSPFv2 packet. The length of the Authentication Trailer is always identical to the message digest size of the specific hash function H that is being used. (§3.3)

Audit verdict: enforced (the tests do what the requirement demands), fresh. (a) forbidden: a trailer carrying anything but Second-Hash, or of a length other than the digest size; (b) TestOSPFAuthSignVerifyCrypto asserts len(signed)==plen+L and the trailer equals the reference Second-Hash; TestRFC5709ReceiveRejectsWrongHashConstruction/inner-hash-only asserts a length-L inner hash is rejected, and a flipped trailer byte is rejected

RFC5709-3.4-1

the cryptographic calculation of the message digest follows the procedure in Section 3.3 above when any NIST SHS algorithm in the HMAC mode is in use. Kindly recall that the cryptographic algorithm/mode in use is indicated implicitly by the KeyID of the received OSPFv2 packet. Implementation Notes: One must save the received digest value before calculating the expected digest value, so that after that calculation the received value can be compared with the expected value to determine whether to accept that OSPF packet. RFC 2328, Section D.4.3 (6) (c) should be read very closely prior to implementing the above. With SHA algorithms in HMAC mode, Apad is placed where the MD5 key would be put if Keyed-MD5 were in use. (§3.4)

Audit verdict: enforced (the tests do what the requirement demands), fresh. (a) forbidden: verifying without the section 3.3 computation, overwriting the received digest before comparing, not placing Apad in the trailer, or not selecting by KeyID; (b) TestRFC5709ReceiveRejectsWrongHashConstruction asserts zero-Apad, underived-key and inner-only digests are rejected while the valid control is accepted; TestOSPFAuthSignVerifyCrypto rejects a flipped digest byte; TestRFC5709ReceiveIndependentDigest accepts an independent digest and asserts Verify left the wire bytes unchanged; TestEngineReceiveSelectsSecurityAssociation rejects packets outside the KeyID's association and counts them

RFC5709-3.4-2

Kindly recall that the cryptographic algorithm/mode in use is indicated implicitly by the KeyID of the received OSPFv2 packet. (§3.4)

Audit verdict: enforced (the tests do what the requirement demands), fresh. (a) forbidden: choosing the algorithm or key other than by the received KeyID (trying other associations); (b) TestEngineReceiveSelectsSecurityAssociation asserts a KeyID 8 (SHA-512) packet signed with SHA-256 and a KeyID 9 packet signed with KeyID 7's secret are rejected even though another configured association verifies them, and unknown KeyID 99 is rejected; TestOSPFAuthCryptoRejectsKeyIDMismatch rejects a non-matching KeyID with the same secret; positives accept each KeyID under its own algorithm

RFC5709-3.2-1

When a new key replaces an old, the KeyStartGenerate time for the new key MUST be less than or equal to the KeyStopGenerate time of the old key. (Section 3.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. (a) forbidden: a new key whose KeyStartGenerate is after the old key's KeyStopGenerate; (b) TestKeyRolloverGapRejected asserts validateConfig returns ErrKeyRolloverGap for start 2026-03-01 after end 2026-02-01, and TestKeyRolloverOverlapAccepted asserts an overlapping rollover validates. The equal-time boundary is not exercised

RFC5709-3.2-2

In the event that the last key associated with an interface expires, it is unacceptable to revert to an unauthenticated condition (§3.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. Re-judged 2026-09-30 (continuation 8, judge): row narrowed per R35 to the MUST NOT (no revert to an unauthenticated condition); the 'not advisable to disrupt routing' clause moved to RFC5709-3.2-5. Positive TestRFC5709LastKeyExpiredStillSigns: only key's send and accept lifetimes over, a Hello through eng.signPacket leaves AuType 2 Key ID 1; positive TestSignKeyNoRevertWhenAllExpired (store level). Negative TestRFC5709LastKeyExpiredRefusesUnauthenticated: AuType 0 Hello refused by verify with autype-mismatch after expiry. All three revert records (selectSendKey, verify) re-recorded by the judge after continuation 8 changed those producers, observed red.

RFC5709-3.2-5

Therefore, the router should send a "last Authentication Key expiration" notification to the network manager and treat the key as having an infinite lifetime until the lifetime is extended, the key is deleted by network management, or a new key is configured. (§3.2)

Audit verdict: enforced (the tests do what the requirement demands), fresh. New row 2026-09-30 (R35, D-8 fixed). auth_keystore.go: lastKeyIndex (latest sendStart, tie -> later accept end) is shared by signer and verifier; selectSendKey signs with it when no key is active; lastKeyExtendedIndex extends its accept window only when every window of the chain has closed and the last key's accept end passed (a not-yet-open chain is not expiry); noticeLocked notifies once per interface until configure installs a new chain; notification = slog Warn + ospf/last-key-expiration event. Positive TestRFC5709LastKeyExpiredKeepsAdjacency: two engines with the same expired one-key chain, two Hellos signed by one verify on the other, exactly one event each (eth0, key 1, send / receive). Negative TestRFC5709ExpiredKeyRefusedOnceNotLast: after a live Key ID 2 is configured the expired Key ID 1 is refused accept-lifetime, the signer moves to Key ID 2, no event. Revert records on lastKeyExtendedIndex observed red for both polarities. 'Lifetime extended' and 'key deleted' are the same configure path as 'new key configured' and are not separately asserted.

Extraction sign-off

Sections

Excluded sentences

Superseded

No document obsoletes RFC 5709, so its obligations are stated where they were written.