RIPv2 Cryptographic Authentication
Extracted elements (28)
Backwards compatibility with RFC 2082 Keyed-MD5 implementations was required, precluding significant protocol changes. The algorithm-independent design of the original specification allowed SHA algorithms to be added without breaking existing deployments.
Integrated key management was deliberately omitted from this specification to avoid having to change all RIPv2 implementations if a flaw in a key management protocol is discovered later; the Key-ID field serves as a hook for a future standardized key management protocol.
The HMAC construction was chosen over the Keyed-MD5 hashing construction because HMAC is widely believed to be stronger. The IESG approved this document despite not meeting BCP 107 automated key management guidelines to encourage rapid migration away from Keyed-MD5.
At least one widely-used implementation of the prior specification (RFC 2082) violates the requirement to use Key-ID and interface to select a Security Association (instead trying all keys), creating a denial-of-service vulnerability; conforming implementations MUST NOT do this.
A router that has forgotten its current sequence number but remembers its Security Association MUST send its first packet with a sequence number of zero; implementers SHOULD provide non-volatile storage for all Security Association components and last received sequence numbers.
An implementation MUST be able to support at least 2 concurrent RIPv2 Security Associations on each RIP interface to support key rollover, which is mandatory.
Any actual occurrence of a RIPv2 Security Association expiration MUST cause a security event to be logged including the expired key, affected RIP instance(s), affected interfaces, Key-ID, and current date/time.
Any known weak key values for NIST Secure Hash Standard algorithms MUST NOT be used with those algorithms.
During key rollover, routers SHOULD implement an algorithm to detect which Security Associations neighbors are using and transmit using both old and new Security Associations until all neighbors have migrated or the old association expires.
If authentication data verification fails, the message MUST be discarded without being processed, and a security event SHOULD be logged including day/time, source IP, Key-ID, interface, and the authentication failure fact.
If the neighbor has been heard from recently and the received sequence number is less than the last received sequence number, the message MUST be discarded unprocessed and the out-of-order sequence number SHOULD be logged as a security event.
Implementations MUST support the storage of more than one key simultaneously, MUST associate a Security Association lifetime and key identifier with each key, and MUST support manual key distribution.
Keyed-MD5 and HMAC-SHA-1 MUST be implemented by all conforming implementations; HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 SHOULD be implemented.
Receivers SHOULD keep track of the most recent sequence number received from a given sender to detect replay attacks.
The Authentication Key MUST NOT ever be sent over the network in cleartext via any protocol.
The receiver MUST NOT try all configured RIPv2 Security Associations (keys) on the receiving interface, as this creates an easily exploited denial-of-service attack; the Key Identifier and receiving interface MUST be used to select the specific Security Association.
The Sequence Number MUST be non-decreasing for all messages sent from a given source router with a given Key ID value.
When the last RIPv2 Security Association of an interface expires, the router MUST send a notification to the network manager and SHOULD treat that last Security Association as having an infinite lifetime until replaced or deleted.
The HMAC key preparation step: if the Authentication Key equals L octets it is used as-is as Ko; if longer, Ko = H(Authentication Key); if shorter, Ko is zero-padded to L octets. Ko is always L octets long.
The RIPv2 Security Association is the central configuration construct containing: KEY-IDENTIFIER (8-bit), AUTHENTICATION ALGORITHM (KEYED-MD5, HMAC-SHA-1, HMAC-SHA-256, HMAC-SHA-384, or HMAC-SHA-512), AUTHENTICATION KEY, SEQUENCE NUMBER (32-bit), START TIME, and STOP TIME. A Security Association is always associated with an interface, not a router.
If a user interface only permits ASCII text entry for cryptographic keys, significant bits become predictable, reducing key strength. Implementations SHOULD support entry of cryptographic keys in hexadecimal format.
Receipt of a RIPv2 packet with an unknown, expired, or invalid KEY-ID SHOULD cause a security event to be logged including the invalid KEY-ID, source IP, interface, and date/time, as it may indicate an active attack.
The mechanism protects against passive attacks but provides incomplete protection against active attacks. The main active-attack vulnerability is the reboot scenario where a router loses its sequence number and must restart from zero, creating a brief replay window.
The mechanism provides no confidentiality for RIPv2 messages, which remain in the clear. Bulk link encryption SHOULD be used when protection against traffic analysis is required.
Use of SNMP (including SNMPv3) or non-key-management protocols (e.g., RADIUS, Diameter) to modify or configure RIPv2 Security Associations is NOT RECOMMENDED, as a compromise of those protocols would cascade into compromise of all RIPv2 routing.
For HMAC-SHA authentication, the Authentication Data field is first filled with Apad (0x878FE1F3 repeated L/4 times), then First-Hash = H(Ko XOR Ipad || RIPv2 Packet) and Second-Hash = H(Ko XOR Opad || First-Hash). The output is NOT truncated; Authentication Data Length equals the full hash output size (e.g., 20 bytes for HMAC-SHA-1).
For Keyed-MD5, the 16-octet Authentication Key is appended to the RIPv2 packet in memory, followed by MD5 trailing pad octets and a 64-bit message length, then MD5 is computed per RFC 1321. The Authentication Data Length field is always 16 octets.
The RIPv2 cryptographic authentication header reuses the 16-octet authentication password field to carry: a 16-bit RIPv2 Packet Length offset, an 8-bit Key ID, an 8-bit Authentication Data Length, a 32-bit non-decreasing Sequence Number, and two reserved zero words. Authentication Type is set to 0x0003. The authentication trailer follows the main packet body.