IS-IS Generic Cryptographic Authentication

We recently updated our IS-IS WG document “IS-IS Generic Cryptographic Authentication” based on discussions that we had on the IETF IS-IS WG mailing list and various other cryptographers and technologists offline

Currently the IS-IS specification allows only clear-text passwords and the HMAC-MD5 style of authentication. This is done via the authentication TLV 10. Our draft proposes a new authentication type to be carried within TLV 10, which we call the generic cryptographic authentication. It is generic because it can be used with any authentication algorithm for authenticating and verifying IS-IS PDUs.

This draft in particular explains how the HMAC-SHA authentication should be used within IS-IS. Since its a generic authentication scheme we needed a way to demultiplex the various authentication algorithms that could have been applied to the PDUs. Doing this by looking at the length of TLV 10 is incorrect and impossible since we can have multiple authentication algorithms returning the same hash length (E.g. Truncated Hashes!).

To solve this we have introduced the concept of a Key ID in IS-IS. Its basically an octet long unsigned number that would uniquely define an IS-IS security association, as manually configured by the network operator. The reciever would determine the active SA by looking at the Key ID carried in the incoming IS-IS PDU.

A Key ID is associated with an authentication algorithm (or the protocol) and a secret key (the password) at the very least. Most implementations (at least the ones that i am aware of!) would also associate a fixed lifetime with a key. A key can thus time out after some time, and the next one can take over. This ensures that the same key is not used in the network for a long time, thereby making it harder for the bad guy to guess the password.

Using Key IDs makes changing keys while maintaining protocol operation extremely convenient. One only needs to compute the authentication data with the parameters specified in the new key, and to change the value of the Key ID sent in the IS-IS PDU. The actual operation of these mechanisms is outside the scope of this post.

Read the draft for more details ..

OSPF HMAC-SHA Cryptographic Authentication

The “OSPF HMAC-SHA Cryptographic Authentication” draft co-authored by me has been accepted as a WG document.

This IETF draft describes a mechanism for authenticating OSPF packets by making use of the HMAC algorithm in conjunction with the SHA family of cryptographic hash functions. Because of the way the hash functions are used in HMAC construction, the collision attacks currently known against SHA-1 do not apply. 
    
So why do we need this extension?

In the cryptographic authentication scheme described in RFC 2328, the OSPF routers on a common network/subnet share a secret key which is used to generate a keyed MD5 digest for each packet while a monotonically increasing sequence number scheme is used to prevent replay attacks. 
    
This isnt good enough as there have been recent reports about attacks on MD5 which raises concerns about the remaining useful lifetime of this scheme. Specifically, the researchers have been able to develop algorithms that can compute hash collisions for some applications of MD5. MD5CRK, was a distributed computing project to break the MD5 hash algorithm in a short period of time. The project closed down with the publication of the paper.
    
It was discovered that collisions can be found in MD5 algorithm in less than 24 hours, making MD5 insecure. Further research has verified this result and shown other ways to find collisions in MD5 hashes.  It should however be noted that these attacks may not necessarily result in direct vulnerabilities in Keyed-MD5 as used in OSPF authentication purposes, because the colliding message may not  necessarily be a syntactically correct protocol packet. However, there is a need felt to move away from MD5 towards more complex and difficult to break hash algorithms. 
    
This document therefore adds support for HMAC  construction to be used for authenticating OSPF packets. HMAC can be used, without modifying any hash function, for calculating and verifying the message authentication values. It verifies both the data integrity and the authenticity of a message. Because of the way the hash functions are used in HMAC construction, the collision attacks    currently known against MD5 and SHA-1 do not apply. 
    
By definition, HMAC requires a cryptographic hash function. We propose to use any one of SHA-1, SHA-224, SHA-256, SHA-384 and SHA-512 [NIST] for this purpose to authenticate the OSPF packets. 
    
This document explains how HMAC-SHA-1, HMAC-SHA-224, HMAC-SHA-256, HMAC-SHA-384 and HMAC-SHA-512 shall work with OSPF.