GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1825

Network Working Group R. Atkinson Request for Comments: 1825 Naval Research Laboratory Category: Standards Track August 1995

          Security Architecture for the Internet Protocol

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.

1. INTRODUCTION

 This memo describes the security mechanisms for IP version 4 (IPv4)
 and IP version 6 (IPv6) and the services that they provide.  Each
 security mechanism is specified in a separate document.  This
 document also describes key management requirements for systems
 implementing those security mechanisms.  This document is not an
 overall Security Architecture for the Internet and is instead focused
 on 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
         The property of knowing that the data received is the same as
         the data that was sent and that the claimed sender is in fact
         the actual sender.
 Integrity
         The property of ensuring that data is transmitted from source
         to destination without undetected alteration.
 Confidentiality
         The property of communicating such that the intended
         recipients know what was being sent but unintended
         parties cannot determine what was sent.
 Encryption
         A mechanism commonly used to provide confidentiality.

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

 Non-repudiation
         The property of a receiver being able to prove that the sender
         of some data did in fact send the data even though the sender
         might later desire to deny ever having sent that data.
 SPI
         Acronym for "Security Parameters Index".  An unstructured
         opaque index which is used in conjunction with the
         Destination Address to identify a particular Security
         Association.
 Security Association
         The set of security information relating to a given network
         connection or set of connections.  This is described in
         detail below.
 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 used, etc. [Sch94].

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:
  1. MUST
    This word or the adjective "REQUIRED" means that the item is an
    absolute requirement of the specification.
  1. SHOULD
    This word or the adjective "RECOMMENDED" means that there might
    exist valid reasons in particular circumstances to ignore this
    item, but the full implications should be understood and the case
    carefully weighed before taking a different course.
  1. MAY
    This word or the adjective "OPTIONAL" means that this item is
    truly optional.  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.

Atkinson Standards Track [Page 2] 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 [Page 3] RFC 1825 Security Architecture for IP August 1995

 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.
 The IP Encapsulating Security Payload (ESP) is designed to provide
 integrity, authentication, and confidentiality to IP datagrams
 [Atk95b]. The ESP supports security between two or more hosts
 implementing ESP, between two or more gateways implementing ESP, and
 between a host or gateway implementing ESP and a set of hosts and/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 and provides security services for the
 trusted hosts when they communicate with 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.  Trusted systems always should be trustworthy, but in
 practice they often are not trustworthy.
 Gateway-to-gateway encryption is most valuable for building private
 virtual networks across an untrusted backbone such as the Internet.
 It does this by excluding outsiders.  As such, it is often not a
 substitute for host-to-host encryption, and indeed the two can be and
 often should be used together.
 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 ESP, while all of the systems behind the
 gateway on the trusted subnet may take advantage of ESP services
 between the gateway and external systems.
 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.  The
 IP Authentication Header should always be used on packets containing
 explicit sensitivity labels to ensure end-to-end label integrity.

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

 If there are no security gateways present in the connection, then two
 end systems that implement ESP may also use it to encrypt only the
 user data (e.g., TCP or UDP) being carried between the two systems.
 ESP is designed to provide maximum flexibility so that users may
 select and use only the security that they desire and need.
 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].
 While these documents do not specifically discuss IPv4 broadcast,
 these IP security mechanisms MAY be used with such packets.  Key
 distribution and Security Association management are not trivial for
 broadcast applications.  Also, if symmetric key algorithms are used
 the value of using cryptography with a broadcast packet is limited
 because the receiver can only know that the received packet came from
 one of many systems knowing the correct key to use.

1.4 Security Associations

 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.
 An implementation MAY also support other parameters as part of a
 Security Association.  A Security Association normally includes the
 parameters listed below, but might include additional parameters as
 well:
  1. Authentication algorithm and algorithm mode being used with

the IP Authentication Header [REQUIRED for AH implementations].

  1. Key(s) used with the authentication algorithm in use with

the Authentication Header [REQUIRED for AH implementations].

  1. Encryption algorithm, algorithm mode, and transform being

