Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/drafts/draft_s_z/draft-simpson-ipsec-enhancement-01.txt

Text File | 1997-04-30 | 15KB | 496 lines

Network Working Group                           W A Simpson (DayDreamer)
Internet Draft                                     D A Wagner (Berkeley)
expires in six months                                         April 1997


                Internet Security Transform Enhancements                 -
                 draft-simpson-ipsec-enhancement-01.txt                  |


Status of this Memo

   This document is an Internet-Draft.  Internet Drafts are working doc-
   uments of the Internet Engineering Task Force (IETF), its Areas, and
   its Working Groups.  Note that other groups may also distribute work-
   ing documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months, and may be updated, replaced, or obsoleted by other documents
   at any time.  It is not appropriate to use Internet Drafts as refer-
   ence material, or to cite them other than as a ``working draft'' or
   ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow
   Directories on:

      ftp.is.co.za (Africa)
      nic.nordu.net (Europe)
      ds.internic.net (US East Coast)
      ftp.isi.edu (US West Coast)
      munnari.oz.au (Pacific Rim)

   Distribution of this memo is unlimited.

Abstract

   This document describes several generic security transform enhance-
   ments for the IP Security Protocols (AH and ESP).













Simpson                   expires in six months                 [Page i]
DRAFT                     Transform Enhancement               April 1997


1.  Introduction

   The implementation of automated key management provides the opportu-
   nity for enhancement of the basic Internet Protocol Security trans-
   forms.  Rapid key updates are available for better replay protection.
   Larger quantities of key material are available to improve the qual-
   ity of the security transforms.

   These features are not always fundamental to operation of Internet    |
   Security, when they duplicate features already available through
   other protocol mechanisms or more powerful transforms.  However,
   automated key management makes these features cheaply available.

   Selection of these enhancements are the domain of particular key man-
   agement mechanisms.  Operational policy considerations are outside
   the scope of this document.


2.  Replay Protection

   When an adversary resends an earlier intercepted IP datagram, the
   target would like to detect and discard that datagram.  It is desir-
   able that detection occur before computationally intensive opera-
   tions, such as decryption.

   Replay protection provides cryptographically secure at-most-once
   datagram delivery.  This is distinguished from the ordinary trans-
   port-layer delivery mechanisms that would be exercised later in the
   protocol processing.

   To provide replay protection, each implementation maintains one (or   |
   more) sequence numbers for each security association.  A sequence     |
   number is unique for each IP Destination and SPI.  Replay protection  |
   is accomplished by authenticating the sequence numbers.  Secure
   replay protection requires that the key used for authentication be
   changed before the sequence number repeats.  This is made practical
   through automated key management.

   When sending, each sequence number MUST be initialized to 1 for the   |
   first datagram, and MUST be incremented (as an unsigned integer)
   after each datagram is sent.

   On receipt, the sequence number is checked against a list of previ-   |
   ously accepted numbers.  There is no requirement that datagrams
   arrive in order.  As each datagram arrives, the sequence number is
   stored so that it won't be accepted again.

   The exact algorithm is implementation dependent.  The implementation  |



Simpson                   expires in six months                 [Page 1]
DRAFT                     Transform Enhancement               April 1997


   MUST reject datagrams with duplicate sequence numbers, and SHOULD     |
   make an effort to accept non-duplicate out-of-order datagrams.


2.1.  AH Sequencing

   A 16-bit sequence number MAY be sent in the previously Reserved field |
   of the Authentication Header (AH) [RFC-1826].  When this feature is   |
   implemented by the sender, the value zero MUST NOT be sent.

   The receiver validates this number within an implementation dependent
   range of expected values.  Any AH protected datagram that fails this
   test is silently discarded.

   Receipt of the value zero indicates that the range has been
   exhausted, or that the sender has not correctly implemented replay
   protection.


2.2.  ESP Sequencing

   A 32-bit sequence number MAY be sent immediately following the SPI in |
   the Encapsulating Security Payload (ESP) [RFC-1827].  When this fea-  +
   ture is implemented by the sender, the value zero MUST NOT be sent.   +

   The receiver validates this number within an implementation dependent +
   range of expected values.  Any ESP protected datagram that fails this +
   test is silently discarded.                                           +

   Receipt of the value zero indicates that the range has been           +
   exhausted, or that the sender has not correctly implemented replay    +
   protection.                                                           +

   When an Initialization Vector (IV) is required by the transform (as
   in [RFC-1829]), this sequence number can be used in formulating the   |
   IV.


2.3.  Combination

   When both AH and ESP Sequencing are present, or multiple AH or ESP    |
   headers are present, the sequence numbers are unique to each header   |
   and likely to be different for each SPI.  Each sequence number is     |
   checked independently.







Simpson                   expires in six months                 [Page 2]
DRAFT                     Transform Enhancement               April 1997


2.4.  Implementation

   A full-size (2**16 or 2**32 bit) array for storing the status of each
   sequence number received is probably impractical.  The following sim-
   ple algorithm is one possible improvement for single IP Source traf-
   fic.

   A low-water mark L is maintained; arriving sequence numbers less than
   (earlier than) the low-water mark are automatically rejected.

   A fixed window size W is chosen, depending on storage constraints.

   An array A[L..L+W-1] of size W is maintained, where each element
   maintains the state (stale or fresh) of the corresponding sequence
   number.

   The following steps are applied to each incoming sequence number S:


































Simpson                   expires in six months                 [Page 3]
DRAFT                     Transform Enhancement               April 1997


      1. If S < L
            discard the datagram.

      2. If S < L+W
         2a. If A[S] == stale
                discard the datagram.
         2b. Else
                set A[S] = stale,
                accept the datagram.

      (note: S > L+W-1)

      3. If A[L] == stale
            Let x = L;
            While A[x] == stale
               Do set x = x + 1.

            Let y = L;
            Let L = x.
            (shift the array A[] down by y-L elements in memory if necessary,
             so now A[] has the new bounds L..L+W-1)
            Set A[j] = fresh for y+W-1 < j < L+W.
            Goto Step 1.

      (note: S > L+W-1 and A[L] == fresh)

      4. Let y = L;
         Let L = S-W+1.
         Shift the array A[] down by y-L elements in memory if necessary,
           so now A[] has the new bounds L..L+W-1 (or L..S).
         Set A[j] = fresh for y+W-1 < j < L+W.
         Set A[S] = stale and accept the datagram.

   Two invariants are maintained in this algorithm.  First, all sequence
   numbers S < L are stale.  Second, all sequence numbers S > L+W-1 are
   fresh.

   Note that step 4 forgets some state information, and may cause out-
   of-order datagrams that were sent earlier but received later to be
   (incorrectly) judged stale and discarded.  Though this algorithm may
   inadvertenly reject a fresh datagram as stale, the important point is
   that it will never accept a replayed datagram.

   An implementation may wish to go through with step 4 only for packets
   that pass the authentication verification.

   This is only one possible algorithm; implementators may choose
   another, so long as it rejects replayed datagrams with duplicate



Simpson                   expires in six months                 [Page 4]
DRAFT                     Transform Enhancement               April 1997


   sequence numbers.


3.  Secret Initialization Vector

   When an Initialization Vector (IV) is specified by the transform (as
   in [RFC-1829]), this IV may be enhanced by combination with a secret
   value.  Provision of a secret IV for each security association is
   made practical through automated key management.

   In most cases, a secret IV is not a requirement, as the [VK83] speci-
   fied attacks are impractical for the current Internet Security trans-
   forms.  The existing transforms already provide that the IV is dif-
   ferent for each datagram in the same security association.  Choosing
   a secret IV during session establishment may ensure that the result-
   ing IV is more likely to be different for every security association
   when there are a large number of security associations between the
   same parties.


3.1.  XOR

   The most simple technique is to generate a secret IV of the appropri-
   ate size, and XOR the secret value with the IV carried in the ESP
   header.


3.2.  Hash

   A more robust technique is to regenerate a new IV using a one-way
   hash function of a (variable length) secret key and the IV carried in
   each ESP header, extracting an appropriate size IV from the result.
   This provides a stronger IV that does not appear related to previous
   IVs.


4.  Whitening

   A simple method for strengthening common block cipher transforms (as
   in [RFC-1829]) involves XOR of additional secret values with each
   block.  Provision of these additional secret values for each security
   association is made practical through automated key management.

   Indeed, so-called "whitening" is merely an application of repeated
   key XOR, the most common cheap method of hiding data.  It is insecure
   without combination with a robust cipher.





Simpson                   expires in six months                 [Page 5]
DRAFT                     Transform Enhancement               April 1997


4.1.  Ciphertext

   The ciphertext may be XOR'd with a secret value before output to the
   datagram.  This requires a secret the same size as the block.  When
   Cipher Block Chaining (CBC) is used, this hides the chaining values
   used as an IV for the next block.


4.2.  Plaintext

   The plaintext may be XOR'd with a secret value before input to the
   block cipher.  This requires a secret the same size as the block.
   The effect is similar to a secret IV applied to all the blocks.


4.3.  With Pseudo-random Sequence

   Another variant is to generate a pseudo-random sequence of secrets to
   XOR with either the ciphertext or plaintext.  This requires a (vari-
   able length) secret to be used as a seed to the sequence generator.


4.4.  With Hash Sequence

   A more robust variant is to generate a sequence of secrets using a
   one-way hash function of a (variable length) secret key and each
   block chaining vector (CV), extracting an appropriate size block from
   the result.  This effect is similar to a secret hash IV applied to
   all the blocks.


4.5.  Combinations

   These variants can be easily combined.  For example, an XOR of a
   secret with both the ciphertext and plaintext when used as a sandwich
   around DES is called DES-XEX2 (DES key plus one XOR key) or DES-XEX3
   (DES key plus two separate XOR keys) [KR96].


Security Considerations

   Analyses of these simple techniques are readily available in the lit-
   erature.  Further details may be found in [Schneier95].

   The IV or CV hashing techniques are particularly useful in conjunc-
   tion with replay protection, as they prevent undetectable modifica-
   tion of the predictable Sequence numbers.




Simpson                   expires in six months                 [Page 6]
DRAFT                     Transform Enhancement               April 1997


Acknowledgements

   Much of the text and implementation details of Replay Protection were
   provided by David Wagner.  Additional suggestions were provided by
   Steve Kent.

   Special thanks to John Ioannidis for inspiration and experimentation
   which began this most recent round of IP Mobility and IP Security
   development.  Some of the text on Replay Protection was derived from
   [swIPe].

   Robert Baldwin suggested the XOR protection of the IV.

   Bart Preneel suggested the hash protection of the IV.

   The use of "whitening" is further described in [Schneier95].          +

   Angelos Keromytis, and Bill Sommerfeld provided useful critiques of   +
   earlier versions of this document.

   This specification has been awaiting RFC publication since April 1996. +


References

   [KR96]   Kaliski, B., and Robshaw, M., "Multiple Encryption: Weighing
            Security and Performance", Dr. Dobbs Journal, January 1996.

   [RFC-1826]
            Atkinson, R., "IP Authentication Header", RFC-1826, Naval
            Research Laboratory, July 1995.

   [RFC-1827]
            Atkinson, R., "IP Encapsulating Security Protocol (ESP)",
            RFC-1827, Naval Research Laboratory, July 1995.

   [RFC-1829]
            Karn, P., Metzger, P., Simpson, W., "The ESP DES-CBC Trans-
            form", July 1995.

   [Schneier95]
            Schneier, B., "Applied Cryptography Second Edition", John
            Wiley & Sons, New York, NY, 1995.  ISBN 0-471-12845-7.

   [swIPe]  Ioannidis, J., and Blaze, M., "The Architecture and Imple-
            mentation of Network-Layer Security Under Unix", Fourth
            Usenix Security Symposium Proceedings, October 1993.




Simpson                   expires in six months                 [Page 7]
DRAFT                     Transform Enhancement               April 1997


   [VK83]   Voydock, V.L., and Kent, S.T., "Security Mechanisms in High-
            level Networks", ACM Computing Surveys, Vol. 15, No. 2, June
            1983.



Contacts

   Comments about this document should be discussed on the               |
   [e-mail] mailing list.

   Questions about this document can also be directed to:                |

      William Allen Simpson
      DayDreamer                                                         |
      Computer Systems Consulting Services
      1384 Fontaine
      Madison Heights, Michigan  48071

          [e-mail]
          [e-mail] (preferred)
          [e-mail]


      David A Wagner
      Computer Science Department
      University of California
      Berkeley, California  94720

          [e-mail]





















Simpson                   expires in six months                 [Page 8]