[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                         Y. Sheffer
Internet-Draft                                                  Porticor
Intended status: Informational                                    Y. Nir
Expires: August 8, 2014                                      Check Point
                                                        February 4, 2014


                        The AutoVPN Architecture
                        draft-sheffer-autovpn-00

Abstract

   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.

Status of This Memo

   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 8, 2014.

Copyright Notice

   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



Sheffer & Nir            Expires August 8, 2014                 [Page 1]


Internet-Draft                   AutoVPN                   February 2014


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Architecture and Protocol Overview  . . . . . . . . . . . . .   4
   4.  Protocol Exchanges  . . . . . . . . . . . . . . . . . . . . .   6
   5.  Message Format  . . . . . . . . . . . . . . . . . . . . . . .   7
     5.1.  ICMP Encoding . . . . . . . . . . . . . . . . . . . . . .   7
     5.2.  UDP Encoding  . . . . . . . . . . . . . . . . . . . . . .   7
     5.3.  Protocol Payloads . . . . . . . . . . . . . . . . . . . .   8
     5.4.  Version Payload . . . . . . . . . . . . . . . . . . . . .   9
     5.5.  Nonce Payloads  . . . . . . . . . . . . . . . . . . . . .  10
     5.6.  NAT-Detect Payload  . . . . . . . . . . . . . . . . . . .  10
   6.  Error Handling and Reliability  . . . . . . . . . . . . . . .  10
   7.  NAT Considerations  . . . . . . . . . . . . . . . . . . . . .  11
   8.  IKE Protocol Considerations . . . . . . . . . . . . . . . . .  11
     8.1.  New IKE Payloads  . . . . . . . . . . . . . . . . . . . .  12
       8.1.1.  AutoVPN Nonce . . . . . . . . . . . . . . . . . . . .  12
       8.1.2.  Contact Details . . . . . . . . . . . . . . . . . . .  12
     8.2.  AUTOVPN_SHARED_SECRET Notification  . . . . . . . . . . .  12
   9.  Security Policy . . . . . . . . . . . . . . . . . . . . . . .  12
     9.1.  Certificate States  . . . . . . . . . . . . . . . . . . .  12
     9.2.  Certificate Rollover and Permanent Association  . . . . .  14
     9.3.  Certificate Conflicts . . . . . . . . . . . . . . . . . .  14
     9.4.  Fallback to Clear . . . . . . . . . . . . . . . . . . . .  15
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  15
   11. Security Considerations . . . . . . . . . . . . . . . . . . .  15
   12. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  15
   13. References  . . . . . . . . . . . . . . . . . . . . . . . . .  15
     13.1.  Normative References . . . . . . . . . . . . . . . . . .  15
     13.2.  Informative References . . . . . . . . . . . . . . . . .  16
   Appendix A.  Change Log . . . . . . . . . . . . . . . . . . . . .  16
     A.1.  -00 . . . . . . . . . . . . . . . . . . . . . . . . . . .  16
   Appendix B.  Implementation Considerations  . . . . . . . . . . .  17
     B.1.  Address Authorization . . . . . . . . . . . . . . . . . .  17
     B.2.  Multiple Interfaces and Alternative Gateways  . . . . . .  17
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  17

1.  Introduction

   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



Sheffer & Nir            Expires August 8, 2014                 [Page 2]


Internet-Draft                   AutoVPN                   February 2014


   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:

   o  It should be suitable for business-to-business traffic, and
      therefore for deployment on the open Internet.

   o  It should be robust, efficient and network friendly enough to be
      enabled by default.

   o  It should be deployable on (existing) security gateways, rather
      than requiring changes to hosts.

   o  It should also work on hosts that are not protected by gateways,
      i.e. hosts that are themselves IPsec endpoints.

   o  It should require zero configuration.  Some limited level of
      security should be provided by devices which are not configured.

   o  After-the-fact security: the security guarantees can be improved
      at a later time, possibly using out-of-band means.



Sheffer & Nir            Expires August 8, 2014                 [Page 3]


Internet-Draft                   AutoVPN                   February 2014


   o  The protocol should coexist with regular IPsec, with no
      degradation in security.

   o  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.

   o  Small gateways, as well as software VPN clients, are often behind
      NAT.  This scenario should be supported.

2.  Terminology

   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].

