RFC relevance of mechanism

As per Relevance of the word mechanism, we have this rfc below:

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

Security Architecture for the Internet

Status of this

This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited

1.

This memo describes the security mechanisms for IP version 4 (IPv4)
and IP version 6 (IPv6) and the services that they provide.
security mechanism is specified in a separate document.
document also describes key management requirements for
implementing those security mechanisms. This document is not
overall Security Architecture for the Internet and is instead
on IP-layer security

1.1 Technical

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

The property of knowing that the data received is the same
the data that was sent and that the claimed sender is in
the actual sender

The property of ensuring that data is transmitted from
to destination without undetected alteration

The property of communicating such that the
recipients know what was being sent but
parties cannot determine what was sent

A mechanism commonly used to provide confidentiality

Atkinson Standards Track [Page 1]

RFC 1825 Security Architecture for IP August 1995

Non-
The property of a receiver being able to prove that the
of some data did in fact send the data even though the
might later desire to deny ever having sent that data

Acronym for "Security Parameters Index". An
opaque index which is used in conjunction with
Destination Address to identify a particular
Association

Security
The set of security information relating to a given
connection or set of connections. This is described
detail below

Traffic
The analysis of network traffic flow for the purpose
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

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

-

This word or the adjective "REQUIRED" means that the item is
absolute requirement of the specification

-

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

-

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

Atkinson Standards Track [Page 2]

RFC 1825 Security Architecture for IP August 1995

1.3 Typical

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

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

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

A security gateway which receives a datagram containing a
sensitivity label, for example IPSO [Ken91], from a trusted
should take that label's value into consideration
creating/selecting an Security Association for use with AH
the gateway and the external destination. In such an environment,
gateway which receives a IP packet containing the IP
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
that it forwards to the trusted host that is the
destination. The IP Authentication Header should always be used
packets containing explicit sensitivity labels to ensure end-to-

Atkinson Standards Track [Page 3]

RFC 1825 Security Architecture for IP August 1995

label integrity. In environments using security gateways,
gateways MUST perform address-based IP packet filtering
unauthenticated packets purporting to be from a system known to
using IP security

The IP Encapsulating Security Payload (ESP) is designed to
integrity, authentication, and confidentiality to IP
[Atk95b]. The ESP supports security between two or more
implementing ESP, between two or more gateways implementing ESP,
between a host or gateway implementing ESP and a set of hosts and/
gateways. A security gateway is a system which acts as
communications gateway between external untrusted systems and
hosts on their own subnetwork and provides security services for
trusted hosts when they communicate with external untrusted systems
A trusted subnetwork contains hosts and routers that trust each
not to engage in active or passive attacks and trust that
underlying communications channel (e.g., an Ethernet) isn't
attacked. Trusted systems always should be trustworthy, but
practice they often are not trustworthy

Gateway-to-gateway encryption is most valuable for building
virtual networks across an untrusted backbone such as the Internet
It does this by excluding outsiders. As such, it is often not
substitute for host-to-host encryption, and indeed the two can be
often should be used together

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

A gateway which receives a datagram containing a
sensitivity label from a trusted host should take that label's
into consideration when creating/selecting a Security Association
use with ESP between the gateway and the external destination.
such an environment, a gateway which receives a IP packet
the ESP should appropriately label the decrypted packet that
forwards to the trusted host that is the ultimate destination.
IP Authentication Header should always be used on packets
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
end systems that implement ESP may also use it to encrypt only
user data (e.g., TCP or UDP) being carried between the two systems
ESP is designed to provide maximum flexibility so that users
select and use only the security that they desire and need

Routing headers for which integrity has not been
protected SHOULD be ignored by the receiver. If this rule is
strictly adhered to, then the system will be vulnerable to
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.
distribution and Security Association management are not trivial
broadcast applications. Also, if symmetric key algorithms are
the value of using cryptography with a broadcast packet is
because the receiver can only know that the received packet came
one of many systems knowing the correct key to use

1.4 Security

