Subject: Re: [RPSEC] rate limiting management traffic, redux

From: Vassilis Prevelakis <[email-masked]>
Date: Fri, 18 Apr 2003 04:43:39 -0400 (EDT)

Damir Rajnovic <[email-masked]> wrote:
> If you send nonce_A and H(secret, nonce_A) you will ensure that router A
> is authenticated because (by the definition) only A knows the secret.
> The router A can also offer a new sequence number in the same packet.
> To make guessing even harder we can say that the router A should
> send H(secret, nonce_A, new_seq_A).
> 
> By sending only nonce_A you are forcing the router B to respond to
> any request it receives. It does not have any means to discriminate
> which requests are legitimate and which are not. By sending a hash
> in the first packet you can authenticate the sender.
[...]
> B can reply with nonce_A, nonce_B, new sequence B and H(secret,
> nonce_B, new_seq_B) and H(secret, sequence A+1). The first hash
> H(secret, nonce_B, new_seq_B) server to initialize the new
> sequence number for the reverse session (from A to B). The second
> hash, H(secret, seq_A+1) is used normally as envisaged. The router
> A will check it first to determine if it will accept the packet
> or not.

Your two message scheme exposes router B to replay attacks. I.e. what
is to prevent me from recording the initial packet
	nonce_A, new_seq_A, H(secret, nonce_A, new_seq_A) 
and sending it to B every now and then? What should A do when it
receives the reply from B? Can I capture A's reply and feed it to
B later on?

If the process of verifying the incoming message and computing the
reply (new seq num, etc) is expensive, then you also expose B to DOS
attacks.

Must we rediscover the wheel in this group? Why don't we all take a break
to read a good book on communications security and return after a week
or so.

**vp

_______________________________________________
RPSEC mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rpsec

---

From: Damir Rajnovic <[email-masked]>
Date: Tue, 22 Apr 2003 07:59:19 +0100

Hello,

>receives the reply from B? Can I capture A's reply and feed it to

Valid points. We can add a time stamp to prevent reply attacks. If
a packet is older than some_time_period it will be discarded.

Let me try again. The proposed exchange may look like this:

*) Router A sends:
nonce_A, time_stamp_A, new_seq_A, H(secret, nonce_A, tim_stamp_A, new_seq_A)

*) After receiving this packet router B will perform the following
   tests:

   1) calculate the hash using his secret that is shared with the
      router A and compare the result with the hash received in
      the packet. If they do not match the packet will be rejected.

   2) Check the time_stamp_A against its own current time. If it is
      older than some predefined (or negotiated) time interval the
      packet will be dropped.

   If packet passes these checks it will be accepted as a legitimate
   request from the router A to negotiate a new sequence number and
   new secret

*) After successful verification the router B will send back:

nonce_A, nonce_B, new_seq_B, time_stamp_B, 
H(secret, nonce_A, nonce_B, new_seq_B, time_stamp_B)

   At the same time router B will set the new shared key to be
   H(secret, nonce_A, nonce_B). However, it will still accept packets
   where only the "old secret" was used.

*) After receiving this packet the router A will perform the following
   checks:

   1) calculate the hash using his secret that is shared with the
      router B and compare the result with the hash received in
      the packet. If they do not match the packet will be rejected.

   2) Check the time_stamp_A against its own current time. If it is
      older than some predefined (or negotiated) time interval the
      packet will be dropped.

*) After successful verification the router A will set its new shared
   key to be H(secret, nonce_A, nonce_B)

Please note that here we can safely drop nonces and use time stamps
instead. That can speed calculation of the hash and would not compromise
the scheme.

>reply (new seq num, etc) is expensive, then you also expose B to DOS

True again. Unfortunately, there is no easy way out of this. You will
either perform a superficial check and then accept a packet as genuine
or you will spend a bit more time verifying legitimacy of the packet
before accepting it. If we can have a check that will provide a
satisfactory level of assurance that the packet is legitimate and that
will take only 10%-15% (preferably even less) of the total processing
time of the packet, then I would classify this as a success IMHO.

Gaus
==============
Damir Rajnovic <[email-masked]>, PSIRT Incident Manager, Cisco Systems
<http://www.cisco.com/go/psirt>      Telephone: +44 7715 546 033
200 Longwater Avenue, Green Park, Reading, Berkshire RG2 6GB, GB
==============
There are no insolvable problems. 
The question is can you accept the solution?