One document matched: draft-sheffer-autovpn-00.xml
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" []>
<rfc category="info" ipr="trust200902"
docName="draft-sheffer-autovpn-00">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<front>
<title abbrev="AutoVPN">The AutoVPN Architecture</title>
<author initials="Y." surname="Sheffer"
fullname="Yaron Sheffer">
<organization abbrev="Porticor">Porticor</organization>
<address>
<email>yaronf.ietf@gmail.com</email>
</address>
</author>
<author initials="Y." surname="Nir" fullname="Yoav Nir">
<organization abbrev="Check Point">Check Point Software Technologies Ltd.</organization>
<address>
<postal>
<street>5 Hasolelim st.</street>
<city>Tel Aviv</city>
<code>6789735</code>
<country>Israel</country>
</postal>
<email>ynir@checkpoint.com</email>
</address>
</author>
<date year="2014" />
<abstract>
<t>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.
</t>
</abstract>
</front>
<middle>
<!-- ************************************************************************************ -->
<section title="Introduction">
<t>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".
</t>
<t>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 <xref target="RFC5386"/> and <xref target="RFC5387"/>.
In addition, the
earlier <xref target="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 <xref target="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.
</t>
<t>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.</t>
<t>This document describes the
AutoVPN architecture, an opportunistic encryption extension to the Internet
Key Exchange v2 (IKEv2 - <xref target="RFC5996"/>) for IPsec VPN.</t>
<t>Some of the requirements behind this protocol are:
<list style="symbols">
<t>It should be suitable for business-to-business traffic,
and therefore for deployment on the open Internet.</t>
<t>It should be robust, efficient and network friendly enough to be
enabled by default.</t>
<t>It should be deployable on (existing) security gateways, rather
than requiring changes to hosts.</t>
<t>It should also work on hosts that are not protected by gateways, i.e. hosts
that are themselves IPsec endpoints.</t>
<t>It should require zero configuration. Some limited level
of security should be provided by devices which are not
configured.</t>
<t>After-the-fact security: the security guarantees can be
improved at a later time, possibly using out-of-band
means.</t>
<t>The protocol should coexist with regular IPsec, with no degradation in security.</t>
<t>The protocol should provide the best possible security
given the imperfections of today's Internet. In particular,
it should not rely on the deployment of DNS Security, anti spoofing
mechanisms or routing security.</t>
<t>Small gateways, as well as software VPN clients, are often behind NAT.
This scenario should be supported.</t>
</list></t>
</section>
<!-- ************************************************************************************ -->
<section title="Terminology">
<t>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.</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
<xref target="RFC2119" />.</t>
</section>
<!-- ************************************************************************************ -->
<section title="Architecture and Protocol Overview" anchor="protocol-overview">
<t>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.</t>
<t>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 <xref target="architecture"/> 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.
</t>
<figure anchor="architecture" title="Deployment Architecture">
<artwork>
<![CDATA[
+--------+ +---------+ +---------+ +--------+
| | | | | | | |
| Host | | Gateway | / -------- \ | Gateway | | Host |
| H1 |---| G1 |---| Internet |---| G2 |---| H2 |
| | | | \ -------- / | | | |
+--------+ +---------+ +---------+ +--------+]]>
</artwork>
</figure>
<t>
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.
</t>
<t>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.</t>
<t>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.
</t>
<t>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.</t>
<t>Lastly, we could have saved one round trip by allowing G2 to spoof H2's address.
We believe this would have been ill advised.</t>
<t>
The flow of messages is depicted in <xref target="message-sequence"/>.
<list style="symbols">
<t>H1 creates a network connection to H2, for example by sending a TCP SYN
packet. H2 replies normally to H1.</t>
<t>G2 intercepts the reply packet, but lets it pass
through. The connection proceeds normally, possibly
including data packets.</t>
<t>G2 sends a Probe Request message, addressed to H1.</t>
<t>G1 intercepts the Probe Request, does not forward it,
and sends a Probe Response, addressed to H2. Note that if H1 is NOT protected
by a gateway, it will receive the Probe Request message and
therefore the message should be
designed to have no effect on innocent receivers.</t>
<t>G2 intercepts the Probe Response, does not forward it, and
sends a Probe Complete, addressed to G1.
</t>
<t>
G1 now initiates an IKE_SA_INIT exchange to G2. This message includes payloads that
can be correlated with the previous messages.</t>
<t>G1 and G2 negotiate an IPsec SA, potentially for all traffic between
H1 and H2.</t>
<t>Both G1 and G2 now move the traffic between H1 and H2
into the new SA.</t>
</list></t>
<figure anchor="message-sequence" title="Message Sequence">
<artwork>
<![CDATA[
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 || ||
||<==============>||<============================>||<==============>||]]>
</artwork>
</figure>
</section>
<!-- ************************************************************************************ -->
<section title="Protocol Exchanges"
anchor="protocol-exchanges">
<t>
AutoVPN consists of a 3-way probing protocol, followed by a slightly extended IKEv2
exchange.</t>
<t>
The normal execution sequence of the protocol is as follows. G2 generates a
fresh, randomly generated value Nonce-R, and sends to H1:
</t>
<t>
<list style="empty">
<t>Probe Request: Version, Nonce-R, NAT-Detect</t>
</list>
</t>
<t>
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:
</t>
<t>
<list style="empty">
<t>Probe Response: Version, Nonce-I, Nonce-R</t>
</list>
</t>
<t>
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:
</t>
<t>
<list style="empty">
<t>Probe Complete: Version, Nonce-I, Nonce-R</t>
</list>
</t>
<t>
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.
</t>
</section>
<!-- ************************************************************************************ -->
<section title="Message Format" anchor="format">
<t>
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.
</t>
<t>
The Probe Request and Probe Complete messages MUST be encoded within ICMP.
The Probe Response message MUST be encoded within UDP.
</t>
<section title="ICMP Encoding">
<t>
Each payload is encoded as an ICMP Extension Object, as per <xref target="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:
<list style="symbols">
<t>Type is "Parameter Problem".</t>
<t>Code is the value 1.</t>
<t>The Checksum field MUST be computed, as per <xref target="RFC0792"/>.</t>
<t>The new Length field is defined in <xref target="RFC4884"/>.</t>
</list>
</t>
<t>
In the Extension Object Headers, Class-Num is TBD by IANA, and C-Type is the Type
value defined for each payload below.
</t>
</section>
<section title="UDP Encoding">
<t>
In this encoding, all payloads are simply concatenated following the Preamble. Each payload
is preceded by a payload header, as defined in <xref target="payloads"/>.
</t>
<t>
The generic Preamble format is described in the next figure.
<figure anchor="autovpn-preamble" title="AutoVPN Preamble">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IP Header... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Header... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SPI (16 bytes, value TBD by IANA) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
</t>
<t>
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.
</t>
</section>
<section anchor="payloads" title="Protocol Payloads">
<t>
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:
<figure anchor="payload-header" title="Payload Header">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | 0 | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... |
+...............................................................+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<list style="hanging">
<t hangText="Type:">
<vspace blankLines="1"/>One of the payload types listed below.
<vspace blankLines="1"/></t>
<t hangText="Length:">
<vspace blankLines="1"/>The payload length in octets, including
this header.
<vspace blankLines="1"/></t>
</list>
The following payload types are defined:
</t>
<texttable>
<ttcol align='center'>Name</ttcol>
<ttcol align='center'>Value</ttcol>
<ttcol align='left'>Definition</ttcol>
<c>Unused</c>
<c>0</c>
<c></c>
<c>Version</c>
<c>1</c>
<c>Generic information about the current message</c>
<c>Nonce-I</c>
<c>2</c>
<c>Initiator's nonce</c>
<c>Nonce-R</c>
<c>3</c>
<c>Responder's nonce</c>
<c>NAT-Detect</c>
<c>4</c>
<c>NAT detection information</c>
<c></c>
<c>4-127</c>
<c>Reserved to IANA</c>
<c></c>
<c>128-255</c>
<c>Reserved for private use</c>
</texttable>
</section>
<section title="Version Payload">
<t>This payload is formatted as follows:</t>
<figure anchor="version-payload" title="Version Payload">
<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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Message Type | Reserved | Vendor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
~ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+]]>
</artwork>
</figure>
<t>The header contains the following fields:</t>
<t>
<list style="hanging">
<t hangText="Version:">
<vspace blankLines="1"/>MUST be 0x01 for this version of the protocol.
<vspace blankLines="1"/></t>
<t hangText="Message Type:">
<vspace blankLines="1"/>1 for Probe Request, 2 for Probe Response, 3 for Probe Complete.
Other values are reserved to IANA.
<vspace blankLines="1"/></t>
<t hangText="Reserved:">
<vspace blankLines="1"/>MUST be sent as 0, and ignored by the receiver.
<vspace blankLines="1"/></t>
<t hangText="Vendor ID:">
<vspace blankLines="1"/>This field is optional and of variable length, possibly 0.
It MAY contain a string uniquely
identifying the vendor (e.g. "example.com"), or a binary string that is statistically
unique (e.g. the SHA-1 hash of "we support the XX extension").
<vspace blankLines="1"/></t>
</list>
</t>
</section>
<section title="Nonce Payloads">
<t>
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.
</t>
<t>
One possible way to construct the nonce is
</t>
<t>
<list style="empty">
<t>key-ID || HMAC-SHA256(K, gateway-IP || packet-fragment)</t>
</list>
</t>
<t>
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.
</t>
</section>
<section title="NAT-Detect Payload">
<t>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.
</t>
</section>
</section>
<!-- ************************************************************************************ -->
<section title="Error Handling and Reliability" anchor="error-handling">
<t>
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.
</t>
<t>
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.
</t>
</section>
<!-- ************************************************************************************ -->
<section title="NAT Considerations">
<t>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:</t>
<t>
<list style="symbols">
<t>If traffic from a host which is behind NAT (H1) is inserted directly into an IPsec
tunnel, it will emerge as-is on the other side, and the receiving host might see a
non-routable <xref target="RFC1918"/> source address.</t>
<t>The initiating gateway may not have enough information to formulate its IKE Traffic
Selector payload (TSi).</t>
</list>
</t>
<t>
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.
</t>
<t>We note that the protocol can be implemented correctly on a gateway that
performs the NAT function itself.
</t>
</section>
<!-- ************************************************************************************ -->
<section title="IKE Protocol Considerations">
<t>
The AutoVPN protocol imposes a few requirements on the IKE peers:
<list style="symbols">
<t>Both peers MUST use a certificate to authenticate.
In many cases this is expected to be a self-signed certificate. But see also
<xref target="cert-rollover"/>.</t>
<t>The peers MUST NOT negotiate any IPsec protocol, other than ESP in tunnel mode.</t>
<t>Each peer MUST offer only a single IP address in its negotiated traffic selector.
This IP address MUST be identical to the one the gateway
has proven authorization for. This MUST also be validated by the opposite peer. Per
policy, traffic selectors MAY be even narrower, e.g. referring to specific protocol
ports.
</t>
</list>
</t>
<section title="New IKE Payloads">
<t>
This protocol defines several new IKE payloads.
</t>
<section title="AutoVPN Nonce">
<t>
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.
</t>
</section>
<section title="Contact Details">
<t>
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:
<list style="empty">
<t>
This gateway is operated by Example Inc. To validate our identity, you may
wish to obtain our public key's fingerprint from our Web site, at
https://www.example.com/autovpn. Or you may wish to contact the network administrator at
1-616-555-1212 to get the fingerprint. Please compare this value with the fingerprint value
displayed by your gateway.
</t>
</list>
For obvious security reasons, this string MUST be rendered as plain text,
and in particular MUST NOT be rendered as HTML.
</t>
</section>
</section>
<section title="AUTOVPN_SHARED_SECRET Notification">
<t>
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 <xref target="cert-rollover"/> for details.
</t>
</section>
</section>
<!-- ************************************************************************************ -->
<section title="Security Policy">
<t>
This section describes the AutoVPN security policy, and should be viewed as an
extension of <xref target="RFC4301"/>.
</t>
<section title="Certificate States">
<t>
AutoVPN defines a state for each peer gateway's certificate.
A certificate may be in one of the following states (<xref target="certificate-states"/>):
<list style="symbols">
<t>Unknown. This may also be a certificate which had been manually removed,
through a manual operation or for a number of reasons listed below.</t>
<t>Known but unverified. A DN is associated with a certificate's fingerprint,
and additional
information may be available ("contact details").
When not used, such certificates may be deleted from the table, after some site-specific
timeout. It is RECOMMENDED that this timeout be larger than 7 days.</t>
<t>Trusted identity. The administrator can manually mark a certificate as Trusted.
Alternatively,
the certificate may have been signed by a trusted third party.</t>
<t>Untrusted identity. The administrator can manually mark a certificate as Untrusted, if
he or she manually checks the certificate's fingerprint and detects a mismatch
against an advertised value. </t>
<t>Managed. These certificates belong to peers that are part of the same managed VPN. They are
not further discussed in this document.</t>
</list>
</t>
<figure anchor="certificate-states" title="Certificate States">
<artwork>
<![CDATA[
/-----------\ /-----------\
| | successful IKE exchange | |
| | ==================================> | |
| Unknown | timeout (when allowed) |Unverified |
| | <================================== | |
| | =========== | |
\-----------/ || successful exchange \-----------/
|| || (trusted third party) ||
|| || ||
|| || manual marking ||
|| configuration || ========================
|| || || ||
|| || || ||
|| || || ||
\/ || \/ \/
/-----------\ || /-----------\ /-----------\
| | || | | | |
| | ====> | | | |
| Managed | | Trusted | | Untrusted |
| | | | | |
| | | | | |
\-----------/ \-----------/ \-----------/]]>
</artwork>
</figure>
<t>
If the gateway detects that a peer's certificate has been explicitly revoked,
it MUST delete this certificate from the table.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<section anchor="cert-rollover" title="Certificate Rollover and Permanent Association">
<t>
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.
</t>
<t>
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.
</t>
<t>
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.
</t>
<t>
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
<list style="empty">
<t>prf+(SK_d, "shared secret for AutoVPN")</t>
</list>
where SK_d is the derivation key of the current IKE SA.
The literal string is represented in ASCII, with no zero terminator.
</t>
</section>
<section title="Certificate Conflicts">
<t>
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.
</t>
<t>
As a result, barring incorrect configuration, the certificate table can never
contain multiple certificates with the same DN.
</t>
</section>
<section title="Fallback to Clear">
<t>
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.
</t>
<t>
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
<xref target="RFC6023"/>.
</t>
</section>
</section>
<!-- ************************************************************************************ -->
<section title="IANA Considerations" anchor="iana">
<t>TBD.</t>
</section>
<!-- ************************************************************************************ -->
<section title="Security Considerations" anchor="security">
<t>TBD.</t>
</section>
<!-- ************************************************************************************ -->
<section title="Acknowledgements">
<t>A proof of concept implementation of this protocol was created by
Michael Rogovin at Check Point, and we would like
to acknowledge his contribution.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.0792.xml"?>
<?rfc include="reference.RFC.1918.xml"?>
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.4301.xml"?>
<?rfc include="reference.RFC.5996.xml"?>
<?rfc include="reference.RFC.4884.xml"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.4322.xml"?>
<?rfc include="reference.RFC.5386.xml"?>
<?rfc include="reference.RFC.5387.xml"?>
<?rfc include="reference.RFC.6023.xml"?>
<?rfc include="reference.RFC.6480.xml"?>
<reference anchor="oe-history" target="http://nohats.ca/wordpress/blog/2013/09/12/history-and-implementation-status-of-opportunistic-encryption-for-ipsec/"><front><title>History and implementation status of Opportunistic Encryption for IPsec</title>
<author initials="P. W." surname="Wouters" fullname="Paul Wouters"><organization/></author><date year="2013" month="September"/>
</front></reference>
</references>
<section title="Change Log">
<section title="-00">
<t>Initial version.</t>
</section>
</section>
<section title="Implementation Considerations">
<section title="Address Authorization">
<t>
Address authorization SHOULD be maintained separately from peer identity. Timing out
authorization data (as proposed in <xref target="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.
</t>
<t>
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 <xref target="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.
</t>
<t>
Also TBD are the IPsec policy implications, within the framework of <xref target="RFC4301"/>,
Sec. 4.4.3.
</t>
</section>
<section title="Multiple Interfaces and Alternative Gateways">
<t>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.</t>
</section>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:11:16 |