Opportunistic Encryption using The Internet Key Exchange (IKE)

+ [Q] [R] + . . AS2 + [A]----+----[SG-A].......+....+.......[SG-B]-------[B] + | ...... + AS1 | ..PI.. + | ...... + [D]----+----[SG-D].......+....+.......[C] AS3 + + +

+ Alice SG-A DNS SG-B Bob + (1) + ------(2)--------------> + <-----(3)--------------- + (4)----(5)-----> + ----------(6)------> + ------(7)-----> + <------(8)------ + <----------(9)------ + <----(10)----- + (11)-----------> + ----------(12)-----> + --------------> + <--------------- + <------------------- + <------------- +

+ 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)------ + <==========(9)====== + <-----(10)---- + (11)-----------> + ==========(12)=====> + --------------> + <--------------- + <=================== + <------------- +

+ +

+ + +The objective of opportunistic encryption is to allow encryption without +any pre-arrangement specific to the pair of systems involved. Each +system administrator adds +public key information to DNS records to support opportunistic +encryption and then enables this feature in the nodes' IPsec stack. +Once this is done, any two such nodes can communicate securely. + + + +This document describes opportunistic encryption as designed and +implemented by the Linux FreeS/WAN project in revisions up and including 2.00. +Note that 2.01 and beyond implements RFC3445, in a backward compatible way. +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 . +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 - as 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. + + +

+ +

+ + To aid in understanding the relationship between security processing and IPsec + we divide network traffic into four categories: + + networks to which traffic is always forbidden. + networks to which traffic in the clear is permitted. + networks to which traffic is encrypted if possible, but otherwise is in the clear + or fails depending on the default policy in place. + + networks to which traffic +must be encrypted, and traffic in the clear is never permitted. +A Virtual Private Network (VPN) is a form of configured tunnel. + + + + + +Traditional firewall devices handle the first two categories. +No authentication is required. +The permit policy is currently the default on the Internet. + + + +This document describes the third category - opportunistic tunnel, which is +proposed as the new default for the Internet. + + + + Category four, 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, that of a public key method that does not + require deployment of an X.509 based infrastructure. + + +Current Virtual Private Networks can often be replaced by an "OE paranoid" +policy as described herein. + +

+ +

+ + + Opportunistic encryption creates tunnels between nodes that + are essentially strangers. This is done without any prior bilateral + arrangement. + There is, therefore, the difficult question of how one knows to whom one is + talking. + + + + One possible answer is that since no useful + authentication can be done, none should be tried. This mode of operation is + named "anonymous encryption". An active man-in-the-middle attack can be + used to thwart the privacy of this type of communication. + Without peer authentication, there is no way to prevent this kind of attack. + + + +Although 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 desireable goal. +The latter 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. + + + + However, 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. It may be that + the packet goes out in the clear, or it may be dropped. + + +

+ +

+ + 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 + +

+ +

+ 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 + + + + + + + + + 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/B is an independent organization, AS2. + Nodes Q and R are nodes on the Internet. PI is the Public + Internet ("The Wild"). + + +

+ +

+ + + The following terminology is used in this document: + + + + a system that performs IPsec tunnel + mode encapsulation/decapsulation. [SG-x] in the diagram. + node [A] in the diagram. When an IP address is needed, this is 192.1.0.65. + node [B] in the diagram. When an IP address is needed, this is 192.2.0.66. + node [C] in the diagram. When an IP address is needed, this is 192.1.1.67. + node [D] in the diagram. When an IP address is needed, this is 192.3.0.68. + Alice's security gateway. Internally it is 192.1.0.1, externally it is 192.1.1.4. + Bob's security gateway. Internally it is 192.2.0.1, externally it is 192.1.1.5. + 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 period represents an untrusted network of unknown + type. + 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. + + 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. + + + the process of encrypting a session without any knowledge of who the + other parties are. No authentication of identities is done. + + + the process of encrypting a session with authenticated knowledge of + who the other party is. + + + the period in seconds (bytes or datagrams) for which a security + association will remain alive before needing to be re-keyed. + + + 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. + + an ISAKMP/IKE security association sometimes + referred to as a keying channel. + + an IPsec security association. + + another term for a set of phase 2 SA (one in each direction). + + Network Address Translation + (see ). + + Network Address and Port Translation + (see ). + + an autonomous system + + Fully-Qualified Domain Name + + + 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. + + + +

+ +

