| Network Working Group | Y. Sheffer |
| Internet-Draft | Porticor |
| Intended status: Informational | Y. Nir |
| Expires: August 07, 2014 | Check Point |
| February 03, 2014 |
The AutoVPN Architecture
draft-sheffer-autovpn-00
This document describes the AutoVPN architecture. AutoVPN allows IPsec security associations to be set up with no prior configuration, using the "leap of faith" paradigm. The document defines a lightweight protocol for negotiating such opportunistic encryption either directly between hosts or between two security gateways on the path.
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on August 07, 2014.
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
In the last few years, there have been several attempts to define an opportunistic encryption architecture, where network traffic is confidentiality-protected, even in the absence of proper authentication of the peers. This protection is often accompanied by continuity of identity, i.e. although the identity may not be authenticated, it is verified to remain unchanged between multiple protocol sessions, and over long periods (days/weeks). This initial protection may be enhanced at a later stage, as peers gain stronger trust in each other's identity. A term which is often used to denote this policy is "leap of faith".
In the IPsec space, these attempts culminated in the BTNS (Better Than Nothing Security) working group's specifications. The BTNS working group produced a number of documents, including [RFC5386] and [RFC5387]. In addition, the earlier [RFC4322] describes Opportunistic Encryption, as implemented in various dialects of Linux (the history of Linux OE is summarized in a long post by Paul Wouters [oe-history]). However these specifications focus on the architectural IPsec implications, and provide insufficient context to implement the behavior described in the current document. "Leap of faith" has never been fully specified in the IPsec context, or when specified, assumes mechanisms that are still not widely deployed.
Similarly to many security architectures, a well designed opportunistic encryption solution requires both a robust protocol, and a user interaction component that allows the user to understand the exact security guarantees available at any time, so that the user may add external inputs about trustworthiness of communication peers while staying away from the "just press OK" mentality.
This document describes the AutoVPN architecture, an opportunistic encryption extension to the Internet Key Exchange v2 (IKEv2 - [RFC5996]) for IPsec VPN.
Some of the requirements behind this protocol are:
We use the term "initiator" for the gateway through which came the original traffic. The gateway may not be the initiator of the new protocol described below. The other gateway is the "responder". Note that these terms correspond to the gateways' behavior with respect to IKE negotiation.
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].
The protocol creates an IPsec tunnel to protect traffic which would otherwise be transmitted in the clear. What follows is a high level description of the sequence of operations.
We use H1 and H2 to denote two hosts (endpoints), and G1 and G2 to denote two IPsec gateways, protecting H1 and H2 respectively. This setup is shown in Figure 1 below. The solution described here is also applicable when one or both hosts is collocated with its respective gateway. Unfortunately it cannot be optimized for these cases, since source IP addresses can always be spoofed.
+--------+ +---------+ +---------+ +--------+
| | | | | | | |
| Host | | Gateway | / -------- \ | Gateway | | Host |
| H1 |---| G1 |---| Internet |---| G2 |---| H2 |
| | | | \ -------- / | | | |
+--------+ +---------+ +---------+ +--------+
Figure 1: Deployment Architecture
Initially, only H1 knows of H2's address. The protocol below allows both intervening gateways to discover each other, and to gain assurance that each one is on-path of the opposite host, i.e. it can see traffic addressed to the respective host, and can respond to such traffic.
We assume that both G1 and G2 contain access control functionality, as required by the IPsec architecture, and that both allow some clear traffic between H1 and H2.
The message sequence below is motivated to a great extent by the need to cater to NAT devices in front of G1, the original initiator. It is assumed that correctly implemented NAT devices will perform correct reverse translation of ICMP messages. However we cannot assume that they handle correctly ICMP messages of an unknown type.
Another major consideration is which side should drive the exchange. We have chosen the responder side (G2), since in an Internet where most traffic uses HTTP, the responder side knows best which traffic should be protected.
Lastly, we could have saved one round trip by allowing G2 to spoof H2's address. We believe this would have been ill advised.
The flow of messages is depicted in Figure 2.
H1 G1 G2 H2
==== ==== ==== ====
|| || Syn || ||
||----------------------------------------------------------------->||
|| || Ack || ||
||<-----------------------------------------------------------------||
|| || Unencrypted traffic || ||
||<================================================================>||
|| || || ||
|| || || ||
|| || Probe Request (ICMP) || ||
||<- - - - - - - -||<-----------------------------|| ||
|| || Probe Response (UDP/4500) || ||
|| ||----------------------------->||- - - - - - - ->||
|| || Probe Complete (ICMP) || ||
|| ||<-----------------------------|| ||
|| || IKE Message #1 || ||
|| ||----------------------------->|| ||
|| || IKE Signaling || ||
|| ||<============================>|| ||
|| || Protected traffic || ||
||<==============>||<============================>||<==============>||
Figure 2: Message Sequence
AutoVPN consists of a 3-way probing protocol, followed by a slightly extended IKEv2 exchange.
The normal execution sequence of the protocol is as follows. G2 generates a fresh, randomly generated value Nonce-R, and sends to H1:
G1 intercepts the received message and does not forward it to H1. G1 MAY verify that the message corresponds to an ongoing connection, using the packet fragment contained in the ICMP envelope. G1 generates a fresh, random Nonce-I and sends to H2:
where the content of Nonce-R is copied from the request. G2 intercepts this message, and does not forward it to H2. G2 MUST verify that Nonce-R is valid, and silently ignore the message otherwise. G2 replies with:
G1 MUST check the validity of Nonce-I and Nonce-R. Finally, G1 sends an IKEv2 IKE_SA_INIT message to G2, containing a copy of the received Nonce-R.
The AutoVPN protocol messages consist of a sequence of type-length-value (TLV) payloads. The messages are encoded in two different base protocols: ICMP and UDP over port 4500.
The Probe Request and Probe Complete messages MUST be encoded within ICMP. The Probe Response message MUST be encoded within UDP.
Each payload is encoded as an ICMP Extension Object, as per [RFC4884]. ICMP Error messages contain a copy of (part of) the original packet, and this is used to associate the ICMP message with the original clear traffic. ICMP header fields are populated as follows:
In the Extension Object Headers, Class-Num is TBD by IANA, and C-Type is the Type value defined for each payload below.
In this encoding, all payloads are simply concatenated following the Preamble. Each payload is preceded by a payload header, as defined in Section 5.3.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Header... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Header... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI (16 bytes, value TBD by IANA) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: AutoVPN Preamble
The generic Preamble format is described in the next figure.
The Probe Response protocol message has 4500 as its destination port. The protocol reuses the IKE/IPsec port 4500, however it is neither IKE nor IPsec. All three can coexist, and are distinguished using the SPI value. The specific SPI value will be allocated out of the "reserved" SPI space.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | 0 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... |
+...............................................................+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: Payload Header
An AutoVPN payload is encoded as an ICMP Extension Object or within a UDP message. When using UDP, the generic payload header is described in the next figure:
The following payload types are defined:
| Name | Value | Definition |
|---|---|---|
| Unused | 0 | |
| Version | 1 | Generic information about the current message |
| Nonce-I | 2 | Initiator's nonce |
| Nonce-R | 3 | Responder's nonce |
| NAT-Detect | 4 | NAT detection information |
| 4-127 | Reserved to IANA | |
| 128-255 | Reserved for private use |
This payload is formatted as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Reserved | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: Version Payload
The header contains the following fields:
Nonces are random or unpredictable values that enable the entity that generated them to recognize them as valid when it receives them again. Nonces MAY be used to encode state, in order to enable stateless implementations of this protocol. The length of each nonce (excluding the payload header) MUST be between 8 and 64 octets, inclusive.
One possible way to construct the nonce is
where K is a secret key known only to the sender, and key-ID identifies the key, enabling smooth roll-over of keys. Packet-fragment is the same portion of the packet as returned in an ICMP response, i.e. the IP header and the 8 octets that follow it.
This payload consists of a 4-octet obfuscated IPv4 address, followed by a 2-octet port number. The address is obfuscated by a XOR operation with 0x0F0F0F0F, with the intention of defeating over-eager NAT devices which might try to rewrite the packet. The address and port are the source address/port of the original (clear) packet, as seen by the remote gateway (G2). The IP protocol (e.g. UDP or TCP) is inferred from the packet fragment included in the ICMP message containing this payload.
The AutoVPN protocol is UDP and ICMP based, and therefore per-message reliability is not guaranteed. Both sides MAY retransmit the ICMP and UDP messages, but MUST NOT do so more than twice (total of 3 messages). The gateway (G2) that sends the first ICMP message MUST NOT retry a particular peer more than once every 24 hours.
The protocol does not include any error messages. If a peer does not accept a particular message for any reason, it MUST silently drop it. For forward compatibility, a receiver SHOULD process incoming messages even if they contain payloads that it does not understand, and SHOULD ignore these payloads.
The current version of the protocol allows both sides to detect a NAT being performed between the gateways. Detection takes place during the probing phase. However this scenario raises several issues, which require further investigation before a useful solution can be proposed:
A solution that can be considered is for G1 to request a Tunnel Inner Address using an IKE Configuration Payload, and to perform NAT on traffic originating from H1 so that it appears to be sourced from that address. One of the issues with this solution is that the initial clear connection will necessarily be broken because of the address change.
We note that the protocol can be implemented correctly on a gateway that performs the NAT function itself.
The AutoVPN protocol imposes a few requirements on the IKE peers:
This protocol defines several new IKE payloads.
This payload has the payload type TBD by IANA. It MUST only be used in the first message of the IKE_SA_INIT exchange. The payload contains an exact copy of the Nonce-R AutoVPN payload, without the AutoVPN payload header.
This payload has the payload type TBD by IANA. It SHOULD be sent by both peers during the IKE_AUTH exchange. The payload contains a human readable UTF-8 string which is designed to assist the person managing the opposite protocol peer in verifying the sender's true identity. An example string is:
For obvious security reasons, this string MUST be rendered as plain text, and in particular MUST NOT be rendered as HTML.
This notification, whose value is TBD by IANA, contains no data. It signifies that an AutoVPN shared secret MUST be created by the two IKE peers. See Section 9.2 for details.
This section describes the AutoVPN security policy, and should be viewed as an extension of [RFC4301].
AutoVPN defines a state for each peer gateway's certificate. A certificate may be in one of the following states (Figure 6):
/-----------\ /-----------\
| | successful IKE exchange | |
| | ==================================> | |
| Unknown | timeout (when allowed) |Unverified |
| | <================================== | |
| | =========== | |
\-----------/ || successful exchange \-----------/
|| || (trusted third party) ||
|| || ||
|| || manual marking ||
|| configuration || ========================
|| || || ||
|| || || ||
|| || || ||
\/ || \/ \/
/-----------\ || /-----------\ /-----------\
| | || | | | |
| | ====> | | | |
| Managed | | Trusted | | Untrusted |
| | | | | |
| | | | | |
\-----------/ \-----------/ \-----------/
Figure 6: Certificate States
If the gateway detects that a peer's certificate has been explicitly revoked, it MUST delete this certificate from the table.
A PAD entry may exist for certificates in the Unverified, Managed or Trusted states. A PAD entry MUST NOT exist for a certificate in the Untrusted state, and IKE exchanges with peers presenting such certificates MUST be rejected, regardless of who initiated the exchange. When a certificate is deleted (whether manually or automatically) or marked as Untrusted, the associated PAD entry MUST be deleted.
When locating the peer, only the DN should be used. The peer's IP address MUST NOT be used, to allow peers to change their address.
In the absence of a certificate rollover mechanism, it would be impossible to distinguish between a legitimate peer presenting a new certificate and a MITM attacker. Therefore, AutoVPN gateways MUST support the shared secret mechanism described here.
As noted above, the information about a peer's certificate will normally time-out and be deleted. However any of the gateways can choose a convenient time to "promote" the association between the gateways, by trigerring the creation of a shared secret. This secret never expires, other than through manual deletion on both peers.
The shared secret is associated with the pair of gateway identities, specifically with the IDi, IDr payloads exchanged between the gateways. Once a shared secret is established, both gateways MUST use it with the associated peer, in preference to certificate-based or other forms of authentication. A shared secret MAY be initiated for a peer in Unverified or Trusted state. On each gateway, the shared secret is associated with the peer gateway's certificate, and both MUST NOT be timed out regardless of the certificate's trust state.
The initiating gateway, which may be an IKE initiator or responder, MAY send the AUTOVPN_SHARED_SECRET notification at any time. The shared secret is the value
where SK_d is the derivation key of the current IKE SA. The literal string is represented in ASCII, with no zero terminator.
A certificate conflict may be detected during the IKE exchange. This happens when an AutoVPN peer presents a certificate whose DN matches the DN of a known AutoVPN certificate, but which is different from that certificate. In such cases the new peer MUST be rejected, with the notification AUTHENTICATION_FAILED.
As a result, barring incorrect configuration, the certificate table can never contain multiple certificates with the same DN.
In some cases it may be desirable to allow fallback to clear traffic in cases where an IKE/IPsec association cannot be established, even when the peer is known. This is left to local policy, and SHOULD be configurable on the gateway. Such configuration MAY take the trust level of the peer gateway into account.
Moreover, some policies may prefer to send traffic unprotected, even when an IKE SA can be established, and then renegotiate an IPsec SA following some manual action. One possible way of doing this is using the mechanism described in [RFC6023].
TBD.
TBD.
A proof of concept implementation of this protocol was created by Michael Rogovin at Check Point, and we would like to acknowledge his contribution.
| [RFC0792] | Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. |
| [RFC1918] | Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. |
| [RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
| [RFC4301] | Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. |
| [RFC5996] | Kaufman, C., Hoffman, P., Nir, Y. and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. |
| [RFC4884] | Bonica, R., Gan, D., Tappan, D. and C. Pignataro, "Extended ICMP to Support Multi-Part Messages", RFC 4884, April 2007. |
| [RFC4322] | Richardson, M. and D.H. Redelmeier, "Opportunistic Encryption using the Internet Key Exchange (IKE)", RFC 4322, December 2005. |
| [RFC5386] | Williams, N. and M. Richardson, "Better-Than-Nothing Security: An Unauthenticated Mode of IPsec", RFC 5386, November 2008. |
| [RFC5387] | Touch, J., Black, D. and Y. Wang, "Problem and Applicability Statement for Better-Than-Nothing Security (BTNS)", RFC 5387, November 2008. |
| [RFC6023] | Nir, Y., Tschofenig, H., Deng, H. and R. Singh, "A Childless Initiation of the Internet Key Exchange Version 2 (IKEv2) Security Association (SA)", RFC 6023, October 2010. |
| [RFC6480] | Lepinski, M. and S. Kent, "An Infrastructure to Support Secure Internet Routing", RFC 6480, February 2012. |
| [oe-history] | Wouters, P. W., "History and implementation status of Opportunistic Encryption for IPsec", September 2013. |
Initial version.
Address authorization SHOULD be maintained separately from peer identity. Timing out authorization data (as proposed in [RFC4322]) is risky, since the authorization protocol allows a MITM, and also exposes clear traffic. This issue is TBD, and for now, authorization will only be removed when a peer is deleted.
We should look at alternative ways to prove address ownership. For example, if the gateway G1 can prove its ownership of a certain address range, it might send an RPKI [RFC6480] certificate to that effect, plus proof of possession in IKE_AUTH. The peer gateway G2 might then decide to allow a wider traffic selector including all of G1's addresses, instead of just H1.
Also TBD are the IPsec policy implications, within the framework of [RFC4301], Sec. 4.4.3.
We might want to support multiple gateway addresses in the probing protocol, so we can have high quality connectivity without resorting to "fallback to the clear" (i.e. have very long timeouts, measured in days). On the other hand, maybe MOBIKE does the work in IKEv2.