rfc1826.txt

RFC 的详细文档！

   The authentication data is the output of the authentication algorithm
   calculated over the the entire IP datagram as described in more
   detail later in this document.  The authentication calculation must
   treat the Authentication Data field itself and all fields that are
   normally modified in transit (e.g., TTL or Hop Limit) as if those
   fields contained all zeros.  All other Authentication Header fields
   are included in the authentication calculation normally.

   The IP Authentication Header has the following syntax:

     +---------------+---------------+---------------+---------------+
     | Next Header   | Length        |           RESERVED            |
     +---------------+---------------+---------------+---------------+
     |                    Security Parameters Index                  |
     +---------------+---------------+---------------+---------------+
     |                                                               |
     +     Authentication Data (variable number of 32-bit words)     |
     |                                                               |
     +---------------+---------------+---------------+---------------+
      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


                   Figure 3:  Authentication Header syntax













Atkinson                    Standards Track                     [Page 5]

RFC 1826                IP Authentication Header             August 1995


3.2 Fields of the Authentication Header

   NEXT HEADER
      8 bits wide.  Identifies the next payload after the Authentication
      Payload.  This values in this field are the set of IP Protocol
      Numbers as defined in the most recent RFC from the Internet
      Assigned Numbers Authority (IANA) describing "Assigned Numbers"
      [STD-2].

   PAYLOAD LENGTH
      8 bits wide.  The length of the Authentication Data field in 32-
      bit words.  Minimum value is 0 words, which is only used in the
      degenerate case of a "null" authentication algorithm.

   RESERVED
      16 bits wide.  Reserved for future use.  MUST be set to all zeros
      when sent.  The value is included in the Authentication Data
      calculation, but is otherwise ignored by the recipient.

   SECURITY PARAMETERS INDEX (SPI)
      A 32-bit pseudo-random value identifying the security association
      for this datagram.  The Security Parameters Index value 0 is
      reserved to indicate that "no security association exists".

      The set of Security Parameters Index values in the range 1 through
      255 are reserved to the Internet Assigned Numbers Authority (IANA)
      for future use.  A reserved SPI value will not normally be
      assigned by IANA unless the use of that particular assigned SPI
      value is openly specified in an RFC.

   AUTHENTICATION DATA
      This length of this field is variable, but is always an integral
      number of 32-bit words.

      Many implementations require padding to other alignments, such as
      64-bits, in order to improve performance.  All implementations
      MUST support such padding, which is specified by the Destination
      on a per SPI basis.  The value of the padding field is arbitrarily
      selected by the sender and is included in the Authentication Data
      calculation.

      An implementation will normally use the combination of Destination
      Address and SPI to locate the Security Association which specifies
      the field's size and use.  The field retains the same format for
      all datagrams of any given SPI and Destination Address pair.






Atkinson                    Standards Track                     [Page 6]

RFC 1826                IP Authentication Header             August 1995


      The Authentication Data fills the field beginning immediately
      after the SPI field.  If the field is longer than necessary to
      store the actual authentication data, then the unused bit
      positions are filled with unspecified, implementation-dependent
      values.

      Refer to each Authentication Transform specification for more
      information regarding the contents of this field.

3.3 Sensitivity Labeling

   As is discussed in greater detail in the IP Security Architecture
   document, IPv6 will normally use implicit Security Labels rather than
   the explicit labels that are currently used with IPv4 [Ken91]
   [Atk95a].  In some situations, users MAY choose to carry explicit
   labels (for example, IPSO labels as defined by RFC-1108 might be used
   with IPv4) in addition to using the implicit labels provided by the
   Authentication Header.  Explicit label options could be defined for
   use with IPv6 (e.g., using the IPv6 end-to-end options header or the
   IPv6 hop-by-hop options header).  Implementations MAY support
   explicit labels in addition to implicit labels, but implementations
   are not required to support explicit labels.  If explicit labels are
   in use, then the explicit label MUST be included in the
   authentication calculation.

4. CALCULATION OF THE AUTHENTICATION DATA

   The authentication data carried by the IP Authentication Header is
   usually calculated using a message digest algorithm (for example,
   MD5) either encrypting that message digest or keying the message
   digest directly [Riv92].  Only algorithms that are believed to be
   cryptographically strong one-way functions should be used with the IP
   Authentication Header.

   Because conventional checksums (e.g., CRC-16) are not
   cryptographically strong, they MUST NOT be used with the
   Authentication Header.

   When processing an outgoing IP packet for Authentication, the first
   step is for the sending system to locate the appropriate Security
   Association.  All Security Associations are unidirectional.  The
   selection of the appropriate Security Association for an outgoing IP
   packet is based at least upon the sending userid and the Destination
   Address.  When host-oriented keying is in use, all sending userids
   will share the same Security Association to a given destination.
   When user-oriented keying is in use, then different users or possibly
   even different applications of the same user might use different
   Security Associations.  The Security Association selected will



