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

From: "Sofia Ray" <[email-masked]>
Date: Wed, 19 Apr 2006 13:04:28 -0500

Manav,

Whats wrong with the authentication scheme detailed in 3567?

Yours,
Sofia

----- Original Message ----
From: Manav Bhatia <[email-masked]>
To: [email-masked]
Sent: Wednesday, 19 April, 2006 8:30:00 AM
Subject: [Isis-wg] IS-IS HMAC SHA Cryptographic Authentication

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

-- 
_______________________________________________

Search for businesses by name, location, or phone number.  -Lycos Yellow Pages

http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.asp?SRC=lycos10

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

---

From: "Tony Li" <[email-masked]>
Date: Wed, 19 Apr 2006 11:17:34 -0700

Sofia,

While I know of no substantive risks to the use of MD5 today as used in
3567, history suggests that someday, there will be.  Thus, having other
algorithms available is only prudent and I strongly support that goal.

Regards,
Tony

> -----Original Message-----
> From: Sofia Ray [mailto:[email-masked]] 
> Sent: Wednesday, April 19, 2006 11:04 AM
> To: [email-masked]
> Subject: Re: [Isis-wg] IS-IS HMAC SHA Cryptographic Authentication
> 
> Manav,
> 
> 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
> 
> 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.
>

---

From: "Tony Li" <[email-masked]>
Date: Wed, 19 Apr 2006 13:15:54 -0700

Hannes,

I'm of the opinion that key rollover and algorithm rollover do not
require actual additional protocol specification and that transmitting
multiple TLVs is not necessary.  For any form of rollover to work, a
receiver must be prepared to accept multiple different combinations of
password and algorithm.  It does not seem like a substantial effort for
the receiver to try all of the possibilities that it is configured for.

Given this, one way to do smooth rollover is to go around and configure
all nodes with the new password and/or algorithm.  Once that's completed
and in production, then nodes can be set to transmit the new password
and/or algorithm.

While 802.11's WEP is hardly a good example of this for security
purposes, most implementations provide a fine example of how the UI for
this would work: one key is used for transmit, while a list of keys is
accepted.

Regards,
Tony

P.s. Yes, I'm well aware that implementations do not currently support
this behavior and will have to change.  Including Juniper's.  Sorry.
;-) 

> From: Hannes Gredler [mailto:[email-masked]] 
> Sent: Wednesday, April 19, 2006 1:02 PM
> To: [email-masked]
> Cc: 'Sofia Ray'; [email-masked]
> furthermore, it would be also time to think about authentication-type
> migration support. i.e. discuss about authentication-type 
> [simple->md5->sha]
> and key rollover schemes and nail down the necessary behaviour
> (multiple instances of TLV #10).
> 
> the prevailing method for both authentication-type and key rollover
> (= disabling authentication check during the transition window)
> is not really smooth.
> 
> /hannes
> 
> Tony Li wrote:
> > Sofia,
> >

---

From: Hannes Gredler <[email-masked]>
Date: Wed, 19 Apr 2006 22:01:51 +0200

furthermore, it would be also time to think about authentication-type
migration support. i.e. discuss about authentication-type [simple->md5->sha]
and key rollover schemes and nail down the necessary behaviour
(multiple instances of TLV #10).

/hannes

---

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

I would agree with Tony and i dont think advertising multiple instances of TLV 10 is required. OTOH, i see a potential problem with including multiple TLVs as that can lead to a simple Dos attack wherein the sender puts multiple TLVs and the receiving router gets overwhelmed processing each one of those. The idea of including multiple TLVs was discussed when we were writing this draft and it was rejected because of the reason stated above.
 
If you notice we send the Key ID in the TLV 10.  Doing this can help us during Key rollover wherein we can have multiple keys configured and the receiver only needs to verify the packet with the key associated with the given Key ID. Not doing this can be CPU intensive for the receiving router during the Key rollover when multiple keys are configured and random packets are sent in.
 
Cheers,
Manav

----- Original Message ----
From: Tony Li <[email-masked]>
To: Hannes Gredler <[email-masked]>; [email-masked]
Cc: [email-masked]
Sent: Thursday, 20 April, 2006 1:45:54 AM
Subject: RE: [Isis-wg] IS-IS HMAC SHA Cryptographic Authentication

Hannes,

Regards,
Tony

---

From: mike shand <[email-masked]>
Date: Thu, 20 Apr 2006 07:49:35 +0100

>the receiver to try all of the possibilities that it is configured for.

Absolutely. That was the way it was designed to work in the original 
form with non-cryptographic passwords (multiple receive passwords 
could be specified to allow migration), and I don't see why the same 
principle shouldn't apply to algorithm migration.

         Mike

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 20 Apr 2006 09:10:36 +0200

tony,

your suggested form of key rollover (all receivers can
authenticate against the new transmit-key) is certainly
a working model, however it is not the most convenient model
from a network operator perspective.

lets assume we start to configure the network with new
authentication keys.

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.)

back to the original idea - multiple instances of TLV #10 don't require
time-based transmit key selection, since the PDU contains
everybody's key of taste, which would IMO be more migration friendly.

BTW the "protocol extension" that i have in mind to make this work
is rather straightforward: clear all instances of TLV #10 to zero
before computing the digest of a single TLV #10 and doing of course
the same on reception.

/hannes

Tony Li wrote:
>>>While I know of no substantive risks to the use of MD5 
>>
>>today as used in
>>
>>>3567, history suggests that someday, there will be.  Thus, 
>>
>>having other
>>
>>>algorithms available is only prudent and I strongly support 
>>
>>that goal.
>>
>>>Regards,
>>>Tony
>>>
>>>
>>>

---

From: "Tony Li" <[email-masked]>
Date: Thu, 20 Apr 2006 10:09:22 -0700

Hannes,

>    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.

Tony