IETF-SSH archive

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

Re: Comments on the reviesed Security Section open issues.



On Tue, May 13, 2003 at 02:00:26AM +0300, Heikki Nousiainen wrote:
> On Mon, 12 May 2003, RJ Atkinson wrote:
> > 
> > Does someone want to try to construct a rationale for the
> > document about why folks believe the attempted replay
> > protection actually works ?
> 
> I'm not much of an editor, but maybe someone can slash something out of 
> the following:
> 
> Running sequence number gives us an unique input for the MAC 
> function regardless of the contents of the packet, as long as the 
> sequence number doesn't wrap. With rekeying before the sequence number 
> wraps, we get an unique input into the MAC function (well, HMAC at least) 
> regardless of the sequence counter wrapping.
> 
> If an attacker captures a packet and inserts it within the SSH stream in 
> order to replay the packet, either the sequence number or the MAC key will 
> be different, and the MAC check will fail.
> 
> 
> We assume MAC is secure of course, specifically it being infeasible to
> construct x' such that MAC(x) = MAC(x'). For HMACs it is discussed in
> rfc 2104.
> I don't know if it's relevant or not, but given that an attacker wants to
> re-use data from the packet, there are even less bits to work with, and,
> even less of a chance of succeeding in creating a valid MAC.

I like this text.  Note that because the "packet sequence
number itself is not included in the packet sent over the wire"
out-of-sequence detection and recovery is not possible.

Rekeying before sequence number wrapping is a MUST though.

Cheers,

Nico
-- 



Home | Main Index | Thread Index | Old Index