The concept of a "Security Association" is fundamental to both the
Encapsulating Security Payload and the IP Authentication Header.
combination of a given Security Parameter Index (SPI) and
Address uniquely identifies a particular "Security Association".
implementation of the Authentication Header or the
Security Payload MUST support this concept of a Security Association
An implementation MAY also support other parameters as part of
Security Association. A Security Association normally includes
parameters listed below, but might include additional parameters
well

- Authentication algorithm and algorithm mode being used
the IP Authentication Header [REQUIRED for AH implementations].

- Key(s) used with the authentication algorithm in use
the Authentication Header [REQUIRED for AH implementations].

- Encryption algorithm, algorithm mode, and transform
used with the IP Encapsulating Security Payload [REQUIRED
ESP implementations].

- Key(s) used with the encryption algorithm in use with
Encapsulating Security Payload [REQUIRED for ESP implementations].

Atkinson Standards Track [Page 5]

RFC 1825 Security Architecture for IP August 1995

- Presence/absence and size of a cryptographic synchronisation
initialisation vector field for the encryption algorithm [
for ESP implementations].

- Authentication algorithm and mode used with the ESP
(if any is in use) [RECOMMENDED for ESP implementations].

- Authentication key(s) used with the authentication
that is part of the ESP transform (if any) [RECOMMENDED
ESP implementations].

- Lifetime of the key or time when key change should
[RECOMMENDED for all implementations].

- Lifetime of this Security Association [RECOMMENDED for
implementations].

- Source Address(es) of the Security Association, might be
wildcard address if more than one sending system shares
same Security Association with the destination [
for all implementations].

