RFC 1825 (rfc1825) - Page 3 of 22


Security Architecture for the Internet Protocol



Alternative Format: Original Text Document



RFC 1825              Security Architecture for IP           August 1995


1.3 Typical Use

   There are two specific headers that are used to provide security
   services in IPv4 and IPv6.  These headers are the "IP Authentication
   Header (AH)" [Atk95a] and the "IP Encapsulating Security Payload
   (ESP)" [Atk95b] header.  There are a number of ways in which these IP
   security mechanisms might be used.  This section describes some of
   the more likely uses.  These descriptions are not complete or
   exhaustive.  Other uses can also be envisioned.

   The IP Authentication Header is designed to provide integrity and
   authentication without confidentiality to IP datagrams.  The lack of
   confidentiality ensures that implementations of the Authentication
   Header will be widely available on the Internet, even in locations
   where the export, import, or use of encryption to provide
   confidentiality is regulated.  The Authentication Header supports
   security between two or more hosts implementing AH, between two or
   more gateways implementing AH, and between a host or gateway
   implementing AH and a set of hosts or gateways.  A security gateway
   is a system which acts as the communications gateway between external
   untrusted systems and trusted hosts on their own subnetwork.  It also
   provides security services for the trusted hosts when they
   communicate with the external untrusted systems.  A trusted
   subnetwork contains hosts and routers that trust each other not to
   engage in active or passive attacks and trust that the underlying
   communications channel (e.g., an Ethernet) isn't being attacked.

   In the case where a security gateway is providing services on behalf
   of one or more hosts on a trusted subnet, the security gateway is
   responsible for establishing the security association on behalf of
   its trusted host and for providing security services between the
   security gateway and the external system(s).  In this case, only the
   gateway need implement AH, while all of the systems behind the
   gateway on the trusted subnet may take advantage of AH services
   between the gateway and external systems.

   A security gateway which receives a datagram containing a recognised
   sensitivity label, for example IPSO [Ken91], from a trusted host
   should take that label's value into consideration when
   creating/selecting an Security Association for use with AH between
   the gateway and the external destination.  In such an environment, a
   gateway which receives a IP packet containing the IP Encapsulating
   Security Payload (ESP) should add appropriate authentication,
   including implicit (i.e., contained in the Security Association used)
   or explicit label information (e.g., IPSO), for the decrypted packet
   that it forwards to the trusted host that is the ultimate
   destination.  The IP Authentication Header should always be used on
   packets containing explicit sensitivity labels to ensure end-to-end



Atkinson                    Standards Track