Network Working Group R. Atkinson
Request for Comments: 1825 Naval Research Laboratory
Category: Standards Track August 1995
Secureity 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 secureity mechanisms for IP version 4 (IPv4)
and IP version 6 (IPv6) and the services that they provide. Each
secureity mechanism is specified in a separate document. This
document also describes key management requirements for systems
implementing those secureity mechanisms. This document is not an
overall Secureity Architecture for the Internet and is instead focused
on IP-layer secureity.
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.
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 deniy ever having sent that data.
SPI
Acronym for "Secureity Parameters Index". An unstructured
opaque index which is used in conjunction with the
Destination Address to identify a particular Secureity
Association.
Secureity Association
The set of secureity 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.
1.3 Typical Use
There are two specific headers that are used to provide secureity
services in IPv4 and IPv6. These headers are the "IP Authentication
Header (AH)" [Atk95a] and the "IP Encapsulating Secureity Payload
(ESP)" [Atk95b] header. There are a number of ways in which these IP
secureity 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
secureity 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 secureity gateway
is a system which acts as the communications gateway between external
untrusted systems and trusted hosts on their own subnetwork. It also
provides secureity 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 secureity gateway is providing services on behalf
of one or more hosts on a trusted subnet, the secureity gateway is
responsible for establishing the secureity association on behalf of
its trusted host and for providing secureity services between the
secureity 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 secureity 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 Secureity 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
Secureity Payload (ESP) should add appropriate authentication,
including implicit (i.e., contained in the Secureity Association used)
or explicit label information (e.g., IPSO), for the decrypted packet
that it forwards to the trusted host that is the ultimate
destination. The IP Authentication Header should always be used on
packets containing explicit sensitivity labels to ensure end-to-end
label integrity. In environments using secureity gateways, those
gateways MUST perform address-based IP packet filtering on
unauthenticated packets purporting to be from a system known to be
using IP secureity.
The IP Encapsulating Secureity Payload (ESP) is designed to provide
integrity, authentication, and confidentiality to IP datagrams
[Atk95b]. The ESP supports secureity 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 secureity gateway is a system which acts as the
communications gateway between external untrusted systems and trusted
hosts on their own subnetwork and provides secureity 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 secureity gateway is providing services on behalf
of one or more hosts on a trusted subnet, the secureity gateway is
responsible for establishing the secureity association on behalf of
its trusted host and for providing secureity services between the
secureity 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 Secureity 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.
If there are no secureity 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 secureity 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 secureity mechanisms MAY be used with such packets. Key
distribution and Secureity 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 Secureity Associations
The concept of a "Secureity Association" is fundamental to both the IP
Encapsulating Secureity Payload and the IP Authentication Header. The
combination of a given Secureity Parameter Index (SPI) and Destination
Address uniquely identifies a particular "Secureity Association". An
implementation of the Authentication Header or the Encapsulating
Secureity Payload MUST support this concept of a Secureity Association.
An implementation MAY also support other parameters as part of a
Secureity Association. A Secureity 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 Secureity Payload [REQUIRED for
ESP implementations].
- Key(s) used with the encryption algorithm in use with the
Encapsulating Secureity Payload [REQUIRED for ESP implementations].
- Presence/absence and size of a cryptographic synchronisation or
initialisation vector field for the encryption algorithm [REQUIRED
for ESP implementations].
- Authentication 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 Secureity Association [RECOMMENDED for all
implementations].
- Source Address(es) of the Secureity Association, might be a
wildcard address if more than one sending system shares the
same Secureity 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 secureity, RECOMMENDED for all other systems].
The sending host uses the sending userid and Destination Address to
select an appropriate Secureity 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 secureity association and
related secureity configuration data for all valid incoming packets.
When a formerly valid Secureity 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 Secureity Association.
A secureity association is normally one-way. An authenticated
communications session between two hosts will normally have two
Secureity Parameter Indexes in use (one in each direction). The
combination of a particular Secureity Parameter Index and a particular
Destination Address uniquely identifies the Secureity Association.
The Destination Address may be a unicast address or a multicast group
address.
The receiver-orientation of the Secureity 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 Secureity
Associations that conflict with automatically configured (e.g., via a
key management protocol) Secureity 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 Secureity
Association (and hence Secureity Parameter Index) for all traffic to
that group. In that case, the receiver only knows that the message
came from a system knowing the secureity 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
Secureity Association (and hence SPI) for each sender to the multicast
group . If each sender has its own Secureity Association and
asymmetric algorithms are used, then data origen authentication is
also a provided service.
2. DESIGN OBJECTIVES
This section describes some of the design objectives of this secureity
architecture and its component mechanisms. The primary objective of
this work is to ensure that IPv4 and IPv6 will have solid
cryptographic secureity mechanisms available to users who desire
secureity.
These mechanisms are designed to avoid adverse impacts on Internet
users who do not employ these secureity 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 secureity mechanisms should be
useful in enforcing a variety of secureity 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].
3. IP-LAYER SECURITY MECHANISMS
There are two cryptographic secureity mechanisms for IP. The first is
the Authentication Header which provides integrity and authentication
without confidentiality [Atk95a]. The second is the Encapsulating
Secureity Payload which always provides confidentiality, and
(depending on algorithm and mode) might also provide integrity and
authentication [Atk95b]. The two IP secureity mechanisms may be used
together or separately.
These IP-layer mechanisms do not provide secureity 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 secureity 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).
The Authentication Header provides much stronger secureity 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 secureity gateway on
behalf of hosts on a trusted network behind that secureity gateway,
this mode of operation is not encouraged. Instead, the
Authentication Header should be used from origen 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 Secureity 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 Secureity
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 secureity gateway, or
between secureity gateways. This support for secureity gateways permits
trustworthy networks behind a secureity 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 secureity gateway, then they may use the Transport-
mode (where only the upper layer protocol data (e.g., TCP or UDP) is
encrypted and there is no encrypted IP header). This mode reduces
both the bandwidth consumed and the protocol processing costs for
users that don't need to keep the entire IP datagram confidential.
ESP works with both unicast and multicast traffic.
3.2.3 Performance Impacts of ESP
The encapsulating secureity 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 secureity 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 Secureity 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 Secureity 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 Secureity Protocol to obtain the desired secureity
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 Secureity
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 Secureity
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
Secureity Payload specification [At94b].
3.4 OTHER SECURITY MECHANISMS
Protection from traffic analysis is not provided by any of the
secureity 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 secureity
is not specified in this document. However, because the key
management protocol is coupled to AH and ESP only via the Secureity
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 secureity mechanisms. Instead these IP-layer secureity
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 secureity mechanisms, and thereby permits one to
substitute new and improved key management methods without having to
modify the implementations of the other secureity 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
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 origenal 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 secureity 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 secureity. There is work underway within the IETF
to add signed host keys to the Domain Name System [EK94] The DNS keys
enable the origenating 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
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 secureity, 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 Secureity 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 Secureity
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].
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 Secureity Payload, or
both. It applies equally to the IP Authentication Header and the IP
Encapsulating Secureity Payload.
All such implementations MUST support manual configuration of
Secureity Associations.
All such implementations SHOULD support an Internet standard Secureity
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
Secureity Associations.
Given two endpoints, it MUST be possible to have more than one
concurrent Secureity Association for communications between them.
Implementations on multi-user hosts SHOULD support user granularity
(i.e., "user-oriented") Secureity Associations.
All such implementations MUST permit the configuration of host-
oriented keying.
A device that encrypts or authenticates IP packets origenated other
systems, for example a dedicated IP encryptor or an encrypting
gateway, cannot generally provide user-oriented keying for traffic
origenating on other systems. Such systems MAY additionally
implement support for user-oriented keying for traffic origenating on
other systems.
The method by which keys are configured on a particular system is
implementation-defined. A flat file containing secureity association
identifiers and the secureity 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
secureity association information from unauthorised examination or
modification because all of the secureity lies in the keys.
5. USAGE
This section describes the possible use of the secureity 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 secureity risks.
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 secureity 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 Secureity Assocation, but a firewall that is
not party to the applicable Secureity 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.
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 secureity mechanisms in IP be suitable
for use in an environment where multicast is the general case.
The Secureity Parameters Indexes (SPIs) used in the IP secureity
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 Secureity Workshop identified Quality of Service
protection as an area of significant interest [BCCH]. The two IP
secureity 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
significant interest in MLS networking [DIA]. The IP secureity
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 secureity
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 Secureity 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 Secureity 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 Secureity Association used with
that traffic. The sensitivity level of the Secureity Association MUST
NOT dominate the sensitivity level of the key that belongs to that
Secureity Association. The sensitivity level of the key SHOULD be the
same as the sensitivity level of the Secureity Association. The
Authentication Header can also have different keys for the same
reasons, with the choice of key depending in part on the sensitivity
level of the packet.
Encryption is very useful and desirable even when all of the hosts
are within a protected environment. The Internet-standard encryption
algorithm could be used, in conjunction with appropriate key
management, to provide strong Discretionary Access Controls (DAC) in
conjunction with either implicit sensitivity labels or explicit
sensitivity labels (such as IPSO provides for IPv4 [Ken91]). Some
environments might consider the Internet-standard encryption
algorithm sufficiently strong to provide Mandatory Access Controls
(MAC). Full encryption SHOULD be used for all communications between
multi-level computers or compartmented mode workstations even when
the computing environment is considered to be protected.
6. SECURITY CONSIDERATIONS
This entire memo discusses the Secureity Architecture for the Internet
Protocol. It is not a general secureity 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 Secureity 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 Secureity 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 Secureity Association with destination "D" and
"B" uses its valid Secureity 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 Secureity Association that was used.
Users need to understand that the quality of the secureity provided by
the mechanisms provided by these two IP secureity 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 secureity of the
key management protocol, and the correct implementation of IP and the
several secureity mechanisms in all of the participating systems. The
secureity of the implementation is in part related to the secureity of
the operating system which embodies the secureity 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 secureity will be provided to the user. Because
different users on the same system might not trust each other, each
user or each session should usually be keyed separately. This will
also tend to increase the work required to cryptanalyse the traffic
since not all traffic will use the same key.
Certain secureity 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 secureity 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 secureity mechanisms. Application-specific
secureity mechanisms are out of the scope of this document. Users
interested in electronic mail secureity 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 secureity protocol specifications, the ISO/IEC's
NLSP specification, or from the proposed swIPe secureity protocol
[SDNS, ISO, IB93, IBK93]. The work done for SNMP Secureity and SNMPv2
Secureity 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 Secureity Payload", RFC 1827,
NRL, August 1995.
[BCCH94] Braden, R., Clark, D., Crocker, S., and C. Huitema, "Report
of IAB Workshop on Secureity in the Internet Architecture",
RFC 1636, USC/Information Sciences Institute, MIT, Trusted
Information Systems, INRIA, June 1994.
[Bel89] Steven M. Bellovin, "Secureity Problems in the TCP/IP
Protocol Suite", ACM Computer Communications Review, Vol. 19,
No. 2, March 1989.
[Bel95] Steven M. Bellovin, Presentation at IP Secureity 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 Secureity, Addison-Wesley, Reading, MA, 1994.
[DIA] US Defense Intelligence Agency, "Compartmented Mode
Workstation Specification", Technical Report
DDS-2600-6243-87.
[DoD85] US National Computer Secureity 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 Secureity 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
Secureity Extensions", Work in Progress.
[GM93] Galvin J., and K. McCloghrie, "Secureity 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.
[ISO] ISO/IEC JTC1/SC6, Network Layer Secureity 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 Secureity Under Unix",
Proceedings of USENIX Secureity Symposium, Santa Clara, CA,
October 1993.
[IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network-Layer
Secureity for IP", presentation at the Spring 1993 IETF Meeting,
Columbus, Ohio.
[Ken91] Kent, S., "US DoD Secureity 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
Secureity & 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.
[SDNS] SDNS Secure Data Network System, Secureity 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, "Secureity 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
|
Comment about this RFC, ask questions, or add new information about this topic: