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-auth-header-01.txt < prev    next >
Text File  |  1997-07-22  |  50KB  |  1,234 lines
  1.  
  2. Network Working Group                             Stephen Kent, BBN Corp
  3. Internet Draft                           Randall Atkinson, @Home Network
  4. draft-ietf-ipsec-auth-header-01.txt                         July 21 1997
  5.  
  6.  
  7.  
  8.  
  9.  
  10.                         IP Authentication Header
  11.  
  12.  
  13.  
  14.  
  15. Status of This Memo
  16.  
  17.    This document is an Internet Draft. Internet Drafts are working
  18.    documents of the Internet Engineering Task Force (IETF), its Areas,
  19.    and its Working Groups. Note that other groups may also distribute
  20.    working documents as Internet Drafts.
  21.  
  22.    Internet Drafts are draft documents valid for a maximum of 6 months.
  23.    Internet Drafts may be updated, replaced, or obsoleted by other
  24.    documents at any time. It is not appropriate to use Internet Drafts
  25.    as reference material or to cite them other than as a "working draft"
  26.    or "work in progress". Please check the I-D abstract listing
  27.    contained in each Internet Draft directory to learn the current
  28.    status of this or any other Internet Draft.
  29.  
  30.    This particular Internet Draft is a product of the IETF's IPsec
  31.    Working Group. It is intended that a future version of this draft
  32.    will be submitted for consideration as a standards-track document.
  33.    Distribution of this document is unlimited.
  34.  
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57. Kent, Atkinson                                                  [Page 1]
  58.  
  59.  
  60. Internet Draft          IP Authentication Header           21 July, 1997
  61.  
  62.  
  63. Table of Contents
  64.  
  65.    1. Introduction......................................................3
  66.    2. Authentication Header Format......................................4
  67.       2.1 Next Header...................................................4
  68.       2.2 Payload Length................................................4
  69.       2.3 Reserved......................................................5
  70.       2.4 Security Parameters Index (SPI)...............................5
  71.       2.5 Sequence Number...............................................5
  72.       2.6 Authentication Data ..........................................5
  73.    3. Authentication Header Processing..................................6
  74.       3.1  Authentication Header Location...............................6
  75.       3.2  Outbound Packet Processing...................................8
  76.          3.2.1  Security Association Lookup.............................8
  77.          3.2.2  Sequence Number Generation..............................8
  78.          3.2.3  Integrity Check Value Calculation.......................9
  79.             3.2.3.1  Handling Mutable Fields............................9
  80.                3.2.3.1.1  ICV Computation for IPv4......................9
  81.                   3.2.3.1.1.1 Base Header Fields........................9
  82.                   3.2.3.1.1.2 Options..................................10
  83.                3.2.3.1.2  ICV Computation for IPv6.....................10
  84.                   3.2.3.1.2.1 Base Header Fields.......................10
  85.                   3.2.3.1.2.2 Extension Headers -- Options.............11
  86.                   3.2.3.1.2.3 Extension Headers -- non-Options.........11
  87.             3.2.3.2  Padding...........................................11
  88.                3.2.3.2.1  Authentication Data Padding..................11
  89.                3.2.3.2.2  Implicit Packet Padding......................12
  90.             3.2.3.3  Authentication Algorithms.........................12
  91.          3.2.4  Fragmentation..........................................12
  92.       3.3  Inbound Packet Processing...................................13
  93.          3.3.1  Reassembly.............................................13
  94.          3.3.2  Security Association Lookup............................13
  95.          3.3.3  Sequence Number Verification...........................13
  96.          3.3.4  Integrity Check Value Verification.....................14
  97.    4. Auditing.........................................................15
  98.    5. Conformance Requirements.........................................15
  99.    6. Security Considerations..........................................16
  100.    7. Differences from RFC 1826........................................16
  101.    Acknowledgements....................................................17
  102.    Appendix A -- Mutability of IP Options/Extension Headers............18
  103.       1. IPv4 Options..................................................18
  104.       2. IPv6 Extension Headers........................................19
  105.    References..........................................................21
  106.    Disclaimer..........................................................22
  107.    Author Information..................................................22
  108.  
  109.  
  110.  
  111.  
  112.  
  113. Kent, Atkinson                                                  [Page 2]
  114.  
  115.  
  116. Internet Draft          IP Authentication Header           21 July, 1997
  117.  
  118.  
  119. 1. Introduction
  120.  
  121.    The IP Authentication Header (AH) is used to provide connectionless
  122.    integrity and data origin authentication for IP datagrams (hereafter
  123.    referred to as just "authentication"), and to provide protection
  124.    against replays.  This latter, optional service may be selected, by
  125.    the receiver, when a Security Association is established.  AH
  126.    provides authentication for as much of the IP header as possible, as
  127.    well as for upper level protocol data.  However, some IP header
  128.    fields may change in transit and the value of these fields, when the
  129.    packet arrives at the receiver, may not be predictable by the
  130.    transmitter.  The values of such fields cannot be protected by AH.
  131.    Thus the protection provided to the IP header by AH is somewhat
  132.    piecemeal.
  133.  
  134.    AH may be applied alone, in combination with the IP Encapsulating
  135.    Security Payload (ESP) [KA97b], or in a nested fashion through the
  136.    use of tunnel mode (see "Security Architecture for the Internet
  137.    Protocol" [KA97a], hereafter referred to as the Security Architecture
  138.    document).  Security services can be provided between a pair of
  139.    communicating hosts, between a pair of communicating security
  140.    gateways, or between a security gateway and a host.  ESP may be used
  141.    to provide the same security services, and it also provides a
  142.    confidentiality (encryption) service.  The primary difference between
  143.    the authentication provided by ESP and AH is the extent of the
  144.    coverage.  Specifically, ESP does not protect any IP header fields
  145.    unless those fields are encapsulated by ESP (tunnel mode).  For more
  146.    details on how to use AH and ESP in various network environments, see
  147.    the Security Architecture document [KA97a].
  148.  
  149.    It is assumed that the reader is familiar with the terms and concepts
  150.    described in the Security Architecture document.  In particular, the
  151.    reader should be familiar with the definitions of security services
  152.    offered by AH and ESP, the concept of Security Associations, the ways
  153.    in which AH can be used in conjunction with ESP, and the different
  154.    key management options available for AH and ESP.  (With regard to the
  155.    last topic, the current key management options required for both AH
  156.    and ESP are manual keying and automated keying via Oakley/ISAKMP.)
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169. Kent, Atkinson                                                  [Page 3]
  170.  
  171.  
  172. Internet Draft          IP Authentication Header           21 July, 1997
  173.  
  174.  
  175. 2.  Authentication Header Format
  176.  
  177.    The protocol header (IPv4, IPv6, or Extension) immediately preceding the
  178.    AH header will contain the value 51 in its Protocol (IPv4) or Next
  179.    Header (IPv6, Extension) field [STD-2].
  180.  
  181.     0                   1                   2                   3
  182.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  183.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  184.    | Next Header   |  Payload Len  |          RESERVED             |
  185.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  186.    |                 Security Parameters Index (SPI)               |
  187.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  188.    |                    Sequence Number Field                      |
  189.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  190.    |                                                               |
  191.    +                Authentication Data (variable)                 |
  192.    |                                                               |
  193.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  194.  
  195.  
  196.    The following subsections define the fields that comprise the AH
  197.    format.  All the fields described here are mandatory, i.e., they are
  198.    always present in the AH format and are included in the ICV
  199.    computation.
  200.  
  201. 2.1 Next Header
  202.  
  203.    The Next Header is an 8-bit field that identifies the type of the
  204.    next payload after the Authentication Header.  The value of this
  205.    field is chosen from the set of IP Protocol Numbers defined in the
  206.    most recent "Assigned Numbers" [STD-2] RFC from the Internet Assigned
  207.    Numbers Authority (IANA).
  208.  
  209. 2.2 Payload Length
  210.  
  211.    This 8-bit field specifies the length of AH, in 32-bit words (4-byte
  212.    units), minus "2," i.e., the fixed portion (as defined in the
  213.    original AH spec) of AH is not counted.  (Since the Sequence Number
  214.    field is always present, the fixed portion of AH is now three 32-bit
  215.    words.  However, the "minus 2" length adjustment has been retained
  216.    for backwards compatibility.)  In the "standard" case of a 96-bit
  217.    authentication value plus the 3 32-bit word fixed portion, this
  218.    length field will be "4".  A "null" authentication algorithm may be
  219.    used only for debugging purposes.  Its use would result in a "1"
  220.    value for this field, as there would be no corresponding
  221.    Authentication Data field.
  222.  
  223.  
  224.  
  225. Kent, Atkinson                                                  [Page 4]
  226.  
  227.  
  228. Internet Draft          IP Authentication Header           21 July, 1997
  229.  
  230.  
  231. 2.3 Reserved
  232.  
  233.    This 16-bit field is reserved for future use.  It MUST be set to
  234.    "zero." (Note that the value is included in the Authentication Data
  235.    calculation, but is otherwise ignored by the recipient.)
  236.  
  237. 2.4 Security Parameters Index (SPI)
  238.  
  239.    The SPI is an arbitrary 32-bit value that uniquely identifies the
  240.    Security Association for this datagram, relative to the destination
  241.    IP address contained in the IP header with which this security header
  242.    is associated, and relative to the security protocol employed.  The
  243.    set of SPI values in the range 1 through 255 are reserved by the
  244.    Internet Assigned Numbers Authority (IANA) for future use; a reserved
  245.    SPI value will not normally be assigned by IANA unless the use of the
  246.    assigned SPI value is specified in an RFC.  It is ordinarily selected
  247.    by the destination system upon establishment of an SA (see the
  248.    Security Architecture document for more details).  (A zero value may
  249.    be used for local debugging purposes, but no AH packets should be
  250.    transmitted with a zero SPI value.)
  251.  
  252. 2.5 Sequence Number
  253.  
  254.    This unsigned 32-bit field contains a monotonically increasing
  255.    counter value (sequence number).  The sender's counter and the
  256.    receiver's counter are initialized to 0 when an SA is established.
  257.    (The first packet sent using a given SA will have a Sequence Number
  258.    of 1; see Section 3.2.2 for more details on how the Sequence Number
  259.    is generated.) The transmitted Sequence Number must never be allowed
  260.    to cycle.  Thus the sender's counter and the receiver's counter MUST
  261.    be reset (by establishing a new SA and thus a new key) prior to the
  262.    transmission of 2^32nd packet on an SA.
  263.  
  264.    This field is always present, even if the receiver does not elect to
  265.    enable the anti-replay service for a specific SA, in order to ensure
  266.    8-byte alignment for the IPv6 environment, when the default integrity
  267.    algorithms are employed.
  268.  
  269.    Processing of the Sequence Number field is at the discretion of the
  270.    receiver, i.e., the sender MUST always transmit this field, but the
  271.    receiver need not act upon it (see the discussion of Sequence Number
  272.    Verification in the "Inbound Processing" section below).
  273.  
  274. 2.6 Authentication Data
  275.  
  276.    This is a variable-length field that contains the Integrity Check
  277.    Value (ICV) for this packet.  The field must be an integral multiple
  278.    of 32 bits in length.  The details of the ICV computation are
  279.  
  280.  
  281. Kent, Atkinson                                                  [Page 5]
  282.  
  283.  
  284. Internet Draft          IP Authentication Header           21 July, 1997
  285.  
  286.  
  287.    described in Section 3.2.3 below.  This field may include explicit
  288.    padding.  This padding is included to ensure that the length of the
  289.    AH header is an integral multiple of 32 bits (IPv4) or 64 bits
  290.    (IPv6).  All implementations MUST support such padding.  Details of
  291.    how to compute the required padding length are provided below.
  292.  
  293. 3. Authentication Header Processing
  294.  
  295. 3.1 Authentication Header Location
  296.  
  297.    Like ESP, AH may be employed in two ways: transport mode or tunnel
  298.    mode.  The former mode is applicable only to host implementations and
  299.    provides protection for upper layer protocols, in addition to
  300.    selected IP header fields.  (In this mode, note that for "bump-in-
  301.    the-stack" or "bump-in-the-wire" implementations, as defined in the
  302.    Security Architecture document, inbound and outbound IP fragments may
  303.    require an IPsec implementation to perform extra IP
  304.    reassembly/fragmentation in order to both conform to this
  305.    specification and provide transparent IPsec support.  Special care is
  306.    required to perform such operations within these implementations when
  307.    multiple interfaces are in use.)
  308.  
  309.    In transport mode, AH is inserted after the IP header and before an
  310.    upper layer protocol, e.g., TCP, UDP, ICMP, etc. or before any other
  311.    IPsec headers that have already been inserted, e.g., ESP.  In the
  312.    context of IPv4, this calls for placing AH after the IP header (and
  313.    any options that it contains), but before the upper layer protocol.
  314.    (Note that the term "transport" mode should not be misconstrued as
  315.    restricting its use to TCP and UDP.  For example, an ICMP message MAY
  316.    be sent using either "transport" mode or "tunnel" mode.)  The
  317.    following diagram illustrates AH transport mode positioning for a
  318.    typical IPv4 packet, on a "before and after" basis.
  319.  
  320.                   BEFORE APPLYING AH
  321.             ----------------------------
  322.       IPv4  |orig IP hdr  |     |      |
  323.             |(any options)| TCP | Data |
  324.             ----------------------------
  325.  
  326.                   AFTER APPLYING AH
  327.             ---------------------------------
  328.       IPv4  |orig IP hdr  |    |     |      |
  329.             |(any options)| AH | TCP | Data |
  330.             ---------------------------------
  331.             |<------- authenticated ------->|
  332.                  except for mutable fields
  333.  
  334.    In the IPv6 context, AH is viewed as an end-to-end payload, and thus
  335.  
  336.  
  337. Kent, Atkinson                                                  [Page 6]
  338.  
  339.  
  340. Internet Draft          IP Authentication Header           21 July, 1997
  341.  
  342.  
  343.    should appear after hop-by-hop, routing, and fragmentation extension
  344.    headers.  The destination options extension header(s) could appear
  345.    either before or after the AH header depending on the semantics
  346.    desired.  The following diagram illustrates AH transport mode
  347.    positioning for a typical IPv6 packet.
  348.  
  349.                        BEFORE APPLYING AH
  350.             ---------------------------------------
  351.       IPv6  |             | ext hdrs |     |      |
  352.             | orig IP hdr |if present| TCP | Data |
  353.             ---------------------------------------
  354.  
  355.                        AFTER APPLYING AH
  356.             ------------------------------------------------------------
  357.       IPv6  |             |hxh,rtg,frag| dest |    | dest |     |      |
  358.             |orig IP hdr  |if present**| opt* | AH | opt* | TCP | Data |
  359.             ------------------------------------------------------------
  360.             |<---- authenticated except for mutable fields ----------->|
  361.  
  362.                 * = if present, could be before AH, after AH, or both
  363.                ** = hop by hop, routing, fragmentation headers
  364.  
  365.    Tunnel mode AH may be employed in either hosts or security gateways
  366.    (or in so-called "bump-in-the-stack" or "bump-in-the-wire"
  367.    implementations, as defined in the Security Architecture document).
  368.    When AH is implemented in a security gateway (to protect subscriber
  369.    transit traffic), tunnel mode must be used.  In tunnel mode, the
  370.    "inner" IP header carries the ultimate source and destination
  371.    addresses, while an "outer" IP header may contain distinct IP
  372.    addresses, e.g., addresses of security gateways.  In tunnel mode, AH
  373.    protects the entire inner IP packet, including the entire inner IP
  374.    header. The position of AH in tunnel mode, relative to the outer IP
  375.    header, is the same as for AH in transport mode.  The following
  376.    diagram illustrates AH tunnel mode positioning for typical IPv4 and
  377.    IPv6 packets.
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393. Kent, Atkinson                                                  [Page 7]
  394.  
  395.  
  396. Internet Draft          IP Authentication Header           21 July, 1997
  397.  
  398.  
  399.             ------------------------------------------------
  400.       IPv4  | new IP hdr* |    | orig IP hdr*  |    |      |
  401.             |(any options)| AH | (any options) |TCP | Data |
  402.             ------------------------------------------------
  403.             |<-- authenticated except for mutable fields ->|
  404.  
  405.             --------------------------------------------------------------
  406.       IPv6  |           | ext hdrs*|    |            | ext hdrs*|   |    |
  407.             |new IP hdr*|if present| AH |orig IP hdr*|if present|TCP|Data|
  408.             --------------------------------------------------------------
  409.             |<-------- authenticated except for mutable fields --------->|
  410.  
  411.              * = construction of outer IP hdr/extensions and modification
  412.                  of inner IP hdr/extensions is discussed below.
  413.  
  414. 3.2  Outbound Packet Processing
  415.  
  416.    In transport mode, the transmitter inserts the AH header after the IP
  417.    header and before an upper layer protocol header, as described above.
  418.    In tunnel mode, the outer and inner IP header/extensions can be
  419.    inter-related in a variety of ways.  The construction of the outer IP
  420.    header/extensions during the encapsulation process is described in
  421.    the Security Architecture document.
  422.  
  423. 3.2.1  Security Association Lookup
  424.  
  425.    AH is applied to an outbound packet only after an IPsec
  426.    implementation determines that the packet is associated with an SA
  427.    that calls for AH processing.  The process of determining what, if
  428.    any, IPsec processing is applied to outbound traffic is described in
  429.    the Security Architecture document.
  430.  
  431. 3.2.2  Sequence Number Generation
  432.  
  433.    The sender's counter is initialized to 0 when an SA is established.
  434.    The transmitter increments the Sequence Number for this SA, checks to
  435.    ensure that the counter has not cycled, and inserts the new value
  436.    into the Sequence Number Field.  Thus the first packet sent using a
  437.    given SA will have a Sequence Number of 1.  A transmitter MUST not
  438.    send a packet on an SA if doing so would cause the sequence number to
  439.    cycle.  An attempt to transmit a packet that would result in sequence
  440.    number overflow is an auditable event.  (Note that this approach to
  441.    Sequence Number management does not require use of modular
  442.    arithmetic.)
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449. Kent, Atkinson                                                  [Page 8]
  450.  
  451.  
  452. Internet Draft          IP Authentication Header           21 July, 1997
  453.  
  454.  
  455. 3.2.3  Integrity Check Value Calculation
  456.  
  457. 3.2.3.1  Handling Mutable Fields
  458.  
  459.    The AH ICV is computed over IP header fields that are either
  460.    immutable in transit or that are predictable in value upon arrival at
  461.    the endpoint for the AH SA.  The ICV also encompasses the upper level
  462.    protocol data, which is assumed to be immutable in transit.  If a
  463.    field may be modified during transit, the value of the field is set
  464.    to zero for purposes of the ICV computation.  If a field is mutable,
  465.    but its value at the (IPsec) receiver is predictable, then that value
  466.    is inserted into the field for purposes of the ICV calculation.  The
  467.    Authentication Data field also is set to zero in preparation for this
  468.    computation.  Note that by replacing each field's value with zero,
  469.    rather than omitting the field, alignment is preserved for the ICV
  470.    calculation.  Also, the zero-fill approach ensures that the length of
  471.    the fields that are so handled cannot be changed during transit, even
  472.    though their contents are not explicitly covered by the ICV.
  473.  
  474.    As a new extension header or IPv4 option is created, it will be
  475.    defined in its own RFC and SHOULD include (in the Security
  476.    Considerations section) directions for how it should be handled when
  477.    calculating the AH ICV.  If the IPSEC implementation encounters an
  478.    extension header that it does not recognize, it MUST zero the whole
  479.    header except for the Next Header and Hdr Ext Len fields.  The length
  480.    of the extension header MUST be computed by 8 * Hdr Ext Len value +
  481.    8.  If the IPSEC implementation encounters an IPv4 option that it
  482.    does not recognize, it should zero the whole option, using the second
  483.    byte of the option as the length.  (IPv6 options contain a flag
  484.    indicating mutability, which determines appropriate processing for
  485.    such options.)
  486.  
  487. 3.2.3.1.1  ICV Computation for IPv4
  488.  
  489. 3.2.3.1.1.1 Base Header Fields
  490.  
  491.    The IPv4 base header fields are classified as follows:
  492.  
  493.    Immutable
  494.              Version
  495.              Internet Header Length
  496.              Total Length
  497.              Identification
  498.              Protocol
  499.              Source Address
  500.              Destination Address (without loose or strict source routing)
  501.  
  502.  
  503.  
  504.  
  505. Kent, Atkinson                                                  [Page 9]
  506.  
  507.  
  508. Internet Draft          IP Authentication Header           21 July, 1997
  509.  
  510.  
  511.    Mutable but predictable
  512.              Destination Address (with loose or strict source routing)
  513.  
  514.    Mutable (zeroed prior to ICV calculation)
  515.              Type of Service (TOS)
  516.              Flags
  517.              Fragment Offset
  518.              Time to Live (TTL)
  519.              Header Checksum
  520.  
  521.       TOS -- This field is excluded because some routers are known to
  522.              change the value of this field, even though the IP specification
  523.              does not consider TOS to be a mutable header field.
  524.  
  525.       Flags -- This field is excluded since an intermediate router might
  526.              set the DF bit, even if the source did not select it.
  527.  
  528.       Fragment Offset -- Since AH is applied only to non-fragmented IP
  529.              packets, the Offset Field must always be zero, and thus it is
  530.              excluded (even though it is predictable).
  531.  
  532.       TTL -- This is changed en-route as a normal course of processing by
  533.              routers, and thus its value at the receiver is not predictable
  534.              by the sender.
  535.  
  536.       Header Checksum -- This will change if any of these other fields
  537.              changes, and thus its value upon reception cannot be predicted
  538.              by the sender.
  539.  
  540. 3.2.3.1.1.2 Options
  541.  
  542.    For IPv4 (unlike IPv6), there is no mechanism for tagging options as
  543.    mutable in transit.  Hence the IPv4 options are explicitly listed in
  544.    Appendix A and classified as immutable, mutable but predictable, or
  545.    mutable.  For IPv4, the entire option is viewed as a unit; so even
  546.    though the type and length fields within most options are immutable
  547.    in transit, if an option is classified as mutable, the entire option
  548.    is zeroed for ICV computation purposes.
  549.  
  550. 3.2.3.1.2  ICV Computation for IPv6
  551.  
  552. 3.2.3.1.2.1 Base Header Fields
  553.  
  554.    The IPv6 base header fields are classified as follows:
  555.  
  556.  
  557.  
  558.  
  559.  
  560.  
  561. Kent, Atkinson                                                 [Page 10]
  562.  
  563.  
  564. Internet Draft          IP Authentication Header           21 July, 1997
  565.  
  566.  
  567.    Immutable
  568.              Version
  569.              Payload Length
  570.              Next Header
  571.              Source Address
  572.              Destination Address (without Routing Extension Header)
  573.  
  574.    Mutable but predictable
  575.              Destination Address (with Routing Extension Header)
  576.  
  577.    Mutable (zeroed prior to ICV calculation)
  578.              Priority
  579.              Flow Label
  580.              Hop Limit
  581.  
  582. 3.2.3.1.2.2 Extension Headers -- Options
  583.  
  584.    The IPv6 extension headers (that are options) are explicitly listed
  585.    in Appendix A and classified as immutable, mutable but predictable,
  586.    or mutable.
  587.  
  588.    IPv6 options in the Hop-by-Hop and Destination Extension Headers
  589.    contain a bit that indicates whether the option might change
  590.    (unpredictably) during transit.  For any option for which contents
  591.    may change en-route, the entire "Option Data" field must be treated
  592.    as zero-valued octets when computing or verifying the ICV.  The
  593.    Option Type and Opt Data Len are included in the ICV calculation.
  594.    All options for which the bit indicates immutability are included in
  595.    the ICV calculation.  See the IPv6 specification [DH95] for more
  596.    information.
  597.  
  598. 3.2.3.1.2.3 Extension Headers -- non-Options
  599.  
  600.    The IPv6 extension headers (that are not options) are explicitly
  601.    listed in Appendix A and classified as immutable, mutable but
  602.    predictable, or mutable.
  603.  
  604. 3.2.3.2  Padding
  605.  
  606. 3.2.3.2.1  Authentication Data Padding
  607.  
  608.    As mentioned in section 2.6, the Authentication Data field explicitly
  609.    includes padding to ensure that the AH header is a multiple of 32
  610.    bits (IPv4) or 64 bits (IPv6).  If padding is required, its length is
  611.    determined by two factors:
  612.  
  613.              - the length of the ICV
  614.              - the IP protocol version (v4 or v6)
  615.  
  616.  
  617. Kent, Atkinson                                                 [Page 11]
  618.  
  619.  
  620. Internet Draft          IP Authentication Header           21 July, 1997
  621.  
  622.  
  623.  
  624.    For example, if a default, 96-bit truncated (see Section 3.2.3.3)
  625.    HMAC algorithm is selected no padding is required for either IPv4 nor
  626.    for IPv6.  However, if a different length ICV is generated, due to
  627.    use of a different algorithm, then padding may be required for the
  628.    IPv6 environment.  The content of the padding field is arbitrarily
  629.    selected by the sender.  (The padding is arbitrary, but need not be
  630.    random to achieve security.)  These padding bytes are included in the
  631.    Authentication Data calculation, counted as part of the Payload
  632.    Length, and transmitted at the end of the Authentication Data field
  633.    to enable the receiver to perform the ICV calculation.
  634.  
  635. 3.2.3.2.2 Implicit Packet Padding
  636.  
  637.    For some authentication algorithms, the byte string over which the
  638.    ICV computation is performed must be a multiple of a blocksize
  639.    specified by the algorithm.  If the IP packet length (including AH)
  640.    does not match the blocksize requirements for the algorithm, implicit
  641.    padding MUST be appended to the end of the packet, prior to ICV
  642.    computation.  The padding octets MUST have a value of zero.  The
  643.    blocksize (and hence the length of the padding) is specified by the
  644.    algorithm specification.  This padding is not transmitted with the
  645.    packet.
  646.  
  647. 3.2.3.3  Authentication Algorithms
  648.  
  649.    The authentication algorithm employed for the ICV computation is
  650.    specified by the SA.  For point-to-point communication, suitable
  651.    authentication algorithms include keyed Message Authentication Codes
  652.    (MACs) based on symmetric encryption algorithms (e.g., DES) or on
  653.    one-way hash functions (e.g., MD5 or SHA-1).  For multicast
  654.    communication, one-way hash algorithms combined with asymmetric
  655.    signature algorithms are appropriate, though performance and space
  656.    considerations currently preclude use of such algorithms.  As of this
  657.    writing, the mandatory-to-implement authentication algorithms are
  658.    based on the former class, i.e., HMAC [KBC97] with SHA-1 [SHA] or
  659.    HMAC with MD5 [Riv92].  The output of the HMAC computation is
  660.    truncated to the leftmost 96 bits.  Other algorithms, possibly with
  661.    different ICV lengths, MAY be supported.
  662.  
  663. 3.2.4  Fragmentation
  664.  
  665.    If required, IP fragmentation occurs after AH processing within an
  666.    IPsec implementation.  Thus, transport mode AH is applied only to
  667.    whole IP datagrams (not to IP fragments).  An IP packet to which AH
  668.    has been applied may itself be fragmented by routers en route, and
  669.    such fragments must be reassembled prior to AH processing at a
  670.    receiver.  In tunnel mode, AH is applied to an IP packet, the payload
  671.  
  672.  
  673. Kent, Atkinson                                                 [Page 12]
  674.  
  675.  
  676. Internet Draft          IP Authentication Header           21 July, 1997
  677.  
  678.  
  679.    of which may be a fragmented IP packet.  For example, a security
  680.    gateway or a "bump-in-the-stack" or "bump-in-the-wire" IPsec
  681.    implementation (see the Security Architecture document for details)
  682.    may apply tunnel mode AH to such fragments.
  683.  
  684. 3.3  Inbound Packet Processing
  685.  
  686. 3.3.1  Reassembly
  687.  
  688.    If required, reassembly is performed prior to AH processing.  If a
  689.    packet offered to AH for processing appears to be an IP fragment,
  690.    i.e., the OFFSET field is non-zero or the MORE FRAGMENTS flag is set,
  691.    the receiver MUST discard the packet; this is an auditable event. The
  692.    audit log entry for this event SHOULD include the SPI value,
  693.    date/time, Source Address, Destination Address, and (in IPv6) the
  694.    Flow ID.
  695.  
  696. 3.3.2  Security Association Lookup
  697.  
  698.    Upon receipt of a packet containing an IP Authentication Header, the
  699.    receiver determines the appropriate (unidirectional) SA, based on the
  700.    destination IP address and the SPI.  (This process is described in
  701.    more detail in the Security Architecture document.)  The SA dictates
  702.    whether the Sequence Number field will be checked, specifies the
  703.    algorithm(s) employed for ICV computation, and indicates the key(s)
  704.    required to validate the ICV.
  705.  
  706.    If no valid Security Association exists for this session (e.g., the
  707.    receiver has no key), the receiver MUST discard the packet; this is
  708.    an auditable event.  The audit log entry for this event SHOULD
  709.    include the SPI value, date/time, Source Address, Destination
  710.    Address, and (in IPv6) the Flow ID.
  711.  
  712. 3.3.3  Sequence Number Verification
  713.  
  714.    All AH implementations MUST support the anti-replay service, though
  715.    its use may be enabled or disabled on a per-SA basis.  (Note that
  716.    there are no provisions for managing transmitted Sequence Number
  717.    values among multiple senders directing traffic to a single,
  718.    multicast SA.  Thus the anti-replay service SHOULD NOT be used in a
  719.    multi-sender multicast environment that employs a single, multicast
  720.    SA.)  If an SA establishment protocol such as Oakley/ISAKMP is
  721.    employed, then the receiver SHOULD notify the transmitter, during SA
  722.    establishment, if the receiver will provide anti-replay protection
  723.    and SHOULD inform the transmitter of the window size.
  724.  
  725.    If the receiver has enabled the anti-replay service for this SA, the
  726.    receiver packet counter for the SA MUST be initialized to zero when
  727.  
  728.  
  729. Kent, Atkinson                                                 [Page 13]
  730.  
  731.  
  732. Internet Draft          IP Authentication Header           21 July, 1997
  733.  
  734.  
  735.    the SA is established.  For each received packet, the receiver MUST
  736.    verify that the packet contains a Sequence Number that does not
  737.    duplicate the Sequence Number of any other packets received during
  738.    the life of this SA.  This SHOULD be the first AH check applied to a
  739.    packet after it has been matched to an SA, to speed rejection of
  740.    duplicate packets.
  741.  
  742.    Duplicates are rejected through the use of a sliding receive window.
  743.    (How the window is implemented is a local matter, but the following
  744.    text describes the functionality that the implementation must
  745.    exhibit.)  A MINIMUM window size of 32 MUST be supported; but a
  746.    window size of 64 is preferred and SHOULD be employed as the default.
  747.    A window size of 64 or larger MAY be chosen by the receiver.  If a
  748.    larger window size is chosen, it MUST be a multiple of 32.  If any
  749.    window size other than the default of 64 is employed by the receiver,
  750.    it MUST be reported to the transmitter during SA negotiation.
  751.  
  752.    The "right" edge of the window represents the highest, validated
  753.    Sequence Number value received on this SA.  Packets that contain
  754.    Sequence Numbers lower than the "left" edge of the window are
  755.    rejected.  Packets falling within the window are checked against a
  756.    list of received packets within the window.  An efficient means for
  757.    performing this check, based on the use of a bit mask, is described
  758.    in the Security Architecture document.
  759.  
  760.    If the received packet falls within the window and is new, or if the
  761.    packet is to the right of the window, then the receiver proceeds to
  762.    ICV verification.  If the ICV validation fails, the receiver MUST
  763.    discard the received IP datagram as invalid; this is an auditable
  764.    event.  The audit log entry for this event SHOULD include the SPI
  765.    value, date/time, Source Address, Destination Address, the Sequence
  766.    Number, and (in IPv6) the Flow ID.  The receive window is updated
  767.    only if the ICV verification succeeds.
  768.  
  769.  
  770.    DISCUSSION:
  771.  
  772.       Note that if the packet is either inside the window and new, or is
  773.       outside the window on the "right" side, the receiver MUST
  774.       authenticate the packet before updating the Sequence Number window
  775.       data.
  776.  
  777. 3.3.4  Integrity Check Value Verification
  778.  
  779.    The receiver computes the ICV over the appropriate fields of the
  780.    packet, using the specified authentication algorithm, and verifies
  781.    that it is the same as the ICV included in the Authentication Data
  782.    field of the packet.  Details of the computation are provided below.
  783.  
  784.  
  785. Kent, Atkinson                                                 [Page 14]
  786.  
  787.  
  788. Internet Draft          IP Authentication Header           21 July, 1997
  789.  
  790.  
  791.    If the computed and received ICV's match, then the datagram is valid,
  792.    and it is accepted.  If the test fails, then the receiver MUST
  793.    discard the received IP datagram as invalid; this is an auditable
  794.    event.  The audit log entry SHOULD include the SPI value, date/time,
  795.    Source Address, Destination Address, and (in IPv6) the Flow ID.
  796.  
  797.    DISCUSSION:
  798.  
  799.       Begin by saving the ICV value and replacing it (but not any
  800.       Authentication Data padding) with zero.  Zero all other fields
  801.       that may have been modified during transit.  (See section 3.2.3.1
  802.       for a discussion of which fields are zeroed before performing the
  803.       ICV calculation.)  Check the overall length of the packet, and if
  804.       it requires implicit padding based on the requirements of the
  805.       authentication algorithm, append zero-filled bytes to the end of
  806.       the packet as required.  Now perform the ICV computation and
  807.       compare the result with the saved value.  (For the mandatory-to-
  808.       implement authentication algorithms, HMAC [KBC97] with SHA-1 [SHA]
  809.       or HMAC with MD5 [Riv92], the output of the HMAC computation is
  810.       truncated to the leftmost 96 bits.  Other algorithms may have
  811.       different ICV lengths.) (If a digital signature and one-way hash
  812.       are used for the ICV computation, the matching process is more
  813.       complex and will be described in the algorithm specification.)
  814.  
  815.  
  816. 4. Auditing
  817.  
  818.    Not all systems that implement AH will implement auditing.  However,
  819.    if AH is incorporated into a system that supports auditing, then the
  820.    AH implementation MUST also support auditing and MUST allow a system
  821.    administrator to enable or disable auditing for AH.  For the most
  822.    part, the granularity of auditing is a local matter.  However,
  823.    several auditable events are identified in this specification and for
  824.    each of these events a minimum set of information that SHOULD be
  825.    included in an audit log is defined.  Additional information also MAY
  826.    be included in the audit log for each of these events, and additional
  827.    events, not explicitly called out in this specification, also MAY
  828.    result in audit log entries.  There is no requirement for the
  829.    receiver to transmit any message to the purported transmitter in
  830.    response to the detection of an auditable event, because of the
  831.    potential to induce denial of service via such action.
  832.  
  833. 5. Conformance Requirements
  834.  
  835.    Implementations that claim conformance or compliance with this
  836.    specification MUST fully implement the AH syntax and processing
  837.    described here and MUST comply with all requirements of the Security
  838.    Architecture document.  If the key used to compute an ICV is manually
  839.  
  840.  
  841. Kent, Atkinson                                                 [Page 15]
  842.  
  843.  
  844. Internet Draft          IP Authentication Header           21 July, 1997
  845.  
  846.  
  847.    distributed, correct provision of the anti-replay service would
  848.    require correct maintenance of the counter state at the transmitter,
  849.    until the key is replaced, and there likely would be no automated
  850.    recovery provision if counter overflow were imminent.  Thus a
  851.    compliant implementation SHOULD NOT provide this service in
  852.    conjunction with SAs that are manually keyed.  A compliant AH
  853.    implementation MUST support the following mandatory-to-implement
  854.    algorithms (specified in [KBC97]):
  855.  
  856.              - HMAC with MD5
  857.              - HMAC with SHA-1
  858.  
  859. 6. Security Considerations
  860.  
  861.    Security is central to the design of this protocol, and these
  862.    security considerations permeate the specification.  Additional
  863.    security-relevant aspects of using the IPsec protocol are discussed
  864.    in the Security Architecture document.
  865.  
  866.  
  867. 7. Differences from RFC 1826
  868.  
  869.    This specification of AH differs from RFC 1826 [ATK95] in several
  870.    important respects, but the fundamental features of AH remain intact.
  871.    One goal of the revision of RFC 1826 was to provide a complete
  872.    framework for AH, with ancillary RFCs required only for algorithm
  873.    specification.  For example, the anti-replay service is now an
  874.    integral, mandatory part of AH, not a feature of a transform defined
  875.    in another RFC.  Carriage of a sequence number to support this
  876.    service is now required at all times, to meet IPv6 alignment
  877.    requirements (even when anti-replay is not enabled for an SA).  The
  878.    default algorithms required for interoperability have been changed to
  879.    HMAC with MD5 or SHA-1 (vs. keyed MD5), for security reasons.  The
  880.    list of IPv4 header fields excluded from the ICV computation has been
  881.    expanded to include the OFFSET and FLAGS fields.
  882.  
  883.    Another motivation for revision was to provide additional detail and
  884.    clarification of subtle points.  This specification provides
  885.    rationale for exclusion of selected IPv4 header fields from AH
  886.    coverage and provides examples on positioning of AH in both the IPv4
  887.    and v6 contexts.  Auditing requirements have been clarified in this
  888.    version of the specification.  Tunnel mode AH was mentioned only in
  889.    passing in RFC 1826, but now is a mandatory feature of AH.
  890.    Discussion of interactions with key management and with security
  891.    labels have been moved to the Security Architecture document.
  892.  
  893.  
  894.  
  895.  
  896.  
  897. Kent, Atkinson                                                 [Page 16]
  898.  
  899.  
  900. Internet Draft          IP Authentication Header           21 July, 1997
  901.  
  902.  
  903. Acknowledgements
  904.  
  905.    For over 2 years, this document has evolved through multiple versions
  906.    and iterations.  During this time, many people have contributed
  907.    significant ideas and energy to the process and the documents
  908.    themselves.  The authors would like to thank Karen Seo for providing
  909.    extensive help in the review, editing, background research, and
  910.    coordination for this version of the specification.  The authors
  911.    would also like to thank the members of the IPsec and IPng working
  912.    groups, with special mention of the efforts of (in alphabetic order):
  913.    Steve Bellovin, Steve Deering, Francis Dupont, Phil Karn, Frank
  914.    Kastenholz, Perry Metzger, David Mihelcic, Hilarie Orman, William
  915.    Simpson, and Nina Yuan.
  916.  
  917.  
  918.  
  919.  
  920.  
  921.  
  922.  
  923.  
  924.  
  925.  
  926.  
  927.  
  928.  
  929.  
  930.  
  931.  
  932.  
  933.  
  934.  
  935.  
  936.  
  937.  
  938.  
  939.  
  940.  
  941.  
  942.  
  943.  
  944.  
  945.  
  946.  
  947.  
  948.  
  949.  
  950.  
  951.  
  952.  
  953. Kent, Atkinson                                                 [Page 17]
  954.  
  955.  
  956. Internet Draft          IP Authentication Header           21 July, 1997
  957.  
  958.  
  959. Appendix A -- Mutability of IP Options/Extension Headers
  960.  
  961.    1. IPv4 Options
  962.  
  963.       This table shows how the IPv4 options are classified with regard to
  964.       "mutability".  Where two references are provided, the second one
  965.       supercedes the first.  This table is based in part on information
  966.       provided in RFC1700, "ASSIGNED NUMBERS", (October 1994).
  967.  
  968.                  Opt.
  969.       Copy Class  #   Name                       Reference
  970.       ---- ----- ---  -------------------------  ---------
  971.       IMMUTABLE -- included in ICV calculation
  972.         0   0     0   End of Options List        [RFC791]
  973.         0   0     1   No Operation               [RFC791]
  974.         1   0     2   Security                   [RFC1108(historic but in use)]
  975.         1   0     5   Extended Security          [RFC1108(historic but in use)]
  976.         1   0     6   Commercial Security        [expired I-D, now US MIL STD]
  977.         1   0    20   Router Alert               [RFC2113]
  978.         1   0    21   Sender Directed Multi-     [RFC1770]
  979.                       Destination Delivery
  980.       MUTABLE -- zeroed
  981.         1   0      3  Loose Source Route         [RFC791]
  982.         0   2      4  Time Stamp                 [RFC791]
  983.         0   0      7  Record Route               [RFC791]
  984.         1   0      9  Strict Source Route        [RFC791]
  985.         0   2     18  Traceroute                 [RFC1393]
  986.  
  987.       EXPERIMENTAL, SUPERCEDED -- zeroed
  988.         1   0      8  Stream ID                  [RFC791, RFC1122 (Host Req)]
  989.         0   0     11  MTU Probe                  [RFC1063, RFC1191 (PMTU)]
  990.         0   0     12  MTU Reply                  [RFC1063, RFC1191 (PMTU)]
  991.         1   0     17  Extended Internet Protocol [RFC1385, RFC1883 (IPv6)]
  992.         0   0     10  Experimental Measurement   [ZSu]
  993.         1   2     13  Experimental Flow Control  [Finn]
  994.         1   0     14  Experimental Access Ctl    [Estrin]
  995.         0   0     15  ???                        [VerSteeg]
  996.         1   0     16  IMI Traffic Descriptor     [Lee]
  997.         1   0     19  Address Extension          [Ullmann IPv7]
  998.  
  999.    NOTE: Use of the Router Alert option is potentially incompatible with
  1000.    use of IPSEC.  Although the option is immutable, its use implies that
  1001.    each router along a packet's path will "process" the packet and
  1002.    consequently might change the packet.  This would happen on a hop by
  1003.    hop basis as the packet goes from router to router.  Prior to being
  1004.    processed by the application to which the option contents are
  1005.    directed, e.g., RSVP/IGMP, the packet should encounter AH processing.
  1006.    However, AH processing would require that each router along the path
  1007.  
  1008.  
  1009. Kent, Atkinson                                                 [Page 18]
  1010.  
  1011.  
  1012. Internet Draft          IP Authentication Header           21 July, 1997
  1013.  
  1014.  
  1015.    is a member of a multicast-SA defined by the SPI.  This might pose
  1016.    problems for packets that are not strictly source routed, and it
  1017.    requires multicast support techniques not currently available.
  1018.  
  1019.    NOTE: Addition or removal of any security labels (BSO, ESO, CIPSO) by
  1020.    systems along a packet's path conflicts with the classification of these
  1021.    IP Options as immutable and is incompatible with the use of IPSEC.
  1022.  
  1023.    2. IPv6 Extension Headers
  1024.  
  1025.       This table shows how the IPv6 Extension Headers are classified with
  1026.       regard to "mutability".
  1027.  
  1028.       Option/Extension Name                  Reference
  1029.       -----------------------------------    ---------
  1030.       MUTABLE BUT PREDICTABLE -- included in ICV calculation
  1031.         Routing (Type 0)                    [RFC1883]
  1032.  
  1033.       BIT INDICATES IF OPTION IS MUTABLE (CHANGES UNPREDICTABLY DURING TRANSIT)
  1034.         Hop by Hop options                  [RFC1883]
  1035.         Destination options                 [RFC1883]
  1036.  
  1037.       NOT APPLICABLE
  1038.         Fragmentation                       [RFC1883]
  1039.  
  1040.       Options -- IPv6 options in the Hop-by-Hop and Destination Extension
  1041.              Headers contain a bit that indicates whether the option might
  1042.              change (unpredictably) during transit.  For any option for which
  1043.              contents may change en-route, the entire "Option Data" field
  1044.              must be treated as zero-valued octets when computing or
  1045.              verifying the ICV.  The Option Type and Opt Data Len are
  1046.              included in the ICV calculation.  All options for which the bit
  1047.              indicates immutability are included in the ICV calculation.  See
  1048.              the IPv6 specification [DH95] for more information.
  1049.  
  1050.       Routing (Type 0) -- The IPv6 Routing Header "Type 0" will rearrange
  1051.              the address fields within the packet during transit from source
  1052.              to destination.  However, the contents of the packet as it will
  1053.              appear at the receiver are known to the sender and to all
  1054.              intermediate hops.  Hence, the IPv6 Routing Header "Type 0" is
  1055.              included in the Authentication Data calculation as mutable but
  1056.              predictable.  The transmitter must order the field so that it
  1057.              appears as it will at the receiver, prior to performing the ICV
  1058.              computation.
  1059.  
  1060.       Fragmentation -- Fragmentation occurs after outbound IPSEC processing
  1061.              (section 3.2.4) and reassembly occurs before inbound IPSEC
  1062.              processing (section 3.3.1).  So the Fragmentation Extension
  1063.  
  1064.  
  1065. Kent, Atkinson                                                 [Page 19]
  1066.  
  1067.  
  1068. Internet Draft          IP Authentication Header           21 July, 1997
  1069.  
  1070.  
  1071.              Header, if it exists, is not seen by IPSEC.
  1072.  
  1073.              Note that on the receive side, the IP implementation could leave
  1074.              a Fragmentation Extension Header in place when it does
  1075.              re-assembly.  If this happens, then when AH receives the packet,
  1076.              before doing ICV processing, AH MUST "remove" (or skip over)
  1077.              this header and change the previous header's "Next Header" field
  1078.              to be the "Next Header" field in the Fragmentation Extension
  1079.              Header.
  1080.  
  1081.              Note that on the send side, the IP implementation could give the
  1082.              IPSEC code a packet with a Fragmentation Extension Header with
  1083.              Offset of 0 (first fragment) and a More Fragments Flag of 0
  1084.              (last fragment).  If this happens, then before doing ICV
  1085.              processing, AH MUST first "remove" (or skip over) this header
  1086.              and change the previous header's "Next Header" field to be the
  1087.              "Next Header" field in the Fragmentation Extension Header.
  1088.  
  1089.  
  1090.  
  1091.  
  1092.  
  1093.  
  1094.  
  1095.  
  1096.  
  1097.  
  1098.  
  1099.  
  1100.  
  1101.  
  1102.  
  1103.  
  1104.  
  1105.  
  1106.  
  1107.  
  1108.  
  1109.  
  1110.  
  1111.  
  1112.  
  1113.  
  1114.  
  1115.  
  1116.  
  1117.  
  1118.  
  1119.  
  1120.  
  1121. Kent, Atkinson                                                 [Page 20]
  1122.  
  1123.  
  1124. Internet Draft          IP Authentication Header           21 July, 1997
  1125.  
  1126.  
  1127. References
  1128.  
  1129.    [ATK95]   R. Atkinson, "The IP Authentication Header," RFC 1826,
  1130.              August 1995.
  1131.  
  1132.    [BCCH94]  R. Braden, D. Clark, S. Crocker, & C.Huitema, "Report of
  1133.              IAB Workshop on Security in the Internet Architecture",
  1134.              RFC-1636, 9 June 1994, pp. 21-34.
  1135.  
  1136.    [Bel89]   Steven M. Bellovin, "Security Problems in the TCP/IP
  1137.              Protocol Suite", ACM Computer Communications Review, Vol.
  1138.              19, No. 2, March 1989.
  1139.  
  1140.    [CER95]   Computer Emergency Response Team (CERT), "IP Spoofing
  1141.              Attacks and Hijacked Terminal Connections", CA-95:01,
  1142.              January 1995. Available via anonymous ftp from
  1143.              info.cert.org in /pub/cert_advisories.
  1144.  
  1145.    [DH95]    Steve Deering & Bob Hinden, "Internet Protocol version 6
  1146.              (IPv6) Specification", RFC-1883, December 1995.
  1147.  
  1148.    [GM93]    James Galvin & Keith McCloghrie, Security Protocols for
  1149.              version 2 of the Simple Network Management Protocol
  1150.              (SNMPv2), RFC-1446, April 1993.
  1151.  
  1152.    [KA97a]   Steve Kent, Randall Atkinson, "Security Architecture for
  1153.              the Internet Protocol", Internet Draft, ?? 1997.
  1154.  
  1155.    [KA97b]   Steve Kent, Randall Atkinson, "IP Encapsulating Security
  1156.              Payload (ESP)", Internet Draft, ?? 1997.
  1157.  
  1158.    [KA97c]   Steve Kent, Randall Atkinson, "IP Authentication Header",
  1159.              Internet Draft, ?? 1997.
  1160.  
  1161.    [KBC97]   Hugo Krawczyk, Mihir Bellare, and Ran Canetti, "HMAC:
  1162.              Keyed-Hashing for Message Authentication", RFC-2104,
  1163.              February 1997.
  1164.  
  1165.    [Ken91]   Steve Kent, "US DoD Security Options for the Internet
  1166.              Protocol", RFC-1108, November 1991.
  1167.  
  1168.    [KA97a]   Steve Kent, Randall Atkinson, "Security Architecture for
  1169.              the Internet Protocol", Internet Draft, ?? 1997.
  1170.  
  1171.    [Riv92]   Ronald Rivest, "The MD5 Message Digest Algorithm," RFC-
  1172.              1321, April 1992.
  1173.  
  1174.    [SHA]     NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995
  1175.  
  1176.  
  1177. Kent, Atkinson                                                 [Page 21]
  1178.  
  1179.  
  1180. Internet Draft          IP Authentication Header           21 July, 1997
  1181.  
  1182.  
  1183.    [STD-1]   J. Postel, "Internet Official Protocol Standards", STD-1,
  1184.              March 1996.
  1185.  
  1186.    [STD-2]   J. Reynolds & J. Postel, "Assigned Numbers", STD-2, 20
  1187.              October 1994.
  1188.  
  1189.  
  1190. Disclaimer
  1191.  
  1192.    The views and specification here are those of the authors and are not
  1193.    necessarily those of their employers.  The authors and their
  1194.    employers specifically disclaim responsibility for any problems
  1195.    arising from correct or incorrect implementation or use of this
  1196.    specification.
  1197.  
  1198.  
  1199.  
  1200. Author Information
  1201.  
  1202.    Stephen Kent
  1203.    BBN Corporation
  1204.    70 Fawcett Street
  1205.    Cambridge, MA  02140
  1206.    USA
  1207.    E-mail: kent@bbn.com
  1208.    Telephone: +1 (617) 873-3988
  1209.  
  1210.    Randall Atkinson
  1211.    @Home Network
  1212.    385 Ravendale Drive
  1213.    Mountain View, CA 94043
  1214.    USA
  1215.    E-mail: rja@inet.org
  1216.  
  1217.  
  1218.  
  1219.  
  1220.  
  1221.  
  1222.  
  1223.  
  1224.  
  1225.  
  1226.  
  1227.  
  1228.  
  1229.  
  1230.  
  1231.  
  1232.  
  1233. Kent, Atkinson                                                 [Page 22]
  1234.