<< | Thread Index | >> ]    [ << | Date Index | >> ]

To: cipe-l,AT,inka,DOT,de
Subject: Replays - thoughts on Gutmann response
From: Allan Latham <alatham,AT,flexsys-group,DOT,com>
Date: Fri, 26 Sep 2003 10:16:46 +0200
In-reply-to: <1064557595.7652.134.camel@monster.omnifarious.org>
References: <944775566166B64B9A2DD5EE0159B5CDBA2A@europa.directory.futurefoundations.com> <1064557595.7652.134.camel@monster.omnifarious.org>

Hi all

the replay problem is this:

An attacker can record a packet and simply resend it later. If the key in use 
is still valid the inserted packet will decrypt correctly. What happens then 
depends on the nature of the payload.

If the payload is a TCP packet it will be out of sequence in the stream and 
the TCP stack will discard it. This is therefore not a problem.

If the payload is UDP or ICMP then the application will see the packet for a 
second time. Whether this is a problem or not depends on how the application 
has been written.

Good design princples dictate that a program should not make assumptions 
about 
the data transport over and above what is specified at the level of the API 
used by that program. That means that if the program is written to use TCP it 
can safely assume that the data stream is reliable and duplicate packets have 
already been discarded. This is the TCP spec.

Now if the program uses UDP then it must allow for the fact that packets can 
arrive out of order or can be duplicated. The program must not assume that 
there is a layer under UDP and IP which drops duplicate packets. If a program 
using UDP cannot cope with duplicate packets this a bug in that program.

It is not the job of the link layer (in this case CIPE) to provide protection 
against duplicate packets. Duplicate packets happen anyway even without a 
malicious attacker. Even if individual links protect against duplication as 
soon as you allow dynamic routing over multiple routes the problem will 
reappear.

If that were all, my opinion would be that we don't have a replay problem 
with 
CIPE. Unfortunately there are some concerns:

1. ICMP and UDP traffic could possibly be replayed to cause a DOS attack.
2. Key exchange replays may allow an attacker to force CIPE to use the static 
key or an already cracked dynamic key.

I hope to cover the whole subject of how to harden key exchange later.

The price to pay for avoiding duplicates is program complexity. A simple 
approach would be to run a sequence count in each packet sent with a specific 
key starting from a sequence number negotiated during key exchange. You then 
need to address the problem of what to do with out of sequence packets.

The simple approach is to discard any with sequence numbers which are not 
greater than the last one you saw. This however discards out of sequence 
packets as well as duplicates. Avoiding this problem adds program complexity 
again.

My own opinion is that if there is going to be an update to CIPE then this 
should be added for the sake of stopping the DOS attacks and part of making 
hacking the key exchange more difficult.

Best regards to all

Allan


<< | Thread Index | >> ]    [ << | Date Index | >> ]