Re: Replays - thoughts on Gutmann response

Just as another thought, has anyone seen this paper?
http://plg.uwaterloo.ca/~aeehassa/home/papers/crypto/secureUDP.htm

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?

Cheers,

Allwyn.


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
Director
Stobor Pty Ltd

Mobile: + 61 414 470 392
Email: [email protected]
Web: http://stobor.net/

--
Message sent by the [email protected] mailing list.
Unsubscribe: mail [email protected], "unsubscribe cipe-l" in body
Other commands available with "help" in body to the same address.
CIPE info and list archive: <URL:http://sites.inka.de/~bigred/devel/cipe.html>