rfc1825.txt

来自「中、英文RFC文档大全打包下载完全版 .」· 文本 代码 · 共 1,236 行 · 第 1/4 页

     of the protected data [REQUIRED for all systems claiming
     to provide multi-level security, RECOMMENDED for all other systems].

   The sending host uses the sending userid and Destination Address to
   select an appropriate Security Association (and hence SPI value).
   The receiving host uses the combination of SPI value and Destination
   Address to distinguish the correct association.  Hence, an AH
   implementation will always be able to use the SPI in combination with
   the Destination Address to determine the security association and
   related security configuration data for all valid incoming packets.
   When a formerly valid Security Association becomes invalid, the
   destination system(s) SHOULD NOT immediately reuse that SPI value and
   instead SHOULD let that SPI value become stale before reusing it for
   some other Security Association.

   A security association is normally one-way.  An authenticated
   communications session between two hosts will normally have two
   Security Parameter Indexes in use (one in each direction).  The
   combination of a particular Security Parameter Index and a particular
   Destination Address uniquely identifies the Security Association.
   The Destination Address may be a unicast address or a multicast group
   address.






Atkinson                    Standards Track                     [Page 6]

RFC 1825              Security Architecture for IP           August 1995


   The receiver-orientation of the Security Association implies that, in
   the case of unicast traffic, the destination system will normally
   select the SPI value.  By having the destination select the SPI
   value, there is no potential for manually configured Security
   Associations that conflict with automatically configured (e.g., via a
   key management protocol) Security Associations.  For multicast
   traffic, there are multiple destination systems but a single
   destination multicast group, so some system or person will need to
   select SPIs on behalf of that multicast group and then communicate
   the information to all of the legitimate members of that multicast
   group via mechanisms not defined here.

   Multiple senders to a multicast group MAY use a single Security
   Association (and hence Security Parameter Index) for all traffic to
   that group.  In that case, the receiver only knows that the message
   came from a system knowing the security association data for that
   multicast group.  A receiver cannot generally authenticate which
   system sent the multicast traffic when symmetric algorithms (e.g.,
   DES, IDEA) are in use.  Multicast traffic MAY also use a separate
   Security Association (and hence SPI) for each sender to the multicast
   group .  If each sender has its own Security Association and
   asymmetric algorithms are used, then data origin authentication is
   also a provided service.

2. DESIGN OBJECTIVES

   This section describes some of the design objectives of this security
   architecture and its component mechanisms.  The primary objective of
   this work is to ensure that IPv4 and IPv6 will have solid
   cryptographic security mechanisms available to users who desire
   security.

   These mechanisms are designed to avoid adverse impacts on Internet
   users who do not employ these security mechanisms for their traffic.
   These mechanisms are intended to be algorithm-independent so that the
   cryptographic algorithms can be altered without affecting the other
   parts of the implementation.  These security mechanisms should be
   useful in enforcing a variety of security policies.

   Standard default algorithms (keyed MD5, DES CBC) are specified to
   ensure interoperability in the global Internet.  The selected default
   algorithms are the same as the standard default algorithms used in
   SNMPv2 [GM93].








Atkinson                    Standards Track                     [Page 7]

RFC 1825              Security Architecture for IP           August 1995


3. IP-LAYER SECURITY MECHANISMS

   There are two cryptographic security mechanisms for IP.  The first is
   the Authentication Header which provides integrity and authentication
   without confidentiality [Atk95a].  The second is the Encapsulating
   Security Payload which always provides confidentiality, and
   (depending on algorithm and mode) might also provide integrity and
   authentication [Atk95b].  The two IP security mechanisms may be used
   together or separately.

   These IP-layer mechanisms do not provide security against a number of
   traffic analysis attacks.  However, there are several techniques
   outside the scope of this specification (e.g., bulk link encryption)
   that might be used to provide protection against traffic analysis
   [VK83].

