Supporting Authentication Trailer for OSPFv3
obsoleted by
- rfc-7166 — Supporting Authentication Trailer for OSPFv3
Extracted elements (26)
OSPFv3 relied solely on IPsec (AH/ESP) for authentication, but IPsec is difficult to configure and maintain in environments such as MANETs, and provides no replay protection when using manual keys. This specification introduces an Authentication Trailer mechanism analogous to OSPFv2's cryptographic authentication to address those gaps.
The IPv6 source address is explicitly included in the HMAC digest computation (via Apad) even though OSPFv3 uses Router ID for neighbor identification, because the source address is copied into neighbor data structures from Hello packets and could be forged in a Man-in-the-Middle attack.
All OSPFv3 routers on a link SHOULD be migrated to OSPFv3 Authentication simultaneously, since a mismatch in SA ID, Authentication Type, or message digest prevents adjacency formation. A transition mode is defined where a router MAY include the Authentication Trailer in transmitted packets without verifying it in received packets to ease incremental deployment.
After successful authentication of an OSPFv3 packet, implementations MUST store the 64-bit cryptographic sequence number for future replay checks.
If the Authentication Trailer is configured for an OSPFv3 link, OSPFv3 Hello and Database Description packets with the AT-bit clear in the Options field MUST be dropped. All OSPFv3 packet types MUST be dropped if the AT is configured and the IPv6 header length is insufficient to include an Authentication Trailer.
If the cryptographic sequence number in the received Authentication Trailer is less than or equal to the last sequence number successfully received from the neighbor, the OSPFv3 packet MUST be dropped and an error event SHOULD be logged.
Implementations MUST include support for at least HMAC-SHA-256, SHOULD include support for HMAC-SHA-1, and MAY include support for HMAC-SHA-384 and HMAC-SHA-512. HMAC-SHA-256 MUST be the default authentication algorithm.
Key storage SHOULD persist across system restarts (warm or cold). If the last key on an interface expires, the router SHOULD send a 'last Authentication Key expiration' notification and treat the key as having infinite lifetime rather than reverting to an unauthenticated state.
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 across cold restarts. One recommended mechanism is to use the high-order 32 bits as a wrap/boot count stored in non-volatile storage.
OSPFv3 routers MUST set the AT-bit in OSPFv3 Hello and Database Description packets to indicate that all packets on the link will include an Authentication Trailer.
OSPFv3 routers supporting this specification MUST minimally support examining the L-bit in OSPFv3 Options and using the LLS data block length to locate the Authentication Trailer. It is RECOMMENDED that such routers fully support OSPFv3 Link-Local Signaling per RFC 5613.
The 64-bit Cryptographic Sequence Number MUST be incremented for every OSPFv3 packet sent. Upon reception, the sequence number MUST be greater than the sequence number in the last accepted packet from that neighbor; otherwise the packet MUST be treated as a replay and dropped.
To achieve smooth key transition, KeyStartAccept SHOULD be less than KeyStartGenerate, and KeyStopGenerate SHOULD be less than KeyStopAccept. The KeyStartGenerate time for a new key MUST be less than or equal to the KeyStopGenerate time of the old key.
When the OSPFv3 Authentication Trailer mechanism is used, OSPFv3 header checksum calculation MUST be omitted on transmission (checksum field SHOULD be set to 0) and verification MUST be omitted on reception, though a non-zero received checksum is included in the digest verification computation.
A new AT-bit (bit position 0x000400) is defined in the 24-bit OSPFv3 Options field to signal that Authentication Trailers are present on the link. Its presence in Hello and Database Description packets indicates all packets on the link will include an Authentication Trailer; for other packet types, the AT expectation is derived from the neighbor data structure.
An OSPFv3 Security Association (SA) is identified by a 16-bit SA ID and carries: Authentication Algorithm (HMAC-SHA-1/256/384/512), Authentication Key, KeyStartAccept, KeyStartGenerate, KeyStopGenerate, and KeyStopAccept. The algorithm is never sent in clear text on the wire.
Cross-protocol replay attack mitigation: the two-octet OSPFv3 Cryptographic Protocol ID (value 1 for OSPFv3) is appended to the Authentication Key K to form a Protocol-Specific Authentication Key Ks before HMAC computation. Other protocols using this mechanism MUST similarly append their respective Protocol IDs.
HMAC computation: Ko (key of length L) is derived from Ks; if Ks > L octets, Ko = H(Ks); if Ks < L, Ko is zero-padded. First-Hash = H(Ko XOR Ipad || OSPFv3 Packet including LLS and AT with Apad). Second-Hash = H(Ko XOR Opad || First-Hash). The Second-Hash is the Authentication Data placed in the trailer.
Sequence number wrap handling: when the low-order 32-bit value wraps, the high-order 32-bit value is incremented and saved to non-volatile storage. If there is any possibility the full 64-bit value may wrap, all keys MUST be reset to prevent replay attacks, after which the high-order bits may be reset to 0.
The Authentication Trailer length is not included in the OSPFv3 header Length field but IS included in the IPv6 payload length. The trailer length equals the total IPv6 payload length minus the OSPFv3 packet length minus any LLS block length.
IANA allocated the AT-bit (0x000400) in the 'OSPFv3 Options (24 bits)' registry. IANA created the 'OSPFv3 Authentication Trailer Options' registry containing the 'OSPFv3 Authentication Types' sub-registry: value 0 is Reserved, value 1 is HMAC Cryptographic Authentication, values 2-65535 are Unassigned. Registration procedure: Standards Action.
IANA created the 'Keying and Authentication for Routing Protocols (KARP) Parameters' category containing the 'Authentication Cryptographic Protocol ID' registry: value 0 is Reserved, value 1 is OSPFv3, values 2-65535 are Unassigned. This registry enables cross-protocol replay attack prevention by providing unique per-protocol identifiers appended to authentication keys.
The authentication mechanism confirms a packet was issued by a router with access to the Authentication Key, but does not authenticate the specific originator. Deployments SHOULD use sufficiently long and random keys; Authentication Keys SHOULD incorporate at least 128 pseudo-random bits. Management systems SHOULD support hexadecimal key input.
The specification provides integrity and authentication but not confidentiality, as routing protocol information does not need to be kept secret. It addresses all security issues identified in RFC 6039 and represents a significant increase in adversary effort compared to unauthenticated or IPsec-manual-key operation.
The Authentication Trailer appended after the OSPFv3 packet (and optional LLS block) contains: Authentication Type (16-bit), Auth Data Len (16-bit, total trailer length including 16-octet fixed header plus digest), Reserved (16-bit, SHOULD be 0), Security Association ID (16-bit), Cryptographic Sequence Number (64-bit strictly increasing), and Authentication Data (variable, carrying the HMAC digest).
The HMAC computation uses Apad as a placeholder in the Authentication Data field during computation: Apad consists of the 16-octet IPv6 source address followed by the value 0x878FE1F3 repeated (L-16)/4 times, where L is the hash output length. The final HMAC output replaces Apad in the transmitted packet.