- Sensitivity level (for example, Secret or Unclassified
of the protected data [REQUIRED for all systems
to provide multi-level security, RECOMMENDED for all other systems].

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

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

Atkinson Standards Track [Page 6]

RFC 1825 Security Architecture for IP August 1995

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

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

2. DESIGN

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

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

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

Atkinson Standards Track [Page 7]

RFC 1825 Security Architecture for IP August 1995

3. IP-LAYER SECURITY

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

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

3.1 AUTHENTICATION

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

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

Atkinson Standards Track [Page 8]

RFC 1825 Security Architecture for IP August 1995

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

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

3.2 ENCAPSULATING SECURITY

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

3.2.1 Description of the ESP

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

3.2.2 Usage of

ESP works between hosts, between a host and a security gateway,
between security gateways. This support for security gateways
trustworthy networks behind a security gateway to omit encryption
thereby avoid the performance and monetary costs of encryption,
still providing confidentiality for traffic transiting
network segments. When both hosts directly implement ESP and
is no intervening security gateway, then they may use the Transport
mode (where only the upper layer protocol data (e.g., TCP or UDP)
encrypted and there is no encrypted IP header). This mode
both the bandwidth consumed and the protocol processing costs
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

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

For interoperability throughout the worldwide Internet,
conforming implementations of the IP Encapsulating Security
MUST support the use of the Data Encryption Standard (DES)
Cipher-Block Chaining (CBC) Mode as detailed in the
specification. Other confidentiality algorithms and modes may
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

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

Atkinson Standards Track [Page 10]

RFC 1825 Security Architecture for IP August 1995

3.4 OTHER SECURITY

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

4. KEY

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

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

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

4.1 Manual Key

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

Atkinson Standards Track [Page 11]

RFC 1825 Security Architecture for IP August 1995

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

4.2 Some Existing Key Management

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

4.3 Automated Key

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

4.4 Keying Approaches for

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

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;
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
session. In systems claiming to provide multi-level security, user
will typically have at least one key per sensitivity level in
(e.g., one key for UNCLASSIFIED traffic, a second key for
traffic, and a third key for TOP SECRET traffic). Similarly,
user-oriented keying one might use separate keys for information
to a multicast group and control messages sent to the same
group

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

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

Hence, support for user-oriented keying SHOULD be present in all
implementations, as is described in the "IP Key
Requirements" section below

4.5 Multicast Key

Multicast key distribution is an active research area in
published literature as of this writing. For multicast groups
relatively few members, manual key distribution or multiple use
existing unicast key distribution algorithms such as
Diffie-Hellman appears feasible. For very large groups, new
techniques will be needed. The use of Core-Based Trees (CBT)
provide session key management as well as multicast routing might
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

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

All such implementations MUST support manual configuration
Security Associations

All such implementations SHOULD support an Internet standard
Association establishment protocol (e.g., IKMP, Photuris) once such
protocol is published as an Internet standards-track RFC

Implementations MAY also support other methods of
Security Associations

Given two endpoints, it MUST be possible to have more than
concurrent Security Association for communications between them
Implementations on multi-user hosts SHOULD support user
(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
systems, for example a dedicated IP encryptor or an
gateway, cannot generally provide user-oriented keying for
originating on other systems. Such systems MAY
implement support for user-oriented keying for traffic originating
other systems

The method by which keys are configured on a particular system
implementation-defined. A flat file containing security
identifiers and the security parameters, including the key(s), is
example of one possible method for manual key distribution. An
system MUST take reasonable steps to protect the keys and
security association information from unauthorised examination
modification because all of the security lies in the keys

5.

This section describes the possible use of the security
provided by IP in several different environments and applications
order to give the implementer and user a better idea of how
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 are not uncommon in the current Internet [CB94].
many dislike their presence because they restrict connectivity,
are unlikely to disappear in the near future. Both of these
mechanisms can be used to increase the security provided
firewalls

Firewalls used with IP often need to be able to parse the headers
options to determine the transport protocol (e.g., UDP or TCP) in
and the port number for that protocol. Firewalls can be used
the Authentication Header regardless of whether that firewall
party to the appropriate Security Assocation, but a firewall that
not party to the applicable Security Association will not normally
able to decrypt an encrypted upper-layer protocol to view
protocol or port number needed to perform per-packet filtering OR
verify that the data (e.g., source, destination, transport protocol
port number) being used for access control decisions is correct
authentic. Hence, authentication might be performed not only
an organisation or campus but also end to end with remote
across the Internet. This use of the Authentication Header with
provides much more assurance that the data being used for
control decisions is authentic

Organisations with two or more sites that are interconnected
commercial IP service might wish to use a selectively
firewall. If an encrypting firewall were placed between each site
a company and the commercial IP service provider, the firewall
provide an encrypted IP tunnel among all the company's sites.
could also encrypt traffic between the company and its suppliers
customers, and other affiliates. Traffic with the
Information Center, with public Internet archives, or some
organisations might not be encrypted because of the unavailability
a standard key management protocol or as a deliberate choice
facilitate better communications, improved network performance,
increased connectivity. Such a practice could easily protect
company's sensitive traffic from eavesdropping and modification

Some organisations (e.g., governments) might wish to use a
encrypting firewall to provide a protected virtual network
commercial IP service. The difference between that and a bulk
encryption device is that a fully encrypting firewall would
filtering of the decrypted traffic as well as providing encryption
IP packets

Atkinson Standards Track [Page 15]

RFC 1825 Security Architecture for IP August 1995

5.2 USE WITH IP

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

The Security Parameters Indexes (SPIs) used in the IP
mechanisms are receiver-oriented, making them well suited for use
IP multicast [Atk95a, Atk95b]. Unfortunately, most
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
distribution protocol to distribute the key to all members or
group could pre-arrange keys using manual key distribution

5.3 USE TO PROVIDE QOS

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

The Authentication Header might be used, with appropriate
management, to provide authentication of packets.
authentication is potentially important in packet
within routers. The IPv6 Flow Identifier might act as a Low-
Identifier (LLID). Used together, packet classification
routers becomes straightforward if the router is provided with
appropriate keying material. For performance reasons the
might authenticate only every Nth packet rather than every packet
but this is still a significant improvement over capabilities in
current Internet. Quality of service provisioning is likely to
use the Flow ID in conjunction with a resource reservation protocol
such as RSVP [ZDESZ93]. Thus, the authenticated
classification can be used to help ensure that each packet
appropriate handling inside routers

5.4 USE IN COMPARTMENTED OR MULTI-LEVEL

A multi-level secure (MLS) network is one where a single network
used to communicate data at different sensitivity levels (e.g.,
Unclassified and Secret) [DoD85] [DoD87]. Many governments

Atkinson Standards Track [Page 16]

RFC 1825 Security Architecture for IP August 1995

significant interest in MLS networking [DIA]. The IP
mechanisms have been designed to support MLS networking.
networking requires the use of strong Mandatory Access
(MAC), which ordinary users are incapable of controlling or
[BL73]. This section pertains only to the use of these IP
mechanisms in MLS environments

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

The Encapsulating Security Payload can be combined with
key policies to provide full multi-level secure networking. In
case each key must be used only at a single sensitivity level
compartment. For example, Key "A" might be used only for
Unclassified packets, while Key "B" is used only for Secret/No
compartments traffic, and Key "C" is used only for Secret/No-
traffic. The sensitivity level of the protected traffic MUST
dominate the sensitivity level of the Security Association used
that traffic. The sensitivity level of the Security Association
NOT dominate the sensitivity level of the key that belongs to
Security Association. The sensitivity level of the key SHOULD be
same as the sensitivity level of the Security Association.
Authentication Header can also have different keys for the
reasons, with the choice of key depending in part on the
level of the packet

Encryption is very useful and desirable even when all of the
are within a protected environment. The Internet-standard
algorithm could be used, in conjunction with appropriate
management, to provide strong Discretionary Access Controls (DAC)
conjunction with either implicit sensitivity labels or
sensitivity labels (such as IPSO provides for IPv4 [Ken91]).

Atkinson Standards Track [Page 17]

RFC 1825 Security Architecture for IP August 1995

environments might consider the Internet-standard
algorithm sufficiently strong to provide Mandatory Access
(MAC). Full encryption SHOULD be used for all communications
multi-level computers or compartmented mode workstations even
the computing environment is considered to be protected

6. SECURITY

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

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

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

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

Atkinson Standards Track [Page 18]

RFC 1825 Security Architecture for IP August 1995

also tend to increase the work required to cryptanalyse the
since not all traffic will use the same key

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

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

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

[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, "
of IAB Workshop on Security in the Internet Architecture",
RFC 1636, USC/Information Sciences Institute, MIT,
Information Systems, INRIA, June 1994.

[Bel89] Steven M. Bellovin, "Security Problems in the TCP/
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
Group Meeting, Proceedings of the 32nd Internet
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
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
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
Workstation Specification", Technical
DDS-2600-6243-87.

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

[DoD87] US National Computer Security Center, "Trusted
Interpretation of the Trusted Computer System
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
Security Extensions", Work in Progress

[GM93] Galvin J., and K. McCloghrie, "Security Protocols
version 2 of the Simple Network Management
(SNMPv2)", RFC 1446, Trusted Information Systems, Hughes
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-
DIS 11577, International Standards Organisation, Geneva
Switzerland, 29 November 1992.

[IB93] John Ioannidis and Matt Blaze, "Architecture
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-
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
Service (V5)", RFC 1510, Digital Equipment Corporation
USC/Information Sciences Institute, September 1993.

[MS95] Metzger, P., and W. Simpson, "IP Authentication with
MD5", RFC 1828, Piermont, Daydreamer, August 1995.

[KMS95] Karn, P., Metzger, P., and W. Simpson, "The ESP DES-
Transform", RFC 1829, Qualcomm, Inc., Piermont, Daydreamer
August 1995.

[NS78] R.M. Needham & M.D. Schroeder, "Using Encryption
Authentication in Large Networks of Computers",
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, "
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,
in NIST Publication NIST-IR-90-4250, February 1990.

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

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

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

AUTHOR'S

Randall
Information Technology
Naval Research
Washington, DC 20375-5320

Phone: (202) 767-2389
Fax: (202) 404-8590
EMail: atkinson@itd.nrl.navy.

Atkinson Standards Track [Page 22]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002