used with the IP Encapsulating Security Payload [REQUIRED for

   ESP implementations].
  1. Key(s) used with the encryption algorithm in use with the

Encapsulating Security Payload [REQUIRED for ESP implementations].

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

  1. Presence/absence and size of a cryptographic synchronisation or

initialisation vector field for the encryption algorithm [REQUIRED

   for ESP implementations].
  1. Authentication algorithm and mode used with the ESP transform

(if any is in use) [RECOMMENDED for ESP implementations].

  1. Authentication key(s) used with the authentication algorithm

that is part of the ESP transform (if any) [RECOMMENDED for

   ESP implementations].
  1. Lifetime of the key or time when key change should occur

[RECOMMENDED for all implementations].

  1. Lifetime of this Security Association [RECOMMENDED for all

implementations].

  1. Source Address(es) of the Security Association, might be a

wildcard address if more than one sending system shares the

   same Security Association with the destination [RECOMMENDED
   for all implementations].
  1. Sensitivity level (for example, Secret or Unclassified)

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] RFC 1825 Security Architecture for IP August 1995

 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 encrypting firewall 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 secured.

4.2 Some Existing Key Management Techniques

 There are a number of key management algorithms that have been
 described in the public literature.  Needham & Schroeder have
 proposed a key management algorithm which relies on a centralised key
 distribution system [NS78, NS81].  This algorithm is used in the
 Kerberos Authentication System developed at MIT under Project Athena
 [KB93].  Diffie and Hellman have devised an algorithm which does not
 require a centralised key distribution system [DH76].  Unfortunately,
 the original Diffie-Hellman technique is vulnerable to an active "man
 in the middle" attack [Sch93, p. 43-44].  However, this vulnerability
 can be mitigated by using signed keys to authentically bootstrap into
 the Diffie-Hellman exchange [Sch93, p. 45].

4.3 Automated Key Distribution

 Widespread deployment and use of IP security will require an
 Internet-standard scalable key management protocol.  Ideally such a
 protocol would support a number of protocols in the Internet protocol
 suite, not just IP security.  There is work underway within the IETF
 to add signed host keys to the Domain Name System [EK94] The DNS keys
 enable the originating party to authenticate key management messages
 with the other key management party using an asymmetric algorithm.
 The two parties would then have an authenticatible communications
 channel that could be used to create a shared session key using
 Diffie-Hellman or other means [DH76] [Sch93].

4.4 Keying Approaches for IP

 There are two 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
 approach, called user-oriented keying, lets user A on host 1 have one

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

 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.
 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 user-oriented keying SHOULD be present in all IP
 implementations, as is described in the "IP Key Management
 Requirements" section below.

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.  The use of Core-Based Trees (CBT) to
 provide session key management as well as multicast routing might be
 an approach used in the future [BFC93].

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

4.6 IP 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.
 All such implementations SHOULD support an Internet standard Security
 Association establishment protocol (e.g., IKMP, Photuris) once such a
 protocol is published as an Internet standards-track RFC.
 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 SHOULD support user granularity
 (i.e., "user-oriented") Security Associations.
 All such implementations MUST permit the configuration of host-
 oriented keying.
 A device that encrypts or authenticates IP packets originated other
 systems, for example a dedicated IP encryptor or an encrypting
 gateway, cannot generally provide user-oriented keying for traffic
 originating on other systems.  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 distribution.  An IP
 system 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.

5. USAGE

 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.

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

5.1 USE WITH FIREWALLS

 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.
 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, but 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 OR 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
 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 protected virtual network 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.

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

5.2 USE WITH IP MULTICAST

 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.

5.3 USE TO PROVIDE QOS PROTECTION

 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
 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.

5.4 USE IN COMPARTMENTED OR MULTI-LEVEL NETWORKS

 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

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

 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/No-Foreign
 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 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

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

 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.

6. SECURITY CONSIDERATIONS

 This entire memo 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 uses 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 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

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

 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
 exist.

ACKNOWLEDGEMENTS

 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, Richard Hale,
 George Kamis, Phil Karn, Frank Kastenholz, Perry Metzger, Dave
 Mihelcic, Hilarie Orman and Bill Simpson provided careful critiques
 of early versions of this document.

