Network Working Group
`Request for Comments: 1825
`Category: Standards Track
`
`R. Atkinson
`Naval Research Laboratory
`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]
`
`Juniper Ex. 1037-p. 1
`Juniper v Implicit
`
`

`

`
`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:
`
` - MUST
`
` This word or the adjective "REQUIRED" means that the item is an
` absolute requirement of the specification.
`
` - 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.
`
` - 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]
`
`Juniper Ex. 1037-p. 2
`Juniper v Implicit
`
`

`

`
`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]
`
`Juniper Ex. 1037-p. 3
`Juniper v Implicit
`
`

`

`
`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]
`
`Juniper Ex. 1037-p. 4
`Juniper v Implicit
`
`

`

`
`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:
`
` - Authentication algorithm and algorithm mode being used with
` the IP Authentication Header [REQUIRED for AH implementations].
`
` - Key(s) used with the authentication algorithm in use with
` the Authentication Header [REQUIRED for AH implementations].
`
` - Encryption algorithm, algorithm mode, and transform being
` used with the IP Encapsulating Security Payload [REQUIRED for
` ESP implementations].
`
` - Key(s) used with the encryption algorithm in use with the
` Encapsulating Security Payload [REQUIRED for ESP implementations].
`
`Atkinson Standards Track [Page 5]
`
`Juniper Ex. 1037-p. 5
`Juniper v Implicit
`
`

`

`
`RFC 1825 Security Architecture for IP August 1995
`
` - Presence/absence and size of a cryptographic synchronisation or
` initialisation vector field for the encryption algorithm [REQUIRED
` for ESP implementations].
`
` - Authentication algorithm and mode used with the ESP transform
` (if any is in use) [RECOMMENDED for ESP implementations].
`
` - Authentication key(s) used with the authentication algorithm
` that is part of the ESP transform (if any) [RECOMMENDED for
` ESP implementations].
`
` - Lifetime of the key or time when key change should occur
` [RECOMMENDED for all implementations].
`
` - Lifetime of this Security Association [RECOMMENDED for all
` implementations].
`
` - 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].
`
` - 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]
`
`Juniper Ex. 1037-p. 6
`Juniper v Implicit
`
`

`

`
`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]
`
`Juniper Ex. 1037-p. 7
`Juniper v Implicit
`
`

`

`
`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]
`
`Juniper Ex. 1037-p. 8
`Juniper v Implicit
`
`

`

`
`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]
`
`Juniper Ex. 1037-p. 9
`Juniper v Implicit
`
`

`

`
`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]
`
`Juniper Ex. 1037-p. 10
`Juniper v Implicit
`
`

`

`
`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]
`
`Juniper Ex. 1037-p. 11
`Juniper v Implicit
`
`

`

`
`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]
`
`Juniper Ex. 1037-p. 12
`Juniper v Implicit
`
`

`

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