3.  Architecture and Protocol Overview

   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



Sheffer & Nir            Expires August 8, 2014                 [Page 4]


Internet-Draft                   AutoVPN                   February 2014


   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.

   o  H1 creates a network connection to H2, for example by sending a
      TCP SYN packet.  H2 replies normally to H1.

   o  G2 intercepts the reply packet, but lets it pass through.  The
      connection proceeds normally, possibly including data packets.

   o  G2 sends a Probe Request message, addressed to H1.

   o  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.

   o  G2 intercepts the Probe Response, does not forward it, and sends a
      Probe Complete, addressed to G1.

   o  G1 now initiates an IKE_SA_INIT exchange to G2.  This message
      includes payloads that can be correlated with the previous
      messages.

   o  G1 and G2 negotiate an IPsec SA, potentially for all traffic
      between H1 and H2.




Sheffer & Nir            Expires August 8, 2014                 [Page 5]


Internet-Draft                   AutoVPN                   February 2014


   o  Both G1 and G2 now move the traffic between H1 and H2 into the new
      SA.


 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

4.  Protocol Exchanges

   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:

      Probe Request: Version, Nonce-R, NAT-Detect

   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:

      Probe Response: Version, Nonce-I, Nonce-R

   where the content of Nonce-R is copied from the request.  G2
   intercepts this message, and does not forward it to H2.  G2 MUST



Sheffer & Nir            Expires August 8, 2014                 [Page 6]


Internet-Draft                   AutoVPN                   February 2014


   verify that Nonce-R is valid, and silently ignore the message
   otherwise.  G2 replies with:

      Probe Complete: Version, Nonce-I, Nonce-R

   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.

5.  Message Format

   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.

5.1.  ICMP Encoding

   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:

   o  Type is "Parameter Problem".

   o  Code is the value 1.

   o  The Checksum field MUST be computed, as per [RFC0792].

   o  The new Length field is defined in [RFC4884].

   In the Extension Object Headers, Class-Num is TBD by IANA, and C-Type
   is the Type value defined for each payload below.

5.2.  UDP Encoding

   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.

   The generic Preamble format is described in the next figure.







Sheffer & Nir            Expires August 8, 2014                 [Page 7]


Internet-Draft                   AutoVPN                   February 2014


    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 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.

5.3.  Protocol Payloads

   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:


    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

   Type:

      One of the payload types listed below.


   Length:

      The payload length in octets, including this header.


   The following payload types are defined:



Sheffer & Nir            Expires August 8, 2014                 [Page 8]


Internet-Draft                   AutoVPN                   February 2014


   +------------+---------+--------------------------------------------+
   |    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                   |
   +------------+---------+--------------------------------------------+

5.4.  Version Payload

   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:

   Version:

      MUST be 0x01 for this version of the protocol.


   Message Type:

      1 for Probe Request, 2 for Probe Response, 3 for Probe Complete.
      Other values are reserved to IANA.


   Reserved:

      MUST be sent as 0, and ignored by the receiver.





Sheffer & Nir            Expires August 8, 2014                 [Page 9]


Internet-Draft                   AutoVPN                   February 2014


   Vendor ID:

      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").


5.5.  Nonce Payloads

   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

      key-ID || HMAC-SHA256(K, gateway-IP || packet-fragment)

   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.

5.6.  NAT-Detect Payload

   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.

6.  Error Handling and Reliability

   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



Sheffer & Nir            Expires August 8, 2014                [Page 10]


Internet-Draft                   AutoVPN                   February 2014


   messages even if they contain payloads that it does not understand,
   and SHOULD ignore these payloads.

7.  NAT Considerations

   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:

   o  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 [RFC1918]
      source address.

   o  The initiating gateway may not have enough information to
      formulate its IKE Traffic Selector payload (TSi).

   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.

