OSPFv2 HMAC-SHA Cryptographic Authentication
updated by
- rfc-7474 — Security Extension for OSPFv2 When Using Manual Key Management
updates
- rfc-2328 — OSPF Version 2
Extracted elements (24)
HMAC-SHA algorithms were added because operators requested the NIST SHS family instead of Keyed-MD5. While published MD5 weaknesses do not directly attack Keyed-MD5, some organizations (e.g., the US government) prefer NIST algorithms for policy reasons.
This specification retains the basic RFC 2328 mechanism rather than migrating to IPsec, due to backwards compatibility requirements and operator preference. If all routers supported IPsec, tunnels could replace this mechanism but would relegate topology to point-to-point adjacencies over the IPsec mesh.
The Apad value was chosen for consistency with IETF specifications for HMAC-SHA authentication of RIPv2 SHA (RFC 4822) and IS-IS SHA (RFC 5310), and to minimize OSPF protocol processing changes relative to RFC 2328 Section D.4.3.
This document updates but does not supersede RFC 2328's Cryptographic Authentication mechanism (Authentication Type 2). The overall authentication process in RFC 2328 Appendix D remains unchanged; only the cryptographic details (SHA instead of MD5, HMAC instead of Keyed-Hash) are updated.
When verifying a received message, one must save the received digest value before computing the expected digest, then compare the two. The cryptographic algorithm in use is indicated implicitly by the KeyID of the received OSPFv2 packet.
An implementation MUST allow network operators to configure ANY authentication algorithm supported by that implementation for use with ANY given KeyID value configured into that OSPFv2 router.
For smooth key transition, KeyStartAccept SHOULD be less than KeyStartGenerate and KeyStopGenerate SHOULD be less than KeyStopAccept. 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.
Implementations MAY include support for HMAC-SHA-384 and HMAC-SHA-512.
Implementations MUST include support for HMAC-SHA-256 as the mandatory-to-implement algorithm for OSPFv2 Cryptographic Authentication.
Implementations SHOULD include support for HMAC-SHA-1 and SHOULD also include support for Keyed-MD5 for backwards compatibility with existing implementations and deployments.
Key storage SHOULD persist across a system restart (warm or cold). If the last key on an interface expires, the router must not revert to unauthenticated operation but should notify the network manager and treat the key as having an infinite lifetime.
The Authentication Algorithm and Authentication Key fields of an OSPFv2 SA SHOULD never be sent over the wire in cleartext form.
Block size B for SHA-1 and SHA-256 is 64 octets; for SHA-384 and SHA-512, B is 128 octets. Ipad is 0x36 repeated B times; Opad is 0x5c repeated B times.
Ko (the cryptographic key used with the hash) is always L octets long: if K equals L octets, Ko = K; if K is longer than L, Ko = H(K); if K is shorter than L, Ko = K zero-padded to L octets.
The Apad constant is defined as the hexadecimal value 0x878FE1F3 repeated (L/4) times, where L is the hash output length in octets, making Apad always the same length as the hash output. It is placed in the Authentication Trailer before computing the HMAC.
The OSPFv2 Security Association (SA) is defined by: Key Identifier (KeyID, 8-bit unsigned), Authentication Algorithm (e.g., HMAC-SHA-256), Authentication Key, Key Start Accept, Key Start Generate, Key Stop Generate, and Key Stop Accept timestamps.
The OSPF Authentication Codes registry entry for Cryptographic Authentication (Registry Code 2) has been updated to refer to both this document and RFC 2328.
Because all specified algorithms use symmetric cryptography, one cannot authenticate precisely which OSPF router sent a given packet; one can only authenticate that the sender knew the OSPFv2 SA currently in use.
No automated key management has been standardized for OSPF as of publication. Common practice of using the same key for very long periods is undesirable; deploying automated key management is strongly recommended to prevent sequence number reuse and replay attacks.
The KeyID field mitigates some DoS risk by allowing the receiver to select the correct SA directly rather than trying all configured SAs. However, an on-link adversary can still force expensive cryptographic operations by sending syntactically valid packets with invalid Authentication Data.
The mechanism is vulnerable to replay attacks by any on-link node. An attacker could record a legitimate OSPF packet and replay it when the sequence number is again valid, causing significant routing disruptions within the OSPF domain.
HMAC computation: First-Hash = H(Ko XOR Ipad || OSPFv2 Packet with Apad-filled Authentication Trailer); Second-Hash = H(Ko XOR Opad || First-Hash). The Second-Hash is the Authentication Data sent in the Authentication Trailer.
The Authentication Data Length field is set to the length in bytes of the cryptographic hash output. For HMAC-SHA-1 it is 20 bytes, SHA-256 is 32 bytes, SHA-384 is 48 bytes, and SHA-512 is 64 bytes. The Authentication Trailer is appended to the OSPF packet and is not counted in the OSPF packet's own Length field but is included in the IP Length field.
The KeyID field is an 8-bit unsigned integer placed in the OSPF packet header that identifies which OSPFv2 SA to use, allowing the receiver to select the correct SA without trying all configured ones.