Subject: [Isis-wg] IS-IS HMAC SHA Cryptographic Authentication

From: Manav Bhatia <[email-masked]>
Date: Wed, 19 Apr 2006 03:00:00 +0000 (GMT)

Hi,
 
We have written a draft on extending ISIS to use HMAC-SHA authentication. Would appreciate if we can get some feedback from the WG. The mechanism proposed in the draft is backward compatible and would work with the existing ISIS implementations.
 
Cheers,
Manav
 
----- Forwarded Message ----
From: [email-masked]
To: [email-masked]
Sent: Wednesday, April 19, 2006 4:20:01 AM
Subject: I-D ACTION:draft-bhatia-manral-isis-hmac-sha-00.txt
 
A New Internet-Draft is available from the on-line Internet-Drafts directories.
 
    Title        : IS-IS HMAC SHA Cryptographic Authentication
    Author(s)    : M. Bhatia, V. Manral
    Filename    : draft-bhatia-manral-isis-hmac-sha-00.txt
    Pages        : 8
    Date        : 2006-4-18
 
This document proposes an extension to IS-IS [ISO] [RFC1195] to allow the use of HMAC SHA authentication algorithm in addition to the already documented authentication schemes described in the base specification and RFC 3567.
 
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-bhatia-manral-isis-hmac-sha-00.txt
 
To remove yourself from the I-D Announcement list, send a message to [email-masked] with the word unsubscribe in the body of the message.

You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings.
 
[clipped] 

_______________________________________________
Isis-wg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/isis-wg

---

From: Vishwas Manral <[email-masked]>
Date: Fri, 21 Apr 2006 18:25:51 -0700

Hi Hannes,

I mostly agree with Tony here, except for a very corner case where we can amplify 
a DoS because we have multiple keys to choose between at the receiver during Key
Rollover.

The point that you bring is an intersting point about KeyRollover. A simple 
way to do it is to also have the Key-Id (opaque value) sent by the sender. The 
sender when doing a key rollover will use a different Key ID(which is shared with
the receiver). As the receiver will have the key with the same Key-ID it can use 
that key for calculating the Hash. We will not have to compute the hash with 
multiple keys which are valid in such a case.

The Key lifetime by itself is a very implementation thing(with no effect for 
interoperability).

On another note, as we may now have multiple authentication algorithms to support 
for any protocol, should we also have an RFC like 4305 for IPsec? That way we do 
not need to change an RFC which tells about how to use an algorithm(HMAC-SHA1) with
IS-IS, but still change the status of algorithm support (e.g. MUST to MAY etc).

I am currently the author of the bis version for the RFC and the discussion regarding 
the same can be seen in the archives.
http://www1.ietf.org/mail-archive/web/ipsec/current/index.html

Thanks,
Vishwas

===================================================================
Tony Li wrote:

Hannes,

> There is a time window (until all routers have the new
> authentication key) where the routers holding the new key are
> using that key and other routers have not yet got the new key
> and hence nothing to verify against.
> 
>    so what you require is some form of coordination i.e.
>    to have all nodes hold off using the new transmit key
>    up until the network is fully transitioned
>    (i have seen implementations who achieve that with
>    time/date based transmit key-selection) -> this requires
>    some form of coordination (timestamp / key lifetime etc.)

Nothing more sophisticated than uniform configuration is required.  The
first configuration pass installs the new key and enables it for
reception.  The second configuration pass switches to using the new key
for transmission.  Those who want to be pedantic can include a third
pass to remove the old key.

Given the widespread deployment of homegrown tools for consistent,
distributed router configuration, I don't see this as a significant
hurdle.