rfc2402.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,236 行 · 第 1/4 页

Network Working Group                                            S. Kent
Request for Comments: 2402                                      BBN Corp
Obsoletes: 1826                                              R. Atkinson
Category: Standards Track                                  @Home Network
                                                           November 1998


                        IP Authentication Header

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Table of Contents

  1. Introduction......................................................2
  2. Authentication Header Format......................................3
     2.1 Next Header...................................................4
     2.2 Payload Length................................................4
     2.3 Reserved......................................................4
     2.4 Security Parameters Index (SPI)...............................4
     2.5 Sequence Number...............................................5
     2.6 Authentication Data ..........................................5
  3. Authentication Header Processing..................................5
     3.1  Authentication Header Location...............................5
     3.2  Authentication Algorithms....................................7
     3.3  Outbound Packet Processing...................................8
        3.3.1  Security Association Lookup.............................8
        3.3.2  Sequence Number Generation..............................8
        3.3.3  Integrity Check Value Calculation.......................9
           3.3.3.1  Handling Mutable Fields............................9
              3.3.3.1.1  ICV Computation for IPv4.....................10
                 3.3.3.1.1.1 Base Header Fields.......................10
                 3.3.3.1.1.2 Options..................................11
              3.3.3.1.2  ICV Computation for IPv6.....................11
                 3.3.3.1.2.1 Base Header Fields.......................11
                 3.3.3.1.2.2 Extension Headers Containing Options.....11
                 3.3.3.1.2.3 Extension Headers Not Containing Options.11
           3.3.3.2  Padding...........................................12
              3.3.3.2.1  Authentication Data Padding..................12



Kent & Atkinson             Standards Track                     [Page 1]

RFC 2402                IP Authentication Header           November 1998


              3.3.3.2.2  Implicit Packet Padding......................12
        3.3.4  Fragmentation..........................................12
     3.4  Inbound Packet Processing...................................13
        3.4.1  Reassembly.............................................13
        3.4.2  Security Association Lookup............................13
        3.4.3  Sequence Number Verification...........................13
        3.4.4  Integrity Check Value Verification.....................15
  4. Auditing.........................................................15
  5. Conformance Requirements.........................................16
  6. Security Considerations..........................................16
  7. Differences from RFC 1826........................................16
  Acknowledgements....................................................17
  Appendix A -- Mutability of IP Options/Extension Headers............18
     A1. IPv4 Options.................................................18
     A2. IPv6 Extension Headers.......................................19
  References..........................................................20
  Disclaimer..........................................................21
  Author Information..................................................22
  Full Copyright Statement............................................22

1.  Introduction

   The IP Authentication Header (AH) is used to provide connectionless
   integrity and data origin authentication for IP datagrams (hereafter
   referred to as just "authentication"), and to provide protection
   against replays.  This latter, optional service may be selected, by
   the receiver, when a Security Association is established. (Although
   the default calls for the sender to increment the Sequence Number
   used for anti-replay, the service is effective only if the receiver
   checks the Sequence Number.)  AH provides authentication for as much
   of the IP header as possible, as well as for upper level protocol
   data.  However, some IP header fields may change in transit and the
   value of these fields, when the packet arrives at the receiver, may
   not be predictable by the sender.  The values of such fields cannot
   be protected by AH.  Thus the protection provided to the IP header by
   AH is somewhat piecemeal.

   AH may be applied alone, in combination with the IP Encapsulating
   Security Payload (ESP) [KA97b], or in a nested fashion through the
   use of tunnel mode (see "Security Architecture for the Internet
   Protocol" [KA97a], hereafter referred to as the Security Architecture
   document).  Security services can be provided between a pair of
   communicating hosts, between a pair of communicating security
   gateways, or between a security gateway and a host.  ESP may be used
   to provide the same security services, and it also provides a
   confidentiality (encryption) service.  The primary difference between
   the authentication provided by ESP and AH is the extent of the
   coverage.  Specifically, ESP does not protect any IP header fields



Kent & Atkinson             Standards Track                     [Page 2]

RFC 2402                IP Authentication Header           November 1998


   unless those fields are encapsulated by ESP (tunnel mode).  For more
   details on how to use AH and ESP in various network environments, see
   the Security Architecture document [KA97a].

   It is assumed that the reader is familiar with the terms and concepts
   described in the Security Architecture document.  In particular, the
   reader should be familiar with the definitions of security services
   offered by AH and ESP, the concept of Security Associations, the ways
   in which AH can be used in conjunction with ESP, and the different
   key management options available for AH and ESP.  (With regard to the
   last topic, the current key management options required for both AH
   and ESP are manual keying and automated keying via IKE [HC98].)

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
   document, are to be interpreted as described in RFC 2119 [Bra97].

2.  Authentication Header Format

   The protocol header (IPv4, IPv6, or Extension) immediately preceding
   the AH header will contain the value 51 in its Protocol (IPv4) or
   Next Header (IPv6, Extension) field [STD-2].

    0                   1                   2                   3
    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Next Header   |  Payload Len  |          RESERVED             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 Security Parameters Index (SPI)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Sequence Number Field                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                Authentication Data (variable)                 |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The following subsections define the fields that comprise the AH
   format.  All the fields described here are mandatory, i.e., they are
   always present in the AH format and are included in the Integrity
   Check Value (ICV) computation (see Sections 2.6 and 3.3.3).










Kent & Atkinson             Standards Track                     [Page 3]

RFC 2402                IP Authentication Header           November 1998


