Supporting Authentication Trailer for OSPFv3
obsoletes
- rfc-6506 — Supporting Authentication Trailer for OSPFv3
Extracted elements (25)
OSPFv3 originally relied solely on IPsec (AH/ESP) for authentication, but IPsec is difficult to configure and maintain in some environments such as MANETs, and does not provide replay protection when using manually configured keys. This document defines an Authentication Trailer mechanism as an alternative that solves replay protection and packet prioritization issues.
The IPv6 source address is included in the HMAC message digest computation to protect against Man-in-the-Middle attacks that modify the source address. OSPFv3 uses Router ID for neighbor identification but learns the IPv6 source address from Hello packets, making it vulnerable without this protection.
RFC 6506 erratum: the key preparation step incorrectly used the Authentication Key (K) rather than the Protocol-Specific Authentication Key (Ks) as the initial key (Ko). Section 4.5 has been corrected to use Ks.
RFC 6506 erratum: the LLS data block checksum calculation should be omitted when an OSPFv3 Authentication Trailer is used (since LLS is included in the auth digest, recomputing a checksum is unnecessary). This is now explicitly stated in Sections 2.2 and 4.2.
A mismatch in SA ID, Authentication Type, or message digest results in failure to form an OSPFv3 adjacency. For multi-access links, communities can be migrated using different Interface Instance IDs, but this results in sub-optimal routing and added complexity.
A transition mode is defined where a router includes the Authentication Trailer in transmitted packets (and sets AT-bit) but does not verify it in received packets. In transition mode, the OSPFv3 header checksum and LLS data block checksum are also calculated and set so that non-authenticating routers do not drop packets.
During message verification, if the SA is not found or not valid for reception (current time < KeyStartAccept or current time >= KeyStopAccept), the OSPFv3 packet MUST be dropped. After successful authentication, implementations MUST store the 64-bit cryptographic sequence number for each OSPFv3 packet type received from the neighbor.
If the cryptographic sequence number in the AT is less than or equal to the last sequence number for the same OSPFv3 packet type from the neighbor, the packet MUST be dropped and an error event SHOULD be logged.
Implementations of this specification MUST include support for at least HMAC-SHA-256, SHOULD include support for HMAC-SHA-1, and MAY include HMAC-SHA-384 and HMAC-SHA-512. HMAC-SHA-256 MUST be used as the default authentication algorithm.
In the event that the last key associated with an interface expires, the OSPFv3 packet MUST NOT be transmitted unauthenticated, and the network operator SHOULD be notified.
OSPFv3 routers implementing this specification MUST use available mechanisms to preserve the sequence number's strictly increasing property for the deployed life of the router including cold restarts, such as using the high-order 32 bits as a wrap/boot count stored in non-volatile storage.
OSPFv3 routers MUST set the AT-bit in all OSPFv3 Hello and Database Description packets that contain an Authentication Trailer.
The 64-bit Cryptographic Sequence Number MUST be incremented for every OSPFv3 packet sent, and upon reception the sequence number MUST be greater than the sequence number in the last accepted packet of the same type from the sending neighbor; otherwise the packet is considered replayed and dropped.
When a new key replaces an old key, the KeyStartGenerate time for the new key MUST be less than or equal to the KeyStopGenerate time of the old key to ensure smooth key transition.
When the OSPFv3 Authentication Trailer is used, both checksum calculation and verification are omitted for the OSPFv3 header checksum and the LLS data block checksum. The OSPFv3 header checksum SHOULD be set to 0 prior to computing the Authentication Trailer message digest.
Cross-protocol replay attack mitigation requires appending the two-octet OSPFv3 Cryptographic Protocol ID (value 1 for OSPFv3) to the Authentication Key K before use, yielding the Protocol-Specific Authentication Key Ks. This prevents keys shared between protocols from being used in replay attacks across protocols.
Sequence number wrap handling: the sequence number is treated as unsigned 64-bit; if the lower-order 32 bits wrap, the higher-order 32 bits are incremented and saved in non-volatile storage. If a full 64-bit wrap is possible, all keys MUST be reset to prevent replay attacks.
The AT-bit is defined in the OSPFv3 Options field (bit position 0x000400) to indicate the presence of an Authentication Trailer. OSPFv3 routers MUST set the AT-bit in Hello and Database Description packets to signal that all packets on the link will include an Authentication Trailer.
The HMAC computation uses a two-pass construction: Ko (derived from Ks, always L octets long) is XORed with Ipad for the inner hash over the full OSPFv3 packet (with Auth Data field set to Apad), then XORed with Opad for the outer hash. Apad consists of the 16-octet IPv6 source address followed by 0x878FE1F3 repeated (L-16)/4 times.
The OSPFv3 Security Association (SA) contains parameters shared between OSPFv3 speakers: a 16-bit SA ID, authentication algorithm (HMAC-SHA-1/256/384/512), Authentication Key, and four time parameters (KeyStartAccept, KeyStartGenerate, KeyStopGenerate, KeyStopAccept) controlling key lifetime.
The 'Cryptographic Protocol ID' registry (under 'KARP Parameters') assigns unique protocol-specific values for cryptographic cross-protocol replay prevention: 0 = Reserved, 1 = OSPFv3, 2-65535 = Unassigned. Registration procedure is Standards Action.
The 'OSPFv3 Authentication Types' registry (under 'OSPFv3 Authentication Trailer Options') defines valid Authentication Type field values: 0 = Reserved, 1 = HMAC Cryptographic Authentication, 2-65535 = Unassigned. Registration procedure is Standards Action.
Deployments supporting a transitionary state that interoperate with routers without this authentication method may be exposed to unauthenticated data during the transition period.
The authentication mechanism provides integrity and sender verification but not confidentiality. It does not authenticate the specific originator but confirms the packet was issued by a router with access to the Authentication Key. Deployments SHOULD use sufficiently long and random Authentication Keys; at least 128 pseudorandom bits are RECOMMENDED to resist guessing and cryptographic attacks.
The Authentication Trailer has a 16-octet fixed header: 2-octet Authentication Type, 2-octet Auth Data Len (total AT length including header and digest), 2-octet Reserved, 2-octet SA ID, and a 64-bit Cryptographic Sequence Number (split into two 32-bit fields), followed by variable-length Authentication Data.