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

Hi,

We have updated the draft to include HMAC-SHA-384 and HMAC-SHA-512 authentication modes. There were some other minor comments as well that we had received. Those have been addressed in this version.

http://www.ietf.org/internet-drafts/draft-bhatia-manral-isis-hmac-sha-01.txt

Would appreciate a feedback from the WG.

Cheers,
Manav

----- Original Message ----
From: Vishwas Manral <vishwas@ipinfusion.com>
To: isis-wg@ietf.org
Sent: Saturday, 22 April, 2006 6:55:51 AM
Subject: RE: [Isis-wg] IS-IS HMAC SHA Cryptographic Authentication

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.

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg

_______________________________________________
Isis-wg mailing list
Isis-wg@ietf.org
https://www1.ietf.org/mailman/listinfo/isis-wg