RFC 2401
Security Architecture for the Internet Protocol
4. Security Associations This section defines Security Association management requirements for all IPv6 implementations and for those IPv4 implementations that implement AH, ESP, or both. The concept of a "Security Association" (SA) is fundamental to IPsec. Both AH and ESP make use of SAs and a major function of IKE is the establishment and maintenance of Security Associations. All implementations of AH or ESP MUST support the concept of a Security Association as described below. The remainder of this section describes various aspects of Security Association management, defining required characteristics for SA policy management, traffic processing, and SA management techniques. 4.1 Definition and Scope A Security Association (SA) is a simplex "connection" that affords security services to the traffic carried by it. Security services are afforded to an SA by the use of AH, or ESP, but not both. If both AH and ESP protection is applied to a traffic stream, then two (or more) SAs are created to afford protection to the traffic stream. To secure typical, bi-directional communication between two hosts, or between two security gateways, two Security Associations (one in each direction) are required. A security association is uniquely identified by a triple consisting of a Security Parameter Index (SPI), an IP Destination Address, and a security protocol (AH or ESP) identifier. In principle, the Destination Address may be a unicast address, an IP broadcast address, or a multicast group address. However, IPsec SA management mechanisms currently are defined only for unicast SAs. Hence, in the
discussions that follow, SAs will be described in the context of point-to-point communication, even though the concept is applicable in the point-to-multipoint case as well. As noted above, two types of SAs are defined: transport mode and tunnel mode. A transport mode SA is a security association between two hosts. In IPv4, a transport mode security protocol header appears immediately after the IP header and any options, and before any higher layer protocols (e.g., TCP or UDP). In IPv6, the security protocol header appears after the base IP header and extensions, but may appear before or after destination options, and before higher layer protocols. In the case of ESP, a transport mode SA provides security services only for these higher layer protocols, not for the IP header or any extension headers preceding the ESP header. In the case of AH, the protection is also extended to selected portions of the IP header, selected portions of extension headers, and selected options (contained in the IPv4 header, IPv6 Hop-by-Hop extension header, or IPv6 Destination extension headers). For more details on the coverage afforded by AH, see the AH specification [KA98a]. A tunnel mode SA is essentially an SA applied to an IP tunnel. Whenever either end of a security association is a security gateway, the SA MUST be tunnel mode. Thus an SA between two security gateways is always a tunnel mode SA, as is an SA between a host and a security gateway. Note that for the case where traffic is destined for a security gateway, e.g., SNMP commands, the security gateway is acting as a host and transport mode is allowed. But in that case, the security gateway is not acting as a gateway, i.e., not transiting traffic. Two hosts MAY establish a tunnel mode SA between themselves. The requirement for any (transit traffic) SA involving a security gateway to be a tunnel SA arises due to the need to avoid potential problems with regard to fragmentation and reassembly of IPsec packets, and in circumstances where multiple paths (e.g., via different security gateways) exist to the same destination behind the security gateways. For a tunnel mode SA, there is an "outer" IP header that specifies the IPsec processing destination, plus an "inner" IP header that specifies the (apparently) ultimate destination for the packet. The security protocol header appears after the outer IP header, and before the inner IP header. If AH is employed in tunnel mode, portions of the outer IP header are afforded protection (as above), as well as all of the tunneled IP packet (i.e., all of the inner IP header is protected, as well as higher layer protocols). If ESP is employed, the protection is afforded only to the tunneled packet, not to the outer header.
In summary,
a) A host MUST support both transport and tunnel mode.
b) A security gateway is required to support only tunnel
mode. If it supports transport mode, that should be used
only when the security gateway is acting as a host, e.g.,
for network management.
4.2 Security Association Functionality
The set of security services offered by an SA depends on the security
protocol selected, the SA mode, the endpoints of the SA, and on the
election of optional services within the protocol. For example, AH
provides data origin authentication and connectionless integrity for
IP datagrams (hereafter referred to as just "authentication"). The
"precision" of the authentication service is a function of the
granularity of the security association with which AH is employed, as
discussed in Section 4.4.2, "Selectors".
AH also offers an anti-replay (partial sequence integrity) service at
the discretion of the receiver, to help counter denial of service
attacks. AH is an appropriate protocol to employ when
confidentiality is not required (or is not permitted, e.g , due to
government restrictions on use of encryption). AH also provides
authentication for selected portions of the IP header, which may be
necessary in some contexts. For example, if the integrity of an IPv4
option or IPv6 extension header must be protected en route between
sender and receiver, AH can provide this service (except for the
non-predictable but mutable parts of the IP header.)
ESP optionally provides confidentiality for traffic. (The strength
of the confidentiality service depends in part, on the encryption
algorithm employed.) ESP also may optionally provide authentication
(as defined above). If authentication is negotiated for an ESP SA,
the receiver also may elect to enforce an anti-replay service with
the same features as the AH anti-replay service. The scope of the
authentication offered by ESP is narrower than for AH, i.e., the IP
header(s) "outside" the ESP header is(are) not protected. If only
the upper layer protocols need to be authenticated, then ESP
authentication is an appropriate choice and is more space efficient
than use of AH encapsulating ESP. Note that although both
confidentiality and authentication are optional, they cannot both be
omitted. At least one of them MUST be selected.
If confidentiality service is selected, then an ESP (tunnel mode) SA
between two security gateways can offer partial traffic flow
confidentiality. The use of tunnel mode allows the inner IP headers
to be encrypted, concealing the identities of the (ultimate) traffic
source and destination. Moreover, ESP payload padding also can be
invoked to hide the size of the packets, further concealing the external characteristics of the traffic. Similar traffic flow confidentiality services may be offered when a mobile user is assigned a dynamic IP address in a dialup context, and establishes a (tunnel mode) ESP SA to a corporate firewall (acting as a security gateway). Note that fine granularity SAs generally are more vulnerable to traffic analysis than coarse granularity ones which are carrying traffic from many subscribers. 4.3 Combining Security Associations The IP datagrams transmitted over an individual SA are afforded protection by exactly one security protocol, either AH or ESP, but not both. Sometimes a security policy may call for a combination of services for a particular traffic flow that is not achievable with a single SA. In such instances it will be necessary to employ multiple SAs to implement the required security policy. The term "security association bundle" or "SA bundle" is applied to a sequence of SAs through which traffic must be processed to satisfy a security policy. The order of the sequence is defined by the policy. (Note that the SAs that comprise a bundle may terminate at different endpoints. For example, one SA may extend between a mobile host and a security gateway and a second, nested SA may extend to a host behind the gateway.) Security associations may be combined into bundles in two ways: transport adjacency and iterated tunneling. o Transport adjacency refers to applying more than one security protocol to the same IP datagram, without invoking tunneling. This approach to combining AH and ESP allows for only one level of combination; further nesting yields no added benefit (assuming use of adequately strong algorithms in each protocol) since the processing is performed at one IPsec instance at the (ultimate) destination. Host 1 --- Security ---- Internet -- Security --- Host 2 | | Gwy 1 Gwy 2 | | | | | | | -----Security Association 1 (ESP transport)------- | | | -------Security Association 2 (AH transport)---------- o Iterated tunneling refers to the application of multiple layers of security protocols effected through IP tunneling. This approach allows for multiple levels of nesting, since each tunnel can originate or terminate at a different IPsec
site along the path. No special treatment is expected for
ISAKMP traffic at intermediate security gateways other than
what can be specified through appropriate SPD entries (See
Case 3 in Section 4.5)
There are 3 basic cases of iterated tunneling -- support is
required only for cases 2 and 3.:
1. both endpoints for the SAs are the same -- The inner and
outer tunnels could each be either AH or ESP, though it
is unlikely that Host 1 would specify both to be the
same, i.e., AH inside of AH or ESP inside of ESP.
Host 1 --- Security ---- Internet -- Security --- Host 2
| | Gwy 1 Gwy 2 | |
| | | |
| -------Security Association 1 (tunnel)---------- | |
| |
---------Security Association 2 (tunnel)--------------
2. one endpoint of the SAs is the same -- The inner and
uter tunnels could each be either AH or ESP.
Host 1 --- Security ---- Internet -- Security --- Host 2
| | Gwy 1 Gwy 2 |
| | | |
| ----Security Association 1 (tunnel)---- |
| |
---------Security Association 2 (tunnel)-------------
3. neither endpoint is the same -- The inner and outer
tunnels could each be either AH or ESP.
Host 1 --- Security ---- Internet -- Security --- Host 2
| Gwy 1 Gwy 2 |
| | | |
| --Security Assoc 1 (tunnel)- |
| |
-----------Security Association 2 (tunnel)-----------
These two approaches also can be combined, e.g., an SA bundle could
be constructed from one tunnel mode SA and one or two transport mode
SAs, applied in sequence. (See Section 4.5 "Basic Combinations of
Security Associations.") Note that nested tunnels can also occur
where neither the source nor the destination endpoints of any of the
tunnels are the same. In that case, there would be no host or
security gateway with a bundle corresponding to the nested tunnels.
For transport mode SAs, only one ordering of security protocols seems appropriate. AH is applied to both the upper layer protocols and (parts of) the IP header. Thus if AH is used in a transport mode, in conjunction with ESP, AH SHOULD appear as the first header after IP, prior to the appearance of ESP. In that context, AH is applied to the ciphertext output of ESP. In contrast, for tunnel mode SAs, one can imagine uses for various orderings of AH and ESP. The required set of SA bundle types that MUST be supported by a compliant IPsec implementation is described in Section 4.5. 4.4 Security Association Databases Many of the details associated with processing IP traffic in an IPsec implementation are largely a local matter, not subject to standardization. However, some external aspects of the processing must be standardized, to ensure interoperability and to provide a minimum management capability that is essential for productive use of IPsec. This section describes a general model for processing IP traffic relative to security associations, in support of these interoperability and functionality goals. The model described below is nominal; compliant implementations need not match details of this model as presented, but the external behavior of such implementations must be mappable to the externally observable characteristics of this model. There are two nominal databases in this model: the Security Policy Database and the Security Association Database. The former specifies the policies that determine the disposition of all IP traffic inbound or outbound from a host, security gateway, or BITS or BITW IPsec implementation. The latter database contains parameters that are associated with each (active) security association. This section also defines the concept of a Selector, a set of IP and upper layer protocol field values that is used by the Security Policy Database to map traffic to a policy, i.e., an SA (or SA bundle). Each interface for which IPsec is enabled requires nominally separate inbound vs. outbound databases (SAD and SPD), because of the directionality of many of the fields that are used as selectors. Typically there is just one such interface, for a host or security gateway (SG). Note that an SG would always have at least 2 interfaces, but the "internal" one to the corporate net, usually would not have IPsec enabled and so only one pair of SADs and one pair of SPDs would be needed. On the other hand, if a host had multiple interfaces or an SG had multiple external interfaces, it might be necessary to have separate SAD and SPD pairs for each interface.
4.4.1 The Security Policy Database (SPD) Ultimately, a security association is a management construct used to enforce a security policy in the IPsec environment. Thus an essential element of SA processing is an underlying Security Policy Database (SPD) that specifies what services are to be offered to IP datagrams and in what fashion. The form of the database and its interface are outside the scope of this specification. However, this section does specify certain minimum management functionality that must be provided, to allow a user or system administrator to control how IPsec is applied to traffic transmitted or received by a host or transiting a security gateway. The SPD must be consulted during the processing of all traffic (INBOUND and OUTBOUND), including non-IPsec traffic. In order to support this, the SPD requires distinct entries for inbound and outbound traffic. One can think of this as separate SPDs (inbound vs. outbound). In addition, a nominally separate SPD must be provided for each IPsec-enabled interface. An SPD must discriminate among traffic that is afforded IPsec protection and traffic that is allowed to bypass IPsec. This applies to the IPsec protection to be applied by a sender and to the IPsec protection that must be present at the receiver. For any outbound or inbound datagram, three processing choices are possible: discard, bypass IPsec, or apply IPsec. The first choice refers to traffic that is not allowed to exit the host, traverse the security gateway, or be delivered to an application at all. The second choice refers to traffic that is allowed to pass without additional IPsec protection. The third choice refers to traffic that is afforded IPsec protection, and for such traffic the SPD must specify the security services to be provided, protocols to be employed, algorithms to be used, etc. For every IPsec implementation, there MUST be an administrative interface that allows a user or system administrator to manage the SPD. Specifically, every inbound or outbound packet is subject to processing by IPsec and the SPD must specify what action will be taken in each case. Thus the administrative interface must allow the user (or system administrator) to specify the security processing to be applied to any packet entering or exiting the system, on a packet by packet basis. (In a host IPsec implementation making use of a socket interface, the SPD may not need to be consulted on a per packet basis, but the effect is still the same.) The management interface for the SPD MUST allow creation of entries consistent with the selectors defined in Section 4.4.2, and MUST support (total) ordering of these entries. It is expected that through the use of wildcards in various selector fields, and because all packets on a
single UDP or TCP connection will tend to match a single SPD entry,
this requirement will not impose an unreasonably detailed level of
SPD specification. The selectors are analogous to what are found in
a stateless firewall or filtering router and which are currently
manageable this way.
In host systems, applications MAY be allowed to select what security
processing is to be applied to the traffic they generate and consume.
(Means of signalling such requests to the IPsec implementation are
outside the scope of this standard.) However, the system
administrator MUST be able to specify whether or not a user or
application can override (default) system policies. Note that
application specified policies may satisfy system requirements, so
that the system may not need to do additional IPsec processing beyond
that needed to meet an application's requirements. The form of the
management interface is not specified by this document and may differ
for hosts vs. security gateways, and within hosts the interface may
differ for socket-based vs. BITS implementations. However, this
document does specify a standard set of SPD elements that all IPsec
implementations MUST support.
The SPD contains an ordered list of policy entries. Each policy
entry is keyed by one or more selectors that define the set of IP
traffic encompassed by this policy entry. (The required selector
types are defined in Section 4.4.2.) These define the granularity of
policies or SAs. Each entry includes an indication of whether
traffic matching this policy will be bypassed, discarded, or subject
to IPsec processing. If IPsec processing is to be applied, the entry
includes an SA (or SA bundle) specification, listing the IPsec
protocols, modes, and algorithms to be employed, including any
nesting requirements. For example, an entry may call for all
matching traffic to be protected by ESP in transport mode using
3DES-CBC with an explicit IV, nested inside of AH in tunnel mode
using HMAC/SHA-1. For each selector, the policy entry specifies how
to derive the corresponding values for a new Security Association
Database (SAD, see Section 4.4.3) entry from those in the SPD and the
packet (Note that at present, ranges are only supported for IP
addresses; but wildcarding can be expressed for all selectors):
a. use the value in the packet itself -- This will limit use
of the SA to those packets which have this packet's value
for the selector even if the selector for the policy entry
has a range of allowed values or a wildcard for this
selector.
b. use the value associated with the policy entry -- If this
were to be just a single value, then there would be no
difference between (b) and (a). However, if the allowed
values for the selector are a range (for IP addresses) or
wildcard, then in the case of a range,(b) would enable use
of the SA by any packet with a selector value within the
range not just by packets with the selector value of the
packet that triggered the creation of the SA. In the case
of a wildcard, (b) would allow use of the SA by packets
with any value for this selector.
For example, suppose there is an SPD entry where the allowed value
for source address is any of a range of hosts (192.168.2.1 to
192.168.2.10). And suppose that a packet is to be sent that has a
source address of 192.168.2.3. The value to be used for the SA could
be any of the sample values below depending on what the policy entry
for this selector says is the source of the selector value:
source for the example of
value to be new SAD
used in the SA selector value
--------------- ------------
a. packet 192.168.2.3 (one host)
b. SPD entry 192.168.2.1 to 192.168.2.10 (range of hosts)
Note that if the SPD entry had an allowed value of wildcard for the
source address, then the SAD selector value could be wildcard (any
host). Case (a) can be used to prohibit sharing, even among packets
that match the same SPD entry.
As described below in Section 4.4.3, selectors may include "wildcard"
entries and hence the selectors for two entries may overlap. (This
is analogous to the overlap that arises with ACLs or filter entries
in routers or packet filtering firewalls.) Thus, to ensure
consistent, predictable processing, SPD entries MUST be ordered and
the SPD MUST always be searched in the same order, so that the first
matching entry is consistently selected. (This requirement is
necessary as the effect of processing traffic against SPD entries
must be deterministic, but there is no way to canonicalize SPD
entries given the use of wildcards for some selectors.) More detail
on matching of packets against SPD entries is provided in Section 5.
Note that if ESP is specified, either (but not both) authentication
or encryption can be omitted. So it MUST be possible to configure
the SPD value for the authentication or encryption algorithms to be
"NULL". However, at least one of these services MUST be selected,
i.e., it MUST NOT be possible to configure both of them as "NULL".
The SPD can be used to map traffic to specific SAs or SA bundles.
Thus it can function both as the reference database for security
policy and as the map to existing SAs (or SA bundles). (To
accommodate the bypass and discard policies cited above, the SPD also
MUST provide a means of mapping traffic to these functions, even though they are not, per se, IPsec processing.) The way in which the SPD operates is different for inbound vs. outbound traffic and it also may differ for host vs. security gateway, BITS, and BITW implementations. Sections 5.1 and 5.2 describe the use of the SPD for outbound and inbound processing, respectively. Because a security policy may require that more than one SA be applied to a specified set of traffic, in a specific order, the policy entry in the SPD must preserve these ordering requirements, when present. Thus, it must be possible for an IPsec implementation to determine that an outbound or inbound packet must be processed thorough a sequence of SAs. Conceptually, for outbound processing, one might imagine links (to the SAD) from an SPD entry for which there are active SAs, and each entry would consist of either a single SA or an ordered list of SAs that comprise an SA bundle. When a packet is matched against an SPD entry and there is an existing SA or SA bundle that can be used to carry the traffic, the processing of the packet is controlled by the SA or SA bundle entry on the list. For an inbound IPsec packet for which multiple IPsec SAs are to be applied, the lookup based on destination address, IPsec protocol, and SPI should identify a single SA. The SPD is used to control the flow of ALL traffic through an IPsec system, including security and key management traffic (e.g., ISAKMP) from/to entities behind a security gateway. This means that ISAKMP traffic must be explicitly accounted for in the SPD, else it will be discarded. Note that a security gateway could prohibit traversal of encrypted packets in various ways, e.g., having a DISCARD entry in the SPD for ESP packets or providing proxy key exchange. In the latter case, the traffic would be internally routed to the key management module in the security gateway. 4.4.2 Selectors An SA (or SA bundle) may be fine-grained or coarse-grained, depending on the selectors used to define the set of traffic for the SA. For example, all traffic between two hosts may be carried via a single SA, and afforded a uniform set of security services. Alternatively, traffic between a pair of hosts might be spread over multiple SAs, depending on the applications being used (as defined by the Next Protocol and Port fields), with different security services offered by different SAs. Similarly, all traffic between a pair of security gateways could be carried on a single SA, or one SA could be assigned for each communicating host pair. The following selector parameters MUST be supported for SA management to facilitate control of SA granularity. Note that in the case of receipt of a packet with an ESP header, e.g., at an encapsulating security gateway or BITW
implementation, the transport layer protocol, source/destination
ports, and Name (if present) may be "OPAQUE", i.e., inaccessible
because of encryption or fragmentation. Note also that both Source
and Destination addresses should either be IPv4 or IPv6.
- Destination IP Address (IPv4 or IPv6): this may be a single IP
address (unicast, anycast, broadcast (IPv4 only), or multicast
group), a range of addresses (high and low values (inclusive),
address + mask, or a wildcard address. The last three are used
to support more than one destination system sharing the same SA
(e.g., behind a security gateway). Note that this selector is
conceptually different from the "Destination IP Address" field
in the <Destination IP Address, IPsec Protocol, SPI> tuple used
to uniquely identify an SA. When a tunneled packet arrives at
the tunnel endpoint, its SPI/Destination address/Protocol are
used to look up the SA for this packet in the SAD. This
destination address comes from the encapsulating IP header.
Once the packet has been processed according to the tunnel SA
and has come out of the tunnel, its selectors are "looked up" in
the Inbound SPD. The Inbound SPD has a selector called
destination address. This IP destination address is the one in
the inner (encapsulated) IP header. In the case of a
transport'd packet, there will be only one IP header and this
ambiguity does not exist. [REQUIRED for all implementations]
- Source IP Address(es) (IPv4 or IPv6): this may be a single IP
address (unicast, anycast, broadcast (IPv4 only), or multicast
group), range of addresses (high and low values inclusive),
address + mask, or a wildcard address. The last three are used
to support more than one source system sharing the same SA
(e.g., behind a security gateway or in a multihomed host).
[REQUIRED for all implementations]
- Name: There are 2 cases (Note that these name forms are
supported in the IPsec DOI.)
1. User ID
a. a fully qualified user name string (DNS), e.g.,
mozart@foo.bar.com
b. X.500 distinguished name, e.g., C = US, SP = MA,
O = GTE Internetworking, CN = Stephen T. Kent.
2. System name (host, security gateway, etc.)
a. a fully qualified DNS name, e.g., foo.bar.com
b. X.500 distinguished name
c. X.500 general name
NOTE: One of the possible values of this selector is "OPAQUE".
[REQUIRED for the following cases. Note that support for name
forms other than addresses is not required for manually keyed
SAs.
o User ID
- native host implementations
- BITW and BITS implementations acting as HOSTS
with only one user
- security gateway implementations for INBOUND
processing.
o System names -- all implementations]
- Data sensitivity level: (IPSO/CIPSO labels)
[REQUIRED for all systems providing information flow security as
per Section 8, OPTIONAL for all other systems.]
- Transport Layer Protocol: Obtained from the IPv4 "Protocol" or
the IPv6 "Next Header" fields. This may be an individual
protocol number. These packet fields may not contain the
Transport Protocol due to the presence of IP extension headers,
e.g., a Routing Header, AH, ESP, Fragmentation Header,
Destination Options, Hop-by-hop options, etc. Note that the
Transport Protocol may not be available in the case of receipt
of a packet with an ESP header, thus a value of "OPAQUE" SHOULD
be supported.
[REQUIRED for all implementations]
NOTE: To locate the transport protocol, a system has to chain
through the packet headers checking the "Protocol" or "Next
Header" field until it encounters either one it recognizes as a
transport protocol, or until it reaches one that isn't on its
list of extension headers, or until it encounters an ESP header
that renders the transport protocol opaque.
- Source and Destination (e.g., TCP/UDP) Ports: These may be
individual UDP or TCP port values or a wildcard port. (The use
of the Next Protocol field and the Source and/or Destination
Port fields (in conjunction with the Source and/or Destination
Address fields), as an SA selector is sometimes referred to as
"session-oriented keying."). Note that the source and
destination ports may not be available in the case of receipt of
a packet with an ESP header, thus a value of "OPAQUE" SHOULD be
supported.
The following table summarizes the relationship between the
"Next Header" value in the packet and SPD and the derived Port
Selector value for the SPD and SAD.
Next Hdr Transport Layer Derived Port Selector Field
in Packet Protocol in SPD Value in SPD and SAD
-------- --------------- ---------------------------
ESP ESP or ANY ANY (i.e., don't look at it)
-don't care- ANY ANY (i.e., don't look at it)
specific value specific value NOT ANY (i.e., drop packet)
fragment
specific value specific value actual port selector field
not fragment
If the packet has been fragmented, then the port information may
not be available in the current fragment. If so, discard the
fragment. An ICMP PMTU should be sent for the first fragment,
which will have the port information. [MAY be supported]
The IPsec implementation context determines how selectors are used.
For example, a host implementation integrated into the stack may make
use of a socket interface. When a new connection is established the
SPD can be consulted and an SA (or SA bundle) bound to the socket.
Thus traffic sent via that socket need not result in additional
lookups to the SPD/SAD. In contrast, a BITS, BITW, or security
gateway implementation needs to look at each packet and perform an
SPD/SAD lookup based on the selectors. The allowable values for the
selector fields differ between the traffic flow, the security
association, and the security policy.
The following table summarizes the kinds of entries that one needs to
be able to express in the SPD and SAD. It shows how they relate to
the fields in data traffic being subjected to IPsec screening.
(Note: the "wild" or "wildcard" entry for src and dst addresses
includes a mask, range, etc.)
Field Traffic Value SAD Entry SPD Entry
-------- ------------- ---------------- --------------------
src addr single IP addr single,range,wild single,range,wildcard
dst addr single IP addr single,range,wild single,range,wildcard
xpt protocol* xpt protocol single,wildcard single,wildcard
src port* single src port single,wildcard single,wildcard
dst port* single dst port single,wildcard single,wildcard
user id* single user id single,wildcard single,wildcard
sec. labels single value single,wildcard single,wildcard
* The SAD and SPD entries for these fields could be "OPAQUE"
because the traffic value is encrypted.
NOTE: In principle, one could have selectors and/or selector values
in the SPD which cannot be negotiated for an SA or SA bundle.
Examples might include selector values used to select traffic for
discarding or enumerated lists which cause a separate SA to be created for each item on the list. For now, this is left for future versions of this document and the list of required selectors and selector values is the same for the SPD and the SAD. However, it is acceptable to have an administrative interface that supports use of selector values which cannot be negotiated provided that it does not mislead the user into believing it is creating an SA with these selector values. For example, the interface may allow the user to specify an enumerated list of values but would result in the creation of a separate policy and SA for each item on the list. A vendor might support such an interface to make it easier for its customers to specify clear and concise policy specifications. 4.4.3 Security Association Database (SAD) In each IPsec implementation there is a nominal Security Association Database, in which each entry defines the parameters associated with one SA. Each SA has an entry in the SAD. For outbound processing, entries are pointed to by entries in the SPD. Note that if an SPD entry does not currently point to an SA that is appropriate for the packet, the implementation creates an appropriate SA (or SA Bundle) and links the SPD entry to the SAD entry (see Section 5.1.1). For inbound processing, each entry in the SAD is indexed by a destination IP address, IPsec protocol type, and SPI. The following parameters are associated with each entry in the SAD. This description does not purport to be a MIB, but only a specification of the minimal data items required to support an SA in an IPsec implementation. For inbound processing: The following packet fields are used to look up the SA in the SAD: o Outer Header's Destination IP address: the IPv4 or IPv6 Destination address. [REQUIRED for all implementations] o IPsec Protocol: AH or ESP, used as an index for SA lookup in this database. Specifies the IPsec protocol to be applied to the traffic on this SA. [REQUIRED for all implementations] o SPI: the 32-bit value used to distinguish among different SAs terminating at the same destination and using the same IPsec protocol. [REQUIRED for all implementations] For each of the selectors defined in Section 4.4.2, the SA entry in the SAD MUST contain the value or values which were negotiated at the time the SA was created. For the sender, these values are used to decide whether a given SA is appropriate for use with an outbound packet. This is part of checking to see if there is an existing SA
that can be used. For the receiver, these values are used to check
that the selector values in an inbound packet match those for the SA
(and thus indirectly those for the matching policy). For the
receiver, this is part of verifying that the SA was appropriate for
this packet. (See Section 6 for rules for ICMP messages.) These
fields can have the form of specific values, ranges, wildcards, or
"OPAQUE" as described in section 4.4.2, "Selectors". Note that for
an ESP SA, the encryption algorithm or the authentication algorithm
could be "NULL". However they MUST not both be "NULL".
The following SAD fields are used in doing IPsec processing:
o Sequence Number Counter: a 32-bit value used to generate the
Sequence Number field in AH or ESP headers.
[REQUIRED for all implementations, but used only for outbound
traffic.]
o Sequence Counter Overflow: a flag indicating whether overflow
of the Sequence Number Counter should generate an auditable
event and prevent transmission of additional packets on the
SA.
[REQUIRED for all implementations, but used only for outbound
traffic.]
o Anti-Replay Window: a 32-bit counter and a bit-map (or
equivalent) used to determine whether an inbound AH or ESP
packet is a replay.
[REQUIRED for all implementations but used only for inbound
traffic. NOTE: If anti-replay has been disabled by the
receiver, e.g., in the case of a manually keyed SA, then the
Anti-Replay Window is not used.]
o AH Authentication algorithm, keys, etc.
[REQUIRED for AH implementations]
o ESP Encryption algorithm, keys, IV mode, IV, etc.
[REQUIRED for ESP implementations]
o ESP authentication algorithm, keys, etc. If the
authentication service is not selected, this field will be
null.
[REQUIRED for ESP implementations]
o Lifetime of this Security Association: a time interval after
which an SA must be replaced with a new SA (and new SPI) or
terminated, plus an indication of which of these actions
should occur. This may be expressed as a time or byte count,
or a simultaneous use of both, the first lifetime to expire
taking precedence. A compliant implementation MUST support
both types of lifetimes, and must support a simultaneous use
of both. If time is employed, and if IKE employs X.509
certificates for SA establishment, the SA lifetime must be
constrained by the validity intervals of the certificates,
and the NextIssueDate of the CRLs used in the IKE exchange
for the SA. Both initiator and responder are responsible for
constraining SA lifetime in this fashion.
[REQUIRED for all implementations]
NOTE: The details of how to handle the refreshing of keys
when SAs expire is a local matter. However, one reasonable
approach is:
(a) If byte count is used, then the implementation
SHOULD count the number of bytes to which the IPsec
algorithm is applied. For ESP, this is the encryption
algorithm (including Null encryption) and for AH,
this is the authentication algorithm. This includes
pad bytes, etc. Note that implementations SHOULD be
able to handle having the counters at the ends of an
SA get out of synch, e.g., because of packet loss or
because the implementations at each end of the SA
aren't doing things the same way.
(b) There SHOULD be two kinds of lifetime -- a soft
lifetime which warns the implementation to initiate
action such as setting up a replacement SA and a
hard lifetime when the current SA ends.
(c) If the entire packet does not get delivered during
the SAs lifetime, the packet SHOULD be discarded.
o IPsec protocol mode: tunnel, transport or wildcard.
Indicates which mode of AH or ESP is applied to traffic on
this SA. Note that if this field is "wildcard" at the
sending end of the SA, then the application has to specify
the mode to the IPsec implementation. This use of wildcard
allows the same SA to be used for either tunnel or transport
mode traffic on a per packet basis, e.g., by different
sockets. The receiver does not need to know the mode in
order to properly process the packet's IPsec headers.
[REQUIRED as follows, unless implicitly defined by context:
- host implementations must support all modes
- gateway implementations must support tunnel mode]
NOTE: The use of wildcard for the protocol mode of an inbound
SA may add complexity to the situation in the receiver (host
only). Since the packets on such an SA could be delivered in
either tunnel or transport mode, the security of an incoming
packet could depend in part on which mode had been used to
deliver it. If, as a result, an application cared about the
SA mode of a given packet, then the application would need a
mechanism to obtain this mode information.
o Path MTU: any observed path MTU and aging variables. See
Section 6.1.2.4
[REQUIRED for all implementations but used only for outbound
traffic]
4.5 Basic Combinations of Security Associations
This section describes four examples of combinations of security
associations that MUST be supported by compliant IPsec hosts or
security gateways. Additional combinations of AH and/or ESP in
tunnel and/or transport modes MAY be supported at the discretion of
the implementor. Compliant implementations MUST be capable of
generating these four combinations and on receipt, of processing
them, but SHOULD be able to receive and process any combination. The
diagrams and text below describe the basic cases. The legend for the
diagrams is:
==== = one or more security associations (AH or ESP, transport
or tunnel)
---- = connectivity (or if so labelled, administrative boundary)
Hx = host x
SGx = security gateway x
X* = X supports IPsec
NOTE: The security associations below can be either AH or ESP. The
mode (tunnel vs transport) is determined by the nature of the
endpoints. For host-to-host SAs, the mode can be either transport or
tunnel.
Case 1. The case of providing end-to-end security between 2 hosts
across the Internet (or an Intranet).
====================================
| |
H1* ------ (Inter/Intranet) ------ H2*
Note that either transport or tunnel mode can be selected by the
hosts. So the headers in a packet between H1 and H2 could look
like any of the following:
Transport Tunnel
----------------- ---------------------
1. [IP1][AH][upper] 4. [IP2][AH][IP1][upper]
2. [IP1][ESP][upper] 5. [IP2][ESP][IP1][upper]
3. [IP1][AH][ESP][upper]
Note that there is no requirement to support general nesting,
but in transport mode, both AH and ESP can be applied to the
packet. In this event, the SA establishment procedure MUST
ensure that first ESP, then AH are applied to the packet.
Case 2. This case illustrates simple virtual private networks
support.
===========================
| |
---------------------|---- ---|-----------------------
| | | | | |
| H1 -- (Local --- SG1* |--- (Internet) ---| SG2* --- (Local --- H2 |
| Intranet) | | Intranet) |
-------------------------- ---------------------------
admin. boundary admin. boundary
Only tunnel mode is required here. So the headers in a packet
between SG1 and SG2 could look like either of the following:
Tunnel
---------------------
4. [IP2][AH][IP1][upper]
5. [IP2][ESP][IP1][upper]
Case 3. This case combines cases 1 and 2, adding end-to-end security
between the sending and receiving hosts. It imposes no new
requirements on the hosts or security gateways, other than a
requirement for a security gateway to be configurable to pass
IPsec traffic (including ISAKMP traffic) for hosts behind it.
===============================================================
| |
| ========================= |
| | | |
---|-----------------|---- ---|-------------------|---
| | | | | | | |
| H1* -- (Local --- SG1* |-- (Internet) --| SG2* --- (Local --- H2* |
| Intranet) | | Intranet) |
-------------------------- ---------------------------
admin. boundary admin. boundary
Case 4. This covers the situation where a remote host (H1) uses the
Internet to reach an organization's firewall (SG2) and to then
gain access to some server or other machine (H2). The remote
host could be a mobile host (H1) dialing up to a local PPP/ARA
server (not shown) on the Internet and then crossing the
Internet to the home organization's firewall (SG2), etc. The
details of support for this case, (how H1 locates SG2,
authenticates it, and verifies its authorization to represent
H2) are discussed in Section 4.6.3, "Locating a Security
Gateway".
======================================================
| |
|============================== |
|| | |
|| ---|----------------------|---
|| | | | |
H1* ----- (Internet) ------| SG2* ---- (Local ----- H2* |
^ | Intranet) |
| ------------------------------
could be dialup admin. boundary (optional)
to PPP/ARA server
Only tunnel mode is required between H1 and SG2. So the choices
for the SA between H1 and SG2 would be one of the ones in case
2. The choices for the SA between H1 and H2 would be one of the
ones in case 1.
Note that in this case, the sender MUST apply the transport
header before the tunnel header. Therefore the management
interface to the IPsec implementation MUST support configuration
of the SPD and SAD to ensure this ordering of IPsec header
application.
As noted above, support for additional combinations of AH and ESP is
optional. Use of other, optional combinations may adversely affect
interoperability.
4.6 SA and Key Management
IPsec mandates support for both manual and automated SA and
cryptographic key management. The IPsec protocols, AH and ESP, are
largely independent of the associated SA management techniques,
although the techniques involved do affect some of the security
services offered by the protocols. For example, the optional anti-
replay services available for AH and ESP require automated SA
management. Moreover, the granularity of key distribution employed
with IPsec determines the granularity of authentication provided.
(See also a discussion of this issue in Section 4.7.) In general,
data origin authentication in AH and ESP is limited by the extent to
which secrets used with the authentication algorithm (or with a key
management protocol that creates such secrets) are shared among
multiple possible sources.
The following text describes the minimum requirements for both types of SA management. 4.6.1 Manual Techniques The simplest form of management is manual management, in which a person manually configures each system with keying material and security association management data relevant to secure communication with other systems. Manual techniques are practical in small, static environments but they do not scale well. For example, a company could create a Virtual Private Network (VPN) using IPsec in security gateways at several sites. If the number of sites is small, and since all the sites come under the purview of a single administrative domain, this is likely to be a feasible context for manual management techniques. In this case, the security gateway might selectively protect traffic to and from other sites within the organization using a manually configured key, while not protecting traffic for other destinations. It also might be appropriate when only selected communications need to be secured. A similar argument might apply to use of IPsec entirely within an organization for a small number of hosts and/or gateways. Manual management techniques often employ statically configured, symmetric keys, though other options also exist. 4.6.2 Automated SA and Key Management Widespread deployment and use of IPsec requires an Internet-standard, scalable, automated, SA management protocol. Such support is required to facilitate use of the anti-replay features of AH and ESP, and to accommodate on-demand creation of SAs, e.g., for user- and session-oriented keying. (Note that the notion of "rekeying" an SA actually implies creation of a new SA with a new SPI, a process that generally implies use of an automated SA/key management protocol.) The default automated key management protocol selected for use with IPsec is IKE [MSST97, Orm97, HC98] under the IPsec domain of interpretation [Pip98]. Other automated SA management protocols MAY be employed. When an automated SA/key management protocol is employed, the output from this protocol may be used to generate multiple keys, e.g., for a single ESP SA. This may arise because: o the encryption algorithm uses multiple keys (e.g., triple DES) o the authentication algorithm uses multiple keys o both encryption and authentication algorithms are employed
The Key Management System may provide a separate string of bits for each key or it may generate one string of bits from which all of them are extracted. If a single string of bits is provided, care needs to be taken to ensure that the parts of the system that map the string of bits to the required keys do so in the same fashion at both ends of the SA. To ensure that the IPsec implementations at each end of the SA use the same bits for the same keys, and irrespective of which part of the system divides the string of bits into individual keys, the encryption key(s) MUST be taken from the first (left-most, high- order) bits and the authentication key(s) MUST be taken from the remaining bits. The number of bits for each key is defined in the relevant algorithm specification RFC. In the case of multiple encryption keys or multiple authentication keys, the specification for the algorithm must specify the order in which they are to be selected from a single string of bits provided to the algorithm. 4.6.3 Locating a Security Gateway This section discusses issues relating to how a host learns about the existence of relevant security gateways and once a host has contacted these security gateways, how it knows that these are the correct security gateways. The details of where the required information is stored is a local matter. Consider a situation in which a remote host (H1) is using the Internet to gain access to a server or other machine (H2) and there is a security gateway (SG2), e.g., a firewall, through which H1's traffic must pass. An example of this situation would be a mobile host (Road Warrior) crossing the Internet to the home organization's firewall (SG2). (See Case 4 in the section 4.5 Basic Combinations of Security Associations.) This situation raises several issues: 1. How does H1 know/learn about the existence of the security gateway SG2? 2. How does it authenticate SG2, and once it has authenticated SG2, how does it confirm that SG2 has been authorized to represent H2? 3. How does SG2 authenticate H1 and verify that H1 is authorized to contact H2? 4. How does H1 know/learn about backup gateways which provide alternate paths to H2? To address these problems, a host or security gateway MUST have an administrative interface that allows the user/administrator to configure the address of a security gateway for any sets of destination addresses that require its use. This includes the ability to configure:
o the requisite information for locating and authenticating the
security gateway and verifying its authorization to represent
the destination host.
o the requisite information for locating and authenticating any
backup gateways and verifying their authorization to represent
the destination host.
It is assumed that the SPD is also configured with policy information
that covers any other IPsec requirements for the path to the security
gateway and the destination host.
This document does not address the issue of how to automate the
discovery/verification of security gateways.
4.7 Security Associations and Multicast
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 to conflict with automatically configured (e.g., via a
key management protocol) Security Associations or for Security
Associations from multiple sources to conflict with each other. For
multicast traffic, there are multiple destination systems per
multicast group. So some system or person will need to coordinate
among all multicast groups to select an SPI or SPIs on behalf of each
multicast group and then communicate the group's IPsec 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 key encryption or authentication
algorithm is employed. In such circumstances, the receiver knows only
that the message came from a system possessing the key for that
multicast group. In such circumstances, a receiver generally will
not be able to authenticate which system sent the multicast traffic.
Specifications for other, more general multicast cases are deferred
to later IPsec documents.
At the time this specification was published, automated protocols for
multicast key distribution were not considered adequately mature for
standardization. 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. An example of current work in this area is the Group Key
Management Protocol (GKMP) [HM97].
(next page on part 3)