Atkinson                    Standards Track                     [Page 7]

RFC 1826                IP Authentication Header             August 1995


   indicate which algorithm, algorithm mode, key, and other security
   properties apply to the outgoing packet.

   Fields which NECESSARILY are modified during transit from the sender
   to the receiver (e.g., TTL and HEADER CHECKSUM for IPv4 or Hop Limit
   for IPv6) and whose value at the receiver are not known with
   certainty by the sender are included in the authentication data
   calculation but are processed specially.  For these fields which are
   modified during transit, the value carried in the IP packet is
   replaced by the value zero for the purpose of the authentication
   calculation.  By replacing the field's value with zero rather than
   omitting these fields, alignment is preserved for the authentication
   calculation.

   The sender MUST compute the authentication over the packet as that
   packet will appear at the receiver.  This requirement is placed in
   order to allow for future IP optional headers which the receiver
   might not know about but the sender necessarily knows about if it is
   including such options in the packet.  This also permits the
   authentication of data that will vary in transit but whose value at
   the final receiver is known with certainty by the sender in advance.

   The sender places the calculated message digest algorithm output into
   the Authentication Data field within the Authentication Header.  For
   purposes of Authentication Data computation, the Authentication Data
   field is considered to be filled with zeros.

   The IPv4 "TIME TO LIVE" and "HEADER CHECKSUM" fields are the only
   fields in the IPv4 base header that are handled specially for the
   Authentication Data calculation.  Reassembly of fragmented packets
   occurs PRIOR to processing by the local IP Authentication Header
   implementation.  The "more" bit is of course cleared upon reassembly.
    Hence, no other fields in the IPv4 header will vary in transit from
   the perspective of the IP Authentication Header implementation.  The
   "TIME TO LIVE" and "HEADER CHECKSUM" fields of the IPv4 base header
   MUST be set to all zeros for the Authentication Data calculation.
   All other IPv4 base header fields are processed normally with their
   actual contents.  Because IPv4 packets are subject to intermediate
   fragmentation in routers, it is important that the reassembly of IPv4
   packets be performed prior to the Authentication Header processing.
   IPv4 Implementations SHOULD use Path MTU Discovery when the IP
   Authentication Header is being used [MD90].  For IPv4, not all
   options are openly specified in a RFC, so it is not possible to
   enumerate in this document all of the options that might normally be
   modified during transit.  The IP Security Option (IPSO) MUST be
   included in the Authentication Data calculation whenever that option
   is present in an IP datagram [Ken91].  If a receiving system does not
   recognise an IPv4 option that is present in the packet, that option



Atkinson                    Standards Track                     [Page 8]

RFC 1826                IP Authentication Header             August 1995


   is included in the Authentication Data calculation.  This means that
   any IPv4 packet containing an IPv4 option that changes during transit
   in a manner not predictable by the sender and which IPv4 option is
   unrecognised by the receiver will fail the authentication check and
   consequently be dropped by the receiver.

   The IPv6 "HOP LIMIT" field is the only field in the IPv6 base header
   that is handled specially for Authentication Data calculation.  The
   value of the HOP LIMIT field is zero for the purpose of
   Authentication Data calculation.  All other fields in the base IPv6
   header MUST be included in the Authentication Data calculation using
   the normal procedures for calculating the Authentication Data.  All
   IPv6 "OPTION TYPE" values contain a bit which MUST be used to
   determine whether that option data will be included in the
   Authentication Data calculation.  This bit is the third-highest-order
   bit of the IPv6 OPTION TYPE field. If this bit is set to zero, then
   the corresponding option is included in the Authentication Data
   calculation.  If this bit is set to one, then the corresponding
   option is replaced by all zero bits of the same length as the option
   for the purpose of the Authentication Data calculation.  The IPv6
   Routing Header "Type 0" will rearrange the address fields within the
   packet during transit from source to destination.  However, this is
   not a problem because the contents of the packet as it will appear at
   the receiver are known to the sender and to all intermediate hops.
   Hence, the IPv6 Routing Header "Type 0" is included in the
   Authentication Data calculation using the normal procedure.

   Upon receipt of a packet containing an IP Authentication Header, the
   receiver first uses the Destination Address and SPI value to locate
   the correct Security Association.  The receiver then independently
   verifies that the Authentication Data field and the received data
   packet are consistent.  Again, the Authentication Data field is
   assumed to be zero for the sole purpose of making the authentication
   computation.  Exactly how this is accomplished is algorithm