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

Re: Derived versus Explicit IV

	 > From: "Theodore Y. Ts'o" <tytso@MIT.EDU>
	 >                  ....  RFC-1829 implementations are allowed to pick
	 > random IV's --- it doesn't specify how the IV's are picked at all.  
	If
	 > they do so, they won't be complaint with the latest ESP, because tha
	t
	 > field is where the sequence number goes, which must be a sequentiall
	y
	 > incrementing field starting at zero.
	 >
	 That latter analysis is not correct.
	 
	 For manual keys, the sequence number starts at a random number.  There
	 is no anti-replay requirement, but the random start provides a small
	 degree of protection through unpredicatability.
	 
	 For automated keys, the sequence number starts at one (not zero).
	 
	 Historically, RFC-1829 was based on swIPe, which had a sequence number.

1829 does not have sequence numbers.  The text explicitly states that
IV selection is implementation-dependent, though use of a counter is
described as meeting the requirements.

A number of people -- including me -- objected to the swIPe sequence
number.  At the time, the cryptographic importance was not understood.
I had many discussions with Karn and Blaze on the subject; the only
rationale offered then was that perhaps higher-level protocols couldn't
cope well with packet replay in a hostile world.  They felt that the
long-standing requirement for such an ability was designed to deal with
non-malicious failures, and that an opponent might be able to do evil
things by re-injecting packets.  They were overruled; most people (again,
including me) felt that the older policy was sufficient.  (And if we
hadn't pulled the sequence number ourselves, we likely would have been
attacked by non-security folks in the IETF, for a layering violation.
Indeed, I believe I deflected just such an attack last night, from a
very well-respected member of the community.)

We put sequence numbers back in when cryptographic problems were found.
For those who haven't read my paper, an enemy with a login on the same
machine can bind to the same port after the target has finished using
it, and replay the packets.  The decryptor module will happily translate
them back to plaintext, thus gutting the privacy protection.  The new
sequence number, though syntactically the same as the original swIPe
version, has a totally different purpose.
Follow-Ups: