| TOC |
|
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 August 22, 2002.
Copyright (C) The Internet Society (2002). All Rights Reserved.
| TOC |
This document describes opportunistic encryption using IKE and IPsec. The objective is to allow encryption without any pre-arrangement specific to the pair of gateways involved. Each gateway administrator makes local arrangements to support opportunistic encryption. Once that is done, any two such gateways can communicate securely.
There are two large payoffs. First, if many machines must communicate securely, this approach reduces administrative overhead to order N (number of gateways), rather than the N squared cost to configure each tunnel separately. Second, it becomes possible to make secure communication the default, even when the partner is not known in advance.
There are naturally some risks and some costs, which are described.
This document is offered up as an Informational RFC.
| TOC |
The objective of opportunistic encryption is to allow encryption without any pre-arrangement specific to the pair of gateways involved. Each gateway administrator makes local arrangements -- specifically, adds public key information to DNS records -- to support opportunistic encryption and then enables this feature in the nodes' IPsec stack. Once that is done, any two such nodes can communicate securely.
This document describes opportunistic encryption as designed and (to date, partially) implemented by the Linux FreeS/WAN project. For project information, see www.freeswan.org.
The Internet Architecture Board (IAB) and Internet Engineering Steering Group have taken a strong stand that the Internet should use powerful encryption to provide security and privacy [4]. This project attempts to put this policy into practice by providing practical means to implement them.
The project believes that the IPsec protocols are the best chance to do that, because they are standardized, widely available and can often be deployed very easily, without changing hardware or software or retraining of users. However, the extension to opportunistic encryption seems necessary, both to help control administrative overheads and to get IPsec more widely used.
The use of "opportunistic encryption" offers the "fax effect". As each person installs one for their own use, it becomes more valuable for their neighbors to install one too, because there's one more person to use it with. The software automatically notices each newly installed box, and doesn't require a network administrator to reconfigure it.
This document describes the infrastructure needed to support this effort.
The term S/WAN is a trademark of RSA Data Systems, and is used with permission by this project.
To aid in understand the relationship between security processing and IPsec we divide network traffic into four categories:
- deny
- networks to which traffic is always forbidden
- permit
- networks to which traffic in the clear is desired
- opportunistic tunnel
- networks to which encryption should be done if possible, but communication is done in the clear otherwise
- configured tunnel
- networks to which encryption must be done, and communication is never in the clear
This document describes the third category. The first two categories are provided by traditional firewall devices. The fourth category is presently the offering of many Virtual Private Network (VPN) devices.
Category one, denied traffic by IP address, requires no authentication.
Category two, permitted traffic by IP address, requires no authentication. This is the normal default on 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 the a single authority, arranging for distribution of authentication material, while difficult, does not require any new technology.
The mechanism described here provides an additional way to distribute the authentication materials, notably a public key method that does not require deployment of an X.509 based infrastructure.
Opportunistic encryption involves creating tunnels with other nodes that are essentially strangers. This is done without any prior bilateral arrangement. There is therefore the difficult question of how does one know who one is talking to.
One possible answer is that one does not know who one is talking to. No useful authentication can be done, so do not even try. This mode of operation has been given the name "anonymous encryption". A man-in-the-middle attack can be used to thwart the privacy of this communication. This would be an active attack. Without peer authentication, there is no way to prevents this kind of attack.
Although a useful mode, it is not the goal of this project. It is a useful starting point, but the system should permit additional layers of trust to be built upon this system. In the described system, the anonymous encryption case is what results without DNSSEC. Were anonymous encryption the end goal, simpler methods are available to achieve this goal.
However, an essential premise of building private connections with strangers is that datagrams received through these opportunistic tunnels are no more special than datagrams that arrived in the clear.
Unlike in a VPN scenario, these datagrams should not be given any special exceptions when it comes to auditing, further authentication or firewalling.
On the outbound side, when initiating opportunistic encryption, it becomes a local matter what to do if one fails to setup a tunnel. It may be that the packet goes out in the clear, or it may be dropped. This is a local configuration matter.
In sum, we gain wider privacy (for the Internet at large) at minimal cost: the cost is the need to reassess assumptions about the relationship between IPsec authentication and further local access control.
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]
| TOC |
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
| 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. SG-A and SG-D are on two different exit paths from organization 1. SG-B/B is an independent organizations. Nodes Q and R are nodes that are on the Internet. PI is the Public Internet ("The Wild").
The following terminology is used in this document:
- security gateway:
- a system that performs IPsec tunnel mode encapsulation/decapsulation. [SGx] 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
- 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 hash sign represents phase 1 (IKE) cipher-text datagrams
- .
- a period represents an untrusted network of unknown type
- configured tunnel:
- Contrast with opportunistic tunnel. A tunnel that is directly/deliberately/hand configured on participating gateways. Configured tunnel are typically given a higher level of trust than opportunistic tunnels.
- road warrior tunnel:
- a configured tunnel connecting one node with a fixed IP address and one node with a variable IP address. A road warrior (RW) connection must be initiated by the variable node, since the fixed t>
3.1.2 Hold policy
3.1.3 Pass-through policy
3.1.4 Deny policy
3.1.5 Encrypt policy
3.2 Keying State Machine - Initiator
3.2.1 Nonexistent connection
3.2.2 clear-text connection
3.2.3 Deny connection
3.2.4 Potential OE connection
3.2.4.1 Restriction on unauthentication TXT delegation records
3.2.5 Pending OE connection
3.2.6 Keyed connection
3.2.7 Expiring connection
3.2.8 Expired connection state
3.3 Keying State Machine - Responder
3.3.1 Unauthenticated OE peer state
3.3.2 Authenticated OE Peer
3.4 Renewal and Teardown
3.4.1 Aging
3.4.2 Teardown and Cleanup
4. Impacts on IKE
4.1 ISAKMP/IKE protocol
4.2 Gateway discovery process
4.3 Self identification
4.4 Public key Retrieval process
4.5 Interactions with DNSSEC
4.6 Recommended proposal types
4.6.1 Phase 1 parameters
4.6.2 Phase 2 parameters
5. DNS issues
5.1 Use of KEY record
5.2 Use of TXT delegation record
5.2.1 Choice of TXT record
5.3 Use of FQDN IDs
6. Network Address Translation interaction
6.1 Colocated NAT/NAPT
6.2 SG-A behind NAT/NAPT
6.3 Bob is behind a NAT/NAPT
7. Host implementations
8. Multihoming
9. Failure modes
9.1 DNS failures
9.2 DNS configured, IKE failures
9.3 System reboots
10. Unresolved issues
10.1 Control of reverse DNS
11. Examples
11.1 Clear-text usage (permit policy)
11.2 Opportunistic Encryption
11.2.1 (5) IPsec packet interception
11.2.2 (5B) DNS lookup for TXT record
11.2.3 (5C) DNS returns TXT record(s)
11.2.4 (5D) Initial IKE Main Mode Packet goes out
11.2.5 (5E1) Message 2 of phase 1 exchange
11.2.6 (5E2) Message 3 of phase 1 exchange
11.2.7 (5E3) Message 4 of phase 1 exchange
11.2.8 (5E4) Message 5 of phase 1 exchange
11.2.9 (5F1) Responder lookup of initiator key
11.2.10 (5F2) DNS replies with public key of initiator
11.2.11 (5E5) Responder replies with ID and authentication
11.2.12 (5G) IKE phase 2
11.2.12.1 (5G1) Initiator proposes tunnel
11.2.12.2 (5H1) Responder determines initiator's authority
11.2.12.3 (5H2) DNS replies with TXT record
11.2.12.4 (5G2) Responder agrees to proposal
11.2.12.5 (5G3) Final acknowledgement from initiator
11.2.13 (6) IPsec succeeds, sets up tunnel for communication between Alice and Bob
11.2.14 (9) SG-B already has tunnel up with G1, uses it
12. Security Considerations
12.1 Configured vs Opportunistic Tunnels
12.2 Firewalls vs Opportunistic Tunnels
12.3 Denial of Service
13. IANA Considerations
14. Acknowledgements
§ References
§ Authors' Addresses
§ Full Copyright Statement
Abstract
This document describes opportunistic encryption using IKE and IPsec. The objective is to allow encryption without any pre-arrangement specific to the pair of gateways involved. Each gateway administrator makes local arrangements to support opportunistic encryption. Once that is done, any two such gateways can communicate securely.
There are two large payoffs. First, if many machines must communicate securely, this approach reduces administrative overhead to order N (number of gateways), rather than the N squared cost to configure each tunnel separately. Second, it becomes possible to make secure communication the default, even when the partner is not known in advance.
There are naturally some risks and some costs, which are described.
This document is offered up as an Informational RFC.
TOC 1. Introduction
1.1 Motivation
The objective of opportunistic encryption is to allow encryption without any pre-arrangement specific to the pair of gateways involved. Each gateway administrator makes local arrangements -- specifically, adds public key information to DNS records -- to support opportunistic encryption and then enables this feature in the nodes' IPsec stack. Once that is done, any two such nodes can communicate securely.
This document describes opportunistic encryption as designed and (to date, partially) implemented by the Linux FreeS/WAN project. For project information, see www.freeswan.org.
The Internet Architecture Board (IAB) and Internet Engineering Steering Group have taken a strong stand that the Internet should use powerful encryption to provide security and privacy [4]. This project attempts to put this policy into practice by providing practical means to implement them.
The project believes that the IPsec protocols are the best chance to do that, because they are standardized, widely available and can often be deployed very easily, without changing hardware or software or retraining of users. However, the extension to opportunistic encryption seems necessary, both to help control administrative overheads and to get IPsec more widely used.
The use of "opportunistic encryption" offers the "fax effect". As each person installs one for their own use, it becomes more valuable for their neighbors to install one too, because there's one more person to use it with. The software automatically notices each newly installed box, and doesn't require a network administrator to reconfigure it.
This document describes the infrastructure needed to support this effort.
The term S/WAN is a trademark of RSA Data Systems, and is used with permission by this project.
1.2 Types of network traffic
To aid in understand the relationship between security processing and IPsec we divide network traffic into four categories:
- deny
- networks to which traffic is always forbidden
- permit
- networks to which traffic in the clear is desired
- opportunistic tunnel
- networks to which encryption should be done if possible, but communication is done in the clear otherwise
- configured tunnel
- networks to which encryption must be done, and communication is never in the clear
This document describes the third category. The first two categories are provided by traditional firewall devices. The fourth category is presently the offering of many Virtual Private Network (VPN) devices.
Category one, denied traffic by IP address, requires no authentication.
Category two, permitted traffic by IP address, requires no authentication. This is the normal default on 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 the a single authority, arranging for distribution of authentication material, while difficult, does not require any new technology.
The mechanism described here provides an additional way to distribute the authentication materials, notably a public key method that does not require deployment of an X.509 based infrastructure.
1.3 Peer authentication in Opportunistic Encryption
Opportunistic encryption involves creating tunnels with other nodes that are essentially strangers. This is done without any prior bilateral arrangement. There is therefore the difficult question of how does one know who one is talking to.
One possible answer is that one does not know who one is talking to. No useful authentication can be done, so do not even try. This mode of operation has been given the name "anonymous encryption". A man-in-the-middle attack can be used to thwart the privacy of this communication. This would be an active attack. Without peer authentication, there is no way to prevents this kind of attack.
Although a useful mode, it is not the goal of this project. It is a useful starting point, but the system should permit additional layers of trust to be built upon this system. In the described system, the anonymous encryption case is what results without DNSSEC. Were anonymous encryption the end goal, simpler methods are available to achieve this goal.
However, an essential premise of building private connections with strangers is that datagrams received through these opportunistic tunnels are no more special than datagrams that arrived in the clear.
Unlike in a VPN scenario, these datagrams should not be given any special exceptions when it comes to auditing, further authentication or firewalling.
On the outbound side, when initiating opportunistic encryption, it becomes a local matter what to do if one fails to setup a tunnel. It may be that the packet goes out in the clear, or it may be dropped. This is a local configuration matter.
In sum, we gain wider privacy (for the Internet at large) at minimal cost: the cost is the need to reassess assumptions about the relationship between IPsec authentication and further local access control.
1.4 Use of RFC2119 terms
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [5]
TOC 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
| 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. SG-A and SG-D are on two different exit paths from organization 1. SG-B/B is an independent organizations. Nodes Q and R are nodes that are on the Internet. PI is the Public Internet ("The Wild").
The following terminology is used in this document:
- security gateway:
- a system that performs IPsec tunnel mode encapsulation/decapsulation. [SGx] 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
- 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 hash sign represents phase 1 (IKE) cipher-text datagrams
- .
- a period represents an untrusted network of unknown type
- configured tunnel:
- Contrast with opportunistic tunnel. A tunnel that is directly/deliberately/hand configured on participating gateways. Configured tunnel are typically given a higher level of trust than opportunistic tunnels.
- road warrior tunnel:
- a configured tunnel connecting one node with a fixed IP address and one node with a variable IP address. A road warrior (RW) connection must be initiated by the variable node, since the fixed t>
3.1.2 Hold policy
3.1.3 Pass-through policy
3.1.4 Deny policy
3.1.5 Encrypt policy
3.2 Keying State Machine - Initiator
3.2.1 Nonexistent connection
3.2.2 clear-text connection
3.2.3 Deny connection
3.2.4 Potential OE connection
3.2.4.1 Restriction on unauthentication TXT delegation records
3.2.5 Pending OE connection
3.2.6 Keyed connection
3.2.7 Expiring connection
3.2.8 Expired connection state
3.3 Keying State Machine - Responder
3.3.1 Unauthenticated OE peer state
3.3.2 Authenticated OE Peer
3.4 Renewal and Teardown
3.4.1 Aging
3.4.2 Teardown and Cleanup
4. Impacts on IKE
4.1 ISAKMP/IKE protocol
4.2 Gateway discovery process
4.3 Self identification
4.4 Public key Retrieval process
4.5 Interactions with DNSSEC
4.6 Recommended proposal types
4.6.1 Phase 1 parameters
4.6.2 Phase 2 parameters
5. DNS issues
5.1 Use of KEY record
5.2 Use of TXT delegation record
5.2.1 Choice of TXT record
5.3 Use of FQDN IDs
6. Network Address Translation interaction
6.1 Colocated NAT/NAPT
6.2 SG-A behind NAT/NAPT
6.3 Bob is behind a NAT/NAPT
7. Host implementations
8. Multihoming
9. Failure modes
9.1 DNS failures
9.2 DNS configured, IKE failures
9.3 System reboots
10. Unresolved issues
10.1 Control of reverse DNS
11. Examples
11.1 Clear-text usage (permit policy)
11.2 Opportunistic Encryption
11.2.1 (5) IPsec packet interception
11.2.2 (5B) DNS lookup for TXT record
11.2.3 (5C) DNS returns TXT record(s)
11.2.4 (5D) Initial IKE Main Mode Packet goes out
11.2.5 (5E1) Message 2 of phase 1 exchange
11.2.6 (5E2) Message 3 of phase 1 exchange
11.2.7 (5E3) Message 4 of phase 1 exchange
11.2.8 (5E4) Message 5 of phase 1 exchange
11.2.9 (5F1) Responder lookup of initiator key
11.2.10 (5F2) DNS replies with public key of initiator
11.2.11 (5E5) Responder replies with ID and authentication
11.2.12 (5G) IKE phase 2
11.2.12.1 (5G1) Initiator proposes tunnel
11.2.12.2 (5H1) Responder determines initiator's authority
11.2.12.3 (5H2) DNS replies with TXT record
11.2.12.4 (5G2) Responder agrees to proposal
11.2.12.5 (5G3) Final acknowledgement from initiator
11.2.13 (6) IPsec succeeds, sets up tunnel for communication between Alice and Bob
11.2.14 (9) SG-B already has tunnel up with G1, uses it
12. Security Considerations
12.1 Configured vs Opportunistic Tunnels
12.2 Firewalls vs Opportunistic Tunnels
12.3 Denial of Service
13. IANA Considerations
14. Acknowledgements
§ References
§ Authors' Addresses
§ Full Copyright Statement
Abstract
This document describes opportunistic encryption using IKE and IPsec. The objective is to allow encryption without any pre-arrangement specific to the pair of gateways involved. Each gateway administrator makes local arrangements to support opportunistic encryption. Once that is done, any two such gateways can communicate securely.
There are two large payoffs. First, if many machines must communicate securely, this approach reduces administrative overhead to order N (number of gateways), rather than the N squared cost to configure each tunnel separately. Second, it becomes possible to make secure communication the default, even when the partner is not known in advance.
There are naturally some risks and some costs, which are described.
This document is offered up as an Informational RFC.
TOC 1. Introduction
1.1 Motivation
The objective of opportunistic encryption is to allow encryption without any pre-arrangement specific to the pair of gateways involved. Each gateway administrator makes local arrangements -- specifically, adds public key information to DNS records -- to support opportunistic encryption and then enables this feature in the nodes' IPsec stack. Once that is done, any two such nodes can communicate securely.
This document describes opportunistic encryption as designed and (to date, partially) implemented by the Linux FreeS/WAN project. For project information, see www.freeswan.org.
The Internet Architecture Board (IAB) and Internet Engineering Steering Group have taken a strong stand that the Internet should use powerful encryption to provide security and privacy [4]. This project attempts to put this policy into practice by providing practical means to implement them.
The project believes that the IPsec protocols are the best chance to do that, because they are standardized, widely available and can often be deployed very easily, without changing hardware or software or retraining of users. However, the extension to opportunistic encryption seems necessary, both to help control administrative overheads and to get IPsec more widely used.
The use of "opportunistic encryption" offers the "fax effect". As each person installs one for their own use, it becomes more valuable for their neighbors to install one too, because there's one more person to use it with. The software automatically notices each newly installed box, and doesn't require a network administrator to reconfigure it.
This document describes the infrastructure needed to support this effort.
The term S/WAN is a trademark of RSA Data Systems, and is used with permission by this project.
1.2 Types of network traffic
To aid in understand the relationship between security processing and IPsec we divide network traffic into four categories:
- deny
- networks to which traffic is always forbidden
- permit
- networks to which traffic in the clear is desired
- opportunistic tunnel
- networks to which encryption should be done if possible, but communication is done in the clear otherwise
- configured tunnel
- networks to which encryption must be done, and communication is never in the clear
This document describes the third category. The first two categories are provided by traditional firewall devices. The fourth category is presently the offering of many Virtual Private Network (VPN) devices.
Category one, denied traffic by IP address, requires no authentication.
Category two, permitted traffic by IP address, requires no authentication. This is the normal default on 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 the a single authority, arranging for distribution of authentication material, while difficult, does not require any new technology.
The mechanism described here provides an additional way to distribute the authentication materials, notably a public key method that does not require deployment of an X.509 based infrastructure.
1.3 Peer authentication in Opportunistic Encryption
Opportunistic encryption involves creating tunnels with other nodes that are essentially strangers. This is done without any prior bilateral arrangement. There is therefore the difficult question of how does one know who one is talking to.
One possible answer is that one does not know who one is talking to. No useful authentication can be done, so do not even try. This mode of operation has been given the name "anonymous encryption". A man-in-the-middle attack can be used to thwart the privacy of this communication. This would be an active attack. Without peer authentication, there is no way to prevents this kind of attack.
Although a useful mode, it is not the goal of this project. It is a useful starting point, but the system should permit additional layers of trust to be built upon this system. In the described system, the anonymous encryption case is what results without DNSSEC. Were anonymous encryption the end goal, simpler methods are available to achieve this goal.
However, an essential premise of building private connections with strangers is that datagrams received through these opportunistic tunnels are no more special than datagrams that arrived in the clear.
Unlike in a VPN scenario, these datagrams should not be given any special exceptions when it comes to auditing, further authentication or firewalling.
On the outbound side, when initiating opportunistic encryption, it becomes a local matter what to do if one fails to setup a tunnel. It may be that the packet goes out in the clear, or it may be dropped. This is a local configuration matter.
In sum, we gain wider privacy (for the Internet at large) at minimal cost: the cost is the need to reassess assumptions about the relationship between IPsec authentication and further local access control.
1.4 Use of RFC2119 terms
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [5]
TOC 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
| 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. SG-A and SG-D are on two different exit paths from organization 1. SG-B/B is an independent organizations. Nodes Q and R are nodes that are on the Internet. PI is the Public Internet ("The Wild").
The following terminology is used in this document:
- security gateway:
- a system that performs IPsec tunnel mode encapsulation/decapsulation. [SGx] 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
- 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 hash sign represents phase 1 (IKE) cipher-text datagrams
- .
- a period represents an untrusted network of unknown type
- configured tunnel:
- Contrast with opportunistic tunnel. A tunnel that is directly/deliberately/hand configured on participating gateways. Configured tunnel are typically given a higher level of trust than opportunistic tunnels.
- road warrior tunnel:
- a configured tunnel connecting one node with a fixed IP address and one node with a variable IP address. A road warrior (RW) connection must be initiated by the variable node, since the fixed t>
3.1.2 Hold policy
3.1.3 Pass-through policy
3.1.4 Deny policy
3.1.5 Encrypt policy
3.2 Keying State Machine - Initiator
3.2.1 Nonexistent connection
3.2.2 clear-text connection
3.2.3 Deny connection
3.2.4 Potential OE connection
3.2.4.1 Restriction on unauthentication TXT delegation records
3.2.5 Pending OE connection
3.2.6 Keyed connection
3.2.7 Expiring connection
3.2.8 Expired connection state
3.3 Keying State Machine - Responder
3.3.1 Unauthenticated OE peer state
3.3.2 Authenticated OE Peer
3.4 Renewal and Teardown
3.4.1 Aging
3.4.2 Teardown and Cleanup
4. Impacts on IKE
4.1 ISAKMP/IKE protocol
4.2 Gateway discovery process
4.3 Self identification
4.4 Public key Retrieval process
4.5 Interactions with DNSSEC
4.6 Recommended proposal types
4.6.1 Phase 1 parameters
4.6.2 Phase 2 parameters
5. DNS issues
5.1 Use of KEY record
5.2 Use of TXT delegation record
5.2.1 Choice of TXT record
5.3 Use of FQDN IDs
6. Network Address Translation interaction
6.1 Colocated NAT/NAPT
6.2 SG-A behind NAT/NAPT
6.3 Bob is behind a NAT/NAPT
7. Host implementations
8. Multihoming
9. Failure modes
9.1 DNS failures
9.2 DNS configured, IKE failures
9.3 System reboots
10. Unresolved issues
10.1 Control of reverse DNS
11. Examples
11.1 Clear-text usage (permit policy)
11.2 Opportunistic Encryption
11.2.1 (5) IPsec packet interception
11.2.2 (5B) DNS lookup for TXT record
11.2.3 (5C) DNS returns TXT record(s)
11.2.4 (5D) Initial IKE Main Mode Packet goes out
11.2.5 (5E1) Message 2 of phase 1 exchange
11.2.6 (5E2) Message 3 of phase 1 exchange
11.2.7 (5E3) Message 4 of phase 1 exchange
11.2.8 (5E4) Message 5 of phase 1 exchange
11.2.9 (5F1) Responder lookup of initiator key
11.2.10 (5F2) DNS replies with public key of initiator
11.2.11 (5E5) Responder replies with ID and authentication
11.2.12 (5G) IKE phase 2
11.2.12.1 (5G1) Initiator proposes tunnel
11.2.12.2 (5H1) Responder determines initiator's authority
11.2.12.3 (5H2) DNS replies with TXT record
11.2.12.4 (5G2) Responder agrees to proposal
11.2.12.5 (5G3) Final acknowledgement from initiator
11.2.13 (6) IPsec succeeds, sets up tunnel for communication between Alice and Bob
11.2.14 (9) SG-B already has tunnel up with G1, uses it
12. Security Considerations
12.1 Configured vs Opportunistic Tunnels
12.2 Firewalls vs Opportunistic Tunnels
12.3 Denial of Service
13. IANA Considerations
14. Acknowledgements
§ References
§ Authors' Addresses
§ Full Copyright Statement
Abstract
This document describes opportunistic encryption using IKE and IPsec. The objective is to allow encryption without any pre-arrangement specific to the pair of gateways involved. Each gateway administrator makes local arrangements to support opportunistic encryption. Once that is done, any two such gateways can communicate securely.
There are two large payoffs. First, if many machines must communicate securely, this approach reduces administrative overhead to order N (number of gateways), rather than the N squared cost to configure each tunnel separately. Second, it becomes possible to make secure communication the default, even when the partner is not known in advance.
There are naturally some risks and some costs, which are described.
This document is offered up as an Informational RFC.
TOC 1. Introduction
1.1 Motivation
The objective of opportunistic encryption is to allow encryption without any pre-arrangement specific to the pair of gateways involved. Each gateway administrator makes local arrangements -- specifically, adds public key information to DNS records -- to support opportunistic encryption and then enables this feature in the nodes' IPsec stack. Once that is done, any two such nodes can communicate securely.
This document describes opportunistic encryption as designed and (to date, partially) implemented by the Linux FreeS/WAN project. For project information, see www.freeswan.org.
The Internet Architecture Board (IAB) and Internet Engineering Steering Group have taken a strong stand that the Internet should use powerful encryption to provide security and privacy [4]. This project attempts to put this policy into practice by providing practical means to implement them.
The project believes that the IPsec protocols are the best chance to do that, because they are standardized, widely available and can often be deployed very easily, without changing hardware or software or retraining of users. However, the extension to opportunistic encryption seems necessary, both to help control administrative overheads and to get IPsec more widely used.
The use of "opportunistic encryption" offers the "fax effect". As each person installs one for their own use, it becomes more valuable for their neighbors to install one too, because there's one more person to use it with. The software automatically notices each newly installed box, and doesn't require a network administrator to reconfigure it.
This document describes the infrastructure needed to support this effort.
The term S/WAN is a trademark of RSA Data Systems, and is used with permission by this project.
1.2 Types of network traffic
To aid in understand the relationship between security processing and IPsec we divide network traffic into four categories:
- deny
- networks to which traffic is always forbidden
- permit
- networks to which traffic in the clear is desired
- opportunistic tunnel
- networks to which encryption should be done if possible, but communication is done in the clear otherwise
- configured tunnel
- networks to which encryption must be done, and communication is never in the clear
This document describes the third category. The first two categories are provided by traditional firewall devices. The fourth category is presently the offering of many Virtual Private Network (VPN) devices.
Category one, denied traffic by IP address, requires no authentication.
Category two, permitted traffic by IP address, requires no authentication. This is the normal default on 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 the a single authority, arranging for distribution of authentication material, while difficult, does not require any new technology.
The mechanism described here provides an additional way to distribute the authentication materials, notably a public key method that does not require deployment of an X.509 based infrastructure.
1.3 Peer authentication in Opportunistic Encryption
Opportunistic encryption involves creating tunnels with other nodes that are essentially strangers. This is done without any prior bilateral arrangement. There is therefore the difficult question of how does one know who one is talking to.
One possible answer is that one does not know who one is talking to. No useful authentication can be done, so do not even try. This mode of operation has been given the name "anonymous encryption". A man-in-the-middle attack can be used to thwart the privacy of this communication. This would be an active attack. Without peer authentication, there is no way to prevents this kind of attack.
Although a useful mode, it is not the goal of this project. It is a useful starting point, but the system should permit additional layers of trust to be built upon this system. In the described system, the anonymous encryption case is what results without DNSSEC. Were anonymous encryption the end goal, simpler methods are available to achieve this goal.
However, an essential premise of building private connections with strangers is that datagrams received through these opportunistic tunnels are no more special than datagrams that arrived in the clear.
Unlike in a VPN scenario, these datagrams should not be given any special exceptions when it comes to auditing, further authentication or firewalling.
On the outbound side, when initiating opportunistic encryption, it becomes a local matter what to do if one fails to setup a tunnel. It may be that the packet goes out in the clear, or it may be dropped. This is a local configuration matter.
In sum, we gain wider privacy (for the Internet at large) at minimal cost: the cost is the need to reassess assumptions about the relationship between IPsec authentication and further local access control.
1.4 Use of RFC2119 terms
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [5]
TOC 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
| 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. SG-A and SG-D are on two different exit paths from organization 1. SG-B/B is an independent organizations. Nodes Q and R are nodes that are on the Internet. PI is the Public Internet ("The Wild").
The following terminology is used in this document:
- security gateway:
- a system that performs IPsec tunnel mode encapsulation/decapsulation. [SGx] 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
- 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 hash sign represents phase 1 (IKE) cipher-text datagrams
- .
- a period represents an untrusted network of unknown type
- configured tunnel:
- Contrast with opportunistic tunnel. A tunnel that is directly/deliberately/hand configured on participating gateways. Configured tunnel are typically given a higher level of trust than opportunistic tunnels.
- road warrior tunnel:
- a configured tunnel connecting one node with a fixed IP address and one node with a variable IP address. A road warrior (RW) connection must be initiated by the variable node, since the fixed t>
3.1.2 Hold policy
3.1.3 Pass-through policy
3.1.4 Deny policy
3.1.5 Encrypt policy
3.2 Keying State Machine - Initiator
3.2.1 Nonexistent connection
3.2.2 clear-text connection
3.2.3 Deny connection
3.2.4 Potential OE connection
3.2.4.1 Restriction on unauthentication TXT delegation records
3.2.5 Pending OE connection
3.2.6 Keyed connection
3.2.7 Expiring connection
3.2.8 Expired connection state
3.3 Keying State Machine - Responder
3.3.1 Unauthenticated OE peer state
3.3.2 Authenticated OE Peer
3.4 Renewal and Teardown
3.4.1 Aging
3.4.2 Teardown and Cleanup
4. Impacts on IKE
4.1 ISAKMP/IKE protocol
4.2 Gateway discovery process
4.3 Self identification
4.4 Public key Retrieval process
4.5 Interactions with DNSSEC
4.6 Recommended proposal types
4.6.1 Phase 1 parameters
4.6.2 Phase 2 parameters
5. DNS issues
5.1 Use of KEY record
5.2 Use of TXT delegation record
5.2.1 Choice of TXT record
5.3 Use of FQDN IDs
6. Network Address Translation interaction
6.1 Colocated NAT/NAPT
6.2 SG-A behind NAT/NAPT
6.3 Bob is behind a NAT/NAPT
7. Host implementations
8. Multihoming
9. Failure modes
9.1 DNS failures
9.2 DNS configured, IKE failures
9.3 System reboots
10. Unresolved issues
10.1 Control of reverse DNS
11. Examples
11.1 Clear-text usage (permit policy)
11.2 Opportunistic Encryption
11.2.1 (5) IPsec packet interception
11.2.2 (5B) DNS lookup for TXT record
11.2.3 (5C) DNS returns TXT record(s)
11.2.4 (5D) Initial IKE Main Mode Packet goes out
11.2.5 (5E1) Message 2 of phase 1 exchange
11.2.6 (5E2) Message 3 of phase 1 exchange
11.2.7 (5E3) Message 4 of phase 1 exchange
11.2.8 (5E4) Message 5 of phase 1 exchange
11.2.9 (5F1) Responder lookup of initiator key
11.2.10 (5F2) DNS replies with public key of initiator
11.2.11 (5E5) Responder replies with ID and authentication
11.2.12 (5G) IKE phase 2
11.2.12.1 (5G1) Initiator proposes tunnel
11.2.12.2 (5H1) Responder determines initiator's authority
11.2.12.3 (5H2) DNS replies with TXT record
11.2.12.4 (5G2) Responder agrees to proposal
11.2.12.5 (5G3) Final acknowledgement from initiator
11.2.13 (6) IPsec succeeds, sets up tunnel for communication between Alice and Bob
11.2.14 (9) SG-B already has tunnel up with G1, uses it
12. Security Considerations
12.1 Configured vs Opportunistic Tunnels
12.2 Firewalls vs Opportunistic Tunnels
12.3 Denial of Service
13. IANA Considerations
14. Acknowledgements
§ References
§ Authors' Addresses
§ Full Copyright Statement
Abstract
This document describes opportunistic encryption using IKE and IPsec. The objective is to allow encryption without any pre-arrangement specific to the pair of gateways involved. Each gateway administrator makes local arrangements to support opportunistic encryption. Once that is done, any two such gateways can communicate securely.
There are two large payoffs. First, if many machines must communicate securely, this approach reduces administrative overhead to order N (number of gateways), rather than the N squared cost to configure each tunnel separately. Second, it becomes possible to make secure communication the default, even when the partner is not known in advance.
There are naturally some risks and some costs, which are described.
This document is offered up as an Informational RFC.
TOC 1. Introduction
1.1 Motivation
The objective of opportunistic encryption is to allow encryption without any pre-arrangement specific to the pair of gateways involved. Each gateway administrator makes local arrangements -- specifically, adds public key information to DNS records -- to support opportunistic encryption and then enables this feature in the nodes' IPsec stack. Once that is done, any two such nodes can communicate securely.
This document describes opportunistic encryption as designed and (to date, partially) implemented by the Linux FreeS/WAN project. For project information, see www.freeswan.org.
The Internet Architecture Board (IAB) and Internet Engineering Steering Group have taken a strong stand that the Internet should use powerful encryption to provide security and privacy [4]. This project attempts to put this policy into practice by providing practical means to implement them.
The project believes that the IPsec protocols are the best chance to do that, because they are standardized, widely available and can often be deployed very easily, without changing hardware or software or retraining of users. However, the extension to opportunistic encryption seems necessary, both to help control administrative overheads and to get IPsec more widely used.
The use of "opportunistic encryption" offers the "fax effect". As each person installs one for their own use, it becomes more valuable for their neighbors to install one too, because there's one more person to use it with. The software automatically notices each newly installed box, and doesn't require a network administrator to reconfigure it.
This document describes the infrastructure needed to support this effort.
The term S/WAN is a trademark of RSA Data Systems, and is used with permission by this project.
1.2 Types of network traffic
To aid in understand the relationship between security processing and IPsec we divide network traffic into four categories:
- deny
- networks to which traffic is always forbidden
- permit
- networks to which traffic in the clear is desired
- opportunistic tunnel
- networks to which encryption should be done if possible, but communication is done in the clear otherwise
- configured tunnel
- networks to which encryption must be done, and communication is never in the clear
This document describes the third category. The first two categories are provided by traditional firewall devices. The fourth category is presently the offering of many Virtual Private Network (VPN) devices.
Category one, denied traffic by IP address, requires no authentication.
Category two, permitted traffic by IP address, requires no authentication. This is the normal default on 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 the a single authority, arranging for distribution of authentication material, while difficult, does not require any new technology.
The mechanism described here provides an additional way to distribute the authentication materials, notably a public key method that does not require deployment of an X.509 based infrastructure.
1.3 Peer authentication in Opportunistic Encryption
Opportunistic encryption involves creating tunnels with other nodes that are essentially strangers. This is done without any prior bilateral arrangement. There is therefore the difficult question of how does one know who one is talking to.
One possible answer is that one does not know who one is talking to. No useful authentication can be done, so do not even try. This mode of operation has been given the name "anonymous encryption". A man-in-the-middle attack can be used to thwart the privacy of this communication. This would be an active attack. Without peer authentication, there is no way to prevents this kind of attack.
Although a useful mode, it is not the goal of this project. It is a useful starting point, but the system should permit additional layers of trust to be built upon this system. In the described system, the anonymous encryption case is what results without DNSSEC. Were anonymous encryption the end goal, simpler methods are available to achieve this goal.
However, an essential premise of building private connections with strangers is that datagrams received through these opportunistic tunnels are no more special than datagrams that arrived in the clear.
Unlike in a VPN scenario, these datagrams should not be given any special exceptions when it comes to auditing, further authentication or firewalling.
On the outbound side, when initiating opportunistic encryption, it becomes a local matter what to do if one fails to setup a tunnel. It may be that the packet goes out in the clear, or it may be dropped. This is a local configuration matter.
In sum, we gain wider privacy (for the Internet at large) at minimal cost: the cost is the need to reassess assumptions about the relationship between IPsec authentication and further local access control.
1.4 Use of RFC2119 terms
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [5]
TOC 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
| 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. SG-A and SG-D are on two different exit paths from organization 1. SG-B/B is an independent organizations. Nodes Q and R are nodes that are on the Internet. PI is the Public Internet ("The Wild").
The following terminology is used in this document:
- security gateway:
- a system that performs IPsec tunnel mode encapsulation/decapsulation. [SGx] 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
- 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 hash sign represents phase 1 (IKE) cipher-text datagrams
- .
- a period represents an untrusted network of unknown type
- configured tunnel:
- Contrast with opportunistic tunnel. A tunnel that is directly/deliberately/hand configured on participating gateways. Configured tunnel are typically given a higher level of trust than opportunistic tunnels.
- road warrior tunnel:
- a configured tunnel connecting one node with a fixed IP address and one node with a variable IP address. A road warrior (RW) connection must be initiated by the variable node, since the fixed t>
3.1.2 Hold policy
3.1.3 Pass-through policy
3.1.4 Deny policy
3.1.5 Encrypt policy
3.2 Keying State Machine - Initiator
3.2.1 Nonexistent connection
3.2.2 clear-text connection
3.2.3 Deny connection
3.2.4 Potential OE connection
3.2.4.1 Restriction on unauthentication TXT delegation records
3.2.5 Pending OE connection
3.2.6 Keyed connection
3.2.7 Expiring connection
3.2.8 Expired connection state
3.3 Keying State Machine - Responder
3.3.1 Unauthenticated OE peer state
3.3.2 Authenticated OE Peer
3.4 Renewal and Teardown
3.4.1 Aging
3.4.2 Teardown and Cleanup
4. Impacts on IKE
4.1 ISAKMP/IKE protocol
4.2 Gateway discovery process
4.3 Self identification
4.4 Public key Retrieval process
4.5 Interactions with DNSSEC
4.6 Recommended proposal types
4.6.1 Phase 1 parameters
4.6.2 Phase 2 parameters
5. DNS issues
5.1 Use of KEY record
5.2 Use of TXT delegation record
5.2.1 Choice of TXT record
5.3 Use of FQDN IDs
6. Network Address Translation interaction
6.1 Colocated NAT/NAPT
6.2 SG-A behind NAT/NAPT
6.3 Bob is behind a NAT/NAPT
7. Host implementations
8. Multihoming
9. Failure modes
9.1 DNS failures
9.2 DNS configured, IKE failures
9.3 System reboots
10. Unresolved issues
10.1 Control of reverse DNS
11. Examples
11.1 Clear-text usage (permit policy)
11.2 Opportunistic Encryption
11.2.1 (5) IPsec packet interception
11.2.2 (5B) DNS lookup for TXT record
11.2.3 (5C) DNS returns TXT record(s)
11.2.4 (5D) Initial IKE Main Mode Packet goes out
11.2.5 (5E1) Message 2 of phase 1 exchange
11.2.6 (5E2) Message 3 of phase 1 exchange
11.2.7 (5E3) Message 4 of phase 1 exchange
11.2.8 (5E4) Message 5 of phase 1 exchange
11.2.9 (5F1) Responder lookup of initiator key
11.2.10 (5F2) DNS replies with public key of initiator
11.2.11 (5E5) Responder replies with ID and authentication
11.2.12 (5G) IKE phase 2
11.2.12.1 (5G1) Initiator proposes tunnel
11.2.12.2 (5H1) Responder determines initiator's authority
11.2.12.3 (5H2) DNS replies with TXT record
11.2.12.4 (5G2) Responder agrees to proposal
11.2.12.5 (5G3) Final acknowledgement from initiator
11.2.13 (6) IPsec succeeds, sets up tunnel for communication between Alice and Bob
11.2.14 (9) SG-B already has tunnel up with G1, uses it
12. Security Considerations
12.1 Configured vs Opportunistic Tunnels
12.2 Firewalls vs Opportunistic Tunnels
12.3 Denial of Service
13. IANA Considerations
14. Acknowledgements
§ References
§ Authors' Addresses
§ Full Copyright Statement
Abstract
This document describes opportunistic encryption using IKE and IPsec. The objective is to allow encryption without any pre-arrangement specific to the pair of gateways involved. Each gateway administrator makes local arrangements to support opportunistic encryption. Once that is done, any two such gateways can communicate securely.
There are two large payoffs. First, if many machines must communicate securely, this approach reduces administrative overhead to order N (number of gateways), rather than the N squared cost to configure each tunnel separately. Second, it becomes possible to make secure communication the default, even when the partner is not known in advance.
There are naturally some risks and some costs, which are described.
This document is offered up as an Informational RFC.
TOC 1. Introduction
1.1 Motivation
The objective of opportunistic encryption is to allow encryption without any pre-arrangement specific to the pair of gateways involved. Each gateway administrator makes local arrangements -- specifically, adds public key information to DNS records -- to support opportunistic encryption and then enables this feature in the nodes' IPsec stack. Once that is done, any two such nodes can communicate securely.
This document describes opportunistic encryption as designed and (to date, partially) implemented by the Linux FreeS/WAN project. For project information, see www.freeswan.org.
The Internet Architecture Board (IAB) and Internet Engineering Steering Group have taken a strong stand that the Internet should use powerful encryption to provide security and privacy [4]. This project attempts to put this policy into practice by providing practical means to implement them.
The project believes that the IPsec protocols are the best chance to do that, because they are standardized, widely available and can often be deployed very easily, without changing hardware or software or retraining of users. However, the extension to opportunistic encryption seems necessary, both to help control administrative overheads and to get IPsec more widely used.
The use of "opportunistic encryption" offers the "fax effect". As each person installs one for their own use, it becomes more valuable for their neighbors to install one too, because there's one more person to use it with. The software automatically notices each newly installed box, and doesn't require a network administrator to reconfigure it.
This document describes the infrastructure needed to support this effort.
The term S/WAN is a trademark of RSA Data Systems, and is used with permission by this project.
1.2 Types of network traffic
To aid in understand the relationship between security processing and IPsec we divide network traffic into four categories:
- deny
- networks to which traffic is always forbidden
- permit
- networks to which traffic in the clear is desired
- opportunistic tunnel
- networks to which encryption should be done if possible, but communication is done in the clear otherwise
- configured tunnel
- networks to which encryption must be done, and communication is never in the clear
This document describes the third category. The first two categories are provided by traditional firewall devices. The fourth category is presently the offering of many Virtual Private Network (VPN) devices.
Category one, denied traffic by IP address, requires no authentication.
Category two, permitted traffic by IP address, requires no authentication. This is the normal default on 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 the a single authority, arranging for distribution of authentication material, while difficult, does not require any new technology.
The mechanism described here provides an additional way to distribute the authentication materials, notably a public key method that does not require deployment of an X.509 based infrastructure.
1.3 Peer authentication in Opportunistic Encryption
Opportunistic encryption involves creating tunnels with other nodes that are essentially strangers. This is done without any prior bilateral arrangement. There is therefore the difficult question of how does one know who one is talking to.
One possible answer is that one does not know who one is talking to. No useful authentication can be done, so do not even try. This mode of operation has been given the name "anonymous encryption". A man-in-the-middle attack can be used to thwart the privacy of this communication. This would be an active attack. Without peer authentication, there is no way to prevents this kind of attack.
Although a useful mode, it is not the goal of this project. It is a useful starting point, but the system should permit additional layers of trust to be built upon this system. In the described system, the anonymous encryption case is what results without DNSSEC. Were anonymous encryption the end goal, simpler methods are available to achieve this goal.
However, an essential premise of building private connections with strangers is that datagrams received through these opportunistic tunnels are no more special than datagrams that arrived in the clear.
Unlike in a VPN scenario, these datagrams should not be given any special exceptions when it comes to auditing, further authentication or firewalling.
On the outbound side, when initiating opportunistic encryption, it becomes a local matter what to do if one fails to setup a tunnel. It may be that the packet goes out in the clear, or it may be dropped. This is a local configuration matter.
In sum, we gain wider privacy (for the Internet at large) at minimal cost: the cost is the need to reassess assumptions about the relationship between IPsec authentication and further local access control.
1.4 Use of RFC2119 terms
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [5]
TOC 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
| 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. SG-A and SG-D are on two different exit paths from organization 1. SG-B/B is an independent organizations. Nodes Q and R are nodes that are on the Internet. PI is the Public Internet ("The Wild").
The following terminology is used in this document:
- security gateway:
- a system that performs IPsec tunnel mode encapsulation/decapsulation. [SGx] 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
- 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 hash sign represents phase 1 (IKE) cipher-text datagrams
- .
- a period represents an untrusted network of unknown type
- configured tunnel:
- Contrast with opportunistic tunnel. A tunnel that is directly/deliberately/hand configured on participating gateways. Configured tunnel are typically given a higher level of trust than opportunistic tunnels.
- road warrior tunnel:
- a configured tunnel connecting one node with a fixed IP address and one node with a variable IP address. A road warrior (RW) connection must be initiated by the variable node, since the fixed t>
3.1.2 Hold policy
3.1.3 Pass-through policy
3.1.4 Deny policy
3.1.5 Encrypt policy
3.2 Keying State Machine - Initiator
3.2.1 Nonexistent connection
3.2.2 clear-text connection
3.2.3 Deny connection
3.2.4 Potential OE connection
3.2.4.1 Restriction on unauthentication TXT delegation records
3.2.5 Pending OE connection
3.2.6 Keyed connection
3.2.7 Expiring connection
3.2.8 Expired connection state
3.3 Keying State Machine - Responder
3.3.1 Unauthenticated OE peer state
3.3.2 Authenticated OE Peer
3.4 Renewal and Teardown
3.4.1 Aging
3.4.2 Teardown and Cleanup
4. Impacts on IKE
4.1 ISAKMP/IKE protocol
4.2 Gateway discovery process
4.3 Self identification
4.4 Public key Retrieval process
4.5 Interactions with DNSSEC
4.6 Recommended proposal types
4.6.1 Phase 1 parameters
4.6.2 Phase 2 parameters
5. DNS issues
5.1 Use of KEY record
5.2 Use of TXT delegation record
5.2.1 Choice of TXT record
5.3 Use of FQDN IDs
6. Network Address Translation interaction
6.1 Colocated NAT/NAPT
6.2 SG-A behind NAT/NAPT
6.3 Bob is behind a NAT/NAPT
7. Host implementations
8. Multihoming
9. Failure modes
9.1 DNS failur