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

Re: replay and insecure security implementations

	 And now, the other part of the message, slightly reordered:
	 
	 > From: Steven Bellovin <smb@research.att.com>
	 > We put sequence numbers back in when cryptographic problems were fou
	nd.
	 >...
	 > The new
	 > sequence number, though syntactically the same as the original swIPe
	 > version, has a totally different purpose.
	 >
	 As much as it pains me, I have to disagree.  Here is the text from
	 the swIPe internet-draft in 1993:
	 
	       Packet sequence number (32 bits)
	          This field protects against replay attacks and may also be us
	ed
	          for synchronization by a stream cipher.  It is unique within
	          the context of an endpoint pair (common source/destination
	          address and Policy identifier).  It is incremented by one wit
	h
	          every packet sent, and initialized whenever the hosts 
	          re-negotiate keys and/or policies.
	 
	          The hosts MUST renegotiate crypto variables before the packet
	          sequence number wraps around. A host MUST NOT accept duplicat
	e
	          packets; this may be achieved by only accepting packets which
	          increment the sequence number, or maintaining a small window
	          of acceptable packet numbers.
	 
This doesn't at all contradict what I said.  If you're doing any sort
of replay prevention in a security context, it's to deter replay attacks.
Naturally, you need to deal with wrap-arounds -- replays are replays.
The question is what sort of attacks, and to what end.  My statement
was based on discussions with Blaze and Karn.  No one mentioned
the sorts of attacks I discussed in my papers.
	 
	 > For those who haven't read my paper, an enemy with a login on the sa
	me
	 > machine can bind to the same port after the target has finished usin
	g
	 > it, and replay the packets.  The decryptor module will happily trans
	late
	 > them back to plaintext, thus gutting the privacy protection.
	 
	 Now, this would be quite a problem, if it represented a real attack.
	 But, in my opinion, this attack is unrealistic in any properly designed
	 and implemented operating system with security.
	 
	 Any implementor that claimed to have a secure system, and had
	 implemented IP Security Protocols, should have protected against this
	 attack.  Indeed, there has been plenty of warning in the literature.
	 
	 But should warnings in the literature not be enough, there was also
	 plenty of guidance in the WG drafts and RFCs.  Here's what Metzger
	 wrote in early 1995 (RFCs 1829 and 1851, with Karn and me):
	 
	    The cut and paste attack described by [Bell95] exploits the nature 
	of
	    all Cipher Block Chaining algorithms.  When a block is damaged in
	    transmission, on decryption both it and the following block will be
	    garbled by the decryption process, but all subsequent blocks will b
	e
	    decrypted correctly.  If an attacker has legitimate access to the
	    same key, this feature can be used to insert or replay previously
	    encrypted data of other users of the same engine, revealing the
	    plaintext.  The usual (ICMP, TCP, UDP) transport checksum can detect
	    this attack, but on its own is not considered cryptographically
	    strong.  In this situation, user or connection oriented integrity
	    checking is needed.

User- or connection-oriented keying are excellent defenses against this
attack.  They're not always practical, especially if outboard (router-based
or bump-in-the-cord) encryption is used.
	 
	 And here's what Karn wrote in 1994 and 1995 (for Photuris, with me):
	 
	    Many security breaches in cryptographic systems have been facilitat
	ed
	    by designs that generate traffic-encrypting keys (or their
	    equivalents) well before they are needed, and then keep them around
	    longer than necessary.  This creates many opportunities for
	    compromise, especially by insiders.  A carefully designed public-ke
	y
	    system can avoid this problem.
	 ...
	    Internet Security protects against threats that come from the
	    external network, not from mutually hostile users of the nodes
	    themselves.  Any secure multi-user operating system MUST be able to
	    protect its resources from hostile users, and protect one hostile
	    user from damaging the resources controlled by another hostile user
	.
	 
	    Each secure multi-user operating system MUST be capable of separate
	ly
	    maintaining multiple Identification Exchange SPI values for each
	    Value Exchange calculated shared-secret.  ...
	 
	       Successful use of user-oriented keying requires a significant
	       level of operating system support.  If the operating system has 
	a
	       security vulnerability, then there is no basis for separate user
	-
	       oriented keying.
	 
	       Use of multi-user segregated exchanges likely requires added
	       functionality in the transport API of the implementation operati
	ng
	       system.  Such a mechanism is outside the scope of this document.

Yes.  So what?  Segregating keys -- and my Danvers presentation was
intended to justify precisely that policy -- is a defense.  Sequence
numbers are another defense that in some contexts work better.