+ + +The opportunistic encryption security gateway (OE gateway) is a regular +gateway node as described in section 2.4 and + with the additional capabilities described here and +in . +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 end point which should be used. + + +

+ +The OE gateway determines whether or not to create a tunnel based on +the destination address of each packet. Upon receiving a packet with a destination +address not recently seen, the OE gateway performs a lookup in DNS for an +authorization resource record (see ). 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. + +

+ +

+ + +The authorization resource record also 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 the public RSA key is not +present, the OE gateway performs a second lookup to find a KEY +resource record for the end point address or name. + + +Origin and integrity protection of the resource records is provided by +DNSSEC (). +documents an optional restriction on the tunnel end point if DNSSEC signatures +are not available for the relevant records. + + +

+ +

+ +The OE gateway maintains a cache, in the forwarding plane, of +source/destination pairs for which opportunistic encryption has been +attempted. This cache maintains a record of whether or not OE was +successful so that subsequent datagrams can be forwarded properly +without additional delay. + + + +Successful negotiation of OE instantiates a new security association. +Failure to negotiate OE results in creation of a +forwarding policy entry either to drop or transmit in the clear future +datagrams. This negative cache is necessary to avoid the possibly lengthy process of repeatedly looking +up the same information. + + + +The cache is timed out periodically, as described in . +This removes entries that are no longer +being used and permits the discovery of changes in authorization policy. + +

+ +

+ + +The OE gateway is modeled to have a forwarding plane and a control +plane. A control channel, such as PF_KEY, connects the two planes. +(See .) +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. + + +

+ + +Let the OE gateway maintain a collection of objects -- a superset of the +security policy database (SPD) specified in . 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. + + + + + + +

+ +If the gateway does not find an entry, then this policy applies. +The gateway creates an entry with an initial state of "hold policy" and requests +keying material from the keying daemon. The gateway does not forward the datagram, +rather it SHOULD attach the datagram to the SPD entry as the "first" datagram and retain it +for eventual transmission in a new state. + + +

+ +

+ +The gateway requests keying material. If the interface to the keying +system is lossy (PF_KEY, for instance, can be), the implementation +SHOULD include a mechanism to retransmit the +keying request at a rate limited to less than 1 request per second. +The gateway does not forward the datagram. The gateway SHOULD attach the +datagram to the SPD entry as the "last" datagram where it is retained +for eventual transmission. +If there is a datagram already so stored, then that already stored datagram is discarded. + + +The rational behind saving the 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 to +for the end-point to retransmit the datagram. In the case where the connection +was not a TCP connection, buyt 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 end-points determine +which data awas dropped while negotiation took place. + +

+ +

+ +The gateway forwards the datagram using the normal forwarding table. +The gateway enters this state only by command from the keying daemon, +and upon entering this state, also forwards the "first" and "last" datagrams. + +

+ +

+ +The gateway discards the datagram. The gateway enters this state only by +command +from the keying daemon, and upon entering this state, discards the "first" +and "last" datagrams. +An implementation MAY provide the administator with a control to determine +if further datagrams cause ICMP messages +to be generated (i.e. ICMP Destination Unreachable, Communication +Administratively Prohibited. type=3, code=13). + +

+ +

+ +The gateway encrypts the datagram using the indicated security association database +(SAD) entry. The gateway enters this state only by command from the keying daemon, and upon entering +this state, releases and forwards the "first" and "last" datagrams using the +new encrypt policy. + + +If the associated SAD entry expires because of byte, packet or time limits, then +the entry returns to the Hold policy, and an expire message is sent to the keying daemon. + +

+ + +All states may be created directly by the keying daemon while acting as a +gateway. + + +

+ + +

+ +Let the keying daemon maintain a collection of objects. Let them be +called "connections" or "conn"s. There are two categories of +connection objects: classes and instances. A class represents an +abstract policy - what could be. An instance represents an actual connection - +what is implemented at the time. + + + +Let there be two further subtypes of connections: keying channels (Phase +1 SAs) and data channels (Phase 2 SAs). Each data channel object may have +a corresponding SPD and SAD entry maintained by the datagram state machine. + + + +For the purposes of opportunistic encryption, there MUST, at least, be +connection classes known as "deny", "always-clear-text", "OE-permissive", and +"OE-paranoid". +The latter two connection classes define a set of source and/or destination +addresses for which opportunistic encryption will be attempted. +The administrator MAY set policy options in a number of additional places. +An implementation MAY create additional connection classes to further refine +these policies. + + + +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. + + + +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 machine's state transitions, the states +associated with the keying system itself are omitted because they are best documented in the keying system +(, + and 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 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. + + + +| 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 failure (short-timeout) + | | |<--.SPI | ICMP failures (normal timeout) + | | | | | + | | +=======+ |---' | + | | | IKE | | ^ | + `--------------| | states|---------------' + | +=======+ | | + `---------------' | + | IPsec SA | invalid SPI + | established | + V | rekey time + .--------------. | + | keyed |<---|-------------------------------. + | connection |----' | + `--------------' | + | timer | + | | + V | + .--------------. connection still active | + clear-text----->| expired |------------------------------------' + deny----->| connection | + `--------------' + | dead connected - deleted + V +]]> + + +

+ +There is no connection instance for a given source/destination address pair. +Upon receipt of a request for keying material for this +source/destination pair, the initiator searches through the connection classes to +determine the most appropriate policy. Upon determining an appropriate +connection class, an instance object is created of that type. +Both of the OE types result in a potential OE connection. + +Failure to find an appropriate connection class results in an +administrator defined default. + + +In each case, when the initiator finds an appropriate class for the new flow, +an instance connection is made of the class which matched. + +

+ +

+ +The non-existent connection makes a transition to this state when an +always-clear-text class is instantiated, or when an OE-permissive +connection fails. During the transition, the initiator creates a pass-through +policy object in the forwarding plane for the appropriate flow. + + +Timing out is the only way to leave this state +(see ). + +

+ +

+ +The empty connection makes a transition to this state when a +deny class is instantiated, or when an OE-paranoid connection fails. +During the transition, the initiator creates a deny policy object in the forwarding plane +for the appropriate flow. + + +Timing out is the only way to leave this state +(see ). + +

+ +

+ +The empty connection makes a transition to this state when one of either OE class is instantiated. +During the transition to this state, the initiator creates a hold policy object in the +forwarding plane for the appropriate flow. + + +In addition, when making a transition into this state, DNS lookup is done in +the reverse-map for a TXT delegation resource record (see ). +The lookup key is the destination address of the flow. + + +There are three ways to exit this state: + +DNS lookup finds a TXT delegation resource record. +DNS lookup does not find a TXT delegation resource record. +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: + +DNS finds an appropriate resource record +It is properly formatted according to + 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 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. + + +

+ +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. + + +

+ +

+ +The potential OE connection makes a transition to this state when +the initiator determines that all the information required from the DNS lookup is present. +Upon entering this state, the initiator attempts to initiate keying to the gateway +provided. + + +Exit from this state occurs 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. + + +Three failures have caused significant problems. They are clearly not the +only possible failures from keying. + + +Note that if there are 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 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 than non-signed records.) + + + +

+ +

+ +The pending OE connection makes a transition to this state when +session keying material (the phase 2 SAs) is derived. The initiator creates an encrypt +policy 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 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 to use 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. + +

+ +

+ +The initiator will periodically place each of the deny, clear-text, and keyed +connections into this +sub-state. See 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 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. + + +

+ +Entry to this state occurs when no datagrams have been 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. + + +The initiator sends an ISAKMP/IKE delete to clean up the phase 2 SAs as described in +. + + +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. + +

+ +

+ +Upon entering this state, the responder starts a DNS lookup for a KEY record for the +initiator. +The responder looks in the reverse-map for a KEY record for 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 section +4.6.2.1.) + + +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. + +

+ +

+ +The peer will eventually propose one or more phase 2 SAs. The responder uses the source and +destination address in the proposal to +finish instantiating the connection state +using the connection class table. +The responder MUST search for an identical connection object at this point. + + +If an identical connection is found, then the responder deletes the old instance, +and the new object makes a transition 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 the responder makes the 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. + +

+ +

+ +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 tunnels are no longer in use is the subject of this section. + + + +There are two methods for removing tunnels: explicit deletion or expiry. + + + +Explicit deletion requires an IKE delete message. As the deletes +MUST be authenticated, both ends of the tunnel must maintain the +key channel (phase 1 ISAKMP SA). An implementation which refuses to either maintain or +recreate the keying channel SA will be unable to use this method. + + + +The tunnel expiry method simply allows the IKE daemon to +expire normally without attempting to re-key it. + + + +Regardless of which method is used to remove tunnels, the implementation MUST +a method to determine if the tunnel is still in use. The specifics are a +local matter, but the FreeS/WAN project uses the following criteria. These +criteria are currently implemented in the key management daemon, but could +also be implemented at the SPD layer using an idle timer. + + + +Set a short initial (soft) lifespan of 1 minute since many net flows last +only a few seconds. + + + +At the end of the lifespan, check to see if the tunnel was used by +traffic in either direction during the last 30 seconds. 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. + + + +The expiring state in the key management +system (see ) implements these timeouts. +The timer above may be in the forwarding plane, +but then it must be re-settable. + + + +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. + + +

+ +

+ + +Teardown should always be coordinated between the two ends of the tunnel by +interpreting and sending delete notifications. There is a +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 also and notify the remote end with a +delete. If the local system receives a delete for a tunnel which is no longer in +existence, then two delete messages have crossed paths. Ignore the delete. +The operation has already been completed. Do not generate any messages in this +situation. + + +Tunnels are to be considered as bidirectional entities, even though the +low-level protocols don't treat them this 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 the local system does not receive a responding delete +for the outbound SAs, try re-sending the original +delete. Three tries spaced 10 seconds apart seems a reasonable +level of effort. A failure of the other end to respond after 3 attempts, +indicates that the possibility of further communication is unlikely. Remove the outgoing SAs. +(The remote system may be a mobile node that is no longer present or powered on.) + + + +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 (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. + + +

+ +

+ + 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 for nonces, + cookies and so on. + + + 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 co-resident on the same gateway. + +

+ +

+ + In a typical configured tunnel, the address of SG-B is provided + via configuration. Furthermore, the mapping of an SPD entry to a 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 implemented 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. + +

+ +

+ + SG-A will have to establish its identity. Use 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) 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 + for more details and restrictions. + +

+ +

+ + Upon receipt of a phase 1 SA proposal with either an IPv4 (IPv6) ID or + an FQDN ID, an IKE daemon needs to examine local caches and + configuration files to determine if this is part of a configured tunnel. + If no configured tunnels are 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), they be consulted concurrently but some + clear ordering of policy be provided. Note that due to variances in + latency, implementations must wait for positive or negative replies from all sources + of policy before making any decisions. + +

+ +

+ + The implementation described (1.98) neither uses DNSSEC directly to + explicitly verify the authenticity of zone information, nor uses the NXT + records to provide authentication of the absence of a TXT or KEY + record. Rather, this implementation uses a trusted path to a DNSSEC + capable caching resolver. + + + To distinguish between an authenticated and an unauthenticated DNS + resource record, a stub resolver capable of returning DNSSEC + information MUST be used. + + +

+ + + +

+ +

+ + 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. + + + + 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 .) 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). + +

+ +

+ + The initiator MUST propose a tunnel between the ultimate + sender ("Alice" or "A") and ultimate recipient ("Bob" or "B") + using 3DES-CBC + mode, MD5 or SHA1 authentication. Perfect Forward Secrecy MUST be specified. + + + Tunnel mode MUST be used. + + + Identities MUST be ID_IPV4_ADDR_SUBNET with the mask being /32. + + + Authorization for the initiator to act on Alice's behalf is determined by + looking for a TXT record in the reverse-map at Alice's IP address. + + + Compression SHOULD NOT be mandatory. It MAY be offered as an option. + +

+ +

+ + In order to establish their own identities, security gateways SHOULD publish + their public keys in their reverse DNS via + DNSSEC's KEY record. + See section 3 of RFC 2535. + + + For example: + + + + 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. + This indicates that this key is for use by IPsec. + An RSA key is present. + The public key of the host as described in . + + + Use of several KEY records allows for key rollover. The SIG Payload in + IKE phase 1 SHOULD be accepted if the public key given by any KEY RR + validates it. + +

+ +

+ +If, for example, machine Alice wishes SG-A to act on her behalf, then +she publishes a TXT record to provide authorization for SG-A to act on +Alice's behalf. Similarly for Bob and SG-B. + + + +These records are located in the reverse DNS (in-addr.arpa or ip6.arpa) for their +respective IP addresses. The reverse DNS SHOULD be secured by DNSSEC. +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: + + + + + The contents of the resource record are expected to be a string that + uses the following syntax, as suggested in RFC1464. + (Note that the reply to query may include other TXT resource + records used by other applications.) + +

+ + + + + where the record is formed by the following fields: + + + Specifies a precedence for this record. This is + similar to MX record preferences. Lower numbers have stronger + preference. + + + Specifies the IP address of the Security Gateway + for this client machine. + + + Is the encoded RSA Public key of the Security + Gateway. The 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. + +

+ + + + + + Is as above. + + + Specifies the FQDN that the Security Gateway + will identify itself with. + + + 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. + + +

+ + When packed into transport format, TXT records which are longer than 255 + characters are divided into smaller <character-strings>. + (See 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. + +

+ +

+ + It has been suggested to use the KEY, OPT, CERT, or KX records + instead of a TXT record. None is satisfactory. + + The KEY RR has a protocol field which could be used to indicate a new protocol, +and an algorithm field which could be used to + indicate different contents in the key data. However, the KEY record + is clearly not intended for storing what are really authorizations, + it is just for identities. Other uses have been discouraged. + + OPT resource records, as defined in 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 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. + + +

+ +

+ + Unfortunately, not every administrator has control over the contents + of the reverse-map. Where the initiator (SG-A) has no suitable reverse-map, 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 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. + However, Alice must still delegate to herself if she wishes others to + initiate OE to her. See . + + < +

+ +

+ +Good cryptographic hygiene says that one should replace public/private key pairs +periodically. Some administrators 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, administrators usually want 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 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. + + +

+ + +

+ + There are no fundamentally new issues for implementing opportunistic encryption + in the presence of network address translation. Rather there are + only the regular IPsec issues with NAT traversal. + + + There are several situations to consider for NAT. + +

+ + If a security gateway is also performing network address translation on + behalf of an end-system, then the packet should be translated prior to + being subjected to opportunistic encryption. This is in contrast to + typically configured tunnels which often exist to bridge islands of + private network address space. The security gateway will use the translated source + address for phase 2, and so the responding security gateway will look up that address 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. + Placing of TXT records is possible. + + In the case of NAPT (m:1), the address will be the security + gateway itself. 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. + +

+ +

+ + If there is a NAT or NAPT between the security gateways, then normal IPsec + NAT traversal problems occur. 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 the security gateway, there is no appropriate ID for phase 2. + Due to the NAT, the end systems live in different IP address spaces. + +

+ +

+ + If the end system is behind a NAT (perhaps SG-B), then there is, in fact, no way for + another end system to address a packet to this end system. + Not only is opportunistic encryption + impossible, but it is also impossible for any communication to + be initiate to the end system. It may be possible for this end + system to initiate in such communication. This creates an asymmetry, but this is common for + NAPT. + +

+ +

+ + When Alice and SG-A are components of the same system, they are + considered to be a host implementation. The packet sequence scenario remains unchanged. + + + Components marked Alice are the upper layers (TCP, UDP, the + application), and SG-A is the IP layer. + + + Note that tunnel mode is still required. + + + As Alice and SG-A are acting on behalf of themselves, no TXT based delegation + record is necessary for Alice to initiate. She can rely on 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 Alice's reverse-map. + +

+ +

+ +If there are multiple paths between Alice and Bob (as illustrated in +the diagram with SG-D), then additional DNS records are required to establish +authorization. + + +In , 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: +

+ + + + +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: + +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. + +It can send to the gateway from which it most recently received datagrams. + This assumes that routing and reachability are symmetrical. + +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. + +It can refuse to negotiate the second tunnel. (It is unclear whether or +not this is even an option.) + +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, 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. + + +

+ +

+ + If a DNS server fails to respond, local policy decides + whether or not to permit communication in the clear as embodied in + the connection classes in . + 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. + +

+ +

+ + 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 because of a crash or reboot, a + faulty configuration, or a firewall filtering port 500. + + + The receipt of ICMP port, host or network unreachable + messages indicates 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 active attacker could easily + prevent any + encryption from ever occurring, possibly preventing all communication. + + + In these situations a clear log should be produced + and local policy should dictate if communication is then + permitted in the clear. + +

+ +

+ +Tunnels sometimes go down because the remote end crashes, +disconnects, or has a network link break. In general there is no +notification of this. 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 outages is undesirable. Note that a tunnel can be torn +down and then re-established without any effect visible to the user +except a pause in traffic. On the other hand, if one end reboots, +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 recovery after reboot is a topic of current research and is not specified in this +document. + + + +A deliberate shutdown should include an attempt, using deletes, to notify all other SGs +currently connected by phase 1 SAs that communication is +about to fail. Again, a remote SG will assume this is a teardown. Attempts by the +remote SGs to negotiate new tunnels as replacements should be ignored. 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. + + +

+ + + +

+ + The method of obtaining information by reverse DNS lookup causes + problems for people who cannot control their reverse DNS + bindings. This is an unresolved problem in this version, and is out + of scope. + +

+ +

+ + +Two example scenarios follow. In the first example GW-A +(Gateway A) and GW-B (Gateway B) have always-clear-text policies, and in the second example they have an OE +policy. The clear-text policy serves as a reference for what occurs in +TCP/IP in the absence of Opportunistic Encryption. + + +Alice wants to communicate with Bob. Perhaps she wants to retrieve a +web page from Bob's web server. In the absence of opportunistic +encryptors, the following events occur: + + +

+ + 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 + + ----(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. + + (11)-----------> + A second exchange + occurs. + ----------(12)-----> + --------------> + <--------------- + <------------------- + <------------- + ]]> + + + +

