IS-IS Generic Cryptographic Authentication
updated by
Extracted elements (22)
Full digital signatures (per RFC 2154) were considered for stronger authentication but rejected because the computational burden was deemed too high relative to the threat environment in operational commercial networks at the time of writing.
HMAC-MD5 (RFC 5304) was extended rather than replaced because, while no open attacks exist at writing time, concerns about MD5's long-term strength motivated a generic cryptographic authentication framework capable of supporting any future hash algorithm.
Per-interface keys were eliminated in favor of Key IDs that map to IS-IS Security Associations. This allows different authentication algorithms to be associated with different Key IDs, enabling smooth key rollover and introduction of new authentication mechanisms without disrupting IS-IS peering.
The Remaining Lifetime field is explicitly excluded from LSP authentication (zeroed before computation) so that intermediate ISes can age LSPs without needing to recompute or re-sign the authentication data, which would otherwise be impractical.
A transition mode is defined where an implementation includes CRYPTO_AUTH information in PDUs but does not verify it, to aid migration from older authentication schemes to CRYPTO_AUTH-based authentication. Operators must ensure this mode is only used during migration as it leaves routers vulnerable.
An implementation MUST fill the authentication type and the length fields before the authentication data is computed.
If IS-IS is unable to find an active key for an outgoing PDU, the PDU MUST be discarded.
Implementations that support the optional checksum for Sequence Number PDUs and IS-IS HELLO PDUs MUST NOT include the Checksum TLV when computing CRYPTO_AUTH authentication.
Level 1 Sequence Number PDUs SHALL use the Area Authentication string (as in Level 1 LSPs); Level 2 Sequence Number PDUs shall use the domain authentication string (as in Level 2 LSPs); IS-IS HELLO PDUs SHALL use the Link Level Authentication string.
On the receiving side, if the computed authentication data does not match the received data, the PDU is discarded and an error event SHOULD be logged.
The authentication data for IS-IS IIH PDUs MUST be computed after the IIH has been padded to the MTU size, if padding is not explicitly disabled.
The Checksum and Remaining Lifetime fields MUST be set to zero for LSPs before authentication is calculated (sender side) and before verification is performed (receiver side).
To ensure greater security, implementations MUST be able to store and use more than one key at the same time, enabling key rollover without disrupting protocol operation.
A new authentication type code 3 (CRYPTO_AUTH) is defined for use in the existing IS-IS Authentication TLV 10. The TLV carries: Auth Type (1 octet, value 3), Key ID (2 octets), and variable-length Authentication Data.
An IS-IS Security Association (SA) is defined by three parameters: a 2-octet Key ID (uniquely identifying the SA), an Authentication Algorithm (one of HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384, HMAC-SHA-512), and an Authentication Key of variable length. The algorithm and key are never sent in cleartext on the wire.
The HMAC computation uses a two-hash (inner/outer) construction. The Authentication Data field is first filled with Apad (0x878FE1F3 repeated L/4 times), then First-Hash = H(Ko XOR Ipad || PDU) and Second-Hash = H(Ko XOR Opad || First-Hash), with the second hash placed in the Authentication Data field.
IANA registered value 3 (Cryptographic Authentication, CRYPTO_AUTH) in the 'IS-IS Authentication Type Codes for TLV 10' subregistry established by RFC 5304.
Authentication keys should be changed periodically, must never be sent in cleartext over the network, and must be unpredictable. The cryptographic strength of the HMAC depends on the underlying hash function and the size and quality of the key.
The mechanism authenticates that a PDU was issued by a system with access to the area or domain password, not by a specific originator. It does not provide confidentiality, as routing topology information does not require secrecy.
The mechanism does not protect IS-IS against replay attacks. An adversary could replay old IIHs to bring down adjacencies, or replay old CSNPs/PSNPs to trigger LSP flooding. Crypto sequence numbers are noted as a potential solution but are out of scope.
The Remaining Lifetime field of LSPs is excluded from authentication (set to zero before computation) to allow intermediate ISes to age LSPs without recomputing the authentication data. This omission can be exploited by an attacker to manipulate the remaining lifetime.
The CRYPTO_AUTH TLV (Type 10) contains: 1-octet Auth Type (0x03), 2-octet Key ID, and variable-length Authentication Data whose size equals the output length of the selected HMAC-SHA variant. TLV lengths are 23 (HMAC-SHA-1), 31 (HMAC-SHA-224), 35 (HMAC-SHA-256), 51 (HMAC-SHA-384), and 67 (HMAC-SHA-512) octets.