3.1 AUTHENTICATION HEADER

   The IP Authentication Header holds authentication information for its
   IP datagram [Atk95a].  It does this by computing a cryptographic
   authentication function over the IP datagram and using a secret
   authentication key in the computation.  The sender computes the
   authentication data prior to sending the authenticated IP packet.
   Fragmentation occurs after the Authentication Header processing for
   outbound packets and prior to Authentication Header processing for
   inbound packets.  The receiver verifies the correctness of the
   authentication data upon reception.  Certain fields which must change
   in transit, such as the "TTL" (IPv4) or "Hop Limit" (IPv6) field,
   which is decremented on each hop, are omitted from the authentication
   calculation.  However the omission of the Hop Limit field does not
   adversely impact the security provided.  Non-repudiation might be
   provided by some authentication algorithms (e.g., asymmetric
   algorithms when both sender and receiver keys are used in the
   authentication calculation) used with the Authentication Header, but
   it is not necessarily provided by all authentication algorithms that
   might be used with the Authentication Header.  The default
   authentication algorithm is keyed MD5, which, like all symmetric
   algorithms, cannot provide non-repudiation by itself.
   Confidentiality and traffic analysis protection are not provided by
   the Authentication Header.

   Use of the Authentication Header will increase the IP protocol
   processing costs in participating systems and will also increase the
   communications latency.  The increased latency is primarily due to
   the calculation of the authentication data by the sender and the
   calculation and comparison of the authentication data by each
   receiver for each IP datagram containing an Authentication Header
   (AH).



Atkinson                    Standards Track                     [Page 8]

RFC 1825              Security Architecture for IP           August 1995


   The Authentication Header provides much stronger security than exists
   in most of the current Internet and should not affect exportability
   or significantly increase implementation cost.  While the
   Authentication Header might be implemented by a security gateway on
   behalf of hosts on a trusted network behind that security gateway,
   this mode of operation is not encouraged.  Instead, the
   Authentication Header should be used from origin to final
   destination.

   All IPv6-capable hosts MUST implement the IP Authentication Header
   with at least the MD5 algorithm using a 128-bit key.  IPv4-systems
   claiming to implement the Authentication Header MUST implement the IP
   Authentication Header with at least the MD5 algorithm using a 128-bit
   key [MS95].  An implementation MAY support other authentication
   algorithms in addition to keyed MD5.

3.2 ENCAPSULATING SECURITY PAYLOAD

   The IP Encapsulating Security Payload (ESP) is designed to provide
   integrity, authentication, and confidentiality to IP datagrams
   [Atk95b].  It does this by encapsulating either an entire IP datagram
   or only the upper-layer protocol (e.g., TCP, UDP, ICMP) data inside
   the ESP, encrypting most of the ESP contents, and then appending a
   new cleartext IP header to the now encrypted Encapsulating Security
   Payload.  This cleartext IP header is used to carry the protected
   data through the internetwork.

3.2.1 Description of the ESP Modes

   There are two modes within ESP.  The first mode, which is known as
   Tunnel-mode, encapsulates an entire IP datagram within the ESP
   header.  The second mode, which is known as Transport-mode,
   encapsulates an upper-layer protocol (for example UDP or TCP) inside
   ESP and then prepends a cleartext IP header.

3.2.2 Usage of ESP

   ESP works between hosts, between a host and a security gateway, or
   between security gateways. This support for security gateways permits
   trustworthy networks behind a security gateway to omit encryption and
   thereby avoid the performance and monetary costs of encryption, while
   still providing confidentiality for traffic transiting untrustworthy
   network segments.  When both hosts directly implement ESP and there
   is no intervening security gateway, then they may use the Transport-
   mode (where only the upper layer protocol data (e.g., TCP or UDP) is
   encrypted and there is no encrypted IP header).  This mode reduces
   both the bandwidth consumed and the protocol processing costs for
   users that don't need to keep the entire IP datagram confidential.



Atkinson                    Standards Track                     [Page 9]

RFC 1825              Security Architecture for IP           August 1995


   ESP works with both unicast and multicast traffic.