8.  IKE Protocol Considerations

   The AutoVPN protocol imposes a few requirements on the IKE peers:

   o  Both peers MUST use a certificate to authenticate.  In many cases
      this is expected to be a self-signed certificate.  But see also
      Section 9.2.

   o  The peers MUST NOT negotiate any IPsec protocol, other than ESP in
      tunnel mode.

   o  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.






Sheffer & Nir            Expires August 8, 2014                [Page 11]


Internet-Draft                   AutoVPN                   February 2014


8.1.  New IKE Payloads

   This protocol defines several new IKE payloads.

8.1.1.  AutoVPN Nonce

   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.

8.1.2.  Contact Details

   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:

      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.

   For obvious security reasons, this string MUST be rendered as plain
   text, and in particular MUST NOT be rendered as HTML.

8.2.  AUTOVPN_SHARED_SECRET Notification

   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.

9.  Security Policy

   This section describes the AutoVPN security policy, and should be
   viewed as an extension of [RFC4301].

9.1.  Certificate States

   AutoVPN defines a state for each peer gateway's certificate.  A
   certificate may be in one of the following states (Figure 6):

   o  Unknown.  This may also be a certificate which had been manually
      removed, through a manual operation or for a number of reasons
      listed below.



Sheffer & Nir            Expires August 8, 2014                [Page 12]


Internet-Draft                   AutoVPN                   February 2014


   o  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.

   o  Trusted identity.  The administrator can manually mark a
      certificate as Trusted.  Alternatively, the certificate may have
      been signed by a trusted third party.

   o  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.

   o  Managed.  These certificates belong to peers that are part of the
      same managed VPN.  They are not further discussed in this
      document.


   /-----------\                                     /-----------\
   |           |       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.




Sheffer & Nir            Expires August 8, 2014                [Page 13]


Internet-Draft                   AutoVPN                   February 2014


   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.

9.2.  Certificate Rollover and Permanent Association

   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

      prf+(SK_d, "shared secret for AutoVPN")

   where SK_d is the derivation key of the current IKE SA.  The literal
   string is represented in ASCII, with no zero terminator.

9.3.  Certificate Conflicts

   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



Sheffer & Nir            Expires August 8, 2014                [Page 14]


Internet-Draft                   AutoVPN                   February 2014


   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.

9.4.  Fallback to Clear

   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].

10.  IANA Considerations

   TBD.

11.  Security Considerations

   TBD.

12.  Acknowledgements

   A proof of concept implementation of this protocol was created by
   Michael Rogovin at Check Point, and we would like to acknowledge his
   contribution.

13.  References

13.1.  Normative References

   [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.





Sheffer & Nir            Expires August 8, 2014                [Page 15]


Internet-Draft                   AutoVPN                   February 2014


   [RFC4301]  Kent, S. and K. Seo, "Security Architecture for the
              Internet Protocol", RFC 4301, December 2005.

   [RFC4884]  Bonica, R., Gan, D., Tappan, D., and C. Pignataro,
              "Extended ICMP to Support Multi-Part Messages", RFC 4884,
              April 2007.

   [RFC5996]  Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen,
              "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC
              5996, September 2010.

13.2.  Informative References

   [RFC4322]  Richardson, M. and D. 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., "History and implementation status of
              Opportunistic Encryption for IPsec", September 2013,
              <http://nohats.ca/wordpress/blog/2013/09/12/history-and-
              implementation-status-of-opportunistic-encryption-for-
              ipsec/>.

Appendix A.  Change Log

A.1.  -00

   Initial version.






Sheffer & Nir            Expires August 8, 2014                [Page 16]


Internet-Draft                   AutoVPN                   February 2014


Appendix B.  Implementation Considerations

B.1.  Address Authorization

   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.

B.2.  Multiple Interfaces and Alternative Gateways

   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.

Authors' Addresses

   Yaron Sheffer
   Porticor

   Email: yaronf.ietf@gmail.com


   Yoav Nir
   Check Point Software Technologies Ltd.
   5 Hasolelim st.
   Tel Aviv  6789735
   Israel

   Email: ynir@checkpoint.com









Sheffer & Nir            Expires August 8, 2014                [Page 17]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/