[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 rfc2401                                  
Network Working Group                                    Randall Atkinson
Internet Draft                                              cisco Systems
draft-ietf-ipsec-arch-sec-01.txt                         10 November 1996
Expire in six months

            Security Architecture for the Internet Protocol


        This document is an Internet Draft.  Internet Drafts are working
   documents of the Internet Engineering Task Force (IETF), its Areas, and its
   working groups.  Note that other groups may also distribute working
   documents as Internet Drafts.

        Internet Drafts are draft documents valid for a maximum of 6
   months.  Internet Drafts may be updated, replaced, or obsoleted by other
   documents at any time.  It is not appropriate to use Internet Drafts as
   reference material or to cite them other than as "work in progress".

        This particular Internet Draft is a product of the IETF's IP Security
   (IPsec) working group.  It is intended that a future version of this draft
   be submitted to the IESG for publication as a Draft Standard RFC.  Comments
   about this draft may be sent to the author or to the IPsec WG mailing list


        This memo describes the security protocols for IP version 4 (IPv4)
   and IP version 6 (IPv6) and the services that they provide.  Each security
   protocol is specified in a separate document.  This document also describes
   key management requirements for systems implementing these security
   protocols.  This document is not an overall Security Architecture for the
   Internet; it addresses only IP-layer security.

1.1 Technical Definitions

        This section provides a few basic definitions that are applicable
   to this document.  Other documents provide more definitions and background
   information. [VK83, HA94]

   Authentication (of Data Origin)

Atkinson                                                        [Page 1]

Internet Draft        Security Architecture for IP      10 November 1996

        A security property that ensures that the origin of received data
   is, in fact, the claimed sender.  Usually bundled with integrity services,
   especially connectionless integrity.

   Integrity (Connectionless)
        A security property that ensures data is transmitted from source to
   destination without undetected alteration.  If the order of
   transmitted data also is ensured, the service is termed
   connection-oriented integrity.  The term anti-replay refers to a
   minimal `qform of connection-oriented integrity designed to detect and
   reject duplicated or very old data units.

        A security property that ensures that communicated data is
   disclosed to intended recipients, but is not disclosed to other,
   unauthorized parties.  Traffic flow confidentiality extends this service to
   externally visible characteristics of communication, e.g., source and
   destination identifiers, message length, or frequency of communication.
   (See also traffic analysis, below.)

        A mechanism commonly used to provide confidentiality.

        A security property that ensures that a participant in a
   communication cannot later deny having participated in the communication.
   This property may apply to either the sender or the recipient of
   communccated data, or both.

        Acronym for "Security Parameters Index."  The combination of an SPI
   and a destination address uniquely identifies a simplex security
   association (SA, see below).  The SPI is carried in IPsec protocols to
   select the set of parameters bound to an SA.  An SPI has only local
   significance, defined by the creator of the SA; thus an SPI is generally
   viewed as an opaque bit string.  However, the creator of an SA may choose
   to interpret the bits in an SPI to facilitate local processing.

   Security Association (SA)
        A simplex (uni-directional) logical connection, created for
   security purposes.  All traffic traversing an SA is subjected to the same
   security processing at the transmitter and receiver.  In IPsec, an SA is a
   network layer abstraction enforced through the use of AH or ESP.

   Security Gateway
        A system that acts as the communications interface between
   untrusted external, networks and internal (trusted) hosts and subnetworks.

Atkinson                                                        [Page 2]

Internet Draft        Security Architecture for IP      10 November 1996

   The internal subnets and hosts served by a security gateway are presumed to
   be trusted by virtue of sharing a common, local, security administration.
   (See "Trusted Subnetwork" below.)  In the IPsec context, a security gateway
   is a point at which AH and/or ESP is implemented in order to serve a set of
   internal hosts, providing security services for these hosts when they
   communicate with external hosts also employing IPsec (either directly or
   via another security gateway).

   Traffic Analysis
        The analysis of network traffic flow for the purpose of deducing
   information that is useful to an adversary.  Examples of such information
   are frequency of transmission, the identities of the conversing parties,
   sizes of packets, flow Identifiers, etc. [Kent78]

   Trusted Subnetwork
        A subnetwork containing 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.

1.2 Requirements Terminology

        In this document, the words that are used to define the
   significance of each particular requirement are usually capitalised.  These
   words are:

   - MUST
        This word or the adjective "REQUIRED" means that implementation of
   the item is an absolute requirement of the specification.

        This word or the adjective "RECOMMENDED" means that there might
   exist valid reasons in particular circumstances to not implement this item,
   but the full implications should be understood and the case carefully
   weighed before taking a different course.

   - MAY
        This word or the adjective "OPTIONAL" means that this item is truly
   optional to implement.  One vendor might choose to include the item because
   a particular marketplace requires it or because it enhances the product,
   for example; another vendor may omit the same item.

1.3  Basic IPsec features

        Two specific headers used to provide security services in IPv4 and
   IPv6: 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 may be employed, in large
   part because AH and ESP may be used independently of one another, in

Atkinson                                                        [Page 3]

Internet Draft        Security Architecture for IP      10 November 1996

   combination with one another, or in an interated (nested) fashion.  This
   section describes the basic features of both protocols and typical uses of
   these protocols.  The next section defines the minimum header processing
   configurations that all compliant IPsec implementations must support.
   (Additional configurations may be supported at the discretion of the
   implementor.)  Thus the configuration examples in this and the next section
   are not exhaustive.

        The IP Authentication Header (AH) can be used to provide
   connectionless integrity and data origin authentication for IP datagrams,
   and optionally to provide anti-replay integrity.  This last, optional
   service may be selected when a security association is established.  This
   header protects an entire IP datagram, including all immutable fields in
   the IP header.  AH does not provide confidentiality; thus implementations
   of AH may be widely deployed, even in countries where controls on
   encryption would preclude deployment of technology that also offered
   confidentiality.  This header should be used whenever the integrity and
   authenticity of the IP header, as well as the associted upper layer
   protocols, must be ensured.  For example, AH can be used to bind a
   sensitivity label (e.g., IPSO [Kent91]) to an IP datagram.

       The Encapsulating Security Payload (ESP) can be used to provide
   confidentiality, data origin authentication, connectionless integrity,
   anti-replay integrity, and limited traffic flow confidentiality.  The set
   of services provided depends on options selected at the time of security
   association establishment and the implementation placement.
   Confidentiality may be selected independent of all other services.  Data
   origin authentication and connectionless integrity are joint services,
   independent of confidentiality.  Anti-replay may be selected only if data
   origin authentication and connectionless integrity are selected, but is
   independent of confidentiality.  Traffic flow confidentiality depends on
   confidentiality, and requires selection of tunnel mode (see below).

       Unlike AH, ESP provides security only for the protocols encapsulated by
   it, not the protocol that carries it.  Perhaps the most obvious use of ESP
   is to provide security services for upper layer protocols such as TCP,
   without affording protection to the IP header that carries the these
   protocols.  Because ESP is an encapsulation protocol, it may be employed
   recursively, to create nested security associations.  For example, one
   ESP-protected SA might extend between a host and a security gateway, and a
   second, nested ESP-protected SA might extend from the same host through the
   security gateway to a host behind the gateway.

       Two modes of ESP are defined: transport mode and tunnel mode.  In
   transport mode, ESP encapsulates any transport layer protocol defined for
   carriage in the TCP/IP suite, e.g., TCP, UDP.  This is the simplest mode
   for use between a pair of hosts implementing ESP.  In tunnel model, the
   protocol encapsulated by ESP is usually IP but could also be another

Atkinson                                                        [Page 4]

Internet Draft        Security Architecture for IP      10 November 1996

   network-layer protocol (e.g. IPX).  Tunnel mode is always used by security
   gateways for all packets not originating on the gateway, to facilitate
   operation in multi-homed environments, especially in the face of possible
   fragmentation of ESP-protected packets.  Tunnel mode can be used to create
   virtual private networks between sites protected by security gateways
   implementing ESP.

       Both AH and ESP can provide security services between a pair of
   communicating hosts, or between a pair of communicating security gateways
   or between a security gateway and a host.  Depending on the choice of
   algorithms, AH and ESP also may support multicast communication, e.g.,
   among a set of hosts or security gateways or combinations thereof.  When a
   security gateway provides services for hosts on a trusted subnet, the
   security gateway is responsible for establishing and managing security
   associations on behalf of the trusted hosts it serves.  The security
   gateway also is responsible for providing security services between the
   gateway itself and correspondant external systems (hosts or security
   gateways) through the implementation of AH and ESP.

1.4  Minimal Essential Support

        All IPsec-compliant implementations MUST support AH and MUST
   support ESP in both transport and tunnel modes.  The requirement to support
   tunnel-mode is imposed to ensure interoperability between host and security
   gateway implementations of ESP.  The requirement to support transport-mode
   ensures interoperability with other hosts using transport-mode and can
   permit some reduction in security overhead.

        A compliant host or security gateway implementation MUST be capable
   of creating and accepting security associations that employ either AH or
   ESP.  A compliant host or security gateway SHOULD also be capable of
   creating pairs of AH and ESP security associations.  A compliant host
   implementation also MUST also support a second (nested) ESP security
   association, in transport mode, above a tunnel mode ESP security

        The following sequences of combinations of AH and ESP, each
   represented by a separate security association, must be supported by an
   IPsec-compliant host: AH, ESP (tunnel), ESP(transport), AH-ESP(transport),
   AH-ESP(tunnel), ESP(tunnel)-AH, AH-ESP(tunnel)-ESP(transport), and

        The following sequences of combinations of AH and ESP must be
   supported by a compliant IPsec security gateway: AH, ESP (tunnel), and
   AH-ESP(tunnel).  Note that transport-mode ESP security associations may be
   employed across a security gateway, terminating at hosts behind the
   gateway.  The gateway does not process these SAs; they are passed through
   transparently, and hence there is no required "support" in the gateway for

Atkinson                                                        [Page 5]

Internet Draft        Security Architecture for IP      10 November 1996

   these header combinations.

        A security gateway which receives a datagram containing a
   recognised sensitivity label, for example IPSO [Ken91], from a trusted host
   MUST 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
   label integrity.  In environments using security gateways, those gateways
   MUST perform address-based IP packet filtering on unauthenticated packets
   purporting to be from a system known to be using IP security.

      A gateway which receives a datagram containing a recognised sensitivity
   label from a trusted host should take that label's value into consideration
   when creating/selecting a Security Association for use with ESP between the
   gateway and the external destination.  In such an environment, a gateway
   which receives a IP packet containing the ESP should appropriately label
   the decrypted packet that it forwards to the trusted host that is the
   ultimate destination.  IP security should always be used on packets
   containing explicit sensitivity labels in a manner to ensure end-to-end
   label integrity.

        Routing headers for which integrity has not been cryptographically
   protected SHOULD be ignored by the receiver.  If this rule is not strictly
   adhered to, then the system will be vulnerable to various kinds of attacks,
   including source routing attacks. [Bel89][CB94][CERT95]

1.5 Security Association Management

        The concept of a "Security Association" is fundamental to both the
   IP Encapsulating Security Payload and the IP Authentication Header.  The
   combination of a given Security Parameter Index (SPI) and Destination
   Address uniquely identifies a particular "Security Association".  An
   implementation of the Authentication Header or the Encapsulating Security
   Payload MUST support this concept of a Security Association.

        A single IPsec Security Association is a simplex (unidirectional)
   connection with which either AH or ESP (but not both) is employed.  If both
   AH and ESP protection is to be applied to a traffic stream, then two (or
   more) security associations are created to control processing of the
   traffic stream.

        A compliant implementation of IPsec Security Association MUST

Atkinson                                                        [Page 6]

Internet Draft        Security Architecture for IP      10 November 1996

   support the following management parameters for each SA; other parameters
   MAY also be included at the discretion of the implementor:

           - Authentication algorithm and mode being used for AH or ESP.
             [REQUIRED for all implementations].
           - Key(s) used with the above authentication algorithm
             [REQUIRED for all implementations].
           - Encryption algorithm and mode used with ESP.
          [REQUIRED for ESP implementations]
           - Key(s) used with the above encryption algorithm.
             [REQUIRED for ESP implementations]
           - Presence/absence and size of a cryptographic synchronisation or
             initialisation vector field for the encryption algorithm.
             [REQUIRED for ESP implementations]
           - Authentication key crypto period (fixed future time or duration).
             [REQUIRED for all implementations].
           - Encryption key crypto period (fixed future tie or duration)
             [REQUIRED for ESP implementations]
           - Lifetime of this Security Association
          [REQUIRED for all implementations]
           - Destination IP Address of the Security Association; this may be
             a wildcard address if more than one desitnation system shares the
             same Security Association (behind a security gateway)
          [REQUIRED for all implementations]
           - Source IP Address(es) of the Security Association; this might be
             a wildcard address if more than one sending system shares the
             same Security Association with the destination
          [REQUIRED for all implementations]
        - Proxy IP Address of the Security Association; this contains
          the IP address of the security gateway that provides security
          services on behalf of the source IP address when IPsec is
          not in use end-to-end from source to destination.
          [REQUIRED for Security Gateways;
           RECOMMENDED for all other implementations]
           - Replay Protection information, including whether it is in use,
             information on the window size for the sequence numbers, etc.
             [REQUIRED for all implementations]
           - Sensitivity level of the protected data (e.g., in IPSO terms)
          [REQUIRED for all systems claiming to provide multi-level
          security, RECOMMENDED for all other systems]
        - Next Protocol (from IP header) as an optional SA selector
          input for outbound traffic
          [RECOMMENDED for all implementations]
        - Source and/or Destination TCP/UDP Ports as an optional SA
          selector for outbound traffic
          [RECOMMENDED for all implementations]
        - Identity of the source of the Security Association
          [RECOMMENDED for all implementations]

Atkinson                                                        [Page 7]

Internet Draft        Security Architecture for IP      10 November 1996

        - Identity of the destination of the Security Association]
          [RECOMMENDED for all implementations]

        The  way  in  which security associations are matched to offered
   (outbound) traffic varies based on whether IPsec is implemented in  a
   host  or  a security gateway, and on the granularity of SA management
   selected.  At a host, the inputs to SA selection are  the  userid  of
   the  sender,  the  Destination  Address  (perhaps  including the next
   protocol  field  and  source  and/or  destination  port  fields   and
   source/destination  identities)  is  used  to  select the appropriate
   Security Association for outbound traffic.  For a multi-level  secure
   host, the senstivity of the traffic, e.g., as expressed in a security
   label, also is an input to the  SA  selection.   A  security  gateway
   generally  does  not have access to userid information and thus IPsec
   implementations in such devices are not required to  select  SAs  for
   outbound  traffic  on that basis.  Since a security gateway typically
   serves a number of hosts, the Source Address (perhaps  including  the
   next  protocol field and source and/or destination port fields) is an
   input to the SA selection.  The Destination Address address  also  is
   an  input, and when in a multi-level secure network context a traffic
   sensitivity label is a REQUIRED additional input.

        Processing for received (inbound) IPsec traffic is much simpler.
   The   receiving  host  uses  the  combination  of  the  SPI  and  the
   Destination Address to distinguish the correct  association.   Hence,
   an  IPsec  implementation  will  always  be  able  to  use the SPI in
   combination with the Destination Address to  determine  the  security
   association  with  which  the traffic is associated.  When a formerly
   valid Security Association is terminated, the  destination  system(s)
   SHOULD NOT immediately reuse that SPI and instead SHOULD let that SPI
   value  become  stale  before  reusing  it  for  some  other  Security

        As noted above, an IPsec Security Association is unidirectional.
   Hence, to secure typical, bi-directional communications  between  two
   hosts  (or security gateways), two Security Associations (one in each
   direction) will be  required.   The  Destination  Address  may  be  a
   unicast  address,  an  IPv4  broadcast  address, or a multicast group

        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

Atkinson                                                        [Page 8]

Internet Draft        Security Architecture for IP      10 November 1996

   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  SHOULD  use  a  single
   Security  Association  (and  hence  Security Parameter Index) for all
   traffic to that group when a symmetric cryptographic algorithm is  in
   use.   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 SHOULD use a separate
   Security Association for each sender to the multicast group  when  an
   asymmetric cryptographic algorithm is in use.  In this last case, the
   receiver can know the specific system that originated the message.


        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

        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  HMAC MD5, Keyed HMAC SHA,
   DES- CBC) are specified to  ensure  interoperability  in  the  global
   Internet.   The  selected default algorithms are widely used in other


        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 usually provides integrity and authentication. [Atk95b]  The  two
   IP  security  mechanisms  are  normally  used  separately.  When both
   confidentiality  and  authentication  are  needed,  a  combined   ESP
   transform should be used instead of using AH with ESP.

Atkinson                                                        [Page 9]

Internet Draft        Security Architecture for IP      10 November 1996

        These  IP-layer  mechanisms  do  not  provide  complete security
   against all traffic analysis attacks, though the use of  ESP  between
   security  gateways  can  provide  partial  traffic  flow  protection.
   However, there are several  techniques  outside  the  scope  of  this
   specification  (e.g.   bulk  link  encryption)  that might be used to
   provide  more  comprehensive  protection  against  traffic  analysis.


        The   IP   Authentication   Header   is   designed   to  provide
   authentication, integrity, and replay  protection  to  IP  datagrams.
   [Atk95a]  It  does  this  by computing a cryptographic authentication
   function over the IP datagram and using one  or  more  authentication
   keys  in the computation.  The authentication algorithm may be either
   symmetric or asymmetric.  The sender computes the authentication data
   prior   to  sending  the  authenticated  IP  packet  and  places  the
   authentication data inside the  Authentication  Data.   Fragmentation
   occurs  after  the  Authentication  Header  processing  for  outbound
   packets  and  reassembly  occurs  prior  to   Authentication   Header
   processing   for   inbound   packets.    The  receiver  verifies  the
   correctness of the authentication data upon reception.

        Certain fields of the outer IP header that may change in transit
   are  zeroed  for  the  authentication  calculation.   For IPv4, these
   fields are:

        Type of Service (TOS)
        Time  To  Live  (TTL)

        Also,  IPv4  options   are   zeroed   for   the   authentication
   calculation, except for the IP Security Option BSO and ESO (RFC-1038,
   RFC-1108) and the undocumented non-standard CIPSO (IPv4 Option number
   134) option, which are included and are not zeroed.

        For IPv6, the "IP Version", "Type of Service", "Flow Label", and
   "Hop Limit" fields of the outermost IPv6 header are  zeroed  for  the
   authentication   calculation.    IPv6  options  contain  a  bit  that
   indicates whether the option might change  during  transit.   Options
   that  might  change  during transit are zeroed for the authentication
   calculation  and  all  others  are  included  in  the  authentication
   calculation.  See the IPv6 specifications for more information.

        Non-repudiation is not normally provided with the Authentication
   Header.  Confidentiality and  traffic  analysis  protection  are  not

Atkinson                                                       [Page 10]

Internet Draft        Security Architecture for IP      10 November 1996

   provided  by the Authentication Header. Replay Protection is normally
   provided by the Authentication Header, though a user might choose not
   to use it.

        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

        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, whenever possible
   the  Authentication  Header  should  be  used  from  origin  to final
   destination so that end-to-end protections are provided.

        All  IPv6-capable  nodes  and  all  IPv4  systems  claiming   to
   implement  the  Authentication  Header  MUST implement the standards-
   track mandatory-to- implement AH  transforms.   As  of  this  writing
   these  are  HMAC  MD5  [OG96]  and  HMAC SHA [CG96], but implementers
   should consult the most recent  edition  of  the  "Internet  Official
   Protocol  Standards" [STD-1] for current guidance.  An implementation
   MAY support  other  authentication  algorithms  in  addition  to  the
   mandatory transforms.


        The  IP  Encapsulating  Security  Payload  (ESP)  is designed to
   provide  integrity,  authentication,  and   confidentiality   to   IP
   datagrams.  [Atk96b] ESP can also provide replay protection when used
   with certain  transforms.   ESP  encapsulates  either  an  entire  IP
   datagram  or only the upper-layer protocol (e.g. TCP, UDP, ICMP) data
   inside the ESP, applies integrity and authentication protections, and
   encrypts  the  data.   If  tunnel-mode  is in use, a new cleartext IP
   header is prepended  to  the  now  encrypted  Encapsulating  Security
   Payload.   In  tunnel-mode,  the 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-

Atkinson                                                       [Page 11]

Internet Draft        Security Architecture for IP      10 November 1996

   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.  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 gateways 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 also implement the standard mandatory ESP transform.  As of this
   writing, that is the Combined ESP transform with DES-CBC,  HMAC  MD5,
   and  Replay Protection. [Hugh96] Implementers should consult the most
   recent "IAB Official Protocols" RFC for current  information  on  the
   mandatory  to  implement  ESP  transform(s).   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]

Atkinson                                                       [Page 12]

Internet Draft        Security Architecture for IP      10 November 1996


        A node normally does not apply both ESP and AH to  the  same  IP
   datagram.   If  confidentiality  is  not  required, then AH should be
   used.  If confidentiality is required, then ESP should be  used.   In
   some  circumstances  a  security gateway might apply ESP (or AH) to a
   packet before forwarding that packet because a secure tunnel has been
   configured  in  that  security gateway.  Hence, IP packets containing
   both ESP and AH are not strictly prohibited.


        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.


        The Security Management protocol that will be used with IP layer
   security  is  not  specified  in this document.  However, because the
   security 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  security  management  is
   performed.  We envision that several security management systems will
   be  usable  with   these   specifications,   including   manual   key

        Support for key management methods where the key management data
   is carried in-line 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

Atkinson                                                       [Page 13]

Internet Draft        Security Architecture for IP      10 November 1996

   approaches  to  key  management.   Mutually  consenting  systems  may
   additionally use other key management  approaches  by  private  prior

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  small,  static environments but does not scale.  It is
   not  a  viable  medium-term  or  long-term  approach,  but  might  be
   appropriate  and  useful  in many environments in the near-term.  For
   example, within a small LAN it  is  entirely  practical  to  manually
   configure  keys  for  each  system.   Within  a single administrative
   domain it is practical to configure keys for each router so that  the
   routing  data  can be protected and to reduce the risk of an intruder
   breaking into a router.  Another case is where an organisation has an
   encrypting  firewall between the internal network and the Internet at
   each of its sites and it connects two or more sites via the Internet.
   In  this case, the security gateway might selectively encrypt traffic
   for other sites within the organisation using a  manually  configured
   key,  while  not  encrypting traffic for other destinations.  It also
   might be appropriate when only selected  communications  need  to  be

4.2 Requirements for Key Management Protocols

        Widespread  deployment  and  use  of  IP  security  requires  an
   Internet-standard scalable key management  protocol.   This  protocol
   should  not  be  limited  to  supporting  IP security.  This protocol
   should be compatible with the IETF's DNS  Security  work  and  should
   include  the ability to obtain bootstrapping information (e.g.  keys,
   addresses) from the Secure DNS as a  mandatory-to-implement  feature.
   signed host keys to the Domain Name System [EK96] The DNS keys enable
   the originating party to authenticate key  management  messages  with
   the  other  key  management  party  using an asymmetric algorithm.  A
   standards-track key management protocol for use with IP Security MUST
   provide  the property of "Perfect Forward Secrecy" as a mandatory-to-
   implement  feature.   Further,  any  standards-track  key  management
   protocol  MUST permit the secure negotiation or secure identification
   of all of the Security Association attributes [as defined  above]  to
   all parties of that Security Association.

4.4 Keying Approaches for IP

        There are several keying approaches for IP.  The first approach,
   called host-oriented keying, has all users on host 1 share  the  same
   key  for use on traffic destined for all users on host 2.  The second

Atkinson                                                       [Page 14]

Internet Draft        Security Architecture for IP      10 November 1996

   approach, called user-oriented keying, lets user A on host 1 have one
   or more unique session keys for its traffic destined for host 2; such
   session keys are not shared with other users on host1.  For  example,
   user  A's  ftp session might use a different key than user A's telnet
   session.  In systems claiming to provide multi-level security, user A
   will  typically  have  at  least one key per sensitivity level in use
   (e.g.  one key for UNCLASSIFIED traffic,  a  second  key  for  SECRET
   traffic,  and  a  third key for TOP SECRET traffic).  Similarly, with
   user-oriented keying one might use separate keys for information sent
   to  a multicast group and control messages sent to the same multicast
   group.  A third approach, called session-unique keying, has a  single
   key  being  assigned to a given IP address, upper-layer protocol, and
   port number triple.

        In many cases, a single computer system will have at  least  two
   mutually suspicious users A and B that do not trust each other.  When
   host-oriented keying is used and mutually suspicious users exist,  it
   is  sometimes  possible for user A to determine the host-oriented key
   via well known methods, such as a Chosen Plaintext attack.  Once user
   A has improperly obtained the key in use, user A can then either read
   user B's encrypted traffic or forge traffic from user B.  When  user-
   oriented  keying  is used, certain kinds of attack from one user onto
   another user's traffic are not possible.

        IP Security is intended to be able  to  provide  Authentication,
   Integrity,   and   Confidentiality   for  applications  operating  on
   connected  end  systems  when  appropriate  algorithms  are  in  use.
   Integrity and Confidentiality can be provided by host-oriented keying
   when appropriate dynamic key management  techniques  and  appropriate
   algorithms  are  in use.  However, authentication of principals using
   applications  on  end-systems   requires   that   processes   running
   applications   be   able  to  request  and  use  their  own  Security
   Associations.  In this manner,  applications  can  make  use  of  key
   distribution facilities that provide authentication.

        Hence,  support for session-unique keying MUST be present in all
   IP Security implementations,  as  is  described  in  the  "IPsec  Key
   Management Requirements" section below.  Support for other styles MAY
   also be implemented.

4.5 Multicast Key Distribution

        Multicast key distribution is an active  research  area  in  the
   published literature as of this writing.  For multicast groups having
   relatively few members, manual key distribution or  multiple  use  of
   existing unicast key distribution algorithms such as modified Diffie-
   Hellman appears  feasible.   For  very  large  groups,  new  scalable
   techniques  will be needed.  In-line key management systems that rely

Atkinson                                                       [Page 15]

Internet Draft        Security Architecture for IP      10 November 1996

   on pre-distributed master keys and then have serious  scaling  issues
   that make them questionable for multicast traffic.

4.6 IPsec Key Management Requirements

        This  section  defines  key management requirements for all IPv6
   implementations and for those IPv4 implementations that implement the
   IP  Authentication  Header, the IP Encapsulating Security Payload, or
   both.  It applies equally to the IP Authentication Header and the  IP
   Encapsulating Security Payload.

        All  such  implementations  MUST support manual configuration of
   Security Associations, including all of the attributes  described  in
   the  Security Association definition section of this document, having
   variable SPI values within the non-reserved range.  An implementation
   that  only supports a fixed SPI value is NOT conforming or compliant.

        All   IPv6   IP   Security   implementations   MUST    implement
   ISAKMP/Oakley.  All IPv4 IP Security implementations SHOULD implement
   ISAKMP/Oakley.   Other  key  management   protocols   MAY   also   be
   implemented. [Sch96]

        Implementations  MAY  also  support other methods of configuring
   Security Associations.

        Given two endpoints, it MUST be possible to have more  than  one
   concurrent  Security  Association  for  communications  between them.
   Implementations on multi-user hosts  having  at  least  discretionary
   access  controls  MUST  support  either user granularity (i.e. "user-
   oriented")   Security   Associations   or   session-unique   Security

        All  such implementations MUST permit the configuration of host-
   oriented keying.

        A device that encrypts or authenticates IP packets originated by
   other  systems,  for  example a dedicated IP encryptor or an security
   gateway, cannot generally provide user-oriented  keying  for  traffic
   originating  on  other  systems.   Such systems MUST support session-
   unique key selection based on source  address,  destination  address,
   upper-layer  protocol, source port (if any), and destination port (if
   any). Such systems  MAY  additionally  implement  support  for  user-
   oriented keying for traffic originating on other systems.

        The  method  by which keys are configured on a particular system
   is  implementation-defined.   A   flat   file   containing   security
   association  identifiers  and  the security parameters, including the
   key(s),  is  an  example  of  one  possible  method  for  manual  key

Atkinson                                                       [Page 16]

Internet Draft        Security Architecture for IP      10 November 1996

   distribution.   An  IP  Security  implementation MUST take reasonable
   steps to protect the keys and other security association  information
   from  unauthorised  examination  or  modification  because all of the
   security lies in the keys.


        This  section  describes  the  possible  use  of  the   security
   mechanisms  provided  by  IP  in  several  different environments and
   applications in order to give the implementer and user a better  idea
   of how these mechanisms can be used to reduce security risks.


        Firewalls  are  not  uncommon  in  the current Internet.  [CB94]
   While many dislike their presence because they restrict connectivity,
   they  are unlikely to disappear in the near future.  Both of these IP
   mechanisms  can  be  used  to  increase  the  security  provided   by

        Firewalls  used  with  IP  often  need  to  be able to parse the
   headers and options to determine the transport protocol (e.g. UDP  or
   TCP)  in use and the port number for that protocol.  Firewalls can be
   used with  the  Authentication  Header  regardless  of  whether  that
   firewall is party to the appropriate Security Assocation.  However, a
   firewall that is not party to  the  applicable  Security  Association
   will  not  normally  be  able  to  decrypt  an  encrypted upper-layer
   protocol to view the protocol or port number needed to  perform  per-
   packet filtering.

        Further,  firewalls  need to verify that the data (e.g.  source,
   destination, transport protocol, port number) being used  for  access
   control  decisions  is  correct and authentic.  Hence, authentication
   might be performed not only within an organisation or campus but also
   end  to end with remote systems across the Internet.  This use of the
   Authentication Header with IP provides much more assurance  that  the
   data being used for access control decisions is authentic.

        Organisations  with  two  or  more sites that are interconnected
   using  commercial  IP  service  might  wish  to  use  a   selectively
   encrypting  firewall.   If an encrypting firewall were placed between
   each site of a company and the commercial IP  service  provider,  the
   firewall could provide an encrypted IP tunnel among all the company's
   sites.  It could also encrypt traffic between  the  company  and  its
   suppliers, customers, and other affiliates.  Traffic with the Network
   Information Center, with public  Internet  archives,  or  some  other
   organisations might not be encrypted because of the unavailability of
   a standard key management protocol  or  as  a  deliberate  choice  to

Atkinson                                                       [Page 17]

Internet Draft        Security Architecture for IP      10 November 1996

   facilitate  better  communications, improved network performance, and
   increased connectivity.  Such a practice  could  easily  protect  the
   company's sensitive traffic from eavesdropping and modification.

        Some organisations (e.g.  governments) might wish to use a fully
   encrypting firewall to provide a Virtual Private Network  (VPN)  over
   commercial  IP  service.   The  difference between that and a bulk IP
   encryption device is that a fully encrypting firewall  would  provide
   filtering of the decrypted traffic as well as providing encryption of
   IP packets.  A related scenario is to use encryption between a mobile
   computer  and the security gateway or encrypting firewall of its home


        In the past several years, the Multicast  Backbone  (MBONE)  has
   grown rapidly.  IETF meetings and other conferences are now regularly
   multicast with real-time audio, video, and whiteboards.  Many  people
   are  now using teleconferencing applications based on IP Multicast in
   the Internet or in private internal networks.  Others  are  using  IP
   multicasting to support distributed simulation or other applications.
   Hence it is important that the security mechanisms in IP be  suitable
   for use in an environment where multicast is the general case.

        The  Security  Parameters Indexes (SPIs) used in the IP security
   mechanisms are receiver-oriented, making them well suited for use  in
   IP   multicast.    [Atk95a,  Atk95b]  Unfortunately,  most  currently
   published multicast key distribution protocols  do  not  scale  well.
   However,  there is active research in this area.  As an interim step,
   a  multicast  group  could  repeatedly  use  a  secure  unicast   key
   distribution  protocol  to  distribute  the key to all members or the
   group could pre-arrange keys using manual key distribution.


        The recent IAB Security Workshop identified Quality  of  Service
   protection  as  an  area  of  significant interest. [BCCH] The two IP
   security mechanisms are intended to provide good  support  for  real-
   time  services  as  well as multicasting.  This section describes one
   possible approach to providing such protection.

        The Authentication Header might be used,  with  appropriate  key
   management,    to    provide   authentication   of   packets.    This
   authentication is  potentially  important  in  packet  classification
   within  routers.   The  IPv6 Flow Identifier might act as a Low-Level
   Identifier  (LLID).   Used  together,  packet  classification  within
   routers  becomes  straightforward  if the router is provided with the
   appropriate keying material.  For  performance  reasons  the  routers

Atkinson                                                       [Page 18]

Internet Draft        Security Architecture for IP      10 November 1996

   might  authenticate  only  every Nth packet rather than every packet,
   but this is still a significant improvement over capabilities in  the
   current  Internet.  Quality of service provisioning is likely to also
   use the Flow ID in conjunction with a resource reservation  protocol,
   such as RSVP. [ZDESZ93] Thus, the authenticated packet classification
   can be used to help ensure  that  each  packet  receives  appropriate
   handling inside routers.


        A multi-level secure (MLS) network is one where a single network
   is used to communicate data at  different  sensitivity  levels  (e.g.
   Unclassified  and  Secret).   [DoD85]  [DoD87]  Many governments have
   significant interest  in  MLS  networking.   [DIA]  The  IP  security
   mechanisms  have  been  designed  to  support  MLS  networking.   MLS
   networking requires the  use  of  strong  Mandatory  Access  Controls
   (MAC),   which   ordinary  users  are  incapable  of  controlling  or
   violating. [BL73] This section pertains only to the use of  these  IP
   security mechanisms in MLS environments.

        The   Authentication  Header  can  be  used  to  provide  strong
   authentication  among  hosts  in   a   single-level   network.    The
   Authentication  Header  can  also be used to provide strong assurance
   for both mandatory access control decisions in  multi-level  networks
   and  discretionary access control decisions in all kinds of networks.
   If explicit IP sensitivity labels (e.g. IPSO) [Ken91]  are  used  and
   confidentiality  is  not  considered  necessary within the particular
   operational environment, the Authentication Header is used to provide
   authentication for the entire packet, including cryptographic binding
   of the sensitivity level to the IP header and user data.  This  is  a
   significant improvement over labeled IPv4 networks where the label is
   trusted even though  it  is  not  trustworthy  because  there  is  no
   authentication or cryptographic binding of the label to the IP header
   and user data.  IPv6 will normally use  implicit  sensitivity  labels
   that  are  part  of the Security Association but not transmitted with
   each packet  instead  of  using  explicit  sensitivity  labels.   All
   explicit  IP  sensitivity  labels  MUST be authenticated using either
   ESP, AH, or both.

        The  Encapsulating  Security  Payload  can  be   combined   with
   appropriate   key   policies   to  provide  full  multi-level  secure
   networking.  In this case each key must be  used  only  at  a  single
   sensitivity  level  and  compartment.   For example, Key "A" might be
   used only for sensitive Unclassified packets, while Key "B"  is  used
   only for Secret/No-compartments traffic, and Key "C" is used only for
   Secret/Compartment-X traffic.  The sensitivity level of the protected
   traffic  MUST  NOT  dominate  the  sensitivity  level of the Security
   Association used with that traffic.  The  sensitivity  level  of  the

Atkinson                                                       [Page 19]

Internet Draft        Security Architecture for IP      10 November 1996

   Security  Association  MUST NOT dominate the sensitivity level of the
   key that belongs to that Security Association.  The sensitivity level
   of  the  key  SHOULD  be  the  same  as  the sensitivity level of the
   Security  Association.   The  Authentication  Header  can  also  have
   different keys for the same reasons, with the choice of key depending
   in part on the sensitivity level of the packet.

        Encryption is very useful and desirable even  when  all  of  the
   hosts  are  within  a  protected  environment.  The Internet-standard
   encryption algorithm could be used, in conjunction  with  appropriate
   key management, to provide strong Discretionary Access Controls (DAC)
   in conjunction with either implicit sensitivity  labels  or  explicit
   sensitivity  labels  (such  as  IPSO provides for IPv4 [Ken91]). Some
   environments  might   consider   the   Internet-standard   encryption
   algorithm  sufficiently  strong  to provide Mandatory Access Controls
   (MAC).  Full encryption should be used for all communications between
   multi-level  computers  or  compartmented mode workstations even when
   the computing environment is considered to be protected.


        This entire draft discusses the Security  Architecture  for  the
   Internet Protocol.  It is not a general security architecture for the
   Internet, but is instead focused on the IP layer.

        Cryptographic transforms for  ESP  which  use  a  block-chaining
   algorithm  and  lack a strong integrity mechanism are vulnerable to a
   cut-and-paste attack described by Bellovin and  should  not  be  used
   unless the Authentication Header is always present with packets using
   that ESP transform. [Bel95]

        If more than one sender shares a  Security  Association  with  a
   destination, then the receiving system can only authenticate that the
   packet was sent from one of those  systems  and  cannot  authenticate
   which  of  those systems sent it.  Similarly, if the receiving system
   does not check that the Security Association used  for  a  packet  is
   valid  for  the  claimed  Source  Address  of  the  packet,  then the
   receiving system cannot authenticate  whether  the  packet's  claimed
   Source  Address  is  valid.  For example, if senders "A" and "B" each
   have their own unique Security Association with destination  "D"  and
   "B"  uses  its  valid Security Association with D but forges a Source
   Address of "A", then "D" will be fooled  into  believing  the  packet
   came  from "A" unless "D" verifies that the claimed Source Address is
   party to the Security Association that was used.

        Users need to  understand  that  the  quality  of  the  security
   provided  by  the  mechanisms  provided  by  these  two  IP  security
   mechanisms depends completely on  the  strength  of  the  implemented

Atkinson                                                       [Page 20]

Internet Draft        Security Architecture for IP      10 November 1996

   cryptographic  algorithms,  the  strength  of the key being used, the
   correct implementation of the cryptographic algorithms, the  security
   of  the key management protocol, and the correct implementation of IP
   and the several security  mechanisms  in  all  of  the  participating
   systems.   The  security  of the implementation is in part related to
   the security of the operating  system  which  embodies  the  security
   implementations.   For example, if the operating system does not keep
   the private cryptologic keys (that is, all  symmetric  keys  and  the
   private  asymmetric keys) confidential, then traffic using those keys
   will not be secure.  If any of these is incorrect  or  insufficiently
   secure,  little  or  no  real  security will be provided to the user.
   Because different users on the  same  system  might  not  trust  each
   other,  each user or each session should usually be keyed separately.
   This will also tend to increase the work required to cryptanalyse the
   traffic since not all traffic will use the same key.

        Certain  security  properties (e.g. traffic analysis protection)
   are not provided by any of these mechanisms.  One  possible  approach
   to traffic analysis protection is appropriate use of link encryption.
   [VK83] Users must carefully consider which security  properties  they
   require  and  take active steps to ensure that their needs are met by
   these or other mechanisms.

        Certain applications (e.g. electronic  mail)  probably  need  to
   have  application-specific security mechanisms.  Application-specific
   security mechanisms are out of the scope  of  this  document.   Users
   interested  in  electronic  mail  security  should  consult  the RFCs
   describing  the  Internet's  Privacy-Enhanced  Mail  system.    Users
   concerned  about other application-specific mechanisms should consult
   the online RFCs to  see  if  suitable  Internet  Standard  mechanisms


        Steve  Kent  provided  detailed and helpful editorial input into
   this draft.  His contributions improved the draft significantly.

        Many of the concepts here are derived from or were influenced by
   the  US  Government's  SDNS  security  protocol  specifications,  the
   ISO/IEC's NLSP specification, or from  the  proposed  swIPe  security
   protocol.  [SDNS,  ISO,  IB93, IBK93] The work done for SNMP Security
   and SNMPv2 Security influenced the choice  of  default  cryptological
   algorithms  and  modes.  [GM93]  Steve  Bellovin, Steve Deering, Phil
   Karn, Frank Kastenholz, Steve Kent,  Perry  Metzger,  Dave  Mihelcic,
   Hilarie  Orman and Bill Simpson provided careful critiques of earlier
   versions of this draft.

Atkinson                                                       [Page 21]

Internet Draft        Security Architecture for IP      10 November 1996


   [Atk96a] Randall Atkinson, IP Authentication Header, RFC-xxxx, 4 June 1996.

   [Atk96b] Randall Atkinson, IP Encapsulating Security Payload, RFC-xxxx,
            4 June 1996.

   [BCCH94] R. Braden, D. Clark, S. Crocker, & C. Huitema, "Report of IAB
            Workshop on Security in the Internet Architecture", RFC-1636,
            DDN Network Information Center, June 1994.

   [Bel89]  Steven M. Bellovin, "Security Problems in the TCP/IP Protocol
            Suite", ACM Computer Communications Review, Vol. 19, No. 2,
            March 1989.

   [Bel95]  Steven M. Bellovin, Presentation at IP Security Working Group
            Meeting, Proceedings of the 32nd Internet Engineering Task
            Force, March 1995, Internet Engineering Task Force, Danvers, MA.

   [BL73]   Bell, D.E. & LaPadula, L.J., "Secure Computer Systems: Mathematical
            Foundations and Model", Technical Report M74-244, The MITRE
            Corporation, Bedford, MA, May 1973.

   [CERT95] CA-95:01

   [CB94]   William R. Cheswick & Steven M. Bellovin, Firewalls & Internet
            Security, Addison-Wesley, Reading, MA, 1994.

   [CG96]   Shu-jen Chang & Rob Glenn, "HMAC-SHA IP Authentication with Replay
         Prevention", Internet Draft, 1 May 1996.

   [DIA]    US Defense Intelligence Agency, "Compartmented Mode Workstation
            Specification", Technical Report DDS-2600-6243-87.

   [DoD85]  US National Computer Security Center, "Department of Defense
            Trusted Computer System Evaluation Criteria", DoD 5200.28-STD,
            US Department of Defense, Ft. Meade, MD., December 1985.

   [DoD87]  US National Computer Security Center, "Trusted Network
            Interpretation of the Trusted Computer System Evaluation Criteria",
            NCSC-TG-005, Version 1, US Department of Defense, Ft. Meade, MD.,
            31 July 1987.

   [DH76]   W. Diffie & M. Hellman, "New Directions in Cryptography", IEEE
            Transactions on Information Theory, Vol. IT-22,  No. 6, November
            1976, pp. 644-654.

   [DH95]     Steve Deering & Bob Hinden, Internet Protocol version 6 (IPv6)

Atkinson                                                       [Page 22]

Internet Draft        Security Architecture for IP      10 November 1996

            Specification, RFC-1883, December 1995.

   [EK96]   D. Eastlake III & C. Kaufman, "Domain Name System Protocol
            Security Extensions", Internet Draft, 30 January 1996.

   [GM93]   J. Galvin & K. McCloghrie, Security Protocols for version 2
            of the Simple Network Management Protocol (SNMPv2), RFC-1446,
            DDN Network Information Center, April 1993.

   [HA94]   N. Haller & R. Atkinson, "On Internet Authentication", RFC-1704,
            DDN Network Information Center, October 1994.

   [Hugh96] J. Hughes (Editor), "Combined DES-CBC, HMAC, and Replay Prevention
         Security Transform", Internet Draft, June 1996.

   [ISO]   ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC
           DIS 11577, International Standards Organisation, Geneva,
        Switzerland, 29 November 1992.

   [IB93]  John Ioannidis and Matt Blaze, "Architecture and Implementation of
           Network-layer Security Under Unix", Proceedings of USENIX Security
           Symposium, Santa Clara, CA, October 1993.

   [IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network-Layer
           Security for IP", presentation at the Spring 1993 IETF Meeting,
           Columbus, Ohio.

   [Ken78] Steve Kent, ..., Proceedings of SIGCOMM '78, ACM SIGCOMM, 1978.

   [Ken91] Steve Kent, US DoD Security Options for the Internet Protocol,
           RFC-1108, DDN Network Information Center, November 1991.

   [Ken93] Steve Kent, Privacy Enhancement for Internet Electronic Mail:
           Part II: Certificate-Based Key Management, RFC-1422, DDN Network
           Information Center, 10 February 1993.

   [KB93]  J. Kohl & B. Neuman, The Kerberos Network Authentication
           Service (V5), RFC-1510, DDN Network Information Center,
           10 September 1993.

   [NS78]  R.M. Needham & M.D. Schroeder, "Using Encryption for Authentication
           in Large Networks of Computers", Communications of the ACM,
           Vol. 21, No. 12, December 1978, pp. 993-999.

   [NS81]  R.M. Needham & M.D. Schroeder, "Authentication Revisited",
           ACM Operating Systems Review, Vol. 21, No. 1., 1981.

   [OG96]  Mike Oehler & Rob Glenn, "HMAC-MD5 IP Authentication with Replay

Atkinson                                                       [Page 23]

Internet Draft        Security Architecture for IP      10 November 1996

           Prevention", Internet Draft, 1 May 1996.

   [OTA94]   US Congress, Office of Technology Assessment, "Information
           Security & Privacy in Network Environments", OTA-TCT-606,
           Government Printing Office, Washington, DC, September 1994.

   [Sch96] Jeff Schiller, "Security AD Statement on IPSEC Key Management",
        Email to IPsec mailing list, September 19, 1996.

   [Sch94] Bruce Schneier, Applied Cryptography, Section 8.6,
           John Wiley & Sons, New York, NY, 1994.

   [SDNS]  SDNS Secure Data Network System, Security Protocol 3, SP3,
           Document SDN.301, Revision 1.5, 15 May 1989, published
           in NIST Publication NIST-IR-90-4250, February 1990.

   [STD-1] J. Postel, "Internet Official Protocol Standards", STD-1,
           March 1996.

   [VK83]  V.L. Voydock & S.T. Kent, "Security Mechanisms in High-level
           Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983.

   [ZDESZ93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and Zappala, D.,
           "RSVP: A New Resource ReSerVation Protocol", IEEE Network magazine,
           September 1993.


     The views expressed in this note are those of the editor and are not
   necessarily those of his employer.  The editor and his employer
   specifically disclaim responsibility for any problems arising from correct
   or incorrect implementation or use of this design.


   Randall Atkinson <rja@cisco.com>
   cisco Systems
   170 West Tasman Drive
   San Jose, CA, 95134-1706

   Telephone: +1 (408) 526-4000

Atkinson                                                       [Page 24]