3.2.3 Performance Impacts of ESP

   The encapsulating security approach used by ESP can noticeably impact
   network performance in participating systems, but use of ESP should
   not adversely impact routers or other intermediate systems that are
   not participating in the particular ESP association.  Protocol
   processing in participating systems will be more complex when
   encapsulating security is used, requiring both more time and more
   processing power.  Use of encryption will also increase the
   communications latency.  The increased latency is primarily due to
   the encryption and decryption required for each IP datagram
   containing an Encapsulating Security Payload.  The precise cost of
   ESP will vary with the specifics of the implementation, including the
   encryption algorithm, key size, and other factors.  Hardware
   implementations of the encryption algorithm are recommended when high
   throughput is desired.

   For interoperability throughout the worldwide Internet, all
   conforming implementations of the IP Encapsulating Security Payload
   MUST support the use of the Data Encryption Standard (DES) in
   Cipher-Block Chaining (CBC) Mode as detailed in the ESP
   specification.  Other confidentiality algorithms and modes may also
   be implemented in addition to this mandatory algorithm and mode.
   Export and use of encryption are regulated in some countries [OTA94].

3.3 COMBINING SECURITY MECHANISMS

   In some cases the IP Authentication Header might be combined with the
   IP Encapsulating Security Protocol to obtain the desired security
   properties.  The Authentication Header always provides integrity and
   authentication and can provide non-repudiation if used with certain
   authentication algorithms (e.g., RSA).  The Encapsulating Security
   Payload always provides integrity and confidentiality and can also
   provide authentication if used with certain authenticating encryption
   algorithms.  Adding the Authentication Header to a IP datagram prior
   to encapsulating that datagram using the Encapsulating Security
   Protocol might be desirable for users wishing to have strong
   integrity, authentication, confidentiality, and perhaps also for
   users who require strong non-repudiation.  When the two mechanisms
   are combined, the placement of the IP Authentication Header makes
   clear which part of the data is being authenticated.  Details on
   combining the two mechanisms are provided in the IP Encapsulating
   Security Payload specification [At94b].






Atkinson                    Standards Track                    [Page 10]

RFC 1825              Security Architecture for IP           August 1995


3.4 OTHER SECURITY MECHANISMS

   Protection from traffic analysis is not provided by any of the
   security mechanisms described above.  It is unclear whether
   meaningful protection from traffic analysis can be provided
   economically at the Internet Layer and it appears that few Internet
   users are concerned about traffic analysis.  One traditional method
   for protection against traffic analysis is the use of bulk link
   encryption.  Another technique is to send false traffic in order to
   increase the noise in the data provided by traffic analysis.
   Reference [VK83] discusses traffic analysis issues in more detail.

4. KEY MANAGEMENT

   The Key Management protocol that will be used with IP layer security
   is not specified in this document.  However, because the key
   management protocol is coupled to AH and ESP only via the Security
   Parameters Index (SPI), we can meaningfully define AH and ESP without
   having to fully specify how key management is performed.  We envision
   that several key management systems will be usable with these
   specifications, including manual key configuration.  Work is ongoing
   within the IETF to specify an Internet Standard key management
   protocol.

   Support for key management methods where the key management data is
   carried within the IP layer is not a design objective for these IP-
   layer security mechanisms.  Instead these IP-layer security
   mechanisms will primarily use key management methods where the key
   management data will be carried by an upper layer protocol, such as
   UDP or TCP, on some specific port number or where the key management
   data will be distributed manually.

   This design permits clear decoupling of the key management mechanism
   from the other security mechanisms, and thereby permits one to
   substitute new and improved key management methods without having to
   modify the implementations of the other security mechanisms.  This
   separation of mechanism is clearly wise given the long history of
   subtle flaws in published key management protocols [NS78, NS81].
   What follows in this section is a brief discussion of a few
   alternative approaches to key management.  Mutually consenting
   systems may additionally use other key management approaches by
   private prior agreement.

4.1 Manual Key Distribution

   The simplest form of key management is manual key management, where a
   person manually configures each system with its own key and also with
   the keys of other communicating systems.  This is quite practical in



Atkinson                    Standards Track                    [Page 11]