[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RPSEC] rate limiting management traffic, redux



At 8:32 AM +0100 4/18/03, Damir Rajnovic wrote:
Hi,

At 16:22 17/04/2003 -0700, Mark Handley wrote:
Suppose I have two routers, A and B that were communicating securely.
Now, A restarts.  How is B going to accept any more packets from A, as
A can no longer send packets that fall in the window?

I think you implied (trying to fill in the details myself):

 - A sends a re-initialization packet to B with nonce_A.
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.
Very good point.

Do we need to choose a new sequence number, rather than just starting at 0 again? I guess we get some benefit from a new sequence starting point in terms of rejecting old or random traffic faster, assuming that the attacker does not have passive wiretap ability (often true, but not always).

 > - B replies with nonce_A and a new nonce_B.

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.

I think that you can accomplish the same result with only two
messages instead of four. Since all data are sent in the clear
the strength of the protection lies in the one-way hash function
and the shared secret.
Right. And, this hash function need not be the same as the function I called for using to generate per-packet tags. This hash function could be slower, since it is used less frequently.

These steps could probably be abandoned.

 - A sends nonce_A and nonce_B back to B along with the new sequence
   number it wants to use and the one-way hash of nonce_A, nonce_B,
   the new sequence number and the secret.

 - On success, B sends nonce_A and nonce_B back to A, the new sequence number
   specified by A, and the one-way hash of nonce_B (but not nonce_A to
   avoid replay) the new sequence number and the secret.

On success, the new secret becomes the hash of the old secret and the
two nonces.
Even using the modified handshake you can derive the new key in the
same manner. A and B are mutually authenticated and H(secret, nonce_A,
nonce_B) was never transmitted.

Gaus
I like the style of your proposed exchanges. The goals of the (re) initialization protocol are to put in place a new secret and, maybe, to reset the sequence number and to minimize the opportunities for an attacker to waste router resources in the process.

Steve
_______________________________________________
RPSEC mailing list
RPSEC@ietf.org
https://www1.ietf.org/mailman/listinfo/rpsec