REFERENCES

 [Atk95a] Atkinson, R., "IP Authentication Header", RFC 1826, NRL,
          August 1995.
 [Atk95b] Atkinson, R., "IP Encapsulating Security Payload", RFC 1827,
          NRL, August 1995.
 [BCCH94] Braden, R., Clark, D., Crocker, S., and C. Huitema, "Report
          of IAB Workshop on Security in the Internet Architecture",
          RFC 1636, USC/Information Sciences Institute, MIT, Trusted
          Information Systems, INRIA, June 1994.
 [Bel89]  Steven M. Bellovin, "Security Problems in the TCP/IP
          Protocol Suite", ACM Computer Communications Review, Vol. 19,
          No. 2, March 1989.

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

 [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.
 [BFC93]  A. Ballardie, P. Francis, & J. Crocroft, "Core Based Trees:
          An Architecture for Scalable Inter-Domain Multicast Routing",
          Proceedings of ACM SIGCOMM 93, ACM Computer Communications
          Review, Volume. 23, Number 4, October 1993, pp. 85-95.
 [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.
 [CB94]   William R. Cheswick & Steven M. Bellovin, Firewalls &
          Internet Security, Addison-Wesley, Reading, MA, 1994.
 [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.
 [EK94]   D. Eastlake III & C. Kaufman, "Domain Name System Protocol
          Security Extensions", Work in Progress.
 [GM93]   Galvin J., and K. McCloghrie, "Security Protocols for
          version 2 of the Simple Network Management Protocol
          (SNMPv2)", RFC 1446, Trusted Information Systems, Hughes LAN
          Systems, April 1993.
 [HA94]   Haller, N., and R. Atkinson, "On Internet Authentication",
          RFC 1704, Bell Communications Research, NRL, October 1994.
 [Hin94]  Bob Hinden (Editor), Internet Protocol version 6 (IPv6)
          Specification, Work in Progress, October 1994.

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

 [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.
 [Ken91] Kent, S., "US DoD Security Options for the Internet Protocol",
         RFC 1108, BBN Communications, November 1991.
 [Ken93] Kent, S., "Privacy Enhancement for Internet Electronic Mail:
         Part II: Certificate-Based Key Management", RFC 1422,
         BBN Communications, February 1993.
 [KB93]  Kohl, J., and B. Neuman, "The Kerberos Network Authentication
         Service (V5)", RFC 1510, Digital Equipment Corporation,
         USC/Information Sciences Institute, September 1993.
 [MS95]  Metzger, P., and W. Simpson, "IP Authentication with Keyed
         MD5", RFC 1828, Piermont, Daydreamer, August 1995.
 [KMS95] Karn, P., Metzger, P., and W. Simpson, "The ESP DES-CBC
         Transform", RFC 1829, Qualcomm, Inc., Piermont, Daydreamer,
         August 1995.
 [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.
 [OTA94] US Congress, Office of Technology Assessment, "Information
         Security & Privacy in Network Environments", OTA-TCT-606,
         Government Printing Office, Washington, DC, September 1994.
 [Sch94] Bruce Schneier, Applied Cryptography, Section 8.6,
         John Wiley & Sons, New York, NY, 1994.

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

 [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.
 [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
           D. Zappala, "RSVP: A New Resource ReSerVation Protocol",
           IEEE Network magazine, September 1993.

DISCLAIMER

 The views expressed in this note are those of the author and are not
 necessarily those of his employer.  The Naval Research Laboratory has
 not passed judgement on the merits, if any, of this work.  The author
 and his employer specifically disclaim responsibility for any problems
 arising from correct or incorrect implementation or use of this
 design.

AUTHOR'S ADDRESS

 Randall Atkinson
 Information Technology Division
 Naval Research Laboratory
 Washington, DC 20375-5320
 USA
 Phone:  (202) 767-2389
 Fax:    (202) 404-8590
 EMail: atkinson@itd.nrl.navy.mil

Atkinson Standards Track [Page 22]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1825.txt · Last modified: 1995/08/08 20:00 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki