From 808cf8b3174aa7ad0833ea69cb55753d21318c9c Mon Sep 17 00:00:00 2001
From: Rene Mayrhofer
+This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.
+Internet-Drafts are working documents of the Internet Engineering
+Task Force (IETF), its areas, and its working groups.
+Note that other groups may also distribute working documents as
+Internet-Drafts.
+Internet-Drafts are draft documents valid for a maximum of six months
+and may be updated, replaced, or obsoleted by other documents at any time.
+It is inappropriate to use Internet-Drafts as reference material or to cite
+them other than as "work in progress."
+The list of current Internet-Drafts can be accessed at
+http://www.ietf.org/ietf/1id-abstracts.txt.
+The list of Internet-Draft Shadow Directories can be accessed at
+http://www.ietf.org/shadow.html.
+This Internet-Draft will expire on November 19, 2003.
+Copyright (C) The Internet Society (2003). All Rights Reserved.
+This document describes opportunistic encryption (OE) using the Internet Key
+Exchange (IKE) and IPsec.
+Each system administrator adds new
+resource records to his or her Domain Name System (DNS) to support
+opportunistic encryption. 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.
+
+
+This document is offered up as an Informational RFC.
+
+
+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
+mostly implemented by the Linux FreeS/WAN project.
+For project information, see http://www.freeswan.org.
+
+
+The Internet Architecture Board (IAB) and Internet Engineering
+Steering Group (IESG) have taken a strong stand that the Internet
+should use powerful encryption to provide security and
+privacy [4].
+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:
+
+
+
+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 [5]
+ The following network diagram is used in the rest of
+ this document as the canonical diagram:
+
+
+ In this diagram, there are four end-nodes: A, B, C and D.
+ There are three gateways, SG-A, SG-B, SG-D. A, D, SG-A and SG-D are part
+ of the same administrative authority, AS1. SG-A and SG-D are on two different exit
+ paths from organization 1. SG-B/B is an independent 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:
+
+
+The opportunistic encryption security gateway (OE gateway) is a regular
+gateway node as described in [2] section 2.4 and
+[3] with the additional capabilities described here and
+in [7].
+The algorithm described here provides a way to determine, for each datagram,
+whether or not to encrypt and tunnel the datagram. 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 Use of TXT delegation record). 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 ([16]). Restriction on unauthenticated TXT delegation records
+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 Renewal and teardown.
+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 [6].)
+The forwarding plane performs per datagram operations. The control plane
+contains a keying
+daemon, such as ISAKMP/IKE, and performs all authorization, peer authentication and
+key derivation functions.
+
+
+Let the OE gateway maintain a collection of objects -- a superset of the
+security policy database (SPD) specified in [7]. 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 responder does not find an entry, then this policy applies.
+The responder creates an entry with an initial state of "hold policy" and requests
+keying material from the keying daemon. The responder does not forward the datagram,
+rather it attaches the datagram to the SPD entry as the "first" datagram and retains it
+for eventual transmission in a new state.
+
+
+
+The responder 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 responder does not forward the datagram. It attaches 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.
+
+
+Because the "first" datagram is probably a TCP SYN packet, the
+responder retains the "first" datagram in an attempt to avoid waiting for a
+TCP retransmit. The responder retains the "last"
+datagram in deference to streaming protocols that find it useful to know
+how much data has been lost. These are recommendations to
+decrease latency. There are no operational requirements for this.
+
+
+The responder forwards the datagram using the normal forwarding table.
+The responder enters this state only by command from the keying daemon,
+and upon entering this state, also forwards the "first" and "last" datagrams.
+
+
+The responder discards the datagram. The responder enters this state only by
+command
+from the keying daemon, and upon entering this state, discards the "first"
+and "last" datagrams.
+Local administration decides if further datagrams cause ICMP messages
+to be generated (i.e. ICMP Destination Unreachable, Communication
+Administratively Prohibited. type=3, code=13).
+
+
+The responder encrypts the datagram using the indicated security association database
+(SAD) entry. The responder 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
+responder.
+
+
+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
+([8],
+[9] and [10] for ISAKMP/IKE),
+and the details are keying system specific. Opportunistic encryption is not
+dependent upon any specific keying protocol, but this document does provide
+requirements for those using ISAKMP/IKE to assure 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.
+
+
+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 Expiring connection).
+
+
+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 Expiring connection).
+
+
+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 Use of TXT delegation record).
+The lookup key is the destination address of the flow.
+
+
+There are three ways to exit this state:
+
+
+
+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:
+
+
+
+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 should make 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 Renewal and teardown 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 [12] 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
+Renewal and teardown.
+
+
+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.
+
+
+The responder has a set of objects identical to those of the initiator.
+
+
+The responder receives an invitation to create a keying channel from an initiator.
+
+
+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 [8] 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 requires
+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 Expiring connection) 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 Use of FQDN IDs
+ 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.
+ [11]
+
+ The initiator MAY offer additional proposals, but the cipher MUST not
+ be weaker than 3DES. The initiator SHOULD limit the number of proposals
+ such that the IKE datagrams do not need to be fragmented.
+
+
+ The responder MUST accept one of the proposals. If any configuration
+ of the responder is required then the responder is not acting in an
+ opportunistic way.
+
+
+ SG-A SHOULD use an ID_IPV4_ADDR (ID_IPV6_ADDR for IPv6) of the external
+ interface of SG-A for phase 1. (There is an exception, see Use of FQDN IDs.) The authentication method MUST be RSA public key signatures.
+ The RSA key for SG-A SHOULD be placed into a DNS KEY record in
+ the reverse space of SG-A (i.e. using in-addr.arpa).
+
+
+ SG-A MUST propose a tunnel between Alice and Bob, using 3DES-CBC
+ mode, MD5 or SHA1 authentication. Perfect Forward Secrecy MUST be specified.
+
+
+ Tunnel mode MUST be used.
+
+
+ Identities MUST be ID_IPV4_ADDR_SUBNET with the mask being /32.
+
+
+ Authorization for SG-A to act on Alice's behalf is determined by
+ looking for a TXT record in the reverse-map at Alice's address.
+
+
+ Compression SHOULD NOT be mandatory. It may be offered as an option.
+
+
+ In order to establish their own identities, SG-A and SG-B SHOULD publish
+ their public keys in their reverse DNS via
+ DNSSEC's KEY record.
+ See section 3 of RFC 2535[16].
+
+
+ For example:
+
+ 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.
+
+
+Alice publishes a TXT record to provide authorization for SG-A to act on
+Alice's behalf.
+
+Bob publishes a TXT record to provide authorization for SG-B to act on Bob's
+behalf.
+
+These records are located in the reverse DNS (in-addr.arpa) for their
+respective IP addresses. The reverse DNS SHOULD be secured by DNSSEC, when
+it is deployed. DNSSEC is required to defend against active attacks.
+
+
+ If Alice's address is P.Q.R.S, then she can authorize another node to
+ act on her behalf by publishing records at:
+
+
+
+ The contents of the resource record are expected to be a string that
+ uses the following syntax, as suggested in [15].
+ (Note that the reply to query may include other TXT resource
+ records used by other applications.)
+
+
+ TOC
+
+
+Independent submission M. Richardson
+Internet-Draft SSW
+Expires: November 19, 2003 D. Redelmeier
+ Mimosa
+ May 21, 2003
Opportunistic Encryption using The Internet Key Exchange (IKE)Status of this Memo
+Copyright Notice
+Abstract
+
+
+
+ TOC Table of Contents
+
+1.
+Introduction
+
+2.
+Overview
+3.
+Specification
+4.
+Impacts on IKE
+5.
+DNS issues
+6.
+Network address translation interaction
+7.
+Host implementations
+8.
+Multi-homing
+9.
+Failure modes
+10.
+Unresolved issues
+11.
+Examples
+12.
+Security considerations
+13.
+IANA Considerations
+14.
+Acknowledgments
+§
+Normative references
+§
+Authors' Addresses
+§
+Full Copyright Statement
+
+
+
+
+ TOC 1. Introduction
+
+1.1 Motivation
+
+1.2 Types of network traffic
+
+
+
1.3 Peer authentication in opportunistic encryption
+
+1.4 Use of RFC2119 terms
+
+
+
+ TOC 2. Overview
+
+2.1 Reference diagram
+
+
+
+
+ [Q] [R]
+ . . AS2
+ [A]----+----[SG-A].......+....+.......[SG-B]-------[B]
+ | ......
+ AS1 | ..PI..
+ | ......
+ [D]----+----[SG-D].......+....+.......[C] AS3
+
+
+
+
+ Reference Network 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
+
+
+
+ TOC 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
+
+
+
+ TOC 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
+
+
+
+ TOC 5. DNS issues
+
+5.1 Use of KEY record
+
+
+KEY 0x4200 4 1 AQNJjkKlIk9...nYyUkKK8
+
+
+
+
5.2 Use of TXT delegation record
+
+
+S.R.Q.P.in-addr.arpa
+
+
+
+
+X-IPsec-Server(P)=A.B.C.D KEY ++
+
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. + +
+- KEY:
+- 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 pieces of the record are separated by any whitespace + (space, tab, newline, carriage return). An ASCII space SHOULD + be used. + +
+
+ In the case where Alice is located at a public address behind a
+ security gateway that has no fixed address (or no control over its
+ reverse-map), then Alice may delegate to a public key by domain name.
+
+
+X-IPsec-Server(P)=@FQDN KEY ++
+
Format of reverse delegation record (FQDN version) |
+
- P:
+- Is as above. + +
+- FQDN:
+- Specifies the FQDN that the Security Gateway + will identify itself with. + +
+- KEY:
+- Is the encoded RSA Public key of the Security + Gateway. +
+
+
+ If there is more than one such TXT record with strongest (lowest + numbered) precedence, one Security Gateway is picked arbitrarily from + those specified in the strongest-preference records. + +
++ When packed into transport format, TXT records which are longer than 255 + characters are divided into smaller <character-strings>. + (See [13] 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 [14] are not + intended to be used for storage of information. They are not to be loaded, + cached or forwarded. They are, therefore, inappropriate for use here. + +
++ CERT records [18] can encode almost any set of + information. A custom type code 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 Format of reverse delegation record (FQDN version). + +
++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. + +
+ TOC |
+ 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 SG-A is also performing network address translation on + behalf of Alice, then the packet should be translated prior to + being subjected to opportunistic encryption. This is in contrast to + typically configured tunnels which often exist to bridge islands of + private network address space. SG-A will use the translated source + address for phase 2, and so SG-B will look 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 SG-A. The ability to get + KEY and TXT records in place will again depend upon whether or not + there is administrative control over the reverse-map. This is + identical to situations involving a single host acting on behalf of + itself. + + FQDN style can be used to get around a lack of a reverse-map for + initiators only. + +
++ If there is a NAT or NAPT between SG-A and SG-B, then normal IPsec + NAT traversal rules apply. In addition to the transport problem + which may be solved by other mechanisms, there + is the issue of what phase 1 and phase 2 IDs to use. While FQDN could + be used during phase 1 for SG-A, there is no appropriate ID for phase 2 + that permits SG-B to determine that SG-A is in fact authorized to speak for Alice. + +
++ If Bob is behind a NAT (perhaps SG-B), then there is, in fact, no way for + Alice to address a packet to Bob. Not only is opportunistic encryption + impossible, but it is also impossible for Alice to initiate any + communication to Bob. It may be possible for Bob to initiate in such + a situation. This creates an asymmetry, but this is common for + NAPT. + +
+ TOC |
+ 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. + +
+ TOC |
+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 Reference Network Diagram, 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)=192.1.1.5 AQMM...3s1Q== +X-IPsec-Server(10)=192.1.1.6 AAJN...j8r9== ++
+
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: + +
+
++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. + +
+ TOC |
+ 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 Keying state machine - initiator. + 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. + +
+ TOC |
+ 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. + +
+ TOC |
+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. + +
+ Alice SG-A DNS SG-B Bob + (1) + ------(2)--------------> + <-----(3)--------------- + (4)----(5)-----> + ----------(6)------> + ------(7)-----> + <------(8)------ + <----------(9)------ + <----(10)----- + (11)-----------> + ----------(12)-----> + --------------> + <--------------- + <------------------- + <------------- ++
Timing of regular transaction |
+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: + +
+
- (1)
+- Human or application 'clicks' with a name. +
+- (2)
+- Application looks up name in DNS to get IP address. +
+- (3)
+- Resolver returns A record to application. +
+- (4)
+- Application starts a TCP session or UDP session and OS sends datagram. +
+- (5)
+- Datagram is seen at first gateway from Alice (SG-A). (SG-A +makes a transition through Empty connection to always-clear connection and +instantiates a pass-through policy at the forwarding plane.) +
+- (6)
+- Datagram is seen at last gateway before Bob (SG-B). +
+- (7)
+- First datagram from Alice is seen by Bob. +
+- (8)
+- First return datagram is sent by Bob. +
+- (9)
+- Datagram is seen at Bob's gateway. (SG-B makes a transition through +Empty connection to always-clear connection and instantiates a pass-through +policy at the forwarding plane.) +
+- (10)
+- Datagram is seen at Alice's gateway. +
+- (11)
+- OS hands datagram to application. Alice sends another datagram. +
+- (12)
+- A second datagram traverses the Internet. +
+
+
+
+In the presence of properly configured opportunistic encryptors, the
+event list is extended.
+
+
+ Alice SG-A DNS SG-B Bob + (1) + ------(2)--------------> + <-----(3)--------------- + (4)----(5)----->+ + ----(5B)-> + <---(5C)-- + ~~~~~~~~~~~~~(5D)~~~> + <~~~~~~~~~~~~(5E1)~~~ + ~~~~~~~~~~~~~(5E2)~~> + <~~~~~~~~~~~~(5E3)~~~ + #############(5E4)##> + <############(5E5)### + <----(5F1)-- + -----(5F2)-> + #############(5G1)##> + <----(5H1)-- + -----(5H2)-> + <############(5G2)### + #############(5G3)##> + ============(6)====> + ------(7)-----> + <------(8)------ + <==========(9)====== + <-----(10)---- + (11)-----------> + ==========(12)=====> + --------------> + <--------------- + <=================== + <------------- ++
+
Timing of opportunistic encryption transaction |
+
- (1)
+- Human or application clicks with a name. +
+- (2)
+- Application initiates DNS mapping. +
+- (3)
+- Resolver returns A record to application. +
+- (4)
+- Application starts a TCP session or UDP. +
+- (5)
+- SG-A (host or SG) sees datagram to target, and buffers it. +
+- (5B)
+- SG-A asks DNS for TXT record. +
+- (5C)
+- DNS returns TXT record(s). +
+- (5D)
+- Initial IKE Main Mode Packet goes out. +
+- (5E)
+- IKE ISAKMP phase 1 succeeds. +
+- (5F)
+- SG-B asks DNS for TXT record to prove SG-A is an agent for Alice. +
+- (5G)
+- IKE phase 2 negotiation. +
+- (5H)
+- DNS lookup by responder (SG-B). +
+- (6)
+- Buffered datagram is sent by SG-A. +
+- (7)
+- Datagram is received by SG-B, decrypted, and sent to Bob. +
+- (8)
+- Bob replies, and datagram is seen by SG-B. +
+- (9)
+- SG-B already has tunnel up with SG-A, and uses it. +
+- (10)
+- SG-A decrypts datagram and gives it to Alice. +
+- (11)
+- Alice receives datagram. Sends new packet to Bob. +
+- (12)
+- SG-A gets second datagram, sees that tunnel is up, and uses it. +
+
+
++ For the purposes of this section, we will describe only the changes that + occur between Timing of regular transaction and + Timing of opportunistic encryption transaction. 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:
+
+
+X-IPsec-Server(10)=192.1.1.5 AQMM...3s1Q== ++
+
Example of reverse delegation record for Bob |
Upon entering Pending OE connection, SG-A sends the initial ISAKMP + message with proposals. See Phase 1 parameters. + +
++ 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 Phase 1 parameters. + 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 Use of KEY record 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 +Use of TXT delegation record. + +
++ 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). + +
+ TOC |
+ 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. + +
+ TOC |
+ There are no known numbers which IANA will need to manage. + +
+ TOC |
+ 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. + +
+ TOC |
TOC |
+ | 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 |
TOC |
+Copyright (C) The Internet Society (2003). All Rights Reserved.
++This document and translations of it may be copied and furnished to +others, and derivative works that comment on or otherwise explain it +or assist in its implementation may be prepared, copied, published and +distributed, in whole or in part, without restriction of any kind, +provided that the above copyright notice and this paragraph are +included on all such copies and derivative works. However, this +document itself may not be modified in any way, such as by removing +the copyright notice or references to the Internet Society or other +Internet organizations, except as needed for the purpose of +developing Internet standards in which case the procedures for +copyrights defined in the Internet Standards process must be +followed, or as required to translate it into languages other than +English.
++The limited permissions granted above are perpetual and will not be +revoked by the Internet Society or its successors or assigns.
++This document and the information contained herein is provided on an +"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING +TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING +BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION +HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF +MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
++Funding for the RFC Editor function is currently provided by the +Internet Society.
+ diff --git a/doc/src/draft-richardson-ipsec-opportunistic.xml b/doc/src/draft-richardson-ipsec-opportunistic.xml new file mode 100644 index 000000000..d587df693 --- /dev/null +++ b/doc/src/draft-richardson-ipsec-opportunistic.xml @@ -0,0 +1,2519 @@ + + + + + +K1Z 5V7
+ /Quote -->/ -s/<\/blockquote>/<-- End Quote/ -# mark headers -s//Header 1: / -s/
/Header 2: / -s/
/Header 3: / -s/
/Header 4: / -s/
/Header 5: / -s/
/Header 6: / -# remove some cruft -s/<\/h[1-6]>// -/^$/d -s/// -# definition lists -s/
// -s/<\/dl>// -s/^
- $/-----------------------------------------/ -s/^
- /-----------------------------------------\ -/ -s/
- /\ -/ -# other types of lists -s/
- // -s/
// -s/
// -s/<\/ol>// -s/<\/ul>// -# tables -s/