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

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 found.
>...
> 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 used
         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 with
         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 duplicate
         packets; this may be achieved by only accepting packets which
         increment the sequence number, or maintaining a small window
         of acceptable packet numbers.


> 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.

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 be
   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.

And here's what Karn wrote in 1994 and 1995 (for Photuris, with me):

   Many security breaches in cryptographic systems have been facilitated
   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-key
   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 separately
   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 operating
      system.  Such a mechanism is outside the scope of this document.

WSimpson@UMich.edu
    Key fingerprint =  17 40 5E 67 15 6F 31 26  DD 0D B9 9B 6A 15 2C 32
BSimpson@MorningStar.com
    Key fingerprint =  2E 07 23 03 C5 62 70 D3  59 B1 4F 5E 1D C2 C1 A2
Follow-Ups: