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

To: cipe-l <cipe-l,AT,inka,DOT,de>
Subject: Re: Replays - thoughts on Gutmann response
From: Mr Allwyn Fernandes <af+cipel,AT,stobor,DOT,net>
Date: Thu, 9 Oct 2003 01:37:48 +1000
In-reply-to: <200309261016.46517.alatham@flexsys-group.com>
References: <944775566166B64B9A2DD5EE0159B5CDBA2A@europa.directory.futurefoundations.com> <1064557595.7652.134.camel@monster.omnifarious.org> <200309261016.46517.alatham@flexsys-group.com>

Just as another thought, has anyone seen this paper?

The paper discusses an (application-layer) UDP-based encrypted link. 
The author is essentially discussing a TLS-style secure link for UDP 
traffic. He goes through the reasons not to use TLS or SSL for his 
application (multimedia streaming). (He does use TLS for his key-ex 
step however.)

The paper suggests using the sliding-window technique for replay 
protection... (as used in IPSEC and OpenVPN)... This addresses Allan's 
concerns about how to simultaneously allow out-of-sequence packets, 
while preventing problems with duplicates...

Just my $0.02... Thoughts, anyone?



On Fri, 26 Sep 2003 18:16, Allan Latham wrote:
> 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

Allwyn Fernandes
Stobor Pty Ltd

Mobile: + 61 414 470 392
Email: af+cipel,AT,stobor,DOT,net
Web: http://stobor.net/

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