2.1  Next Header

   The Next Header is an 8-bit field that identifies the type of the
   next payload after the Authentication Header.  The value of this
   field is chosen from the set of IP Protocol Numbers defined in the
   most recent "Assigned Numbers" [STD-2] RFC from the Internet Assigned
   Numbers Authority (IANA).

2.2  Payload Length

   This 8-bit field specifies the length of AH in 32-bit words (4-byte
   units), minus "2".  (All IPv6 extension headers, as per RFC 1883,
   encode the "Hdr Ext Len" field by first subtracting 1 (64-bit word)
   from the header length (measured in 64-bit words).  AH is an IPv6
   extension header.  However, since its length is measured in 32-bit
   words, the "Payload Length" is calculated by subtracting 2 (32 bit
   words).)  In the "standard" case of a 96-bit authentication value
   plus the 3 32-bit word fixed portion, this length field will be "4".
   A "null" authentication algorithm may be used only for debugging
   purposes.  Its use would result in a "1" value for this field for
   IPv4 or a "2" for IPv6, as there would be no corresponding
   Authentication Data field (see Section 3.3.3.2.1 on "Authentication
   Data Padding").

2.3  Reserved

   This 16-bit field is reserved for future use.  It MUST be set to
   "zero." (Note that the value is included in the Authentication Data
   calculation, but is otherwise ignored by the recipient.)

2.4  Security Parameters Index (SPI)

   The SPI is an arbitrary 32-bit value that, in combination with the
   destination IP address and security protocol (AH), uniquely
   identifies the Security Association for this datagram.  The set of
   SPI values in the range 1 through 255 are reserved by the Internet
   Assigned Numbers Authority (IANA) for future use; a reserved SPI
   value will not normally be assigned by IANA unless the use of the
   assigned SPI value is specified in an RFC.  It is ordinarily selected
   by the destination system upon establishment of an SA (see the
   Security Architecture document for more details).

   The SPI value of zero (0) is reserved for local, implementation-
   specific use and MUST NOT be sent on the wire.  For example, a key
   management implementation MAY use the zero SPI value to mean "No
   Security Association Exists" during the period when the IPsec
   implementation has requested that its key management entity establish
   a new SA, but the SA has not yet been established.



Kent & Atkinson             Standards Track                     [Page 4]

RFC 2402                IP Authentication Header           November 1998


2.5  Sequence Number

   This unsigned 32-bit field contains a monotonically increasing
   counter value (sequence number).  It is mandatory and is always
   present even if the receiver does not elect to enable the anti-replay
   service for a specific SA.  Processing of the Sequence Number field
   is at the discretion of the receiver, i.e., the sender MUST always
   transmit this field, but the receiver need not act upon it (see the
   discussion of Sequence Number Verification in the "Inbound Packet
   Processing" section below).

   The sender's counter and the receiver's counter are initialized to 0
   when an SA is established.  (The first packet sent using a given SA
   will have a Sequence Number of 1; see Section 3.3.2 for more details
   on how the Sequence Number is generated.)  If anti-replay is enabled
   (the default), the transmitted Sequence Number must never be allowed
   to cycle.  Thus, the sender's counter and the receiver's counter MUST
   be reset (by establishing a new SA and thus a new key) prior to the
   transmission of the 2^32nd packet on an SA.

2.6  Authentication Data

   This is a variable-length field that contains the Integrity Check
   Value (ICV) for this packet.  The field must be an integral multiple
   of 32 bits in length.  The details of the ICV computation are
   described in Section 3.3.2 below.  This field may include explicit
   padding.  This padding is included to ensure that the length of the
   AH header is an integral multiple of 32 bits (IPv4) or 64 bits
   (IPv6).  All implementations MUST support such padding.  Details of
   how to compute the required padding length are provided below.  The
   authentication algorithm specification MUST specify the length of the
   ICV and the comparison rules and processing steps for validation.

3.  Authentication Header Processing

3.1  Authentication Header Location

   Like ESP, AH may be employed in two ways: transport mode or tunnel
   mode.  The former mode is applicable only to host implementations and
   provides protection for upper layer protocols, in addition to
   selected IP header fields.  (In this mode, note that for "bump-in-
   the-stack" or "bump-in-the-wire" implementations, as defined in the
   Security Architecture document, inbound and outbound IP fragments may
   require an IPsec implementation to perform extra IP
   reassembly/fragmentation in order to both conform to this
   specification and provide transparent IPsec support.  Special care is
   required to perform such operations within these implementations when
   multiple interfaces are in use.)



Kent & Atkinson             Standards Track                     [Page 5]

RFC 2402                IP Authentication Header           November 1998


   In transport mode, AH is inserted after the IP header and before an
   upper layer protocol, e.g., TCP, UDP, ICMP, etc. or before any other
   IPsec headers that have already been inserted.  In the context of
   IPv4, this calls for placing AH after the IP header (and any options
   that it contains), but before the upper layer protocol.  (Note that
   the term "transport" mode should not be misconstrued as restricting
   its use to TCP and UDP.  For example, an ICMP message MAY be sent
   using either "transport" mode or "tunnel" mode.)  The following
   diagram illustrates AH transport mode positioning for a typical IPv4
   packet, on a "before and after" basis.

                  BEFORE APPLYING AH
            ----------------------------
      IPv4  |orig IP hdr  |     |      |
            |(any options)| TCP | Data |
            ----------------------------

                  AFTER APPLYING AH
            ---------------------------------
      IPv4  |orig IP hdr  |    |     |      |
            |(any options)| AH | TCP | Data |
            ---------------------------------
            |<------- authenticated ------->|