+ +

+ + +In the presence of properly configured opportunistic encryptors, the +event list is extended. Only changes are annotated. + + +The following symbols are used in the time-sequence diagram + + + + 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. + + + + +

+ + <-----(3)--------------- + (4)----(5)----->+ + SG-A sees datagram + to new target and + saves it as "first" + + ----(5B)-> + SG-A asks DNS + for TXT RR. + + <---(5C)-- + DNS returns TXT RR. + + ~~~~~~~~~~~~~(5D)~~~> + initial IKE main mode + packet is sent. + + <~~~~~~~~~~~~(5E1)~~~ + ~~~~~~~~~~~~~(5E2)~~> + <~~~~~~~~~~~~(5E3)~~~ + IKE phase 1 - privacy. + + #############(5E4)##> + SG-A sends ID to SG-B + <----(5F1)-- + SG-B asks DNS + for SG-A's public + KEY + -----(5F2)-> + DNS provides KEY RR. + SG-B authenticates SG-A + + <############(5E5)### + IKE phase 1 - complete + + #############(5G1)##> + IKE phase 2 - Alice<->Bob + tunnel is proposed. + + <----(5H1)-- + SG-B asks DNS for + Alice's TXT record. + -----(5H2)-> + DNS replies with TXT + record. SG-B checks + SG-A's authorization. + + <############(5G2)### + SG-B accepts proposal. + + #############(5G3)##> + SG-A confirms. + + ============(6)====> + SG-A sends "first" + packet in new IPsec + SA. + ------(7)-----> + packet is decrypted + and forward to Bob. + <------(8)------ + <==========(9)====== + return packet also + encrypted. + <-----(10)---- + + (11)-----------> + a second packet + is sent by Alice + ==========(12)=====> + existing tunnel is used + --------------> + <--------------- + <=================== + <------------- + ]]> + + + + + + For the purposes of this section, we will describe only the changes that + occur between and + . 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 non-existent policy state). SG-A creates a hold policy, and buffers the datagram. SG-A requests keys from the keying daemon. + + + + SG-A's IKE daemon, having looked up the source/destination pair in the connection + class list, creates a new Potential OE connection instance. SG-A starts DNS + queries. + +

+ +

+ + + DNS returns properly formed TXT delegation records, and SG-A's IKE daemon + causes this instance to make a transition from Potential OE connection to Pending OE + connection. + + + + Using the example above, the returned record might contain: + +

+ + + with SG-B's IP address and public key listed. + + +

+ +

+ Upon entering Pending OE connection, SG-A sends the initial ISAKMP + message with proposals. See . + +

+ +

+ + SG-B receives the message. A new connection instance is created in the + unauthenticated OE peer state. + +

+ +

+ + SG-A sends a Diffie-Hellman exponent. This is an internal state of the + keying daemon. + +

+ +

+ + SG-B responds with a Diffie-Hellman exponent. This is an internal state of the + keying protocol. + +

+ +

+ + SG-A uses the phase 1 SA to send its identity under encryption. + The choice of identity is discussed in . + This is an internal state of the keying protocol. + +

+ +

