home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1800s / rfc1826.txt < prev    next >
Text File  |  1995-08-07  |  30KB  |  732 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        R. Atkinson
  8. Request for Comments: 1826                     Naval Research Laboratory
  9. Category: Standards Track                                    August 1995
  10.  
  11.  
  12.                         IP Authentication Header
  13.  
  14. Status of this Memo
  15.  
  16.    This document specifies an Internet standards track protocol for the
  17.    Internet community, and requests discussion and suggestions for
  18.    improvements.  Please refer to the current edition of the "Internet
  19.    Official Protocol Standards" (STD 1) for the standardization state
  20.    and status of this protocol.  Distribution of this memo is unlimited.
  21.  
  22. ABSTRACT
  23.  
  24.    This document describes a mechanism for providing cryptographic
  25.    authentication for IPv4 and IPv6 datagrams.  An Authentication Header
  26.    (AH) is normally inserted after an IP header and before the other
  27.    information being authenticated.
  28.  
  29. 1. INTRODUCTION
  30.  
  31.    The Authentication Header is a mechanism for providing strong
  32.    integrity and authentication for IP datagrams.  It might also provide
  33.    non-repudiation, depending on which cryptographic algorithm is used
  34.    and how keying is performed.  For example, use of an asymmetric
  35.    digital signature algorithm, such as RSA, could provide non-
  36.    repudiation.
  37.  
  38.    Confidentiality, and protection from traffic analysis are not
  39.    provided by the Authentication Header.  Users desiring
  40.    confidentiality should consider using the IP Encapsulating Security
  41.    Protocol (ESP) either in lieu of or in conjunction with the
  42.    Authentication Header [Atk95b].  This document assumes the reader has
  43.    previously read the related IP Security Architecture document which
  44.    defines the overall security architecture for IP and provides
  45.    important background information for this specification [Atk95a].
  46.  
  47. 1.1 Overview
  48.  
  49.    The IP Authentication Header seeks to provide security by adding
  50.    authentication information to an IP datagram. This authentication
  51.    information is calculated using all of the fields in the IP datagram
  52.    (including not only the IP Header but also other headers and the user
  53.    data) which do not change in transit.  Fields or options which need
  54.    to change in transit (e.g., "hop count", "time to live", "ident",
  55.  
  56.  
  57.  
  58. Atkinson                    Standards Track                     [Page 1]
  59.  
  60. RFC 1826                IP Authentication Header             August 1995
  61.  
  62.  
  63.    "fragment offset", or "routing pointer") are considered to be zero
  64.    for the calculation of the authentication data.  This provides
  65.    significantly more security than is currently present in IPv4 and
  66.    might be sufficient for the needs of many users.
  67.  
  68.    Use of this specification will increase the IP protocol processing
  69.    costs in participating end systems and will also increase the
  70.    communications latency.  The increased latency is primarily due to
  71.    the calculation of the authentication data by the sender and the
  72.    calculation and comparison of the authentication data by the receiver
  73.    for each IP datagram containing an Authentication Header.  The impact
  74.    will vary with authentication algorithm used and other factors.
  75.  
  76.    In order for the Authentication Header to work properly without
  77.    changing the entire Internet infrastructure, the authentication data
  78.    is carried in its own payload.  Systems that aren't participating in
  79.    the authentication MAY ignore the Authentication Data.  When used
  80.    with IPv6, the Authentication Header is normally placed after the
  81.    Fragmentation and End-to-End headers and before the ESP and
  82.    transport-layer headers.  The information in the other IP headers is
  83.    used to route the datagram from origin to destination.  When used
  84.    with IPv4, the Authentication Header immediately follows an IPv4
  85.    header.
  86.  
  87.    If a symmetric authentication algorithm is used and intermediate
  88.    authentication is desired, then the nodes performing such
  89.    intermediate authentication would need to be provided with the
  90.    appropriate keys.  Possession of those keys would permit any one of
  91.    those systems to forge traffic claiming to be from the legitimate
  92.    sender to the legitimate receiver or to modify the contents of
  93.    otherwise legitimate traffic.  In some environments such intermediate
  94.    authentication might be desirable [BCCH94].  If an asymmetric
  95.    authentication algorithm is used and the routers are aware of the
  96.    appropriate public keys and authentication algorithm, then the
  97.    routers possessing the authentication public key could authenticate
  98.    the traffic being handled without being able to forge or modify
  99.    otherwise legitimate traffic.  Also, Path MTU Discovery MUST be used
  100.    when intermediate authentication of the Authentication Header is
  101.    desired and IPv4 is in use because with this method it is not
  102.    possible to authenticate a fragment of a packet [MD90] [Kno93].
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Atkinson                    Standards Track                     [Page 2]
  115.  
  116. RFC 1826                IP Authentication Header             August 1995
  117.  
  118.  
  119. 1.2 Requirements Terminology
  120.  
  121.    In this document, the words that are used to define the significance
  122.    of each particular requirement are usually capitalised.  These words
  123.    are:
  124.  
  125.    - MUST
  126.  
  127.       This word or the adjective "REQUIRED" means that the item is an
  128.       absolute requirement of the specification.
  129.  
  130.    - SHOULD
  131.  
  132.       This word or the adjective "RECOMMENDED" means that there might
  133.       exist valid reasons in particular circumstances to ignore this
  134.       item, but the full implications should be understood and the case
  135.       carefully weighed before taking a different course.
  136.  
  137.    - MAY
  138.  
  139.       This word or the adjective "OPTIONAL" means that this item is
  140.       truly optional.  One vendor might choose to include the item
  141.       because a particular marketplace requires it or because it
  142.       enhances the product, for example; another vendor may omit the
  143.       same item.
  144.  
  145. 2. KEY MANAGEMENT
  146.  
  147.    Key management is an important part of the IP security architecture.
  148.    However, it is not integrated with this specification because of a
  149.    long history in the public literature of subtle flaws in key
  150.    management algorithms and protocols.  The IP Authentication Header
  151.    tries to decouple the key management mechanisms from the security
  152.    protocol mechanisms.  The only coupling between the key management
  153.    protocol and the security protocol is with the Security Parameters
  154.    Index (SPI), which is described in more detail below.  This
  155.    decoupling permits several different key management mechanisms to be
  156.    used.  More importantly, it permits the key management protocol to be
  157.    changed or corrected without unduly impacting the security protocol
  158.    implementations.
  159.  
  160.    The key management mechanism is used to negotiate a number of
  161.    parameters for each "Security Association", including not only the
  162.    keys but also other information (e.g., the authentication algorithm
  163.    and mode) used by the communicating parties.  The key management
  164.    mechanism creates and maintains a logical table containing the
  165.    several parameters for each current security association.  An
  166.    implementation of the IP Authentication Header will need to read that
  167.  
  168.  
  169.  
  170. Atkinson                    Standards Track                     [Page 3]
  171.  
  172. RFC 1826                IP Authentication Header             August 1995
  173.  
  174.  
  175.    logical table of security parameters to determine how to process each
  176.    datagram containing an Authentication Header (e.g., to determine
  177.    which algorithm/mode and key to use in authentication).
  178.  
  179.    Security Associations are unidirectional.  A bidirectional
  180.    communications session will normally have one Security Association in
  181.    each direction.  For example, when a TCP session exists between two
  182.    systems A and B, there will normally be one Security Association from
  183.    A to B and a separate second Security Assocation from B to A.  The
  184.    receiver assigns the SPI value to the the Security Association with
  185.    that sender.  The other parameters of the Security Association are
  186.    determined in a manner specified by the key management mechanism.
  187.    Section 4 of this document describes in detail the process of
  188.    selecting a Security Association for an outgoing packet and
  189.    identifying the Security Assocation for an incoming packet.
  190.  
  191.    The IP Security Architecture document describes key management in
  192.    detail.  It includes specification of the key management requirements
  193.    for this protocol, and is incorporated here by reference [Atk95a].
  194.  
  195. 3. AUTHENTICATION HEADER SYNTAX
  196.  
  197.    The Authentication Header (AH) may appear after any other headers
  198.    which are examined at each hop, and before any other headers which
  199.    are not examined at an intermediate hop.  The IPv4 or IPv6 header
  200.    immediately preceding the Authentication Header will contain the
  201.    value 51 in its Next Header (or Protocol) field [STD-2].
  202.  
  203.    Example high-level diagrams of IP datagrams with the Authentication
  204.    Header follow.
  205.  
  206.  +------------+-------------------+------------+-------+---------------+
  207.  | IPv6 Header| Hop-by-Hop/Routing| Auth Header| Others| Upper Protocol|
  208.  +------------+-------------------+------------+-------+---------------+
  209.  
  210.                 Figure 1: IPv6 Example
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Atkinson                    Standards Track                     [Page 4]
  227.  
  228. RFC 1826                IP Authentication Header             August 1995
  229.  
  230.  
  231.    When used with IPv6, the Authentication Header normally appears after
  232.    the IPv6 Hop-by-Hop Header and before the IPv6 Destination Options.
  233.  
  234.     +-------------+--------------+-------------------------------+
  235.     | IPv4 Header |  Auth Header | Upper Protocol (e.g. TCP, UDP)|
  236.     +-------------+--------------+-------------------------------+
  237.  
  238.                    Figure 2:  IPv4 Example
  239.  
  240.  
  241.    When used with IPv4, the Authentication Header normally follows the
  242.    main IPv4 header.
  243.  
  244. 3.1 Authentication Header Syntax
  245.  
  246.    The authentication data is the output of the authentication algorithm
  247.    calculated over the the entire IP datagram as described in more
  248.    detail later in this document.  The authentication calculation must
  249.    treat the Authentication Data field itself and all fields that are
  250.    normally modified in transit (e.g., TTL or Hop Limit) as if those
  251.    fields contained all zeros.  All other Authentication Header fields
  252.    are included in the authentication calculation normally.
  253.  
  254.    The IP Authentication Header has the following syntax:
  255.  
  256.      +---------------+---------------+---------------+---------------+
  257.      | Next Header   | Length        |           RESERVED            |
  258.      +---------------+---------------+---------------+---------------+
  259.      |                    Security Parameters Index                  |
  260.      +---------------+---------------+---------------+---------------+
  261.      |                                                               |
  262.      +     Authentication Data (variable number of 32-bit words)     |
  263.      |                                                               |
  264.      +---------------+---------------+---------------+---------------+
  265.       1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8 1 2 3 4 5 6 7 8
  266.  
  267.  
  268.                    Figure 3:  Authentication Header syntax
  269.  
  270.  
  271.  
  272.  
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Atkinson                    Standards Track                     [Page 5]
  283.  
  284. RFC 1826                IP Authentication Header             August 1995
  285.  
  286.  
  287. 3.2 Fields of the Authentication Header
  288.  
  289.    NEXT HEADER
  290.       8 bits wide.  Identifies the next payload after the Authentication
  291.       Payload.  This values in this field are the set of IP Protocol
  292.       Numbers as defined in the most recent RFC from the Internet
  293.       Assigned Numbers Authority (IANA) describing "Assigned Numbers"
  294.       [STD-2].
  295.  
  296.    PAYLOAD LENGTH
  297.       8 bits wide.  The length of the Authentication Data field in 32-
  298.       bit words.  Minimum value is 0 words, which is only used in the
  299.       degenerate case of a "null" authentication algorithm.
  300.  
  301.    RESERVED
  302.       16 bits wide.  Reserved for future use.  MUST be set to all zeros
  303.       when sent.  The value is included in the Authentication Data
  304.       calculation, but is otherwise ignored by the recipient.
  305.  
  306.    SECURITY PARAMETERS INDEX (SPI)
  307.       A 32-bit pseudo-random value identifying the security association
  308.       for this datagram.  The Security Parameters Index value 0 is
  309.       reserved to indicate that "no security association exists".
  310.  
  311.       The set of Security Parameters Index values in the range 1 through
  312.       255 are reserved to the Internet Assigned Numbers Authority (IANA)
  313.       for future use.  A reserved SPI value will not normally be
  314.       assigned by IANA unless the use of that particular assigned SPI
  315.       value is openly specified in an RFC.
  316.  
  317.    AUTHENTICATION DATA
  318.       This length of this field is variable, but is always an integral
  319.       number of 32-bit words.
  320.  
  321.       Many implementations require padding to other alignments, such as
  322.       64-bits, in order to improve performance.  All implementations
  323.       MUST support such padding, which is specified by the Destination
  324.       on a per SPI basis.  The value of the padding field is arbitrarily
  325.       selected by the sender and is included in the Authentication Data
  326.       calculation.
  327.  
  328.       An implementation will normally use the combination of Destination
  329.       Address and SPI to locate the Security Association which specifies
  330.       the field's size and use.  The field retains the same format for
  331.       all datagrams of any given SPI and Destination Address pair.
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Atkinson                    Standards Track                     [Page 6]
  339.  
  340. RFC 1826                IP Authentication Header             August 1995
  341.  
  342.  
  343.       The Authentication Data fills the field beginning immediately
  344.       after the SPI field.  If the field is longer than necessary to
  345.       store the actual authentication data, then the unused bit
  346.       positions are filled with unspecified, implementation-dependent
  347.       values.
  348.  
  349.       Refer to each Authentication Transform specification for more
  350.       information regarding the contents of this field.
  351.  
  352. 3.3 Sensitivity Labeling
  353.  
  354.    As is discussed in greater detail in the IP Security Architecture
  355.    document, IPv6 will normally use implicit Security Labels rather than
  356.    the explicit labels that are currently used with IPv4 [Ken91]
  357.    [Atk95a].  In some situations, users MAY choose to carry explicit
  358.    labels (for example, IPSO labels as defined by RFC-1108 might be used
  359.    with IPv4) in addition to using the implicit labels provided by the
  360.    Authentication Header.  Explicit label options could be defined for
  361.    use with IPv6 (e.g., using the IPv6 end-to-end options header or the
  362.    IPv6 hop-by-hop options header).  Implementations MAY support
  363.    explicit labels in addition to implicit labels, but implementations
  364.    are not required to support explicit labels.  If explicit labels are
  365.    in use, then the explicit label MUST be included in the
  366.    authentication calculation.
  367.  
  368. 4. CALCULATION OF THE AUTHENTICATION DATA
  369.  
  370.    The authentication data carried by the IP Authentication Header is
  371.    usually calculated using a message digest algorithm (for example,
  372.    MD5) either encrypting that message digest or keying the message
  373.    digest directly [Riv92].  Only algorithms that are believed to be
  374.    cryptographically strong one-way functions should be used with the IP
  375.    Authentication Header.
  376.  
  377.    Because conventional checksums (e.g., CRC-16) are not
  378.    cryptographically strong, they MUST NOT be used with the
  379.    Authentication Header.
  380.  
  381.    When processing an outgoing IP packet for Authentication, the first
  382.    step is for the sending system to locate the appropriate Security
  383.    Association.  All Security Associations are unidirectional.  The
  384.    selection of the appropriate Security Association for an outgoing IP
  385.    packet is based at least upon the sending userid and the Destination
  386.    Address.  When host-oriented keying is in use, all sending userids
  387.    will share the same Security Association to a given destination.
  388.    When user-oriented keying is in use, then different users or possibly
  389.    even different applications of the same user might use different
  390.    Security Associations.  The Security Association selected will
  391.  
  392.  
  393.  
  394. Atkinson                    Standards Track                     [Page 7]
  395.  
  396. RFC 1826                IP Authentication Header             August 1995
  397.  
  398.  
  399.    indicate which algorithm, algorithm mode, key, and other security
  400.    properties apply to the outgoing packet.
  401.  
  402.    Fields which NECESSARILY are modified during transit from the sender
  403.    to the receiver (e.g., TTL and HEADER CHECKSUM for IPv4 or Hop Limit
  404.    for IPv6) and whose value at the receiver are not known with
  405.    certainty by the sender are included in the authentication data
  406.    calculation but are processed specially.  For these fields which are
  407.    modified during transit, the value carried in the IP packet is
  408.    replaced by the value zero for the purpose of the authentication
  409.    calculation.  By replacing the field's value with zero rather than
  410.    omitting these fields, alignment is preserved for the authentication
  411.    calculation.
  412.  
  413.    The sender MUST compute the authentication over the packet as that
  414.    packet will appear at the receiver.  This requirement is placed in
  415.    order to allow for future IP optional headers which the receiver
  416.    might not know about but the sender necessarily knows about if it is
  417.    including such options in the packet.  This also permits the
  418.    authentication of data that will vary in transit but whose value at
  419.    the final receiver is known with certainty by the sender in advance.
  420.  
  421.    The sender places the calculated message digest algorithm output into
  422.    the Authentication Data field within the Authentication Header.  For
  423.    purposes of Authentication Data computation, the Authentication Data
  424.    field is considered to be filled with zeros.
  425.  
  426.    The IPv4 "TIME TO LIVE" and "HEADER CHECKSUM" fields are the only
  427.    fields in the IPv4 base header that are handled specially for the
  428.    Authentication Data calculation.  Reassembly of fragmented packets
  429.    occurs PRIOR to processing by the local IP Authentication Header
  430.    implementation.  The "more" bit is of course cleared upon reassembly.
  431.     Hence, no other fields in the IPv4 header will vary in transit from
  432.    the perspective of the IP Authentication Header implementation.  The
  433.    "TIME TO LIVE" and "HEADER CHECKSUM" fields of the IPv4 base header
  434.    MUST be set to all zeros for the Authentication Data calculation.
  435.    All other IPv4 base header fields are processed normally with their
  436.    actual contents.  Because IPv4 packets are subject to intermediate
  437.    fragmentation in routers, it is important that the reassembly of IPv4
  438.    packets be performed prior to the Authentication Header processing.
  439.    IPv4 Implementations SHOULD use Path MTU Discovery when the IP
  440.    Authentication Header is being used [MD90].  For IPv4, not all
  441.    options are openly specified in a RFC, so it is not possible to
  442.    enumerate in this document all of the options that might normally be
  443.    modified during transit.  The IP Security Option (IPSO) MUST be
  444.    included in the Authentication Data calculation whenever that option
  445.    is present in an IP datagram [Ken91].  If a receiving system does not
  446.    recognise an IPv4 option that is present in the packet, that option
  447.  
  448.  
  449.  
  450. Atkinson                    Standards Track                     [Page 8]
  451.  
  452. RFC 1826                IP Authentication Header             August 1995
  453.  
  454.  
  455.    is included in the Authentication Data calculation.  This means that
  456.    any IPv4 packet containing an IPv4 option that changes during transit
  457.    in a manner not predictable by the sender and which IPv4 option is
  458.    unrecognised by the receiver will fail the authentication check and
  459.    consequently be dropped by the receiver.
  460.  
  461.    The IPv6 "HOP LIMIT" field is the only field in the IPv6 base header
  462.    that is handled specially for Authentication Data calculation.  The
  463.    value of the HOP LIMIT field is zero for the purpose of
  464.    Authentication Data calculation.  All other fields in the base IPv6
  465.    header MUST be included in the Authentication Data calculation using
  466.    the normal procedures for calculating the Authentication Data.  All
  467.    IPv6 "OPTION TYPE" values contain a bit which MUST be used to
  468.    determine whether that option data will be included in the
  469.    Authentication Data calculation.  This bit is the third-highest-order
  470.    bit of the IPv6 OPTION TYPE field. If this bit is set to zero, then
  471.    the corresponding option is included in the Authentication Data
  472.    calculation.  If this bit is set to one, then the corresponding
  473.    option is replaced by all zero bits of the same length as the option
  474.    for the purpose of the Authentication Data calculation.  The IPv6
  475.    Routing Header "Type 0" will rearrange the address fields within the
  476.    packet during transit from source to destination.  However, this is
  477.    not a problem because the contents of the packet as it will appear at
  478.    the receiver are known to the sender and to all intermediate hops.
  479.    Hence, the IPv6 Routing Header "Type 0" is included in the
  480.    Authentication Data calculation using the normal procedure.
  481.  
  482.    Upon receipt of a packet containing an IP Authentication Header, the
  483.    receiver first uses the Destination Address and SPI value to locate
  484.    the correct Security Association.  The receiver then independently
  485.    verifies that the Authentication Data field and the received data
  486.    packet are consistent.  Again, the Authentication Data field is
  487.    assumed to be zero for the sole purpose of making the authentication
  488.    computation.  Exactly how this is accomplished is algorithm
  489.    dependent.  If the processing of the authentication algorithm
  490.    indicates the datagram is valid, then it is accepted.  If the
  491.    algorithm determines that the data and the Authentication Header do
  492.    not match, then the receiver SHOULD discard the received IP datagram
  493.    as invalid and MUST record the authentication failure in the system
  494.    log or audit log.  If such a failure occurs, the recorded log data
  495.    MUST include the SPI value, date/time received, clear-text Sending
  496.    Address, clear-text Destination Address, and (if it exists) the
  497.    clear-text Flow ID.  The log data MAY also include other information
  498.    about the failed packet.
  499.  
  500.  
  501.  
  502.  
  503.  
  504.  
  505.  
  506. Atkinson                    Standards Track                     [Page 9]
  507.  
  508. RFC 1826                IP Authentication Header             August 1995
  509.  
  510.  
  511. 5. CONFORMANCE REQUIREMENTS
  512.  
  513.    Implementations that claim conformance or compliance with this
  514.    specification MUST fully implement the header described here, MUST
  515.    support manual key distribution for use with this option, MUST comply
  516.    with all requirements of the "Security Architecture for the Internet
  517.    Protocol" [Atk95a], and MUST support the use of keyed MD5 as
  518.    described in the companion document entitled "IP Authentication using
  519.    Keyed MD5" [MS95].  Implementations MAY also implement other
  520.    authentication algorithms.  Implementors should consult the most
  521.    recent version of the "IAB Official Standards" RFC for further
  522.    guidance on the status of this document.
  523.  
  524. 6. SECURITY CONSIDERATIONS
  525.  
  526.    This entire RFC discusses an authentication mechanism for IP.  This
  527.    mechanism is not a panacea to the several security issues in any
  528.    internetwork, however it does provide a component useful in building
  529.    a secure internetwork.
  530.  
  531.    Users need to understand that the quality of the security provided by
  532.    this specification depends completely on the strength of whichever
  533.    cryptographic algorithm has been implemented, the strength of the key
  534.    being used, the correctness of that algorithm's implementation, upon
  535.    the security of the key management mechanism and its implementation,
  536.    and upon the correctness of the IP Authentication Header and IP
  537.    implementations in all of the participating systems. If any of these
  538.    assumptions do not hold, then little or no real security will be
  539.    provided to the user.  Implementors are encouraged to use high
  540.    assurance methods to develop all of the security relevant parts of
  541.    their products.
  542.  
  543.    Users interested in confidentiality should consider using the IP
  544.    Encapsulating Security Payload (ESP) instead of or in conjunction
  545.    with this specification [Atk95b].  Users seeking protection from
  546.    traffic analysis might consider the use of appropriate link
  547.    encryption.  Description and specification of link encryption is
  548.    outside the scope of this note [VK83].  Users interested in combining
  549.    the IP Authentication Header with the IP Encapsulating Security
  550.    Payload should consult the IP Encapsulating Security Payload
  551.    specification for details.
  552.  
  553.    One particular issue is that in some cases a packet which causes an
  554.    error to be reported back via ICMP might be so large as not to
  555.    entirely fit within the ICMP message returned.  In such cases, it
  556.    might not be possible for the receiver of the ICMP message to
  557.    independently authenticate the portion of the returned message.  This
  558.    could mean that the host receiving such an ICMP message would either
  559.  
  560.  
  561.  
  562. Atkinson                    Standards Track                    [Page 10]
  563.  
  564. RFC 1826                IP Authentication Header             August 1995
  565.  
  566.  
  567.    trust an unauthenticated ICMP message, which might in turn create
  568.    some security problem, or not trust and hence not react appropriately
  569.    to some legitimate ICMP message that should have been reacted to.  It
  570.    is not clear that this issue can be fully resolved in the presence of
  571.    packets that are the same size as or larger than the minimum IP MTU.
  572.    Similar complications arise if an encrypted packet causes an ICMP
  573.    error message to be sent and that packet is truncated.
  574.  
  575.    Active attacks are now widely known to exist in the Internet [CER95].
  576.    The presence of active attacks means that unauthenticated source
  577.    routing, either unidirectional (receive-only) or with replies
  578.    following the original received source route represents a significant
  579.    security risk unless all received source routed packets are
  580.    authenticated using the IP Authentication Header or some other
  581.    cryptologic mechanism.  It is noteworthy that the attacks described
  582.    in [CER95] include a subset of those described in [Bel89].
  583.  
  584.    The use of IP tunneling with AH creates multiple pairs of endpoints
  585.    that might perform AH processing.  Implementers and administrators
  586.    should carefully consider the impacts of tunneling on authenticity of
  587.    the received tunneled packets.
  588.  
  589. ACKNOWLEDGEMENTS
  590.  
  591.    This document benefited greatly from work done by Bill Simpson, Perry
  592.    Metzger, and Phil Karn to make general the approach originally
  593.    defined by the author for SIP, SIPP, and finally IPv6.
  594.  
  595.    The basic concept here is derived in large part from the SNMPv2
  596.    Security Protocol work described in [GM93].  Steve Bellovin, Steve
  597.    Deering, Frank Kastenholz, Dave Mihelcic, and Hilarie Orman provided
  598.    thoughtful critiques of early versions of this note.  Francis Dupont
  599.    discovered and pointed out the security issue with ICMP in low IP MTU
  600.    links that is noted just above.
  601.  
  602. REFERENCES
  603.  
  604.    [Atk95a] Atkinson, R., "Security Architecture for the Internet
  605.             Protocol", RFC 1825, NRL, August 1995.
  606.  
  607.    [Atk95b] Atkinson, R., "IP Encapsulating Security Payload", RFC 1827,
  608.             NRL, August 1995.
  609.  
  610.    [Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP Protocol
  611.            Suite", ACM Computer Communications Review, Vol. 19, No. 2,
  612.            March 1989.
  613.  
  614.  
  615.  
  616.  
  617.  
  618. Atkinson                    Standards Track                    [Page 11]
  619.  
  620. RFC 1826                IP Authentication Header             August 1995
  621.  
  622.  
  623.    [BCCH94] Braden, R., Clark, D., Crocker, S., and C. Huitema, "Report
  624.             of IAB Workshop on Security in the Internet Architecture",
  625.             RFC 1636, USC/Information Sciences Institute, MIT, Trusted
  626.             Information Systems, INRIA, June 1994, pp. 21-34.
  627.  
  628.    [CER95] Computer Emergency Response Team (CERT), "IP Spoofing Attacks
  629.            and Hijacked Terminal Connections", CA-95:01, January 1995.
  630.            Available via anonymous ftp from info.cert.org in
  631.            /pub/cert_advisories.
  632.  
  633.    [GM93]  Galvin J., and K. McCloghrie, "Security Protocols for
  634.            version 2 of the Simple Network Management Protocol
  635.            (SNMPv2)", RFC 1446, Trusted Information Systems, Hughes LAN
  636.            Systems, April 1993.
  637.  
  638.    [Hin94] Bob Hinden (Editor), Internet Protocol version 6 (IPv6)
  639.            Specification, Work in Progress, October 1994.
  640.  
  641.    [Ken91] Kent, S., "US DoD Security Options for the Internet Protocol",
  642.            RFC 1108, BBN Communications, November 1991.
  643.  
  644.    [Kno93] Knowles, Stev, "IESG Advice from Experience with Path MTU
  645.            Discovery", RFC 1435, FTP Software, March 1993.
  646.  
  647.    [MS95]  Metzger, P., and W. Simpson, "IP Authentication with Keyed
  648.            MD5", RFC 1828, Piermont, Daydreamer, August 1995.
  649.  
  650.    [MD90]  Mogul, J., and S. Deering, "Path MTU Discovery", RFC 1191,
  651.            DECWRL, Stanford University, November 1990.
  652.  
  653.    [STD-2] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
  654.            RFC 1700, USC/Information Sciences Institute, October 1994.
  655.  
  656.    [Riv92] Rivest, R., "MD5 Digest Algorithm", RFC 1321, MIT and RSA Data
  657.            Security, Inc., April 1992.
  658.  
  659.    [VK83]  V.L. Voydock & S.T. Kent, "Security Mechanisms in High-level
  660.            Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983.
  661.  
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668.  
  669.  
  670.  
  671.  
  672.  
  673.  
  674. Atkinson                    Standards Track                    [Page 12]
  675.  
  676. RFC 1826                IP Authentication Header             August 1995
  677.  
  678.  
  679. DISCLAIMER
  680.  
  681.    The views and specification here are those of the author and are not
  682.    necessarily those of his employer.  The Naval Research Laboratory has
  683.    not passed judgement on the merits, if any, of this work.  The author
  684.    and his employer specifically disclaim responsibility for any
  685.    problems arising from correct or incorrect implementation or use of
  686.    this specification.
  687.  
  688. AUTHOR INFORMATION
  689.  
  690.    Randall Atkinson
  691.    Information Technology Division
  692.    Naval Research Laboratory
  693.    Washington, DC 20375-5320
  694.    USA
  695.  
  696.    Phone:  (202) 767-2389
  697.    Fax:    (202) 404-8590
  698.    EMail:  atkinson@itd.nrl.navy.mil
  699.  
  700.  
  701.  
  702.  
  703.  
  704.  
  705.  
  706.  
  707.  
  708.  
  709.  
  710.  
  711.  
  712.  
  713.  
  714.  
  715.  
  716.  
  717.  
  718.  
  719.  
  720.  
  721.  
  722.  
  723.  
  724.  
  725.  
  726.  
  727.  
  728.  
  729.  
  730. Atkinson                    Standards Track                    [Page 13]
  731.  
  732.