Subject: Re: [Isis-wg] draft-ietf-isis-hmac-03.txt

From: Alex Zinin <[email-masked]>
Date: Sun, 1 Jul 2001 01:12:18 -0700

David,

>> Thinking more about this... I guess we can go without CSNs in LSPs,
>> as the LSP's own SN should be enough in most cases (except for
>> the purge case, which is described in HMAC). So, we need only
>> two CSN groups---IIH & SNPs.

> Sounds good. Allows implementations to easily reorder
> types of messages if desired (e.g., high priority hellos)

> -------------------------------------------------------------------
> I had another question, but upon reading my email this morning,
> I see that it's already been addressed :-)
> (problem with restarting after being up for a while... 
> after restart you are using small seq num but BadGuy replays 
> one of your previous high seq num to your peer... so peer stops 
> listening to you until/unless your seq num increments up to the
> old value)

> I'm definitely NOT a security expert, but since there
> were some drawbacks mentioned for the proposed scheme
> (issues with NVRAM, and calendar clock),

With the reservation that each system will select it's own source
for generation ID, I think the nv memory approach is good.
If we assume that the genID is saved in the same place as the
device's config or other settings, the case of a failure
of this block should be extremely rare and would require
attention anyway (the router has no config, no IP addresses,
no ISIS started, no nothing, so no worries about authentication)...

> I'm wondering what would be the drawbacks of taking a page
> from the LSP seq num handling and just putting in a mechanism
> for an entity to bump up their seq num state if they discover a
> prior incarnation with higher state floating about. 

> They could discover that if the crypto data in a hello 
> included not only your crypto state (seqNum, or genId + seqNum)
> for the message in question, but also your current view of your 
> neighbor's state for each category (IIH, SNP). 

You see, when a router goes down, it is very likely that other
routers will destroy the adjacency and the associated neighbor
data structure by the time it is back. Hence, when the router
is back up, it won't see itself's state in the neighbors' Hellos,
and I wouldn't like to introduce changes in other parts of
implementations.

One could also think about maintaining a single CSN per segment
and pushing the transmit CSN up whenever a greater one is
received. This also has multiple drawbacks. One is decreased
key lifetime (since routers are "racing"). The key lifetime is
in inverse proportion to the number of routers on the segment.
Another is none of the two addresses the case of all routers
being restarted, so one would want to save the genID anyway.

> Actually, I just thought of one possible bad scenario, but
> it seems sort of far-out?... if a BadGuy had a large
> history of your prior messages (you had been up a long time), 
> then they could incrementally fool your neighbor... replay to 
> set seq num a bit higher than you, then you recover, then they
> replay a different one to set yet a bit higher, then you recover, etc.
> You could recover with a relatively large extra jump to reduce this,
> I suppose, but then you'll start using up the space faster.
> If the space is large enough (genID+seqNum) then this
> might not be an issue?

The above would be possible if the attacker recorded a session
and the genID of the router under attack rolled back to zero.
The way this problem is addressed now is by making sure the keys
are changed before the CSN is used up. I think this is a practically
acceptable assumption, since (as mentioned before) each 32-bit CSN
is enough for more than 10 years.

Alex.

_______________________________________________
Isis-wg mailing list  -  [email-masked]
http://external.juniper.net/mailman/listinfo/isis-wg

---

From: RJ Atkinson <[email-masked]>
Date: Sat, 30 Jun 2001 09:55:02 -0400

At 23:06 29/06/01, Alex Zinin wrote:
>(I belive Jerome Etienne has a paper on a similar
> mechanism for OSPF somewhere.)

        With all respect to the author, that proposal creates more 
security problems than it solves.  It changes how one engages in an
active attack, but does not increase the attacker's work function.
Further, the author of proposal seems to (erroneously) think the 
goal of OSPF MD5 is perfect security, which it never was.  The goal 
of OSPF MD5 and RIP MD5 was to make a plausible (not necessarily optimal)
engineering tradeoff between increased work function for the attacker
and implementation/deployment complexity -- and to eliminate purely
passive attacks as a significant threat.

>   1. SeqNum roll back does not seem to be a problem to me,
>      see item 4 below.
>
>   2. In the new TLV, introduce the generation ID (16 or 32 bits).
>
>   3. The implementations guarantee that the generation ID is
>      incremented with each reboot using one of multiple methods,
>      e.g., reading, incrementing and writing it back to nvram
>      on each boot, or using seconds since somewhen, or a calendar
>      clock, whatever is better suited for a specific system.
>
>   4. The CSN is incremented after each packet. If a system sends
>      10 packs per sec, 32-bit space will give us more than 10
>      years of a key lifetime. We may want to increase it though,
>      if we seriously consider subsecond hellos.
>
>   5. The receiving side checks that the CSN in the packet is
>      _greater_ than the locally stored value.
>
> Vernon did not seem to like the scheme, because of the possible
> issues with NVRAM, and calendar clock...

        I'm with Vernon.  The attack changes, but it is not obvious 
that the new attack would be any more work, just different.  To be
useful, a security mechanism needs to visibly increase the work
that an attacker must make against the system being attacked,
IMHO.

        IMHO, the likely next logical improvement step would be to
move to real digital signatures (as different from a keyed hash
function).  I doubt there is much interest in implementing or
deploying that, taking the existence of OSPF with Digital Signatures
as a datum.

Ran
[email-masked]

---

From: Alex Zinin <[email-masked]>
Date: Mon, 2 Jul 2001 13:40:50 -0700

Ran,

 To make sure we're on the same page, I'm not looking at this
 as an attempt to improve the authentication mechanism from
 the crypto perspective (as you mentioned, Digital Signatures
 do not seem to be of real interest to people), but as an attempt
 to prevent very simple replay attacks _within_ HMAC and try to
 fix those well-known problems with the sequence numbers that you
 mentioned and Vernon elaborated on.

-- 
Alex Zinin