Network Working Group M. Richardson Internet-Draft SSW Expires: September 30, 2002 D. Redelmeier Mimosa H. Spencer SP Systems April 2002 Opportunistic Encryption using The Internet Key Exchange (IKE) draft-richardson-ipsec-opportunistic-09.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 30, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document describes opportunistic encryption (OE) using the Internet Key Exchange (IKE) and IPsec. Each system administrator makes local arrangements -- adds new resource records to its Domain Name System (DNS) -- to support opportunistic encryption. The objective is to allow encryption without any pre-arrangement specific to the pair of systems involved. Once that is done, any two such Richardson, et al. Expires September 30, 2002 [Page 1] Internet-Draft opportunistic April 2002 systems can communicate securely. 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. There are two large payoffs. First, the administrative overhead is reduced from the square of the number of systems to a linear dependence. Second, it becomes possible to make secure communication the default, even when the partner is not known in advance. This document is offered up as an Informational RFC. Richardson, et al. Expires September 30, 2002 [Page 2] Internet-Draft opportunistic April 2002 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 5 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . 5 1.2 Types of network traffic . . . . . . . . . . . . . . . . 6 1.3 Peer authentication in Opportunistic Encryption . . . . 6 1.4 Use of RFC2119 terms . . . . . . . . . . . . . . . . . . 7 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1 Reference diagram . . . . . . . . . . . . . . . . . . . 8 2.2 Terminology . . . . . . . . . . . . . . . . . . . . . . 8 2.3 Model of Operation . . . . . . . . . . . . . . . . . . . 10 3. Specification . . . . . . . . . . . . . . . . . . . . . 12 3.1 Datagram State Machine . . . . . . . . . . . . . . . . . 12 3.2 Keying State Machine - Initiator . . . . . . . . . . . . 13 3.3 Keying State Machine - Responder . . . . . . . . . . . . 18 3.4 Renewal and Teardown . . . . . . . . . . . . . . . . . . 19 4. Impacts on IKE . . . . . . . . . . . . . . . . . . . . . 22 4.1 ISAKMP/IKE protocol . . . . . . . . . . . . . . . . . . 22 4.2 Gateway discovery process . . . . . . . . . . . . . . . 22 4.3 Self identification . . . . . . . . . . . . . . . . . . 22 4.4 Public key Retrieval process . . . . . . . . . . . . . . 23 4.5 Interactions with DNSSEC . . . . . . . . . . . . . . . . 23 4.6 Recommended proposal types . . . . . . . . . . . . . . . 23 5. DNS issues . . . . . . . . . . . . . . . . . . . . . . . 25 5.1 Use of KEY record . . . . . . . . . . . . . . . . . . . 25 5.2 Use of TXT delegation record . . . . . . . . . . . . . . 25 5.3 Use of FQDN IDs . . . . . . . . . . . . . . . . . . . . 27 5.4 Key roll-over . . . . . . . . . . . . . . . . . . . . . 28 6. Network Address Translation interaction . . . . . . . . 29 6.1 Co-located NAT/NAPT . . . . . . . . . . . . . . . . . . 29 6.2 SG-A behind NAT/NAPT . . . . . . . . . . . . . . . . . . 29 6.3 Bob is behind a NAT/NAPT . . . . . . . . . . . . . . . . 29 7. Host implementations . . . . . . . . . . . . . . . . . . 30 8. Multihoming . . . . . . . . . . . . . . . . . . . . . . 31 9. Failure modes . . . . . . . . . . . . . . . . . . . . . 33 9.1 DNS failures . . . . . . . . . . . . . . . . . . . . . . 33 9.2 DNS configured, IKE failures . . . . . . . . . . . . . . 33 9.3 System reboots . . . . . . . . . . . . . . . . . . . . . 33 10. Unresolved issues . . . . . . . . . . . . . . . . . . . 35 Richardson, et al. Expires September 30, 2002 [Page 3] Internet-Draft opportunistic April 2002 10.1 Control of reverse DNS . . . . . . . . . . . . . . . . . 35 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . 36 11.1 Clear-text usage (permit policy) . . . . . . . . . . . . 36 11.2 Opportunistic Encryption . . . . . . . . . . . . . . . . 37 between Alice and Bob . . . . . . . . . . . . . . . . . 41 12. Security Considerations . . . . . . . . . . . . . . . . 43 12.1 Configured vs Opportunistic Tunnels . . . . . . . . . . 43 12.2 Firewalls vs Opportunistic Tunnels . . . . . . . . . . . 44 12.3 Denial of Service . . . . . . . . . . . . . . . . . . . 44 13. IANA Considerations . . . . . . . . . . . . . . . . . . 45 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . 46 Normative references . . . . . . . . . . . . . . . . . . 47 Authors' Addresses . . . . . . . . . . . . . . . . . . . 48 Full Copyright Statement . . . . . . . . . . . . . . . . 49 Richardson, et al. Expires September 30, 2002 [Page 4] Internet-Draft opportunistic April 2002 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 makes local arrangements -- specifically, adds public key information to DNS records -- to support opportunistic encryption and then enables this feature in the nodes' IPsec stack. Once that is done, any two such nodes can communicate securely. This document describes opportunistic encryption as designed and mostly implemented by the Linux FreeS/WAN project. 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 [4]. This project attempts to put this policy into practice by providing practical means to implement them. The project believes that the IPsec, ISAKMP/IKE, DNS and DNSSEC protocols are the best chance to do that, because they are standardized, widely available and can often be deployed very easily, without changing hardware or software or retraining of 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. The use of "opportunistic encryption" offers the "fax effect". As each person installs one for their own use, it becomes more valuable for their neighbors to install one too, because there's one more person to use it with. The software automatically notices each newly installed box, and doesn't require a network administrator to reconfigure it. This document describes the infrastructure needed to support this effort. The term S/WAN is a trademark of RSA Data Systems, and is used with permission by this project. Richardson, et al. Expires September 30, 2002 [Page 5] Internet-Draft opportunistic April 2002 1.2 Types of network traffic To aid in understanding the relationship between security processing and IPsec we divide network traffic into four categories: * deny: networks to which traffic is always forbidden * permit: networks to which traffic in the clear is desired * opportunistic tunnel: networks to which encryption should be done if possible, but communication is done in the clear otherwise or fails, depending on default policy * configured tunnel: networks to which encryption must be done, and communication is never in the clear The first two categories are provided by traditional firewall devices. Category one, denied traffic by IP address, requires no authentication. Category two, permitted traffic by IP address, requires no authentication. This is has been the default on the Internet. This document describes the third category, which is proposed as the new default policy for the Internet. Category four, encrypt traffic or drop it, requires authentication of the end points. As the number of end points 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 provides an additional way to distribute the authentication materials, notably a public key method that does not require deployment of an X.509 based infrastructure. Current Virtual Private Networks can often be replaced by a "OE paranoid" policy as described herein. 1.3 Peer authentication in Opportunistic Encryption Opportunistic encryption involves creating tunnels with other nodes that are essentially strangers. This is done without any prior bilateral arrangement. There is therefore the difficult question of how does one know who one is talking to. One possible answer is that one does not know who one is talking to. No useful authentication can be done, so do not even try. This mode of operation has been given the name "anonymous encryption". A man- in-the-middle attack can be used to thwart the privacy of this Richardson, et al. Expires September 30, 2002 [Page 6] Internet-Draft opportunistic April 2002 communication. This would be an active attack. Without peer authentication, there is no way to prevents this kind of attack. Although a useful mode, it is not the goal of this project. It is a useful starting point, but the system should permit additional layers of trust to be built upon this system. In the described system, the anonymous encryption case is what results without DNSSEC. Were anonymous encryption the end goal, simpler methods are available to achieve this goal. Peers are therefore authenticated with DNSSEC when available. It is a matter of local policy to decide how much trust to extend when DNSSEC is not available. However, an essential premise of building private connections with strangers is that datagrams received through these opportunistic tunnels are no more special than datagrams that arrived in the clear. Unlike in a VPN scenario, these datagrams should not be given any special exceptions when it comes to auditing, further authentication or firewalling. On the outbound side, when initiating opportunistic encryption, it becomes a local matter what to do if one fails to setup a tunnel. It may be that the packet goes out in the clear, or it may be dropped. This is a local configuration matter. In sum, we gain wider privacy (for the Internet at large) at minimal cost: the cost is the need to reassess assumptions about the relationship between IPsec authentication and further local access control. 1.4 Use of RFC2119 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 [5] Richardson, et al. Expires September 30, 2002 [Page 7] Internet-Draft opportunistic April 2002 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 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/B is an independent organizations, AS2. Nodes Q and R are nodes that are on the Internet. PI is the Public Internet ("The Wild"). 2.2 Terminology The following terminology is used in this document: security 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 Richardson, et al. Expires September 30, 2002 [Page 8] Internet-Draft opportunistic April 2002 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. - a single dash represents clear-text datagrams = an equals sign represents phase 2 (IPsec) cipher-text datagrams ~ a single tilde represents clear-text phase 1 datagrams # a hash sign represents phase 1 (IKE) cipher-text datagrams . a period represents an untrusted network of unknown type configured tunnel: Contrast with opportunistic tunnel. A tunnel that is directly/deliberately/hand configured on participating gateways. Configured tunnel 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 does not know what the address for the "road warrior" currently is. anonymous encryption: The process of encrypting a session without any knowledge of who the other parities are. That is, no authentication of identities is done. opportunistic encryption: The process of encrypting a session with authenticated knowledge of who the other parties are. lifetime: The period in seconds (bytes or datagrams) which a security association will remain alive before needing to be re- keyed. lifespan: The effective time 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. Richardson, et al. Expires September 30, 2002 [Page 9] Internet-Draft opportunistic April 2002 phase 1 SA: an ISAKMP/IKE security association, sometimes also referred to as a keying channel and also referred to as "Main Mode". phase 2 SA: an IPsec security association, also sometimes called a "Quick Mode" SA tunnel: another term for a set of phase 2 SA (one in each direction) NAT: Network Address Translation (see [20]) NAPT: Network Address and Port Translation (see [20]) AS: an Autonomous System (AS) is a group of systems (a network) that are under the administrative control of a single organization. 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 [2] section 2.4 and [3] with additional capabilities described here and in [7]. The algorithm described here provides a way to determine, for each datagram, whether or not to encrypt and tunnel the datagram. Thus, two important things that must be determined are whether or not to encrypt/tunnel and, if so, to which destination. 2.3.1 Tunnel Authorization The decision as to whether or not to create a tunnel is determined on a per-destination address basis. 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). This record is located using the IP address to perform a search in the in-addr.arpa (IPv4) or ip6.arpa (IPv6) maps. The presence of an authorization record indicates the desire for a tunnel to be formed. Richardson, et al. Expires September 30, 2002 [Page 10] Internet-Draft opportunistic April 2002 2.3.2 Tunnel End-point discovery The record further provides the address or name of the tunnel end- point which 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 this is not present, then the address or name provided is used to perform a second lookup to find a KEY Resource Record. Origin and integrity protection of the resource records is provided by DNSSEC ([16]). Section 3.2.4.1 documents an optional restriction on the tunnel end point 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 results in a new security association being instantiated. Failure to negotiate OE results in creation of a forwarding policy entry - either to drop or transmit in the clear future datagrams. This negative cache is necessary so as to avoid repeatedly looking up the same information, a possibly lengthly process. The cache is timed out periodically, as described in Section 3.4. This is done to remove entries which are no longer being used and to permit changes in authorization policy to be discovered. Richardson, et al. Expires September 30, 2002 [Page 11] Internet-Draft opportunistic April 2002 3. Specification The OE gateway is modeled to have a forwarding plane and a control plane. They are connected by a control channel such as PF_KEY. (See [6]) 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 Datagram State Machine Let the OE gateway maintain a collection of objects -- a superset of the Security Policy Database specific in [7]. For each combination of source and destination address, one may find an SPD object in one of five states. Prior to forwarding each datagram, the source and destination addresses are used to pick an entry from the SPD. The SPD then determines if, and how, the packet is forwarded. 3.1.1 Non-existent policy If there is no entry found, then this policy applies. An entry is created with an initial state of "Hold policy". A request for keying material is sent to the keying daemon. The datagram is not forwarded, rather it is attached to the SPD entry as the "first" datagram and retained for eventual transmission in a new state. 3.1.2 Hold policy A request for keying has been previously made. If the interface to the keying system is lossy (PF_KEY, for instance, can be) a mechanism to retransmit the keying request, rate limited to less than 1 request per second SHOULD be made. The datagram is not forwarded. The datagram is attached to the SPD entry as the "last" datagram and retained for eventual transmission. If there was previously a datagram so stored, then it is discarded. The retention of the "first" datagram attempts to avoid waiting for a TCP retransmit, as the first datagram is probably a TCP SYN packet. The retention of the last datagram as well applies to streaming protocols, where it is useful to know how much data has been lost. These are recommendations to decrease latency - there is no operational requirements for this. 3.1.3 Pass-through policy The datagram is forwarded using the normal forwarding table. This state is entered only via command from the keying daemon. Upon entering this state, the "first" and "last" datagrams are forwarded. Richardson, et al. Expires September 30, 2002 [Page 12] Internet-Draft opportunistic April 2002 3.1.4 Deny policy The datagram is discarded. This state is entered only via command from the keying daemon. Upon entering this state, the "first" and "last" datagrams are discarded. It is a local matter if further datagrams cause ICMP messages to be generated (i.e. ICMP Administratively denied). 3.1.5 Encrypt policy The datagram is encrypted using the indicated Security Association Database (SAD) entry. This state is entered only via command from the keying daemon. Upon entering this state, the "first" and "last" datagrams are released using the new encrypt policy and forwarded. If the associated SAD entry expires (due to byte, packet or time limits) then the entry returns to the Hold policy, causing an expire message to be communicated to the keying daemon. All states may be created directly by the keying daemon while acting as a responder. 3.2 Keying State Machine - Initiator Let the keying daemon maintain a collection of objects -- let them be called "connections" (or "conn"s for short). There are two categories of connection objects: classes and instances. A class connection represents an abstract policy - what could be. An instance represents an actual connection, what is in fact implemented at the time. Let there be two further subtypes of connections: keying channels (aka Phase 1 SAs) and data channels (aka 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", "OE-paranoid". The latter two connection classes define a set of source and/or destination addresses for which Opportunistic Encryption will be attempted. There are a number of additional places where the administrator MAY set policy options. An implementation MAY create additional connection classes so that these policies may be enacted in a more fine grained fashion. The simplest system may need only the "OE-permissive" connection, and would list its own (single) IP address as the source address of this policy, and the wild-card address 0.0.0.0/0 as the destination IPv4 address. That is, the simplest policy is to try Opportunistic Encryption with all destinations. Richardson, et al. Expires September 30, 2002 [Page 13] Internet-Draft opportunistic April 2002 The distinction between permissive and paranoid OE use will become clear in the state transition differences. In general, a permissive OE will, on failure, install a pass-through policy, while a paranoid OE will, on failure, install a drop policy. In this description of the keying machines state transitions, the states associated with the keying system itself are omitted. This is done for two reasons: they are best documented in the keying system ([8], [9] and [10] for ISAKMP/IKE), and the details are keying system specific. Opportunistic Encryption is not dependent upon any specific keying protocol, but this document does provide requirements for those using ISAKMP/IKE to assure inter-operability. The state transitions that may be involved in communicating with the forwarding plane are omitted. PF_KEY and similar protocols have their own set of states required for message sends and completion notifications. Finally, the retransmits and recursive lookups that are normal for DNS are not included in this state machine. 3.2.1 Nonexistent connection There is no connection for a given source/destination address pair. Upon receipt of a request for keying material for this particular source/destination pair, a search is made through the connection classes to determine the most appropriate policy. Upon determining an appropriate connection class, then an instance object is created of that type. Both of the OE types results in a Potential OE connection. Failure to find an appropriate connection class results in an administrator defined default. In each case, when an appropriate class is found for the new flow then an instance connection is made of the type which matched. 3.2.2 clear-text connection A transition is made from the non-existent connection to this state when an instance of the always-clear-text class is instantiated, or when an OE-permissive connection fails. During the transition, a pass-through policy object is created in the forwarding plane for the appropriate flow. The only way to leave this state is due to a timeout; see expiry connection. Richardson, et al. Expires September 30, 2002 [Page 14] Internet-Draft opportunistic April 2002 3.2.3 Deny connection A transition is made from the empty connection to this state when an instance of the deny class is instantiated, or when an OE-paranoid connection fails. During the transition, a deny policy object is created in the forwarding plane for the appropriate flow. The only way to leave this state is due to a timeout; see expiry connection. 3.2.4 Potential OE connection A transition is made from the empty connection to this state when an instance of either OE class is instantiated. During the transition to this state, a hold policy object is created in the forwarding plane for the appropriate flow. In addition, when transitioning into this state, DNS lookup(s) are done in the reverse map for a TXT delegation resource record. (see Section 5.2) The destination address of the flow is used as the lookup key. There are three ways to exit this state: due a timeout in the DNS lookup, and via positive or negative replies as to the existence of the TXT delegation resource record. If there is a resource record found, and it is properly formatted, and if DNSSEC is enabled - the signature has been vouched for (either through local confirmation or via trusted path to a recursive DNSSEC server), then there is a transition to the Pending OE connection state. (Note that if the public key is not presented in the TXT delegation record, then it must be looked up as well as a sub-state. The DNS lookups are not considered a success until all have completed successfully) If there is no resource record found, or DNS times out then it is to be considered that this is not an OE capable receiver. If this was an OE-paranoid instance, then there is a transition to the deny connection. If this was an OE-permissive instance, then there is a transition to the clear-text connection. If the resource record is found but is misformed, or if DNSSEC has been enabled and reports a failure to authenticate, then there should be a transition to the deny connection. This fact SHOULD be logged. If the administrator wishes to override this, then an always-clear class can be installed for this flow. An implementation MAY make this situation a new class. Richardson, et al. Expires September 30, 2002 [Page 15] Internet-Draft opportunistic April 2002 3.2.4.1 Restriction on unauthenticated TXT delegation records An implementation SHOULD also provide an additional administrative control on delegation records and DNSSEC. This control would apply to delegation records (the TXT records in the reverse map) that are not protected by DNSSEC. Records of this type are only permitted to delegate to their own address as a gateway. When this option is enabled, an active attack on DNS will be unable to redirect packets to other than the original destination. 3.2.5 Pending OE connection A transition is made from the Potential OE connection to this state when it has been determined that all the information from DNS requires is present. Upon entering this state, an attempt to initiate keying to the gateway provided is started. One exits from this state either with a successfully created IPsec SA, or with a failure of some kind. Successful SA creation results in a transition to the Key connection state. There are three failures which are distinguished. They are clearly not the only possible failures from keying, but these are the ones that have caused the most problems. Note that if there were multiple gateways available in the TXT delegation records, then a failure can only be declared after all have been tried. Further, creation of a phase 1 SA does not constitute success - a set of phase 2 SAs (a tunnel) is considered success. The first failure is when an ICMP port unreachable is consistently received without any other communication, or when there is silence from the remote end. This likely means that the gateway is either not alive, or that the keying daemon is not functional. For an OE- permissive connection, transition to the clear-text connection, but with a rather low lifespan. The gateway may be in the process of rebooting, etc. For an OE-pessimistic connection, transition to the deny connection, again with a low lifespan. How long is long enough to wait for the remote keying daemon to wake up is a matter of some debate. 5 minutes is usually long enough for the network to reconverge if there is a routing failure. Many systems can reboot in that time as well. However, 5 minutes is far too long for most users to wait to hear that they can not connect with OE. Implementations SHOULD make this a tunable parameter. If a phase 1 SA is created, but there is either no response to the Richardson, et al. Expires September 30, 2002 [Page 16] Internet-Draft opportunistic April 2002 phase 2 proposal, or a negative notify (the notify must be authenticated) is received, then the remote gateway is not prepared to do OE at this time. As before transition to clear-text/deny based upon connection class, but this time with a normal lifespan. The third type of failure is when there is signature failure authenticating the remote gateway. In this case, again transition to clear-text/deny based upon the connection class, but make the timeout depend upon the remaining time to live in the DNS. (Note that DNSSEC signed resource records have a different expiry time from non-signed records) One possibility is that there has been a key roll-over, but that DNS has not caught up. 3.2.6 Keyed connection A transition is made from the Pending OE connection to this state when session keying material (aka the phase 2 SAs) has been formed. An Encrypt Policy is created in the forwarding plane for this flow. There are three ways to exit this state. The first is by receipt of an authenticated delete message (via the keying channel) from the peer. This is normal teardown, and results in a transition to Expired connection. The second way is by expiry of the forwarding plane keying material. This causes a re-key operation to be started with a transition back to Pending OE connection. In general, the soft expiry will occur with sufficient time left for the keys to continue to be used. Note that a re-key can fail, which may result in the connection failing to clear-text or deny as appropriate. Note that in the event of a failure, the forwarding plane policy does not change until the phase 2 SA (IPsec SA) has reached its hard expiry. The third way is via a response to a negotiation from a remote gateway, via receipt of an indication from the forwarding plane of having received an unknown SPI from that gateway, or an ICMP from the remote gateway indicating an unknown SPI. Each of these things should be considered a hint that the remote gateway has rebooted or restarted. Since these can easily be forged, care must be exercised. A cautious (rate-limited) attempt to re-key the connection should be done. 3.2.7 Expiring connection Each of the deny, clear-text, and keyed connections will periodically be placed into this sub-state. See Section 3.4 for more details of how often this occurs. The forwarding plane is queried for last use time of the appropriate policy. If the use time is relatively Richardson, et al. Expires September 30, 2002 [Page 17] Internet-Draft opportunistic April 2002 recent, then the state returns to the previous deny, clear-text or keyed connection state. If not, then it enters the expired connection state. The DNS query and answer that lead to the state in question is also examined. It may have become stale. (A negative, i.e. no such record answer is valid for the period of time given by the MINIMUM field in an attached SOA record. See [12] section 4.3.4) If it has become stale, then a new query is made. If a change in the results are seen, then a transition to a new state is made as described in Potential OE connection state. Note that both outgoing SPD and incoming SAD must be queried as some flows may be unidirectional for some time. Note that the policy at the forwarding plane is not updated unless there is a conclusion that there should be a change. 3.2.8 Expired connection Entry to this state is due to no datagrams being forwarded recently via the appropriate SPD and SAD objects. The objects in the forwarding plane are removed (logging any final byte and packet counts if appropriate) and the connection instance in the keying plane is deleted. An ISAKMP/IKE Delete is sent to clean up the phase 2 SAs as described in Section 3.4. A difficult question has been whether or not to also delete the phase 1 SAs at this time. This is left as a local implementation issue. Implementations that do delete the phase 1 SAs MUST send authenticated Delete messages to indicate that they are doing so. There is some advantage to simply keeping the phase 1 SAs around until they expire - they may prove useful again in the near future. 3.3 Keying State Machine - Responder The responder has an identical set of objects as the initiator. The responder gets its first indication that something is happening when it receives an invitation to create a keying channel from an initiator. 3.3.1 Unauthenticated OE peer Upon entering this state, a DNS lookup is done for a KEY record for the initiator. This is done in the reverse map for a KEY record for Richardson, et al. Expires September 30, 2002 [Page 18] Internet-Draft opportunistic April 2002 the initiator if the initiator has offered an ID_IPV4_ADDR, and in the forward map if the initiator has offered an ID_FQDN type. (See [8] section 4.6.2.1.) This state is exited upon successful receipt of a KEY from DNS, and use of it to verify the signature of the initiator. Successful authentication of the peer results in a transition to Authenticated OE Peer. Note that this state generally occurs in the middle of the key negotiation protocol. It is really a form of pseudo-state. 3.3.2 Authenticated OE Peer The peer will eventually propose one or more phase 2 SAs. The source and destination address in the proposal are used to initialize the still empty connection state using the connection class table. A search for an identical connection object MUST be made at this point. If an identical connection is found, then delete the old instance that had been created, and transition this new object to the Pending OE connection state. This means that new ISAKMP connections with a given peer will always use the latest instance, which is the correct one if the peer has rebooted in the interim. If an identical connection is not found, then transition according to the rules given for the initiator. Note that if the initiator is in OE-paranoid mode and the responder is in either always-clear-text or deny, then no communication is possible according to policy. An implementation is permitted to create new types of policies, such as "accept OE, but do not initiate it". This is a local matter. 3.4 Renewal and Teardown 3.4.1 Aging A potentially unlimited number of tunnels may exist. In practice, only a few tunnels are used during a period of time. Unused tunnels MUST therefore be torn down. Detecting when they are no longer in use is the subject of this section. There are two methods in which the tunnel may be removed: by expiring or with explicit deletion. Explicit deletion is done with an IKE Delete message. To do this Richardson, et al. Expires September 30, 2002 [Page 19] Internet-Draft opportunistic April 2002 requires that both ends maintain the key channel (phase 1 ISAKMP SA), as the deletes MUST be authenticated. An implementation which refuses to either maintain or recreate the keying channel SA will be unable to use this method. In the expiry method, the tunnel is simply allowed by the IKE daemon to expire normally, without attempting to re-key it. Regardless of which method is used, a method is required to determine if the tunnel is still in use. This is a local matter, but the following criteria are what is used by the FreeSWAN project. This criteria is currently implemented in the key management daemon, but could also be implemented at the SPD layer using an idle timer. + a short initial (soft) lifespan of 1 minute is set. This is done since many net flows in fact last only a few seconds. + at the end of the lifespan, a check is made to see if the tunnel was used by traffic in either direction during the last half of this period. If so, assign a longer tentative lifespan, of 20 minutes, after which, look again. If the tunnel is not in use then close the tunnel. These timeouts are implemented by the Expiring state in the key management system (see Section 3.2.7). The timer given above may in fact be present in the forwarding plane, but it must, in this case be resettable. The tentative lifespan is independent of re-keying; it is just the time when the tunnel's future is next considered. (The term lifespan is used here rather than lifetime for this reason.) This should happen reasonably frequently, unlike re-keying, which is costly and shouldn't be too frequent. A multi-step back-off algorithm is not considered worth the effort here. If the security gateway and the client host are one and the same (and not a Bump-in-the-Stack or Bump-in-the-Wire implementation), tunnel teardown decisions MAY pay attention to TCP connection status, as reported by the local TCP layer. A still-open TCP connection is almost a guarantee that more traffic is coming, while the demise of the only TCP connection through a tunnel is a strong hint that no more traffic will transit. 3.4.2 Teardown and Cleanup Teardown should always be coordinated with the other end. This means Richardson, et al. Expires September 30, 2002 [Page 20] Internet-Draft opportunistic April 2002 interpreting and sending Delete notifications. There is some detailed sub-state in the Expired Connection state of the key manager that relates to retransmits of the Delete notifications, but this is considered to be a keying system detail. On receiving a Delete for the outbound SAs of a tunnel (or some subset of them), tear down the inbound ones too, and notify the other end with a Delete. If a Delete is received for a tunnel which is no longer in existence, then two Delete messages have crossed paths. Ignore the Delete - the operation has already been done. Do not generate any messages in this situation. Tunnels need to be considered as bidirectional entities, even though the low-level protocols don't think of them that way. When the deletion is initiated locally, rather than as a response to a received Delete, send a Delete for (all) the inbound SAs of a tunnel. If no responding Delete is received for the outbound SAs, try re-sending the original Delete. Three tries spaced 10s apart seems a reasonable level of effort. A failure for the other end to respond at this point likely indicates that no further communication will be possible in any case. The outgoing SAs are removed. (Likely, it was a mobile node and it is not present or powered on anymore) After re-keying, transmission should switch to using the new outgoing SAs (ISAKMP or IPsec) immediately, and the old leftover outgoing SAs should be cleared out promptly (and Delete should be sent for the outgoing SAs) rather than waiting for them to expire. This reduces clutter and minimizes confusion for the operator doing diagnostics. Richardson, et al. Expires September 30, 2002 [Page 21] Internet-Draft opportunistic April 2002 4. Impacts on IKE 4.1 ISAKMP/IKE protocol The IKE wire protocol needs no modifications. The major changes are implementation issues relating to how the proposals are interpreted, and from whom they may come. As Opportunistic Encryption is designed to be useful between peers without prior operator configuration, an IKE daemon must be prepared to negotiate phase 1 SAs with any node. This may require a large amount of resources to maintain cookie state, as well as large amounts of entropy to for nonces, cookies, etc. The major changes to support Opportunistic Encryption are at the IKE daemon level. These changes relate to handling of key acquisition requests, lookup of public keys and TXT records, and interactions with firewalls and other security facilities that may be coresident on the same gateway. 4.2 Gateway discovery process In a typical configured tunnel situation, the address of SG-B is provided via configuration. Furthermore, the mapping of SPD entry to gateway is typically a 1:1 mapping. When the 0.0.0.0/0 SPD entry technique is used, then the mapping to a gateway is determined by the reverse DNS records. The need to do a DNS lookup and wait for a reply will typically introduce a new state and a new event source (DNS replies) to IKE. Although a synchronous DNS request can be done for proof of concept, experience is that it can cause very high latencies when a queue of queries must all timeout in series. Use of an asynchronous DNS lookup will also permit overlap of DNS lookups with some of the protocol steps. 4.3 Self identification SG-A will have to establish its identity. This is done by use of an IPv4 ID in phase 1. There are many situations where the administrator of SG-A may not be able to control the reverse DNS records for SG-A's public IP address. Typical situations include dialup connections and most residential- type broadband Internet access (ADSL, cable-modem). In these situations, a fully qualified domain name which is under the control of SG-A's administrator may be used when acting as an initiator only. Richardson, et al. Expires September 30, 2002 [Page 22] Internet-Draft opportunistic April 2002 The FQDN ID should be used in phase 1. See Section 5.3 for more details and restrictions. 4.4 Public key Retrieval process Upon receipt of a phase 1 SA proposal with either an IPv4 (IPv6) ID, or an FQDN ID, an IKE daemon will need to examine local caches and configuration files to determine if this is part of a configured tunnel. If none is found, then the implementation should attempt to retrieve a KEY record from the reverse DNS (in the case of an IPv4/ IPv6 ID), or from the forward DNS in the case of FQDN ID. It is reasonable that if other non-local sources of policy are used (COPS, LDAP, ...) that they be consulted concurrently, but that some clear ordering of policy be provided. Note that due to variances in latency, one must wait for positive or negative replies from all sources of policy before making any decisions. 4.5 Interactions with DNSSEC The present implementation does not use DNSSEC directly to explicitly verify the authenticity of zone information, or use the NXT records to provide authentication of the absence of a TXT or KEY record. Rather, the present implementation uses a trusted path to a DNSSEC capable caching resolver. To distinguish between authenticated and unauthenticated DNS Resource Record, a stub resolver capable of returning DNSSEC information MUST be used. 4.6 Recommended proposal types 4.6.1 Phase 1 parameters Main mode MUST be used. The initiator MUST offer at least one proposal using some combination of: 3DES, HMAC-MD5 or HMAC-SHA1, DH group 2 or 5. Group 5 SHOULD be proposed first. [11] The initiator MAY offer additional proposals, but the cipher MUST not be weaker than 3DES. The initiator SHOULD limit the number of proposals such that the IKE datagrams do not need to be fragmented. The responder MUST accept one of the proposals. If any configuration of the responder is required then the responder is not acting in an opportunistic way. Richardson, et al. Expires September 30, 2002 [Page 23] Internet-Draft opportunistic April 2002 SG-A SHOULD use an ID_IPV4_ADDR (ID_IPV6_ADDR for IPv6), of the external interface of SG-A for phase 1. (There is an exception, see Section 5.3) The authentication method MUST be RSA public key signatures. The RSA key for SG-A SHOULD be placed into a DNS KEY record in the reverse space of SG-A. (i.e. using in-addr.arpa.) 4.6.2 Phase 2 parameters SG-A MUST propose a tunnel between Alice and Bob, using 3DES-CBC mode, MD5 or SHA1 authentication. Perfect Forward Secrecy MUST be specified. Tunnel mode MUST be used. Authorization for SG-A to act on Alice's behalf is determined by looking for a TXT record in the reverse map at Alice's address. Compression SHOULD NOT be mandatory. It may be offered as an option. Richardson, et al. Expires September 30, 2002 [Page 24] Internet-Draft opportunistic April 2002 5. DNS issues 5.1 Use of KEY record In order to establish their own identity, SG-A and SG-B SHOULD publish their public keys in their reverse DNS. This is done via DNSSEC's KEY record. See section 3 of RFC 2535[16]. For example: KEY 0x4200 4 1 AQNJjkKlIk9...nYyUkKK8 0x4200 The flag bits, indicating that this key is prohibited for use confidentiality (it authenticates the peer only, DH is used for confidentiality), and that this key is associated with the non-zone entity whose name is the RR owner name. No other flags are set. 4 This indicates that this key is for use by IPsec 1 An RSA key is present AQNJjkKlIk9...nYyUkKK8 the public key of the host as described in [17] 5.2 Use of TXT delegation record A TXT record is published by Alice (Bob) to provide authorization for SG-A (SG-B) to act on its behalf. This record is located in the reverse DNS (in-addr.arpa) for Alice's IP address. The reverse DNS SHOULD be secured by DNSSEC, when it is deployed. DNSSEC is required to defend against active attacks. If Alice's address is P.Q.R.S, then she can authorize another node to act on her behalf by publishing records at: S.R.Q.P.in-addr.arpa The contents of the resource record are expected to be a string that follows the following syntax, as suggested in [15]. (Note that the reply to query may include other TXT resource records used by other applications) Richardson, et al. Expires September 30, 2002 [Page 25] Internet-Draft opportunistic April 2002 --------------------------------------------------------------------- X-IPsec-Server(P)=A.B.C.D KEY Figure 2: Format of reverse delegation record --------------------------------------------------------------------- P: the P specifies a precedence for this record. This is similar to MX record preferences. Lower numbers have stronger preference. A.B.C.D: specifies the IP address of the Security Gateway for this client machine. KEY: is the encoded RSA Public key of the Security Gateway. This is provided here to avoid a second DNS lookup. If this field is absent, then a KEY resource record should be looked up in the reverse map of A.B.C.D. This key is transmitted in base64 format. The pieces of the record are separated by any whitespace (space, tab, newline, carriage return). An ASCII space SHOULD be used. In the case where Alice is located at a public address behind a security gateway that has no fixed address (or no control over its reverse map), then Alice may delegate to a public key by domain name: --------------------------------------------------------------------- X-IPsec-Server(P)=@FQDN KEY Figure 3: Format of reverse delegation record (FQDN version) --------------------------------------------------------------------- P: is as above. FQDN specifies the FQDN that the Security Gateway will identify itself with. KEY: is the encoded RSA Public key of the Security Gateway. If there is more than one such TXT record with strongest (lowest numbered) precedence, one Security Gateway is picked arbitrarily from those specified in the strongest-preference records. Richardson, et al. Expires September 30, 2002 [Page 26] Internet-Draft opportunistic April 2002 5.2.1 Long TXT records When packed into transport format, TXT records which are longer than 255 characters are divided into smaller . (see [13] section 3.3 and 3.3.14). These should be reassembled into a single string for processing. Whitespace characters in the base64 encoding are to be ignored. 5.2.2 Choice of TXT record It has been suggested to use the OPT, CERT, KEY or KX records instead of a TXT record. The KEY RR has a Protocol field which could be used to indicate use for a new protocol, and an Algorithm field which could be used to indicate different contents in the key data. However, the KEY record is not clearly intended for storing what are really authorizations, it is just for identities. Other uses have been discouraged. OPT resource records, as defined in [14] are not intended to be used for storage of information. They are not to be loaded, cached or forwarded. They are therefore inappropriate for use here. CERT records [18] can encode almost any set of information. A custom Type code would be used permitting any suitable encoding to be stored, not just X.509. The certificate RR, according to the RFC, are to be signed internally, which may add undesirable and unnecessary bulk. Larger DNS records may require TCP transfers instead of UDP ones. At the time of protocol design, the CERT RR was not widely deployed and could not be counted upon. Use of CERT records will be investigated, and may result in a future revision of this document. KX records are ideally suited for this use, but had not been deployed at the time of implementation. 5.3 Use of FQDN IDs Unfortunately, not every administrator has control over the contents of the reverse-map. The only case where we can work around this is where the initiator (SG-A) has no suitable reverse map. In this case, the authorization record present in the reverse map of Alice may refer to a FQDN instead of an IP address. In this case, the client's TXT record gives the fully qualified domain name (FQDN) in place of its security gateway's IP address. The initiator should use the ID_FQDN ID-payload in phase 1. A Richardson, et al. Expires September 30, 2002 [Page 27] Internet-Draft opportunistic April 2002 forward lookup for a KEY record on the FQDN must yield the initiator's public key. This method can also be used when the external address of SG-A is dynamic. If SG-A is acting on behalf of Alice, then Alice must still delegate authority for SG-A to do so in her reverse map. When Alice and SG-A are one and the same (i.e. Alice is acting as an end-node) then there is no need for this when initiating only. Alice must still delegate to herself if she wishes others to initiate OE to her. See Figure 3 5.4 Key roll-over Good crypto hygiene says that one should replace public/private key pairs periodically. Some may wish to do this as often as daily. Typical DNS propagation delays are determined by the SOA Resource Record MINIMUM parameter, which controls how long DNS replies may be cached. For reasonable operation of DNS servers, one usually wants this value to be at least several hours, sometimes as a long as a day. This presents a problem - a new key MUST not be used prior to it propagating through DNS. This problem is dealt with by having the Security Gateway generate a new public/private key pair at least MINIMUM seconds in advance of using it. It then adds this key to the DNS (both as a second KEY record and to any TXT delegation records) at key generation time. When authenticating, all gateways MUST have available all public keys that are found in DNS for this entity. This permits the authenticating end to check both the key for "today" and the key for "tomorrow". Note that it is the end which is creating the signature (possesses the private key) that determines which key is to be used. Richardson, et al. Expires September 30, 2002 [Page 28] Internet-Draft opportunistic April 2002 6. Network Address Translation interaction There are no fundamentally new issues for getting opportunistic encryption to work in the presence of network address translation. Rather there are just the regular IPsec issues with NAT traversal. There are several situations to consider for NAT: 6.1 Co-located NAT/NAPT If SG-A is also performing Network Address Translation on behalf of Alice, then the packet should be translated prior to being subjected to opportunistic encryption. This is in contrast to typical configured tunnel which often exist to bridge islands of private network address space. SG-A will use the translated source address for phase 2, and so SG-B will look that address up to confirm SG-A's authorization. In the case of NAT (1:1), the address space into which the translation is done MUST be globally unique, and control over the reverse map is assumed to be a given. Placing of TXT records is possible. In the case of NAPT (m:1), the address will be SG-A. The ability to get KEY and TXT records in place will again depend upon whether or not there is administrative control over the reverse map. This is identical to situations involving a single host acting on behalf of itself. FQDN style can be used to get around a lack of a reverse map for initiators only. 6.2 SG-A behind NAT/NAPT If there is a NAT or NAPT between SG-A and SG-B, then normal IPsec NAT traversal rules would apply. In addition to the transport problem which may be solved by other mechanisms, there is the issue of what phase 1 and phase 2 IDs to use. While FQDN could be used during phase 1 for SG-A, there is no appropriate ID for phase 2 that permits SG-B to determine that SG-A was in fact authorized to speak for Alice. 6.3 Bob is behind a NAT/NAPT If Bob is behind a NAT (perhaps SG-B), then there is in fact no way for Alice to address a packet to Bob. Not only is opportunistic encryption impossible, but it is also impossible for Alice to initiate any communication to Bob. It may be possible for Bob to initiate in such a situation - this creates an asymmetry, but this is common for NAPT. Richardson, et al. Expires September 30, 2002 [Page 29] Internet-Draft opportunistic April 2002 7. Host implementations When Alice and SG-A are components of the same system, then this is considered to be a host implementation. The scenario remains unchanged with respect to packet sequence. Components marked Alice are simply the upper layers (TCP, UDP, the application), and SG-A is the IP layer. Note that tunnel mode is still recommended. As Alice/SG-A are acting on behalf of themselves, no TXT based delegation record is necessary for Alice to initiate. She can rely on a FQDN in a forward map. This is particularly attractive to mobile nodes such as notebook computers at conferences. To respond, Alice/SG-A will still need an entry in her reverse map. Richardson, et al. Expires September 30, 2002 [Page 30] Internet-Draft opportunistic April 2002 8. Multihoming If there are multiple paths between Alice and Bob (such as illustrated in the diagram with SG-D) then additional DNS records are required to establish authorization. In the diagram in Figure 1, Alice has two ways to exit her network: SG-A and SG-D. Previously SG-D has been ignored. Postulate that there are routers between Alice and her set of security gateways (denoted by the + signs and the marking of an autonomous system number for Alice's network). Datagrams may therefore travel to either SG-A or SG-D en route to Bob. As long as all network connections are in good order it does not matter how datagrams exit Alice's network. When they reach either security gateway, the security gateway will find the TXT delegation record in Bob's reverse map, and establish an SA with SG-B. SG-B has no problem establishing that either of SG-A or SG-D may speak for Alice, as Alice has published two equally weighted TXT delegation records: --------------------------------------------------------------------- X-IPsec-Server(10)=192.1.1.5 AQMM...3s1Q== X-IPsec-Server(10)=192.1.1.6 AAJN...j8r9== Figure 4: Multiple gateway delegation example --------------------------------------------------------------------- Alice's routers can now happily do any kind of load sharing that they might wish to do. SG-A and SG-D will both send datagrams addressed to Bob through their tunnel to SG-B. Even if Alice wishes to prefer one gateway over another via use of non-equal weight delegation records, this has relevance only when SG- B is initiating to Alice. If the precedences are the same, then SG-B has a more difficult time. It must decide which of the two tunnels to use. SG-B has no information about which link is less loaded, nor which security gateway has more cryptographic resources available. SG-B in fact has no knowledge of whether both gateways are even reachable. The Public Internet's default free zone may well know a good route to Alice, but the datagrams that SG-B creates must be addressed to Richardson, et al. Expires September 30, 2002 [Page 31] Internet-Draft opportunistic April 2002 either SG-A or SG-D; they can not be addressed to Alice directly. There are a number of choices which SG-B may make: 1. It can ignore the problem and round robin among the tunnels it has. This will cause losses during times when one or the other security gateway is unreachable. If this worries Alice, she can change the weights in her TXT delegation records. 2. It can always send to the gateway that it most recently received from. This assumes that routing and reachability is symmetrical. 3. It can listen to BGP information from the Internet to decide which system is currently up. This is clearly a much more complicated thing to do, but if SG-B is already doing this because it is participating in the BGP peering system to announce Bob, the results data may already be available to it. 4. It can refuse to negotiate the second tunnel. (It is unclear whether or not this is even an option) 5. It can silently replace the outgoing portion of the first tunnel with the second one, while still retaining the incoming portions of both. SG-B can thus be willing willing to accept datagrams from either SG-A or SG-D, but sending only to the gateway that most recently re-keyed with it. These are decisions left to local policy. Note that even if SG-B has perfect knowledge about reachability of SG-A and SG-D, Alice may not be reachable from one or other of these security gateways due to internal reachability issues. FreeS/WAN implements option 5. Consideration to implementing a different in being given. The multi-homing aspects of OE are not well developed and may be a subject of a future document. Richardson, et al. Expires September 30, 2002 [Page 32] Internet-Draft opportunistic April 2002 9. Failure modes 9.1 DNS failures If a DNS server fails to respond, then it is a local policy decision whether or not to permit communication in the clear. This is embodied in the connection classes in Section 3.2. It should be clear that mounting a denial of service attack on the DNS server responsible for a particular network's reverse map is an easy thing to do. Such an attack may cause all communication with that network to go in the clear for a permissive policy, and for communication to fail completely if this is a paranoid policy. Please note that this is an active attack. At the same time, there are still a very large number of networks that do not have properly configured reverse maps. Further, the effect of the above denial of service attack, if the policy is not to communicate, is that the target network becomes isolated. This is why this decision MUST be a matter of local policy. 9.2 DNS configured, IKE failures In this situation, DNS records claim that opportunistic encryption should occur, but the target gateway either does not respond on port 500, or refuses the proposal. This may be due to a crash/reboot, due to misconfiguration, or a firewall filtering port 500. The receipt of ICMP port, host or network unreachable messages should be taken as a sign that there is a potential problem, but MUST NOT cause communication to fail immediately. ICMP messages are easily forged by attackers. If such a forgery caused immediate failure, then an attacker could easily prevent any encryption from ever occurring, possibly preventing all communication. It is recommended that in these situations that a clear log be produced about the problem. A local policy should dictate if communication is then permitted in the clear at this point. 9.3 System reboots Tunnels sometimes go down because the other end crashes, or disconnects, or has a network link break, and there is no notice of this in the general case. (Even in the event of a crash and successful reboot, other SGs don't hear about it unless the rebooted SG has specific reason to talk to them immediately.) Over-quick response to temporary network out- ages is undesirable... but note that a tunnel can be torn down and then re-established without any user-visible effect except a pause in traffic, whereas if one end Richardson, et al. Expires September 30, 2002 [Page 33] Internet-Draft opportunistic April 2002 does reboot, the other end can't get datagrams to it at all (except via IKE) until the situation is noticed. So a bias toward quick response is appropriate, even at the cost of occasional false alarms. A mechanism for recover after reboot is not specified in this document as it is a topic of current research. A deliberate shutdown should include an attempt to notify all other SGs currently connected by phase 1 SAs, using Deletes, that communication is about to fail. (Again, these will be taken as teardowns; attempts by the other SGs to negotiate new tunnels as replacements should be ignored at this point.) And when possible, SGs should attempt to preserve information about currently- connected SGs in non-volatile storage, so that after a crash, an Initial-Contact can be sent to previous partners to indicate loss of all previously established connections. Richardson, et al. Expires September 30, 2002 [Page 34] Internet-Draft opportunistic April 2002 10. Unresolved issues 10.1 Control of reverse DNS The method of obtaining information by reverse DNS lookup causes problems for people who can not control their reverse DNS bindings. This is an unresolved problem in this version, and is out of scope. Richardson, et al. Expires September 30, 2002 [Page 35] Internet-Draft opportunistic April 2002 11. Examples 11.1 Clear-text usage (permit policy) What follows are two example scenarios. The first is where GW-A (Gateway A) and GW-B (Gateway B) have always-cleartext policies, and the second where they have some OE policy. --------------------------------------------------------------------- Alice SG-A DNS SG-B Bob (1) ------(2)--------------> <-----(3)--------------- (4)----(5)-----> ----------(6)------> ------(7)-----> <------(8)------ <----------(9)------ <----(10)----- (11)-----------> ----------(12)-----> --------------> <--------------- <------------------- <------------- Figure 5: Timing of regular transaction --------------------------------------------------------------------- Alice wants to communicate with Bob. Perhaps she wishes to retrieve a web page from Bob's web server. In the absence of opportunistic encryptors, the following events occur: (1) Human or application 'clicks' with a name (2) Application looks up name in DNS to get IP address (3) Resolver returns A record to application (4) Application starts a TCP session or UDP session, OS sends packet (5) Packet is seen at first gateway from Alice (SG-A) (SG-A transitions through Empty connection to always-clear connection and instantiates a pass-through policy at the forwarding plane) Richardson, et al. Expires September 30, 2002 [Page 36] Internet-Draft opportunistic April 2002 (6) Packet is seen at last gateway before Bob (SG-B) (7) First packet from Alice is seen by Bob (8) First return packet is sent by Bob (9) Packet is seen at Bob's gateway (SG-B transitions through an Empty connection to always-clear connection and instantiates a pass-through policy at the forwarding plane) (10) Packet is seen at Alice's gateway (11) OS hands packet to application, Alice sends another packet (12) a second packet traverses the Internet 11.2 Opportunistic Encryption In the presence of properly configured opportunistic encryptors, the event list is extended. --------------------------------------------------------------------- Alice SG-A DNS SG-B Bob (1) ------(2)--------------> <-----(3)--------------- (4)----(5)----->+ ----(5B)-> <---(5C)-- ~~~~~~~~~~~~~(5D)~~~> <~~~~~~~~~~~~(5E1)~~~ ~~~~~~~~~~~~~(5E2)~~> <~~~~~~~~~~~~(5E3)~~~ #############(5E4)##> <############(5E5)### <----(5F1)-- -----(5F2)-> #############(5G1)##> <----(5H1)-- -----(5H2)-> <############(5G2)### #############(5G3)##> ============(6)====> ------(7)-----> <------(8)------ Richardson, et al. Expires September 30, 2002 [Page 37] Internet-Draft opportunistic April 2002 <==========(9)====== <-----(10)---- (11)-----------> ==========(12)=====> --------------> <--------------- <=================== <------------- Figure 6: Timing of Opportunistic Encryption transaction --------------------------------------------------------------------- (1) Human or application clicks with a name (2) Application initiates DNS mapping. (3) resolver returns A record to application (4) Application starts a TCP session or UDP (5) SG (host or SG) sees packet to target, buffers it. (5B) SG asks DNS for TXT record (5C) DNS returns TXT record(s) (5D) Initial IKE Main Mode Packet goes out (5E) IKE ISAKMP phase 1 succeeds (5F) SG-B asks DNS for TXT record to prove SG-A agent for Alice (5G) IKE phase 2 negotiation (5H) DNS lookup by responder (SG-B) (6) buffered packet is sent by SG-A (7) packet is received by SG-B, and decrypted, sent to Bob (8) Bob replies, packet is seen by SG-B (9) SG-B already has tunnel up with SG-A, uses it (10) SG-A decrypts packet and give it to Alice (11) Alice receives packet. Sends new packet to Bob Richardson, et al. Expires September 30, 2002 [Page 38] Internet-Draft opportunistic April 2002 (12) SG-A gets second packet, sees that tunnel is up, uses it For the purposes of this section, we will describe only the changes that occur between Figure 5 and Figure 6. This means time points 5, 6, 7, 9 and 10. 11.2.1 (5) IPsec packet interception At point (5), SG-A intercepts the packet due to the lack of a policy (the non-existent policy!) for this source/destination pair. A hold policy is created, and the packet is buffered. A request is sent to the keying daemon for keys. 11.2.2 (5B) DNS lookup for TXT record SG-A's IKE daemon, having looked up the source/destination in the connection class list, creates a new Potential OE connection instance. The DNS queries are started. 11.2.3 (5C) DNS returns TXT record(s) DNS returns properly formed TXT delegation records, and SG-A's IKE daemon transitions this instance from Potential OE connection to Pending OE connection. For the example above, the returned record might contain: --------------------------------------------------------------------- X-IPsec-Server(10)=192.1.1.5 AQMM...3s1Q== Figure 7: Example of reverse delegation record --------------------------------------------------------------------- with SG-B's IP address and public key listed. 11.2.4 (5D) Initial IKE Main Mode Packet goes out Upon entering Pending OE connection, SG-A sends the initial ISAKMP message, with proposals, see Section 4.6.1. 11.2.5 (5E1) Message 2 of phase 1 exchange SG-B receives the message. A new connection instance is created in the Unauthenticated OE Peer state. Richardson, et al. Expires September 30, 2002 [Page 39] Internet-Draft opportunistic April 2002 11.2.6 (5E2) Message 3 of phase 1 exchange SG-A sends a Diffie-Hellman exponent. This is an internal state of the keying daemon. 11.2.7 (5E3) Message 4 of phase 1 exchange SG-B responds with a Diffie-Hellman exponent. This is an internal state of the keying protocol. 11.2.8 (5E4) Message 5 of phase 1 exchange SG-A uses the phase 1 SA to send its identity under encryption. The choice of identity is discussed in Section 4.6.1. This is an internal state of the keying protocol. 11.2.9 (5F1) Responder lookup of initiator key SG-B asks DNS for the public key of the initiator. This is done by asking for a KEY record by IP address in the reverse map. That is, a KEY resource record is queried for 4.1.1.192.in-addr.arpa (recall that SG-A's external address is 192.1.1.4) The resulting public key is used to authenticate the initiator. See Section 5.1 for further details. 11.2.10 (5F2) DNS replies with public key of initiator Upon successfully authenticating the peer, the connection instance is transitioned to Authenticated OE peer on SG-B. The format of the TXT record that is returned is described in Section 5.2. 11.2.11 (5E5) Responder replies with ID and authentication SG-B sends its ID along with authentication material. This is an internal state for the keying protocol. 11.2.12 (5G) IKE phase 2 11.2.12.1 (5G1) Initiator proposes tunnel Having established mutually agreeable authentications (via KEY) and authorizations (via TXT), SG-A proposes to create an IPsec tunnel for datagrams transiting from Alice to Bob. This tunnel is established for only the Alice/Bob combination, not for any subnets that may be behind SG-A and SG-B. Richardson, et al. Expires September 30, 2002 [Page 40] Internet-Draft opportunistic April 2002 11.2.12.2 (5H1) Responder determines initiator's authority While the identity of SG-A has been established, its authority to speak for Alice has not yet been confirmed. This is done by doing a reverse lookup on Alice's address for a TXT record. Upon receiving this specific proposal, SG-B transitions its instance into the Potential OE connection state. SG-B may already have an instance, and the check is made as described above. 11.2.12.3 (5H2) DNS replies with TXT record(s) The returned key and IP address should match that of SG-A. 11.2.12.4 (5G2) Responder agrees to proposal Should additional communication occur between, for instance, Dave and Bob via SG-A and SG-B, a new tunnel (phase 2 SA) would be established. The phase 1 SA may be reusable. SG-A, having successfully keyed the tunnel, now transitions from Pending OE connection to Keyed OE connection. The responder MUST setup the inbound IPsec SAs before sending its reply. 11.2.12.5 (5G3) Final acknowledgment from initiator The initiator agrees with the responder's choice and sets up the tunnel. The initiator sets up the inbound and outbound IPsec SAs. The proper authorization returned with keys prompts SG-B to transition its instance to the Keyed OE connection. Upon receipt of this message, the responder may now setup the outbound IPsec SAs 11.2.13 (6) IPsec succeeds, sets up tunnel for communication between Alice and Bob The packet which was saved at step (5) is sent through the newly created tunnel to SG-B, where it gets decrypted and forwarded. Bob receives it at (7) and replies at (8). 11.2.14 (9) SG-B already has tunnel up with G1, uses it At (9), SG-B has already established an SPD entry mapping Bob->Alice via a tunnel, so this tunnel is simply applied. The packet is Richardson, et al. Expires September 30, 2002 [Page 41] Internet-Draft opportunistic April 2002 encrypted to SG-A, decrypted by SG-A and passed to Alice at (10). Richardson, et al. Expires September 30, 2002 [Page 42] Internet-Draft opportunistic April 2002 12. Security Considerations 12.1 Configured vs Opportunistic Tunnels Configured tunnels are those which are setup using bilateral mechanisms: exchanging public keys (raw RSA, DSA, PKIX), pre-shared secrets, or by referencing keys that are in known places (distinguished name from LDAP, DNS). These keys are then used to configure a specific tunnel. A pre-configured tunnel may be on all the time, or may be keyed only when needed. The end points of the tunnel are not necessarily static: many mobile applications ("road warrior") are considered to be configured tunnels. The primary consideration is that configured tunnels are assigned specific security properties. They may be trusted in different ways. This is usually related to exceptions to firewall rules, exceptions to NAT processing, and to bandwidth or other quality of service restrictions. Opportunistic tunnels are not inherently trusted in any strong way. They are created without prior arrangement. As the two parties are strangers, there MUST be no confusion of datagrams that arrive from opportunistic peers and those that arrive from configured tunnels. A security gateway MUST take care that an opportunistic peer can not impersonate a configured peer. Ingress filtering MUST be used to make sure that only packets authorized by negotiation (and the concomitant authentication and authorization) are accepted from a tunnel. This is to prevent one peer from impersonating another. An implementation suggestion is to logically treat opportunistically tunnel datagrams as if they arrive on a distinct logical interface from other configured tunnels. As the number of opportunistic tunnels that may be created automatically on a system is potentially very high, careful attention to scaling should be taken into account. As with any IKE negotiation, opportunistic encryption cannot be secure without authentication. Opportunistic encryption relies on DNS for its authentication information and therefore cannot be fully secure without a secure DNS. Without secure DNS, it can protect against passive eavesdropping, but not against active man-in-the- middle attacks. Richardson, et al. Expires September 30, 2002 [Page 43] Internet-Draft opportunistic April 2002 12.2 Firewalls vs Opportunistic Tunnels Typical usage of per-packet access control lists is to implement various kinds of security gateways. These are typically called "firewalls". Typical usage of virtual private network (VPN) within a firewall is to bypass all or part of the access controls between two networks. Additional trust (as outlined in the previous section) is given to datagrams that arrive in the VPN. Datagrams that arrive via opportunistically configured tunnels MUST not be trusted. Any security policy that would apply to a packet arriving in the clear SHOULD also be applied to datagrams arriving opportunistically. 12.3 Denial of Service There are several different forms of denial of service which an implementor should concern themselves with. Most of these problems are shared with security gateways that have large numbers of mobile peers (road warriors). The design of ISAKMP/IKE, and its use of cookies, defend against many kinds of denial of service. There is an assumption that if the phase 1 (ISAKMP) SA is authenticated, that it was worthwhile creating. Opportunism changes this assumption. As the gateway will communicate with anyone, it is possible to form phase 1 SAs with any machine on the Internet. Richardson, et al. Expires September 30, 2002 [Page 44] Internet-Draft opportunistic April 2002 13. IANA Considerations There are no known numbers which IANA will need to manage. Richardson, et al. Expires September 30, 2002 [Page 45] Internet-Draft opportunistic April 2002 14. Acknowledgments Thanks to Tero Kivinen, Sandy Harris, Wes Hardarker, Robert Moskowitz, Jakob Schlyter, Bill Sommerfeld, John Gilmore and John Denker for their comments and constructive criticism. Richardson, et al. Expires September 30, 2002 [Page 46] Internet-Draft opportunistic April 2002 Normative references [1] Redelmeier, D. and H. Spencer, "Opportunistic Encryption", paper http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/ opportunism.spec, May 2001. [2] Defense Advanced Research Projects Agency (DARPA), Information Processing Techniques Office and , "Internet Protocol", STD 5, RFC 791, September 1981. [3] Braden, R. and J. Postel, "Requirements for Internet gateways", RFC 1009, June 1987. [4] IAB, IESG, Carpenter, B. and F. Baker, "IAB and IESG Statement on Cryptographic Technology and the Internet", RFC 1984, August 1996. [5] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [6] McDonald, D., Metz, C. and B. Phan, "PF_KEY Key Management API, Version 2", RFC 2367, July 1998. [7] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [8] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. [9] Maughan, D., Schneider, M. and M. Schertler, "Internet Security Association and Key Management Protocol (ISAKMP)", RFC 2408, November 1998. [10] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [11] Kivinen, T. and M. Kojo, "More MODP Diffie-Hellman groups for IKE", ID internet-draft (draft-ietf-ipsec-ike-modp-groups-03) (normative), November 2001. [12] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [13] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [14] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. Richardson, et al. Expires September 30, 2002 [Page 47] Internet-Draft opportunistic April 2002 [15] Rosenbaum, R., "Using the Domain Name System To Store Arbitrary String Attributes", RFC 1464, May 1993. [16] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [17] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)", RFC 3110, May 2001. [18] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the Domain Name System (DNS)", RFC 2538, March 1999. [19] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A. Sastry, "The COPS (Common Open Policy Service) Protocol", RFC 2748, January 2000. [20] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. Authors' Addresses Michael C. Richardson Sandelman Software Works 470 Dawson Avenue Ottawa, ON K1Z 5V7 CA EMail: mcr@sandelman.ottawa.on.ca URI: http://www.sandelman.ottawa.on.ca/ D. Hugh Redelmeier Mimosa Toronto, ON CA EMail: hugh@mimosa.com Henry Spencer SP Systems Box 280 Station A Toronto, ON M5W 1B2 Canada EMail: henry@spsystems.net Richardson, et al. Expires September 30, 2002 [Page 48] Internet-Draft opportunistic April 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Richardson, et al. Expires September 30, 2002 [Page 49]