Request for Comments: 4322 SSW
Category: Informational D.H. Redelmeier
Mimosa
December 2005
Opportunistic Encryption using the Internet Key Exchange (IKE)
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes opportunistic encryption (OE) as designed and
implemented by the Linux FreeS/WAN project. OE uses the Internet Key
Exchange (IKE) and IPsec protocols. The objective is to allow
encryption for secure communication without any pre-arrangement
specific to the pair of systems involved. DNS is used to distribute
the public keys of each system involved. This is resistant to
passive attacks. The use of DNS Security (DNSSEC) secures this
system against active attackers as well.
As a result, the administrative overhead is reduced from the square
of the number of systems to a linear dependence, and it becomes
possible to make secure communication the default even when the
partner is not known in advance.
Table of Contents
1. Introduction ....................................................3
1.1. Motivation .................................................3
1.2. Encryption Regimes .........................................4
1.3. Peer Authentication in Opportunistic Encryption ............4
1.4. Use of RFC 2119 Terms ......................................5
2. Overview ........................................................6
2.1. Reference Diagram ..........................................6
2.2. Terminology ................................................6
2.3. Model of Operation .........................................8
3. Protocol Specification ..........................................9
3.1. Forwarding Plane State Machine .............................9
3.2. Keying Daemon -- Initiator ................................12
3.3. Keying Daemon -- Responder ................................20
3.4. Renewal and Teardown ......................................22
4. Impacts on IKE .................................................24
4.1. ISAKMP/IKE Protocol .......................................24
4.2. Gateway Discovery Process .................................24
4.3. Self Identification .......................................24
4.4. Public Key Retrieval Process ..............................25
4.5. Interactions with DNSSEC ..................................25
4.6. Required Proposal Types ...................................25
5. DNS Issues .....................................................26
5.1. Use of KEY Record .........................................26
5.2. Use of TXT Delegation Record ..............................27
5.3. Use of FQDN IDs ...........................................29
5.4. Key Roll-Over .............................................29
6. Network Address Translation Interaction ........................30
6.1. Co-Located NAT/NAPT .......................................30
6.2. Security Gateway behind a NAT/NAPT ........................30
6.3. End System behind a NAT/NAPT ..............................31
7. Host Implementations ...........................................31
8. Multi-Homing ...................................................31
9. Failure Modes ..................................................33
9.1. DNS Failures ..............................................33
9.2. DNS Configured, IKE Failures ..............................33
9.3. System Reboots ............................................34
10. Unresolved Issues .............................................34
10.1. Control of Reverse DNS ...................................34
11. Examples ......................................................34
11.1. Clear-Text Usage (Permit Policy) .........................34
11.2. Opportunistic Encryption .................................36
12. Security Considerations .......................................39
12.1. Configured versus Opportunistic Tunnels ..................39
12.2. Firewalls versus Opportunistic Tunnels ...................40
12.3. Denial of Service ........................................41
13. Acknowledgements ..............................................41
14. References ....................................................41
14.1. Normative References .....................................41
14.2. Informative References ...................................42
1. Introduction
1.1. Motivation
The objective of opportunistic encryption is to allow encryption
without any pre-arrangement specific to the pair of systems involved.
Each system administrator adds public key information to DNS records
to support opportunistic encryption and then enables this feature in
the nodes’ IPsec stack. Once this is done, any two such nodes can
communicate securely.
This document describes opportunistic encryption as designed and
implemented by the Linux FreeS/WAN project in revisions up and
including 2.00. Note that 2.01 and beyond implements [RFC3445] in a
backward compatible way. A future document [IPSECKEY] will describe
a variation that complies with RFC 3445. For project information,
see http://www.freeswan.org.
The Internet Architecture Board (IAB) and Internet Engineering
Steering Group (IESG) have taken a strong stand that the Internet
should use powerful encryption to provide security and privacy
[RFC1984]. The Linux FreeS/WAN project attempts to provide a
practical means to implement this policy.
The project uses the IPsec, ISAKMP/IKE, DNS, and DNSSEC protocols
because they are standardized, widely available, and can often be
deployed very easily without changing hardware or software, or
retraining users.
The extensions to support opportunistic encryption are simple. No
changes to any on-the-wire formats are needed. The only changes are
to the policy decision making system. This means that opportunistic
encryption can be implemented with very minimal changes to an
existing IPsec implementation.
Opportunistic encryption creates a "fax effect". The proliferation
of the fax machine was possible because it did not require that
everyone buy one overnight. Instead, as each person installed one,
the value of having one increased because there were more people that
could receive faxes. Once opportunistic encryption is installed, it
automatically recognizes other boxes using opportunistic encryption,
without any further configuration by the network administrator. So,
as opportunistic encryption software is installed on more boxes, its
value as a tool increases.
This document describes the infrastructure to permit deployment of
Opportunistic Encryption.
The term S/WAN is a trademark of RSA Data Systems, and is used with
permission by this project.
1.2. Encryption Regimes
To aid in understanding the relationship between security processing
and IPsec, we divide policies controlling network traffic into four
categories. The traffic is categorized by destination address using
longest prefix match. Therefore, each category is enumerated by a
set of network prefixes. The categories are mutually exclusive; a
particular prefix should only occur in one category.
* Deny: network prefixes to which traffic is always forbidden.
* Permit: network prefixes to which traffic in the clear is
permitted.
* Opportunistic tunnel: network prefixes to which traffic is
encrypted if possible, when it otherwise might be sent in the
clear.
* Configured tunnel: network prefixes to which traffic must be
encrypted, and traffic in the clear is never permitted. A
traditionally defined Virtual Private Network (VPN) is a form of
configured tunnel.
Traditional firewall devices handle the first two categories. No
authentication is required. The permit policy is currently the
default on the Internet.
This document describes the third category: opportunistic tunnel,
which is proposed as the new default for the Internet.
Category four’s policy is a very strict "encrypt it or drop it"
policy, which requires authentication of the endpoints. As the
number of endpoints is typically bounded and is typically under a
single authority, arranging for distribution of authentication
material, while difficult, does not require any new technology. The
mechanism described here, however, does provides an additional way to
distribute the authentication materials; it is a public key method
that does not require deployment of an X.509 based infrastructure.
1.3. Peer Authentication in Opportunistic Encryption
Opportunistic encryption creates tunnels between nodes that are
essentially strangers. This is done without any prior bilateral
arrangement. Therefore, there is the difficult question of how one
knows to whom one is talking.
One possible answer is that since no useful authentication can be
done, none should be tried. This mode of operation is named
"anonymous encryption". An active man-in-the-middle attack can be
used to thwart the privacy of this type of communication. Without
peer authentication, there is no way to prevent this kind of attack.
Although it is a useful mode, anonymous encryption is not the goal of
this project. Simpler methods are available that can achieve
anonymous encryption only, but authentication of the peer is a
desirable goal. Authentication of the peer is achieved through key
distribution in DNS, leveraging upon the authentication of the DNS in
DNSSEC.
Peers are, therefore, authenticated with DNSSEC when available.
Local policy determines how much trust to extend when DNSSEC is not
available.
An essential premise of building private connections with strangers
is that datagrams received through opportunistic tunnels are no more
special than datagrams that arrive in the clear. Unlike in a VPN,
these datagrams should not be given any special exceptions when it
comes to auditing, further authentication, or firewalling.
When initiating outbound opportunistic encryption, local
configuration determines what happens if tunnel setup fails. The
packet may go out in the clear, or it may be dropped.
1.4. Use of RFC 2119 Terms
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [RFC2119]
2. Overview
2.1. Reference Diagram
The following network diagram is used in the rest of this document as
the canonical diagram:
[Q] [R]
. . AS2
[A]----+----[SG-A].......+....+.......[SG-B]-------[B]
| ......
AS1 | ..PI..
| ......
[D]----+----[SG-D].......+....+.......[C] AS3
Figure 1: Reference Network Diagram
In this diagram, there are four end-nodes: A, B, C, and D. There are
three security gateways, SG-A, SG-B, SG-D. A, D, SG-A, and SG-D are
part of the same administrative authority, AS1. SG-A and SG-D are on
two different exit paths from organization 1. SG-B and B are part of
an independent organization, AS2. Nodes Q and R are nodes on the
Internet. PI is the Public Internet ("The Wild").
2.2. Terminology
Note: The network numbers used in this document are for illustrative
purposes only. This document could not use the reserved example
network numbers of [RFC3330] because multiple address ranges were
needed.
The following terminology is used in this document:
Security gateway (or simply gateway): a system that performs IPsec
tunnel mode encapsulation/decapsulation. [SG-x] in the diagram.
Alice: node [A] in the diagram. When an IP address is needed, this
is 192.1.0.65.
Bob: node [B] in the diagram. When an IP address is needed, this is
192.2.0.66.
Carol: node [C] in the diagram. When an IP address is needed, this
is 192.1.1.67.
Dave: node [D] in the diagram. When an IP address is needed, this is
192.3.0.68.
SG-A: Alice’s security gateway. Internally it is 192.1.0.1,
externally it is 192.1.1.4.
SG-B: Bob’s security gateway. Internally it is 192.2.0.1, externally
it is 192.1.1.5.
SG-D: Dave’s security gateway. Also Alice’s backup security gateway.
Internally it is 192.3.0.1, externally it is 192.1.1.6.
Configured tunnel: a tunnel that is directly and deliberately hand-
configured on participating gateways. Configured tunnels are
typically given a higher level of trust than opportunistic
tunnels.
Road warrior tunnel: a configured tunnel connecting one node with a
fixed IP address and one node with a variable IP address. A road
warrior (RW) connection must be initiated by the variable node,
since the fixed node cannot know the current address for the road
warrior.
Anonymous encryption: the process of encrypting a session without any
knowledge of who the other parties are. No authentication of
identities is done.
Opportunistic encryption: the process of encrypting a session with
authenticated knowledge of who the other party is without
prearrangement.
Lifetime: the period in seconds (bytes or datagrams) for which a
security association will remain alive before rekeying is needed.
Lifespan: the effective time for which a security association remains
useful. A security association with a lifespan shorter than its
lifetime would be removed when no longer needed. A security
association with a lifespan longer than its lifetime would need to
be re-keyed one or more times.
Phase 1 SA: an ISAKMP/IKE security association sometimes referred to
as a keying channel.
Phase 2 SA: an IPsec security association.
Tunnel: another term for a set of phase 2 SA (one in each direction).
NAT: Network Address Translation (see [RFC2663]).
NAPT: Network Address and Port Translation (see [RFC2663]).
AS: an autonomous system.
FQDN: Fully-Qualified Domain Name
Default-free zone: a set of routers that maintain a complete set of
routes to all currently reachable destinations. Having such a
list, these routers never make use of a default route. A datagram
with a destination address not matching any route will be dropped
by such a router.
2.3. Model of Operation
The opportunistic encryption security gateway (OE gateway) is a
regular gateway node, as described in [RFC0791] section 2.4 and
[RFC1812], with the additional capabilities described here and in
[RFC2401]. The algorithm described here provides a way to determine,
for each datagram, whether or not to encrypt and tunnel the datagram.
Two important things that must be determined are whether or not to
encrypt and tunnel and, if so, the destination address or name of the
tunnel endpoint that should be used.
2.3.1. Tunnel Authorization
The OE gateway determines whether or not to create a tunnel based on
the destination address of each packet. Upon receiving a packet with
a destination address not recently seen, the OE gateway performs a
lookup in DNS for an authorization resource record (see Section 5.2).
The record is located using the IP address to perform a search in the
in-addr.arpa (IPv4) or ip6.arpa (IPv6) maps. If an authorization
record is found, the OE gateway interprets this as a request for a
tunnel to be formed.
2.3.2. Tunnel Endpoint Discovery
The authorization resource record also provides the address or name
of the tunnel endpoint that should be used.
The record may also provide the public RSA key of the tunnel end
point itself. This is provided for efficiency only. If the public
RSA key is not present, the OE gateway performs a second lookup to
find a KEY resource record for the endpoint address or name.
Origin and integrity protection of the resource records is provided
by DNSSEC (see [RFC4033]). Section 3.2.4.1 documents an optional
restriction on the tunnel endpoint if DNSSEC signatures are not
available for the relevant records.
2.3.3. Caching of Authorization Results
The OE gateway maintains a cache, in the forwarding plane, of
source/destination pairs for which opportunistic encryption has been
attempted. This cache maintains a record of whether or not OE was
successful so that subsequent datagrams can be forwarded properly
without additional delay.
Successful negotiation of OE instantiates a new security association.
Failure to negotiate OE results in creation of a forwarding policy
entry either to deny or permit transmission in the clear future
datagrams. This negative cache is necessary to avoid the possibly
lengthy process of repeatedly looking up the same information.
The cache is timed out periodically, as described in Section 3.4.
This removes entries that are no longer being used and permits the
discovery of changes in authorization policy.
3. Protocol Specification
The OE gateway is modeled to have a forwarding plane and a control
plane. A control channel, such as PF_KEY [RFC2367], connects the two
planes.
The forwarding plane performs per-datagram operations. The control
plane contains a keying daemon, such as ISAKMP/IKE, and performs all
authorization, peer authentication, and key derivation functions.
3.1. Forwarding Plane State Machine
Let the OE gateway maintain a collection of objects -- a superset of
the security policy database (SPD) specified in [RFC2401]. For each
combination of source and destination address, an SPD object exists
in one of five following states. Prior to forwarding each datagram,
the responder uses the source and destination addresses to pick an
entry from the SPD. The SPD then determines if and how the packet is
forwarded.
.--------------.
| nonexistent |
| policy |
`--------------’
|
| PF_ACQUIRE
|
|<---------.
V | new packet
.--------------. | (maybe resend PF_ACQUIRE)
| hold policy |--’
| |--.
`--------------’ \ pass
| | \ msg .---------.
| | \ V | forward
| | .-------------. | packet
create | | | pass policy |--’
IPsec | | `-------------’
SA | |
| \
| \
V \ deny
.---------. \ msg
| encrypt | \
| policy | \ ,---------.
`---------’ \ | | discard
\ V | packet
.-------------. |
| deny policy |--’
`-------------’
3.1.1. Nonexistent Policy
If the gateway does not find an entry, then this policy applies. The
gateway creates an entry with an initial state of "hold policy" and
requests keying material from the keying daemon. The gateway does
not forward the datagram; rather, it SHOULD attach the datagram to
the SPD entry as the "first" datagram and retain it for eventual
transmission in a new state.
3.1.2. Hold Policy
The gateway requests keying material. If the interface to the keying
system is lossy (PF_KEY, for instance, can be), the implementation
SHOULD include a mechanism to retransmit the keying request at a rate
limited to less than 1 request per second. The gateway does not
forward the datagram. The gateway SHOULD attach the datagram to the
SPD entry as the "last" datagram, where it is retained for eventual
transmission. If there is a datagram already stored in this way,
then that already-stored datagram is discarded.
The rationale behind saving the "first" and "last" datagrams are as
follows: The "first" datagram is probably a TCP SYN packet. Once
there is keying established, the gateway will release this datagram,
avoiding the need for the endpoint to retransmit the datagram. In
the case where the connection was not a TCP connection, but was
instead a streaming protocol or a DNS request, the "last" datagram
that was retained is likely the most recent data. The difference
between "first" and "last" may also help the endpoints determine
which data was dropped while negotiation took place.
3.1.3. Pass-Through Policy
The gateway forwards the datagram using the normal forwarding table.
The gateway enters this state only by command from the keying daemon,
and upon entering this state, also forwards the "first" and "last"
datagrams.
3.1.4. Deny Policy
The gateway discards the datagram. The gateway enters this state
only by command from the keying daemon, and upon entering this state,
discards the "first" and "last" datagrams. An implementation MAY
provide the administrator with a control to determine if further
datagrams cause ICMP messages to be generated (i.e., ICMP Destination
Unreachable, Communication Administratively Prohibited. type=3,
code=13).
3.1.5. Encrypt Policy
The gateway encrypts the datagram using the indicated security
association database (SAD) entry. The gateway enters this state only
by command from the keying daemon, and upon entering this state,
releases and forwards the "first" and "last" datagrams using the new
encrypt policy.
If the associated SAD entry expires because of byte, packet or time
limits, then the entry returns to the Hold policy, and an expire
message is sent to the keying daemon.
All states may be created directly by the keying daemon while acting
as a gateway.
3.2. Keying Daemon -- Initiator
Let the keying daemon maintain a collection of objects. Let them be
called "connections" or "conn"s. There are two categories of
connection objects: classes and instances. A class represents an
abstract policy (i.e., what could be). An instance represents an
actual connection (i.e., what is running at the time).
Let there be two further subtypes of connections: keying channels
(Phase 1 SAs) and data channels (Phase 2 SAs). Each data channel
object may have a corresponding SPD and SAD entry maintained by the
datagram state machine.
For the purposes of opportunistic encryption, there MUST, at least,
be connection classes known as "deny", "always-clear-text", "OE-
permissive", and "OE-paranoid". The latter two connection classes
define a set of destination prefixes for which opportunistic
encryption will be attempted. The administrator MAY set policy
options in a number of additional places. An implementation MAY