home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
drafts
/
draft_ietf_i
/
draft-ietf-ipsec-arch-sec-01.txt
< prev
next >
Wrap
Text File
|
1996-11-13
|
67KB
|
1,344 lines
Network Working Group Randall Atkinson
Internet Draft cisco Systems
draft-ietf-ipsec-arch-sec-01.txt 10 November 1996
Expire in six months
Security Architecture for the Internet Protocol
STATUS OF THIS MEMO
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, and its
working groups. Note that other groups may also distribute working
documents as Internet Drafts.
Internet Drafts are draft documents valid for a maximum of 6
months. Internet Drafts may be updated, replaced, or obsoleted by other
documents at any time. It is not appropriate to use Internet Drafts as
reference material or to cite them other than as "work in progress".
This particular Internet Draft is a product of the IETF's IP Security
(IPsec) working group. It is intended that a future version of this draft
be submitted to the IESG for publication as a Draft Standard RFC. Comments
about this draft may be sent to the author or to the IPsec WG mailing list
<ipsec@tis.com>.
1. INTRODUCTION
This memo describes the security protocols for IP version 4 (IPv4)
and IP version 6 (IPv6) and the services that they provide. Each security
protocol is specified in a separate document. This document also describes
key management requirements for systems implementing these security
protocols. This document is not an overall Security Architecture for the
Internet; it addresses only IP-layer security.
1.1 Technical Definitions
This section provides a few basic definitions that are applicable
to this document. Other documents provide more definitions and background
information. [VK83, HA94]
Authentication (of Data Origin)
Atkinson [Page 1]
Internet Draft Security Architecture for IP 10 November 1996
A security property that ensures that the origin of received data
is, in fact, the claimed sender. Usually bundled with integrity services,
especially connectionless integrity.
Integrity (Connectionless)
A security property that ensures data is transmitted from source to
destination without undetected alteration. If the order of
transmitted data also is ensured, the service is termed
connection-oriented integrity. The term anti-replay refers to a
minimal `qform of connection-oriented integrity designed to detect and
reject duplicated or very old data units.
Confidentiality
A security property that ensures that communicated data is
disclosed to intended recipients, but is not disclosed to other,
unauthorized parties. Traffic flow confidentiality extends this service to
externally visible characteristics of communication, e.g., source and
destination identifiers, message length, or frequency of communication.
(See also traffic analysis, below.)
Encryption
A mechanism commonly used to provide confidentiality.
Non-repudiation
A security property that ensures that a participant in a
communication cannot later deny having participated in the communication.
This property may apply to either the sender or the recipient of
communccated data, or both.
SPI
Acronym for "Security Parameters Index." The combination of an SPI
and a destination address uniquely identifies a simplex security
association (SA, see below). The SPI is carried in IPsec protocols to
select the set of parameters bound to an SA. An SPI has only local
significance, defined by the creator of the SA; thus an SPI is generally
viewed as an opaque bit string. However, the creator of an SA may choose
to interpret the bits in an SPI to facilitate local processing.
Security Association (SA)
A simplex (uni-directional) logical connection, created for
security purposes. All traffic traversing an SA is subjected to the same
security processing at the transmitter and receiver. In IPsec, an SA is a
network layer abstraction enforced through the use of AH or ESP.
Security Gateway
A system that acts as the communications interface between
untrusted external, networks and internal (trusted) hosts and subnetworks.
Atkinson [Page 2]
Internet Draft Security Architecture for IP 10 November 1996
The internal subnets and hosts served by a security gateway are presumed to
be trusted by virtue of sharing a common, local, security administration.
(See "Trusted Subnetwork" below.) In the IPsec context, a security gateway
is a point at which AH and/or ESP is implemented in order to serve a set of
internal hosts, providing security services for these hosts when they
communicate with external hosts also employing IPsec (either directly or
via another security gateway).
Traffic Analysis
The analysis of network traffic flow for the purpose of deducing
information that is useful to an adversary. Examples of such information
are frequency of transmission, the identities of the conversing parties,
sizes of packets, flow Identifiers, etc. [Kent78]
Trusted Subnetwork
A subnetwork containing hosts and routers that trust each other not
to engage in active or passive attacks and trust that the underlying
communications channel (e.g., an Ethernet) isn't being attacked.
1.2 Requirements Terminology
In this document, the words that are used to define the
significance of each particular requirement are usually capitalised. These
words are:
- MUST
This word or the adjective "REQUIRED" means that implementation of
the item is an absolute requirement of the specification.
- SHOULD
This word or the adjective "RECOMMENDED" means that there might
exist valid reasons in particular circumstances to not implement this item,
but the full implications should be understood and the case carefully
weighed before taking a different course.
- MAY
This word or the adjective "OPTIONAL" means that this item is truly
optional to implement. One vendor might choose to include the item because
a particular marketplace requires it or because it enhances the product,
for example; another vendor may omit the same item.
1.3 Basic IPsec features
Two specific headers used to provide security services in IPv4 and
IPv6: the "IP Authentication Header (AH)" [Atk95a] and the "IP
Encapsulating Security Payload (ESP)" [Atk95b] header. There are a number
of ways in which these IP security mechanisms may be employed, in large
part because AH and ESP may be used independently of one another, in
Atkinson [Page 3]
Internet Draft Security Architecture for IP 10 November 1996
combination with one another, or in an interated (nested) fashion. This
section describes the basic features of both protocols and typical uses of
these protocols. The next section defines the minimum header processing
configurations that all compliant IPsec implementations must support.
(Additional configurations may be supported at the discretion of the
implementor.) Thus the configuration examples in this and the next section
are not exhaustive.
The IP Authentication Header (AH) can be used to provide
connectionless integrity and data origin authentication for IP datagrams,
and optionally to provide anti-replay integrity. This last, optional
service may be selected when a security association is established. This
header protects an entire IP datagram, including all immutable fields in
the IP header. AH does not provide confidentiality; thus implementations
of AH may be widely deployed, even in countries where controls on
encryption would preclude deployment of technology that also offered
confidentiality. This header should be used whenever the integrity and
authenticity of the IP header, as well as the associted upper layer
protocols, must be ensured. For example, AH can be used to bind a
sensitivity label (e.g., IPSO [Kent91]) to an IP datagram.
The Encapsulating Security Payload (ESP) can be used to provide
confidentiality, data origin authentication, connectionless integrity,
anti-replay integrity, and limited traffic flow confidentiality. The set
of services provided depends on options selected at the time of security
association establishment and the implementation placement.
Confidentiality may be selected independent of all other services. Data
origin authentication and connectionless integrity are joint services,
independent of confidentiality. Anti-replay may be selected only if data
origin authentication and connectionless integrity are selected, but is
independent of confidentiality. Traffic flow confidentiality depends on
confidentiality, and requires selection of tunnel mode (see below).
Unlike AH, ESP provides security only for the protocols encapsulated by
it, not the protocol that carries it. Perhaps the most obvious use of ESP
is to provide security services for upper layer protocols such as TCP,
without affording protection to the IP header that carries the these
protocols. Because ESP is an encapsulation protocol, it may be employed
recursively, to create nested security associations. For example, one
ESP-protected SA might extend between a host and a security gateway, and a
second, nested ESP-protected SA might extend from the same host through the
security gateway to a host behind the gateway.
Two modes of ESP are defined: transport mode and tunnel mode. In
transport mode, ESP encapsulates any transport layer protocol defined for
carriage in the TCP/IP suite, e.g., TCP, UDP. This is the simplest mode
for use between a pair of hosts implementing ESP. In tunnel model, the
protocol encapsulated by ESP is usually IP but could also be another
Atkinson [Page 4]
Internet Draft Security Architecture for IP 10 November 1996
network-layer protocol (e.g. IPX). Tunnel mode is always used by security
gateways for all packets not originating on the gateway, to facilitate
operation in multi-homed environments, especially in the face of possible
fragmentation of ESP-protected packets. Tunnel mode can be used to create
virtual private networks between sites protected by security gateways
implementing ESP.
Both AH and ESP can provide security services between a pair of
communicating hosts, or between a pair of communicating security gateways
or between a security gateway and a host. Depending on the choice of
algorithms, AH and ESP also may support multicast communication, e.g.,
among a set of hosts or security gateways or combinations thereof. When a
security gateway provides services for hosts on a trusted subnet, the
security gateway is responsible for establishing and managing security
associations on behalf of the trusted hosts it serves. The security
gateway also is responsible for providing security services between the
gateway itself and correspondant external systems (hosts or security
gateways) through the implementation of AH and ESP.
1.4 Minimal Essential Support
All IPsec-compliant implementations MUST support AH and MUST
support ESP in both transport and tunnel modes. The requirement to support
tunnel-mode is imposed to ensure interoperability between host and security
gateway implementations of ESP. The requirement to support transport-mode
ensures interoperability with other hosts using transport-mode and can
permit some reduction in security overhead.
A compliant host or security gateway implementation MUST be capable
of creating and accepting security associations that employ either AH or
ESP. A compliant host or security gateway SHOULD also be capable of
creating pairs of AH and ESP security associations. A compliant host
implementation also MUST also support a second (nested) ESP security
association, in transport mode, above a tunnel mode ESP security
association.
The following sequences of combinations of AH and ESP, each
represented by a separate security association, must be supported by an
IPsec-compliant host: AH, ESP (tunnel), ESP(transport), AH-ESP(transport),
AH-ESP(tunnel), ESP(tunnel)-AH, AH-ESP(tunnel)-ESP(transport), and
ESP(tunnel)-ESP(transport).
The following sequences of combinations of AH and ESP must be
supported by a compliant IPsec security gateway: AH, ESP (tunnel), and
AH-ESP(tunnel). Note that transport-mode ESP security associations may be
employed across a security gateway, terminating at hosts behind the
gateway. The gateway does not process these SAs; they are passed through
transparently, and hence there is no required "support" in the gateway for
Atkinson [Page 5]
Internet Draft Security Architecture for IP 10 November 1996
these header combinations.
A security gateway which receives a datagram containing a
recognised sensitivity label, for example IPSO [Ken91], from a trusted host
MUST take that label's value into consideration when creating/selecting an
Security Association for use with AH between the gateway and the external
destination. In such an environment, a gateway which receives a IP packet
containing the IP Encapsulating Security Payload (ESP) should add
appropriate authentication, including implicit (i.e. contained in the
Security Association used) or explicit label information (e.g. IPSO), for
the decrypted packet that it forwards to the trusted host that is the
ultimate destination. The IP Authentication Header should always be used
on packets containing explicit sensitivity labels to ensure end-to-end
label integrity. In environments using security gateways, those gateways
MUST perform address-based IP packet filtering on unauthenticated packets
purporting to be from a system known to be using IP security.
A gateway which receives a datagram containing a recognised sensitivity
label from a trusted host should take that label's value into consideration
when creating/selecting a Security Association for use with ESP between the
gateway and the external destination. In such an environment, a gateway
which receives a IP packet containing the ESP should appropriately label
the decrypted packet that it forwards to the trusted host that is the
ultimate destination. IP security should always be used on packets
containing explicit sensitivity labels in a manner to ensure end-to-end
label integrity.
Routing headers for which integrity has not been cryptographically
protected SHOULD be ignored by the receiver. If this rule is not strictly
adhered to, then the system will be vulnerable to various kinds of attacks,
including source routing attacks. [Bel89][CB94][CERT95]
1.5 Security Association Management
The concept of a "Security Association" is fundamental to both the
IP Encapsulating Security Payload and the IP Authentication Header. The
combination of a given Security Parameter Index (SPI) and Destination
Address uniquely identifies a particular "Security Association". An
implementation of the Authentication Header or the Encapsulating Security
Payload MUST support this concept of a Security Association.
A single IPsec Security Association is a simplex (unidirectional)
connection with which either AH or ESP (but not both) is employed. If both
AH and ESP protection is to be applied to a traffic stream, then two (or
more) security associations are created to control processing of the
traffic stream.
A compliant implementation of IPsec Security Association MUST
Atkinson [Page 6]
Internet Draft Security Architecture for IP 10 November 1996
support the following management parameters for each SA; other parameters
MAY also be included at the discretion of the implementor:
- Authentication algorithm and mode being used for AH or ESP.
[REQUIRED for all implementations].
- Key(s) used with the above authentication algorithm
[REQUIRED for all implementations].
- Encryption algorithm and mode used with ESP.
[REQUIRED for ESP implementations]
- Key(s) used with the above encryption algorithm.
[REQUIRED for ESP implementations]
- Presence/absence and size of a cryptographic synchronisation or
initialisation vector field for the encryption algorithm.
[REQUIRED for ESP implementations]
- Authentication key crypto period (fixed future time or duration).
[REQUIRED for all implementations].
- Encryption key crypto period (fixed future tie or duration)
[REQUIRED for ESP implementations]
- Lifetime of this Security Association
[REQUIRED for all implementations]
- Destination IP Address of the Security Association; this may be
a wildcard address if more than one desitnation system shares the
same Security Association (behind a security gateway)
[REQUIRED for all implementations]
- Source IP Address(es) of the Security Association; this might be
a wildcard address if more than one sending system shares the
same Security Association with the destination
[REQUIRED for all implementations]
- Proxy IP Address of the Security Association; this contains
the IP address of the security gateway that provides security
services on behalf of the source IP address when IPsec is
not in use end-to-end from source to destination.
[REQUIRED for Security Gateways;
RECOMMENDED for all other implementations]
- Replay Protection information, including whether it is in use,
information on the window size for the sequence numbers, etc.
[REQUIRED for all implementations]
- Sensitivity level of the protected data (e.g., in IPSO terms)
[REQUIRED for all systems claiming to provide multi-level
security, RECOMMENDED for all other systems]
- Next Protocol (from IP header) as an optional SA selector
input for outbound traffic
[RECOMMENDED for all implementations]
- Source and/or Destination TCP/UDP Ports as an optional SA
selector for outbound traffic
[RECOMMENDED for all implementations]
- Identity of the source of the Security Association
[RECOMMENDED for all implementations]
Atkinson [Page 7]
Internet Draft Security Architecture for IP 10 November 1996
- Identity of the destination of the Security Association]
[RECOMMENDED for all implementations]
The way in which security associations are matched to offered
(outbound) traffic varies based on whether IPsec is implemented in a
host or a security gateway, and on the granularity of SA management
selected. At a host, the inputs to SA selection are the userid of
the sender, the Destination Address (perhaps including the next
protocol field and source and/or destination port fields and
source/destination identities) is used to select the appropriate
Security Association for outbound traffic. For a multi-level secure
host, the senstivity of the traffic, e.g., as expressed in a security
label, also is an input to the SA selection. A security gateway
generally does not have access to userid information and thus IPsec
implementations in such devices are not required to select SAs for
outbound traffic on that basis. Since a security gateway typically
serves a number of hosts, the Source Address (perhaps including the
next protocol field and source and/or destination port fields) is an
input to the SA selection. The Destination Address address also is
an input, and when in a multi-level secure network context a traffic
sensitivity label is a REQUIRED additional input.
Processing for received (inbound) IPsec traffic is much simpler.
The receiving host uses the combination of the SPI and the
Destination Address to distinguish the correct association. Hence,
an IPsec implementation will always be able to use the SPI in
combination with the Destination Address to determine the security
association with which the traffic is associated. When a formerly
valid Security Association is terminated, the destination system(s)
SHOULD NOT immediately reuse that SPI and instead SHOULD let that SPI
value become stale before reusing it for some other Security
Association.
As noted above, an IPsec Security Association is unidirectional.
Hence, to secure typical, bi-directional communications between two
hosts (or security gateways), two Security Associations (one in each
direction) will be required. The Destination Address may be a
unicast address, an IPv4 broadcast address, or a multicast group
address.
The receiver-orientation of the Security Association implies
that, in the case of unicast traffic, the destination system will
normally select the SPI value. By having the destination select the
SPI value, there is no potential for manually configured Security
Associations that conflict with automatically configured (e.g. via a
key management protocol) Security Associations. For multicast
traffic, there are multiple destination systems but a single
destination multicast group, so some system or person will need to
Atkinson [Page 8]
Internet Draft Security Architecture for IP 10 November 1996
select SPIs on behalf of that multicast group and then communicate
the information to all of the legitimate members of that multicast
group via mechanisms not defined here.
Multiple senders to a multicast group SHOULD use a single
Security Association (and hence Security Parameter Index) for all
traffic to that group when a symmetric cryptographic algorithm is in
use. In that case, the receiver only knows that the message came
from a system knowing the security association data for that
multicast group. A receiver cannot generally authenticate which
system sent the multicast traffic when symmetric algorithms (e.g.
DES, IDEA) are in use. Multicast traffic SHOULD use a separate
Security Association for each sender to the multicast group when an
asymmetric cryptographic algorithm is in use. In this last case, the
receiver can know the specific system that originated the message.
2. DESIGN OBJECTIVES
This section describes some of the design objectives of this
security architecture and its component mechanisms. The primary
objective of this work is to ensure that IPv4 and IPv6 will have
solid cryptographic security mechanisms available to users who desire
security.
These mechanisms are designed to avoid adverse impacts on
Internet users who do not employ these security mechanisms for their
traffic. These mechanisms are intended to be algorithm-independent
so that the cryptographic algorithms can be altered without affecting
the other parts of the implementation. These security mechanisms
should be useful in enforcing a variety of security policies.
Standard default algorithms (Keyed HMAC MD5, Keyed HMAC SHA,
DES- CBC) are specified to ensure interoperability in the global
Internet. The selected default algorithms are widely used in other
contexts.
3. IP-LAYER SECURITY MECHANISMS
There are two cryptographic security mechanisms for IP. The
first is the Authentication Header which provides integrity and
authentication without confidentiality. [Atk95a] The second is the
Encapsulating Security Payload which always provides confidentiality,
and usually provides integrity and authentication. [Atk95b] The two
IP security mechanisms are normally used separately. When both
confidentiality and authentication are needed, a combined ESP
transform should be used instead of using AH with ESP.
Atkinson [Page 9]
Internet Draft Security Architecture for IP 10 November 1996
These IP-layer mechanisms do not provide complete security
against all traffic analysis attacks, though the use of ESP between
security gateways can provide partial traffic flow protection.
However, there are several techniques outside the scope of this
specification (e.g. bulk link encryption) that might be used to
provide more comprehensive protection against traffic analysis.
[VK83]
3.1 AUTHENTICATION HEADER
The IP Authentication Header is designed to provide
authentication, integrity, and replay protection to IP datagrams.
[Atk95a] It does this by computing a cryptographic authentication
function over the IP datagram and using one or more authentication
keys in the computation. The authentication algorithm may be either
symmetric or asymmetric. The sender computes the authentication data
prior to sending the authenticated IP packet and places the
authentication data inside the Authentication Data. Fragmentation
occurs after the Authentication Header processing for outbound
packets and reassembly occurs prior to Authentication Header
processing for inbound packets. The receiver verifies the
correctness of the authentication data upon reception.
Certain fields of the outer IP header that may change in transit
are zeroed for the authentication calculation. For IPv4, these
fields are:
Type of Service (TOS)
Time To Live (TTL)
Checksum
Offset
Flags
Also, IPv4 options are zeroed for the authentication
calculation, except for the IP Security Option BSO and ESO (RFC-1038,
RFC-1108) and the undocumented non-standard CIPSO (IPv4 Option number
134) option, which are included and are not zeroed.
For IPv6, the "IP Version", "Type of Service", "Flow Label", and
"Hop Limit" fields of the outermost IPv6 header are zeroed for the
authentication calculation. IPv6 options contain a bit that
indicates whether the option might change during transit. Options
that might change during transit are zeroed for the authentication
calculation and all others are included in the authentication
calculation. See the IPv6 specifications for more information.
Non-repudiation is not normally provided with the Authentication
Header. Confidentiality and traffic analysis protection are not
Atkinson [Page 10]
Internet Draft Security Architecture for IP 10 November 1996
provided by the Authentication Header. Replay Protection is normally
provided by the Authentication Header, though a user might choose not
to use it.
Use of the Authentication Header will increase the IP protocol
processing costs in participating systems and will also increase the
communications latency. The increased latency is primarily due to
the calculation of the authentication data by the sender and the
calculation and comparison of the authentication data by each
receiver for each IP datagram containing an Authentication Header
(AH).
The Authentication Header provides much stronger security than
exists in most of the current Internet and should not affect
exportability or significantly increase implementation cost. While
the Authentication Header might be implemented by a security gateway
on behalf of hosts on a trusted network behind that security gateway,
this mode of operation is not encouraged. Instead, whenever possible
the Authentication Header should be used from origin to final
destination so that end-to-end protections are provided.
All IPv6-capable nodes and all IPv4 systems claiming to
implement the Authentication Header MUST implement the standards-
track mandatory-to- implement AH transforms. As of this writing
these are HMAC MD5 [OG96] and HMAC SHA [CG96], but implementers
should consult the most recent edition of the "Internet Official
Protocol Standards" [STD-1] for current guidance. An implementation
MAY support other authentication algorithms in addition to the
mandatory transforms.
3.2 ENCAPSULATING SECURITY PAYLOAD
The IP Encapsulating Security Payload (ESP) is designed to
provide integrity, authentication, and confidentiality to IP
datagrams. [Atk96b] ESP can also provide replay protection when used
with certain transforms. ESP encapsulates either an entire IP
datagram or only the upper-layer protocol (e.g. TCP, UDP, ICMP) data
inside the ESP, applies integrity and authentication protections, and
encrypts the data. If tunnel-mode is in use, a new cleartext IP
header is prepended to the now encrypted Encapsulating Security
Payload. In tunnel-mode, the cleartext IP header is used to carry
the protected data through the internetwork.
3.2.1 Description of the ESP Modes
There are two modes within ESP. The first mode, which is known
as Tunnel-mode, encapsulates an entire IP datagram within the
ESP header. The second mode, which is known as Transport-
Atkinson [Page 11]
Internet Draft Security Architecture for IP 10 November 1996
mode, encapsulates an upper-layer protocol (for example UDP or TCP)
inside ESP and then prepends a cleartext IP header.
3.2.2 Usage of ESP
ESP works between hosts, between a host and a security gateway,
or between security gateways. This support for security gateways
permits trustworthy networks behind a security gateway to omit
encryption and thereby avoid the performance and monetary costs of
encryption, while still providing confidentiality for traffic
transiting untrustworthy network segments. When both hosts
directly implement ESP and there is no intervening security gateway,
then they may use the Transport- mode (where only the upper layer
protocol data (e.g. TCP or UDP) is encrypted and there is no
encrypted IP header). This mode reduces both the bandwidth
consumed and the protocol processing costs for users that don't need
to keep the entire IP datagram confidential. ESP works with both
unicast and multicast traffic.
3.2.3 Performance Impacts of ESP
The encapsulating security approach used by ESP can noticeably
impact network performance in participating systems, but use of ESP
should not adversely impact gateways or other intermediate systems
that are not participating in the particular ESP association.
Protocol processing in participating systems will be more complex
when encapsulating security is used, requiring both more time and
more processing power. Use of encryption will also increase the
communications latency. The increased latency is primarily due to
the encryption and decryption required for each IP datagram
containing an Encapsulating Security Payload. The precise cost of
ESP will vary with the specifics of the implementation, including the
encryption algorithm, key size, and other factors. Hardware
implementations of the encryption algorithm are recommended when high
throughput is desired.
For interoperability throughout the worldwide Internet, all
conforming implementations of the IP Encapsulating Security Payload
MUST also implement the standard mandatory ESP transform. As of this
writing, that is the Combined ESP transform with DES-CBC, HMAC MD5,
and Replay Protection. [Hugh96] Implementers should consult the most
recent "IAB Official Protocols" RFC for current information on the
mandatory to implement ESP transform(s). Other confidentiality
algorithms and modes may also be implemented in addition to this
mandatory algorithm and mode. Export and use of encryption are
regulated in some countries. [OTA94]
Atkinson [Page 12]
Internet Draft Security Architecture for IP 10 November 1996
3.3 COMBINING SECURITY MECHANISMS
A node normally does not apply both ESP and AH to the same IP
datagram. If confidentiality is not required, then AH should be
used. If confidentiality is required, then ESP should be used. In
some circumstances a security gateway might apply ESP (or AH) to a
packet before forwarding that packet because a secure tunnel has been
configured in that security gateway. Hence, IP packets containing
both ESP and AH are not strictly prohibited.
3.4 OTHER SECURITY MECHANISMS
Protection from traffic analysis is not provided by any of the
security mechanisms described above. It is unclear whether
meaningful protection from traffic analysis can be provided
economically at the Internet Layer and it appears that few Internet
users are concerned about traffic analysis. One traditional method
for protection against traffic analysis is the use of bulk link
encryption. Another technique is to send false traffic in order to
increase the noise in the data provided by traffic analysis.
Reference [VK83] discusses traffic analysis issues in more detail.
4. SECURITY ASSOCIATION MANAGEMENT
The Security Management protocol that will be used with IP layer
security is not specified in this document. However, because the
security management protocol is coupled to AH and ESP only via the
Security Parameters Index (SPI), we can meaningfully define AH and
ESP without having to fully specify how security management is
performed. We envision that several security management systems will
be usable with these specifications, including manual key
configuration.
Support for key management methods where the key management data
is carried in-line within the IP layer is not a design objective for
these IP-layer security mechanisms. Instead these IP-layer security
mechanisms will primarily use key management methods where the key
management data will be carried by an upper layer protocol, such as
UDP or TCP, on some specific port number or where the key management
data will be distributed manually.
This design permits clear decoupling of the key management
mechanism from the other security mechanisms, and thereby permits one
to substitute new and improved key management methods without having
to modify the implementations of the other security mechanisms. This
separation of mechanism is clearly wise given the long history of
subtle flaws in published key management protocols. [NS78, NS81] What
follows in this section is a brief discussion of a few alternative
Atkinson [Page 13]
Internet Draft Security Architecture for IP 10 November 1996
approaches to key management. Mutually consenting systems may
additionally use other key management approaches by private prior
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 security gateway might selectively encrypt traffic
for other sites within the organisation using a manually configured
key, while not encrypting traffic for other destinations. It also
might be appropriate when only selected communications need to be
secured.
4.2 Requirements for Key Management Protocols
Widespread deployment and use of IP security requires an
Internet-standard scalable key management protocol. This protocol
should not be limited to supporting IP security. This protocol
should be compatible with the IETF's DNS Security work and should
include the ability to obtain bootstrapping information (e.g. keys,
addresses) from the Secure DNS as a mandatory-to-implement feature.
signed host keys to the Domain Name System [EK96] The DNS keys enable
the originating party to authenticate key management messages with
the other key management party using an asymmetric algorithm. A
standards-track key management protocol for use with IP Security MUST
provide the property of "Perfect Forward Secrecy" as a mandatory-to-
implement feature. Further, any standards-track key management
protocol MUST permit the secure negotiation or secure identification
of all of the Security Association attributes [as defined above] to
all parties of that Security Association.
4.4 Keying Approaches for IP
There are several keying approaches for IP. The first approach,
called host-oriented keying, has all users on host 1 share the same
key for use on traffic destined for all users on host 2. The second
Atkinson [Page 14]
Internet Draft Security Architecture for IP 10 November 1996
approach, called user-oriented keying, lets user A on host 1 have one
or more unique session keys for its traffic destined for host 2; such
session keys are not shared with other users on host1. For example,
user A's ftp session might use a different key than user A's telnet
session. In systems claiming to provide multi-level security, user A
will typically have at least one key per sensitivity level in use
(e.g. one key for UNCLASSIFIED traffic, a second key for SECRET
traffic, and a third key for TOP SECRET traffic). Similarly, with
user-oriented keying one might use separate keys for information sent
to a multicast group and control messages sent to the same multicast
group. A third approach, called session-unique keying, has a single
key being assigned to a given IP address, upper-layer protocol, and
port number triple.
In many cases, a single computer system will have at least two
mutually suspicious users A and B that do not trust each other. When
host-oriented keying is used and mutually suspicious users exist, it
is sometimes possible for user A to determine the host-oriented key
via well known methods, such as a Chosen Plaintext attack. Once user
A has improperly obtained the key in use, user A can then either read
user B's encrypted traffic or forge traffic from user B. When user-
oriented keying is used, certain kinds of attack from one user onto
another user's traffic are not possible.
IP Security is intended to be able to provide Authentication,
Integrity, and Confidentiality for applications operating on
connected end systems when appropriate algorithms are in use.
Integrity and Confidentiality can be provided by host-oriented keying
when appropriate dynamic key management techniques and appropriate
algorithms are in use. However, authentication of principals using
applications on end-systems requires that processes running
applications be able to request and use their own Security
Associations. In this manner, applications can make use of key
distribution facilities that provide authentication.
Hence, support for session-unique keying MUST be present in all
IP Security implementations, as is described in the "IPsec Key
Management Requirements" section below. Support for other styles MAY
also be implemented.
4.5 Multicast Key Distribution
Multicast key distribution is an active research area in the
published literature as of this writing. For multicast groups having
relatively few members, manual key distribution or multiple use of
existing unicast key distribution algorithms such as modified Diffie-
Hellman appears feasible. For very large groups, new scalable
techniques will be needed. In-line key management systems that rely
Atkinson [Page 15]
Internet Draft Security Architecture for IP 10 November 1996
on pre-distributed master keys and then have serious scaling issues
that make them questionable for multicast traffic.
4.6 IPsec Key Management Requirements
This section defines key management requirements for all IPv6
implementations and for those IPv4 implementations that implement the
IP Authentication Header, the IP Encapsulating Security Payload, or
both. It applies equally to the IP Authentication Header and the IP
Encapsulating Security Payload.
All such implementations MUST support manual configuration of
Security Associations, including all of the attributes described in
the Security Association definition section of this document, having
variable SPI values within the non-reserved range. An implementation
that only supports a fixed SPI value is NOT conforming or compliant.
All IPv6 IP Security implementations MUST implement
ISAKMP/Oakley. All IPv4 IP Security implementations SHOULD implement
ISAKMP/Oakley. Other key management protocols MAY also be
implemented. [Sch96]
Implementations MAY also support other methods of configuring
Security Associations.
Given two endpoints, it MUST be possible to have more than one
concurrent Security Association for communications between them.
Implementations on multi-user hosts having at least discretionary
access controls MUST support either user granularity (i.e. "user-
oriented") Security Associations or session-unique Security
Associations.
All such implementations MUST permit the configuration of host-
oriented keying.
A device that encrypts or authenticates IP packets originated by
other systems, for example a dedicated IP encryptor or an security
gateway, cannot generally provide user-oriented keying for traffic
originating on other systems. Such systems MUST support session-
unique key selection based on source address, destination address,
upper-layer protocol, source port (if any), and destination port (if
any). Such systems MAY additionally implement support for user-
oriented keying for traffic originating on other systems.
The method by which keys are configured on a particular system
is implementation-defined. A flat file containing security
association identifiers and the security parameters, including the
key(s), is an example of one possible method for manual key
Atkinson [Page 16]
Internet Draft Security Architecture for IP 10 November 1996
distribution. An IP Security implementation MUST take reasonable
steps to protect the keys and other security association information
from unauthorised examination or modification because all of the
security lies in the keys.
5. USAGE
This section describes the possible use of the security
mechanisms provided by IP in several different environments and
applications in order to give the implementer and user a better idea
of how these mechanisms can be used to reduce security risks.
5.1 USE WITH FIREWALLS
Firewalls are not uncommon in the current Internet. [CB94]
While many dislike their presence because they restrict connectivity,
they are unlikely to disappear in the near future. Both of these IP
mechanisms can be used to increase the security provided by
firewalls.
Firewalls used with IP often need to be able to parse the
headers and options to determine the transport protocol (e.g. UDP or
TCP) in use and the port number for that protocol. Firewalls can be
used with the Authentication Header regardless of whether that
firewall is party to the appropriate Security Assocation. However, a
firewall that is not party to the applicable Security Association
will not normally be able to decrypt an encrypted upper-layer
protocol to view the protocol or port number needed to perform per-
packet filtering.
Further, firewalls need to verify that the data (e.g. source,
destination, transport protocol, port number) being used for access
control decisions is correct and authentic. Hence, authentication
might be performed not only within an organisation or campus but also
end to end with remote systems across the Internet. This use of the
Authentication Header with IP provides much more assurance that the
data being used for access control decisions is authentic.
Organisations with two or more sites that are interconnected
using commercial IP service might wish to use a selectively
encrypting firewall. If an encrypting firewall were placed between
each site of a company and the commercial IP service provider, the
firewall could provide an encrypted IP tunnel among all the company's
sites. It could also encrypt traffic between the company and its
suppliers, customers, and other affiliates. Traffic with the Network
Information Center, with public Internet archives, or some other
organisations might not be encrypted because of the unavailability of
a standard key management protocol or as a deliberate choice to
Atkinson [Page 17]
Internet Draft Security Architecture for IP 10 November 1996
facilitate better communications, improved network performance, and
increased connectivity. Such a practice could easily protect the
company's sensitive traffic from eavesdropping and modification.
Some organisations (e.g. governments) might wish to use a fully
encrypting firewall to provide a Virtual Private Network (VPN) over
commercial IP service. The difference between that and a bulk IP
encryption device is that a fully encrypting firewall would provide
filtering of the decrypted traffic as well as providing encryption of
IP packets. A related scenario is to use encryption between a mobile
computer and the security gateway or encrypting firewall of its home
campus.
5.2 USE WITH IP MULTICAST
In the past several years, the Multicast Backbone (MBONE) has
grown rapidly. IETF meetings and other conferences are now regularly
multicast with real-time audio, video, and whiteboards. Many people
are now using teleconferencing applications based on IP Multicast in
the Internet or in private internal networks. Others are using IP
multicasting to support distributed simulation or other applications.
Hence it is important that the security mechanisms in IP be suitable
for use in an environment where multicast is the general case.
The Security Parameters Indexes (SPIs) used in the IP security
mechanisms are receiver-oriented, making them well suited for use in
IP multicast. [Atk95a, Atk95b] Unfortunately, most currently
published multicast key distribution protocols do not scale well.
However, there is active research in this area. As an interim step,
a multicast group could repeatedly use a secure unicast key
distribution protocol to distribute the key to all members or the
group could pre-arrange keys using manual key distribution.
5.3 USE TO PROVIDE QOS PROTECTION
The recent IAB Security Workshop identified Quality of Service
protection as an area of significant interest. [BCCH] The two IP
security mechanisms are intended to provide good support for real-
time services as well as multicasting. This section describes one
possible approach to providing such protection.
The Authentication Header might be used, with appropriate key
management, to provide authentication of packets. This
authentication is potentially important in packet classification
within routers. The IPv6 Flow Identifier might act as a Low-Level
Identifier (LLID). Used together, packet classification within
routers becomes straightforward if the router is provided with the
appropriate keying material. For performance reasons the routers
Atkinson [Page 18]
Internet Draft Security Architecture for IP 10 November 1996
might authenticate only every Nth packet rather than every packet,
but this is still a significant improvement over capabilities in the
current Internet. Quality of service provisioning is likely to also
use the Flow ID in conjunction with a resource reservation protocol,
such as RSVP. [ZDESZ93] Thus, the authenticated packet classification
can be used to help ensure that each packet receives appropriate
handling inside routers.
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 security
mechanisms have been designed to support MLS networking. MLS
networking requires the use of strong Mandatory Access Controls
(MAC), which ordinary users are incapable of controlling or
violating. [BL73] This section pertains only to the use of these IP
security mechanisms in MLS environments.
The Authentication Header can be used to provide strong
authentication among hosts in a single-level network. The
Authentication Header can also be used to provide strong assurance
for both mandatory access control decisions in multi-level networks
and discretionary access control decisions in all kinds of networks.
If explicit IP sensitivity labels (e.g. IPSO) [Ken91] are used and
confidentiality is not considered necessary within the particular
operational environment, the Authentication Header is used to provide
authentication for the entire packet, including cryptographic binding
of the sensitivity level to the IP header and user data. This is a
significant improvement over labeled IPv4 networks where the label is
trusted even though it is not trustworthy because there is no
authentication or cryptographic binding of the label to the IP header
and user data. IPv6 will normally use implicit sensitivity labels
that are part of the Security Association but not transmitted with
each packet instead of using explicit sensitivity labels. All
explicit IP sensitivity labels MUST be authenticated using either
ESP, AH, or both.
The Encapsulating Security Payload can be combined with
appropriate key policies to provide full multi-level secure
networking. In this case each key must be used only at a single
sensitivity level and compartment. For example, Key "A" might be
used only for sensitive Unclassified packets, while Key "B" is used
only for Secret/No-compartments traffic, and Key "C" is used only for
Secret/Compartment-X traffic. The sensitivity level of the protected
traffic MUST NOT dominate the sensitivity level of the Security
Association used with that traffic. The sensitivity level of the
Atkinson [Page 19]
Internet Draft Security Architecture for IP 10 November 1996
Security Association MUST NOT dominate the sensitivity level of the
key that belongs to that Security Association. The sensitivity level
of the key SHOULD be the same as the sensitivity level of the
Security Association. The Authentication Header can also have
different keys for the same reasons, with the choice of key depending
in part on the sensitivity level of the packet.
Encryption is very useful and desirable even when all of the
hosts are within a protected environment. The Internet-standard
encryption algorithm could be used, in conjunction with appropriate
key management, to provide strong Discretionary Access Controls (DAC)
in conjunction with either implicit sensitivity labels or explicit
sensitivity labels (such as IPSO provides for IPv4 [Ken91]). Some
environments might consider the Internet-standard encryption
algorithm sufficiently strong to provide Mandatory Access Controls
(MAC). Full encryption should be used for all communications between
multi-level computers or compartmented mode workstations even when
the computing environment is considered to be protected.
6. SECURITY CONSIDERATIONS
This entire draft discusses the Security Architecture for the
Internet Protocol. It is not a general security architecture for the
Internet, but is instead focused on the IP layer.
Cryptographic transforms for ESP which use a block-chaining
algorithm and lack a strong integrity mechanism are vulnerable to a
cut-and-paste attack described by Bellovin and should not be used
unless the Authentication Header is always present with packets using
that ESP transform. [Bel95]
If more than one sender shares a Security Association with a
destination, then the receiving system can only authenticate that the
packet was sent from one of those systems and cannot authenticate
which of those systems sent it. Similarly, if the receiving system
does not check that the Security Association used for a packet is
valid for the claimed Source Address of the packet, then the
receiving system cannot authenticate whether the packet's claimed
Source Address is valid. For example, if senders "A" and "B" each
have their own unique Security Association with destination "D" and
"B" uses its valid Security Association with D but forges a Source
Address of "A", then "D" will be fooled into believing the packet
came from "A" unless "D" verifies that the claimed Source Address is
party to the Security Association that was used.
Users need to understand that the quality of the security
provided by the mechanisms provided by these two IP security
mechanisms depends completely on the strength of the implemented
Atkinson [Page 20]
Internet Draft Security Architecture for IP 10 November 1996
cryptographic algorithms, the strength of the key being used, the
correct implementation of the cryptographic algorithms, the security
of the key management protocol, and the correct implementation of IP
and the several security mechanisms in all of the participating
systems. The security of the implementation is in part related to
the security of the operating system which embodies the security
implementations. For example, if the operating system does not keep
the private cryptologic keys (that is, all symmetric keys and the
private asymmetric keys) confidential, then traffic using those keys
will not be secure. If any of these is incorrect or insufficiently
secure, little or no real security will be provided to the user.
Because different users on the same system might not trust each
other, each user or each session should usually be keyed separately.
This will also tend to increase the work required to cryptanalyse the
traffic since not all traffic will use the same key.
Certain security properties (e.g. traffic analysis protection)
are not provided by any of these mechanisms. One possible approach
to traffic analysis protection is appropriate use of link encryption.
[VK83] Users must carefully consider which security properties they
require and take active steps to ensure that their needs are met by
these or other mechanisms.
Certain applications (e.g. electronic mail) probably need to
have application-specific security mechanisms. Application-specific
security mechanisms are out of the scope of this document. Users
interested in electronic mail security should consult the RFCs
describing the Internet's Privacy-Enhanced Mail system. Users
concerned about other application-specific mechanisms should consult
the online RFCs to see if suitable Internet Standard mechanisms
exist.
ACKNOWLEDGEMENTS
Steve Kent provided detailed and helpful editorial input into
this draft. His contributions improved the draft significantly.
Many of the concepts here are derived from or were influenced by
the US Government's SDNS security protocol specifications, the
ISO/IEC's NLSP specification, or from the proposed swIPe security
protocol. [SDNS, ISO, IB93, IBK93] The work done for SNMP Security
and SNMPv2 Security influenced the choice of default cryptological
algorithms and modes. [GM93] Steve Bellovin, Steve Deering, Phil
Karn, Frank Kastenholz, Steve Kent, Perry Metzger, Dave Mihelcic,
Hilarie Orman and Bill Simpson provided careful critiques of earlier
versions of this draft.
Atkinson [Page 21]
Internet Draft Security Architecture for IP 10 November 1996
REFERENCES
[Atk96a] Randall Atkinson, IP Authentication Header, RFC-xxxx, 4 June 1996.
[Atk96b] Randall Atkinson, IP Encapsulating Security Payload, RFC-xxxx,
4 June 1996.
[BCCH94] R. Braden, D. Clark, S. Crocker, & C. Huitema, "Report of IAB
Workshop on Security in the Internet Architecture", RFC-1636,
DDN Network Information Center, June 1994.
[Bel89] Steven M. Bellovin, "Security Problems in the TCP/IP Protocol
Suite", ACM Computer Communications Review, Vol. 19, No. 2,
March 1989.
[Bel95] Steven M. Bellovin, Presentation at IP Security Working Group
Meeting, Proceedings of the 32nd Internet Engineering Task
Force, March 1995, Internet Engineering Task Force, Danvers, MA.
[BL73] Bell, D.E. & LaPadula, L.J., "Secure Computer Systems: Mathematical
Foundations and Model", Technical Report M74-244, The MITRE
Corporation, Bedford, MA, May 1973.
[CERT95] CA-95:01
[CB94] William R. Cheswick & Steven M. Bellovin, Firewalls & Internet
Security, Addison-Wesley, Reading, MA, 1994.
[CG96] Shu-jen Chang & Rob Glenn, "HMAC-SHA IP Authentication with Replay
Prevention", Internet Draft, 1 May 1996.
[DIA] US Defense Intelligence Agency, "Compartmented Mode Workstation
Specification", Technical Report DDS-2600-6243-87.
[DoD85] US National Computer Security Center, "Department of Defense
Trusted Computer System Evaluation Criteria", DoD 5200.28-STD,
US Department of Defense, Ft. Meade, MD., December 1985.
[DoD87] US National Computer Security Center, "Trusted Network
Interpretation of the Trusted Computer System Evaluation Criteria",
NCSC-TG-005, Version 1, US Department of Defense, Ft. Meade, MD.,
31 July 1987.
[DH76] W. Diffie & M. Hellman, "New Directions in Cryptography", IEEE
Transactions on Information Theory, Vol. IT-22, No. 6, November
1976, pp. 644-654.
[DH95] Steve Deering & Bob Hinden, Internet Protocol version 6 (IPv6)
Atkinson [Page 22]
Internet Draft Security Architecture for IP 10 November 1996
Specification, RFC-1883, December 1995.
[EK96] D. Eastlake III & C. Kaufman, "Domain Name System Protocol
Security Extensions", Internet Draft, 30 January 1996.
[GM93] J. Galvin & K. McCloghrie, Security Protocols for version 2
of the Simple Network Management Protocol (SNMPv2), RFC-1446,
DDN Network Information Center, April 1993.
[HA94] N. Haller & R. Atkinson, "On Internet Authentication", RFC-1704,
DDN Network Information Center, October 1994.
[Hugh96] J. Hughes (Editor), "Combined DES-CBC, HMAC, and Replay Prevention
Security Transform", Internet Draft, June 1996.
[ISO] ISO/IEC JTC1/SC6, Network Layer Security Protocol, ISO-IEC
DIS 11577, International Standards Organisation, Geneva,
Switzerland, 29 November 1992.
[IB93] John Ioannidis and Matt Blaze, "Architecture and Implementation of
Network-layer Security Under Unix", Proceedings of USENIX Security
Symposium, Santa Clara, CA, October 1993.
[IBK93] John Ioannidis, Matt Blaze, & Phil Karn, "swIPe: Network-Layer
Security for IP", presentation at the Spring 1993 IETF Meeting,
Columbus, Ohio.
[Ken78] Steve Kent, ..., Proceedings of SIGCOMM '78, ACM SIGCOMM, 1978.
[Ken91] Steve Kent, US DoD Security Options for the Internet Protocol,
RFC-1108, DDN Network Information Center, November 1991.
[Ken93] Steve Kent, Privacy Enhancement for Internet Electronic Mail:
Part II: Certificate-Based Key Management, RFC-1422, DDN Network
Information Center, 10 February 1993.
[KB93] J. Kohl & B. Neuman, The Kerberos Network Authentication
Service (V5), RFC-1510, DDN Network Information Center,
10 September 1993.
[NS78] R.M. Needham & M.D. Schroeder, "Using Encryption for Authentication
in Large Networks of Computers", Communications of the ACM,
Vol. 21, No. 12, December 1978, pp. 993-999.
[NS81] R.M. Needham & M.D. Schroeder, "Authentication Revisited",
ACM Operating Systems Review, Vol. 21, No. 1., 1981.
[OG96] Mike Oehler & Rob Glenn, "HMAC-MD5 IP Authentication with Replay
Atkinson [Page 23]
Internet Draft Security Architecture for IP 10 November 1996
Prevention", Internet Draft, 1 May 1996.
[OTA94] US Congress, Office of Technology Assessment, "Information
Security & Privacy in Network Environments", OTA-TCT-606,
Government Printing Office, Washington, DC, September 1994.
[Sch96] Jeff Schiller, "Security AD Statement on IPSEC Key Management",
Email to IPsec mailing list, September 19, 1996.
[Sch94] Bruce Schneier, Applied Cryptography, Section 8.6,
John Wiley & Sons, New York, NY, 1994.
[SDNS] SDNS Secure Data Network System, Security Protocol 3, SP3,
Document SDN.301, Revision 1.5, 15 May 1989, published
in NIST Publication NIST-IR-90-4250, February 1990.
[STD-1] J. Postel, "Internet Official Protocol Standards", STD-1,
March 1996.
[VK83] V.L. Voydock & S.T. Kent, "Security Mechanisms in High-level
Networks", ACM Computing Surveys, Vol. 15, No. 2, June 1983.
[ZDESZ93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and Zappala, D.,
"RSVP: A New Resource ReSerVation Protocol", IEEE Network magazine,
September 1993.
DISCLAIMER
The views expressed in this note are those of the editor and are not
necessarily those of his employer. The editor and his employer
specifically disclaim responsibility for any problems arising from correct
or incorrect implementation or use of this design.
EDITOR INFORMATION:
Randall Atkinson <rja@cisco.com>
cisco Systems
170 West Tasman Drive
San Jose, CA, 95134-1706
USA
Telephone: +1 (408) 526-4000
Atkinson [Page 24]