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 HMACSHA 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 RFC 5310 for more details ..


About Manav Bhatia

Manav Bhatia is a SDN/NFV dataplane architect at Ionos Networks and has co-authored several IETF standards on routing protocols, BFD, IPv6, security, etc. He is also a member of IETF Routing Area Directorate where he helps the Area Directors review the IETF standards for their impact on the Routing Area. View all posts by Manav Bhatia

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: