home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-ipsec-esp-des-md5-03.txt < prev    next >
Text File  |  1996-09-16  |  24KB  |  837 lines
  1.  
  2. Security Working Group                               IPsec Working Group
  3. INTERNET DRAFT                                         J. Hughes, Editor
  4.                                                           September 1996
  5.                                                    Expires in Six months
  6.  
  7.  
  8.     Combined DES-CBC, HMAC and Replay Prevention Security Transform
  9.                  <draft-ietf-ipsec-esp-des-md5-03.txt>
  10.  
  11.  
  12.  
  13. Status of this Memo
  14.  
  15.    This document is a submission to the IETF Internet Protocol Security
  16.    (IPSEC) Working Group. Comments are solicited and should be addressed
  17.    to the working group mailing list (ipsec@tis.com) or to the editor.
  18.  
  19.    This document is an Internet-Draft.  Internet Drafts are working
  20.    documents of the Internet Engineering Task Force (IETF), its areas,
  21.    and its working Groups. Note that other groups may also distribute
  22.    working documents as Internet Drafts.
  23.  
  24.    Internet-Drafts draft documents are valid for a maximum of six months
  25.    and may be updated, replaced, or obsoleted by other documents at any
  26.    time. It is inappropriate to use Internet-Drafts as reference
  27.    material or to cite them other than as "work in progress."
  28.  
  29.    To learn the current status of any Internet-Draft, please check the
  30.    "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
  31.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  32.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  33.    ftp.isi.edu (US West Coast).
  34.  
  35.    Distribution of this memo is unlimited.
  36.  
  37. Abstract
  38.  
  39.    This draft describes a combination of privacy, authentication,
  40.    integrity and replay prevention into a single packet format.
  41.  
  42.    This document is the result of significant work by several major con-
  43.    tributors and the IPsec working group as a whole. These contributors,
  44.    cited later in this document, provided many of the key technical
  45.    details summarized in this document. [IB93] [IBK93]
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53. Hughes                     September 14, 1996                   [Page 1]
  54.  
  55.  
  56.  
  57.  
  58.  
  59. INTERNET DRAFT                                            September 1996
  60.  
  61.  
  62.  
  63. Requirements Terminology
  64.  
  65.    In this document, the words that are used to define the  significance
  66.    of  each particular requirement are usually capitalised.  These words
  67.    are:
  68.  
  69.    - MUST
  70.  
  71.       This word or the adjective "REQUIRED" means that the  item  is  an
  72.       absolute requirement of the specification.
  73.  
  74.    - SHOULD
  75.  
  76.       This word or the adjective "RECOMMENDED" means  that  there  might
  77.       exist  valid  reasons  in  particular circumstances to ignore this
  78.       item, but the full implications should be understood and the  case
  79.       carefully weighed before taking a different course.
  80.  
  81.    - MAY
  82.  
  83.       This word or the adjective "OPTIONAL" means that this item is tru-
  84.       ly  optional.  One vendor might choose to include the item because
  85.       a particular marketplace requires it or because  it  enhances  the
  86.       product, for example; another vendor may omit the same item.
  87.  
  88.    For the purpose of this RFC, the terms conformance and compliance are
  89.    synonymous.
  90.  
  91. 1.  Discussion
  92.  
  93.    This draft allows a combination of MD5 and DES-CBC. In addition to
  94.    privacy, the goal of this transform is to ensure that the packet is
  95.    authentic, can not be modified in transit, or replayed.
  96.  
  97.    The claims of privacy, integrity, authentication, and replay preven-
  98.    tion are made in this draft. A good general text describing the
  99.    methods and algorithm are in [Schneier95].
  100.  
  101.    Privacy is provided by DES-CBC [FIPS-46] [FIPS-46-1] [FIPS-74]
  102.    [FIPS-81].
  103.  
  104.    Integrity is provided by HMAC [Krawczyk96].
  105.  
  106.    Authentication is provided since only the source and destination know
  107.    the HMAC key. If the HMAC is correct, it proves that it must have
  108.    been added by the source.
  109.  
  110.  
  111.  
  112.  
  113. Hughes                     September 14, 1996                   [Page 2]
  114.  
  115.  
  116.  
  117.  
  118.  
  119. INTERNET DRAFT                                            September 1996
  120.  
  121.  
  122.    Replay prevention is provided by the combination of a constantly
  123.    increasing count, the SPI and the HMAC key. The integrity of the
  124.    replay field is provided by the HMAC.
  125.  
  126. 2.  Packet Format
  127.  
  128.  
  129.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---
  130.  |                Security Parameters Index (SPI)                | ^
  131.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
  132.  |                                                               | |
  133.  +                Initialization Vector (Optional)               + |
  134.  |                                                               | |
  135.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |  ---
  136.  |                 Replay Prevention Field (count)               | |   ^
  137.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |   |
  138.  |                                                               | |   |
  139.  ~                      Payload Data                             ~ |   |
  140.  |                                                               |HMAC |
  141.  +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |  DES
  142.  |               |         Padding (0-7 bytes)                   | |  CBC
  143.  +-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |   |
  144.  |                               |  Pad Length   | Payload Type  | v   |
  145.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---  |
  146.  |                                                               |     |
  147.  ~                        HMAC digest                            ~     |
  148.  |                                                               |     v
  149.  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+    ---
  150.  
  151.  
  152.  
  153.  
  154. 2.1.  Security Parameters Index
  155.  
  156.    This field is negotiated at key setup and MUST not be 0 [RFC-1825]
  157.  
  158. 2.2.  Initialization Vector
  159.  
  160.    The use of an explicit Initialization Vector MAY be negotiated. The
  161.    purpose of this mode is to support devices that automatically gen-
  162.    erate IVs and can not operate using a constant IV_key_.
  163.  
  164.    This field is optional and is only used when an explicit IV is nego-
  165.    tiated during key exchange.  This field is contains random data or
  166.    contains the last cyphertext block of a previous packet sent or
  167.    received.
  168.  
  169.    For the packet which the explicit IV is received, the explicit IV is
  170.  
  171.  
  172.  
  173. Hughes                     September 14, 1996                   [Page 3]
  174.  
  175.  
  176.  
  177.  
  178.  
  179. INTERNET DRAFT                                            September 1996
  180.  
  181.  
  182.    used in place of the constant IV_key_ described later in this docu-
  183.    ment.
  184.  
  185. 2.3.  Replay Prevention
  186.  
  187.    Replay Prevention is an unsigned 32 bit incrementing counter starting
  188.    at a mutual agreed upon value (see Key Material) and is enforced to
  189.    be within a mutually negotiated window size.
  190.  
  191.    The key (K, as described in a later section) MUST be changed fre-
  192.    quently enough so that the counter is not allowed to return to the
  193.    initial value; in other words, the key MUST be changed before 2^32
  194.    packets are transmitted using this key. For a given SPI, counter
  195.    wrapping MUST be considered to be a replay attack. (While a wrap is a
  196.    replay attack, there is always the possibility that a packet can get
  197.    duplicated, so the presence of a single or small number of duplicate
  198.    packets is not an absolute indication of a replay attack.)
  199.  
  200.    The receiver MUST verify that for a given SPI the packets received
  201.    have non-repeating (non-duplicate) counter values. This can be imple-
  202.    mented as a simple increasing count test or the receiver MAY choose
  203.    to accept out-of-order packets as long as it is guaranteed that pack-
  204.    ets can be received only once. For example, an implementation can use
  205.    a sliding receive window. If such a receive window is supported, the
  206.    receiver MUST ensure that it will accept packets within the current
  207.    window only once, and reject any packets it receives with a value
  208.    that is less than the lower bound of the window.
  209.  
  210.    Negotiated window sizes of 1 and 32 are suggested and larger multi-
  211.    ples of 32 are allowed. 1 indicates that only constantly increasing
  212.    replay numbers are allowed and packets which have replay values less
  213.    than the highest received are always rejected. 32 indicates that are
  214.    within 32 of the highest received, and are guaranteed not to have
  215.    been received before, are allowed.
  216.  
  217.    A window size of 1 MUST be supported. A value of 32 SHOULD be sup-
  218.    ported.
  219.  
  220.    If a value of 32 is negotiated, then the most recent 32 packets are
  221.    allowed to arrive out of order. That is, these 32 packets can arrive
  222.    in any sequence relative to each other except that these packets are
  223.    guaranteed to arrive only once. Appendix A has actual code that
  224.    implement a 32 packet replay window and a test routine. The purpose
  225.    of this routine is to show how it could be implemented.
  226.  
  227. 2.4.  Payload
  228.  
  229.    The payload contains data that is described by the payload type
  230.  
  231.  
  232.  
  233. Hughes                     September 14, 1996                   [Page 4]
  234.  
  235.  
  236.  
  237.  
  238.  
  239. INTERNET DRAFT                                            September 1996
  240.  
  241.  
  242.    field. This field is an integral number of bytes in length; the fol-
  243.    lowing padding and pad length fields will help provide alignment to a
  244.    double word boundary.
  245.  
  246. 2.5.  Padding
  247.  
  248.    The padding (pad bytes and pad length field) is used to align the
  249.    following "payload type" field to end on a double word boundary (when
  250.    counting from the start of the replay field).
  251.  
  252.    Padding bytes SHOULD be initialized with random data.
  253.  
  254.    At a minimum, the number of pad bytes added MUST be enough to align
  255.    the payload type field on the next appropriate boundary. However, the
  256.    sender MAY choose to include additional padding, provided that the
  257.    alignment is maintained. In total, the sender can add 0-255 bytes of
  258.    padding.
  259.  
  260. 2.6.  Pad Length
  261.  
  262.    The pad length field indicates the number of pad bytes immediately
  263.    preceding it. The range of valid values is 0-255, where a value of
  264.    zero indicates that the byte immediately preceding the pad length
  265.    field is the last byte of the payload.
  266.  
  267. 2.7.  Payload Type
  268.  
  269.    Describes what the payload is. The values are described in:
  270.  
  271.         ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers
  272.  
  273.  
  274. 2.8.  HMAC Digest
  275.  
  276.    The HMAC digest is a 128 bit residue described in [Krawczyk96]. This
  277.    covers the SPI, replay, payload, padding, pad length, payload type.
  278.  
  279.    HMAC is a keyed algorithm, where both directions are keyed
  280.    separately.  The implementation MUST use the HMAC_key_ as described
  281.    in the section on keys.
  282.  
  283. 3.  Encryption Transform Procedure
  284.  
  285.    CBC chaining with an constant IV_key_ is used (IV_key_I for the ini-
  286.    tiator -> responder direction and IV_key_R for the responder -> ini-
  287.    tiator direction). The IV_key_ remains constant for all packets send
  288.    in this direction.
  289.  
  290.  
  291.  
  292.  
  293. Hughes                     September 14, 1996                   [Page 5]
  294.  
  295.  
  296.  
  297.  
  298.  
  299. INTERNET DRAFT                                            September 1996
  300.  
  301.  
  302.    If an explicit IV is negotiated, 64 bits of random or the last
  303.    cyphertext block of a previous packet send or receive can be used.
  304.  
  305.         IV or
  306.        IV_key_  count|x1          x2             x3
  307.           |        |              |              |
  308.           |-------(+)    --------(+)    --------(+)
  309.                    |     |        |     |        |
  310.                 -------  |     -------  |     --------
  311.              k--| DES |  |  k--| DES |  |  k--| DES  |
  312.                 -------  |     -------  |     --------
  313.                    |     |        |     |        |
  314.                    |-----|        |-----|        |----...
  315.                    |              |              |
  316.                    y1             y2             y3
  317.  
  318.  
  319.  
  320.    Where count is the Replay counter. x1, x2, x3 are the plaintext (x1
  321.    is 32 bits, all others are 64 bits). y1, y2, y3 are the ciphertext.
  322.  
  323.    This transformation is comprised of the following 3 steps.
  324.  
  325.       1. Taking the data and encapsulating it with the SPI, IV (if
  326.       present), count, pad, pad length, and payload type.
  327.  
  328.       2. Calculating the HMAC using the HMAC_key_ and creating the dig-
  329.       est from the SPI, IV (if present), count, data, pad, pad length,
  330.       and payload type and placing the result into the HMAC digest
  331.       field.
  332.  
  333.       3. Encrypting the count, data, pad, pad length, payload type, and
  334.       HMAC digest using DES and the appropriate DES_key_ and IV_key_.
  335.       (Note that the first DES block is a combination of the count and
  336.       the first word of plaintext.)
  337.  
  338.  
  339. 4.  Decryption Transform Procedure
  340.  
  341.    CBC chaining with an constant IV_key_ is used. if an IV is present in
  342.    the packet, then the IV_key_ is not used and is replaced by the IV.
  343.  
  344.  
  345.  
  346.  
  347.  
  348.  
  349.  
  350.  
  351.  
  352.  
  353. Hughes                     September 14, 1996                   [Page 6]
  354.  
  355.  
  356.  
  357.  
  358.  
  359. INTERNET DRAFT                                            September 1996
  360.  
  361.  
  362.  
  363.          IV or
  364.         IV_key_    y1             y2             y3
  365.           |        |              |              |
  366.           |        |------        |------        |----...
  367.           |        |     |        |     |        |
  368.           |     -------  |     -------  |     --------
  369.           |  k--| DES |  |  k--| DES |  |  k--| DES  |
  370.           |     -------  |     -------  |     --------
  371.           |        |     |        |     |        |
  372.           |-------(+)    |-------(+)    |-------(+)
  373.                    |              |              |
  374.               (count|x1)          x2             x3
  375.  
  376.  
  377.  
  378.    Decryption is comprised of the following 4 steps.
  379.  
  380.       1. (Optional step) Decrypt the first bock of data using the
  381.       appropriate DES_key_ and IV_key_ (or IV) and then do a quick "san-
  382.       ity check" of the count. If the count has decreased below the win-
  383.       dow or has increased by more than 65k, then it is safe to discard
  384.       this packet as either a replay, non-authentic or too old. If the
  385.       count is within 65K, then the probability that the packet is
  386.       authentic is 65535/65536. (The following replay check and HMAC
  387.       check are both still required).
  388.  
  389.       2. Decrypt the count (if not already done), data, pad, pad length,
  390.       and payload type using DES and the appropriate DES_key_ and
  391.       IV_key_ (or IV).
  392.  
  393.       3. Calculate the HMAC using the HMAC_key_ and create the digest
  394.       from the SPI, IV (if present) count, data, pad, pad length, and
  395.       payload type and checking the result at digest at the end of the
  396.       packet. If the digest is incorrect, discard the packet.
  397.  
  398.       4. Check the count using the window algorithm discussed above. If
  399.       the packet is duplicate or too old, discard the packet.
  400.  
  401.  
  402. 5.  Key Material
  403.  
  404.    The key K is provided by the key management layer. This key is used
  405.    to derive the symmetric keys, they are:
  406.  
  407.       DES_Key_I is the DES key for traffic from the initiator ->
  408.       responder.
  409.  
  410.  
  411.  
  412.  
  413. Hughes                     September 14, 1996                   [Page 7]
  414.  
  415.  
  416.  
  417.  
  418.  
  419. INTERNET DRAFT                                            September 1996
  420.  
  421.  
  422.       DES_Key_R is the DES key for traffic from the responder -> initia-
  423.       tor.
  424.  
  425.       HMAC_Key_I is the key for the HMAC Algorithm for traffic from the
  426.       initiator -> responder.
  427.  
  428.       HMAC_Key_R is the key for the HMAC Algorithm for traffic from the
  429.       responder -> initiator.
  430.  
  431.       IV_key_I is used to stop code book attacks on the first block for
  432.       traffic from the initiator -> responder.
  433.  
  434.       IV_key_R is used to stop code book attacks on the first block for
  435.       traffic from the responder -> initiator.
  436.  
  437.       RP_key_I is the initial value and wrap point for the replay
  438.       prevention field for traffic from the initiator -> responder.
  439.  
  440.       RP_key_R is the initial value and wrap point for the replay
  441.       prevention field for traffic from the responder -> initiator.
  442.  
  443.    The vertical bar symbol "|" is used to denote concatenation of bit
  444.    strings.
  445.  
  446.    MD5(x|y) denotes the result of applying the MD5 function to the con-
  447.    catenated bit strings x and y.
  448.  
  449.    Truncate(x,n) denotes the result of truncating x to its first n bits.
  450.  
  451.  
  452.  
  453.  
  454.  
  455.  
  456.  
  457.  
  458.  
  459.  
  460.  
  461.  
  462.  
  463.  
  464.  
  465.  
  466.  
  467.  
  468.  
  469.  
  470.  
  471.  
  472.  
  473. Hughes                     September 14, 1996                   [Page 8]
  474.  
  475.  
  476.  
  477.  
  478.  
  479. INTERNET DRAFT                                            September 1996
  480.  
  481.  
  482.        DES_Key_I  = Truncate(MD5( D_Pad_I | K ),64)
  483.        DES_Key_R  = Truncate(MD5( D_Pad_R | K ),64)
  484.         IV_Key_I  = Truncate(MD5( I_Pad_I | K ),64)
  485.         IV_Key_R  = Truncate(MD5( I_Pad_R | K ),64)
  486.       HMAC_Key_I  =          MD5( H_Pad_I | K )
  487.       HMAC_Key_R  =          MD5( H_Pad_R | K )
  488.         RP_Key_I  = Truncate(MD5( R_Pad_I | K ),32)
  489.         RP_Key_R  = Truncate(MD5( R_Pad_R | K ),32)
  490.  
  491.  
  492.    where each _Pad_is 512 bit string.
  493.  
  494.       D_Pad_I = 0x5C repeated 64 times.
  495.       D_Pad_R = 0x3A repeated 64 times.
  496.       I_Pad_I = 0xAC repeated 64 times.
  497.       I_Pad_R = 0x55 repeated 64 times.
  498.       H_Pad_I = 0x53 repeated 64 times.
  499.       H_Pad_R = 0x3C repeated 64 times.
  500.       R_Pad_I = 0x35 repeated 64 times.
  501.       R_Pad_R = 0xCC repeated 64 times.
  502.  
  503.  
  504.    (Implementation note, The 16 byte intermediate residuals can be  pre-
  505.    calculated from these constants and stored to reduce processing over-
  506.    head).
  507.  
  508. 6.  Security Considerations
  509.  
  510.    The ESP-DES-HMAC-RP transform described in this draft is immune to
  511.    the [Bellovin96] attacks. (AH [RFC-1826], in some modes, can also
  512.    provide immunity to these attack.)
  513.  
  514.    The implications of the size of K can be found in [Blaze96].
  515.  
  516. 7.  References
  517.  
  518.    [Bellovin96] Bellovin, S., "Problem Areas for the IP Security Proto-
  519.    cols", AT&T Research, ftp://ftp.research.att.com/dist/smb/badesp.ps,
  520.    July, 1996.
  521.  
  522.    [FIPS-46] US National Bureau of Standards, "Data Encryption Stan-
  523.    dard", Federal Information Processing Standard (FIPS) Publication 46,
  524.    January 1977.
  525.  
  526.  
  527.  
  528.  
  529.  
  530.  
  531.  
  532.  
  533. Hughes                     September 14, 1996                   [Page 9]
  534.  
  535.  
  536.  
  537.  
  538.  
  539. INTERNET DRAFT                                            September 1996
  540.  
  541.  
  542.    [FIPS-46-1] US National Bureau of Standards, "Data Encryption Stan-
  543.    dard", Federal Information Processing Standard (FIPS) Publication
  544.    46-1, January 1988.
  545.  
  546.    [FIPS-74] US National Bureau of Standards, "Guidelines for Implement-
  547.    ing and Using the Data Encryption Standard", Federal Information Pro-
  548.    cessing Standard (FIPS) Publication 74, April 1981.
  549.  
  550.    [FIPS-81] US National Bureau of Standards, "DES Modes of Operation"
  551.    Federal Information Processing Standard (FIPS) Publication 81,
  552.    December 1980.
  553.  
  554.    [Krawczyk96] Krawczyk, H., Bellare, M., Canetti, R., "HMAC-MD5:
  555.    Keyed-MD5 for Message Authentication", work-in-progress,
  556.    http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ipsec-
  557.    hmac-md5-00.txt, March, 1996
  558.  
  559.    [Maughan96] Maughan, D., Schertler, M. Internet Security Association
  560.    and Key Management Protocol (ISAKMP), work-in-progress,
  561.    http://info.internet.isi.edu:80/in-drafts/files/draft-ietf-ipsec-
  562.    isakmp-04.txt, February, 1996
  563.  
  564.    [Orman96] Orman, H., "The Oakley Key Determination Protocol", work-
  565.    in-progress, http://info.internet.isi.edu:80/in-drafts/files/draft-
  566.    ietf-ipsec-oakley-00.txt, February, 1996.
  567.  
  568.    [RFC-1825] Atkinson, R, "Security Architecture for the Internet Pro-
  569.    tocol", ftp://ds.internic.net/rfc/rfc1825.txt, August 1995.
  570.  
  571.    [RFC-1826] Atkinson, R, "IP Authentication Header",
  572.    ftp://ds.internic.net/rfc/rfc1826.txt, August 1995.
  573.  
  574.    [Schneier95] Schneier, B., "Applied Cryptography Second Edition",
  575.    John Wiley & Sons, New York, NY, 1995.  ISBN 0-471-12845-7
  576.  
  577.    [Blaze96] Blaze M., Diffie, W., Rivest, R., Schneier, B., Shimomura,
  578.    T., Thompson, E., Wiener, M., "Minimal Key Lengths for Symmetric
  579.    Ciphers to Provide Adequate Commercial Security",
  580.    http://theory.lcs.mit.edu/~rivest/bsa-final-report.ascii, January,
  581.    1996
  582.  
  583.    [IB93] John Ioannidis and Matt Blaze, "Architecture and Implementa-
  584.    tion of Network-layer Security Under Unix", Proceedings of USENIX
  585.    Security Symposium, Santa Clara, CA, October 1993.
  586.  
  587.  
  588.  
  589.  
  590.  
  591.  
  592.  
  593. Hughes                     September 14, 1996                  [Page 10]
  594.  
  595.  
  596.  
  597.  
  598.  
  599. INTERNET DRAFT                                            September 1996
  600.  
  601.  
  602.    [IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network-
  603.    Layer Security for IP", presentation at the Spring 1993 IETF Meeting,
  604.    Columbus, Ohio.
  605.  
  606. 8.  Acknowledgements
  607.  
  608.    This document is the result of significant work by several major con-
  609.    tributors. They include (in alphabetical order):
  610.  
  611.         Robert W. Baldwin
  612.         <baldwin@rsa.com>
  613.         RSA Labs.
  614.  
  615.         Kevin Kingdon
  616.         <kevin@rsa.com>
  617.         RSA Labs
  618.  
  619.         Hugo Krawczyk
  620.         <hugo@watson.ibm.com>
  621.         IBM Corporation
  622.  
  623.         Perry Metzger
  624.         <perry@piermont.com>
  625.         Piermont Information Services
  626.  
  627.         Phil Rogaway
  628.         <rogaway@cs.ucdavis.edu>
  629.         University of California at Davis
  630.  
  631.         Bill Simpson
  632.         <bill.simpson@um.cc.umich.edu>
  633.         Computer Systems Consulting Services
  634.  
  635.         David A Wagner
  636.         <daw@cs.berkeley.edu>
  637.         University of California at Berkeley
  638.  
  639.  
  640.    In addition, the contributions of the entire IPSEC Working Group  are
  641.    acknowledged.  Additional  thanks for finding the missing "l"s in the
  642.    window code to:
  643.  
  644.  
  645.         Anton Elin
  646.         <ant@ankey.ru>
  647.         Ankey Engineering
  648.  
  649.  
  650.  
  651.  
  652.  
  653. Hughes                     September 14, 1996                  [Page 11]
  654.  
  655.  
  656.  
  657.  
  658.  
  659. INTERNET DRAFT                                            September 1996
  660.  
  661.  
  662.  
  663.    The IPsec working group can be contacted through the chairs:
  664.  
  665.         Ran Atkinson
  666.         <rja@cisco.com>
  667.         Cisco Systems
  668.  
  669.         Paul Lambert
  670.         <PALAMBER@us.oracle.com>
  671.         Oracle Corporation
  672.  
  673.  
  674. 9.  Editor's Address
  675.  
  676.         James P. Hughes
  677.         <hughes@network.com>
  678.         Network Systems Corporation
  679.  
  680.  
  681.  
  682.  
  683.  
  684.  
  685.  
  686.  
  687.  
  688.  
  689.  
  690.  
  691.  
  692.  
  693.  
  694.  
  695.  
  696.  
  697.  
  698.  
  699.  
  700.  
  701.  
  702.  
  703.  
  704.  
  705.  
  706.  
  707.  
  708.  
  709.  
  710.  
  711.  
  712.  
  713. Hughes                     September 14, 1996                  [Page 12]
  714.  
  715.  
  716.  
  717.  
  718.  
  719. INTERNET DRAFT                                            September 1996
  720.  
  721.  
  722. Appendix A
  723.  
  724.    This is a routine that implements a 32 packet window. This is intend-
  725.    ed on being an implementation sample.
  726.  
  727.    #include <stdio.h>
  728.    #include <stdlib.h>
  729.    typedef unsigned long u_long;
  730.  
  731.    enum {
  732.        ReplayWindowSize = 32
  733.    };
  734.  
  735.    u_long bitmap = 0;          /* session state - must be 32 bits */
  736.    u_long lastSeq = 0;         /* session state */
  737.  
  738.    /* Returns 0 if packet disallowed, 1 if packet permitted */
  739.    int ChkReplayWindow(u_long seq);
  740.  
  741.    int ChkReplayWindow(u_long seq) {
  742.        u_long diff;
  743.  
  744.        if (seq == 0) return 0; /* first == 0 or wrapped */
  745.        if (seq > lastSeq) {    /* new larger sequence number */
  746.            diff = seq - lastSeq;
  747.            if (diff < ReplayWindowSize) { /* In window */
  748.                bitmap = (bitmap << diff) | 1; /* set bit for this packet */
  749.            } else bitmap = 1;  /* This packet has a "way larger" */
  750.            lastSeq = seq;
  751.            return 1;           /* larger is good */
  752.        }
  753.        diff = lastSeq - seq;
  754.        if (diff >= ReplayWindowSize) return 0; /* too old or wrapped */
  755.        if (bitmap & (1l << diff)) return 0; /* this packet already seen */
  756.        bitmap |= (1l << diff);  /* mark as seen */
  757.        return 1;               /* out of order but good */
  758.    }
  759.  
  760.  
  761.  
  762.  
  763.  
  764.  
  765.  
  766.  
  767.  
  768.  
  769.  
  770.  
  771.  
  772.  
  773. Hughes                     September 14, 1996                  [Page 13]
  774.  
  775.  
  776.  
  777.  
  778.  
  779. INTERNET DRAFT                                            September 1996
  780.  
  781.  
  782. char string_buffer[512];
  783. #define STRING_BUFFER_SIZE sizeof(string_buffer)
  784.  
  785. int main() {
  786.     int result;
  787.     u_long last, current, bits;
  788.  
  789.     printf("Input initial state (bits in hex, last msgnum):\n");
  790.     if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) exit(0);
  791.     sscanf(string_buffer, "%lx %lu", &bits, &last);
  792.     if (last != 0)
  793.     bits |= 1;
  794.     bitmap = bits;
  795.     lastSeq = last;
  796.     printf("bits:%08lx last:%lu\n", bitmap, lastSeq);
  797.     printf("Input value to test (current):\n");
  798.  
  799.     while (1) {
  800.         if (!fgets(string_buffer, STRING_BUFFER_SIZE, stdin)) break;
  801.         sscanf(string_buffer, "%lu", ¤t);
  802.         result = ChkReplayWindow(current);
  803.         printf("%-3s", result ? "OK" : "BAD");
  804.         printf(" bits:%08lx last:%lu\n", bitmap, lastSeq);
  805.     }
  806.     return 0;
  807. }
  808.  
  809.  
  810.  
  811.  
  812.  
  813.  
  814.  
  815.  
  816.  
  817.  
  818.  
  819.  
  820.  
  821.  
  822.  
  823.  
  824.  
  825.  
  826.  
  827.  
  828.  
  829.  
  830.  
  831.  
  832.  
  833. Hughes                     September 14, 1996                  [Page 14]
  834.  
  835.  
  836.  
  837.