+ + 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 4.1.1.192.in-addr.arpa + (recall that SG-A's external address is 192.1.1.4). + SG-B uses the resulting public key to authenticate the initiator. See for further details. + +

+ +

+ +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 +. + +

+ +

+ + SG-B sends its ID along with authentication material. This is an internal + state for the keying protocol. + +

+ +

+ + 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. + +

+ +

+ + 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. + + 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. +

+ +

+ + The returned key and IP address should match that of SG-A. + +

+ +

+ + Should additional communication occur between, for instance, Dave and Bob using + 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 makes a transition from + Pending OE connection to Keyed OE connection. + + The responder MUST setup the inbound IPsec SAs before sending its reply. +

+ +

+ + 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 make a transition + to the keyed OE connection state. + + Upon receipt of this message, the responder may now setup the outbound + IPsec SAs. +

+ +

+ + 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). + +

+ +

+ + 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). + + +

+ + + +

+ +

+ + 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 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 can not 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. + +

+ +

+ + Typical usage of per datagram access control lists is to implement various +kinds of security gateways. These are typically called "firewalls". + + + Typical usage of a 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 datagram arriving in the +clear SHOULD also be applied to datagrams arriving opportunistically. + +

+ +

+ + There are several different forms of denial of service that 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. Opportunism changes the assumption that if the phase 1 (ISAKMP) + SA is authenticated, that it was worthwhile creating. Because the gateway will communicate with any machine, it is + possible to form phase 1 SAs with any machine on the Internet. + + +

+ +

+ + There are no known numbers which IANA will need to manage. + +

+ +

+ + Substantive portions of this document are based upon previous work by + Henry Spencer. + + + 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. + +

+ +

[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 University of Southern California (USC)/Information Sciences Institute, "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", RFC 3526, March 2003.
[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.
[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.

	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

Status of this Memo

Copyright Notice

Abstract

Table of Contents

1. Introduction

1.1 Motivation

1.2 Types of network traffic

1.3 Peer authentication in opportunistic encryption

1.4 Use of RFC2119 terms

2. Overview

2.1 Reference diagram

2.2 Terminology

2.3 Model of operation

2.3.1 Tunnel authorization

2.3.2 Tunnel end-point discovery

2.3.3 Caching of authorization results

3. Specification

3.1 Datagram state machine

3.1.1 Non-existent policy

3.1.2 Hold policy

3.1.3 Pass-through policy

3.1.4 Deny policy

3.1.5 Encrypt policy

3.2 Keying state machine - initiator

3.2.1 Nonexistent connection

3.2.2 Clear-text connection

3.2.3 Deny connection

3.2.4 Potential OE connection

3.2.4.1 Restriction on unauthenticated TXT delegation records

3.2.5 Pending OE connection

3.2.6 Keyed connection

3.2.7 Expiring connection

3.2.8 Expired connection

3.3 Keying state machine - responder

3.3.1 Unauthenticated OE peer

3.3.2 Authenticated OE Peer

3.4 Renewal and teardown

3.4.1 Aging

3.4.2 Teardown and cleanup

4. Impacts on IKE

4.1 ISAKMP/IKE protocol

4.2 Gateway discovery process

4.3 Self identification

4.4 Public key retrieval process

4.5 Interactions with DNSSEC

4.6 Required proposal types

4.6.1 Phase 1 parameters

4.6.2 Phase 2 parameters

5. DNS issues

5.1 Use of KEY record

5.2 Use of TXT delegation record

5.2.1 Long TXT records

5.2.2 Choice of TXT record

5.3 Use of FQDN IDs

5.4 Key roll-over

6. Network address translation interaction

6.1 Co-located NAT/NAPT

6.2 SG-A behind NAT/NAPT

6.3 Bob is behind a NAT/NAPT

7. Host implementations

8. Multi-homing

9. Failure modes

9.1 DNS failures

9.2 DNS configured, IKE failures

9.3 System reboots

10. Unresolved issues

10.1 Control of reverse DNS

11. Examples

11.1 Clear-text usage (permit policy)

11.2 Opportunistic encryption

11.2.1 (5) IPsec datagram interception

11.2.2 (5B) DNS lookup for TXT record

11.2.3 (5C) DNS returns TXT record(s)

11.2.4 (5D) Initial IKE main mode packet goes out

11.2.5 (5E1) Message 2 of phase 1 exchange

11.2.6 (5E2) Message 3 of phase 1 exchange

11.2.7 (5E3) Message 4 of phase 1 exchange

11.2.8 (5E4) Message 5 of phase 1 exchange

11.2.9 (5F1) Responder lookup of initiator key

11.2.10 (5F2) DNS replies with public key of initiator