diff options
| author | Rene Mayrhofer <rene@mayrhofer.eu.org> | 2006-07-09 11:39:54 +0000 |
|---|---|---|
| committer | Rene Mayrhofer <rene@mayrhofer.eu.org> | 2006-07-09 11:39:54 +0000 |
| commit | 360796fdebe9389dbf74cc93775e71fc57cb8907 (patch) | |
| tree | da13b4afaa4f6e052e247dc32f43534f68c3c391 | |
| parent | 6782d06a206e8aa8304d4ec9518361aecd1b9472 (diff) | |
| download | vyos-strongswan-360796fdebe9389dbf74cc93775e71fc57cb8907.tar.gz vyos-strongswan-360796fdebe9389dbf74cc93775e71fc57cb8907.zip | |
Load /tmp/tmp.UCewB23859/strongswan-2.7.2+dfsg into
branches/source-dist/debian/strongswan.
| -rw-r--r-- | doc/draft-richardson-ipsec-opportunistic.txt | 2688 | ||||
| -rw-r--r-- | doc/draft-richardson-ipsec-rr.txt | 840 | ||||
| -rw-r--r-- | doc/draft-spencer-ipsec-ike-implementation.nr | 1203 | ||||
| -rw-r--r-- | doc/draft-spencer-ipsec-ike-implementation.txt | 1232 | ||||
| -rw-r--r-- | doc/src/draft-richardson-ipsec-opportunistic.html | 2456 | ||||
| -rw-r--r-- | doc/src/draft-richardson-ipsec-opportunistic.xml | 2519 | ||||
| -rw-r--r-- | doc/src/draft-richardson-ipsec-rr.html | 659 | ||||
| -rw-r--r-- | doc/src/draft-richardson-ipsec-rr.xml | 560 |
8 files changed, 0 insertions, 12157 deletions
diff --git a/doc/draft-richardson-ipsec-opportunistic.txt b/doc/draft-richardson-ipsec-opportunistic.txt deleted file mode 100644 index 4c87d857a..000000000 --- a/doc/draft-richardson-ipsec-opportunistic.txt +++ /dev/null @@ -1,2688 +0,0 @@ - - -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) - draft-richardson-ipsec-opportunistic-11.txt - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on November 19, 2003. - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - -Abstract - - 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. - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 1] - -Internet-Draft opportunistic May 2003 - - - 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. - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 3. Specification . . . . . . . . . . . . . . . . . . . . . . . . 10 - 4. Impacts on IKE . . . . . . . . . . . . . . . . . . . . . . . . 21 - 5. DNS issues . . . . . . . . . . . . . . . . . . . . . . . . . . 24 - 6. Network address translation interaction . . . . . . . . . . . 28 - 7. Host implementations . . . . . . . . . . . . . . . . . . . . . 29 - 8. Multi-homing . . . . . . . . . . . . . . . . . . . . . . . . . 30 - 9. Failure modes . . . . . . . . . . . . . . . . . . . . . . . . 32 - 10. Unresolved issues . . . . . . . . . . . . . . . . . . . . . . 34 - 11. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 - 12. Security considerations . . . . . . . . . . . . . . . . . . . 42 - 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 44 - 14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45 - Normative references . . . . . . . . . . . . . . . . . . . . . 46 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 47 - Full Copyright Statement . . . . . . . . . . . . . . . . . . . 48 - - - - - - - - - - - - - - - - - - - - - - - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 2] - -Internet-Draft opportunistic May 2003 - - -1. Introduction - -1.1 Motivation - - The objective of opportunistic encryption is to allow encryption - without any pre-arrangement specific to the pair of systems involved. - Each system administrator adds public key information to DNS records - to support opportunistic encryption and then enables this feature in - the nodes' IPsec stack. Once this is done, any two such nodes can - communicate securely. - - This document describes opportunistic encryption as designed and - 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. - - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 3] - -Internet-Draft opportunistic May 2003 - - -1.2 Types of network traffic - - To aid in understanding the relationship between security processing - and IPsec we divide network traffic into four categories: - - * Deny: networks to which traffic is always forbidden. - - * Permit: networks to which traffic in the clear is permitted. - - * Opportunistic tunnel: networks to which traffic is encrypted if - possible, but otherwise is in the clear or fails depending on the - default policy in place. - - * Configured tunnel: networks to which traffic must be encrypted, and - traffic in the clear is never permitted. - - 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. - -1.3 Peer authentication in opportunistic encryption - - Opportunistic encryption creates tunnels between nodes that are - essentially strangers. This is done without any prior bilateral - arrangement. 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. - - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 4] - -Internet-Draft opportunistic May 2003 - - - 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. - -1.4 Use of RFC2119 terms - - The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, - SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this - document, are to be interpreted as described in [5] - - - - - - - - - - - - - - - - - - - - - - - - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 5] - -Internet-Draft opportunistic May 2003 - - -2. Overview - -2.1 Reference diagram - - --------------------------------------------------------------------- - - The following network diagram is used in the rest of this document as - the canonical diagram: - - [Q] [R] - . . AS2 - [A]----+----[SG-A].......+....+.......[SG-B]-------[B] - | ...... - AS1 | ..PI.. - | ...... - [D]----+----[SG-D].......+....+.......[C] AS3 - - - - Figure 1: Reference Network Diagram - - --------------------------------------------------------------------- - - In this diagram, there are four end-nodes: A, B, C and D. There are - three gateways, SG-A, SG-B, SG-D. A, D, SG-A and SG-D are part of - the same administrative authority, AS1. SG-A and SG-D are on two - different exit paths from organization 1. SG-B/B is an independent - organization, AS2. Nodes Q and R are nodes on the Internet. PI is - the Public Internet ("The Wild"). - -2.2 Terminology - - The following terminology is used in this document: - - Security gateway: a system that performs IPsec tunnel mode - encapsulation/decapsulation. [SG-x] in the diagram. - - Alice: node [A] in the diagram. When an IP address is needed, this - is 192.1.0.65. - - Bob: node [B] in the diagram. When an IP address is needed, this is - 192.2.0.66. - - Carol: node [C] in the diagram. When an IP address is needed, this - is 192.1.1.67. - - Dave: node [D] in the diagram. When an IP address is needed, this is - 192.3.0.68. - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 6] - -Internet-Draft opportunistic May 2003 - - - SG-A: Alice's security gateway. Internally it is 192.1.0.1, - externally it is 192.1.1.4. - - SG-B: Bob's security gateway. Internally it is 192.2.0.1, externally - it is 192.1.1.5. - - SG-D: Dave's security gateway. Also Alice's backup security gateway. - Internally it is 192.3.0.1, externally it is 192.1.1.6. - - - A single dash represents clear-text datagrams. - - = An equals sign represents phase 2 (IPsec) cipher-text datagrams. - - ~ A single tilde represents clear-text phase 1 datagrams. - - # A hash sign represents phase 1 (IKE) cipher-text datagrams. - - . A period represents an untrusted network of unknown type. - - Configured tunnel: a tunnel that is directly and deliberately hand - configured on participating gateways. Configured tunnels are - typically given a higher level of trust than opportunistic - tunnels. - - Road warrior tunnel: a configured tunnel connecting one node with a - fixed IP address and one node with a variable IP address. A road - warrior (RW) connection must be initiated by the variable node, - since the fixed node cannot know the current address for the road - warrior. - - Anonymous encryption: the process of encrypting a session without any - knowledge of who the other parties are. No authentication of - identities is done. - - Opportunistic encryption: the process of encrypting a session with - authenticated knowledge of who the other parties are. - - Lifetime: the period in seconds (bytes or datagrams) for which a - security association will remain alive before needing to be re- - keyed. - - Lifespan: the effective time for which a security association remains - useful. A security association with a lifespan shorter than its - lifetime would be removed when no longer needed. A security - association with a lifespan longer than its lifetime would need to - be re-keyed one or more times. - - Phase 1 SA: an ISAKMP/IKE security association sometimes referred to - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 7] - -Internet-Draft opportunistic May 2003 - - - as a keying channel. - - Phase 2 SA: an IPsec security association. - - Tunnel: another term for a set of phase 2 SA (one in each direction). - - NAT: Network Address Translation (see [20]). - - NAPT: Network Address and Port Translation (see [20]). - - AS: an autonomous system (AS) is a group of systems (a network) that - are under the administrative control of a single organization. - - Default-free zone: a set of routers that maintain a complete set of - routes to all currently reachable destinations. Having such a - list, these routers never make use of a default route. A datagram - with a destination address not matching any route will be dropped - by such a router. - - -2.3 Model of operation - - The opportunistic encryption security gateway (OE gateway) is a - regular gateway node as described in [2] section 2.4 and [3] with 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. - -2.3.1 Tunnel authorization - - The OE gateway determines whether or not to create a tunnel based on - the destination address of each packet. Upon receiving a packet with - a destination address not recently seen, the OE gateway performs a - lookup in DNS for an authorization resource record (see Section 5.2). - The record is located using the IP address to perform a search in the - in-addr.arpa (IPv4) or ip6.arpa (IPv6) maps. If an authorization - record is found, the OE gateway interprets this as a request for a - tunnel to be formed. - -2.3.2 Tunnel end-point discovery - - 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 - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 8] - -Internet-Draft opportunistic May 2003 - - - 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]). Section 3.2.4.1 documents an optional restriction - on the tunnel end point if DNSSEC signatures are not available for - the relevant records. - -2.3.3 Caching of authorization results - - The OE gateway maintains a cache, in the forwarding plane, of source/ - destination pairs for which opportunistic encryption has been - attempted. This cache maintains a record of whether or not OE was - successful so that subsequent datagrams can be forwarded properly - without additional delay. - - Successful negotiation of OE 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 Section 3.4. - This removes entries that are no longer being used and permits the - discovery of changes in authorization policy. - - - - - - - - - - - - - - - - - - - - - - - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 9] - -Internet-Draft opportunistic May 2003 - - -3. Specification - - 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. - -3.1 Datagram state machine - - 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. - -3.1.1 Non-existent policy - - 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. - -3.1.2 Hold policy - - 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. - - - - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 10] - -Internet-Draft opportunistic May 2003 - - -3.1.3 Pass-through policy - - 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. - -3.1.4 Deny policy - - 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). - -3.1.5 Encrypt policy - - 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. - -3.2 Keying state machine - initiator - - Let the keying daemon maintain a collection of objects. Let them be - called "connections" or "conn"s. There are two categories of - connection objects: classes and instances. A class represents an - abstract policy - 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 - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 11] - -Internet-Draft opportunistic May 2003 - - - 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. - -3.2.1 Nonexistent connection - - 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. - - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 12] - -Internet-Draft opportunistic May 2003 - - -3.2.2 Clear-text connection - - 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 Section 3.2.7). - -3.2.3 Deny 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 Section 3.2.7). - -3.2.4 Potential OE 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 - Section 5.2). The lookup key is the destination address of the flow. - - There are three ways to exit this state: - - 1. DNS lookup finds a TXT delegation resource record. - - 2. DNS lookup does not find a TXT delegation resource record. - - 3. DNS lookup times out. - - Based upon the results of the DNS lookup, the potential OE connection - makes a transition to the pending OE connection state. The - conditions for a successful DNS look are: - - 1. DNS finds an appropriate resource record - - 2. It is properly formatted according to Section 5.2 - - 3. if DNSSEC is enabled, then the signature has been vouched for. - - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 13] - -Internet-Draft opportunistic May 2003 - - - 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. - -3.2.4.1 Restriction on unauthenticated TXT delegation records - - An implementation SHOULD also provide an additional administrative - control on delegation records and DNSSEC. This control would apply - to delegation records (the TXT records in the reverse-map) that are - not protected by DNSSEC. Records of this type are only permitted to - delegate to their own address as a gateway. When this option is - enabled, an active attack on DNS will be unable to redirect packets - to other than the original destination. - -3.2.5 Pending OE connection - - 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 - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 14] - -Internet-Draft opportunistic May 2003 - - - 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.) - -3.2.6 Keyed connection - - 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. - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 15] - -Internet-Draft opportunistic May 2003 - - - 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. - -3.2.7 Expiring connection - - The initiator will periodically place each of the deny, clear-text, - and keyed connections into this sub-state. See Section 3.4 for more - details of how often this occurs. The initiator queries the - forwarding plane for last use time of the appropriate policy. If the - last use time is relatively recent, then the connection returns to - the previous deny, clear-text or keyed connection state. If not, - then the connection enters the expired connection state. - - The DNS query and answer that lead to the expiring connection state - are also examined. The DNS query may become stale. (A negative, - i.e. no such record, answer is valid for the period of time given by - the MINIMUM field in an attached SOA record. See [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. - -3.2.8 Expired connection - - 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 - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 16] - -Internet-Draft opportunistic May 2003 - - - plane is deleted. - - The initiator sends an ISAKMP/IKE delete to clean up the phase 2 SAs - as described in Section 3.4. - - Whether or not to delete the phase 1 SAs at this time is left as a - local implementation issue. Implementations that do delete the phase - 1 SAs MUST send authenticated delete messages to indicate that they - are doing so. There is an advantage to keeping the phase 1 SAs until - they expire - they may prove useful again in the near future. - -3.3 Keying state machine - responder - - 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. - -3.3.1 Unauthenticated OE peer - - 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. - -3.3.2 Authenticated OE Peer - - 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 - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 17] - -Internet-Draft opportunistic May 2003 - - - 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. - -3.4 Renewal and teardown - -3.4.1 Aging - - A potentially unlimited number of tunnels may exist. In practice, - only a few tunnels are used during a period of time. Unused tunnels - MUST, therefore, be torn down. Detecting when 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. - - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 18] - -Internet-Draft opportunistic May 2003 - - - The expiring state in the key management system (see Section 3.2.7) - 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. - -3.4.2 Teardown and cleanup - - 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.) - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 19] - -Internet-Draft opportunistic May 2003 - - - 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 20] - -Internet-Draft opportunistic May 2003 - - -4. Impacts on IKE - -4.1 ISAKMP/IKE protocol - - The IKE wire protocol needs no modifications. The major changes are - implementation issues relating to how the proposals are interpreted, - and from whom they may come. - - As opportunistic encryption is designed to be useful between peers - without prior operator configuration, an IKE daemon must be prepared - to negotiate phase 1 SAs with any node. This may require a large - amount of resources to maintain cookie state, as well as large - amounts of entropy 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. - -4.2 Gateway discovery process - - 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. - -4.3 Self identification - - 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 Section - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 21] - -Internet-Draft opportunistic May 2003 - - - 5.3 for more details and restrictions. - -4.4 Public key retrieval process - - Upon receipt of a phase 1 SA proposal with either an IPv4 (IPv6) ID - or an FQDN ID, an IKE daemon 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. - -4.5 Interactions with DNSSEC - - 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. - -4.6 Required proposal types - -4.6.1 Phase 1 parameters - - Main mode MUST be used. - - The initiator MUST offer at least one proposal using some combination - of: 3DES, HMAC-MD5 or HMAC-SHA1, DH group 2 or 5. Group 5 SHOULD be - proposed first. [11] - - The initiator MAY offer additional proposals, but the cipher MUST not - be weaker than 3DES. The initiator SHOULD limit the number of - proposals such that the IKE datagrams do not need to be fragmented. - - The responder MUST accept one of the proposals. If any configuration - of the responder is required then the responder is not acting in an - opportunistic way. - - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 22] - -Internet-Draft opportunistic May 2003 - - - SG-A SHOULD use an ID_IPV4_ADDR (ID_IPV6_ADDR for IPv6) of the - external interface of SG-A for phase 1. (There is an exception, see - Section 5.3.) The authentication method MUST be RSA public key - signatures. The RSA key for SG-A SHOULD be placed into a DNS KEY - record in the reverse space of SG-A (i.e. using in-addr.arpa). - -4.6.2 Phase 2 parameters - - SG-A MUST propose a tunnel between Alice and Bob, using 3DES-CBC - mode, MD5 or SHA1 authentication. Perfect Forward Secrecy MUST be - specified. - - Tunnel mode MUST be used. - - 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 23] - -Internet-Draft opportunistic May 2003 - - -5. DNS issues - -5.1 Use of KEY record - - 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: - - KEY 0x4200 4 1 AQNJjkKlIk9...nYyUkKK8 - - 0x4200: The flag bits, indicating that this key is prohibited for - confidentiality use (it authenticates the peer only, a separate - Diffie-Hellman exchange is used for confidentiality), and that - this key is associated with the non-zone entity whose name is the - RR owner name. No other flags are set. - - 4: This indicates that this key is for use by IPsec. - - 1: An RSA key is present. - - AQNJjkKlIk9...nYyUkKK8: The public key of the host as described in - [17]. - - 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. - -5.2 Use of TXT delegation record - - 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: - - S.R.Q.P.in-addr.arpa - - 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.) - - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 24] - -Internet-Draft opportunistic May 2003 - - - --------------------------------------------------------------------- - - - X-IPsec-Server(P)=A.B.C.D KEY - - Figure 2: Format of reverse delegation record - - --------------------------------------------------------------------- - - P: Specifies a precedence for this record. This is similar to MX - record preferences. Lower numbers have stronger preference. - - A.B.C.D: Specifies the IP address of the Security Gateway for this - client machine. - - 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 - - Figure 3: Format of reverse delegation record (FQDN version) - - --------------------------------------------------------------------- - - P: Is as above. - - FQDN: Specifies the FQDN that the Security Gateway will identify - itself with. - - KEY: Is the encoded RSA Public key of the Security Gateway. - - If there is more than one such TXT record with strongest (lowest - numbered) precedence, one Security Gateway is picked arbitrarily from - those specified in the strongest-preference records. - - - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 25] - -Internet-Draft opportunistic May 2003 - - -5.2.1 Long TXT 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. - -5.2.2 Choice of TXT record - - 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. - -5.3 Use of FQDN IDs - - 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 - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 26] - -Internet-Draft opportunistic May 2003 - - - 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 Figure 3. - -5.4 Key roll-over - - 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. - - - - - - - - - - - - - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 27] - -Internet-Draft opportunistic May 2003 - - -6. Network address translation interaction - - 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. - -6.1 Co-located NAT/NAPT - - If SG-A is also performing network address translation on behalf of - Alice, then the packet should be translated prior to being subjected - to opportunistic encryption. This is in contrast to 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. - -6.2 SG-A behind NAT/NAPT - - If there is a NAT or NAPT between SG-A and SG-B, then normal IPsec - NAT traversal rules 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. - -6.3 Bob is behind a NAT/NAPT - - If Bob is behind a NAT (perhaps SG-B), then there is, in fact, no way - for Alice to address a packet to Bob. Not only is opportunistic - encryption impossible, but it is also impossible for Alice to - initiate any communication to Bob. It may be possible for Bob to - initiate in such a situation. This creates an asymmetry, but this is - common for NAPT. - - - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 28] - -Internet-Draft opportunistic May 2003 - - -7. Host implementations - - 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 29] - -Internet-Draft opportunistic May 2003 - - -8. Multi-homing - - 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 Figure 1, Alice has two ways to exit her network: SG-A and SG-D. - Previously SG-D has been ignored. Postulate that there are routers - between Alice and her set of security gateways (denoted by the + - signs and the marking of an autonomous system number for Alice's - network). Datagrams may, therefore, travel to either SG-A or SG-D en - route to Bob. - - As long as all network connections are in good order, it does not - matter how datagrams exit Alice's network. When they reach either - security gateway, the security gateway will find the TXT delegation - record in Bob's reverse-map, and establish an SA with SG-B. - - SG-B has no problem establishing that either of SG-A or SG-D may - speak for Alice, because Alice has published two equally weighted TXT - delegation records: - - --------------------------------------------------------------------- - - - X-IPsec-Server(10)=192.1.1.5 AQMM...3s1Q== - X-IPsec-Server(10)=192.1.1.6 AAJN...j8r9== - - Figure 4: Multiple gateway delegation example for Alice - - --------------------------------------------------------------------- - - Alice's routers can now do any kind of load sharing needed. Both SG- - A and SG-D send datagrams addressed to Bob through their tunnel to - SG-B. - - Alice's use of non-equal weight delegation records to show preference - of one gateway over another, has relevance only when SG-B is - initiating to Alice. - - If the precedences are the same, then SG-B has a more difficult time. - It must decide which of the two tunnels to use. SG-B has no - information about which link is less loaded, nor which security - gateway has more cryptographic resources available. SG-B, in fact, - has no knowledge of whether both gateways are even reachable. - - The Public Internet's default-free zone may well know a good route to - Alice, but the datagrams that SG-B creates must be addressed to - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 30] - -Internet-Draft opportunistic May 2003 - - - either SG-A or SG-D; they can not be addressed to Alice directly. - - SG-B may make a number of choices: - - 1. It can ignore the problem and round robin among the tunnels. - This causes losses during times when one or the other security - gateway is unreachable. If this worries Alice, she can change - the weights in her TXT delegation records. - - 2. It can send to the gateway from which it most recently received - datagrams. This assumes that routing and reachability are - symmetrical. - - 3. It can listen to BGP information from the Internet to decide - which system is currently up. This is clearly much more - complicated, but if SG-B is already participating in the BGP - peering system to announce Bob, the results data may already be - available to it. - - 4. It can refuse to negotiate the second tunnel. (It is unclear - whether or not this is even an option.) - - 5. It can silently replace the outgoing portion of the first tunnel - with the second one while still retaining the incoming portions - of both. 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. - - - - - - - - - - - - - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 31] - -Internet-Draft opportunistic May 2003 - - -9. Failure modes - -9.1 DNS failures - - 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 Section 3.2. It is easy to mount a denial of service - attack on the DNS server responsible for a particular network's - reverse-map. Such an attack may cause all communication with that - network to go in the clear if the policy is permissive, or fail - completely if the policy is paranoid. Please note that this is an - active attack. - - There are still many networks that do not have properly configured - reverse-maps. Further, if the policy is not to communicate, the - above denial of service attack isolates the target network. - Therefore, the decision of whether or not to permit communication in - the clear MUST be a matter of local policy. - -9.2 DNS configured, IKE failures - - 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. - -9.3 System reboots - - 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 - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 32] - -Internet-Draft opportunistic May 2003 - - - 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 33] - -Internet-Draft opportunistic May 2003 - - -10. Unresolved issues - -10.1 Control of reverse DNS - - 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 34] - -Internet-Draft opportunistic May 2003 - - -11. Examples - -11.1 Clear-text usage (permit policy) - - 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)-----> - --------------> - <--------------- - <------------------- - <------------- - - Figure 5: 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.) - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 35] - -Internet-Draft opportunistic May 2003 - - - (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. - - -11.2 Opportunistic encryption - - In the presence of properly configured opportunistic encryptors, the - event list is extended. - - --------------------------------------------------------------------- - - - Alice SG-A DNS SG-B Bob - (1) - ------(2)--------------> - <-----(3)--------------- - (4)----(5)----->+ - ----(5B)-> - <---(5C)-- - ~~~~~~~~~~~~~(5D)~~~> - <~~~~~~~~~~~~(5E1)~~~ - ~~~~~~~~~~~~~(5E2)~~> - <~~~~~~~~~~~~(5E3)~~~ - #############(5E4)##> - <############(5E5)### - <----(5F1)-- - -----(5F2)-> - #############(5G1)##> - <----(5H1)-- - -----(5H2)-> - <############(5G2)### - #############(5G3)##> - ============(6)====> - ------(7)-----> - <------(8)------ - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 36] - -Internet-Draft opportunistic May 2003 - - - <==========(9)====== - <-----(10)---- - (11)-----------> - ==========(12)=====> - --------------> - <--------------- - <=================== - <------------- - - Figure 6: Timing of opportunistic encryption transaction - - --------------------------------------------------------------------- - - (1) Human or application clicks with a name. - - (2) Application initiates DNS mapping. - - (3) Resolver returns A record to application. - - (4) Application starts a TCP session or UDP. - - (5) SG-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. - - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 37] - -Internet-Draft opportunistic May 2003 - - - (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 Figure 5 and Figure 6. This corresponds to time - points 5, 6, 7, 9 and 10 on the list above. - -11.2.1 (5) IPsec datagram interception - - 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. - -11.2.2 (5B) DNS lookup for TXT record - - 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. - -11.2.3 (5C) DNS returns TXT record(s) - - 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== - - Figure 7: Example of reverse delegation record for Bob - - --------------------------------------------------------------------- - - with SG-B's IP address and public key listed. - -11.2.4 (5D) Initial IKE main mode packet goes out - - Upon entering Pending OE connection, SG-A sends the initial ISAKMP - message with proposals. See Section 4.6.1. - -11.2.5 (5E1) Message 2 of phase 1 exchange - - SG-B receives the message. A new connection instance is created in - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 38] - -Internet-Draft opportunistic May 2003 - - - the unauthenticated OE peer state. - -11.2.6 (5E2) Message 3 of phase 1 exchange - - SG-A sends a Diffie-Hellman exponent. This is an internal state of - the keying daemon. - -11.2.7 (5E3) Message 4 of phase 1 exchange - - SG-B responds with a Diffie-Hellman exponent. This is an internal - state of the keying protocol. - -11.2.8 (5E4) Message 5 of phase 1 exchange - - SG-A uses the phase 1 SA to send its identity under encryption. The - choice of identity is discussed in Section 4.6.1. This is an - internal state of the keying protocol. - -11.2.9 (5F1) Responder lookup of initiator key - - SG-B asks DNS for the public key of the initiator. 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 Section 5.1 for further details. - -11.2.10 (5F2) DNS replies with public key of initiator - - Upon successfully authenticating the peer, the connection instance - makes a transition to authenticated OE peer on SG-B. - - The format of the TXT record returned is described in Section 5.2. - -11.2.11 (5E5) Responder replies with ID and authentication - - SG-B sends its ID along with authentication material. This is an - internal state for the keying protocol. - -11.2.12 (5G) IKE phase 2 - -11.2.12.1 (5G1) Initiator proposes tunnel - - Having established mutually agreeable authentications (via KEY) and - authorizations (via TXT), SG-A proposes to create an IPsec tunnel for - datagrams transiting from Alice to Bob. This tunnel is established - only for the Alice/Bob combination, not for any subnets that may be - behind SG-A and SG-B. - - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 39] - -Internet-Draft opportunistic May 2003 - - -11.2.12.2 (5H1) Responder determines initiator's authority - - While the identity of SG-A has been established, its authority to - speak for Alice has not yet been confirmed. 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. - -11.2.12.3 (5H2) DNS replies with TXT record(s) - - The returned key and IP address should match that of SG-A. - -11.2.12.4 (5G2) Responder agrees to proposal - - Should additional communication occur between, for instance, Dave and - Bob 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. - -11.2.12.5 (5G3) Final acknowledgment from initiator - - The initiator agrees with the responder's choice and sets up the - tunnel. The initiator sets up the inbound and outbound IPsec SAs. - - The proper authorization returned with keys prompts SG-B to make a - transition to the keyed OE connection state. - - Upon receipt of this message, the responder may now setup the - outbound IPsec SAs. - -11.2.13 (6) IPsec succeeds, and sets up tunnel for communication between - Alice and Bob - - SG-A sends the datagram saved at step (5) through the newly created - tunnel to SG-B, where it gets decrypted and forwarded. Bob receives - it at (7) and replies at (8). - -11.2.14 (9) SG-B already has tunnel up with G1 and uses it - - At (9), SG-B has already established an SPD entry mapping Bob->Alice - via a tunnel, so this tunnel is simply applied. The datagram is - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 40] - -Internet-Draft opportunistic May 2003 - - - encrypted to SG-A, decrypted by SG-A and passed to Alice at (10). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 41] - -Internet-Draft opportunistic May 2003 - - -12. Security considerations - -12.1 Configured vs opportunistic tunnels - - Configured tunnels are those which are setup using bilateral - mechanisms: exchanging public keys (raw RSA, DSA, PKIX), pre-shared - secrets, or by referencing keys that are in known places - (distinguished name from LDAP, DNS). These keys are then used to - configure a specific tunnel. - - A pre-configured tunnel may be on all the time, or may be keyed only - when needed. The end points of the tunnel are not necessarily - static: many mobile applications (road warrior) are considered to be - configured tunnels. - - The primary 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. - - - - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 42] - -Internet-Draft opportunistic May 2003 - - -12.2 Firewalls versus Opportunistic Tunnels - - 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. - -12.3 Denial of service - - 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. - - - - - - - - - - - - - - - - - - - - - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 43] - -Internet-Draft opportunistic May 2003 - - -13. IANA Considerations - - There are no known numbers which IANA will need to manage. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 44] - -Internet-Draft opportunistic May 2003 - - -14. Acknowledgments - - 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. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 45] - -Internet-Draft opportunistic May 2003 - - -Normative references - - [1] Redelmeier, D. and H. Spencer, "Opportunistic Encryption", - paper http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/ - opportunism.spec, May 2001. - - [2] Defense Advanced Research Projects Agency (DARPA), Information - Processing Techniques Office and 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. - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 46] - -Internet-Draft opportunistic May 2003 - - - [15] Rosenbaum, R., "Using the Domain Name System To Store Arbitrary - String Attributes", RFC 1464, May 1993. - - [16] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [17] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name - System (DNS)", RFC 3110, May 2001. - - [18] Eastlake, D. and O. Gudmundsson, "Storing Certificates in the - Domain Name System (DNS)", RFC 2538, March 1999. - - [19] Durham, D., Boyle, J., Cohen, R., Herzog, S., Rajan, R. and A. - Sastry, "The COPS (Common Open Policy Service) Protocol", RFC - 2748, January 2000. - - [20] Srisuresh, P. and M. Holdrege, "IP Network Address Translator - (NAT) Terminology and Considerations", RFC 2663, August 1999. - - -Authors' Addresses - - Michael C. Richardson - Sandelman Software Works - 470 Dawson Avenue - Ottawa, ON K1Z 5V7 - CA - - EMail: mcr@sandelman.ottawa.on.ca - URI: http://www.sandelman.ottawa.on.ca/ - - - D. Hugh Redelmeier - Mimosa - Toronto, ON - CA - - EMail: hugh@mimosa.com - - - - - - - - - - - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 47] - -Internet-Draft opportunistic May 2003 - - -Full Copyright Statement - - 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. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Richardson & Redelmeier Expires November 19, 2003 [Page 48] - diff --git a/doc/draft-richardson-ipsec-rr.txt b/doc/draft-richardson-ipsec-rr.txt deleted file mode 100644 index 7c229b8e1..000000000 --- a/doc/draft-richardson-ipsec-rr.txt +++ /dev/null @@ -1,840 +0,0 @@ - - -IPSECKEY WG M. Richardson -Internet-Draft SSW -Expires: March 4, 2004 September 4, 2003 - - - A method for storing IPsec keying material in DNS. - draft-ietf-ipseckey-rr-07.txt - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - Internet-Drafts are working documents of the Internet Engineering - Task Force (IETF), its areas, and its working groups. Note that - other groups may also distribute working documents as Internet- - Drafts. - - Internet-Drafts are draft documents valid for a maximum of six months - and may be updated, replaced, or obsoleted by other documents at any - time. It is inappropriate to use Internet-Drafts as reference - material or to cite them other than as "work in progress." - - The list of current Internet-Drafts can be accessed at http:// - www.ietf.org/ietf/1id-abstracts.txt. - - The list of Internet-Draft Shadow Directories can be accessed at - http://www.ietf.org/shadow.html. - - This Internet-Draft will expire on March 4, 2004. - -Copyright Notice - - Copyright (C) The Internet Society (2003). All Rights Reserved. - -Abstract - - This document describes a new resource record for DNS. This record - may be used to store public keys for use in IPsec systems. - - This record replaces the functionality of the sub-type #1 of the KEY - Resource Record, which has been obsoleted by RFC3445. - - - - - - - - - - -Richardson Expires March 4, 2004 [Page 1] - -Internet-Draft ipsecrr September 2003 - - -Table of Contents - - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 1.2 Usage Criteria . . . . . . . . . . . . . . . . . . . . . . . . 3 - 2. Storage formats . . . . . . . . . . . . . . . . . . . . . . . 4 - 2.1 IPSECKEY RDATA format . . . . . . . . . . . . . . . . . . . . 4 - 2.2 RDATA format - precedence . . . . . . . . . . . . . . . . . . 4 - 2.3 RDATA format - algorithm type . . . . . . . . . . . . . . . . 4 - 2.4 RDATA format - gateway type . . . . . . . . . . . . . . . . . 4 - 2.5 RDATA format - gateway . . . . . . . . . . . . . . . . . . . . 5 - 2.6 RDATA format - public keys . . . . . . . . . . . . . . . . . . 5 - 3. Presentation formats . . . . . . . . . . . . . . . . . . . . . 7 - 3.1 Representation of IPSECKEY RRs . . . . . . . . . . . . . . . . 7 - 3.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 - 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 - 4.1 Active attacks against unsecured IPSECKEY resource records . . 9 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 - 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 - Normative references . . . . . . . . . . . . . . . . . . . . . 13 - Non-normative references . . . . . . . . . . . . . . . . . . . 14 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 - Full Copyright Statement . . . . . . . . . . . . . . . . . . . 15 - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Richardson Expires March 4, 2004 [Page 2] - -Internet-Draft ipsecrr September 2003 - - -1. Introduction - - The type number for the IPSECKEY RR is TBD. - -1.1 Overview - - The IPSECKEY resource record (RR) is used to publish a public key - that is to be associated with a Domain Name System (DNS) name for use - with the IPsec protocol suite. This can be the public key of a - host, network, or application (in the case of per-port keying). - - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", - "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC2119 [8]. - -1.2 Usage Criteria - - An IPSECKEY resource record SHOULD be used in combination with DNSSEC - unless some other means of authenticating the IPSECKEY resource - record is available. - - It is expected that there will often be multiple IPSECKEY resource - records at the same name. This will be due to the presence of - multiple gateways and the need to rollover keys. - - This resource record is class independent. - - - - - - - - - - - - - - - - - - - - - - - - - -Richardson Expires March 4, 2004 [Page 3] - -Internet-Draft ipsecrr September 2003 - - -2. Storage formats - -2.1 IPSECKEY RDATA format - - The RDATA for an IPSECKEY RR consists of a precedence value, a public - key, algorithm type, and an optional gateway address. - - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | precedence | gateway type | algorithm | gateway | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+ + - ~ gateway ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | / - / public key / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| - - -2.2 RDATA format - precedence - - This is an 8-bit precedence for this record. This is interpreted in - the same way as the PREFERENCE field described in section 3.3.9 of - RFC1035 [2]. - - Gateways listed in IPSECKEY records with lower precedence are to be - attempted first. Where there is a tie in precedence, the order - should be non-deterministic. - -2.3 RDATA format - algorithm type - - The algorithm type field identifies the public key's cryptographic - algorithm and determines the format of the public key field. - - A value of 0 indicates that no key is present. - - The following values are defined: - - 1 A DSA key is present, in the format defined in RFC2536 [11] - - 2 A RSA key is present, in the format defined in RFC3110 [12] - - -2.4 RDATA format - gateway type - - The gateway type field indicates the format of the information that - is stored in the gateway field. - - - -Richardson Expires March 4, 2004 [Page 4] - -Internet-Draft ipsecrr September 2003 - - - The following values are defined: - - 0 No gateway is present - - 1 A 4-byte IPv4 address is present - - 2 A 16-byte IPv6 address is present - - 3 A wire-encoded domain name is present. The wire-encoded format is - self-describing, so the length is implicit. The domain name MUST - NOT be compressed. - - -2.5 RDATA format - gateway - - The gateway field indicates a gateway to which an IPsec tunnel may be - created in order to reach the entity named by this resource record. - - There are three formats: - - A 32-bit IPv4 address is present in the gateway field. The data - portion is an IPv4 address as described in section 3.4.1 of RFC1035 - [2]. This is a 32-bit number in network byte order. - - A 128-bit IPv6 address is present in the gateway field. The data - portion is an IPv6 address as described in section 2.2 of RFC1886 - [7]. This is a 128-bit number in network byte order. - - The gateway field is a normal wire-encoded domain name, as described - in section 3.3 of RFC1035 [2]. Compression MUST NOT be used. - -2.6 RDATA format - public keys - - Both of the public key types defined in this document (RSA and DSA) - inherit their public key formats from the corresponding KEY RR - formats. Specifically, the public key field contains the algorithm- - specific portion of the KEY RR RDATA, which is all of the KEY RR DATA - after the first four octets. This is the same portion of the KEY RR - that must be specified by documents that define a DNSSEC algorithm. - Those documents also specify a message digest to be used for - generation of SIG RRs; that specification is not relevant for - IPSECKEY RR. - - Future algorithms, if they are to be used by both DNSSEC (in the KEY - RR) and IPSECKEY, are likely to use the same public key encodings in - both records. Unless otherwise specified, the IPSECKEY public key - field will contain the algorithm-specific portion of the KEY RR RDATA - for the corresponding algorithm. The algorithm must still be - - - -Richardson Expires March 4, 2004 [Page 5] - -Internet-Draft ipsecrr September 2003 - - - designated for use by IPSECKEY, and an IPSECKEY algorithm type number - (which might be different than the DNSSEC algorithm number) must be - assigned to it. - - The DSA key format is defined in RFC2536 [11] - - The RSA key format is defined in RFC3110 [12], with the following - changes: - - The earlier definition of RSA/MD5 in RFC2065 limited the exponent and - modulus to 2552 bits in length. RFC3110 extended that limit to 4096 - bits for RSA/SHA1 keys. The IPSECKEY RR imposes no length limit on - RSA public keys, other than the 65535 octet limit imposed by the two- - octet length encoding. This length extension is applicable only to - IPSECKEY and not to KEY RRs. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Richardson Expires March 4, 2004 [Page 6] - -Internet-Draft ipsecrr September 2003 - - -3. Presentation formats - -3.1 Representation of IPSECKEY RRs - - IPSECKEY RRs may appear in a zone data master file. The precedence, - gateway type and algorithm and gateway fields are REQUIRED. The - base64 encoded public key block is OPTIONAL; if not present, then the - public key field of the resource record MUST be construed as being - zero octets in length. - - The algorithm field is an unsigned integer. No mnemonics are - defined. - - If no gateway is to be indicated, then the gateway type field MUST be - zero, and the gateway field MUST be "." - - The Public Key field is represented as a Base64 encoding of the - Public Key. Whitespace is allowed within the Base64 text. For a - definition of Base64 encoding, see RFC1521 [3] Section 5.2. - - The general presentation for the record as as follows: - - IN IPSECKEY ( precedence gateway-type algorithm - gateway base64-encoded-public-key ) - - -3.2 Examples - - An example of a node 192.0.2.38 that will accept IPsec tunnels on its - own behalf. - - 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 - 192.0.2.38 - AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) - - An example of a node, 192.0.2.38 that has published its key only. - - 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 0 2 - . - AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) - - An example of a node, 192.0.2.38 that has delegated authority to the - node 192.0.2.3. - - 38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 - 192.0.2.3 - AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) - - - - -Richardson Expires March 4, 2004 [Page 7] - -Internet-Draft ipsecrr September 2003 - - - An example of a node, 192.0.1.38 that has delegated authority to the - node with the identity "mygateway.example.com". - - 38.1.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 3 2 - mygateway.example.com. - AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) - - An example of a node, 2001:0DB8:0200:1:210:f3ff:fe03:4d0 that has - delegated authority to the node 2001:0DB8:c000:0200:2::1 - - $ORIGIN 1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.int. - 0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN IPSECKEY ( 10 2 2 - 2001:0DB8:0:8002::2000:1 - AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Richardson Expires March 4, 2004 [Page 8] - -Internet-Draft ipsecrr September 2003 - - -4. Security Considerations - - This entire memo pertains to the provision of public keying material - for use by key management protocols such as ISAKMP/IKE (RFC2407) [9]. - - The IPSECKEY resource record contains information that SHOULD be - communicated to the end client in an integral fashion - i.e. free - from modification. The form of this channel is up to the consumer of - the data - there must be a trust relationship between the end - consumer of this resource record and the server. This relationship - may be end-to-end DNSSEC validation, a TSIG or SIG(0) channel to - another secure source, a secure local channel on the host, or some - combination of the above. - - The keying material provided by the IPSECKEY resource record is not - sensitive to passive attacks. The keying material may be freely - disclosed to any party without any impact on the security properties - of the resulting IPsec session: IPsec and IKE provide for defense - against both active and passive attacks. - - Any user of this resource record MUST carefully document their trust - model, and why the trust model of DNSSEC is appropriate, if that is - the secure channel used. - -4.1 Active attacks against unsecured IPSECKEY resource records - - This section deals with active attacks against the DNS. These - attacks require that DNS requests and responses be intercepted and - changed. DNSSEC is designed to defend against attacks of this kind. - - The first kind of active attack is when the attacker replaces the - keying material with either a key under its control or with garbage. - - If the attacker is not able to mount a subsequent man-in-the-middle - attack on the IKE negotiation after replacing the public key, then - this will result in a denial of service, as the authenticator used by - IKE would fail. - - If the attacker is able to both to mount active attacks against DNS - and is also in a position to perform a man-in-the-middle attack on - IKE and IPsec negotiations, then the attacker will be in a position - to compromise the resulting IPsec channel. Note that an attacker - must be able to perform active DNS attacks on both sides of the IKE - negotiation in order for this to succeed. - - The second kind of active attack is one in which the attacker - replaces the the gateway address to point to a node under the - attacker's control. The attacker can then either replace the public - - - -Richardson Expires March 4, 2004 [Page 9] - -Internet-Draft ipsecrr September 2003 - - - key or remove it, thus providing an IPSECKEY record of its own to - match the gateway address. - - This later form creates a simple man-in-the-middle since the attacker - can then create a second tunnel to the real destination. Note that, - as before, this requires that the attacker also mount an active - attack against the responder. - - Note that the man-in-the-middle can not just forward cleartext - packets to the original destination. While the destination may be - willing to speak in the clear, replying to the original sender, the - sender will have already created a policy expecting ciphertext. - Thus, the attacker will need to intercept traffic from both sides. - In some cases, the attacker may be able to accomplish the full - intercept by use of Network Addresss/Port Translation (NAT/NAPT) - technology. - - Note that the danger here only applies to cases where the gateway - field of the IPSECKEY RR indicates a different entity than the owner - name of the IPSECKEY RR. In cases where the end-to-end integrity of - the IPSECKEY RR is suspect, the end client MUST restrict its use of - the IPSECKEY RR to cases where the RR owner name matches the content - of the gateway field. - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Richardson Expires March 4, 2004 [Page 10] - -Internet-Draft ipsecrr September 2003 - - -5. IANA Considerations - - This document updates the IANA Registry for DNS Resource Record Types - by assigning type X to the IPSECKEY record. - - This document creates an IANA registry for the algorithm type field. - - Values 0, 1 and 2 are defined in Section 2.3. Algorithm numbers 3 - through 255 can be assigned by IETF Consensus (see RFC2434 [6]). - - This document creates an IANA registry for the gateway type field. - - Values 0, 1, 2 and 3 are defined in Section 2.4. Algorithm numbers 4 - through 255 can be assigned by Standards Action (see RFC2434 [6]). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Richardson Expires March 4, 2004 [Page 11] - -Internet-Draft ipsecrr September 2003 - - -6. Acknowledgments - - My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob - Austein, and Olafur Gurmundsson who reviewed this document carefully. - Additional thanks to Olafur Gurmundsson for a reference - implementation. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Richardson Expires March 4, 2004 [Page 12] - -Internet-Draft ipsecrr September 2003 - - -Normative references - - [1] Mockapetris, P., "Domain names - concepts and facilities", STD - 13, RFC 1034, November 1987. - - [2] Mockapetris, P., "Domain names - implementation and - specification", STD 13, RFC 1035, November 1987. - - [3] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail - Extensions) Part One: Mechanisms for Specifying and Describing - the Format of Internet Message Bodies", RFC 1521, September - 1993. - - [4] Bradner, S., "The Internet Standards Process -- Revision 3", BCP - 9, RFC 2026, October 1996. - - [5] Eastlake, D. and C. Kaufman, "Domain Name System Security - Extensions", RFC 2065, January 1997. - - [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA - Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Richardson Expires March 4, 2004 [Page 13] - -Internet-Draft ipsecrr September 2003 - - -Non-normative references - - [7] Thomson, S. and C. Huitema, "DNS Extensions to support IP - version 6", RFC 1886, December 1995. - - [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement - Levels", BCP 14, RFC 2119, March 1997. - - [9] Piper, D., "The Internet IP Security Domain of Interpretation - for ISAKMP", RFC 2407, November 1998. - - [10] Eastlake, D., "Domain Name System Security Extensions", RFC - 2535, March 1999. - - [11] Eastlake, D., "DSA KEYs and SIGs in the Domain Name System - (DNS)", RFC 2536, March 1999. - - [12] Eastlake, D., "RSA/SHA-1 SIGs and RSA KEYs in the Domain Name - System (DNS)", RFC 3110, May 2001. - - [13] Massey, D. and S. Rose, "Limiting the Scope of the KEY Resource - Record (RR)", RFC 3445, December 2002. - - -Author's Address - - 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/ - - - - - - - - - - - - - - - - - -Richardson Expires March 4, 2004 [Page 14] - -Internet-Draft ipsecrr September 2003 - - -Full Copyright Statement - - 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. - -Acknowledgement - - Funding for the RFC Editor function is currently provided by the - Internet Society. - - - - - - - - - - - - - - - - - - - -Richardson Expires March 4, 2004 [Page 15] - diff --git a/doc/draft-spencer-ipsec-ike-implementation.nr b/doc/draft-spencer-ipsec-ike-implementation.nr deleted file mode 100644 index 5b5776e22..000000000 --- a/doc/draft-spencer-ipsec-ike-implementation.nr +++ /dev/null @@ -1,1203 +0,0 @@ -.\" date, expiry date, copyright year, and revision -.DA "26 Feb 2002" -.ds e "26 Aug 2002 -.ds c 2002 -.ds r 02 -.\" boilerplate -.pl 10i -.nr PL 10i -.po 0 -.nr PO 0 -.ll 7.2i -.nr LL 7.2i -.lt 7.2i -.nr LT 7.2i -.hy 0 -.nr HY 0 -.ad l -.nr PD 1v -.\" macros for paragraph, section header, reference, TOC -.de P -.br -.LP -.in 3 -.. -.de H -.br -.ne 5 -.LP -.in 0 -.. -.de R -.IP " [\\$1]" 14 -.. -.de T -.ie \\$1=1 \{\ -.nf -.ta \n(LLu-3nR -.\} -.el \{\ -.fi -.\} -.. -.de S -.ie '\\$1'' \\$2 \a \\$3 -.el \\$1. \\$2 \a \\$3 -.. -.\" headers/footers -.ds LH "Internet Draft -.ds CH "IKE Implementation Issues -.ds RH "\*(DY -.ds LF "Spencer & Redelmeier -.ds CF " -.ds RF "[Page %] -.\" and let's get started -.RT -.nf -.tl 'Network Working Group''Henry Spencer' -.tl 'Internet Draft''SP Systems' -.tl 'Expires: \*e''D. Hugh Redelmeier' -.tl '''Mimosa Systems' -.tl '''\*(DY' -.sp -.ce 99 -IKE Implementation Issues -<draft-spencer-ipsec-ike-implementation-\*r.txt> -.ce 0 -.H -Status of this Memo -.P -This document is an Internet-Draft and is in full conformance with -all provisions of Section 10 of RFC2026. -.P -(If approved as an Informational RFC...) -This memo provides information for the Internet community. -This memo does not specify an Internet standard of any kind. -.P -Distribution of this memo is unlimited. -.P -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. -.P -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." -.P -The list of current Internet-Drafts can be accessed at -http://www.ietf.org/ietf/1id-abstracts.txt. -.P -The list of Internet-Draft Shadow Directories can be accessed at -http://www.ietf.org/shadow.html. -.P -This Internet-Draft will expire on \*e. -.H -Copyright Notice -.P -Copyright (C) The Internet Society \*c. All Rights Reserved. -.bp -.H -Table of Contents -.P -.T 1 -.S "1" "Introduction" "3" -.S "2" "Lower-level Background and Notes" "4" -.S "2.1" "Packet Handling" "4" -.S "2.2" "Ciphers" "5" -.S "2.3" "Interfaces" "5" -.S "3" "IKE Infrastructural Issues" "5" -.S "3.1" "Continuous Channel" "5" -.S "3.2" "Retransmission" "5" -.S "3.3" "Replay Prevention" "6" -.S "4" "Basic Keying and Rekeying" "7" -.S "4.1" "When to Create SAs" "7" -.S "4.2" "When to Rekey" "8" -.S "4.3" "Choosing an SA" "9" -.S "4.4" "Why to Rekey" "9" -.S "4.5" "Rekeying ISAKMP SAs" "10" -.S "4.6" "Bulk Negotiation" "10" -.S "5" "Deletions, Teardowns, Crashes" "11" -.S "5.1" "Deletions" "11" -.S "5.2" "Teardowns and Shutdowns" "12" -.S "5.3" "Crashes" "13" -.S "5.4" "Network Partitions" "13" -.S "5.5" "Unknown SAs" "14" -.S "6" "Misc. IKE Issues" "16" -.S "6.1" "Groups 1 and 5" "16" -.S "6.2" "To PFS Or Not To PFS" "16" -.S "6.3" "Debugging Tools, Lack Thereof" "16" -.S "6.4" "Terminology, Vagueness Thereof" "17" -.S "6.5" "A Question of Identity" "17" -.S "6.6" "Opportunistic Encryption" "17" -.S "6.7" "Authentication and RSA Keys" "17" -.S "6.8" "Misc. Snags" "18" -.S "7" "Security Considerations" "19" -.S "8" "References" "19" -.S "" "Authors' Addresses" "20" -.S "" "Full Copyright Statement" "21" -.T 0 -.bp -.H -Abstract -.P -The current IPsec specifications for key exchange and connection management, -RFCs 2408 [ISAKMP] and 2409 [IKE], -leave many aspects of connection management unspecified, -most prominently rekeying practices. -Pending clarifications in future revisions of the specifications, -this document sets down some successful experiences, -to minimize the extent to which new implementors have to rely -on unwritten folklore. -.P -The Linux FreeS/WAN implementation of IPsec interoperates -with almost every other IPsec implementation. -This document describes how the FreeS/WAN project has resolved -some of the gaps in the IPsec specifications -(and plans to resolve some others), -and what difficulties have been encountered, -in hopes that this generally-successful experience -might be informative to new implementors. -.P -This is offered as an Informational RFC. -.P -This -\*r revision mainly: -discusses ISAKMP SA expiry during IPsec-SA rekeying (4.5), -revises the discussion of bidirectional Deletes (5.1), -suggests remembering the parameters of successful negotiations -for later use (4.2, 5.3), -notes an unsuccessful negotiation from the other end as a hint of a possibly -broken connection (5.5), -and adds sections on network partitions (5.4), -authentication methods and the subtleties of RSA public keys (6.7), -and miscellaneous interoperability concerns (6.8). -.H -1. Introduction -.P -The current IPsec specifications for key exchange and connection management, -RFCs 2408 [ISAKMP] and 2409 [IKE], -leave many aspects of connection management unspecified, -most prominently rekeying practices. -This is a cryptic puzzle which -each group of implementors has to struggle with, -and differences in how the ambiguities and gaps are resolved are -potentially a fruitful source of interoperability problems. -We can hope that future revisions of the specifications will clear this up. -Meanwhile, it seems useful to set down some successful experiences, -to minimize the extent to which new implementors have to rely -on unwritten folklore. -.P -The Linux FreeS/WAN implementation of IPsec interoperates -with almost every other IPsec implementation, -and because of its free nature, -it also sees some use as a reference implementation by other implementors. -The high degree of interoperability is noteworthy -given its organizers' strong minimalist bias, -which has caused them to implement only -a small subset of the full glory of IPsec. -This document describes how the FreeS/WAN project has resolved -some of the gaps in the IPsec specifications -(and plans to resolve some others), -and what difficulties have been encountered, -in hopes that this generally-successful experience -might be informative to new implementors. -.P -One small caution about applicability: -this experience may not be relevant -to severely resource-constrained implementations. -FreeS/WAN's target environment is previous-generation PCs, -now available at trivial cost (often, -within an organization, at no cost), -which have quite impressive CPU power and memory by the standards -of only a few years ago. -Some of the approaches discussed here may be inapplicable to -implementations with severe external constraints which prevent them -from taking advantage of modern hardware technology. -.H -2. Lower-level Background and Notes -.H -2.1. Packet Handling -.P -FreeS/WAN implements ESP [ESP] and AH [AH] straightforwardly, -although AH sees little use among our users. -Our ESP/AH implementation cannot currently handle packets -with IP options; -somewhat surprisingly, this has caused little difficulty. -We insist on encryption and do not support authentication-only -connections, and this has not caused significant difficulty either. -.P -MTU and fragmentation issues, by contrast, have been a constant headache. -We will not describe the details of our current approach to them, -because it still needs work. -One difficulty we have encountered is that many combinations of -packet source and packet destination -apparently cannot cope with an "interior minimum" in the path MTU, -e.g. where an IPsec tunnel intervenes and its headers reduce the MTU -for an intermediate link. -This is particularly prevalent when using common PC software to -connect to large well-known web sites; -we think it is largely due to -misconfigured firewalls which do not pass ICMP -Fragmentation Required messages. -The only solution we have yet found is to lie about the MTU of the tunnel, -accepting the (undesirable) fragmentation of the ESP packets -for the sake of preserving connectivity. -.P -We currently zero out the TOS field of ESP packets, -rather than copying it from the inner header, -on the grounds that it lends itself too well to traffic analysis -and covert channels. -We provide an option to restore RFC 2401 [IPSEC] copying behavior, -but this appears to see little use. -.H -2.2. Ciphers -.P -We initially implemented both DES [DES] and 3DES [CIPHERS] for both -IKE and ESP, -but after the Deep Crack effort [CRACK] demonstrated its inherent insecurity, -we dropped support for DES. -Somewhat surprisingly, -our insistence on 3DES has caused almost no interoperability problems, -despite DES being officially mandatory. -A very few other systems either do not support 3DES or support it only -as an optional upgrade, -which inconveniences a few would-be users. -There have also been one or two cases of systems -which don't quite seem to know the difference! -.P -See also section 6.1 for a consequence of our insistence on 3DES. -.H -2.3. Interfaces -.P -We currently employ PF_KEY version 2 [PFKEY], -plus various non-standard extensions, -as our interface between keying and ESP. -This has not proven entirely satisfactory. -Our feeling now is that keying issues and policy issues -do not really lend -themselves to the clean separation that PF_KEY envisions. -.H -3. IKE Infrastructural Issues -.P -A number of problems in IPsec connection management become easier if -some attention is first paid to providing an infrastructure -to support solving them. -.H -3.1. Continuous Channel -.P -FreeS/WAN uses an approximation to the "continuous channel" model, -in which ISAKMP SAs are maintained between IKEs -so long as any IPsec SAs are open between the two systems. -The resource consumption of this is minor: -the only substantial overhead is occasional rekeying. -IPsec SA management becomes significantly simpler if there is always -a channel for transmission of control messages. -We suggest (although we do not yet fully implement this) that -inability to maintain (e.g., to rekey) this control path -should be grounds for tearing down the IPsec SAs as well. -.P -As a corollary of this, -there is one and only one ISAKMP SA maintained between a pair of IKEs -(although see sections 5.3 and 6.5 for minor complications). -.H -3.2. Retransmission -.P -The unreliable nature of UDP transmission is a nuisance. -IKE implementations should always be prepared to retransmit the most recent -message they sent on an ISAKMP SA, -since there is some possibility that the other end did not get it. -This means, in particular, -that the system sending the supposedly-last message of an exchange -cannot relax and assume that the exchange is complete, -at least not until a significant timeout has elapsed. -.P -Systems must also retain information about the message most recently received -in an exchange, -so that a duplicate of it can be detected -(and possibly interpreted as a NACK for the response). -.P -The retransmission rules FreeS/WAN follows are: -(1) if a reply is expected, retransmit only if it does not appear -before a timeout; -and (2) if a reply is not expected (last message of the exchange), -retransmit only on receiving a retransmission of the previous message. -Notably, in case (1) we do NOT retransmit on receiving a retransmission, -which avoids possible congestion problems arising from packet duplication, -at the price of slowing response to packet loss. -The timeout for case (1) is 10 seconds for the first retry, -20 seconds for the second, and 40 seconds for all subsequent -retries (normally only one, -except when -configuration settings call for persistence and the message is -the first message of Main Mode with a new peer). -These retransmission rules have been entirely successful. -.P -(Michael Thomas of Cisco has pointed out that the retry timeouts should -include some random jitter, to de-synchronize hosts which are -initially synchronized by, e.g., a power outage. -We already jitter our rekeying times, -as noted in section 4.2, -but that does not help with initial startup. -We're implementing jittered retries, -but cannot yet report on experience with this.) -.P -There is a deeper problem, of course, when an entire "exchange" consists -of a single message, -e.g. the ISAKMP Informational Exchange. -Then there is no way to decide whether or when a retransmission is -warranted at all. -This seems like poor design, to put it mildly -(and there is now talk of fixing it). -We have no experience in dealing with this problem at this time, -although it is part of the reason why we have delayed implementing -Notification messages. -.H -3.3. Replay Prevention -.P -The unsequenced nature of UDP transmission is also troublesome, -because it means that higher levels must consider the possibility -of replay attacks. -FreeS/WAN takes the position that systematically eliminating this -possibility at a low level is strongly preferable to forcing careful -consideration of possible impacts at every step of an exchange. -RFC 2408 [ISAKMP] section 3.1 states that the Message ID of an -ISAKMP message must be "unique". -FreeS/WAN interprets this literally, -as forbidding duplication of Message IDs -within the set of all messages sent via a single ISAKMP SA. -.P -This requires remembering all Message IDs until the ISAKMP SA is -superseded by rekeying, -but that is not costly (four bytes per sent or received message), -and it ELIMINATES replay attacks from consideration; -we believe this investment of resources is well worthwhile. -If the resource consumption becomes excessive\(emin our experience -it has not\(emthe ISAKMP SA can be rekeyed early to collect the garbage. -.P -There is theoretically an interoperability problem when talking to -implementations which interpret "unique" more loosely -and may re-use Message IDs, -but it has not been encountered in practice. -This approach appears to be completely interoperable. -.P -The proposal by -Andrew Krywaniuk [REPLAY], -which advocates turning the Message ID into an anti-replay counter, -would achieve the same goal without the minor per-message memory overhead. -This may be preferable, -although it means an actual protocol change and more study is needed. -.H -4. Basic Keying and Rekeying -.H -4.1. When to Create SAs -.P -As Tim Jenkins [REKEY] pointed out, -there is a potential race condition in Quick Mode: -a fast lightly-loaded Initiator might start using IPsec SAs very -shortly after sending QM3 (the third and last message of Quick Mode), -while a slow heavily-loaded Responder might -not be ready to receive them until after spending -a significant amount of time creating its inbound SAs. -The problem is even worse if QM3 gets delayed or lost. -.P -FreeS/WAN's approach to this is what Jenkins called "Responder Pre-Setup": -the Responder creates its inbound IPsec SAs before it sends QM2, -so they are always ready and waiting -when the Initiator sends QM3 and begins sending traffic. -This approach is simple and reliable, -and in our experience it interoperates with everybody. -(There is potentially still a problem if FreeS/WAN is the Initiator -and the Responder does not use Responder Pre-Setup, -but no such problems have been seen.) -The only real weakness of Responder Pre-Setup -is the possibility of replay attacks, -which we have eliminated by other means (see section 3.3). -.P -With this approach, the Commit Bit is useless, -and we ignore it. -In fact, until quite recently we discarded any IKE message containing it, -and this caused surprisingly few interoperability problems; -apparently it is not widely used. -We have recently been persuaded that simply ignoring it is preferable; -preliminary experience with this indicates that the result is successful -interoperation with implementations which set it. -.H -4.2. When to Rekey -.P -To preserve connectivity for user traffic, -rekeying of a connection -(that is, creation of new IPsec SAs to supersede the current ones) -must begin before its current IPsec SAs expire. -Preferably one end should predictably start rekeying negotiations first, -to avoid the extra overhead of two simultaneous negotiations, -although either end should be prepared to rekey if the other does not. -There is also a problem with "convoys" of keying negotiations: -for example, a "hub" gateway with many IPsec connections -can be inundated with rekeying negotiations -exactly one connection-expiry time after it reboots, -and the massive overload this induces tends to make this -situation self-perpetuating, -so it recurs regularly. -(Convoys can also evolve gradually from initially-unsynchronized negotiations.) -.P -FreeS/WAN has the concept of a "rekeying margin", measured in seconds. -If FreeS/WAN was the Initiator for the previous rekeying -(or the startup, if none) of the connection, -it nominally starts rekeying negotiations at expiry time -minus one rekeying margin. -Some random jitter is added to break up convoys: -rather than starting rekeying exactly at minus one margin, -it starts at a random time between minus one margin -and minus two margins. -(The randomness here need not be cryptographic in quality, -so long as it varies over time and between hosts. -We use an ordinary PRNG seeded with a few bytes from a cryptographic -randomness source. -The seeding mostly just ensures that the PRNG sequence is different -for different hosts, even if they start up simultaneously.) -.P -If FreeS/WAN was the Responder for the previous rekeying/startup, -and nothing has been heard from the previous Initiator -at expiry time minus one-half the rekeying margin, -FreeS/WAN will initiate rekeying negotiations. -No jitter is applied; -we now believe that it should be jittered, -say between minus one-half margin and minus one-quarter margin. -.P -Having the Initiator lead the way is an obvious way of deciding -who should speak first, -since there is already an Initiator/Responder asymmetry in the connection. -Moreover, our experience has been that Initiator lead gives a significantly -higher probability of successful negotiation! -The negotiation process itself is asymmetric, -because the Initiator must make a few specific proposals which the Responder -can only accept or reject, -so the Initiator must try to guess where its "acceptable" region -(in parameter space) -might overlap with the Responder's. -We have seen situations where negotiations would succeed or fail -depending on which end initiated them, -because one end was making better guesses. -Given an existing connection, -we KNOW that the previous Initiator WAS able to initiate a successful -negotiation, -so it should (if at all possible) take the lead again. -Also, the Responder should remember the Initiator's successful proposal, -and start from that -rather than from his own default proposals if he must take the lead; -we don't currently implement this completely but plan to. -.P -FreeS/WAN defaults the rekeying margin to 9 minutes, -although this can be changed by configuration. -There is also -a configuration option to alter the permissible range of jitter. -The defaults were chosen somewhat arbitrarily, -but they work extremely well -and the configuration options are rarely used. -.H -4.3. Choosing an SA -.P -Once rekeying has occurred, -both old and new IPsec SAs for the connection exist, -at least momentarily. -FreeS/WAN accepts incoming traffic -on either old or new inbound SAs, -but sends outgoing traffic only on the new outbound ones. -This approach appears to be significantly more robust than -using the old ones until they expire, -notably in cases where renegotiation has occurred because something has -gone wrong on the other end. -It avoids having to pay meticulous attention to the state of the other end, -state which is difficult to learn reliably given the limitations of IKE. -.P -This approach has interoperated successfully with ALMOST all other -implementations. -The only (well-characterized) problem cases have been implementations -which rely on receiving a Delete message for the old SAs to tell them -to switch over to the new ones. -Since delivery of Delete is unreliable, -and support for Delete is optional, -this reliance seems like a serious mistake. -This is all the more true because Delete -announces that the deletion has -already occurred [ISAKMP, section 3.15], not that it is about to occur, -so packets already in transit in the other direction could be lost. -Delete should be used for resource cleanup, not for switchover control. -(These matters are discussed further in section 5.) -.H -4.4. Why to Rekey -.P -FreeS/WAN currently implements only time-based expiry (life in seconds), -although we are working toward -supporting volume-based expiry (life in kilobytes) as well. -The lack of volume-based expiry has not been an interoperability -problem so far. -.P -Volume-based expiry does add some minor complications. -In particular, it makes explicit Delete of now-disused SAs more important, -because once an SA stops being used, -it might not expire on its own. -We believe this lacks robustness and is generally unwise, -especially given the lack of a reliable Delete, -and expect to use volume-based expiry only as a supplement -to time-based expiry. -However, Delete support (see section 5) does seem advisable -for use with volume-based expiry. -.P -We do not believe that volume-based expiry alters the desirability -of switching immediately to the new SAs after rekeying. -Rekeying margins are normally a small fraction of the total life of an SA, -so we feel there is no great need to "use it all up". -.H -4.5. Rekeying ISAKMP SAs -.P -The above discussion has focused on rekeying for IPsec SAs, -but FreeS/WAN applies the same approaches to rekeying for ISAKMP SAs, -with similar success. -.P -One issue which we have noticed, but not explicitly dealt with, -is that difficulties may ensue if an IPsec-SA rekeying negotiation -is in progress at the time when the relevant ISAKMP SA gets rekeyed. -The IKE specification [IKE] hints, but does not actually say, -that a Quick Mode negotiation should remain on a single ISAKMP SA throughout. -.P -A reasonable rekeying margin will generally -prevent the old ISAKMP SA from actually expiring during a negotiation. -Some attention may be needed to prevent in-progress negotiations from -being switched to the new ISAKMP SA. -Any attempt at pre-expiry deletion of the ISAKMP SA must be postponed -until after such dangling negotiations are completed, -and there should be enough delay between ISAKMP-SA rekeying and a -deletion attempt to (more or less) -ensure that there are no negotiation-starting packets still in transit -from before the rekeying. -.P -At present, FreeS/WAN does none of this, -and we don't KNOW of any resulting trouble. -With normal lifetimes, the problem should be uncommon, -and we speculate that an occasional disrupted negotiation simply gets retried. -.H -4.6. Bulk Negotiation -.P -Quick Mode nominally provides for negotiating possibly-large numbers of -similar but unrelated IPsec SAs simultaneously -[IKE, section 9]. -Nobody appears to do this. -FreeS/WAN does not support it, and its absence has caused no problems. -.H -5. Deletions, Teardowns, Crashes -.P -FreeS/WAN currently ignores all Notifications and Deletes, -and never generates them. -This has caused little difficulty in interoperability, -which shouldn't be surprising (since Notification and Delete support is -officially entirely optional) but does seem to surprise some people. -Nevertheless, we do plan some changes to this approach -based on past experience. -.H -5.1. Deletions -.P -As hinted at above, -we plan to implement Delete support, done as follows. -Shortly after rekeying of IPsec SAs, -the Responder issues a Delete for its old inbound SAs -(but does not actually delete them yet). -The Responder initiates this because the Initiator started using the -new SAs on sending QM3, while the Responder started using them only -on (or somewhat after) receiving QM3, -so there is less chance of old-SA packets still being in transit from -the Initiator. -The Initiator issues an unsolicited Delete only if it does not hear one -from the Responder after a longer delay. -.P -Either party, on receiving a Delete -for one or more of the old outbound SAs of a connection, -deletes ALL the connection's SAs, -and acknowledges with a Delete for the old inbound SAs. -A Delete for nonexistent SAs -(e.g., SAs which have already been expired or deleted) is ignored. -There is no retransmission of unacknowledged Deletes. -.P -In the normal case, -with prompt reliable transmission (except possibly for loss of the -Responder's initial Delete) -and conforming implementations -on both ends, this results in three Deletes being transmitted, -resembling the classic three-way handshake. -Loss of a Delete after the first, or multiple losses, -will cause the SAs not to be deleted on at least one end. -It appears difficult to do much better without at least -a distinction between request and acknowledgement. -.P -RFC 2409 section 9 "strongly suggests" that there be no response to -informational messages such as Deletes, -but the only rationale offered is prevention of infinite loops -endlessly exchanging "I don't understand you" informationals. -Since Deletes cannot lead to such a loop -(and in any case, the nonexistent-SA rule prevents more than one -acknowledgement for the same connection), -we believe this recommendation is inapplicable here. -.P -As noted in section 4.3, these Deletes are intended for -resource cleanup, not to control switching between SAs. -But we expect that they will improve interoperability -with some broken implementations. -.P -We believe strongly that connections need to be considered as a whole, -rather than treating each SA as an independent entity. -We will issue Deletes only for the full set of inbound SAs of -a connection, -and will treat a Delete for any outbound SA as equivalent to deletion -of all the outbound SAs for the associated connection. -.P -The above is phrased in terms of IPsec SAs, -but essentially the same approach can be applied to ISAKMP SAs -(the Deletes for the old ISAKMP SA should be sent via the new one). -.H -5.2. Teardowns and Shutdowns -.P -When a connection is not intended to be up permanently, -there is a need to coordinate teardown, -so that both ends are aware that the connection is down. -This is both for recovery of resources, -and to avoid routing packets through -dangling SAs which can no longer deliver them. -.P -Connection teardown will use the same bidirectional exchange of Deletes -as discussed in section 5.1: -a Delete received for current IPsec SAs (not yet obsoleted by rekeying) -indicates that the other host wishes to tear down the associated connection. -.P -A Delete received for a current ISAKMP SA indicates that the other host -wishes to tear down not only the ISAKMP SA but also all IPsec SAs -currently under the supervision of that ISAKMP SA. -The 5.1 bidirectional exchange might seem impossible in this case, -since reception of an ISAKMP-SA Delete indicates that the other end -will ignore further traffic on that ISAKMP SA. -We suggest using the same tactic discussed in 5.1 for IPsec SAs: -the first Delete is sent without actually doing the deletion, -and the response to receiving a Delete is to do the deletion and reply -with another Delete. -If there is no response to the first Delete, -retry a small number of times and then give up and do the deletion; -apart from being robust against packet loss, -this also maximizes the probability that an implementation which does -not do the bidirectional Delete will receive at least one of the Deletes. -.P -When a host with current connections knows that it is about to shut down, -it will issue Deletes for all SAs involved (both IPsec and ISAKMP), -advising its peers (as per the meaning of Delete [ISAKMP, section 3.15]) -that the SAs have become useless. -It will ignore attempts at rekeying or connection startup thereafter, -until it shuts down. -.P -It would be better to have a Final-Contact notification, -analogous to Initial-Contact but indicating that no new negotiations -should be attempted until further notice. -Initial-Contact actually could be used for shutdown notification (!), -but in networks where connections are intended to exist permanently, -it seems likely to provoke unwanted attempts -to renegotiate the lost connections. -.H -5.3. Crashes -.P -Systems sometimes crash. -Coping with the resulting loss of information is easily the most -difficult problem we have found in implementing robust IPsec systems. -.P -When connections are intended to be permanent, -it is simple to specify renegotiation on reboot. -With our approach to SA selection (see section 4.3), -this handles such cases robustly and well. -We do have to tell users that BOTH hosts should be set this way. -In cases where crashes are synchronized (e.g. by power interruptions), -this may result in simultaneous negotiations at reboot. -We currently allow both negotiations to proceed to completion, -but our use-newest selection method -effectively ignores one connection or the other, -and when one of them rekeys, -we notice that the new SAs replace those of both old connections, -and we then refrain from rekeying the other. -(This duplicate detection is desirable in any event, for robustness, -to ensure that the system converges on a reasonable state eventually -after it is perturbed by difficulties or bugs.) -.P -When connections are not permanent, the situation is less happy. -One particular situation in which we see problems is when a number of -"Road Warrior" hosts occasionally call in to a central server. -The server is normally configured not to initiate such connections, -since it does not know when the Road Warrior is available (or what IP -address it is using). -Unfortunately, if the server crashes and reboots, -any Road Warriors then connected have a problem: -they don't know that the server has crashed, -so they can't renegotiate, -and the server has forgotten both the connections and -their (transient) IP addresses, -so it cannot renegotiate. -.P -We believe that the simplest answer to this problem is what John Denker -has dubbed "address inertia": -the server makes a best-effort attempt to remember (in nonvolatile storage) -which connections were active and what the far-end addresses were -(and what the successful proposal's parameters were), -so that it can attempt renegotiation on reboot. -We have not implemented this yet, but intend to; -Denker has implemented it himself, -although in a somewhat messy way, -and reports excellent results. -.H -5.4. Network Partitions -.P -A network partition, making the two ends unable to reach each other, -has many of the same characteristics as having the other end crash... until -the network reconnects. -It is desirable that recovery from this be automatic. -.P -If the network reconnects before any rekeying attempts -or other IKE activities occurred, -recovery is fully transparent, -because the IKEs have no idea that there was any problem. -(Complaints such as ICMP Host Unreachable messages are unauthenticated -and hence cannot be given much weight.) -This fits the general mold of TCP/IP: -if nobody wanted to send any traffic, a network outage doesn't matter. -.P -If IKE activity did occur, -the IKE implementation will discover that the other end doesn't seem -to be responding. -The preferred response to this depends on the nature of the connection. -If it was intended to be ephemeral (e.g. opportunistic encryption [OE]), -closing it down after a few retries is reasonable. -If the other end is expected to sometimes drop the connection without -warning, it may not be desirable to retry at all. -(We support both these forms of configurability, -and indeed we also have a configuration option to suppress -rekeying entirely on one end.) -.P -If the connection was intended to be permanent, however, -then persistent attempts to re-establish it are appropriate. -Some degree of backoff is appropriate here, -so that retries get less frequent as the outage gets prolonged. -Backoff should be limited, -so that re-established connectivity is not followed by a long delay -before a retry. -Finally, after many retries (say 24 hours' worth), -it may be preferable to just declare the connection down and rely -on manual intervention to re-establish it, -should this be desirable. -We do not yet fully support all this. -.H -5.5. Unknown SAs -.P -A more complete solution to crashes -would be for an IPsec host to note the arrival -of ESP packets on an unknown IPsec SA, -and report it somehow to the other host, which can then decide to renegotiate. -This arguably might be preferable in any case\(emif -the non-rebooted host has no traffic to send, -it does not care whether the connection is intact\(embut -delays and packet loss will be reduced -if the connection is renegotiated BEFORE there is traffic for it. -So unknown-SA detection is best reserved as a fallback method, -with address inertia used to deal with most such cases. -.P -A difficulty with unknown-SA detection is, -just HOW should the other host be notified? -IKE provides no good way to do the notification: -Notification payloads (e.g., Initial-Contact) are unauthenticated -unless they are sent under protection of an ISAKMP SA. -A "Security Failures - Bad SPI" ICMP message [SECFAIL] -is an interesting alternative, -but has the disadvantage of likewise being unauthenticated. -It's fundamentally unlikely that there is a simple solution to this, -given that almost any way of arranging or checking authentication for such a -notification is costly. -.P -We think the best answer to this is a two-step approach. -An unauthenticated Initial-Contact or -Security Failures - Bad SPI cannot be taken as a reliable -report of a problem, -but can be taken as a hint that a problem MIGHT exist. -Then there needs to be some reliable way of checking such hints, -subject to rate limiting since the checks are likely to be costly -(and checking the same connection repeatedly at short intervals is unlikely -to be worthwhile anyway). -So the rebooted host sends the notification, -and the non-rebooted host\(emwhich still thinks it has a connection\(emchecks -whether the connection still works, -and renegotiates if not. -.P -Also, if an IPsec host which believes it has a connection to another host -sees an unsuccessful attempt by that host to negotiate a new one, -that is also a hint of possible problems, -justifying a check and possible renegotiation. -("Unsuccessful" here means a negotiation failure due to lack of a -satisfactory proposal. -A failure due to authentication failure -suggests a denial-of-service attack by a third party, -rather than a genuine problem on the legitimate other end.) -As noted in section 4.2, -it is possible for negotiations to succeed or fail based on which -end initiates them, and some robustness against that is desirable. -.P -We have not yet decided what form the notification should take. -IKE Initial-Contact is an obvious possibility, -but has some disadvantages. -It does not specify which connection has had difficulties. -Also, the specification [IKE section 4.6.3.3] -refers to "remote system" and "sending system" -without clearly specifying just what "system" means; -in the case of a multi-homed host using multiple forms of identification, -the question is not trivial. -Initial-Contact does have the fairly-decisive advantage -that it is likely to convey the right general -meaning even to an implementation which does not do things -exactly the way ours does. -.P -A more fundamental difficulty is what form the reliable check takes. -What is wanted is an "IKE ping", -verifying that the ISAKMP SA is still intact -(it being unlikely that IPsec SAs have been lost while the ISAKMP SA has not). -The lack of such a facility is a serious failing of IKE. -An acknowledged Notification of some sort would be ideal, -but there is none at present. -Some existing implementations are known -to use the private Notification values 30000 as ping -and 30002 as ping reply, -and that seems the most attractive choice at present. -If it is not recognized, there will probably be no reply, -and the result will be an unnecessary renegotiation, -so this needs strict rate limiting. -(Also, when a new connection is set up, -it's probably worth determining by experiment whether the other end -supports IKE ping, and remembering that.) -.P -While we think this facility is desirable, -and is about the best that can be done with the poor tools available, -we have not gotten very far in implementation and cannot comment -intelligently about how well it works or interoperates. -.H -6. Misc. IKE Issues -.H -6.1. Groups 1 and 5 -.P -We have dropped support for the first Oakley Group (group 1), -despite it being officially mandatory, -on the grounds that it is -grossly too weak to provide enough randomness for 3DES. -There have been some interoperability problems, -mostly quite minor: -ALMOST everyone supports group 2 as well, -although sometimes it has to be explicitly configured. -.P -We also support the quasi-standard group 5 [GROUPS]. -This has not been seriously exercised yet, -because historically -we offered group 2 first and almost everyone accepted it. -We have recently changed to offering group 5 first, -and no difficulties have been reported. -.H -6.2. To PFS Or Not To PFS -.P -A persistent small interoperability problem is that -the presence or absence of PFS (for keys [IKE, section 5.5]) -is neither negotiated nor announced. -We have it enabled by default, -and successful interoperation often requires having -the other end turn it on in their implementation, -or having the FreeS/WAN end disable it. -Almost everyone supports it, but it's usually not the default, -and interoperability is often impossible unless the two ends -somehow reach prior agreement on it. -.P -We do not explicitly support the other flavor of PFS, -for identities [IKE, section 8], -and this has caused no interoperability problems. -.H -6.3. Debugging Tools, Lack Thereof -.P -We find IKE lacking in basic debugging tools. -Section 5.4, above, -notes that an IKE ping would be useful for connectivity verification. -It would also be extremely helpful for determining that UDP/500 -packets get back and forth successfully between the two ends, -which is often an important first step in debugging. -.P -It's also quite common to have IKE negotiate a connection successfully, -but to have some firewall along the way blocking ESP. -Users find this mysterious and difficult to diagnose. -We have no immediate suggestions on what could be done about it. -.H -6.4. Terminology, Vagueness Thereof -.P -The terminology of IPsec needs work. -We feel that both the specifications and user-oriented -documentation would be greatly clarified by concise, intelligible names for -certain concepts. -.P -We semi-consistently use "group" for the set of IPsec SAs which are -established in one direction -by a single Quick Mode negotiation and are used together -to process a packet (e.g., an ESP SA plus an AH SA), -"connection" for the logical packet path provided -by a succession of pairs of groups -(each rekeying providing a new pair, one group in each direction), -and "keying channel" for the corresponding supervisory path provided -by a sequence of ISAKMP SAs. -.P -We think it's a botch that "PFS" is used to refer to two very different things, -but we have no specific new terms to suggest, since we only implement -one kind of PFS and thus can just ignore the other. -.H -6.5. A Question of Identity -.P -One specification problem deserves note: -exactly when can an existing phase 1 negotiation -be re-used for a new phase 2 negotiation, -as IKE [IKE, section 4] specifies? -Presumably, -when it connects the same two "parties"... but exactly what is a "party"? -.P -As noted in section 5.4, -in cases involving multi-homing and multiple identities, -it's not clear exactly what criteria are used for deciding -whether the intended far end for a new negotiation is the same one -as for a previous negotiation. -Is it by Identification Payload? -By IP address? -Or what? -.P -We currently use a somewhat-vague notion of "identity", -basically what gets sent in Identification Payloads, -for this, and this seems to be successful, -but we think this needs better specification. -.H -6.6. Opportunistic Encryption -.P -Further IKE challenges appear in the context of Opportunistic Encryption -[OE], -but operational experience with it is too limited as yet for us -to comment usefully right now. -.H -6.7. Authentication and RSA Keys -.P -We provide two IKE authentication methods: -shared secrets ("pre-shared keys") -and RSA digital signatures. -(A user-provided add-on package generalizes the latter to limited -support for certificates; -we have not worked extensively with it ourselves yet and cannot comment -on it yet.) -.P -Shared secrets, despite their administrative difficulties, -see considerable use, -and are also the method of last resort for interoperability problems. -.P -For digital signatures, -we have taken the somewhat unorthodox approach of using "bare" RSA public keys, -either supplied in configuration files or fetched from DNS, -rather than getting involved in the complexity of certificates. -We encode our RSA public keys using the DNS KEY encoding [DNSRSA] -(aka "RFC 2537", although that RFC is now outdated), -which has given us no difficulties and which we highly recommend. -We have seen two difficulties in connection with RSA keys, however. -.P -First, -while a number of IPsec implementations are able to take "bare" RSA public keys, -each one seems to have its own idea of what format should be used -for transporting them. -We've had little success with interoperability here, -mostly because of key-format issues; -the implementations generally WILL interoperate successfully if you can -somehow get an RSA key into them at all, but that's hard. -X.509 certificates seem to be the lowest (!) -common denominator for key transfer. -.P -Second, -although the content of RSA public keys has been stable, -there has been a small but subtle change over time in the content -of RSA private keys. -The "internal modulus", -used to compute the private exponent "d" from the public exponent "e" -(or vice-versa) -was originally [RSA] [PKCS1v1] [SCHNEIER] specified to be (p-1)*(q-1), -where p and q are the two primes. -However, more recent definitions [PKCS1v2] call it -"lambda(n)" and define it to be lcm(p-1,\ q-1); -this appears to be a minor optimization. -The result is that private keys generated with the new definition -often fail consistency checks in implementations using the old definition. -Fortunately, it is seldom necessary to move private keys around. -Our software now consistently uses the new definition -(and thus will accept keys generated with either definition), -but our key generator also has an option to generate old-definition keys, -for the benefit of users who upgrade their networks incrementally. -.H -6.8. Misc. Snags -.P -Nonce size is another characteristic that is neither negotiated nor announced -but that the two ends must somehow be able to agree on. -Our software accepts anything between 8 and 256, and defaults to 16. -These numbers were chosen rather arbitrarily, -but we have seen no interoperability failures here. -.P -Nothing in the ISAKMP [ISAKMP] or IKE [IKE] specifications says -explicitly that a normal Message ID must be non-zero, -but a zero Message ID in fact causes failures. -.P -Similarly, there is nothing in the specs which says that ISAKMP cookies -must be non-zero, but zero cookies will in fact cause trouble. -.H -7. Security Considerations -.P -Since this document discusses aspects of building robust and -interoperable IPsec implementations, -security considerations permeate it. -.H -8. References -.R AH -Kent, S., and Atkinson, R., -"IP Authentication Header", -RFC 2402, -Nov 1998. -.R CIPHERS -Pereira, R., and Adams, R., -"The ESP CBC-Mode Cipher Algorithms", -RFC 2451, -Nov 1998. -.R CRACK -Electronic Frontier Foundation, -"Cracking DES: -Secrets of Encryption Research, Wiretap Politics and Chip Design", -O'Reilly 1998, -ISBN 1-56592-520-3. -.R DES -Madson, C., and Doraswamy, N., -"The ESP DES-CBC Cipher Algorithm", -RFC 2405, -Nov 1998. -.R DNSRSA -D. Eastlake 3rd, -"RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)", -RFC 3110, -May 2001. -.R ESP -Kent, S., and Atkinson, R., -"IP Encapsulating Security Payload (ESP)", -RFC 2406, -Nov 1998. -.R GROUPS -Kivinen, T., and Kojo, M., -"More MODP Diffie-Hellman groups for IKE", -<draft-ietf-ipsec-ike-modp-groups-04.txt>, -13 Dec 2001 (work in progress). -.R IKE -Harkins, D., and Carrel, D., -"The Internet Key Exchange (IKE)", -RFC 2409, Nov 1998. -.R IPSEC -Kent, S., and Atkinson, R., -"Security Architecture for the Internet Protocol", -RFC 2401, Nov 1998. -.R ISAKMP -Maughan, D., Schertler, M., Schneider, M., and Turner, J., -"Internet Security Association and Key Management Protocol (ISAKMP)", -RFC 2408, Nov 1998. -.R OE -Richardson, M., Redelmeier, D. H., and Spencer, H., -"A method for doing opportunistic encryption with IKE", -<draft-richardson-ipsec-opportunistic-06.txt>, -21 Feb 2002 (work in progress). -.R PKCS1v1 -Kaliski, B., -"PKCS #1: RSA Encryption, Version 1.5", -RFC 2313, March 1998. -.R PKCS1v2 -Kaliski, B., and Staddon, J., -"PKCS #1: RSA Cryptography Specifications, Version 2.0", -RFC 2437, Oct 1998. -.R PFKEY -McDonald, D., Metz, C., and Phan, B., -"PF_KEY Key Management API, Version 2", -RFC 2367, July 1998. -.R REKEY -Tim Jenkins, "IPsec Re-keying Issues", -<draft-jenkins-ipsec-rekeying-06.txt>, -2 May 2000 (draft expired, work no longer in progress). -.R REPLAY -Krywaniuk, A., -"Using Isakmp Message Ids for Replay Protection", -<draft-krywaniuk-ipsec-antireplay-00.txt>, -9 July 2001 -(work in progress). -.R RSA -Rivest, R.L., Shamir, A., and Adleman, L., -"A Method for Obtaining Digital Signatures and Public-Key -Cryptosystems", -Communications of the ACM v21n2, Feb 1978, p. 120. -.R SCHNEIER -Bruce Schneier, "Applied Cryptography", 2nd ed., -Wiley 1996, ISBN 0-471-11709-9. -.R SECFAIL -Karn, P., and Simpson, W., -"ICMP Security Failures Messages", -RFC 2521, -March 1999. -.H -Authors' Addresses -.P -.nf -.ne 8 -Henry Spencer -SP Systems -Box 280 Stn. A -Toronto, Ont. M5W1B2 -Canada - -henry@spsystems.net -416-690-6561 -.ne 8 -.sp 2 -D. Hugh Redelmeier -Mimosa Systems Inc. -29 Donino Ave. -Toronto, Ont. M4N2W6 -Canada - -hugh@mimosa.com -416-482-8253 -.bp -.H -Full Copyright Statement -.P -Copyright (C) The Internet Society \*c. 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 implmentation 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. diff --git a/doc/draft-spencer-ipsec-ike-implementation.txt b/doc/draft-spencer-ipsec-ike-implementation.txt deleted file mode 100644 index 145c00ba8..000000000 --- a/doc/draft-spencer-ipsec-ike-implementation.txt +++ /dev/null @@ -1,1232 +0,0 @@ - - - -Network Working Group Henry Spencer -Internet Draft SP Systems -Expires: 26 Aug 2002 D. Hugh Redelmeier - Mimosa Systems - 26 Feb 2002 - - IKE Implementation Issues - <draft-spencer-ipsec-ike-implementation-02.txt> - -Status of this Memo - - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC2026. - - (If approved as an Informational RFC...) This memo provides - information for the Internet community. This memo does not specify - an Internet standard of any kind. - - Distribution of this memo is unlimited. - - 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 26 Aug 2002. - -Copyright Notice - - Copyright (C) The Internet Society 2002. All Rights Reserved. - - - - - - - - - - -Spencer & Redelmeier [Page 1] - -Internet Draft IKE Implementation Issues 26 Feb 2002 - - -Table of Contents - - 1. Introduction ................................................... 3 - 2. Lower-level Background and Notes ............................... 4 - 2.1. Packet Handling .............................................. 4 - 2.2. Ciphers ...................................................... 5 - 2.3. Interfaces ................................................... 5 - 3. IKE Infrastructural Issues ..................................... 5 - 3.1. Continuous Channel ........................................... 5 - 3.2. Retransmission ............................................... 5 - 3.3. Replay Prevention ............................................ 6 - 4. Basic Keying and Rekeying ...................................... 7 - 4.1. When to Create SAs ........................................... 7 - 4.2. When to Rekey ................................................ 8 - 4.3. Choosing an SA ............................................... 9 - 4.4. Why to Rekey ................................................. 9 - 4.5. Rekeying ISAKMP SAs ......................................... 10 - 4.6. Bulk Negotiation ............................................ 10 - 5. Deletions, Teardowns, Crashes ................................. 11 - 5.1. Deletions ................................................... 11 - 5.2. Teardowns and Shutdowns ..................................... 12 - 5.3. Crashes ..................................................... 13 - 5.4. Network Partitions .......................................... 13 - 5.5. Unknown SAs ................................................. 14 - 6. Misc. IKE Issues .............................................. 16 - 6.1. Groups 1 and 5 .............................................. 16 - 6.2. To PFS Or Not To PFS ........................................ 16 - 6.3. Debugging Tools, Lack Thereof ............................... 16 - 6.4. Terminology, Vagueness Thereof .............................. 17 - 6.5. A Question of Identity ...................................... 17 - 6.6. Opportunistic Encryption .................................... 17 - 6.7. Authentication and RSA Keys ................................. 17 - 6.8. Misc. Snags ................................................. 18 - 7. Security Considerations ....................................... 19 - 8. References .................................................... 19 - Authors' Addresses ............................................... 20 - Full Copyright Statement ......................................... 21 - - - - - - - - - - - - - - -Spencer & Redelmeier [Page 2] - -Internet Draft IKE Implementation Issues 26 Feb 2002 - - -Abstract - - The current IPsec specifications for key exchange and connection - management, RFCs 2408 [ISAKMP] and 2409 [IKE], leave many aspects of - connection management unspecified, most prominently rekeying - practices. Pending clarifications in future revisions of the - specifications, this document sets down some successful experiences, - to minimize the extent to which new implementors have to rely on - unwritten folklore. - - The Linux FreeS/WAN implementation of IPsec interoperates with almost - every other IPsec implementation. This document describes how the - FreeS/WAN project has resolved some of the gaps in the IPsec - specifications (and plans to resolve some others), and what - difficulties have been encountered, in hopes that this generally- - successful experience might be informative to new implementors. - - This is offered as an Informational RFC. - - This -02 revision mainly: discusses ISAKMP SA expiry during IPsec-SA - rekeying (4.5), revises the discussion of bidirectional Deletes - (5.1), suggests remembering the parameters of successful negotiations - for later use (4.2, 5.3), notes an unsuccessful negotiation from the - other end as a hint of a possibly broken connection (5.5), and adds - sections on network partitions (5.4), authentication methods and the - subtleties of RSA public keys (6.7), and miscellaneous - interoperability concerns (6.8). - -1. Introduction - - The current IPsec specifications for key exchange and connection - management, RFCs 2408 [ISAKMP] and 2409 [IKE], leave many aspects of - connection management unspecified, most prominently rekeying - practices. This is a cryptic puzzle which each group of implementors - has to struggle with, and differences in how the ambiguities and gaps - are resolved are potentially a fruitful source of interoperability - problems. We can hope that future revisions of the specifications - will clear this up. Meanwhile, it seems useful to set down some - successful experiences, to minimize the extent to which new - implementors have to rely on unwritten folklore. - - The Linux FreeS/WAN implementation of IPsec interoperates with almost - every other IPsec implementation, and because of its free nature, it - also sees some use as a reference implementation by other - implementors. The high degree of interoperability is noteworthy - given its organizers' strong minimalist bias, which has caused them - to implement only a small subset of the full glory of IPsec. This - document describes how the FreeS/WAN project has resolved some of the - - - -Spencer & Redelmeier [Page 3] - -Internet Draft IKE Implementation Issues 26 Feb 2002 - - - gaps in the IPsec specifications (and plans to resolve some others), - and what difficulties have been encountered, in hopes that this - generally-successful experience might be informative to new - implementors. - - One small caution about applicability: this experience may not be - relevant to severely resource-constrained implementations. - FreeS/WAN's target environment is previous-generation PCs, now - available at trivial cost (often, within an organization, at no - cost), which have quite impressive CPU power and memory by the - standards of only a few years ago. Some of the approaches discussed - here may be inapplicable to implementations with severe external - constraints which prevent them from taking advantage of modern - hardware technology. - -2. Lower-level Background and Notes - -2.1. Packet Handling - - FreeS/WAN implements ESP [ESP] and AH [AH] straightforwardly, - although AH sees little use among our users. Our ESP/AH - implementation cannot currently handle packets with IP options; - somewhat surprisingly, this has caused little difficulty. We insist - on encryption and do not support authentication-only connections, and - this has not caused significant difficulty either. - - MTU and fragmentation issues, by contrast, have been a constant - headache. We will not describe the details of our current approach - to them, because it still needs work. One difficulty we have - encountered is that many combinations of packet source and packet - destination apparently cannot cope with an "interior minimum" in the - path MTU, e.g. where an IPsec tunnel intervenes and its headers - reduce the MTU for an intermediate link. This is particularly - prevalent when using common PC software to connect to large well- - known web sites; we think it is largely due to misconfigured - firewalls which do not pass ICMP Fragmentation Required messages. - The only solution we have yet found is to lie about the MTU of the - tunnel, accepting the (undesirable) fragmentation of the ESP packets - for the sake of preserving connectivity. - - We currently zero out the TOS field of ESP packets, rather than - copying it from the inner header, on the grounds that it lends itself - too well to traffic analysis and covert channels. We provide an - option to restore RFC 2401 [IPSEC] copying behavior, but this appears - to see little use. - - - - - - -Spencer & Redelmeier [Page 4] - -Internet Draft IKE Implementation Issues 26 Feb 2002 - - -2.2. Ciphers - - We initially implemented both DES [DES] and 3DES [CIPHERS] for both - IKE and ESP, but after the Deep Crack effort [CRACK] demonstrated its - inherent insecurity, we dropped support for DES. Somewhat - surprisingly, our insistence on 3DES has caused almost no - interoperability problems, despite DES being officially mandatory. A - very few other systems either do not support 3DES or support it only - as an optional upgrade, which inconveniences a few would-be users. - There have also been one or two cases of systems which don't quite - seem to know the difference! - - See also section 6.1 for a consequence of our insistence on 3DES. - -2.3. Interfaces - - We currently employ PF_KEY version 2 [PFKEY], plus various non- - standard extensions, as our interface between keying and ESP. This - has not proven entirely satisfactory. Our feeling now is that keying - issues and policy issues do not really lend themselves to the clean - separation that PF_KEY envisions. - -3. IKE Infrastructural Issues - - A number of problems in IPsec connection management become easier if - some attention is first paid to providing an infrastructure to - support solving them. - -3.1. Continuous Channel - - FreeS/WAN uses an approximation to the "continuous channel" model, in - which ISAKMP SAs are maintained between IKEs so long as any IPsec SAs - are open between the two systems. The resource consumption of this - is minor: the only substantial overhead is occasional rekeying. - IPsec SA management becomes significantly simpler if there is always - a channel for transmission of control messages. We suggest (although - we do not yet fully implement this) that inability to maintain (e.g., - to rekey) this control path should be grounds for tearing down the - IPsec SAs as well. - - As a corollary of this, there is one and only one ISAKMP SA - maintained between a pair of IKEs (although see sections 5.3 and 6.5 - for minor complications). - -3.2. Retransmission - - The unreliable nature of UDP transmission is a nuisance. IKE - implementations should always be prepared to retransmit the most - - - -Spencer & Redelmeier [Page 5] - -Internet Draft IKE Implementation Issues 26 Feb 2002 - - - recent message they sent on an ISAKMP SA, since there is some - possibility that the other end did not get it. This means, in - particular, that the system sending the supposedly-last message of an - exchange cannot relax and assume that the exchange is complete, at - least not until a significant timeout has elapsed. - - Systems must also retain information about the message most recently - received in an exchange, so that a duplicate of it can be detected - (and possibly interpreted as a NACK for the response). - - The retransmission rules FreeS/WAN follows are: (1) if a reply is - expected, retransmit only if it does not appear before a timeout; and - (2) if a reply is not expected (last message of the exchange), - retransmit only on receiving a retransmission of the previous - message. Notably, in case (1) we do NOT retransmit on receiving a - retransmission, which avoids possible congestion problems arising - from packet duplication, at the price of slowing response to packet - loss. The timeout for case (1) is 10 seconds for the first retry, 20 - seconds for the second, and 40 seconds for all subsequent retries - (normally only one, except when configuration settings call for - persistence and the message is the first message of Main Mode with a - new peer). These retransmission rules have been entirely successful. - - (Michael Thomas of Cisco has pointed out that the retry timeouts - should include some random jitter, to de-synchronize hosts which are - initially synchronized by, e.g., a power outage. We already jitter - our rekeying times, as noted in section 4.2, but that does not help - with initial startup. We're implementing jittered retries, but - cannot yet report on experience with this.) - - There is a deeper problem, of course, when an entire "exchange" - consists of a single message, e.g. the ISAKMP Informational Exchange. - Then there is no way to decide whether or when a retransmission is - warranted at all. This seems like poor design, to put it mildly (and - there is now talk of fixing it). We have no experience in dealing - with this problem at this time, although it is part of the reason why - we have delayed implementing Notification messages. - -3.3. Replay Prevention - - The unsequenced nature of UDP transmission is also troublesome, - because it means that higher levels must consider the possibility of - replay attacks. FreeS/WAN takes the position that systematically - eliminating this possibility at a low level is strongly preferable to - forcing careful consideration of possible impacts at every step of an - exchange. RFC 2408 [ISAKMP] section 3.1 states that the Message ID - of an ISAKMP message must be "unique". FreeS/WAN interprets this - literally, as forbidding duplication of Message IDs within the set of - - - -Spencer & Redelmeier [Page 6] - -Internet Draft IKE Implementation Issues 26 Feb 2002 - - - all messages sent via a single ISAKMP SA. - - This requires remembering all Message IDs until the ISAKMP SA is - superseded by rekeying, but that is not costly (four bytes per sent - or received message), and it ELIMINATES replay attacks from - consideration; we believe this investment of resources is well - worthwhile. If the resource consumption becomes excessive--in our - experience it has not--the ISAKMP SA can be rekeyed early to collect - the garbage. - - There is theoretically an interoperability problem when talking to - implementations which interpret "unique" more loosely and may re-use - Message IDs, but it has not been encountered in practice. This - approach appears to be completely interoperable. - - The proposal by Andrew Krywaniuk [REPLAY], which advocates turning - the Message ID into an anti-replay counter, would achieve the same - goal without the minor per-message memory overhead. This may be - preferable, although it means an actual protocol change and more - study is needed. - -4. Basic Keying and Rekeying - -4.1. When to Create SAs - - As Tim Jenkins [REKEY] pointed out, there is a potential race - condition in Quick Mode: a fast lightly-loaded Initiator might start - using IPsec SAs very shortly after sending QM3 (the third and last - message of Quick Mode), while a slow heavily-loaded Responder might - not be ready to receive them until after spending a significant - amount of time creating its inbound SAs. The problem is even worse - if QM3 gets delayed or lost. - - FreeS/WAN's approach to this is what Jenkins called "Responder Pre- - Setup": the Responder creates its inbound IPsec SAs before it sends - QM2, so they are always ready and waiting when the Initiator sends - QM3 and begins sending traffic. This approach is simple and - reliable, and in our experience it interoperates with everybody. - (There is potentially still a problem if FreeS/WAN is the Initiator - and the Responder does not use Responder Pre-Setup, but no such - problems have been seen.) The only real weakness of Responder Pre- - Setup is the possibility of replay attacks, which we have eliminated - by other means (see section 3.3). - - With this approach, the Commit Bit is useless, and we ignore it. In - fact, until quite recently we discarded any IKE message containing - it, and this caused surprisingly few interoperability problems; - apparently it is not widely used. We have recently been persuaded - - - -Spencer & Redelmeier [Page 7] - -Internet Draft IKE Implementation Issues 26 Feb 2002 - - - that simply ignoring it is preferable; preliminary experience with - this indicates that the result is successful interoperation with - implementations which set it. - -4.2. When to Rekey - - To preserve connectivity for user traffic, rekeying of a connection - (that is, creation of new IPsec SAs to supersede the current ones) - must begin before its current IPsec SAs expire. Preferably one end - should predictably start rekeying negotiations first, to avoid the - extra overhead of two simultaneous negotiations, although either end - should be prepared to rekey if the other does not. There is also a - problem with "convoys" of keying negotiations: for example, a "hub" - gateway with many IPsec connections can be inundated with rekeying - negotiations exactly one connection-expiry time after it reboots, and - the massive overload this induces tends to make this situation self- - perpetuating, so it recurs regularly. (Convoys can also evolve - gradually from initially-unsynchronized negotiations.) - - FreeS/WAN has the concept of a "rekeying margin", measured in - seconds. If FreeS/WAN was the Initiator for the previous rekeying - (or the startup, if none) of the connection, it nominally starts - rekeying negotiations at expiry time minus one rekeying margin. Some - random jitter is added to break up convoys: rather than starting - rekeying exactly at minus one margin, it starts at a random time - between minus one margin and minus two margins. (The randomness here - need not be cryptographic in quality, so long as it varies over time - and between hosts. We use an ordinary PRNG seeded with a few bytes - from a cryptographic randomness source. The seeding mostly just - ensures that the PRNG sequence is different for different hosts, even - if they start up simultaneously.) - - If FreeS/WAN was the Responder for the previous rekeying/startup, and - nothing has been heard from the previous Initiator at expiry time - minus one-half the rekeying margin, FreeS/WAN will initiate rekeying - negotiations. No jitter is applied; we now believe that it should be - jittered, say between minus one-half margin and minus one-quarter - margin. - - Having the Initiator lead the way is an obvious way of deciding who - should speak first, since there is already an Initiator/Responder - asymmetry in the connection. Moreover, our experience has been that - Initiator lead gives a significantly higher probability of successful - negotiation! The negotiation process itself is asymmetric, because - the Initiator must make a few specific proposals which the Responder - can only accept or reject, so the Initiator must try to guess where - its "acceptable" region (in parameter space) might overlap with the - Responder's. We have seen situations where negotiations would - - - -Spencer & Redelmeier [Page 8] - -Internet Draft IKE Implementation Issues 26 Feb 2002 - - - succeed or fail depending on which end initiated them, because one - end was making better guesses. Given an existing connection, we KNOW - that the previous Initiator WAS able to initiate a successful - negotiation, so it should (if at all possible) take the lead again. - Also, the Responder should remember the Initiator's successful - proposal, and start from that rather than from his own default - proposals if he must take the lead; we don't currently implement this - completely but plan to. - - FreeS/WAN defaults the rekeying margin to 9 minutes, although this - can be changed by configuration. There is also a configuration - option to alter the permissible range of jitter. The defaults were - chosen somewhat arbitrarily, but they work extremely well and the - configuration options are rarely used. - -4.3. Choosing an SA - - Once rekeying has occurred, both old and new IPsec SAs for the - connection exist, at least momentarily. FreeS/WAN accepts incoming - traffic on either old or new inbound SAs, but sends outgoing traffic - only on the new outbound ones. This approach appears to be - significantly more robust than using the old ones until they expire, - notably in cases where renegotiation has occurred because something - has gone wrong on the other end. It avoids having to pay meticulous - attention to the state of the other end, state which is difficult to - learn reliably given the limitations of IKE. - - This approach has interoperated successfully with ALMOST all other - implementations. The only (well-characterized) problem cases have - been implementations which rely on receiving a Delete message for the - old SAs to tell them to switch over to the new ones. Since delivery - of Delete is unreliable, and support for Delete is optional, this - reliance seems like a serious mistake. This is all the more true - because Delete announces that the deletion has already occurred - [ISAKMP, section 3.15], not that it is about to occur, so packets - already in transit in the other direction could be lost. Delete - should be used for resource cleanup, not for switchover control. - (These matters are discussed further in section 5.) - -4.4. Why to Rekey - - FreeS/WAN currently implements only time-based expiry (life in - seconds), although we are working toward supporting volume-based - expiry (life in kilobytes) as well. The lack of volume-based expiry - has not been an interoperability problem so far. - - Volume-based expiry does add some minor complications. In - particular, it makes explicit Delete of now-disused SAs more - - - -Spencer & Redelmeier [Page 9] - -Internet Draft IKE Implementation Issues 26 Feb 2002 - - - important, because once an SA stops being used, it might not expire - on its own. We believe this lacks robustness and is generally - unwise, especially given the lack of a reliable Delete, and expect to - use volume-based expiry only as a supplement to time-based expiry. - However, Delete support (see section 5) does seem advisable for use - with volume-based expiry. - - We do not believe that volume-based expiry alters the desirability of - switching immediately to the new SAs after rekeying. Rekeying - margins are normally a small fraction of the total life of an SA, so - we feel there is no great need to "use it all up". - -4.5. Rekeying ISAKMP SAs - - The above discussion has focused on rekeying for IPsec SAs, but - FreeS/WAN applies the same approaches to rekeying for ISAKMP SAs, - with similar success. - - One issue which we have noticed, but not explicitly dealt with, is - that difficulties may ensue if an IPsec-SA rekeying negotiation is in - progress at the time when the relevant ISAKMP SA gets rekeyed. The - IKE specification [IKE] hints, but does not actually say, that a - Quick Mode negotiation should remain on a single ISAKMP SA - throughout. - - A reasonable rekeying margin will generally prevent the old ISAKMP SA - from actually expiring during a negotiation. Some attention may be - needed to prevent in-progress negotiations from being switched to the - new ISAKMP SA. Any attempt at pre-expiry deletion of the ISAKMP SA - must be postponed until after such dangling negotiations are - completed, and there should be enough delay between ISAKMP-SA - rekeying and a deletion attempt to (more or less) ensure that there - are no negotiation-starting packets still in transit from before the - rekeying. - - At present, FreeS/WAN does none of this, and we don't KNOW of any - resulting trouble. With normal lifetimes, the problem should be - uncommon, and we speculate that an occasional disrupted negotiation - simply gets retried. - -4.6. Bulk Negotiation - - Quick Mode nominally provides for negotiating possibly-large numbers - of similar but unrelated IPsec SAs simultaneously [IKE, section 9]. - Nobody appears to do this. FreeS/WAN does not support it, and its - absence has caused no problems. - - - - - -Spencer & Redelmeier [Page 10] - -Internet Draft IKE Implementation Issues 26 Feb 2002 - - -5. Deletions, Teardowns, Crashes - - FreeS/WAN currently ignores all Notifications and Deletes, and never - generates them. This has caused little difficulty in - interoperability, which shouldn't be surprising (since Notification - and Delete support is officially entirely optional) but does seem to - surprise some people. Nevertheless, we do plan some changes to this - approach based on past experience. - -5.1. Deletions - - As hinted at above, we plan to implement Delete support, done as - follows. Shortly after rekeying of IPsec SAs, the Responder issues a - Delete for its old inbound SAs (but does not actually delete them - yet). The Responder initiates this because the Initiator started - using the new SAs on sending QM3, while the Responder started using - them only on (or somewhat after) receiving QM3, so there is less - chance of old-SA packets still being in transit from the Initiator. - The Initiator issues an unsolicited Delete only if it does not hear - one from the Responder after a longer delay. - - Either party, on receiving a Delete for one or more of the old - outbound SAs of a connection, deletes ALL the connection's SAs, and - acknowledges with a Delete for the old inbound SAs. A Delete for - nonexistent SAs (e.g., SAs which have already been expired or - deleted) is ignored. There is no retransmission of unacknowledged - Deletes. - - In the normal case, with prompt reliable transmission (except - possibly for loss of the Responder's initial Delete) and conforming - implementations on both ends, this results in three Deletes being - transmitted, resembling the classic three-way handshake. Loss of a - Delete after the first, or multiple losses, will cause the SAs not to - be deleted on at least one end. It appears difficult to do much - better without at least a distinction between request and - acknowledgement. - - RFC 2409 section 9 "strongly suggests" that there be no response to - informational messages such as Deletes, but the only rationale - offered is prevention of infinite loops endlessly exchanging "I don't - understand you" informationals. Since Deletes cannot lead to such a - loop (and in any case, the nonexistent-SA rule prevents more than one - acknowledgement for the same connection), we believe this - recommendation is inapplicable here. - - As noted in section 4.3, these Deletes are intended for resource - cleanup, not to control switching between SAs. But we expect that - they will improve interoperability with some broken implementations. - - - -Spencer & Redelmeier [Page 11] - -Internet Draft IKE Implementation Issues 26 Feb 2002 - - - We believe strongly that connections need to be considered as a - whole, rather than treating each SA as an independent entity. We - will issue Deletes only for the full set of inbound SAs of a - connection, and will treat a Delete for any outbound SA as equivalent - to deletion of all the outbound SAs for the associated connection. - - The above is phrased in terms of IPsec SAs, but essentially the same - approach can be applied to ISAKMP SAs (the Deletes for the old ISAKMP - SA should be sent via the new one). - -5.2. Teardowns and Shutdowns - - When a connection is not intended to be up permanently, there is a - need to coordinate teardown, so that both ends are aware that the - connection is down. This is both for recovery of resources, and to - avoid routing packets through dangling SAs which can no longer - deliver them. - - Connection teardown will use the same bidirectional exchange of - Deletes as discussed in section 5.1: a Delete received for current - IPsec SAs (not yet obsoleted by rekeying) indicates that the other - host wishes to tear down the associated connection. - - A Delete received for a current ISAKMP SA indicates that the other - host wishes to tear down not only the ISAKMP SA but also all IPsec - SAs currently under the supervision of that ISAKMP SA. The 5.1 - bidirectional exchange might seem impossible in this case, since - reception of an ISAKMP-SA Delete indicates that the other end will - ignore further traffic on that ISAKMP SA. We suggest using the same - tactic discussed in 5.1 for IPsec SAs: the first Delete is sent - without actually doing the deletion, and the response to receiving a - Delete is to do the deletion and reply with another Delete. If there - is no response to the first Delete, retry a small number of times and - then give up and do the deletion; apart from being robust against - packet loss, this also maximizes the probability that an - implementation which does not do the bidirectional Delete will - receive at least one of the Deletes. - - When a host with current connections knows that it is about to shut - down, it will issue Deletes for all SAs involved (both IPsec and - ISAKMP), advising its peers (as per the meaning of Delete [ISAKMP, - section 3.15]) that the SAs have become useless. It will ignore - attempts at rekeying or connection startup thereafter, until it shuts - down. - - It would be better to have a Final-Contact notification, analogous to - Initial-Contact but indicating that no new negotiations should be - attempted until further notice. Initial-Contact actually could be - - - -Spencer & Redelmeier [Page 12] - -Internet Draft IKE Implementation Issues 26 Feb 2002 - - - used for shutdown notification (!), but in networks where connections - are intended to exist permanently, it seems likely to provoke - unwanted attempts to renegotiate the lost connections. - -5.3. Crashes - - Systems sometimes crash. Coping with the resulting loss of - information is easily the most difficult problem we have found in - implementing robust IPsec systems. - - When connections are intended to be permanent, it is simple to - specify renegotiation on reboot. With our approach to SA selection - (see section 4.3), this handles such cases robustly and well. We do - have to tell users that BOTH hosts should be set this way. In cases - where crashes are synchronized (e.g. by power interruptions), this - may result in simultaneous negotiations at reboot. We currently - allow both negotiations to proceed to completion, but our use-newest - selection method effectively ignores one connection or the other, and - when one of them rekeys, we notice that the new SAs replace those of - both old connections, and we then refrain from rekeying the other. - (This duplicate detection is desirable in any event, for robustness, - to ensure that the system converges on a reasonable state eventually - after it is perturbed by difficulties or bugs.) - - When connections are not permanent, the situation is less happy. One - particular situation in which we see problems is when a number of - "Road Warrior" hosts occasionally call in to a central server. The - server is normally configured not to initiate such connections, since - it does not know when the Road Warrior is available (or what IP - address it is using). Unfortunately, if the server crashes and - reboots, any Road Warriors then connected have a problem: they don't - know that the server has crashed, so they can't renegotiate, and the - server has forgotten both the connections and their (transient) IP - addresses, so it cannot renegotiate. - - We believe that the simplest answer to this problem is what John - Denker has dubbed "address inertia": the server makes a best-effort - attempt to remember (in nonvolatile storage) which connections were - active and what the far-end addresses were (and what the successful - proposal's parameters were), so that it can attempt renegotiation on - reboot. We have not implemented this yet, but intend to; Denker has - implemented it himself, although in a somewhat messy way, and reports - excellent results. - -5.4. Network Partitions - - A network partition, making the two ends unable to reach each other, - has many of the same characteristics as having the other end crash... - - - -Spencer & Redelmeier [Page 13] - -Internet Draft IKE Implementation Issues 26 Feb 2002 - - - until the network reconnects. It is desirable that recovery from - this be automatic. - - If the network reconnects before any rekeying attempts or other IKE - activities occurred, recovery is fully transparent, because the IKEs - have no idea that there was any problem. (Complaints such as ICMP - Host Unreachable messages are unauthenticated and hence cannot be - given much weight.) This fits the general mold of TCP/IP: if nobody - wanted to send any traffic, a network outage doesn't matter. - - If IKE activity did occur, the IKE implementation will discover that - the other end doesn't seem to be responding. The preferred response - to this depends on the nature of the connection. If it was intended - to be ephemeral (e.g. opportunistic encryption [OE]), closing it down - after a few retries is reasonable. If the other end is expected to - sometimes drop the connection without warning, it may not be - desirable to retry at all. (We support both these forms of - configurability, and indeed we also have a configuration option to - suppress rekeying entirely on one end.) - - If the connection was intended to be permanent, however, then - persistent attempts to re-establish it are appropriate. Some degree - of backoff is appropriate here, so that retries get less frequent as - the outage gets prolonged. Backoff should be limited, so that re- - established connectivity is not followed by a long delay before a - retry. Finally, after many retries (say 24 hours' worth), it may be - preferable to just declare the connection down and rely on manual - intervention to re-establish it, should this be desirable. We do not - yet fully support all this. - -5.5. Unknown SAs - - A more complete solution to crashes would be for an IPsec host to - note the arrival of ESP packets on an unknown IPsec SA, and report it - somehow to the other host, which can then decide to renegotiate. - This arguably might be preferable in any case--if the non-rebooted - host has no traffic to send, it does not care whether the connection - is intact--but delays and packet loss will be reduced if the - connection is renegotiated BEFORE there is traffic for it. So - unknown-SA detection is best reserved as a fallback method, with - address inertia used to deal with most such cases. - - A difficulty with unknown-SA detection is, just HOW should the other - host be notified? IKE provides no good way to do the notification: - Notification payloads (e.g., Initial-Contact) are unauthenticated - unless they are sent under protection of an ISAKMP SA. A "Security - Failures - Bad SPI" ICMP message [SECFAIL] is an interesting - alternative, but has the disadvantage of likewise being - - - -Spencer & Redelmeier [Page 14] - -Internet Draft IKE Implementation Issues 26 Feb 2002 - - - unauthenticated. It's fundamentally unlikely that there is a simple - solution to this, given that almost any way of arranging or checking - authentication for such a notification is costly. - - We think the best answer to this is a two-step approach. An - unauthenticated Initial-Contact or Security Failures - Bad SPI cannot - be taken as a reliable report of a problem, but can be taken as a - hint that a problem MIGHT exist. Then there needs to be some - reliable way of checking such hints, subject to rate limiting since - the checks are likely to be costly (and checking the same connection - repeatedly at short intervals is unlikely to be worthwhile anyway). - So the rebooted host sends the notification, and the non-rebooted - host--which still thinks it has a connection--checks whether the - connection still works, and renegotiates if not. - - Also, if an IPsec host which believes it has a connection to another - host sees an unsuccessful attempt by that host to negotiate a new - one, that is also a hint of possible problems, justifying a check and - possible renegotiation. ("Unsuccessful" here means a negotiation - failure due to lack of a satisfactory proposal. A failure due to - authentication failure suggests a denial-of-service attack by a third - party, rather than a genuine problem on the legitimate other end.) - As noted in section 4.2, it is possible for negotiations to succeed - or fail based on which end initiates them, and some robustness - against that is desirable. - - We have not yet decided what form the notification should take. IKE - Initial-Contact is an obvious possibility, but has some - disadvantages. It does not specify which connection has had - difficulties. Also, the specification [IKE section 4.6.3.3] refers - to "remote system" and "sending system" without clearly specifying - just what "system" means; in the case of a multi-homed host using - multiple forms of identification, the question is not trivial. - Initial-Contact does have the fairly-decisive advantage that it is - likely to convey the right general meaning even to an implementation - which does not do things exactly the way ours does. - - A more fundamental difficulty is what form the reliable check takes. - What is wanted is an "IKE ping", verifying that the ISAKMP SA is - still intact (it being unlikely that IPsec SAs have been lost while - the ISAKMP SA has not). The lack of such a facility is a serious - failing of IKE. An acknowledged Notification of some sort would be - ideal, but there is none at present. Some existing implementations - are known to use the private Notification values 30000 as ping and - 30002 as ping reply, and that seems the most attractive choice at - present. If it is not recognized, there will probably be no reply, - and the result will be an unnecessary renegotiation, so this needs - strict rate limiting. (Also, when a new connection is set up, it's - - - -Spencer & Redelmeier [Page 15] - -Internet Draft IKE Implementation Issues 26 Feb 2002 - - - probably worth determining by experiment whether the other end - supports IKE ping, and remembering that.) - - While we think this facility is desirable, and is about the best that - can be done with the poor tools available, we have not gotten very - far in implementation and cannot comment intelligently about how well - it works or interoperates. - -6. Misc. IKE Issues - -6.1. Groups 1 and 5 - - We have dropped support for the first Oakley Group (group 1), despite - it being officially mandatory, on the grounds that it is grossly too - weak to provide enough randomness for 3DES. There have been some - interoperability problems, mostly quite minor: ALMOST everyone - supports group 2 as well, although sometimes it has to be explicitly - configured. - - We also support the quasi-standard group 5 [GROUPS]. This has not - been seriously exercised yet, because historically we offered group 2 - first and almost everyone accepted it. We have recently changed to - offering group 5 first, and no difficulties have been reported. - -6.2. To PFS Or Not To PFS - - A persistent small interoperability problem is that the presence or - absence of PFS (for keys [IKE, section 5.5]) is neither negotiated - nor announced. We have it enabled by default, and successful - interoperation often requires having the other end turn it on in - their implementation, or having the FreeS/WAN end disable it. Almost - everyone supports it, but it's usually not the default, and - interoperability is often impossible unless the two ends somehow - reach prior agreement on it. - - We do not explicitly support the other flavor of PFS, for identities - [IKE, section 8], and this has caused no interoperability problems. - -6.3. Debugging Tools, Lack Thereof - - We find IKE lacking in basic debugging tools. Section 5.4, above, - notes that an IKE ping would be useful for connectivity verification. - It would also be extremely helpful for determining that UDP/500 - packets get back and forth successfully between the two ends, which - is often an important first step in debugging. - - It's also quite common to have IKE negotiate a connection - successfully, but to have some firewall along the way blocking ESP. - - - -Spencer & Redelmeier [Page 16] - -Internet Draft IKE Implementation Issues 26 Feb 2002 - - - Users find this mysterious and difficult to diagnose. We have no - immediate suggestions on what could be done about it. - -6.4. Terminology, Vagueness Thereof - - The terminology of IPsec needs work. We feel that both the - specifications and user-oriented documentation would be greatly - clarified by concise, intelligible names for certain concepts. - - We semi-consistently use "group" for the set of IPsec SAs which are - established in one direction by a single Quick Mode negotiation and - are used together to process a packet (e.g., an ESP SA plus an AH - SA), "connection" for the logical packet path provided by a - succession of pairs of groups (each rekeying providing a new pair, - one group in each direction), and "keying channel" for the - corresponding supervisory path provided by a sequence of ISAKMP SAs. - - We think it's a botch that "PFS" is used to refer to two very - different things, but we have no specific new terms to suggest, since - we only implement one kind of PFS and thus can just ignore the other. - -6.5. A Question of Identity - - One specification problem deserves note: exactly when can an existing - phase 1 negotiation be re-used for a new phase 2 negotiation, as IKE - [IKE, section 4] specifies? Presumably, when it connects the same - two "parties"... but exactly what is a "party"? - - As noted in section 5.4, in cases involving multi-homing and multiple - identities, it's not clear exactly what criteria are used for - deciding whether the intended far end for a new negotiation is the - same one as for a previous negotiation. Is it by Identification - Payload? By IP address? Or what? - - We currently use a somewhat-vague notion of "identity", basically - what gets sent in Identification Payloads, for this, and this seems - to be successful, but we think this needs better specification. - -6.6. Opportunistic Encryption - - Further IKE challenges appear in the context of Opportunistic - Encryption [OE], but operational experience with it is too limited as - yet for us to comment usefully right now. - -6.7. Authentication and RSA Keys - - We provide two IKE authentication methods: shared secrets ("pre- - shared keys") and RSA digital signatures. (A user-provided add-on - - - -Spencer & Redelmeier [Page 17] - -Internet Draft IKE Implementation Issues 26 Feb 2002 - - - package generalizes the latter to limited support for certificates; - we have not worked extensively with it ourselves yet and cannot - comment on it yet.) - - Shared secrets, despite their administrative difficulties, see - considerable use, and are also the method of last resort for - interoperability problems. - - For digital signatures, we have taken the somewhat unorthodox - approach of using "bare" RSA public keys, either supplied in - configuration files or fetched from DNS, rather than getting involved - in the complexity of certificates. We encode our RSA public keys - using the DNS KEY encoding [DNSRSA] (aka "RFC 2537", although that - RFC is now outdated), which has given us no difficulties and which we - highly recommend. We have seen two difficulties in connection with - RSA keys, however. - - First, while a number of IPsec implementations are able to take - "bare" RSA public keys, each one seems to have its own idea of what - format should be used for transporting them. We've had little - success with interoperability here, mostly because of key-format - issues; the implementations generally WILL interoperate successfully - if you can somehow get an RSA key into them at all, but that's hard. - X.509 certificates seem to be the lowest (!) common denominator for - key transfer. - - Second, although the content of RSA public keys has been stable, - there has been a small but subtle change over time in the content of - RSA private keys. The "internal modulus", used to compute the - private exponent "d" from the public exponent "e" (or vice-versa) was - originally [RSA] [PKCS1v1] [SCHNEIER] specified to be (p-1)*(q-1), - where p and q are the two primes. However, more recent definitions - [PKCS1v2] call it "lambda(n)" and define it to be lcm(p-1, q-1); this - appears to be a minor optimization. The result is that private keys - generated with the new definition often fail consistency checks in - implementations using the old definition. Fortunately, it is seldom - necessary to move private keys around. Our software now consistently - uses the new definition (and thus will accept keys generated with - either definition), but our key generator also has an option to - generate old-definition keys, for the benefit of users who upgrade - their networks incrementally. - -6.8. Misc. Snags - - Nonce size is another characteristic that is neither negotiated nor - announced but that the two ends must somehow be able to agree on. - Our software accepts anything between 8 and 256, and defaults to 16. - These numbers were chosen rather arbitrarily, but we have seen no - - - -Spencer & Redelmeier [Page 18] - -Internet Draft IKE Implementation Issues 26 Feb 2002 - - - interoperability failures here. - - Nothing in the ISAKMP [ISAKMP] or IKE [IKE] specifications says - explicitly that a normal Message ID must be non-zero, but a zero - Message ID in fact causes failures. - - Similarly, there is nothing in the specs which says that ISAKMP - cookies must be non-zero, but zero cookies will in fact cause - trouble. - -7. Security Considerations - - Since this document discusses aspects of building robust and - interoperable IPsec implementations, security considerations permeate - it. - -8. References - - [AH] Kent, S., and Atkinson, R., "IP Authentication Header", - RFC 2402, Nov 1998. - - [CIPHERS] Pereira, R., and Adams, R., "The ESP CBC-Mode Cipher - Algorithms", RFC 2451, Nov 1998. - - [CRACK] Electronic Frontier Foundation, "Cracking DES: Secrets of - Encryption Research, Wiretap Politics and Chip Design", - O'Reilly 1998, ISBN 1-56592-520-3. - - [DES] Madson, C., and Doraswamy, N., "The ESP DES-CBC Cipher - Algorithm", RFC 2405, Nov 1998. - - [DNSRSA] D. Eastlake 3rd, "RSA/SHA-1 SIGs and RSA KEYs in the - Domain Name System (DNS)", RFC 3110, May 2001. - - [ESP] Kent, S., and Atkinson, R., "IP Encapsulating Security - Payload (ESP)", RFC 2406, Nov 1998. - - [GROUPS] Kivinen, T., and Kojo, M., "More MODP Diffie-Hellman - groups for IKE", <draft-ietf-ipsec-ike-modp- - groups-04.txt>, 13 Dec 2001 (work in progress). - - [IKE] Harkins, D., and Carrel, D., "The Internet Key Exchange - (IKE)", RFC 2409, Nov 1998. - - [IPSEC] Kent, S., and Atkinson, R., "Security Architecture for the - Internet Protocol", RFC 2401, Nov 1998. - - - - - -Spencer & Redelmeier [Page 19] - -Internet Draft IKE Implementation Issues 26 Feb 2002 - - - [ISAKMP] Maughan, D., Schertler, M., Schneider, M., and Turner, J., - "Internet Security Association and Key Management Protocol - (ISAKMP)", RFC 2408, Nov 1998. - - [OE] Richardson, M., Redelmeier, D. H., and Spencer, H., "A - method for doing opportunistic encryption with IKE", - <draft-richardson-ipsec-opportunistic-06.txt>, 21 Feb 2002 - (work in progress). - - [PKCS1v1] Kaliski, B., "PKCS #1: RSA Encryption, Version 1.5", RFC - 2313, March 1998. - - [PKCS1v2] Kaliski, B., and Staddon, J., "PKCS #1: RSA Cryptography - Specifications, Version 2.0", RFC 2437, Oct 1998. - - [PFKEY] McDonald, D., Metz, C., and Phan, B., "PF_KEY Key - Management API, Version 2", RFC 2367, July 1998. - - [REKEY] Tim Jenkins, "IPsec Re-keying Issues", <draft-jenkins- - ipsec-rekeying-06.txt>, 2 May 2000 (draft expired, work no - longer in progress). - - [REPLAY] Krywaniuk, A., "Using Isakmp Message Ids for Replay - Protection", <draft-krywaniuk-ipsec-antireplay-00.txt>, 9 - July 2001 (work in progress). - - [RSA] Rivest, R.L., Shamir, A., and Adleman, L., "A Method for - Obtaining Digital Signatures and Public-Key - Cryptosystems", Communications of the ACM v21n2, Feb 1978, - p. 120. - - [SCHNEIER] Bruce Schneier, "Applied Cryptography", 2nd ed., Wiley - 1996, ISBN 0-471-11709-9. - - [SECFAIL] Karn, P., and Simpson, W., "ICMP Security Failures - Messages", RFC 2521, March 1999. - -Authors' Addresses - - Henry Spencer - SP Systems - Box 280 Stn. A - Toronto, Ont. M5W1B2 - Canada - - henry@spsystems.net - 416-690-6561 - - - - -Spencer & Redelmeier [Page 20] - -Internet Draft IKE Implementation Issues 26 Feb 2002 - - - D. Hugh Redelmeier - Mimosa Systems Inc. - 29 Donino Ave. - Toronto, Ont. M4N2W6 - Canada - - hugh@mimosa.com - 416-482-8253 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -Spencer & Redelmeier [Page 21] - -Internet Draft IKE Implementation Issues 26 Feb 2002 - - -Full Copyright Statement - - Copyright (C) The Internet Society 2002. All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implmentation 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. - - - - - - - - - - - - - - - - - - - - - - - - -Spencer & Redelmeier [Page 22] - diff --git a/doc/src/draft-richardson-ipsec-opportunistic.html b/doc/src/draft-richardson-ipsec-opportunistic.html deleted file mode 100644 index 87a13365a..000000000 --- a/doc/src/draft-richardson-ipsec-opportunistic.html +++ /dev/null @@ -1,2456 +0,0 @@ -<html><head><title>Opportunistic Encryption using The Internet Key Exchange (IKE)</title> -<STYLE type='text/css'> - .title { color: #990000; font-size: 22px; line-height: 22px; font-weight: bold; text-align: right; - font-family: helvetica, arial, sans-serif } - .filename { color: #666666; font-size: 18px; line-height: 28px; font-weight: bold; text-align: right; - font-family: helvetica, arial, sans-serif } - p.copyright { color: #000000; font-size: 10px; - font-family: verdana, charcoal, helvetica, arial, sans-serif } - p { margin-left: 2em; margin-right: 2em; } - li { margin-left: 3em; } - ol { margin-left: 2em; margin-right: 2em; } - ul.text { margin-left: 2em; margin-right: 2em; } - pre { margin-left: 3em; color: #333333 } - ul.toc { color: #000000; line-height: 16px; - font-family: verdana, charcoal, helvetica, arial, sans-serif } - H3 { color: #333333; font-size: 16px; line-height: 16px; font-family: helvetica, arial, sans-serif } - H4 { color: #000000; font-size: 14px; font-family: helvetica, arial, sans-serif } - TD.header { color: #ffffff; font-size: 10px; font-family: arial, helvetica, san-serif; valign: top } - TD.author-text { color: #000000; font-size: 10px; - font-family: verdana, charcoal, helvetica, arial, sans-serif } - TD.author { color: #000000; font-weight: bold; margin-left: 4em; font-size: 10px; font-family: verdana, charcoal, helvetica, arial, sans-serif } - A:link { color: #990000; font-weight: bold; - font-family: MS Sans Serif, verdana, charcoal, helvetica, arial, sans-serif } - A:visited { color: #333333; font-weight: bold; - font-family: MS Sans Serif, verdana, charcoal, helvetica, arial, sans-serif } - A:name { color: #333333; font-weight: bold; - font-family: MS Sans Serif, verdana, charcoal, helvetica, arial, sans-serif } - .link2 { color:#ffffff; font-weight: bold; text-decoration: none; - font-family: monaco, charcoal, geneva, MS Sans Serif, helvetica, monotype, verdana, sans-serif; - font-size: 9px } - .RFC { color:#666666; font-weight: bold; text-decoration: none; - font-family: monaco, charcoal, geneva, MS Sans Serif, helvetica, monotype, verdana, sans-serif; - font-size: 9px } - .hotText { color:#ffffff; font-weight: normal; text-decoration: none; - font-family: charcoal, monaco, geneva, MS Sans Serif, helvetica, monotype, verdana, sans-serif; - font-size: 9px } -</style> -</head> -<body bgcolor="#ffffff" text="#000000" alink="#000000" vlink="#666666" link="#990000"> -<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> -<table width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table width="100%" border="0" cellpadding="2" cellspacing="1"> -<tr valign="top"><td width="33%" bgcolor="#666666" class="header">Independent submission</td><td width="33%" bgcolor="#666666" class="header">M. Richardson</td></tr> -<tr valign="top"><td width="33%" bgcolor="#666666" class="header">Internet-Draft</td><td width="33%" bgcolor="#666666" class="header">SSW</td></tr> -<tr valign="top"><td width="33%" bgcolor="#666666" class="header">Expires: November 19, 2003</td><td width="33%" bgcolor="#666666" class="header">D. Redelmeier</td></tr> -<tr valign="top"><td width="33%" bgcolor="#666666" class="header"> </td><td width="33%" bgcolor="#666666" class="header">Mimosa</td></tr> -<tr valign="top"><td width="33%" bgcolor="#666666" class="header"> </td><td width="33%" bgcolor="#666666" class="header">May 21, 2003</td></tr> -</table></td></tr></table> -<div align="right"><font face="monaco, MS Sans Serif" color="#990000" size="+3"><b><br><span class="title">Opportunistic Encryption using The Internet Key Exchange (IKE)</span></b></font></div> -<div align="right"><font face="monaco, MS Sans Serif" color="#666666" size="+2"><b><span class="filename">draft-richardson-ipsec-opportunistic-11.txt</span></b></font></div> -<font face="verdana, helvetica, arial, sans-serif" size="2"> - -<h3>Status of this Memo</h3> -<p> -This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.</p> -<p> -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.</p> -<p> -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."</p> -<p> -The list of current Internet-Drafts can be accessed at -<a href='http://www.ietf.org/ietf/1id-abstracts.txt'>http://www.ietf.org/ietf/1id-abstracts.txt</a>.</p> -<p> -The list of Internet-Draft Shadow Directories can be accessed at -<a href='http://www.ietf.org/shadow.html'>http://www.ietf.org/shadow.html</a>.</p> -<p> -This Internet-Draft will expire on November 19, 2003.</p> - -<h3>Copyright Notice</h3> -<p> -Copyright (C) The Internet Society (2003). All Rights Reserved.</p> - -<h3>Abstract</h3> - -<p> -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. - -</p> -<p> -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. - -</p> -<p> -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. - -</p> -<p> -This document is offered up as an Informational RFC. - -</p><a name="toc"><br><hr size="1" shade="0"></a> -<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> -<h3>Table of Contents</h3> -<ul compact class="toc"> -<b><a href="#anchor1">1.</a> -Introduction<br></b> -<b><a href="#anchor6">2.</a> -Overview<br></b> -<b><a href="#anchor13">3.</a> -Specification<br></b> -<b><a href="#anchor31">4.</a> -Impacts on IKE<br></b> -<b><a href="#anchor38">5.</a> -DNS issues<br></b> -<b><a href="#anchor42">6.</a> -Network address translation interaction<br></b> -<b><a href="#anchor46">7.</a> -Host implementations<br></b> -<b><a href="#anchor47">8.</a> -Multi-homing<br></b> -<b><a href="#anchor48">9.</a> -Failure modes<br></b> -<b><a href="#anchor52">10.</a> -Unresolved issues<br></b> -<b><a href="#anchor54">11.</a> -Examples<br></b> -<b><a href="#securityconsiderations">12.</a> -Security considerations<br></b> -<b><a href="#anchor79">13.</a> -IANA Considerations<br></b> -<b><a href="#anchor80">14.</a> -Acknowledgments<br></b> -<b><a href="#rfc.references1">§</a> -Normative references<br></b> -<b><a href="#rfc.authors">§</a> -Authors' Addresses<br></b> -<b><a href="#rfc.copyright">§</a> -Full Copyright Statement<br></b> -</ul> -<br clear="all"> - -<a name="anchor1"><br><hr size="1" shade="0"></a> -<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> -<a name="rfc.section.1"></a><h3>1. Introduction</h3> - -<a name="rfc.section.1.1"></a><h4><a name="anchor2">1.1</a> Motivation</h4> - -<p> -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. - -</p> -<p> -This document describes opportunistic encryption as designed and -mostly implemented by the Linux FreeS/WAN project. -For project information, see http://www.freeswan.org. - -</p> -<p> -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 <a href="#RFC1984">[4]</a>. -The Linux FreeS/WAN project attempts to provide a practical means to implement this policy. - -</p> -<p> -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. - -</p> -<p> -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. - -</p> -<p> -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. - -</p> -<p> -This document describes the infrastructure to permit deployment of -Opportunistic Encryption. - -</p> -<p> -The term S/WAN is a trademark of RSA Data Systems, and is used with permission -by this project. - -</p> -<a name="rfc.section.1.2"></a><h4><a name="anchor3">1.2</a> Types of network traffic</h4> - -<p> - To aid in understanding the relationship between security processing and IPsec - we divide network traffic into four categories: - -<blockquote class="text"><dl> -<dt>* Deny:</dt> -<dd> networks to which traffic is always forbidden. -</dd> -<dt>* Permit:</dt> -<dd> networks to which traffic in the clear is permitted. -</dd> -<dt>* Opportunistic tunnel:</dt> -<dd> networks to which traffic is encrypted if possible, but otherwise is in the clear - or fails depending on the default policy in place. - -</dd> -<dt>* Configured tunnel:</dt> -<dd> networks to which traffic must be encrypted, and traffic in the clear is never permitted. -</dd> -</dl></blockquote><p> -</p> -<p> -Traditional firewall devices handle the first two categories. No authentication is required. -The permit policy is currently the default on the Internet. - -</p> -<p> -This document describes the third category - opportunistic tunnel, which is -proposed as the new default for the Internet. - -</p> -<p> - 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. - -</p> -<p> -Current Virtual Private Networks can often be replaced by an "OE paranoid" -policy as described herein. - -</p> -<a name="rfc.section.1.3"></a><h4><a name="anchor4">1.3</a> Peer authentication in opportunistic encryption</h4> - -<p> - 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. - -</p> -<p> - 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. - -</p> -<p> -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. - -</p> -<p> - Peers are, therefore, authenticated with DNSSEC when available. Local policy -determines how much trust to extend when DNSSEC is not available. - -</p> -<p> - 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. - -</p> -<p> - 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. - -</p> -<a name="rfc.section.1.4"></a><h4><a name="anchor5">1.4</a> Use of RFC2119 terms</h4> - -<p> - 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 <a href="#RFC2119">[5]</a> -</p> -<a name="anchor6"><br><hr size="1" shade="0"></a> -<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> -<a name="rfc.section.2"></a><h3>2. Overview</h3> - -<a name="rfc.section.2.1"></a><h4><a name="anchor7">2.1</a> Reference diagram</h4> -<br><hr size="1" shade="0"> -<a name="networkdiagram"></a> - -<p>The following network diagram is used in the rest of - this document as the canonical diagram: -</p></font><pre> - [Q] [R] - . . AS2 - [A]----+----[SG-A].......+....+.......[SG-B]-------[B] - | ...... - AS1 | ..PI.. - | ...... - [D]----+----[SG-D].......+....+.......[C] AS3 - - - </pre><font face="verdana, helvetica, arial, sans-serif" size="2"> - -<p> -</p><table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Reference Network Diagram </b></font><br></td></tr></table><hr size="1" shade="0"> - -<p> - 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"). - -</p> -<a name="rfc.section.2.2"></a><h4><a name="anchor8">2.2</a> Terminology</h4> - -<p> - The following terminology is used in this document: - -</p> -<blockquote class="text"><dl> -<dt>Security gateway:</dt> -<dd> a system that performs IPsec tunnel - mode encapsulation/decapsulation. [SG-x] in the diagram. -</dd> -<dt>Alice:</dt> -<dd> node [A] in the diagram. When an IP address is needed, this is 192.1.0.65. -</dd> -<dt>Bob:</dt> -<dd> node [B] in the diagram. When an IP address is needed, this is 192.2.0.66. -</dd> -<dt>Carol:</dt> -<dd> node [C] in the diagram. When an IP address is needed, this is 192.1.1.67. -</dd> -<dt>Dave:</dt> -<dd> node [D] in the diagram. When an IP address is needed, this is 192.3.0.68. -</dd> -<dt>SG-A:</dt> -<dd> Alice's security gateway. Internally it is 192.1.0.1, externally it is 192.1.1.4. -</dd> -<dt>SG-B:</dt> -<dd> Bob's security gateway. Internally it is 192.2.0.1, externally it is 192.1.1.5. -</dd> -<dt>SG-D:</dt> -<dd> Dave's security gateway. Also Alice's backup security gateway. Internally it is 192.3.0.1, externally it is 192.1.1.6. -</dd> -<dt>-</dt> -<dd> A single dash represents clear-text datagrams. -</dd> -<dt>=</dt> -<dd> An equals sign represents phase 2 (IPsec) cipher-text - datagrams. -</dd> -<dt>~</dt> -<dd> A single tilde represents clear-text phase 1 datagrams. -</dd> -<dt>#</dt> -<dd> A hash sign represents phase 1 (IKE) cipher-text - datagrams. -</dd> -<dt>.</dt> -<dd> A period represents an untrusted network of unknown - type. -</dd> -<dt>Configured tunnel:</dt> -<dd> 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. -</dd> -<dt>Road warrior tunnel:</dt> -<dd> 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. -</dd> -<dt>Anonymous encryption:</dt> -<dd> - the process of encrypting a session without any knowledge of who the - other parties are. No authentication of identities is done. -</dd> -<dt>Opportunistic encryption:</dt> -<dd> - the process of encrypting a session with authenticated knowledge of - who the other parties are. -</dd> -<dt>Lifetime:</dt> -<dd> - the period in seconds (bytes or datagrams) for which a security - association will remain alive before needing to be re-keyed. -</dd> -<dt>Lifespan:</dt> -<dd> - 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. -</dd> -<dt>Phase 1 SA:</dt> -<dd> an ISAKMP/IKE security association sometimes - referred to as a keying channel. -</dd> -<dt>Phase 2 SA:</dt> -<dd> an IPsec security association. -</dd> -<dt>Tunnel:</dt> -<dd> another term for a set of phase 2 SA (one in each direction). -</dd> -<dt>NAT:</dt> -<dd> Network Address Translation - (see <a href="#RFC2663">[20]</a>). -</dd> -<dt>NAPT:</dt> -<dd> Network Address and Port Translation - (see <a href="#RFC2663">[20]</a>). -</dd> -<dt>AS:</dt> -<dd> an autonomous system (AS) is a group of systems (a network) that - are under the administrative control of a single organization. -</dd> -<dt>Default-free zone:</dt> -<dd> - 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. - -</dd> -</dl></blockquote><p> -<a name="rfc.section.2.3"></a><h4><a name="anchor9">2.3</a> Model of operation</h4> - -<p> -The opportunistic encryption security gateway (OE gateway) is a regular -gateway node as described in <a href="#RFC0791">[2]</a> section 2.4 and -<a href="#RFC1009">[3]</a> with the additional capabilities described here and -in <a href="#RFC2401">[7]</a>. -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. - -</p> -<a name="rfc.section.2.3.1"></a><h4><a name="anchor10">2.3.1</a> Tunnel authorization</h4> - -<p> -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 <a href="#TXT">Use of TXT delegation record</a>). 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. - -</p> -<a name="rfc.section.2.3.2"></a><h4><a name="anchor11">2.3.2</a> Tunnel end-point discovery</h4> - -<p> -The authorization resource record also provides the address or name of the tunnel -end point which should be used. - -</p> -<p> -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. - -</p> -<p> -Origin and integrity protection of the resource records is provided by -DNSSEC (<a href="#RFC2535">[16]</a>). <a href="#nodnssec">Restriction on unauthenticated TXT delegation records</a> -documents an optional restriction on the tunnel end point if DNSSEC signatures -are not available for the relevant records. - -</p> -<a name="rfc.section.2.3.3"></a><h4><a name="anchor12">2.3.3</a> Caching of authorization results</h4> - -<p> -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. - -</p> -<p> -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. - -</p> -<p> -The cache is timed out periodically, as described in <a href="#teardown">Renewal and teardown</a>. -This removes entries that are no longer -being used and permits the discovery of changes in authorization policy. - -</p> -<a name="anchor13"><br><hr size="1" shade="0"></a> -<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> -<a name="rfc.section.3"></a><h3>3. Specification</h3> - -<p> -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 <a href="#RFC2367">[6]</a>.) -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. - -</p> -<a name="rfc.section.3.1"></a><h4><a name="anchor14">3.1</a> Datagram state machine</h4> - -<p> -Let the OE gateway maintain a collection of objects -- a superset of the -security policy database (SPD) specified in <a href="#RFC2401">[7]</a>. 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. - -</p> -<a name="rfc.section.3.1.1"></a><h4><a name="anchor15">3.1.1</a> Non-existent policy</h4> - -<p> -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. - - -</p> -<a name="rfc.section.3.1.2"></a><h4><a name="anchor16">3.1.2</a> Hold policy</h4> - -<p> -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. - -</p> -<p> -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. - -</p> -<a name="rfc.section.3.1.3"></a><h4><a name="anchor17">3.1.3</a> Pass-through policy</h4> - -<p> -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. - -</p> -<a name="rfc.section.3.1.4"></a><h4><a name="anchor18">3.1.4</a> Deny policy</h4> - -<p> -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). - -</p> -<a name="rfc.section.3.1.5"></a><h4><a name="anchor19">3.1.5</a> Encrypt policy</h4> - -<p> -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. - -</p> -<p> -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. - -</p> -<p> -All states may be created directly by the keying daemon while acting as a -responder. - -</p> -<a name="rfc.section.3.2"></a><h4><a name="initclasses">3.2</a> Keying state machine - initiator</h4> - -<p> -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. - -</p> -<p> -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. - -</p> -<p> -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. - -</p> -<p> -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. - -</p> -<p> -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. - -</p> -<p> -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 -(<a href="#RFC2407">[8]</a>, -<a href="#RFC2408">[9]</a> and <a href="#RFC2409">[10]</a> 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. - -</p> -<p> -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. - -</p> -<p> -Finally, the retransmits and recursive lookups that are normal for DNS are -not included in this description of the state machine. - -</p> -<a name="rfc.section.3.2.1"></a><h4><a name="anchor20">3.2.1</a> Nonexistent connection</h4> - -<p> -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. - -</p> -<p>Failure to find an appropriate connection class results in an -administrator defined default. - -</p> -<p> -In each case, when the initiator finds an appropriate class for the new flow, -an instance connection is made of the class which matched. - -</p> -<a name="rfc.section.3.2.2"></a><h4><a name="anchor21">3.2.2</a> Clear-text connection</h4> - -<p> -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. - -</p> -<p> -Timing out is the only way to leave this state -(see <a href="#expiring">Expiring connection</a>). - -</p> -<a name="rfc.section.3.2.3"></a><h4><a name="anchor22">3.2.3</a> Deny connection</h4> - -<p> -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. - -</p> -<p> -Timing out is the only way to leave this state -(see <a href="#expiring">Expiring connection</a>). - -</p> -<a name="rfc.section.3.2.4"></a><h4><a name="anchor23">3.2.4</a> Potential OE connection</h4> - -<p> -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. - -</p> -<p> -In addition, when making a transition into this state, DNS lookup is done in -the reverse-map for a TXT delegation resource record (see <a href="#TXT">Use of TXT delegation record</a>). -The lookup key is the destination address of the flow. - -</p> -<p> -There are three ways to exit this state: - -<ol class="text"> -<li>DNS lookup finds a TXT delegation resource record. -</li> -<li>DNS lookup does not find a TXT delegation resource record. -</li> -<li>DNS lookup times out. -</li> -</ol><p> -</p> -<p> -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: - -<ol class="text"> -<li>DNS finds an appropriate resource record -</li> -<li>It is properly formatted according to <a href="#TXT">Use of TXT delegation record</a> -</li> -<li> if DNSSEC is enabled, then the signature has been vouched for. -</li> -</ol><p> - -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. - -</p> -<p> -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. - -</p> -<p> -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. - -</p> -<a name="rfc.section.3.2.4.1"></a><h4><a name="nodnssec">3.2.4.1</a> Restriction on unauthenticated TXT delegation records</h4> - -<p> -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. - -</p> -<a name="rfc.section.3.2.5"></a><h4><a name="anchor24">3.2.5</a> Pending OE connection</h4> - -<p> -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. - -</p> -<p> -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. - -</p> -<p> -Three failures have caused significant problems. They are clearly not the -only possible failures from keying. - -</p> -<p> -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. - -</p> -<p> -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. - -</p> -<p> -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. - -</p> -<p> -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. - -</p> -<p> -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.) - -</p> -<a name="rfc.section.3.2.6"></a><h4><a name="keyed">3.2.6</a> Keyed connection</h4> - -<p> -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. - -</p> -<p> -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. - -</p> -<p> -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. - -</p> -<p> -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. - -</p> -<a name="rfc.section.3.2.7"></a><h4><a name="expiring">3.2.7</a> Expiring connection</h4> - -<p> -The initiator will periodically place each of the deny, clear-text, and keyed -connections into this -sub-state. See <a href="#teardown">Renewal and teardown</a> 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. - -</p> -<p> -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 <a href="#RFC1034">[12]</a> 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. - -</p> -<p> -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. - -</p> -<p> -Also note that the policy at the forwarding plane is not updated unless there -is a conclusion that there should be a change. - -</p> -<a name="rfc.section.3.2.8"></a><h4><a name="anchor25">3.2.8</a> Expired connection</h4> - -<p> -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. - -</p> -<p> -The initiator sends an ISAKMP/IKE delete to clean up the phase 2 SAs as described in -<a href="#teardown">Renewal and teardown</a>. - -</p> -<p> -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. - -</p> -<a name="rfc.section.3.3"></a><h4><a name="anchor26">3.3</a> Keying state machine - responder</h4> - -<p> -The responder has a set of objects identical to those of the initiator. - -</p> -<p> -The responder receives an invitation to create a keying channel from an initiator. - -</p> -<a name="rfc.section.3.3.1"></a><h4><a name="anchor27">3.3.1</a> Unauthenticated OE peer</h4> - -<p> -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 <a href="#RFC2407">[8]</a> section -4.6.2.1.) - -</p> -<p> -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. - -</p> -<p> -Successful authentication of the peer results in a transition to the -authenticated OE Peer state. - -</p> -<p> -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. - -</p> -<a name="rfc.section.3.3.2"></a><h4><a name="anchor28">3.3.2</a> Authenticated OE Peer</h4> - -<p> -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. - -</p> -<p> -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. - -</p> -<p> -If an identical connection is not found, then the responder makes the transition according to the -rules given for the initiator. - -</p> -<p> -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. - -</p> -<a name="rfc.section.3.4"></a><h4><a name="teardown">3.4</a> Renewal and teardown</h4> - -<a name="rfc.section.3.4.1"></a><h4><a name="anchor29">3.4.1</a> Aging</h4> - -<p> -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. - -</p> -<p> -There are two methods for removing tunnels: explicit deletion or expiry. - -</p> -<p> -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. - -</p> -<p> -The tunnel expiry method, simply allows the IKE daemon to -expire normally without attempting to re-key it. - -</p> -<p> -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. - -</p> -<p> -Set a short initial (soft) lifespan of 1 minute since many net flows last -only a few seconds. - -</p> -<p> -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. - -</p> -<p> -The expiring state in the key management -system (see <a href="#expiring">Expiring connection</a>) implements these timeouts. -The timer above may be in the forwarding plane, -but then it must be re-settable. - -</p> -<p> -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. - -</p> -<p> -A multi-step back-off algorithm is not considered worth the effort here. - -</p> -<p> -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. - -</p> -<a name="rfc.section.3.4.2"></a><h4><a name="anchor30">3.4.2</a> Teardown and cleanup</h4> - -<p> -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. - -</p> -<p> -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. - -</p> -<p> -Tunnels are to be considered as bidirectional entities, even though the -low-level protocols don't treat them this way. - -</p> -<p> -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.) - -</p> -<p> -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. - -</p> -<a name="anchor31"><br><hr size="1" shade="0"></a> -<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> -<a name="rfc.section.4"></a><h3>4. Impacts on IKE</h3> - -<a name="rfc.section.4.1"></a><h4><a name="anchor32">4.1</a> ISAKMP/IKE protocol</h4> - -<p> - 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. - -</p> -<p> - 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. - -</p> -<p> - 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. - -</p> -<a name="rfc.section.4.2"></a><h4><a name="anchor33">4.2</a> Gateway discovery process</h4> - -<p> - 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. - -</p> -<p> - 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. - -</p> -<p> - Use of an asynchronous DNS lookup will also permit overlap of DNS lookups with - some of the protocol steps. - -</p> -<a name="rfc.section.4.3"></a><h4><a name="anchor34">4.3</a> Self identification</h4> - -<p> - SG-A will have to establish its identity. Use an - IPv4 ID in phase 1. - -</p> -<p> 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 <a href="#fqdn">Use of FQDN IDs</a> - for more details and restrictions. - -</p> -<a name="rfc.section.4.4"></a><h4><a name="anchor35">4.4</a> Public key retrieval process</h4> - -<p> - 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. - -</p> -<p> - 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. - -</p> -<a name="rfc.section.4.5"></a><h4><a name="anchor36">4.5</a> Interactions with DNSSEC</h4> - -<p> - 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. - -</p> -<p> - To distinguish between an authenticated and an unauthenticated DNS - resource record, a stub resolver capable of returning DNSSEC - information MUST be used. - -</p> -<a name="rfc.section.4.6"></a><h4><a name="anchor37">4.6</a> Required proposal types</h4> - -<a name="rfc.section.4.6.1"></a><h4><a name="phase1id">4.6.1</a> Phase 1 parameters</h4> - -<p> - Main mode MUST be used. - -</p> -<p> - 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. - <a href="#RFC3526">[11]</a> -</p> -<p> - 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. - -</p> -<p> - 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. - -</p> -<p> - 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 <a href="#fqdn">Use of FQDN IDs</a>.) 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). - -</p> -<a name="rfc.section.4.6.2"></a><h4><a name="phase2id">4.6.2</a> Phase 2 parameters</h4> - -<p> - SG-A MUST propose a tunnel between Alice and Bob, using 3DES-CBC - mode, MD5 or SHA1 authentication. Perfect Forward Secrecy MUST be specified. - -</p> -<p> - Tunnel mode MUST be used. - -</p> -<p> - Identities MUST be ID_IPV4_ADDR_SUBNET with the mask being /32. - -</p> -<p> - 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. - -</p> -<p> - Compression SHOULD NOT be mandatory. It may be offered as an option. - -</p> -<a name="anchor38"><br><hr size="1" shade="0"></a> -<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> -<a name="rfc.section.5"></a><h3>5. DNS issues</h3> - -<a name="rfc.section.5.1"></a><h4><a name="KEY">5.1</a> Use of KEY record</h4> - -<p> - 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 <a href="#RFC2535">RFC 2535</a>[16]. - -</p> -<p> -<p>For example: -</p></font><pre> -KEY 0x4200 4 1 AQNJjkKlIk9...nYyUkKK8 -</pre><font face="verdana, helvetica, arial, sans-serif" size="2"> - -<blockquote class="text"><dl> -<dt>0x4200:</dt> -<dd> 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. -</dd> -<dt>4:</dt> -<dd>This indicates that this key is for use by IPsec. -</dd> -<dt>1:</dt> -<dd>An RSA key is present. -</dd> -<dt>AQNJjkKlIk9...nYyUkKK8:</dt> -<dd>The public key of the host as described in <a href="#RFC3110">[17]</a>. -</dd> -</dl></blockquote><p> -</p> -<p>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. - -</p> -<a name="rfc.section.5.2"></a><h4><a name="TXT">5.2</a> Use of TXT delegation record</h4> - -<p> -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. - -</p> -<p> - If Alice's address is P.Q.R.S, then she can authorize another node to - act on her behalf by publishing records at: - </p> -</font><pre> -S.R.Q.P.in-addr.arpa - </pre><font face="verdana, helvetica, arial, sans-serif" size="2"> -<p> - -</p> -<p> - The contents of the resource record are expected to be a string that - uses the following syntax, as suggested in <a href="#RFC1464">[15]</a>. - (Note that the reply to query may include other TXT resource - records used by other applications.) - - <br><hr size="1" shade="0"> -<a name="txtformat"></a> -</p> -</font><pre> -X-IPsec-Server(P)=A.B.C.D KEY - </pre><font face="verdana, helvetica, arial, sans-serif" size="2"> -<p> -<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Format of reverse delegation record </b></font><br></td></tr></table><hr size="1" shade="0"> - -</p> -<blockquote class="text"><dl> -<dt>P:</dt> -<dd> Specifies a precedence for this record. This is - similar to MX record preferences. Lower numbers have stronger - preference. - -</dd> -<dt>A.B.C.D:</dt> -<dd> Specifies the IP address of the Security Gateway - for this client machine. - -</dd> -<dt>KEY:</dt> -<dd> 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. - -</dd> -</dl></blockquote><p> -<p> - The pieces of the record are separated by any whitespace - (space, tab, newline, carriage return). An ASCII space SHOULD - be used. - -</p> -<p> - 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. - - <br><hr size="1" shade="0"> -<a name="txtfqdnformat"></a> -</p> -</font><pre> -X-IPsec-Server(P)=@FQDN KEY - </pre><font face="verdana, helvetica, arial, sans-serif" size="2"> -<p> -<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Format of reverse delegation record (FQDN version) </b></font><br></td></tr></table><hr size="1" shade="0"> - -</p> -<blockquote class="text"><dl> -<dt>P:</dt> -<dd> Is as above. - -</dd> -<dt>FQDN:</dt> -<dd> Specifies the FQDN that the Security Gateway - will identify itself with. - -</dd> -<dt>KEY:</dt> -<dd> Is the encoded RSA Public key of the Security - Gateway. -</dd> -</dl></blockquote><p> -<p> - 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. - -</p> -<a name="rfc.section.5.2.1"></a><h4><a name="anchor39">5.2.1</a> Long TXT records</h4> - -<p> - When packed into transport format, TXT records which are longer than 255 - characters are divided into smaller <character-strings>. - (See <a href="#RFC1035">[13]</a> 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. - -</p> -<a name="rfc.section.5.2.2"></a><h4><a name="anchor40">5.2.2</a> Choice of TXT record</h4> - -<p> - It has been suggested to use the KEY, OPT, CERT, or KX records - instead of a TXT record. None is satisfactory. - -</p> -<p> 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. - -</p> -<p> OPT resource records, as defined in <a href="#RFC2671">[14]</a> 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. - -</p> -<p> - CERT records <a href="#RFC2538">[18]</a> 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. - -</p> -<p> - 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. - -</p> -<p> - KX records are ideally suited for use instead of TXT records, but had not been deployed at - the time of implementation. - -</p> -<a name="rfc.section.5.3"></a><h4><a name="fqdn">5.3</a> Use of FQDN IDs</h4> - -<p> - 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. - -</p> -<p> - 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. - -</p> -<p> - This method can also be used when the external address of SG-A is - dynamic. - -</p> -<p> - 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. -</p> -<p>However, Alice must still delegate to herself if she wishes others to - initiate OE to her. See <a href="#txtfqdnformat">Format of reverse delegation record (FQDN version)</a>. - -</p> -<a name="rfc.section.5.4"></a><h4><a name="anchor41">5.4</a> Key roll-over</h4> - -<p> -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. - -</p> -<p> -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. - -</p> -<p> -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. - -</p> -<a name="anchor42"><br><hr size="1" shade="0"></a> -<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> -<a name="rfc.section.6"></a><h3>6. Network address translation interaction</h3> - -<p> - 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. - -</p> -<p> - There are several situations to consider for NAT. - -</p> -<a name="rfc.section.6.1"></a><h4><a name="anchor43">6.1</a> Co-located NAT/NAPT</h4> - -<p> - 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. - -</p> -<p> 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. - -</p> -<p> 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. - -</p> -<a name="rfc.section.6.2"></a><h4><a name="anchor44">6.2</a> SG-A behind NAT/NAPT</h4> - -<p> - 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. - -</p> -<a name="rfc.section.6.3"></a><h4><a name="anchor45">6.3</a> Bob is behind a NAT/NAPT</h4> - -<p> - 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. - -</p> -<a name="anchor46"><br><hr size="1" shade="0"></a> -<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> -<a name="rfc.section.7"></a><h3>7. Host implementations</h3> - -<p> - 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. - -</p> -<p> - Components marked Alice are the upper layers (TCP, UDP, the - application), and SG-A is the IP layer. - -</p> -<p> - Note that tunnel mode is still required. - -</p> -<p> - 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. - -</p> -<a name="anchor47"><br><hr size="1" shade="0"></a> -<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> -<a name="rfc.section.8"></a><h3>8. Multi-homing</h3> - -<p> -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. - -</p> -<p> -In <a href="#networkdiagram">Reference Network Diagram</a>, 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. - -</p> -<p> -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. - -</p> -<p> -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: - <br><hr size="1" shade="0"> -<a name="txtmultiexample"></a> -</p> -</font><pre> -X-IPsec-Server(10)=192.1.1.5 AQMM...3s1Q== -X-IPsec-Server(10)=192.1.1.6 AAJN...j8r9== - </pre><font face="verdana, helvetica, arial, sans-serif" size="2"> -<p> -<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Multiple gateway delegation example for Alice </b></font><br></td></tr></table><hr size="1" shade="0"> - -</p> -<p> -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. - -</p> -<p> -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. - -</p> -<p> -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. - -</p> -<p> -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. - -</p> -<p> -SG-B may make a number of choices: - -<ol class="text"> -<li>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. -</li> -<li>It can send to the gateway from which it most recently received datagrams. - This assumes that routing and reachability are symmetrical. -</li> -<li>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. -</li> -<li>It can refuse to negotiate the second tunnel. (It is unclear whether or -not this is even an option.) -</li> -<li>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. -</li> -</ol><p> -</p> -<p> -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. - -</p> -<p> -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. - -</p> -<a name="anchor48"><br><hr size="1" shade="0"></a> -<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> -<a name="rfc.section.9"></a><h3>9. Failure modes</h3> - -<a name="rfc.section.9.1"></a><h4><a name="anchor49">9.1</a> DNS failures</h4> - -<p> - 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 <a href="#initclasses">Keying state machine - initiator</a>. - 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. - -</p> -<p> - 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. - -</p> -<a name="rfc.section.9.2"></a><h4><a name="anchor50">9.2</a> DNS configured, IKE failures</h4> - -<p> - 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. - -</p> -<p> - 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. - -</p> -<p> - In these situations a clear log should be produced - and local policy should dictate if communication is then - permitted in the clear. - -</p> -<a name="rfc.section.9.3"></a><h4><a name="anchor51">9.3</a> System reboots</h4> - -<p> -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. - -</p> -<p> -A mechanism for recovery after reboot is a topic of current research and is not specified in this -document. - -</p> -<p> -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. - -</p> -<a name="anchor52"><br><hr size="1" shade="0"></a> -<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> -<a name="rfc.section.10"></a><h3>10. Unresolved issues</h3> - -<a name="rfc.section.10.1"></a><h4><a name="anchor53">10.1</a> Control of reverse DNS</h4> - -<p> - 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. - -</p> -<a name="anchor54"><br><hr size="1" shade="0"></a> -<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> -<a name="rfc.section.11"></a><h3>11. Examples</h3> - -<a name="rfc.section.11.1"></a><h4><a name="anchor55">11.1</a> Clear-text usage (permit policy)</h4> - -<p> -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. - -</p><br><hr size="1" shade="0"> -<a name="regulartiming"></a> -</font><pre> - Alice SG-A DNS SG-B Bob - (1) - ------(2)--------------> - <-----(3)--------------- - (4)----(5)-----> - ----------(6)------> - ------(7)-----> - <------(8)------ - <----------(9)------ - <----(10)----- - (11)-----------> - ----------(12)-----> - --------------> - <--------------- - <------------------- - <------------- - </pre><font face="verdana, helvetica, arial, sans-serif" size="2"> -<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Timing of regular transaction </b></font><br></td></tr></table><hr size="1" shade="0"> - -<p> -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: - -<blockquote class="text"><dl> -<dt>(1)</dt> -<dd>Human or application 'clicks' with a name. -</dd> -<dt>(2)</dt> -<dd>Application looks up name in DNS to get IP address. -</dd> -<dt>(3)</dt> -<dd>Resolver returns A record to application. -</dd> -<dt>(4)</dt> -<dd>Application starts a TCP session or UDP session and OS sends datagram. -</dd> -<dt>(5)</dt> -<dd>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.) -</dd> -<dt>(6)</dt> -<dd>Datagram is seen at last gateway before Bob (SG-B). -</dd> -<dt>(7)</dt> -<dd>First datagram from Alice is seen by Bob. -</dd> -<dt>(8)</dt> -<dd>First return datagram is sent by Bob. -</dd> -<dt>(9)</dt> -<dd>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.) -</dd> -<dt>(10)</dt> -<dd>Datagram is seen at Alice's gateway. -</dd> -<dt>(11)</dt> -<dd>OS hands datagram to application. Alice sends another datagram. -</dd> -<dt>(12)</dt> -<dd>A second datagram traverses the Internet. -</dd> -</dl></blockquote><p> -</p> -<a name="rfc.section.11.2"></a><h4><a name="anchor56">11.2</a> Opportunistic encryption</h4> - -<p> -In the presence of properly configured opportunistic encryptors, the -event list is extended. - -<br><hr size="1" shade="0"> -<a name="opportunistictiming"></a> -</p> -</font><pre> - 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)=====> - --------------> - <--------------- - <=================== - <------------- - </pre><font face="verdana, helvetica, arial, sans-serif" size="2"> -<p> -<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Timing of opportunistic encryption transaction </b></font><br></td></tr></table><hr size="1" shade="0"> - -<blockquote class="text"><dl> -<dt>(1)</dt> -<dd>Human or application clicks with a name. -</dd> -<dt>(2)</dt> -<dd>Application initiates DNS mapping. -</dd> -<dt>(3)</dt> -<dd>Resolver returns A record to application. -</dd> -<dt>(4)</dt> -<dd>Application starts a TCP session or UDP. -</dd> -<dt>(5)</dt> -<dd>SG-A (host or SG) sees datagram to target, and buffers it. -</dd> -<dt>(5B)</dt> -<dd>SG-A asks DNS for TXT record. -</dd> -<dt>(5C)</dt> -<dd>DNS returns TXT record(s). -</dd> -<dt>(5D)</dt> -<dd>Initial IKE Main Mode Packet goes out. -</dd> -<dt>(5E)</dt> -<dd>IKE ISAKMP phase 1 succeeds. -</dd> -<dt>(5F)</dt> -<dd>SG-B asks DNS for TXT record to prove SG-A is an agent for Alice. -</dd> -<dt>(5G)</dt> -<dd>IKE phase 2 negotiation. -</dd> -<dt>(5H)</dt> -<dd>DNS lookup by responder (SG-B). -</dd> -<dt>(6)</dt> -<dd>Buffered datagram is sent by SG-A. -</dd> -<dt>(7)</dt> -<dd>Datagram is received by SG-B, decrypted, and sent to Bob. -</dd> -<dt>(8)</dt> -<dd>Bob replies, and datagram is seen by SG-B. -</dd> -<dt>(9)</dt> -<dd>SG-B already has tunnel up with SG-A, and uses it. -</dd> -<dt>(10)</dt> -<dd>SG-A decrypts datagram and gives it to Alice. -</dd> -<dt>(11)</dt> -<dd>Alice receives datagram. Sends new packet to Bob. -</dd> -<dt>(12)</dt> -<dd>SG-A gets second datagram, sees that tunnel is up, and uses it. -</dd> -</dl></blockquote><p> -</p> -<p> - For the purposes of this section, we will describe only the changes that - occur between <a href="#regulartiming">Timing of regular transaction</a> and - <a href="#opportunistictiming">Timing of opportunistic encryption transaction</a>. This corresponds to time points 5, 6, 7, 9 and 10 on the list above. - -</p> -<a name="rfc.section.11.2.1"></a><h4><a name="anchor57">11.2.1</a> (5) IPsec datagram interception</h4> - -<p> - 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. - -</p> -<a name="rfc.section.11.2.2"></a><h4><a name="anchor58">11.2.2</a> (5B) DNS lookup for TXT record</h4> - -<p> - 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. - -</p> -<a name="rfc.section.11.2.3"></a><h4><a name="anchor59">11.2.3</a> (5C) DNS returns TXT record(s)</h4> - -<p> - 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. - -</p> -<p> - Using the example above, the returned record might contain: - - <br><hr size="1" shade="0"> -<a name="txtexample"></a> -</p> -</font><pre> -X-IPsec-Server(10)=192.1.1.5 AQMM...3s1Q== - </pre><font face="verdana, helvetica, arial, sans-serif" size="2"> -<p> -<table border="0" cellpadding="0" cellspacing="2" align="center"><tr><td align="center"><font face="monaco, MS Sans Serif" size="1"><b> Example of reverse delegation record for Bob </b></font><br></td></tr></table><hr size="1" shade="0"> - - with SG-B's IP address and public key listed. - -</p> -<a name="rfc.section.11.2.4"></a><h4><a name="anchor60">11.2.4</a> (5D) Initial IKE main mode packet goes out</h4> - -<p>Upon entering Pending OE connection, SG-A sends the initial ISAKMP - message with proposals. See <a href="#phase1id">Phase 1 parameters</a>. - -</p> -<a name="rfc.section.11.2.5"></a><h4><a name="anchor61">11.2.5</a> (5E1) Message 2 of phase 1 exchange</h4> - -<p> - SG-B receives the message. A new connection instance is created in the - unauthenticated OE peer state. - -</p> -<a name="rfc.section.11.2.6"></a><h4><a name="anchor62">11.2.6</a> (5E2) Message 3 of phase 1 exchange</h4> - -<p> - SG-A sends a Diffie-Hellman exponent. This is an internal state of the - keying daemon. - -</p> -<a name="rfc.section.11.2.7"></a><h4><a name="anchor63">11.2.7</a> (5E3) Message 4 of phase 1 exchange</h4> - -<p> - SG-B responds with a Diffie-Hellman exponent. This is an internal state of the - keying protocol. - -</p> -<a name="rfc.section.11.2.8"></a><h4><a name="anchor64">11.2.8</a> (5E4) Message 5 of phase 1 exchange</h4> - -<p> - SG-A uses the phase 1 SA to send its identity under encryption. - The choice of identity is discussed in <a href="#phase1id">Phase 1 parameters</a>. - This is an internal state of the keying protocol. - -</p> -<a name="rfc.section.11.2.9"></a><h4><a name="anchor65">11.2.9</a> (5F1) Responder lookup of initiator key</h4> - -<p> - 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 <a href="#KEY">Use of KEY record</a> for further details. - -</p> -<a name="rfc.section.11.2.10"></a><h4><a name="anchor66">11.2.10</a> (5F2) DNS replies with public key of initiator</h4> - -<p> -Upon successfully authenticating the peer, the connection instance makes a -transition to authenticated OE peer on SG-B. - -</p> -<p> -The format of the TXT record returned is described in -<a href="#TXT">Use of TXT delegation record</a>. - -</p> -<a name="rfc.section.11.2.11"></a><h4><a name="anchor67">11.2.11</a> (5E5) Responder replies with ID and authentication</h4> - -<p> - SG-B sends its ID along with authentication material. This is an internal - state for the keying protocol. - -</p> -<a name="rfc.section.11.2.12"></a><h4><a name="anchor68">11.2.12</a> (5G) IKE phase 2</h4> - -<a name="rfc.section.11.2.12.1"></a><h4><a name="anchor69">11.2.12.1</a> (5G1) Initiator proposes tunnel</h4> - -<p> - 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. - -</p> -<a name="rfc.section.11.2.12.2"></a><h4><a name="anchor70">11.2.12.2</a> (5H1) Responder determines initiator's authority</h4> - -<p> - 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. - -</p> -<p>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. -</p> -<a name="rfc.section.11.2.12.3"></a><h4><a name="anchor71">11.2.12.3</a> (5H2) DNS replies with TXT record(s)</h4> - -<p> - The returned key and IP address should match that of SG-A. - -</p> -<a name="rfc.section.11.2.12.4"></a><h4><a name="anchor72">11.2.12.4</a> (5G2) Responder agrees to proposal</h4> - -<p> - 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. - -</p> -<p>SG-A, having successfully keyed the tunnel, now makes a transition from - Pending OE connection to Keyed OE connection. - -</p> -<p>The responder MUST setup the inbound IPsec SAs before sending its reply. -</p> -<a name="rfc.section.11.2.12.5"></a><h4><a name="anchor73">11.2.12.5</a> (5G3) Final acknowledgment from initiator</h4> - -<p> - The initiator agrees with the responder's choice and sets up the tunnel. - The initiator sets up the inbound and outbound IPsec SAs. - -</p> -<p> - The proper authorization returned with keys prompts SG-B to make a transition - to the keyed OE connection state. - -</p> -<p>Upon receipt of this message, the responder may now setup the outbound - IPsec SAs. -</p> -<a name="rfc.section.11.2.13"></a><h4><a name="anchor74">11.2.13</a> (6) IPsec succeeds, and sets up tunnel for communication between Alice and Bob</h4> - -<p> - 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). - -</p> -<a name="rfc.section.11.2.14"></a><h4><a name="anchor75">11.2.14</a> (9) SG-B already has tunnel up with G1 and uses it</h4> - -<p> - 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). - -</p> -<a name="securityconsiderations"><br><hr size="1" shade="0"></a> -<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> -<a name="rfc.section.12"></a><h3>12. Security considerations</h3> - -<a name="rfc.section.12.1"></a><h4><a name="anchor76">12.1</a> Configured vs opportunistic tunnels</h4> - -<p> - 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. - -</p> -<p> -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. - -</p> -<p> -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. - -</p> -<p> -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. - -</p> -<p> -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. - -</p> -<p> -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. - -</p> -<p> -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. - -</p> -<a name="rfc.section.12.2"></a><h4><a name="anchor77">12.2</a> Firewalls versus Opportunistic Tunnels</h4> - -<p> - Typical usage of per datagram access control lists is to implement various -kinds of security gateways. These are typically called "firewalls". - -</p> -<p> - 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. - -</p> -<p> - 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. - -</p> -<a name="rfc.section.12.3"></a><h4><a name="anchor78">12.3</a> Denial of service</h4> - -<p> - 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). - -</p> -<p> - 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. - -</p> -<a name="anchor79"><br><hr size="1" shade="0"></a> -<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> -<a name="rfc.section.13"></a><h3>13. IANA Considerations</h3> - -<p> - There are no known numbers which IANA will need to manage. - -</p> -<a name="anchor80"><br><hr size="1" shade="0"></a> -<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> -<a name="rfc.section.14"></a><h3>14. Acknowledgments</h3> - -<p> - Substantive portions of this document are based upon previous work by - Henry Spencer. - -</p> -<p> - 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. - -</p> -<p> - Sandra Hoffman and Bill Dickie did the detailed proof reading and editing. - -</p> -<a name="rfc.references1"><br><hr size="1" shade="0"></a> -<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> -<h3>Normative references</h3> -<table width="99%" border="0"> -<tr><td class="author-text" valign="top"><b><a name="OEspec">[1]</a></b></td> -<td class="author-text"><a href="mailto:hugh@mimosa.com">Redelmeier, D.</a> and <a href="mailto:henry@spsystems.net">H. Spencer</a>, "Opportunistic Encryption", paper http://www.freeswan.org/freeswan_trees/freeswan-1.91/doc/opportunism.spec, May 2001.</td></tr> -<tr><td class="author-text" valign="top"><b><a name="RFC0791">[2]</a></b></td> -<td class="author-text">Defense Advanced Research Projects Agency (DARPA), Information Processing Techniques Office and University of Southern California (USC)/Information Sciences Institute, "<a href="ftp://ftp.isi.edu/in-notes/rfc791.txt">Internet Protocol</a>", STD 5, RFC 791, September 1981.</td></tr> -<tr><td class="author-text" valign="top"><b><a name="RFC1009">[3]</a></b></td> -<td class="author-text"><a href="mailto:">Braden, R.</a> and <a href="mailto:">J. Postel</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc1009.txt">Requirements for Internet gateways</a>", RFC 1009, June 1987.</td></tr> -<tr><td class="author-text" valign="top"><b><a name="RFC1984">[4]</a></b></td> -<td class="author-text">IAB, IESG, <a href="mailto:brian@dxcoms.cern.ch">Carpenter, B.</a> and <a href="mailto:fred@cisco.com">F. Baker</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc1984.txt">IAB and IESG Statement on Cryptographic Technology and the Internet</a>", RFC 1984, August 1996.</td></tr> -<tr><td class="author-text" valign="top"><b><a name="RFC2119">[5]</a></b></td> -<td class="author-text"><a href="mailto:-">Bradner, S.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2119.txt">Key words for use in RFCs to Indicate Requirement Levels</a>", BCP 14, RFC 2119, March 1997.</td></tr> -<tr><td class="author-text" valign="top"><b><a name="RFC2367">[6]</a></b></td> -<td class="author-text"><a href="mailto:danmcd@eng.sun.com">McDonald, D.</a>, <a href="mailto:cmetz@inner.net">Metz, C.</a> and <a href="mailto:phan@itd.nrl.navy.mil">B. Phan</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2367.txt">PF_KEY Key Management API, Version 2</a>", RFC 2367, July 1998.</td></tr> -<tr><td class="author-text" valign="top"><b><a name="RFC2401">[7]</a></b></td> -<td class="author-text"><a href="mailto:kent@bbn.com">Kent, S.</a> and <a href="mailto:rja@corp.home.net">R. Atkinson</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2401.txt">Security Architecture for the Internet Protocol</a>", RFC 2401, November 1998.</td></tr> -<tr><td class="author-text" valign="top"><b><a name="RFC2407">[8]</a></b></td> -<td class="author-text"><a href="mailto:ddp@network-alchemy.com">Piper, D.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2407.txt">The Internet IP Security Domain of Interpretation for ISAKMP</a>", RFC 2407, November 1998.</td></tr> -<tr><td class="author-text" valign="top"><b><a name="RFC2408">[9]</a></b></td> -<td class="author-text"><a href="mailto:wdm@tycho.ncsc.mil">Maughan, D.</a>, <a href="mailto:mss@tycho.ncsc.mil">Schneider, M.</a> and <a href="er@raba.com">M. Schertler</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2408.txt">Internet Security Association and Key Management Protocol (ISAKMP)</a>", RFC 2408, November 1998.</td></tr> -<tr><td class="author-text" valign="top"><b><a name="RFC2409">[10]</a></b></td> -<td class="author-text"><a href="mailto:dharkins@cisco.com">Harkins, D.</a> and <a href="mailto:carrel@ipsec.org">D. Carrel</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2409.txt">The Internet Key Exchange (IKE)</a>", RFC 2409, November 1998.</td></tr> -<tr><td class="author-text" valign="top"><b><a name="RFC3526">[11]</a></b></td> -<td class="author-text"><a href="mailto:kivinen@ssh.fi">Kivinen, T.</a> and <a href="mailto:mrskojo@cc.helsinki.fi">M. Kojo</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc3526.txt">More MODP Diffie-Hellman groups for IKE</a>", RFC 3526, March 2003.</td></tr> -<tr><td class="author-text" valign="top"><b><a name="RFC1034">[12]</a></b></td> -<td class="author-text">Mockapetris, P., "<a href="ftp://ftp.isi.edu/in-notes/rfc1034.txt">Domain names - concepts and facilities</a>", STD 13, RFC 1034, November 1987.</td></tr> -<tr><td class="author-text" valign="top"><b><a name="RFC1035">[13]</a></b></td> -<td class="author-text"><a href="mailto:">Mockapetris, P.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc1035.txt">Domain names - implementation and specification</a>", STD 13, RFC 1035, November 1987.</td></tr> -<tr><td class="author-text" valign="top"><b><a name="RFC2671">[14]</a></b></td> -<td class="author-text"><a href="mailto:vixie@isc.org">Vixie, P.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2671.txt">Extension Mechanisms for DNS (EDNS0)</a>", RFC 2671, August 1999.</td></tr> -<tr><td class="author-text" valign="top"><b><a name="RFC1464">[15]</a></b></td> -<td class="author-text"><a href="mailto:rosenbaum@lkg.dec.com">Rosenbaum, R.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc1464.txt">Using the Domain Name System To Store Arbitrary String Attributes</a>", RFC 1464, May 1993.</td></tr> -<tr><td class="author-text" valign="top"><b><a name="RFC2535">[16]</a></b></td> -<td class="author-text"><a href="mailto:dee3@us.ibm.com">Eastlake, D.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2535.txt">Domain Name System Security Extensions</a>", RFC 2535, March 1999.</td></tr> -<tr><td class="author-text" valign="top"><b><a name="RFC3110">[17]</a></b></td> -<td class="author-text">Eastlake, D., "<a href="ftp://ftp.isi.edu/in-notes/rfc3110.txt">RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)</a>", RFC 3110, May 2001.</td></tr> -<tr><td class="author-text" valign="top"><b><a name="RFC2538">[18]</a></b></td> -<td class="author-text"><a href="mailto:dee3@us.ibm.com">Eastlake, D.</a> and <a href="mailto:ogud@tislabs.com">O. Gudmundsson</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2538.txt">Storing Certificates in the Domain Name System (DNS)</a>", RFC 2538, March 1999.</td></tr> -<tr><td class="author-text" valign="top"><b><a name="RFC2748">[19]</a></b></td> -<td class="author-text"><a href="mailto:David.Durham@intel.com">Durham, D.</a>, <a href="mailto:jboyle@Level3.net">Boyle, J.</a>, <a href="mailto:ronc@cisco.com">Cohen, R.</a>, <a href="mailto:herzog@iphighway.com">Herzog, S.</a>, <a href="mailto:rajan@research.att.com">Rajan, R.</a> and <a href="mailto:asastry@cisco.com">A. Sastry</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2748.txt">The COPS (Common Open Policy Service) Protocol</a>", RFC 2748, January 2000.</td></tr> -<tr><td class="author-text" valign="top"><b><a name="RFC2663">[20]</a></b></td> -<td class="author-text"><a href="mailto:srisuresh@lucent.com">Srisuresh, P.</a> and <a href="mailto:holdrege@lucent.com">M. Holdrege</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2663.txt">IP Network Address Translator (NAT) Terminology and Considerations</a>", RFC 2663, August 1999.</td></tr> -</table> - -<a name="rfc.authors"><br><hr size="1" shade="0"></a> -<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> -<h3>Authors' Addresses</h3> -<table width="99%" border="0" cellpadding="0" cellspacing="0"> -<tr><td class="author-text"> </td> -<td class="author-text">Michael C. Richardson</td></tr> -<tr><td class="author-text"> </td> -<td class="author-text">Sandelman Software Works</td></tr> -<tr><td class="author-text"> </td> -<td class="author-text">470 Dawson Avenue</td></tr> -<tr><td class="author-text"> </td> -<td class="author-text">Ottawa, ON K1Z 5V7</td></tr> -<tr><td class="author-text"> </td> -<td class="author-text">CA</td></tr> -<tr><td class="author" align="right">EMail: </td> -<td class="author-text"><a href="mailto:mcr@sandelman.ottawa.on.ca">mcr@sandelman.ottawa.on.ca</a></td></tr> -<tr><td class="author" align="right">URI: </td> -<td class="author-text"><a href="http://www.sandelman.ottawa.on.ca/">http://www.sandelman.ottawa.on.ca/</a></td></tr> -<tr cellpadding="3"><td> </td><td> </td></tr> -<tr><td class="author-text"> </td> -<td class="author-text">D. Hugh Redelmeier</td></tr> -<tr><td class="author-text"> </td> -<td class="author-text">Mimosa</td></tr> -<tr><td class="author-text"> </td> -<td class="author-text">Toronto, ON</td></tr> -<tr><td class="author-text"> </td> -<td class="author-text">CA</td></tr> -<tr><td class="author" align="right">EMail: </td> -<td class="author-text"><a href="mailto:hugh@mimosa.com">hugh@mimosa.com</a></td></tr> -</table> -<a name="rfc.copyright"><br><hr size="1" shade="0"></a> -<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> -<h3>Full Copyright Statement</h3> -<p class='copyright'> -Copyright (C) The Internet Society (2003). All Rights Reserved.</p> -<p class='copyright'> -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.</p> -<p class='copyright'> -The limited permissions granted above are perpetual and will not be -revoked by the Internet Society or its successors or assigns.</p> -<p class='copyright'> -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.</p> -<h3>Acknowledgement</h3> -<p class='copyright'> -Funding for the RFC Editor function is currently provided by the -Internet Society.</p> -</font></body></html> diff --git a/doc/src/draft-richardson-ipsec-opportunistic.xml b/doc/src/draft-richardson-ipsec-opportunistic.xml deleted file mode 100644 index d587df693..000000000 --- a/doc/src/draft-richardson-ipsec-opportunistic.xml +++ /dev/null @@ -1,2519 +0,0 @@ -<?xml version="1.0"?> -<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> -<?rfc toc="yes"?> -<?rfc tocdepth='2' ?> - -<rfc ipr="full2026" docName="draft-richardson-ipsec-opportunistic-12.txt"> - -<front> - <area>Security</area> - <workgroup>Independent submission</workgroup> - <title abbrev="opportunistic"> - Opportunistic Encryption using The Internet Key Exchange (IKE) - </title> - - <author initials="M." surname="Richardson" fullname="Michael C. Richardson"> - <organization abbrev="SSW">Sandelman Software Works</organization> - <address> - <postal> - <street>470 Dawson Avenue</street> - <city>Ottawa</city> - <region>ON</region> - <code>K1Z 5V7</code> - <country>CA</country> - </postal> - <email>mcr@sandelman.ottawa.on.ca</email> - <uri>http://www.sandelman.ottawa.on.ca/</uri> - </address> - </author> - - <author initials="D.H." surname="Redelmeier" - fullname="D. Hugh Redelmeier"> - <organization abbrev="Mimosa">Mimosa</organization> - <address> - <postal> - <city>Toronto</city> - <region>ON</region> - <country>CA</country> - </postal> - <email>hugh@mimosa.com</email> - </address> - </author> - - <date month="June" year="2003"></date> - -<abstract> - <t> -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. - </t> - <t> -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. - </t> - <t> -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. - </t> - <t> -This document is offered up as an Informational RFC. - </t> -</abstract> - -</front> - -<middle> - -<section title="Introduction"> - -<section title="Motivation"> - -<t> -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. -</t> - -<t> -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. -</t> - - <t> -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 <xref target="RFC1984" />. -The Linux FreeS/WAN project attempts to provide a practical means to implement this policy. - </t> - - <t> -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. - </t> - - <t> -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. - </t> - - <t> -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. -</t> - - <t> -This document describes the infrastructure to permit deployment of -Opportunistic Encryption. -</t> - - <t> -The term S/WAN is a trademark of RSA Data Systems, and is used with permission -by this project. - </t> - -</section> - -<section title="Types of network traffic"> - <t> - To aid in understanding the relationship between security processing and IPsec - we divide network traffic into four categories: - <list style="hanging"> - <t hangText="* Deny:"> networks to which traffic is always forbidden.</t> - <t hangText="* Permit:"> networks to which traffic in the clear is permitted.</t> - <t hangText="* Opportunistic tunnel:"> networks to which traffic is encrypted if possible, but otherwise is in the clear - or fails depending on the default policy in place. - </t> - <t hangText="* Configured tunnel:"> 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. -</t> - </list> - </t> - -<t> -Traditional firewall devices handle the first two categories. -No authentication is required. -The permit policy is currently the default on the Internet. -</t> - -<t> -This document describes the third category - opportunistic tunnel, which is -proposed as the new default for the Internet. -</t> - -<t> - 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. -</t> -<t> -Current Virtual Private Networks can often be replaced by an "OE paranoid" -policy as described herein. -</t> -</section> - -<section title="Peer authentication in opportunistic encryption"> - - <t> - 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. - </t> - - <t> - 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. - </t> - - <t> -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. -</t> - - <t> - Peers are, therefore, authenticated with DNSSEC when available. Local policy -determines how much trust to extend when DNSSEC is not available. - </t> - - <t> - 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. - </t> - - <t> - 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. - </t> - - </section> - -<section title="Use of RFC2119 terms"> -<t> - 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 <xref target="RFC2119" /> -</t> -</section> - -</section> - -<section title="Overview"> - - <section title="Reference diagram"> - - <figure anchor="networkdiagram" title="Reference Network Diagram"> - <preamble>The following network diagram is used in the rest of - this document as the canonical diagram:</preamble> - <artwork> - [Q] [R] - . . AS2 - [A]----+----[SG-A].......+....+.......[SG-B]-------[B] - | ...... - AS1 | ..PI.. - | ...... - [D]----+----[SG-D].......+....+.......[C] AS3 - - - </artwork> - <postamble></postamble> - - </figure> - - <t> - 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"). - </t> - - </section> - - <section title="Terminology"> - - <t> - The following terminology is used in this document: - </t> - - <list style="hanging"> - <t hangText="Security gateway (or simply gateway):"> a system that performs IPsec tunnel - mode encapsulation/decapsulation. [SG-x] in the diagram.</t> - <t hangText="Alice:"> node [A] in the diagram. When an IP address is needed, this is 192.1.0.65.</t> - <t hangText="Bob:"> node [B] in the diagram. When an IP address is needed, this is 192.2.0.66.</t> - <t hangText="Carol:"> node [C] in the diagram. When an IP address is needed, this is 192.1.1.67.</t> - <t hangText="Dave:"> node [D] in the diagram. When an IP address is needed, this is 192.3.0.68.</t> - <t hangText="SG-A:"> Alice's security gateway. Internally it is 192.1.0.1, externally it is 192.1.1.4.</t> - <t hangText="SG-B:"> Bob's security gateway. Internally it is 192.2.0.1, externally it is 192.1.1.5.</t> - <t hangText="SG-D:"> Dave's security gateway. Also Alice's backup security gateway. Internally it is 192.3.0.1, externally it is 192.1.1.6.</t> - <t hangText="."> A period represents an untrusted network of unknown - type.</t> - <t hangText="Configured tunnel:"> a tunnel that - is directly and deliberately hand configured on participating gateways. - Configured tunnels are typically given a higher level of - trust than opportunistic tunnels.</t> - - <t hangText="Road warrior tunnel:"> a configured tunnel connecting one - node with a fixed IP address and one node with a variable IP address. - A road warrior (RW) connection must be initiated by the - variable node, since the fixed node cannot know the - current address for the road warrior. </t> - - <t hangText="Anonymous encryption:"> - the process of encrypting a session without any knowledge of who the - other parties are. No authentication of identities is done.</t> - - <t hangText="Opportunistic encryption:"> - the process of encrypting a session with authenticated knowledge of - who the other party is.</t> - - <t hangText="Lifetime:"> - the period in seconds (bytes or datagrams) for which a security - association will remain alive before needing to be re-keyed.</t> - - <t hangText="Lifespan:"> - the effective time for which a security association remains useful. A - security association with a lifespan shorter than its lifetime would - be removed when no longer needed. A security association with a - lifespan longer than its lifetime would need to be re-keyed one or - more times.</t> - - <t hangText="Phase 1 SA:"> an ISAKMP/IKE security association sometimes - referred to as a keying channel.</t> - - <t hangText="Phase 2 SA:"> an IPsec security association.</t> - - <t hangText="Tunnel:"> another term for a set of phase 2 SA (one in each direction).</t> - - <t hangText="NAT:"> Network Address Translation - (see <xref target="RFC2663" />).</t> - - <t hangText="NAPT:"> Network Address and Port Translation - (see <xref target="RFC2663" />).</t> - - <t hangText="AS:"> an autonomous system </t> - - <t hangText="FQDN:"> Fully-Qualified Domain Name </t> - - <t hangText="Default-free zone:"> - a set of routers that maintain a complete set of routes to - all currently reachable destinations. Having such a list, these routers - never make use of a default route. A datagram with a destination address - not matching any route will be dropped by such a router. - </t> - - </list> - </section> - -<section title="Model of operation"> - -<t> -The opportunistic encryption security gateway (OE gateway) is a regular -gateway node as described in <xref target="RFC0791" /> section 2.4 and -<xref target="RFC1009" /> with the additional capabilities described here and -in <xref target="RFC2401" />. -The algorithm described here provides a way to determine, for each datagram, -whether or not to encrypt and tunnel the datagram. Two important things -that must be determined are whether or not to encrypt and tunnel and, if -so, the destination address or name of the tunnel end point which should be used. -</t> - -<section title="Tunnel authorization"> -<t> -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 <xref target="TXT"/>). 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. -</t> -</section> - -<section title="Tunnel end-point discovery"> - -<t> -The authorization resource record also provides the address or name of the tunnel -end point which should be used. -</t> -<t> -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. -</t> -<t> -Origin and integrity protection of the resource records is provided by -DNSSEC (<xref target="RFC2535"/>). <xref target="nodnssec"/> -documents an optional restriction on the tunnel end point if DNSSEC signatures -are not available for the relevant records. -</t> - -</section> - -<section title="Caching of authorization results"> -<t> -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. -</t> - -<t> -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. -</t> - -<t> -The cache is timed out periodically, as described in <xref target="teardown" />. -This removes entries that are no longer -being used and permits the discovery of changes in authorization policy. -</t> -</section> - -</section> <!-- "Model of operation" --> - -</section> <!-- "Overview" --> - -<section title="Protocol Specification"> - -<t> -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 <xref target="RFC2367" />.) -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. -</t> - -<section title="Forwarding plane state machine"> - -<t> -Let the OE gateway maintain a collection of objects -- a superset of the -security policy database (SPD) specified in <xref target="RFC2401" />. For -each combination of source and destination address, an SPD -object exists in one of five following states. -Prior to forwarding each datagram, the responder uses the source and -destination addresses to pick an entry from the SPD. -The SPD then determines if and how the packet is forwarded. -</t> - -<!-- from file forwardingstate.txt --> -<artwork><![CDATA[ - .--------------. - | non-existant | - | policy | - `--------------' - | - | PF_ACQUIRE - | - |<---------. - V | new packet - .--------------. | (maybe resend PF_ACQUIRE) - | hold policy |--' - | |--. - `--------------' \ pass - | | \ msg .---------. - | | \ V | forward - | | .-------------. | packet - create | | | pass policy |--' - IPsec | | `-------------' - SA | | - | \ - | \ - V \ deny - .---------. \ msg - | encrypt | \ - | policy | \ ,---------. - `---------' \ | | discard - \ V | packet - .-------------. | - | deny policy |--' - '-------------' -]]></artwork> - - -<section title="Non-existent policy"> -<t> -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. - -</t> -</section> - -<section title="Hold policy"> -<t> -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. -</t> -<t> -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. -</t> -</section> - -<section title="Pass-through policy"> -<t> -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. -</t> -</section> - -<section title="Deny policy"> -<t> -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). -</t> -</section> - -<section title="Encrypt policy"> -<t> -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. -</t> -<t> -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. -</t> -</section> - -<t> -All states may be created directly by the keying daemon while acting as a -gateway. -</t> - -</section> <!-- "Datagram state machine" --> - - -<section anchor="initclasses" title="Keying Daemon -- initiator"> -<t> -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. -</t> - -<t> -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. -</t> - -<t> -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. -</t> - -<t> -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. -</t> - -<t> -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. -</t> - -<t> -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 -(<xref target="RFC2407" />, -<xref target="RFC2408" /> and <xref target="RFC2409" /> 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. -</t> -<t> -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. -</t> -<t> -Finally, the retransmits and recursive lookups that are normal for DNS are -not included in this description of the state machine. -</t> - -<!-- from file initiatorstate.txt --> -<artwork><![CDATA[ - - | - | PF_ACQUIRE - | - V - .---------------. - | non-existant | - | connection | - `---------------' - | | | - send , | \ -expired pass / | \ send -conn. msg / | \ deny - ^ / | \ msg - | V | do \ -.---------------. | DNS \ .---------------. -| clear-text | | lookup `->| deny |---> expired -| connection | | for | connection | connection -`---------------' | destination `---------------' - ^ ^ | ^ - | | no record | | - | | OE-permissive V | no record - | | .---------------. | OE-paranoid - | `------------| potential OE |---------' - | | connection | ^ - | `---------------' | - | | | - | | got TXT record | DNSSEC failure - | | reply | - | V | wrong - | .---------------. | failure - | | authenticate |---------' - | | & parse TXT RR| ^ - | repeated `---------------' | - | ICMP | | - | failures | initiate IKE to | - | (short-timeout) | responder | - | V | - | phase-2 .---------------. | failure - | failure | pending |---------' - | (normal | OE | ^ - | timeout) | |invalid | phase-2 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 -]]></artwork> - - -<section title="Nonexistent connection"> -<t> -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. -</t> -<t>Failure to find an appropriate connection class results in an -administrator defined default. -</t> -<t> -In each case, when the initiator finds an appropriate class for the new flow, -an instance connection is made of the class which matched. -</t> -</section> - -<section title="Clear-text connection"> -<t> -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. -</t> -<t> -Timing out is the only way to leave this state -(see <xref target="expiring" />). -</t> -</section> - -<section title="Deny connection"> -<t> -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. -</t> -<t> -Timing out is the only way to leave this state -(see <xref target="expiring" />). -</t> -</section> - -<section title="Potential OE connection"> -<t> -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. -</t> -<t> -In addition, when making a transition into this state, DNS lookup is done in -the reverse-map for a TXT delegation resource record (see <xref target="TXT" />). -The lookup key is the destination address of the flow. -</t> -<t> -There are three ways to exit this state: -<list style="numbers"> -<t>DNS lookup finds a TXT delegation resource record.</t> -<t>DNS lookup does not find a TXT delegation resource record.</t> -<t>DNS lookup times out.</t> -</list> -</t> - -<t> -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: -<list style="numbers"> -<t>DNS finds an appropriate resource record</t> -<t>It is properly formatted according to <xref target="TXT" /></t> -<t> if DNSSEC is enabled, then the signature has been vouched for.</t> -</list> - -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. -</t> -<t> -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. -</t> -<t> -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. -</t> - -<section anchor="nodnssec" title="Restriction on unauthenticated TXT delegation records"> -<t> -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. -<!-- This was asked for by Bill Sommerfeld --> -</t> -</section> -</section> - -<section title="Pending OE connection"> -<t> -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. -</t> -<t> -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. -</t> -<t> -Three failures have caused significant problems. They are clearly not the -only possible failures from keying. -</t> -<t> -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. -</t> -<t> -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. -</t> -<t> -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. -</t> -<t> -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. -</t> -<t> -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.) -<!-- dig @gateway would also work here --> -</t> - -</section> - -<section anchor="keyed" title="Keyed connection"> -<t> -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. -</t> -<t> -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. -</t> -<t> -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. -</t> -<t> -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. -</t> -</section> - -<section anchor="expiring" title="Expiring connection"> -<t> -The initiator will periodically place each of the deny, clear-text, and keyed -connections into this -sub-state. See <xref target="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. -</t> -<t> -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 <xref target="RFC1034" /> section 4.3.4.) -If the DNS query is stale, then a new query is made. If the results change, then the connection -makes a transition to a new state as described in potential OE connection state. -</t> -<t> -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. -</t> -<t> -Also note that the policy at the forwarding plane is not updated unless there -is a conclusion that there should be a change. -</t> - -</section> -<section title="Expired connection"> -<t> -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. -</t> -<t> -The initiator sends an ISAKMP/IKE delete to clean up the phase 2 SAs as described in -<xref target="teardown" />. -</t> -<t> -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. -</t> -</section> - -</section> <!-- "Keying state machine - initiator" --> - -<section title="Keying Daemon - responder"> -<t> -The responder has a set of objects identical to those of the initiator. -</t> -<t> -The responder receives an invitation to create a keying channel from an initiator. -</t> - -<!-- from file responderstate.txt --> -<artwork><![CDATA[ - | - | IKE main mode - | phase 1 - V - .-----------------. - | unauthenticated | - | OE peer | - `-----------------' - | - | lookup KEY RR in in-addr.arpa - | (if ID_IPV4_ADDR) - | lookup KEY RR in forward - | (if ID_FQDN) - V - .-----------------. RR not found - | received DNS |---------------> log failure - | reply | - `----+--------+---' - phase 2 | \ misformatted - proposal | `------------------> log failure - V - .----------------. - | authenticated | identical initiator - | OE peer |--------------------> initiator - `----------------' connection found state machine - | - | look for TXT record for initiator - | - V - .---------------. - | authorized |---------------------> log failure - | OE peer | - `---------------' - | - | - V - potential OE - connection in - initiator state - machine - - -$Id: draft-richardson-ipsec-opportunistic.xml,v 1.1 2004/03/15 20:35:24 as Exp $ -]]></artwork> - - -<section title="Unauthenticated OE peer"> -<t> -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 <xref target="RFC2407" /> section -4.6.2.1.) -</t> -<t> -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. -</t> - -<!-- -<t> -The public key that is retrieved should be stored in stable storage for an -administratively defined period of time, (typically several months if -possible). If a key has previously been stored on disk, then the returned key -should be compared to what has been received, and the key considered valid -only if they match. -</t> ---> - -<t> -Successful authentication of the peer results in a transition to the -authenticated OE Peer state. -</t> -<t> -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. -</t> -</section> - -<section title="Authenticated OE Peer"> -<t> -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. -</t> -<t> -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. -</t> -<t> -If an identical connection is not found, then the responder makes the transition according to the -rules given for the initiator. -</t> -<t> -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. - </t> -</section> - -</section> <!-- "Keying state machine - responder" --> - -<section anchor="teardown" title="Renewal and teardown"> - <section title="Aging"> -<t> -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. -</t> - -<t> -There are two methods for removing tunnels: explicit deletion or expiry. -</t> - -<t> -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. -</t> - -<t> -The tunnel expiry method simply allows the IKE daemon to -expire normally without attempting to re-key it. -</t> - -<t> -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. -</t> - -<t> -Set a short initial (soft) lifespan of 1 minute since many net flows last -only a few seconds. -</t> - -<t> -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. -</t> - -<t> -The expiring state in the key management -system (see <xref target="expiring" />) implements these timeouts. -The timer above may be in the forwarding plane, -but then it must be re-settable. -</t> - -<t> -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. -</t> - -<t> -A multi-step back-off algorithm is not considered worth the effort here. -</t> - -<t> -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. -</t> - -</section> <!-- "Aging" --> - -<section title="Teardown and cleanup"> - -<t> -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. -</t> - -<t> -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. -</t> -<t> -Tunnels are to be considered as bidirectional entities, even though the -low-level protocols don't treat them this way. -</t> - -<t> -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.) -</t> - -<t> -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. -</t> - -</section> - -</section> - -</section> <!-- "Specification" --> - -<section title="Impacts on IKE"> - - <section title="ISAKMP/IKE protocol"> - <t> - 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. - </t> - <t> - 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. - </t> - <t> - 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. - </t> - </section> - - <section title="Gateway discovery process"> - <t> - 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. - </t> - <t> - 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. - </t> - <t> - Use of an asynchronous DNS lookup will also permit overlap of DNS lookups with - some of the protocol steps. - </t> - </section> - - <section title="Self identification"> - <t> - SG-A will have to establish its identity. Use an - IPv4 ID in phase 1. - </t> - <t> 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 <xref target="fqdn" /> - for more details and restrictions. - </t> - </section> - - <section title="Public key retrieval process"> - <t> - 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. - </t> - <t> - 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. - </t> - </section> - - <section title="Interactions with DNSSEC"> - <t> - 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. - </t> - <t> - To distinguish between an authenticated and an unauthenticated DNS - resource record, a stub resolver capable of returning DNSSEC - information MUST be used. - </t> - - </section> - -<!-- - <section title="Interactions with COPS"> - <t> - At this time there is no experience with implementations that interact - with COPS Policy Decision Points (PDP) <xref target="RFC2748" />. It is - suggested that it may be - appropriate for many of - the policy and discovery mechanisms outlined here to be done by a PDP. - In this context, the IKE daemon present in the Policy Enforcement Point - (PEP) may not need any modifications. - </t> - </section> ---> - - <section title="Required proposal types"> - - <section anchor="phase1id" title="Phase 1 parameters"> - <t> - Main mode MUST be used. - </t> - <t> - 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. - <xref target="RFC3526" /> - </t> - <t> - 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. - </t> - <t> - 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. - </t> - <t> - 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 <xref - target="fqdn" />.) 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). - </t> - </section> - - <section anchor="phase2id" title="Phase 2 parameters"> - <t> - 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. - </t> - <t> - Tunnel mode MUST be used. - </t> - <t> - Identities MUST be ID_IPV4_ADDR_SUBNET with the mask being /32. - </t> - <t> - 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. - </t> - <t> - Compression SHOULD NOT be mandatory. It MAY be offered as an option. - </t> - </section> - </section> - -</section> - -<section title="DNS issues"> - <section anchor="KEY" title="Use of KEY record"> - <t> - 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 <xref target="RFC2535">RFC 2535</xref>. - </t> - <t> - <preamble>For example:</preamble> - <artwork><![CDATA[ -KEY 0x4200 4 1 AQNJjkKlIk9...nYyUkKK8 -]]></artwork> - - <list style="hanging"> - <t hangText="0x4200:"> The flag bits, indicating that this key is prohibited - for confidentiality use (it authenticates the peer only, a separate - Diffie-Hellman exchange is used for - confidentiality), and that this key is associated with the non-zone entity - whose name is the RR owner name. No other flags are set.</t> - <t hangText="4:">This indicates that this key is for use by IPsec.</t> - <t hangText="1:">An RSA key is present.</t> - <t hangText="AQNJjkKlIk9...nYyUkKK8:">The public key of the host as described in <xref target="RFC3110" />.</t> - </list> - </t> - <t>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. - </t> - </section> - - <section anchor="TXT" title="Use of TXT delegation record"> - <t> -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. -</t> - -<t> -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. - </t> - <t> - If Alice's address is P.Q.R.S, then she can authorize another node to - act on her behalf by publishing records at: - <artwork><![CDATA[ -S.R.Q.P.in-addr.arpa - ]]></artwork> - </t> - - <t> - The contents of the resource record are expected to be a string that - uses the following syntax, as suggested in <xref target="RFC1464">RFC1464</xref>. - (Note that the reply to query may include other TXT resource - records used by other applications.) - - <figure anchor="txtformat" title="Format of reverse delegation record"> - <artwork><![CDATA[ -X-IPsec-Server(P)=A.B.C.D KEY - ]]></artwork> - </figure> - </t> - - where the record is formed by the following fields: - - <list style="hanging"> - <t hangText="P:"> Specifies a precedence for this record. This is - similar to MX record preferences. Lower numbers have stronger - preference. - </t> - - <t hangText="A.B.C.D:"> Specifies the IP address of the Security Gateway - for this client machine. - </t> - - <t hangText="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. - </t> - </list> - - <t> - The fields of the record MUST be separated by whitespace. This - MAY be: space, tab, newline, or carriage return. A space is preferred. - </t> - - <t> - 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. - - <figure anchor="txtfqdnformat" - title="Format of reverse delegation record (FQDN version)"> - <artwork><![CDATA[ -X-IPsec-Server(P)=@FQDN KEY - ]]></artwork> - </figure> - </t> - - <list style="hanging"> - <t hangText="P:"> Is as above. - </t> - - <t hangText="FQDN:"> Specifies the FQDN that the Security Gateway - will identify itself with. - </t> - - <t hangText="KEY:"> Is the encoded RSA Public key of the Security - Gateway. </t> - </list> - - <t> - 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. - </t> - - <section title="Long TXT records"> - <t> - When packed into transport format, TXT records which are longer than 255 - characters are divided into smaller <character-strings>. - (See <xref target="RFC1035" /> section 3.3 and 3.3.14.) These MUST - be reassembled into a single string for processing. - Whitespace characters in the base64 encoding are to be ignored. - </t> - </section> - - <section title="Choice of TXT record"> - <t> - It has been suggested to use the KEY, OPT, CERT, or KX records - instead of a TXT record. None is satisfactory. - </t> - <t> 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. - </t> - <t> OPT resource records, as defined in <xref target="RFC2671" /> are not - intended to be used for storage of information. They are not to be loaded, - cached or forwarded. They are, therefore, inappropriate for use here. - </t> - <t> - CERT records <xref target="RFC2538" /> can encode almost any set of - information. A custom type code could be used permitting any suitable - encoding to be stored, not just X.509. According to - the RFC, the certificate RRs are to be signed internally which may add undesirable -and unnecessary bulk. Larger DNS records may require TCP instead of UDP transfers. - </t> - <t> - 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. - </t> - <t> - KX records are ideally suited for use instead of TXT records, but had not been deployed at - the time of implementation. -<!-- Jakob Schlyter <j@crt.se> confirmed --> - </t> - </section> - </section> - - <section anchor="fqdn" title="Use of FQDN IDs"> - <t> - 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. - </t> - <t> - 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. - </t> - <t> - This method can also be used when the external address of SG-A is - dynamic. - </t> - <t> - 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. </t> - <t>However, Alice must still delegate to herself if she wishes others to - initiate OE to her. See <xref target="txtfqdnformat" />. - </t> - < - </section> - -<section title="Key roll-over"> -<t> -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. -</t> -<t> -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. -</t> -<t> -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. -</t> - - </section> -</section> - - -<section title="Network address translation interaction"> - <t> - 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. - </t> - <t> - There are several situations to consider for NAT. - </t> - <section title="Co-located NAT/NAPT"> - <t> - 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. - </t> - <t> 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. - </t> - <t> 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. - </t> - </section> - - <section title="Security Gateway behind NAT/NAPT"> - <t> - 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. - </t> - </section> - - <section title="End System is behind a NAT/NAPT"> - <t> - 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. - </t> - </section> -</section> - -<section title="Host implementations"> -<t> - 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. -</t> -<t> - Components marked Alice are the upper layers (TCP, UDP, the - application), and SG-A is the IP layer. -</t> -<t> - Note that tunnel mode is still required. -</t> -<t> - 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. -</t> -</section> - -<section title="Multi-homing"> -<t> -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. -</t> -<t> -In <xref target="networkdiagram" />, 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. -</t> -<t> -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. -</t> -<t> -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: - <figure anchor="txtmultiexample" - title="Multiple gateway delegation example for Alice"> - <artwork><![CDATA[ -X-IPsec-Server(10)=192.1.1.5 AQMM...3s1Q== -X-IPsec-Server(10)=192.1.1.6 AAJN...j8r9== - ]]></artwork> - </figure> -</t> -<t> -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. -</t> -<t> -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. -</t> -<t> -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. -</t> -<t> -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. -</t> -<t> -SG-B may make a number of choices: -<list style="numbers"> -<t>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.</t> - -<t>It can send to the gateway from which it most recently received datagrams. - This assumes that routing and reachability are symmetrical.</t> - -<t>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. </t> - -<t>It can refuse to negotiate the second tunnel. (It is unclear whether or -not this is even an option.)</t> - -<t>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.</t> -</list> -</t> - -<t> -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. -</t> - -<t> -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. -</t> - -</section> - -<section title="Failure modes"> - <section title="DNS failures"> - <t> - 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 <xref target="initclasses" />. - 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. - </t> - <t> - 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. - </t> - </section> - - <section title="DNS configured, IKE failures"> - <t> - 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. - </t> - <t> - 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. - </t> - <t> - In these situations a clear log should be produced - and local policy should dictate if communication is then - permitted in the clear. - </t> - </section> - - <section title="System reboots"> -<t> -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. -</t> - -<t> -A mechanism for recovery after reboot is a topic of current research and is not specified in this -document. -</t> - -<t> -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. -</t> - - </section> -</section> - -<!-- -<section title="Performance experiences"> - - Claudia> Is it useful to point out (or to clarify for our own discussion) any of the - Claudia> following: - - Claudia> * how much time this is likely to take on typical current hardware? - Claudia> * what steps are likely to be time consuming - Claudia> * how any added time could affect a typical transaction, such as hitting - Claudia> a web site - Claudia> * any ways to minimize such time delays - - <section title="Introduced latency"> - </section> - - <section title="Cryptographic performance"> - </section> - - <section title="Phase 1 SA performance"> - </section> - -</section> ---> - -<section title="Unresolved issues"> - <section title="Control of reverse DNS"> - <t> - 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. - </t> - </section> -</section> - -<section title="Examples"> - -<section title="Clear-text usage (permit policy)"> - -<t> -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. - -<t> -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: -</t> - - <figure anchor="regulartiming" title="Timing of regular transaction"> - <artwork><![CDATA[ - Alice SG-A DNS SG-B Bob - Human or application - 'clicks' with a name. - (1) - - ------(2)--------------> - Application looks up - name in DNS to get - IP address. - - <-----(3)--------------- - Resolver returns "A" RR - to application with IP - address. - - (4) - Application starts a TCP session - or UDP session and OS sends - first datagram - - ----(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)-----> - --------------> - <--------------- - <------------------- - <------------- - ]]></artwork> -</figure> - -</t> -</section> - -<section title="Opportunistic encryption"> - -<t> -In the presence of properly configured opportunistic encryptors, the -event list is extended. Only changes are annotated. -</t> - -<t>The following symbols are used in the time-sequence diagram</t> - -<t> -<list style="hanging"> - <t hangText="-"> A single dash represents clear-text datagrams.</t> - <t hangText="="> An equals sign represents phase 2 (IPsec) cipher-text - datagrams.</t> - <t hangText="~"> A single tilde represents clear-text phase 1 datagrams.</t> - <t hangText="#"> A hash sign represents phase 1 (IKE) cipher-text - datagrams.</t> -</list> -</t> - -<t> -<figure anchor="opportunistictiming" title="Timing of opportunistic encryption transaction"> - <artwork><![CDATA[ - Alice SG-A DNS SG-B Bob - (1) - ------(2)--------------> - <-----(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 - --------------> - <--------------- - <=================== - <------------- - ]]></artwork> -</figure> - -</t> - - <t> - For the purposes of this section, we will describe only the changes that - occur between <xref target="regulartiming" /> and - <xref target="opportunistictiming" />. This corresponds to time points 5, 6, 7, 9 and 10 on the list above. - </t> - -<list style="symbols"> - <t> - 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. - </t> - - <t> - 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. - </t> - </section> - - <section title="(5C) DNS returns TXT record(s)"> - - <t> - 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. - </t> - - <t> - Using the example above, the returned record might contain: - - <figure anchor="txtexample" - title="Example of reverse delegation record for Bob"> - <artwork><![CDATA[ -X-IPsec-Server(10)=192.1.1.5 AQMM...3s1Q== - ]]></artwork> - </figure> - with SG-B's IP address and public key listed. - </t> - - </section> - - <section title="(5D) Initial IKE main mode packet goes out"> - <t>Upon entering Pending OE connection, SG-A sends the initial ISAKMP - message with proposals. See <xref target="phase1id" />. - </t> - </section> - - <section title="(5E1) Message 2 of phase 1 exchange"> - <t> - SG-B receives the message. A new connection instance is created in the - unauthenticated OE peer state. - </t> - </section> - - <section title="(5E2) Message 3 of phase 1 exchange"> - <t> - SG-A sends a Diffie-Hellman exponent. This is an internal state of the - keying daemon. - </t> - </section> - - <section title="(5E3) Message 4 of phase 1 exchange"> - <t> - SG-B responds with a Diffie-Hellman exponent. This is an internal state of the - keying protocol. - </t> - </section> - - <section title="(5E4) Message 5 of phase 1 exchange"> - <t> - SG-A uses the phase 1 SA to send its identity under encryption. - The choice of identity is discussed in <xref target="phase1id" />. - This is an internal state of the keying protocol. - </t> - </section> - - <section title="(5F1) Responder lookup of initiator key"> - <t> - 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 <xref - target="KEY" /> for further details. - </t> - </section> - -<section title="(5F2) DNS replies with public key of initiator"> -<t> -Upon successfully authenticating the peer, the connection instance makes a -transition to authenticated OE peer on SG-B. -</t> -<t> -The format of the TXT record returned is described in -<xref target="TXT" />. -</t> -</section> - - <section title="(5E5) Responder replies with ID and authentication"> - <t> - SG-B sends its ID along with authentication material. This is an internal - state for the keying protocol. - </t> - </section> - - <section title="(5G) IKE phase 2"> - <section title="(5G1) Initiator proposes tunnel"> - <t> - 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. - </t> - </section> - - <section title="(5H1) Responder determines initiator's authority"> - <t> - 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. - </t> - <t>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.</t> - </section> - - <section title="(5H2) DNS replies with TXT record(s)"> - <t> - The returned key and IP address should match that of SG-A. - </t> - </section> - - <section title="(5G2) Responder agrees to proposal"> - <t> - 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. - </t> - <t>SG-A, having successfully keyed the tunnel, now makes a transition from - Pending OE connection to Keyed OE connection. - </t> - <t>The responder MUST setup the inbound IPsec SAs before sending its reply.</t> - </section> - - <section title="(5G3) Final acknowledgment from initiator"> - <t> - The initiator agrees with the responder's choice and sets up the tunnel. - The initiator sets up the inbound and outbound IPsec SAs. - </t> - <t> - The proper authorization returned with keys prompts SG-B to make a transition - to the keyed OE connection state. - </t> - <t>Upon receipt of this message, the responder may now setup the outbound - IPsec SAs.</t> - </section> - </section> - - <section title="(6) IPsec succeeds, and sets up tunnel for communication between Alice and Bob"> - <t> - 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). - </t> - </section> - - <section title="(9) SG-B already has tunnel up with G1 and uses it"> - <t> - 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). - </t> - - </section> -</section> <!-- OE example --> - -</section> <!-- Examples --> - -<section anchor="securityconsiderations" title="Security considerations"> - - <section title="Configured vs opportunistic tunnels"> -<t> - 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. -</t> -<t> -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. -</t> -<t> -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. -</t> -<t> -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. -</t> -<t> -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. -</t> -<t> -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. -</t> -<t> -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. -</t> - </section> - - <section title="Firewalls versus Opportunistic Tunnels"> -<t> - Typical usage of per datagram access control lists is to implement various -kinds of security gateways. These are typically called "firewalls". -</t> -<t> - 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. -</t> -<t> - 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. -</t> - </section> - - <section title="Denial of service"> -<t> - 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). -</t> -<t> - 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. -</t> - -</section> -</section> - -<section title="IANA Considerations"> -<t> - There are no known numbers which IANA will need to manage. -</t> -</section> - -<section title="Acknowledgments"> -<t> - Substantive portions of this document are based upon previous work by - Henry Spencer. -</t> -<t> - 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. -</t> -<t> - Sandra Hoffman and Bill Dickie did the detailed proof reading and editing. -</t> -</section> - -</middle> - -<back> -<references title="Normative references"> -<?rfc include="reference.OEspec" ?> -<!-- renumber according to reference order --> -<?rfc include="reference.RFC.0791" ?> -<?rfc include="reference.RFC.1009" ?> -<?rfc include="reference.RFC.1984" ?> -<?rfc include="reference.RFC.2119" ?> -<!-- IPsec --> -<?rfc include="reference.RFC.2367" ?> -<?rfc include="reference.RFC.2401" ?> -<?rfc include="reference.RFC.2407" ?> -<?rfc include="reference.RFC.2408" ?> -<?rfc include="reference.RFC.2409" ?> -<!-- MODPGROUPS --> -<?rfc include="reference.RFC.3526" ?> -<!-- DNSSEC --> -<?rfc include="reference.RFC.1034" ?> -<?rfc include="reference.RFC.1035" ?> -<?rfc include="reference.RFC.2671" ?> -<?rfc include="reference.RFC.1464" ?> -<?rfc include="reference.RFC.2535" ?> -<?rfc include="reference.RFC.3110" ?> -<?rfc include="reference.RFC.2538" ?> -<!-- COPS --> -<?rfc include="reference.RFC.2748" ?> -<!-- NAT --> -<?rfc include="reference.RFC.2663" ?> -</references> -<!-- <references title="Non-normative references"> --> -<!-- ESPUDP --> -<!-- <?rfc include="reference.ESPUDP" ?> --> -<!-- </references> --> -</back> -</rfc> -<!-- - $Id: draft-richardson-ipsec-opportunistic.xml,v 1.1 2004/03/15 20:35:24 as Exp $ - - $Log: draft-richardson-ipsec-opportunistic.xml,v $ - Revision 1.1 2004/03/15 20:35:24 as - added files from freeswan-2.04-x509-1.5.3 - - Revision 1.33 2003/06/30 03:19:59 mcr - timing-diagram with inline explanation. - - Revision 1.32 2003/06/30 01:57:44 mcr - initial edits per-Bob Braden. - - Revision 1.31 2003/05/26 19:31:23 mcr - updates to drafts - IPSEC RR - SC versions, and RFC3526 - reference in OE draft. - - Revision 1.30 2003/05/21 15:42:34 mcr - updates due to publication of RFC 3526. - - Revision 1.29 2003/01/17 16:22:55 mcr - rev 11 of OE draft. - - Revision 1.28 2002/07/25 19:27:31 mcr - added DHR's minor edits. - - Revision 1.27 2002/07/21 16:26:26 mcr - slides from presentation at OLS - draft-10 of OE draft. - - Revision 1.26 2002/07/16 03:46:53 mcr - second edits from Sandra. - - Revision 1.25 2002/07/16 03:36:14 mcr - removed HS from authors list - updated reference inclusion to use <?rfc-include directive. - Revision 1.24 2002/07/11 02:08:21 mcr - updated XML file from Sandra - - Revision 1.23 2002/06/06 17:18:53 mcr - spellcheck. - - Revision 1.22 2002/06/06 17:14:19 mcr - results of hand-editing session from May 28th. - This is FINAL OE draft. - - Revision 1.21 2002/06/06 02:25:44 mcr - results of hand-editing session from May 28th. - This is FINAL OE draft. - - Revision 1.20 2002/05/24 03:28:37 mcr - changes as requested by RFC editor. - - Revision 1.19 2002/04/09 16:01:05 mcr - comments from PHB. - - Revision 1.18 2002/04/08 02:14:34 mcr - RGBs changes to rev6. - - Revision 1.17 2002/03/12 21:23:55 mcr - adjusted definition of default-free zone. - moved text on key rollover from format description to new - section. - - Revision 1.16 2002/02/22 01:23:21 mcr - revisions from MCR (2002/2/18) and net. - - Revision 1.15 2002/02/21 20:44:12 mcr - extensive from DHR. - - Revision 1.14 2002/02/10 16:20:39 mcr - -05 draft. Many revisions to do "OE system in world of OE systems" - view of the universe. - - Revision 1.13 2001/12/20 04:35:22 mcr - fixed reference to rfc1984. - - Revision 1.12 2001/12/20 03:35:19 mcr - comments from Henry, Tero, and Sandy. - - Revision 1.11 2001/12/19 07:26:22 mcr - added comment about KX records. - - Revision 1.10 2001/11/09 04:28:10 mcr - fixed some typos with XML, and one s/SG-B/SG-D/. - - Revision 1.9 2001/11/09 04:07:13 mcr - expanded section 10: multihoming, with an example. - - Revision 1.8 2001/11/09 02:16:51 mcr - added lifetime/lifespan definitions. - moved example from 5B to 5C. - added reference to phase 1 IDs to 5D. - cleared up text in aging section. - added text about delegation of DNSSEC activity to a DNS server. - spelt out DH group names. - added text about ignoring TXT records unless DNSSEC is deployed (somerfeld) - added example of TXT delegation using FQDN. - clarified some text in NAT interaction section. - clarified absense of TXT record need for host implementation - - Revision 1.7 2001/11/08 23:09:37 mcr - changed revision of draft to 03. - - Revision 1.6 2001/11/08 19:37:14 mcr - fixed some formatting of Aging section. - - Revision 1.5 2001/11/08 19:19:30 mcr - fixed address for DHR, updated address for MCR, - added reference to original HS/DHR OE specification paper. - - Revision 1.4 2001/11/08 19:08:24 mcr - section 10, "Renewal and Teardown" added moved between 4/5, and - slightly rewritten. - - Revision 1.3 2001/11/08 18:56:34 mcr - sections 4.2, 5.6, 5.7.1 and 6.2 edited as per HS. - section 10, "Renewal and Teardown" added. - section 11, "Failure modes" completed. - - Revision 1.2 2001/11/05 20:31:31 mcr - added section from OE spec on aging and teardown. - - Revision 1.1 2001/11/05 04:27:58 mcr - OE draft added to documentation. - - Revision 1.12 2001/10/10 01:12:31 mcr - removed impact on DNS servers section. - removed nested comments. - adjusted data of issue - - Revision 1.11 2001/09/17 02:55:50 mcr - outline is now stable. - - Revision 1.5 2001/08/19 02:53:32 mcr - version 00d formatted. - - Revision 1.10 2001/08/19 02:34:04 mcr - version 00d formatted. - - Revision 1.9 2001/08/19 02:21:54 mcr - version 00d - - Revision 1.8 2001/07/20 19:07:06 mcr - commented out section 1.1 - - Revision 1.7 2001/07/20 14:14:22 mcr - HS and HD comments. - - Revision 1.6 2001/07/19 00:56:50 mcr - version 00b. - - Revision 1.5 2001/07/12 23:57:07 mcr - OE ID, 00. - - -!> diff --git a/doc/src/draft-richardson-ipsec-rr.html b/doc/src/draft-richardson-ipsec-rr.html deleted file mode 100644 index 08473104f..000000000 --- a/doc/src/draft-richardson-ipsec-rr.html +++ /dev/null @@ -1,659 +0,0 @@ -<html><head><title>A method for storing IPsec keying material in DNS.</title> -<STYLE type='text/css'> - .title { color: #990000; font-size: 22px; line-height: 22px; font-weight: bold; text-align: right; - font-family: helvetica, arial, sans-serif } - .filename { color: #666666; font-size: 18px; line-height: 28px; font-weight: bold; text-align: right; - font-family: helvetica, arial, sans-serif } - p.copyright { color: #000000; font-size: 10px; - font-family: verdana, charcoal, helvetica, arial, sans-serif } - p { margin-left: 2em; margin-right: 2em; } - li { margin-left: 3em; } - ol { margin-left: 2em; margin-right: 2em; } - ul.text { margin-left: 2em; margin-right: 2em; } - pre { margin-left: 3em; color: #333333 } - ul.toc { color: #000000; line-height: 16px; - font-family: verdana, charcoal, helvetica, arial, sans-serif } - H3 { color: #333333; font-size: 16px; line-height: 16px; font-family: helvetica, arial, sans-serif } - H4 { color: #000000; font-size: 14px; font-family: helvetica, arial, sans-serif } - TD.header { color: #ffffff; font-size: 10px; font-family: arial, helvetica, san-serif; valign: top } - TD.author-text { color: #000000; font-size: 10px; - font-family: verdana, charcoal, helvetica, arial, sans-serif } - TD.author { color: #000000; font-weight: bold; margin-left: 4em; font-size: 10px; font-family: verdana, charcoal, helvetica, arial, sans-serif } - A:link { color: #990000; font-weight: bold; - font-family: MS Sans Serif, verdana, charcoal, helvetica, arial, sans-serif } - A:visited { color: #333333; font-weight: bold; - font-family: MS Sans Serif, verdana, charcoal, helvetica, arial, sans-serif } - A:name { color: #333333; font-weight: bold; - font-family: MS Sans Serif, verdana, charcoal, helvetica, arial, sans-serif } - .link2 { color:#ffffff; font-weight: bold; text-decoration: none; - font-family: monaco, charcoal, geneva, MS Sans Serif, helvetica, monotype, verdana, sans-serif; - font-size: 9px } - .RFC { color:#666666; font-weight: bold; text-decoration: none; - font-family: monaco, charcoal, geneva, MS Sans Serif, helvetica, monotype, verdana, sans-serif; - font-size: 9px } - .hotText { color:#ffffff; font-weight: normal; text-decoration: none; - font-family: charcoal, monaco, geneva, MS Sans Serif, helvetica, monotype, verdana, sans-serif; - font-size: 9px } -</style> -</head> -<body bgcolor="#ffffff" text="#000000" alink="#000000" vlink="#666666" link="#990000"> -<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> -<table width="66%" border="0" cellpadding="0" cellspacing="0"><tr><td><table width="100%" border="0" cellpadding="2" cellspacing="1"> -<tr valign="top"><td width="33%" bgcolor="#666666" class="header">IPSECKEY WG</td><td width="33%" bgcolor="#666666" class="header">M. Richardson</td></tr> -<tr valign="top"><td width="33%" bgcolor="#666666" class="header">Internet-Draft</td><td width="33%" bgcolor="#666666" class="header">SSW</td></tr> -<tr valign="top"><td width="33%" bgcolor="#666666" class="header">Expires: March 4, 2004</td><td width="33%" bgcolor="#666666" class="header">September 4, 2003</td></tr> -</table></td></tr></table> -<div align="right"><font face="monaco, MS Sans Serif" color="#990000" size="+3"><b><br><span class="title">A method for storing IPsec keying material in DNS.</span></b></font></div> -<div align="right"><font face="monaco, MS Sans Serif" color="#666666" size="+2"><b><span class="filename">draft-ietf-ipseckey-rr-07.txt</span></b></font></div> -<font face="verdana, helvetica, arial, sans-serif" size="2"> - -<h3>Status of this Memo</h3> -<p> -This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026.</p> -<p> -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.</p> -<p> -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."</p> -<p> -The list of current Internet-Drafts can be accessed at -<a href='http://www.ietf.org/ietf/1id-abstracts.txt'>http://www.ietf.org/ietf/1id-abstracts.txt</a>.</p> -<p> -The list of Internet-Draft Shadow Directories can be accessed at -<a href='http://www.ietf.org/shadow.html'>http://www.ietf.org/shadow.html</a>.</p> -<p> -This Internet-Draft will expire on March 4, 2004.</p> - -<h3>Copyright Notice</h3> -<p> -Copyright (C) The Internet Society (2003). All Rights Reserved.</p> - -<h3>Abstract</h3> - -<p> -This document describes a new resource record for DNS. This record may be -used to store public keys for use in IPsec systems. - -</p> -<p> -This record replaces the functionality of the sub-type #1 of the KEY Resource -Record, which has been obsoleted by RFC3445. - -</p><a name="toc"><br><hr size="1" shade="0"></a> -<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> -<h3>Table of Contents</h3> -<ul compact class="toc"> -<b><a href="#anchor1">1.</a> -Introduction<br></b> -<b><a href="#anchor2">1.1</a> -Overview<br></b> -<b><a href="#anchor3">1.2</a> -Usage Criteria<br></b> -<b><a href="#anchor4">2.</a> -Storage formats<br></b> -<b><a href="#anchor5">2.1</a> -IPSECKEY RDATA format<br></b> -<b><a href="#anchor6">2.2</a> -RDATA format - precedence<br></b> -<b><a href="#algotype">2.3</a> -RDATA format - algorithm type<br></b> -<b><a href="#gatewaytype">2.4</a> -RDATA format - gateway type<br></b> -<b><a href="#anchor7">2.5</a> -RDATA format - gateway<br></b> -<b><a href="#anchor8">2.6</a> -RDATA format - public keys<br></b> -<b><a href="#anchor9">3.</a> -Presentation formats<br></b> -<b><a href="#anchor10">3.1</a> -Representation of IPSECKEY RRs<br></b> -<b><a href="#anchor11">3.2</a> -Examples<br></b> -<b><a href="#anchor12">4.</a> -Security Considerations<br></b> -<b><a href="#anchor13">4.1</a> -Active attacks against unsecured IPSECKEY resource records<br></b> -<b><a href="#anchor14">5.</a> -IANA Considerations<br></b> -<b><a href="#anchor15">6.</a> -Acknowledgments<br></b> -<b><a href="#rfc.references1">§</a> -Normative references<br></b> -<b><a href="#rfc.references2">§</a> -Non-normative references<br></b> -<b><a href="#rfc.authors">§</a> -Author's Address<br></b> -<b><a href="#rfc.copyright">§</a> -Full Copyright Statement<br></b> -</ul> -<br clear="all"> - -<a name="anchor1"><br><hr size="1" shade="0"></a> -<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> -<a name="rfc.section.1"></a><h3>1. Introduction</h3> - -<p> - The type number for the IPSECKEY RR is TBD. - -</p> -<a name="rfc.section.1.1"></a><h4><a name="anchor2">1.1</a> Overview</h4> - -<p> - The IPSECKEY resource record (RR) is used to publish a public key that is - to be associated with a Domain Name System (DNS) name for use with the - IPsec protocol suite. This can be the public key of a host, - network, or application (in the case of per-port keying). - -</p> -<p> - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL - NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and - "OPTIONAL" in this document are to be interpreted as described in - RFC2119 <a href="#RFC2119">[8]</a>. - -</p> -<a name="rfc.section.1.2"></a><h4><a name="anchor3">1.2</a> Usage Criteria</h4> - -<p> - An IPSECKEY resource record SHOULD be used in combination with DNSSEC -unless some other means of authenticating the IPSECKEY resource record -is available. - -</p> -<p> - It is expected that there will often be multiple IPSECKEY resource - records at the same name. This will be due to the presence - of multiple gateways and the need to rollover keys. - - -</p> -<p> - This resource record is class independent. - -</p> -<a name="anchor4"><br><hr size="1" shade="0"></a> -<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> -<a name="rfc.section.2"></a><h3>2. Storage formats</h3> - -<a name="rfc.section.2.1"></a><h4><a name="anchor5">2.1</a> IPSECKEY RDATA format</h4> - -<p> - The RDATA for an IPSECKEY RR consists of a precedence value, a public key, - algorithm type, and an optional gateway address. - -</p></font><pre> - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | precedence | gateway type | algorithm | gateway | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+ + - ~ gateway ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | / - / public key / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| -</pre><font face="verdana, helvetica, arial, sans-serif" size="2"> - -<a name="rfc.section.2.2"></a><h4><a name="anchor6">2.2</a> RDATA format - precedence</h4> - -<p> -This is an 8-bit precedence for this record. This is interpreted in -the same way as the PREFERENCE field described in section -3.3.9 of RFC1035 <a href="#RFC1035">[2]</a>. - -</p> -<p> -Gateways listed in IPSECKEY records with lower precedence are -to be attempted first. Where there is a tie in precedence, the order -should be non-deterministic. - -</p> -<a name="rfc.section.2.3"></a><h4><a name="algotype">2.3</a> RDATA format - algorithm type</h4> - -<p> -The algorithm type field identifies the public key's cryptographic -algorithm and determines the format of the public key field. - -</p> -<p> -A value of 0 indicates that no key is present. - -</p> -<p> -The following values are defined: - -<blockquote class="text"><dl> -<dt>1</dt> -<dd>A DSA key is present, in the format defined in RFC2536 <a href="#RFC2536">[11]</a> -</dd> -<dt>2</dt> -<dd>A RSA key is present, in the format defined in RFC3110 <a href="#RFC3110">[12]</a> -</dd> -</dl></blockquote><p> -</p> -<a name="rfc.section.2.4"></a><h4><a name="gatewaytype">2.4</a> RDATA format - gateway type</h4> - -<p> -The gateway type field indicates the format of the information that -is stored in the gateway field. - -</p> -<p> -The following values are defined: - -<blockquote class="text"><dl> -<dt>0</dt> -<dd>No gateway is present -</dd> -<dt>1</dt> -<dd>A 4-byte IPv4 address is present -</dd> -<dt>2</dt> -<dd>A 16-byte IPv6 address is present -</dd> -<dt>3</dt> -<dd>A wire-encoded domain name is present. The wire-encoded -format is self-describing, so the length is implicit. The domain name -MUST NOT be compressed. -</dd> -</dl></blockquote><p> -</p> -<a name="rfc.section.2.5"></a><h4><a name="anchor7">2.5</a> RDATA format - gateway</h4> - -<p> -The gateway field indicates a gateway to which an IPsec tunnel may be -created in order to reach the entity named by this resource record. - -</p> -<p> -There are three formats: - -</p> -<p> -A 32-bit IPv4 address is present in the gateway field. The data -portion is an IPv4 address as described in section 3.4.1 of -<a href="#RFC1035">RFC1035</a>[2]. This is a 32-bit number in network byte order. - -</p> -<p>A 128-bit IPv6 address is present in the gateway field. -The data portion is an IPv6 address as described in section 2.2 of -<a href="#RFC1886">RFC1886</a>[7]. This is a 128-bit number in network byte order. - -</p> -<p> -The gateway field is a normal wire-encoded domain name, as described -in section 3.3 of RFC1035 <a href="#RFC1035">[2]</a>. Compression MUST NOT be used. - -</p> -<a name="rfc.section.2.6"></a><h4><a name="anchor8">2.6</a> RDATA format - public keys</h4> - -<p> -Both of the public key types defined in this document (RSA and DSA) -inherit their public key formats from the corresponding KEY RR formats. -Specifically, the public key field contains the algorithm-specific -portion of the KEY RR RDATA, which is all of the KEY RR DATA after the -first four octets. This is the same portion of the KEY RR that must be -specified by documents that define a DNSSEC algorithm. -Those documents also specify a message digest to be used for generation -of SIG RRs; that specification is not relevant for IPSECKEY RR. - -</p> -<p> -Future algorithms, if they are to be used by both DNSSEC (in the KEY -RR) and IPSECKEY, are likely to use the same public key encodings in -both records. Unless otherwise specified, the IPSECKEY public key -field will contain the algorithm-specific portion of the KEY RR RDATA -for the corresponding algorithm. The algorithm must still be -designated for use by IPSECKEY, and an IPSECKEY algorithm type number -(which might be different than the DNSSEC algorithm number) must be -assigned to it. - -</p> -<p>The DSA key format is defined in RFC2536 <a href="#RFC2536">[11]</a> -</p> -<p>The RSA key format is defined in RFC3110 <a href="#RFC3110">[12]</a>, -with the following changes: -</p> -<p> -The earlier definition of RSA/MD5 in RFC2065 limited the exponent and -modulus to 2552 bits in length. RFC3110 extended that limit to 4096 -bits for RSA/SHA1 keys. The IPSECKEY RR imposes no length limit on -RSA public keys, other than the 65535 octet limit imposed by the -two-octet length encoding. This length extension is applicable only -to IPSECKEY and not to KEY RRs. - -</p> -<a name="anchor9"><br><hr size="1" shade="0"></a> -<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> -<a name="rfc.section.3"></a><h3>3. Presentation formats</h3> - -<a name="rfc.section.3.1"></a><h4><a name="anchor10">3.1</a> Representation of IPSECKEY RRs</h4> - -<p> - IPSECKEY RRs may appear in a zone data master file. - The precedence, gateway type and algorithm and gateway fields are REQUIRED. - The base64 encoded public key block is OPTIONAL; if not present, - then the public key field of the resource record MUST be construed - as being zero octets in length. - -</p> -<p> - The algorithm field is an unsigned integer. No mnemonics are defined. - -</p> -<p> - If no gateway is to be indicated, then the gateway type field MUST - be zero, and the gateway field MUST be "." - -</p> -<p> - The Public Key field is represented as a Base64 encoding of the - Public Key. Whitespace is allowed within the Base64 text. For a - definition of Base64 encoding, see -<a href="#RFC1521">RFC1521</a>[3] Section 5.2. - -</p> -<p> - The general presentation for the record as as follows: -</p> -</font><pre> -IN IPSECKEY ( precedence gateway-type algorithm - gateway base64-encoded-public-key ) -</pre><font face="verdana, helvetica, arial, sans-serif" size="2"> -<p> - -</p> -<a name="rfc.section.3.2"></a><h4><a name="anchor11">3.2</a> Examples</h4> - -<p> -An example of a node 192.0.2.38 that will accept IPsec tunnels on its -own behalf. -</p> -</font><pre> -38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 - 192.0.2.38 - AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) -</pre><font face="verdana, helvetica, arial, sans-serif" size="2"> -<p> - -</p> -<p> -An example of a node, 192.0.2.38 that has published its key only. -</p> -</font><pre> -38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 0 2 - . - AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) -</pre><font face="verdana, helvetica, arial, sans-serif" size="2"> -<p> - -</p> -<p> -An example of a node, 192.0.2.38 that has delegated authority to the node -192.0.2.3. -</p> -</font><pre> -38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 - 192.0.2.3 - AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) -</pre><font face="verdana, helvetica, arial, sans-serif" size="2"> -<p> - -</p> -<p> -An example of a node, 192.0.1.38 that has delegated authority to the node -with the identity "mygateway.example.com". -</p> -</font><pre> -38.1.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 3 2 - mygateway.example.com. - AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) -</pre><font face="verdana, helvetica, arial, sans-serif" size="2"> -<p> - -</p> -<p> -An example of a node, 2001:0DB8:0200:1:210:f3ff:fe03:4d0 that has -delegated authority to the node 2001:0DB8:c000:0200:2::1 -</p> -</font><pre> -$ORIGIN 1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.int. -0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN IPSECKEY ( 10 2 2 - 2001:0DB8:0:8002::2000:1 - AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) -</pre><font face="verdana, helvetica, arial, sans-serif" size="2"> -<p> - -</p> -<a name="anchor12"><br><hr size="1" shade="0"></a> -<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> -<a name="rfc.section.4"></a><h3>4. Security Considerations</h3> - -<p> - This entire memo pertains to the provision of public keying material - for use by key management protocols such as ISAKMP/IKE (RFC2407) - <a href="#RFC2407">[9]</a>. - -</p> -<p> -The IPSECKEY resource record contains information that SHOULD be -communicated to the end client in an integral fashion - i.e. free from -modification. The form of this channel is up to the consumer of the -data - there must be a trust relationship between the end consumer of this -resource record and the server. This relationship may be end-to-end -DNSSEC validation, a TSIG or SIG(0) channel to another secure source, -a secure local channel on the host, or some combination of the above. - -</p> -<p> -The keying material provided by the IPSECKEY resource record is not -sensitive to passive attacks. The keying material may be freely -disclosed to any party without any impact on the security properties -of the resulting IPsec session: IPsec and IKE provide for defense -against both active and passive attacks. - -</p> -<p> - Any user of this resource record MUST carefully document their trust - model, and why the trust model of DNSSEC is appropriate, if that is - the secure channel used. - -</p> -<a name="rfc.section.4.1"></a><h4><a name="anchor13">4.1</a> Active attacks against unsecured IPSECKEY resource records</h4> - -<p> -This section deals with active attacks against the DNS. These attacks -require that DNS requests and responses be intercepted and changed. -DNSSEC is designed to defend against attacks of this kind. - -</p> -<p> -The first kind of active attack is when the attacker replaces the -keying material with either a key under its control or with garbage. - -</p> -<p> -If the attacker is not able to mount a subsequent -man-in-the-middle attack on the IKE negotiation after replacing the -public key, then this will result in a denial of service, as the -authenticator used by IKE would fail. - -</p> -<p> -If the attacker is able to both to mount active attacks against DNS -and is also in a position to perform a man-in-the-middle attack on IKE and -IPsec negotiations, then the attacker will be in a position to compromise -the resulting IPsec channel. Note that an attacker must be able to -perform active DNS attacks on both sides of the IKE negotiation in -order for this to succeed. - -</p> -<p> -The second kind of active attack is one in which the attacker replaces -the the gateway address to point to a node under the attacker's -control. The attacker can then either replace the public key or remove -it, thus providing an IPSECKEY record of its own to match the -gateway address. - -</p> -<p> -This later form creates a simple man-in-the-middle since the attacker -can then create a second tunnel to the real destination. Note that, as before, -this requires that the attacker also mount an active attack against -the responder. - -</p> -<p> -Note that the man-in-the-middle can not just forward cleartext -packets to the original destination. While the destination may be -willing to speak in the clear, replying to the original sender, -the sender will have already created a policy expecting ciphertext. -Thus, the attacker will need to intercept traffic from both sides. In some -cases, the attacker may be able to accomplish the full intercept by use -of Network Addresss/Port Translation (NAT/NAPT) technology. - -</p> -<p> -Note that the danger here only applies to cases where the gateway -field of the IPSECKEY RR indicates a different entity than the owner -name of the IPSECKEY RR. In cases where the end-to-end integrity of -the IPSECKEY RR is suspect, the end client MUST restrict its use -of the IPSECKEY RR to cases where the RR owner name matches the -content of the gateway field. - -</p> -<a name="anchor14"><br><hr size="1" shade="0"></a> -<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> -<a name="rfc.section.5"></a><h3>5. IANA Considerations</h3> - -<p> -This document updates the IANA Registry for DNS Resource Record Types -by assigning type X to the IPSECKEY record. - -</p> -<p> -This document creates an IANA registry for the algorithm type field. - -</p> -<p> -Values 0, 1 and 2 are defined in <a href="#algotype">RDATA format - algorithm type</a>. Algorithm numbers -3 through 255 can be assigned by IETF Consensus (<a href="#RFC2434">see RFC2434</a>[6]). - -</p> -<p> -This document creates an IANA registry for the gateway type field. - -</p> -<p> -Values 0, 1, 2 and 3 are defined in <a href="#gatewaytype">RDATA format - gateway type</a>. -Algorithm numbers 4 through 255 can be assigned by -Standards Action (<a href="#RFC2434">see RFC2434</a>[6]). - -</p> -<a name="anchor15"><br><hr size="1" shade="0"></a> -<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> -<a name="rfc.section.6"></a><h3>6. Acknowledgments</h3> - -<p> -My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob Austein, -and Olafur Gurmundsson who reviewed this document carefully. -Additional thanks to Olafur Gurmundsson for a reference implementation. - -</p> -<a name="rfc.references1"><br><hr size="1" shade="0"></a> -<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> -<h3>Normative references</h3> -<table width="99%" border="0"> -<tr><td class="author-text" valign="top"><b><a name="RFC1034">[1]</a></b></td> -<td class="author-text">Mockapetris, P., "<a href="ftp://ftp.isi.edu/in-notes/rfc1034.txt">Domain names - concepts and facilities</a>", STD 13, RFC 1034, November 1987.</td></tr> -<tr><td class="author-text" valign="top"><b><a name="RFC1035">[2]</a></b></td> -<td class="author-text"><a href="mailto:">Mockapetris, P.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc1035.txt">Domain names - implementation and specification</a>", STD 13, RFC 1035, November 1987.</td></tr> -<tr><td class="author-text" valign="top"><b><a name="RFC1521">[3]</a></b></td> -<td class="author-text"><a href="mailto:nsb@bellcore.com">Borenstein, N.</a> and <a href="mailto:">N. Freed</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc1521.txt">MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies</a>", RFC 1521, September 1993.</td></tr> -<tr><td class="author-text" valign="top"><b><a name="RFC2026">[4]</a></b></td> -<td class="author-text"><a href="mailto:sob@harvard.edu">Bradner, S.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2026.txt">The Internet Standards Process -- Revision 3</a>", BCP 9, RFC 2026, October 1996.</td></tr> -<tr><td class="author-text" valign="top"><b><a name="RFC2065">[5]</a></b></td> -<td class="author-text"><a href="mailto:dee@cybercash.com">Eastlake, D.</a> and <a href="mailto:charlie_kaufman@iris.com">C. Kaufman</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2065.txt">Domain Name System Security Extensions</a>", RFC 2065, January 1997.</td></tr> -<tr><td class="author-text" valign="top"><b><a name="RFC2434">[6]</a></b></td> -<td class="author-text"><a href="mailto:narten@raleigh.ibm.com">Narten, T.</a> and <a href="mailto:Harald@Alvestrand.no">H. Alvestrand</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2434.txt">Guidelines for Writing an IANA Considerations Section in RFCs</a>", BCP 26, RFC 2434, October 1998.</td></tr> -</table> - -<a name="rfc.references2"><br><hr size="1" shade="0"></a> -<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> -<h3>Non-normative references</h3> -<table width="99%" border="0"> -<tr><td class="author-text" valign="top"><b><a name="RFC1886">[7]</a></b></td> -<td class="author-text"><a href="mailto:set@thumper.bellcore.com">Thomson, S.</a> and <a href="mailto:Christian.Huitema@MIRSA.INRIA.FR">C. Huitema</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc1886.txt">DNS Extensions to support IP version 6</a>", RFC 1886, December 1995.</td></tr> -<tr><td class="author-text" valign="top"><b><a name="RFC2119">[8]</a></b></td> -<td class="author-text"><a href="mailto:-">Bradner, S.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2119.txt">Key words for use in RFCs to Indicate Requirement Levels</a>", BCP 14, RFC 2119, March 1997.</td></tr> -<tr><td class="author-text" valign="top"><b><a name="RFC2407">[9]</a></b></td> -<td class="author-text"><a href="mailto:ddp@network-alchemy.com">Piper, D.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2407.txt">The Internet IP Security Domain of Interpretation for ISAKMP</a>", RFC 2407, November 1998.</td></tr> -<tr><td class="author-text" valign="top"><b><a name="RFC2535">[10]</a></b></td> -<td class="author-text"><a href="mailto:dee3@us.ibm.com">Eastlake, D.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2535.txt">Domain Name System Security Extensions</a>", RFC 2535, March 1999.</td></tr> -<tr><td class="author-text" valign="top"><b><a name="RFC2536">[11]</a></b></td> -<td class="author-text"><a href="mailto:dee3@us.ibm.com">Eastlake, D.</a>, "<a href="ftp://ftp.isi.edu/in-notes/rfc2536.txt">DSA KEYs and SIGs in the Domain Name System (DNS)</a>", RFC 2536, March 1999.</td></tr> -<tr><td class="author-text" valign="top"><b><a name="RFC3110">[12]</a></b></td> -<td class="author-text">Eastlake, D., "<a href="ftp://ftp.isi.edu/in-notes/rfc3110.txt">RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS)</a>", RFC 3110, May 2001.</td></tr> -<tr><td class="author-text" valign="top"><b><a name="RFC3445">[13]</a></b></td> -<td class="author-text">Massey, D. and S. Rose, "<a href="ftp://ftp.isi.edu/in-notes/rfc3445.txt">Limiting the Scope of the KEY Resource Record (RR)</a>", RFC 3445, December 2002.</td></tr> -</table> - -<a name="rfc.authors"><br><hr size="1" shade="0"></a> -<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> -<h3>Author's Address</h3> -<table width="99%" border="0" cellpadding="0" cellspacing="0"> -<tr><td class="author-text"> </td> -<td class="author-text">Michael C. Richardson</td></tr> -<tr><td class="author-text"> </td> -<td class="author-text">Sandelman Software Works</td></tr> -<tr><td class="author-text"> </td> -<td class="author-text">470 Dawson Avenue</td></tr> -<tr><td class="author-text"> </td> -<td class="author-text">Ottawa, ON K1Z 5V7</td></tr> -<tr><td class="author-text"> </td> -<td class="author-text">CA</td></tr> -<tr><td class="author" align="right">EMail: </td> -<td class="author-text"><a href="mailto:mcr@sandelman.ottawa.on.ca">mcr@sandelman.ottawa.on.ca</a></td></tr> -<tr><td class="author" align="right">URI: </td> -<td class="author-text"><a href="http://www.sandelman.ottawa.on.ca/">http://www.sandelman.ottawa.on.ca/</a></td></tr> -</table> -<a name="rfc.copyright"><br><hr size="1" shade="0"></a> -<table border="0" cellpadding="0" cellspacing="2" width="30" height="15" align="right"><tr><td bgcolor="#990000" align="center" width="30" height="15"><a href="#toc" CLASS="link2"><font face="monaco, MS Sans Serif" color="#ffffff" size="1"><b> TOC </b></font></a><br></td></tr></table> -<h3>Full Copyright Statement</h3> -<p class='copyright'> -Copyright (C) The Internet Society (2003). All Rights Reserved.</p> -<p class='copyright'> -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.</p> -<p class='copyright'> -The limited permissions granted above are perpetual and will not be -revoked by the Internet Society or its successors or assigns.</p> -<p class='copyright'> -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.</p> -<h3>Acknowledgement</h3> -<p class='copyright'> -Funding for the RFC Editor function is currently provided by the -Internet Society.</p> -</font></body></html> diff --git a/doc/src/draft-richardson-ipsec-rr.xml b/doc/src/draft-richardson-ipsec-rr.xml deleted file mode 100644 index e51b32615..000000000 --- a/doc/src/draft-richardson-ipsec-rr.xml +++ /dev/null @@ -1,560 +0,0 @@ -<?xml version="1.0"?> -<!DOCTYPE rfc SYSTEM "rfc2629.dtd"> -<?rfc toc="yes"?> - -<rfc ipr="full2026" docName="draft-ietf-ipseckey-rr-07.txt"> - -<front> - <area>Security</area> - <workgroup>IPSECKEY WG</workgroup> - <title abbrev="ipsecrr"> - A method for storing IPsec keying material in DNS. - </title> - - <author initials="M." surname="Richardson" fullname="Michael C. Richardson"> - <organization abbrev="SSW">Sandelman Software Works</organization> - <address> - <postal> - <street>470 Dawson Avenue</street> - <city>Ottawa</city> - <region>ON</region> - <code>K1Z 5V7</code> - <country>CA</country> - </postal> - <email>mcr@sandelman.ottawa.on.ca</email> - <uri>http://www.sandelman.ottawa.on.ca/</uri> - </address> - </author> - - <date month="September" year="2003" /> - -<abstract> - <t> -This document describes a new resource record for DNS. This record may be -used to store public keys for use in IPsec systems. -</t> - -<t> -This record replaces the functionality of the sub-type #1 of the KEY Resource -Record, which has been obsoleted by RFC3445. -</t> -</abstract> - -</front> - -<middle> - -<section title="Introduction"> -<t> - The type number for the IPSECKEY RR is TBD. -</t> - -<section title="Overview"> -<t> - The IPSECKEY resource record (RR) is used to publish a public key that is - to be associated with a Domain Name System (DNS) name for use with the - IPsec protocol suite. This can be the public key of a host, - network, or application (in the case of per-port keying). -</t> - -<t> - The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL - NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and - "OPTIONAL" in this document are to be interpreted as described in - RFC2119 <xref target="RFC2119" />. -</t> -</section> - -<section title="Usage Criteria"> -<t> - An IPSECKEY resource record SHOULD be used in combination with DNSSEC -unless some other means of authenticating the IPSECKEY resource record -is available. -</t> - -<t> - It is expected that there will often be multiple IPSECKEY resource - records at the same name. This will be due to the presence - of multiple gateways and the need to rollover keys. - -</t> - -<t> - This resource record is class independent. -</t> -</section> -</section> - -<section title="Storage formats"> - -<section title="IPSECKEY RDATA format"> - -<t> - The RDATA for an IPSECKEY RR consists of a precedence value, a public key, - algorithm type, and an optional gateway address. -</t> - -<artwork><![CDATA[ - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | precedence | gateway type | algorithm | gateway | - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------+ + - ~ gateway ~ - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - | / - / public key / - / / - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-| -]]></artwork> -</section> - -<section title="RDATA format - precedence"> -<t> -This is an 8-bit precedence for this record. This is interpreted in -the same way as the PREFERENCE field described in section -3.3.9 of RFC1035 <xref target="RFC1035" />. -</t> -<t> -Gateways listed in IPSECKEY records with lower precedence are -to be attempted first. Where there is a tie in precedence, the order -should be non-deterministic. -</t> -</section> - -<section anchor="algotype" title="RDATA format - algorithm type"> -<t> -The algorithm type field identifies the public key's cryptographic -algorithm and determines the format of the public key field. -</t> - -<t> -A value of 0 indicates that no key is present. -</t> - -<t> -The following values are defined: - <list style="hanging"> - <t hangText="1">A DSA key is present, in the format defined in RFC2536 <xref target="RFC2536" /></t> - <t hangText="2">A RSA key is present, in the format defined in RFC3110 <xref target="RFC3110" /></t> - </list> -</t> - -</section> - -<section anchor="gatewaytype" title="RDATA format - gateway type"> -<t> -The gateway type field indicates the format of the information that -is stored in the gateway field. -</t> - -<t> -The following values are defined: - <list style="hanging"> - <t hangText="0">No gateway is present</t> - <t hangText="1">A 4-byte IPv4 address is present</t> - <t hangText="2">A 16-byte IPv6 address is present</t> - <t hangText="3">A wire-encoded domain name is present. The wire-encoded -format is self-describing, so the length is implicit. The domain name -MUST NOT be compressed.</t> - </list> -</t> - -</section> - -<section title="RDATA format - gateway"> -<t> -The gateway field indicates a gateway to which an IPsec tunnel may be -created in order to reach the entity named by this resource record. -</t> -<t> -There are three formats: -</t> - -<t> -A 32-bit IPv4 address is present in the gateway field. The data -portion is an IPv4 address as described in section 3.4.1 of -<xref target="RFC1035">RFC1035</xref>. This is a 32-bit number in network byte order. -</t> - -<t>A 128-bit IPv6 address is present in the gateway field. -The data portion is an IPv6 address as described in section 2.2 of -<xref target="RFC1886">RFC1886</xref>. This is a 128-bit number in network byte order. -</t> - -<t> -The gateway field is a normal wire-encoded domain name, as described -in section 3.3 of RFC1035 <xref target="RFC1035" />. Compression MUST NOT be used. -</t> - -</section> - -<section title="RDATA format - public keys"> -<t> -Both of the public key types defined in this document (RSA and DSA) -inherit their public key formats from the corresponding KEY RR formats. -Specifically, the public key field contains the algorithm-specific -portion of the KEY RR RDATA, which is all of the KEY RR DATA after the -first four octets. This is the same portion of the KEY RR that must be -specified by documents that define a DNSSEC algorithm. -Those documents also specify a message digest to be used for generation -of SIG RRs; that specification is not relevant for IPSECKEY RR. -</t> - -<t> -Future algorithms, if they are to be used by both DNSSEC (in the KEY -RR) and IPSECKEY, are likely to use the same public key encodings in -both records. Unless otherwise specified, the IPSECKEY public key -field will contain the algorithm-specific portion of the KEY RR RDATA -for the corresponding algorithm. The algorithm must still be -designated for use by IPSECKEY, and an IPSECKEY algorithm type number -(which might be different than the DNSSEC algorithm number) must be -assigned to it. -</t> - -<t>The DSA key format is defined in RFC2536 <xref target="RFC2536" /></t>. - -<t>The RSA key format is defined in RFC3110 <xref target="RFC3110" />, -with the following changes:</t> - -<t> -The earlier definition of RSA/MD5 in RFC2065 limited the exponent and -modulus to 2552 bits in length. RFC3110 extended that limit to 4096 -bits for RSA/SHA1 keys. The IPSECKEY RR imposes no length limit on -RSA public keys, other than the 65535 octet limit imposed by the -two-octet length encoding. This length extension is applicable only -to IPSECKEY and not to KEY RRs. -</t> - -</section> - -</section> - - - -<section title="Presentation formats"> - -<section title="Representation of IPSECKEY RRs"> -<t> - IPSECKEY RRs may appear in a zone data master file. - The precedence, gateway type and algorithm and gateway fields are REQUIRED. - The base64 encoded public key block is OPTIONAL; if not present, - then the public key field of the resource record MUST be construed - as being zero octets in length. -</t> -<t> - The algorithm field is an unsigned integer. No mnemonics are defined. -</t> -<t> - If no gateway is to be indicated, then the gateway type field MUST - be zero, and the gateway field MUST be "." -</t> - -<t> - The Public Key field is represented as a Base64 encoding of the - Public Key. Whitespace is allowed within the Base64 text. For a - definition of Base64 encoding, see -<xref target="RFC1521">RFC1521</xref> Section 5.2. -</t> - - -<t> - The general presentation for the record as as follows: -<artwork><![CDATA[ -IN IPSECKEY ( precedence gateway-type algorithm - gateway base64-encoded-public-key ) -]]></artwork> -</t> -</section> - - -<section title="Examples"> -<t> -An example of a node 192.0.2.38 that will accept IPsec tunnels on its -own behalf. -<artwork><![CDATA[ -38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 - 192.0.2.38 - AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) -]]></artwork> -</t> - -<t> -An example of a node, 192.0.2.38 that has published its key only. -<artwork><![CDATA[ -38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 0 2 - . - AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) -]]></artwork> -</t> - -<t> -An example of a node, 192.0.2.38 that has delegated authority to the node -192.0.2.3. -<artwork><![CDATA[ -38.2.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 1 2 - 192.0.2.3 - AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) -]]></artwork> -</t> - -<t> -An example of a node, 192.0.1.38 that has delegated authority to the node -with the identity "mygateway.example.com". -<artwork><![CDATA[ -38.1.0.192.in-addr.arpa. 7200 IN IPSECKEY ( 10 3 2 - mygateway.example.com. - AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) -]]></artwork> -</t> - -<t> -An example of a node, 2001:0DB8:0200:1:210:f3ff:fe03:4d0 that has -delegated authority to the node 2001:0DB8:c000:0200:2::1 -<artwork><![CDATA[ -$ORIGIN 1.0.0.0.0.0.2.8.B.D.0.1.0.0.2.ip6.int. -0.d.4.0.3.0.e.f.f.f.3.f.0.1.2.0 7200 IN IPSECKEY ( 10 2 2 - 2001:0DB8:0:8002::2000:1 - AQNRU3mG7TVTO2BkR47usntb102uFJtugbo6BSGvgqt4AQ== ) -]]></artwork> -</t> - -</section> -</section> - -<section title="Security Considerations"> -<t> - This entire memo pertains to the provision of public keying material - for use by key management protocols such as ISAKMP/IKE (RFC2407) - <xref target="RFC2407" />. -</t> - -<t> -The IPSECKEY resource record contains information that SHOULD be -communicated to the end client in an integral fashion - i.e. free from -modification. The form of this channel is up to the consumer of the -data - there must be a trust relationship between the end consumer of this -resource record and the server. This relationship may be end-to-end -DNSSEC validation, a TSIG or SIG(0) channel to another secure source, -a secure local channel on the host, or some combination of the above. -</t> - -<t> -The keying material provided by the IPSECKEY resource record is not -sensitive to passive attacks. The keying material may be freely -disclosed to any party without any impact on the security properties -of the resulting IPsec session: IPsec and IKE provide for defense -against both active and passive attacks. -</t> - -<t> - Any user of this resource record MUST carefully document their trust - model, and why the trust model of DNSSEC is appropriate, if that is - the secure channel used. -</t> - -<section title="Active attacks against unsecured IPSECKEY resource records"> -<t> -This section deals with active attacks against the DNS. These attacks -require that DNS requests and responses be intercepted and changed. -DNSSEC is designed to defend against attacks of this kind. -</t> - -<t> -The first kind of active attack is when the attacker replaces the -keying material with either a key under its control or with garbage. -</t> - -<t> -If the attacker is not able to mount a subsequent -man-in-the-middle attack on the IKE negotiation after replacing the -public key, then this will result in a denial of service, as the -authenticator used by IKE would fail. -</t> - -<t> -If the attacker is able to both to mount active attacks against DNS -and is also in a position to perform a man-in-the-middle attack on IKE and -IPsec negotiations, then the attacker will be in a position to compromise -the resulting IPsec channel. Note that an attacker must be able to -perform active DNS attacks on both sides of the IKE negotiation in -order for this to succeed. -</t> - -<t> -The second kind of active attack is one in which the attacker replaces -the the gateway address to point to a node under the attacker's -control. The attacker can then either replace the public key or remove -it, thus providing an IPSECKEY record of its own to match the -gateway address. -</t> - -<t> -This later form creates a simple man-in-the-middle since the attacker -can then create a second tunnel to the real destination. Note that, as before, -this requires that the attacker also mount an active attack against -the responder. -</t> - -<t> -Note that the man-in-the-middle can not just forward cleartext -packets to the original destination. While the destination may be -willing to speak in the clear, replying to the original sender, -the sender will have already created a policy expecting ciphertext. -Thus, the attacker will need to intercept traffic from both sides. In some -cases, the attacker may be able to accomplish the full intercept by use -of Network Addresss/Port Translation (NAT/NAPT) technology. -</t> - -<t> -Note that the danger here only applies to cases where the gateway -field of the IPSECKEY RR indicates a different entity than the owner -name of the IPSECKEY RR. In cases where the end-to-end integrity of -the IPSECKEY RR is suspect, the end client MUST restrict its use -of the IPSECKEY RR to cases where the RR owner name matches the -content of the gateway field. -</t> -</section> - -</section> - -<section title="IANA Considerations"> -<t> -This document updates the IANA Registry for DNS Resource Record Types -by assigning type X to the IPSECKEY record. -</t> - -<t> -This document creates an IANA registry for the algorithm type field. -</t> -<t> -Values 0, 1 and 2 are defined in <xref target="algotype" />. Algorithm numbers -3 through 255 can be assigned by IETF Consensus (<xref target="RFC2434">see RFC2434</xref>). -</t> - -<t> -This document creates an IANA registry for the gateway type field. -</t> -<t> -Values 0, 1, 2 and 3 are defined in <xref target="gatewaytype" />. -Algorithm numbers 4 through 255 can be assigned by -Standards Action (<xref target="RFC2434">see RFC2434</xref>). -</t> - - - -</section> - -<section title="Acknowledgments"> -<t> -My thanks to Paul Hoffman, Sam Weiler, Jean-Jacques Puig, Rob Austein, -and Olafur Gurmundsson who reviewed this document carefully. -Additional thanks to Olafur Gurmundsson for a reference implementation. -</t> -</section> - -</middle> - -<back> -<references title="Normative references"> -<!-- DNSSEC --> -<?rfc include="reference.RFC.1034" ?> -<?rfc include="reference.RFC.1035" ?> -<?rfc include="reference.RFC.1521" ?> -<?rfc include="reference.RFC.2026" ?> -<?rfc include="reference.RFC.2065" ?> -<?rfc include="reference.RFC.2434" ?> -</references> - -<references title="Non-normative references"> -<?rfc include="reference.RFC.1886" ?> -<?rfc include="reference.RFC.2119" ?> -<?rfc include="reference.RFC.2407" ?> -<?rfc include="reference.RFC.2535" ?> -<?rfc include="reference.RFC.2536" ?> -<?rfc include="reference.RFC.3110" ?> -<?rfc include="reference.RFC.3445" ?> -</references> -</back> -</rfc> -<!-- - $Id: draft-richardson-ipsec-rr.xml,v 1.1 2004/03/15 20:35:24 as Exp $ - - $Log: draft-richardson-ipsec-rr.xml,v $ - Revision 1.1 2004/03/15 20:35:24 as - added files from freeswan-2.04-x509-1.5.3 - - Revision 1.23 2003/09/04 23:26:09 mcr - more nits. - - Revision 1.22 2003/08/16 15:55:35 mcr - fixed version to -06. - - Revision 1.21 2003/08/16 15:52:32 mcr - Sam's comments on IANA considerations. - - Revision 1.20 2003/07/27 22:57:54 mcr - updated document with new text about a seperate registry - for the algorithm type. - - Revision 1.19 2003/06/30 01:51:50 mcr - minor typo fixes. - - Revision 1.18 2003/06/16 17:45:00 mcr - adjusted date on rev-04. - - Revision 1.17 2003/06/16 17:41:30 mcr - revision -04 - - Revision 1.16 2003/06/16 17:39:20 mcr - adjusted typos, and adjusted IANA considerations. - - Revision 1.15 2003/05/26 19:31:23 mcr - updates to drafts - IPSEC RR - SC versions, and RFC3526 - reference in OE draft. - - Revision 1.14 2003/05/23 13:57:40 mcr - updated draft ##. - - Revision 1.13 2003/05/23 13:54:45 mcr - updated month on draft. - - Revision 1.12 2003/05/21 15:42:49 mcr - new SC section with comments from Rob Austein. - - Revision 1.11 2003/05/20 20:52:22 mcr - new security considerations section. - - Revision 1.10 2003/05/20 19:07:47 mcr - rewrote Security Considerations. - - Revision 1.9 2003/05/20 18:17:09 mcr - nits from Rob Austein. - - Revision 1.8 2003/04/29 00:44:59 mcr - updates according to WG consensus: restored three-way - gateway field type. - - Revision 1.7 2003/03/30 17:00:29 mcr - updates according to community feedback. - - Revision 1.6 2003/03/19 02:20:24 mcr - updated draft based upon comments from working group - - Revision 1.5 2003/02/23 22:39:22 mcr - updates to IPSECKEY draft. - - Revision 1.4 2003/02/21 04:39:04 mcr - updated drafts, and added crosscompile.html - - Revision 1.3 2003/01/17 16:26:34 mcr - updated IPSEC KEY draft with restrictions. - - Revision 1.2 2002/08/26 18:20:54 mcr - updated documents - - Revision 1.1 2002/08/10 20:05:33 mcr - document proposing IPSECKEY Resource Record - - -!> |