Network Working Group M. Richardson 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).
AbstractThis 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. 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
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.
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. RFC2119]
[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"). 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 18.104.22.168. Bob: node [B] in the diagram. When an IP address is needed, this is 22.214.171.124. Carol: node [C] in the diagram. When an IP address is needed, this is 126.96.36.199. Dave: node [D] in the diagram. When an IP address is needed, this is 188.8.131.52.
SG-A: Alice's security gateway. Internally it is 184.108.40.206, externally it is 220.127.116.11. SG-B: Bob's security gateway. Internally it is 18.104.22.168, externally it is 22.214.171.124. SG-D: Dave's security gateway. Also Alice's backup security gateway. Internally it is 126.96.36.199, externally it is 188.8.131.52. 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. 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. 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. RFC4033]). Section 184.108.40.206 documents an optional restriction on the tunnel endpoint if DNSSEC signatures are not available for the relevant records.
Section 3.4. This removes entries that are no longer being used and permits the discovery of changes in authorization policy. 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. 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 |--' `-------------'
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.
specific keying protocol, but this document does provide requirements for those using ISAKMP/IKE to assure that implementations inter- operate. 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 description of the state machine. | | PF_ACQUIRE | V .---------------. | nonexistent | | connection | `---------------' | | | send , | \ expired pass / | \ send conn. msg / | \ deny ^ / | \ msg | V | do \ .---------------. | DNS \ .---------------. | clear-text | | lookup `->| deny |--->expired | connection | | for | connection | connection `---------------' | destination `---------------' ^ ^ | ^ | | no record | | | | OE-permissive V | no record | | .---------------. | OE-paranoid | `------------| potential OE |---------' | | connection | ^ | `---------------' | | | | | | got TXT record | DNSSEC failure | | reply | | V | wrong | .---------------. | failure | | authenticate |---------' | | & parse TXT RR| ^ | repeated `---------------' | | ICMP | | | failures | initiate IKE to | | (short timeout) | responder |
| V | | phase-2 .---------------. | failure | failure | pending |---------' | (normal | OE | ^ | timeout) | |invalid | phase-2 fail (normal | | |<--.SPI | timeout) | | | | | ICMP failures (short | | +=======+ |---' | timeout) | | | IKE | | ^ | `----------------| states|---------------' | +=======+ | | `---------------' | | IPsec SA | invalid SPI | established | V | rekey time .--------------. | | keyed |<---|------------------------------. | connection |----' | `--------------' | | timer | | | V | .--------------. connection still active | clear-text----->| expired |-----------------------------------' deny----->| connection | `--------------' | dead connection - deleted V
Section 3.2.7). Section 3.2.7). Section 5.2). The lookup key is the destination address of the flow. There are three ways to exit this state: 1. DNS lookup finds a TXT delegation resource record. 2. DNS lookup does not find a TXT delegation resource record. 3. DNS lookup times out. Based upon the results of the DNS lookup, the potential OE connection makes a transition to the pending OE connection state. The conditions for a successful DNS look are: 1. DNS finds an appropriate resource record. 2. It is properly formatted according to Section 5.2. 3. If DNSSEC is enabled, then the signature has been vouched for.
Note that if the initiator does not find the public key present in the TXT delegation record, then the public key must be looked up as a sub-state. Only successful completion of all the DNS lookups is considered a success. If DNS lookup does not find a resource record or if DNS times out, then the initiator considers the receiver not OE capable. If this is an OE-paranoid instance, then the potential OE connection makes a transition to the deny connection state. If this is an OE-permissive instance, then the potential OE connection makes a transition to the clear-text connection state. If the initiator finds a resource record, but it is not properly formatted, or if DNSSEC is enabled and reports a failure to authenticate, then the potential OE connection makes a transition to the deny connection state. This action SHOULD be logged. If the administrator wishes to override this transition between states, then an always-clear class can be installed for this flow. An implementation MAY make this situation a new class.
Note that if there are multiple gateways available in the TXT delegation records, then a failure can only be declared after all of them 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 occurs when an ICMP port unreachable is consistently received without any other communication, or when there is silence from the remote end. This usually means that either the gateway is not alive, or the keying daemon is not functional. For an OE-permissive connection, the initiator makes a transition to the clear-text connection, but with a low lifespan. For an OE- pessimistic connection, the initiator makes a transition to the deny connection again with a low lifespan. The lifespan in both cases is kept low because the remote gateway may be in the process of rebooting or be otherwise temporarily unavailable. The length of time to wait for the remote keying daemon to wake up is a matter of some debate. If there is a routing failure, 5 minutes is usually long enough for the network to re-converge. Many systems can reboot in that amount of time as well. However, 5 minutes is far too long for most users to wait to hear that they can not connect using OE. Implementations SHOULD make this a tunable parameter. The second failure occurs after a phase 1 SA has been created, but there is either no response to the phase 2 proposal, or the initiator receives a negative notify (the notify must be authenticated). The remote gateway is not prepared to do OE at this time. As before, the initiator makes a transition to the clear-text or the deny connection based upon connection class, but this time with a normal lifespan. The third failure occurs when there is signature failure while authenticating the remote gateway. This can occur when there has been a key roll-over, but DNS has not caught up. In this case again, the initiator makes a transition to the clear-text or the deny connection based upon the connection class. However, the lifespan depends upon the remaining time to live in the DNS. (Note that DNSSEC signed resource records have a different expiry time from non-signed records.)
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 the expired connection state. The second exit is by expiry of the forwarding plane keying material. This starts a re-key operation with a transition back to pending OE connection. In general, the soft expiry occurs with sufficient time left to continue using the keys. A re-key can fail, which may result in the connection failing to clear-text or deny as appropriate. In the event of a failure, the forwarding plane policy does not change until the phase 2 SA (IPsec SA) reaches its hard expiry. The third exit is in response to a negotiation from a remote gateway. If the forwarding plane signals the control plane that it has received an unknown SPI from the remote gateway, or an ICMP is received from the remote gateway indicating an unknown SPI, the initiator should consider that the remote gateway has rebooted or restarted. Since these indications are easily forged, the implementation must exercise care. The initiator should make a cautious (rate-limited) attempt to re-key the connection. Section 3.4 for more details of how often this occurs. The initiator queries the forwarding plane for last use time of the appropriate policy. If the last use time is relatively recent, then the connection returns to the previous deny, clear-text or keyed connection state. If not, then the connection enters the expired connection state. The DNS query and answer that lead to the expiring connection state are also examined. The DNS query may 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 [RFC1034] section 4.3.4.) If the DNS query is stale, then a new query is made. If the results change, then the connection makes a transition to a new state as described in potential OE connection state. Note that when considering how stale a connection is, both outgoing SPD and incoming SAD must be queried as some flows may be unidirectional for some time. Also note that the policy at the forwarding plane is not updated unless there is a conclusion that there should be a change.
Section 3.4. Whether or not to delete the phase 1 SAs at this time 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 an advantage to keeping the phase 1 SAs until they expire: they may prove useful again in the near future.
RFC2407] section 220.127.116.11.) The responder exits this state upon successful receipt of a KEY from DNS, and use of the key to verify the signature of the initiator. Successful authentication of the peer results in a transition to the authenticated OE Peer state. Note that the unauthenticated OE peer state generally occurs in the middle of the key negotiation protocol. It is really a form of pseudo-state.
Section 3.2.4. Section 3.2.7) implements these timeouts. The timer above may be in the forwarding plane, but then it must 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.) Unlike re- keying, this tunnel use check is not costly and should happen reasonably frequently. A multi-step back-off algorithm is not considered worth the effort here. If the security gateway and the client host are 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 expected. Closing of the only TCP connection through a tunnel is a strong hint that no more traffic is expected.
outgoing SAs) rather than waiting for them to expire. This reduces clutter and minimizes confusion for the operator doing diagnostics.
type broadband Internet access (ADSL, cable-modem) connections. In these situations, a fully qualified domain name that is under the control of SG-A's administrator may be used when acting as an initiator only. The FQDN ID should be used in phase 1. See Section 5.3 for more details and restrictions. RFC3526]) 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. The initiator SHOULD use an ID_IPV4_ADDR (ID_IPV6_ADDR for IPv6) of the external interface of the initiator for phase 1. (There is an exception, see Section 5.3.) The authentication method MUST be RSA public key signatures. The RSA key for the initiator SHOULD be placed into a DNS KEY record in the reverse space of the initiator (i.e., using in-addr.arpa or ip6.arpa). section 3 of RFC 2535 [RFC2535]. For example: KEY 0x4200 4 1 AQNJjkKlIk9...nYyUkKK8 0x4200: The flag bits, indicating that this key is prohibited for confidentiality use (it authenticates the peer only, a separate Diffie-Hellman exchange 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 [RFC3110]. Use of several KEY records allows for key roll-over. The SIG Payload in IKE phase 1 SHOULD be accepted if the public key, given by any KEY RR, validates it. RFC1464]. (Note that the reply to query may include other TXT resource records used by other applications.) X-IPsec-Server(P)=A.B.C.D public-key Figure 2: Format of reverse delegation record 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. public-key: Is the encoded RSA Public key of the Security Gateway. The public-key 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. The key is transmitted in base64 format. The fields of the record MUST be separated by whitespace. This MAY be: space, tab, newline, or carriage return. A space is preferred.
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 public-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. public-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. RFC1035] section 3.3 and 3.3.14.) These MUST be reassembled into a single string for processing. Whitespace characters in the base64 encoding are to be ignored. RFC2671], 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 [RFC2538] can encode almost any set of information. A custom type code could be used permitting any suitable encoding to be stored, not just X.509. According to the RFC, the certificate RRs are to be signed internally, which may add undesirable and unnecessary bulk. Larger DNS records may require TCP instead of UDP transfers.
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 be proposed in a future revision of this document. KX records are ideally suited for use instead of TXT records, but had not been deployed at the time of implementation. Figure 3.
record and in additional TXT delegation records) at key generation time. Note: only one key is allowed in each TXT record. 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.
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, because Alice has published two equally weighted TXT delegation records:
X-IPsec-Server(10)=18.104.22.168 AQMM...3s1Q== X-IPsec-Server(10)=22.214.171.124 AAJN...j8r9== Figure 4: Multiple gateway delegation example for Alice Alice's routers can now do any kind of load sharing needed. Both SG-A and SG-D send datagrams addressed to Bob through their tunnel to SG-B. Alice's use of non-equal weight delegation records to show preference of one gateway over another, 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 either SG-A or SG-D; they can not be addressed to Alice directly. SG-B may make a number of choices: 1. It can ignore the problem and round robin among the tunnels. This causes 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 send to the gateway from which it most recently received datagrams. This assumes that routing and reachability are symmetrical. 3. It can listen to BGP information from the Internet to decide which system is currently up. This is clearly much more complicated, but if SG-B is already 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. Thus, SG-B can accept datagrams from either SG-A or SG-D, but send only to the gateway that most recently re-keyed with it.
Local policy determines which choice SG-B makes. Note that even if SG-B has perfect knowledge about the reachability of SG-A and SG-D, Alice may not be reachable from either of these security gateways because of internal reachability issues. FreeS/WAN implements option 5. Implementing a different option is being considered. The multi-homing aspects of OE are not well developed and may be the subject of a future document. Section 3.2. It is easy to mount a denial of service attack on the DNS server responsible for a particular network's reverse-map. Such an attack may cause all communication with that network to go in the clear if the policy is permissive, or fail completely if the policy is paranoid. Please note that this is an active attack. There are still many networks that do not have properly configured reverse-maps. Further, if the policy is not to communicate, the above denial of service attack isolates the target network. Therefore, the decision of whether or not to permit communication in the clear MUST be a matter of local policy.
Alice SG-A DNS SG-B Bob Human or application 'clicks' with a name. (1) ------(2)--------------> Application looks up name in DNS to get IP address. <-----(3)--------------- Resolver returns "A" RR to application with IP address. (4) Application starts a TCP session or UDP session and OS sends first datagram Alice SG-A DNS SG-B Bob ----(5)-----> Datagram is seen at first gateway from Alice (SG-A). ----------(6)------> Datagram traverses network. ------(7)-----> Datagram arrives at Bob, is provided to TCP. <------(8)------ A reply is sent. <----------(9)------ Datagram traverses network. <----(10)----- Alice receives answer. Alice SG-A DNS SG-B Bob (11)-----------> A second exchange occurs.
----------(12)-----> --------------> <--------------- <------------------- <------------- Figure 5: Timing of regular transaction
Alice SG-A DNS SG-B Bob (1) ------(2)--------------> <-----(3)--------------- (4)----(5)----->+ ----(5B)-> <---(5C)-- ~~~~~~~~~~~~~(5D)~~~> <~~~~~~~~~~~~(5E)~~~~ ~~~~~~~~~~~~~(5F)~~~> <~~~~~~~~~~~~(5G)~~~~ #############(5H)###> <----(5I)--- -----(5J)--> <############(5K)#### #############(5L)###> <----(5M)--- -----(5N)--> <############(5O)#### #############(5P)###> ============(6)====> ------(7)-----> <------(8)------ <==========(9)====== <-----(10)---- (11)-----------> ==========(12)=====> --------------> <--------------- <=================== <------------- Figure 6: Timing of opportunistic encryption transaction
For the purposes of this section, we will describe only the changes that occur between Figure 5 and Figure 6. This corresponds to time points 5, 6, 7, 9, and 10 on the list above. At point (5), SG-A intercepts the datagram because this source/destination pair lacks a policy (the nonexistent policy state). SG-A creates a hold policy, and buffers the datagram. SG-A requests keys from the keying daemon. (5B) DNS query for TXT record. (5C) DNS response for TXT record. (5D) Initial IKE message to responder. (5E) Message 2 of phase 1 exchange. SG-B receives the message. A new connection instance is created in the unauthenticated OE peer state. (5F) Message 3 of phase 1 exchange. SG-A sends a Diffie-Hellman exponent. This is an internal state of the keying daemon. (5G) Message 4 of phase 1 exchange. SG-B responds with a Diffie-Hellman exponent. This is an internal state of the keying protocol. (5H) 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. (5I) Responder lookup of initiator key. SG-B asks DNS for the public key of the initiator. DNS looks for a KEY record by IP address in the reverse-map. That is, a KEY resource record is queried for 126.96.36.199.in-addr.arpa (recall that SG-A's external address is 188.8.131.52). SG-B uses the resulting public key to authenticate the initiator. See Section 5.1 for further details. (5J) DNS replies with public key of initiator. Upon successfully authenticating the peer, the connection instance makes a transition to authenticated OE peer on SG-B. The format of the TXT record returned is described in Section 5.2. Responder replies with ID and authentication. SG-B sends its ID along with authentication material, completing the phase 1 negotiation. (5L) IKE phase 2 negotiation. 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 only for the Alice/Bob combination, not for any subnets that may be behind SG-A and SG-B.
(5M) Authorization for SG-A to speak for Alice. While the identity of SG-A has been established, its authority to speak for Alice has not yet been confirmed. SG-B does a reverse lookup on Alice's address for a TXT record. (5N) Responder determines initiator's authority. A TXT record is returned. It confirms that SG-A is authorized to speak for Alice. Upon receiving this specific proposal, SG-B's connection instance makes a transition into the potential OE connection state. SG-B may already have an instance, and the check is made as described above. (5O) Responder agrees to proposal. SG-B, satisfied that SG-A is authorized, proceeds with the phase 2 exchange. The responder MUST setup the inbound IPsec SAs before sending its reply. (5P) Final acknowledgement from initiator. The initiator agrees with the responder's choice of proposal and sets up the tunnel. The initiator sets up the inbound and outbound IPsec SAs. Upon receipt of this message, the responder may now setup the outbound IPsec SAs. (6) IPsec succeeds and sets up a tunnel for communication between Alice and Bob. SG-A sends the datagram saved at step (5) through the newly created tunnel to SG-B, where it gets decrypted and forwarded. Bob receives it at (7) and replies at (8). SG-B already has a tunnel up with G1 and 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 datagram is encrypted to SG-A, decrypted by SG-A, and passed to Alice at (10).
The primary characteristic is that configured tunnels are assigned specific security properties. They may be trusted in different ways relating 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 cannot impersonate a configured peer. Ingress filtering MUST be used to make sure that only datagrams 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 treat opportunistic tunnel datagrams as if they arrive on a logical interface distinct 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, opportunistic encryption can protect against passive eavesdropping but not against active man-in-the-middle attacks.
OEspec] 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. Sandra Hoffman and Bill Dickie did the detailed proof reading and editing. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2407] Piper, D., "The Internet IP Security Domain of Interpretation for ISAKMP", RFC 2407, November 1998. [RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet Security Association and key Management Protocol (ISAKMP)", RFC 2408, November 1998. [RFC2409] Harkins, D. and D. Carrel, "The Internet key Exchange (IKE)", RFC 2409, November 1998.
[RFC2535] Eastlake, D., "Domain Name System Security Extensions", RFC 2535, March 1999. [RFC3110] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)", RFC 3110, May 2001. [IPSECKEY] Richardson, M., "A Method for Storing IPsec keying Material in DNS", RFC 4025, March 2005. [OEspec] H. Spencer and Redelmeier, D., "Opportunistic Encryption", paper, http://www.freeswan.org/ oeid/opportunism-spec.txt, May 2001. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [RFC1464] Rosenbaum, R., "Using the Domain Name System To Store Arbitrary String Attributes", RFC 1464, May 1993. [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", RFC 1812, June 1995. [RFC1984] IAB, IESG, Carpenter, B., and F. Baker, "IAB and IESG Statement on Cryptographic Technology and the Internet", RFC 1984, August 1996. [RFC2367] McDonald, D., Metz, C. and B. Phan, "PF_KEY Key Management API, Version 2", RFC 2367, July 1998. [RFC2538] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the Domain Name System (DNS)", RFC 2538, March 1999. [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. [RFC3330] IANA, "Special-Use IPv4 Addresses", RFC 3330, September 2002.
[RFC3445] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource Record (RR)", RFC 3445, December 2002. [RFC3526] Kivinen, T. and M. Kojo, "More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)", RFC 3526, May 2003. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. http://www.sandelman.ottawa.on.ca/ D. Hugh Redelmeier Mimosa Systems Inc. 29 Donino Avenue Toronto, ON M4N 2W6 CA EMail: email@example.com
Full Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- firstname.lastname@example.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.