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