One document matched: draft-mrw-dvne-prot-00.xml
<?xml version="1.0"?> <!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc2629 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml'>
]/>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" ipr="trust200902" docName="draft-mrw-dvne-prot-00.txt">
<front>
<title abbrev="DVNE Protocol">Dynamic Virtual Network Engine (DVNE) Protocol</title>
<author initials="M." surname="Wasserman" fullname="Margaret Wasserman">
<organization>Painless Security</organization>
<address>
<postal>
<street>356 Abbott Street</street>
<city>North Andover</city> <region>MA</region>
<code>01845</code>
<country>USA</country>
</postal>
<phone>+1 781 405 7464</phone>
<email>mrw@painless-security.com</email>
<uri>http://www.painless-security.com</uri>
</address>
</author>
<author fullname="Padmanabha Nallur" initials="P."
surname="Nallur">
<organization>Futurewei Technologies</organization>
<address>
<postal>
<street>3255-4, Scott Blvd</street>
<city>Santa Clara</city>
<region>California</region>
<country>USA</country>
</postal>
<email>pnallur@huawei.com</email>
</address>
</author>
<date month="October" year="2010" />
<abstract>
<t>
This document describes the Dynamic Virtual Network Engine (DVNE)
protocol. The DVNE protocol is a signaling protocol between a virtual
network node (the DVNE Client) and a configuration server (the DVNE
Mediator). The DVNE protocol is used to authenticate the nodes in a
Virtual Network and assist them to setup and release VPN connections
directly among themselves.
</t>
<t>
A DVNE clients can be located anywhere in a private or public network,
directly connected or behind one or more levels of NAT. The DVNE
protocol performs client authentication, peer discovery, virtual
network address management, and provides all parameters necessary to
enable the clients setup a secure VPN connection. The protocol does
not explicitly setup the VPN connection itself. It only enables the
clients to be able to directly setup the VPN connection themselves.
</t>
</abstract>
</front>
<middle>
<section title="Requirements Terminology">
<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 RFC 2119
<xref target="RFC2119"/>.
</t>
</section>
<section title="Introduction">
<t>
This document describes the Dynamic Virtual Network Engine (DVNE)
protocol. The DVNE protocol is a signaling protocol between a virtual
network node (the DVNE Client) and a configuration server (the DVNE
Mediator). The DVNE protocol is used to authenticate the nodes in a
Virtual Network and assist them to setup and release VPN connections
directly among themselves.
</t>
<t>
A DVNE clients can be located anywhere in a private or public network,
directly connected or behind one or more levels of NAT. The DVNE
protocol performs client authentication, peer discovery, virtual
network address management, and provides all parameters necessary to
enable the clients setup a secure VPN connection. The protocol does
not explicitly setup the VPN connection itself. It only enables the
clients to be able to directly setup the VPN connection themselves.
</t>
<t>
The DVNE protocol is used by the DVNE framework to setup a virtual or
overlay networks among hosts which is independent of the underlying
physical network.
</t>
<t>
This document provides an overview of DVNE protocol functionality,
including detailed flows, message layouts, and parameters of the DVNE
protocol. The main functional components of the DVNE Protocol are the
DVNE Client (a node on a virtual network) and the DVNE Mediator (a
server that provides authentiction and configuration information).
An architectural framework for the DVNE protocol is described in
draft-mrw-dvne-fw-00.txt (replace with reference, when available).
</t>
</section>
<section title="Definitions">
<t>
<list style="symbols">
<t>
DVNE Client: Client software running on a host or a network node
(e.g., router) that communicates with the DVNE Mediator.
</t>
<t>
DVNE Mediator: A server that implemnets DVNE and provides
configuration information and parameters to DVNE clients.
</t>
<t>
DVNE Session: A secure session between a DVNE Client and DVNE
Mediator.
</t>
</list>
</t>
</section>
<section title="DVNE Protocol Functional Overview">
<t>
DVNE Protocol (DVNEP) is a signaling protocol between a DVNE Client and DVNE Mediator to essentially perform the following functions:
<list style="symbols">
<t>
Authentication of clients
</t>
<t>
Peer discovery (locate the peer)
</t>
<t>
Address assignment to the DVNE client
</t>
<t>
Provide all parameters necessary for the two endpoints to setup a
secure VPN connection.
</t>
</list>
</t>
<t>
DVNEP transparently supports all types of NAT traversals for the end points. DVNEP does not directly setup a secure VPN connection between the end points. It does provide all parameters necessary for the end points so that they can setup the VPN connection directly. The main advantage of this approach is that all existing methods of VPN connection setup can be supported without changes.
</t>
<t>
The DVNE Client software runs on a host machine and is responsible for communicating with the DVNE Mediator. Among other functions, the DVNE Client software performs the following generic functions:
<list style="symbols">
<t>
Client startup or installation. Upon client startup, the client should be able to reach one or more DVNE Mediator.
</t>
<t>
Client cache to store data provided by the Mediator
</t>
</list>
</t>
<t>
The following is a list functions described in this document:
<list style="symbols">
<t>
Client identification:To uniquely identify a client in a specific domain. A domain represents a specific virtual network or overlay network.
</t>
<t>
Client authentication:In the first phase, the clients are authenticated using username/password mechanism.
</t>
<t>
Client Location:The clients can be located behind any type of multiple
NAT traversals
<list style="symbols">
<t>
Use standards compliant protocols like STUN, TURN and ICE to identify and locate a client behind one or more NATs.
</t>
</list>
</t>
<t>
Addressing:Each domain or virtual network in DVNE has its own independent addressing. Each client is provided with an address in the private address space in the virtual network as long as it is connected to the DVNE network. The following are supported as a part of addressing functions:
<list style="symbols">
<t>
Private address space in the virtual network
</t>
<t>
Static address or dynamic address via the DHCP server (NOT supported in phase 1)
</t>
</list>
</t>
<t>
Secure session between the client and the DVNE Mediator:Using secure credentials a session is established between a client and the DVNE Mediator. All the communication is encrypted and standard security algorithms are supported.
</t>
<t>
Peer discovery:The DVNE Mediator assists a client in locating and discovering a desired client in the same virtual network.
<list style="symbols">
<t>
Dynamic translation of client id to end points:used for determining the destination end point location or a next-hop determination
</t>
<t>
Provide a list of Virtual Network members to every client
</t>
</list>
</t>
<t>
Connection setup and release requests
<list style="symbols">
<t>
The relay of the client transport addresses and other information
between the clients.
</t>
<t>
If the clients request to establish a manual IPSEC connection, for
example, then provide the security parameters (e.g., keys, SPI) to the
clients.
</t>
</list>
</t>
</list>
</t>
</section>
<section title="Description of DVNE Protocol Operation">
<t>
This section describes the operation of the DVNE protocol at a
conceptual level.
</t>
<section title="Overview">
<t>
An example topology view of the DVNE and its components are shown in
the Figure below. This is used to illustrate various functions like
login, connection setup etc., in subsequent sections.
</t>
<t>
FIGURE TBD: Figure 1. DVNE and its components
</t>
</section>
<section title="Client Startup or Installation">
<t>
The DVNE Client software upon installation should at a minimum be
programmed to reach one of the DVNE Mediators. The DVNE Mediator
server name or IP address/Port# must be made available in the Client
Cache. In future, after successful connection to this DVNE Mediator,
the list of all other possible DVNE Mediators that this client can
reach is downloaded to the client.
</t>
<t>
The DVNE Mediator is expected to be globally addressable via public
internet. In future, we can add the capability of DVNE Mediators also
being behind firewalls or NAT.
</t>
</section>
<section title="Login">
<t>
All clients of DVNE are required to first login to one of the DVNE
Mediators. After successful login a session is open between the DVNE
client and the mediator. The session between DVNE client and mediator
is kept active as long as the client wants to have a connection to any
other client in the virtual network. The process of login involves the
following:
<list style="symbols">
<t>
Identify and authenticate the clients.The client and the mediator
perform mutual authentication
</t>
<t>
Determine the virtual network that the client belongs to
</t>
<t>
Provide the client with the latest list of VN Members that are
‘online’ in the virtual network
</t>
<t>
Provide the client with Virtual Network global data (e.g., TURN, STUN
server addresses)
</t>
</list>
</t>
</section>
<section title="Identification">
<t>
The client identity in DVNE uniquely identifies both the client and
the virtual network that the client belongs to. The client identity is
explicitly provided by the client during login to the DVNE. The client
id for example can take the form client-id@vn-id.dvne.com where
“vn-id” identifies a specific virtual network and the “client-id”
identifies a specific client. Both the client-id and vn-id are a
combination of alphanumeric characters.
</t>
</section>
<section title="Authentication">
<t>
Each client is authenticated by the DVNE mediator. In addition, the
clients initially use TLS protocol to communicate with the DVNE
Mediator and only upon successful authentication at TLS level, a
secure session is established between the client and the DVNE
Mediator. The primary goal of the TLS protocol is to provide privacy
and data integrity between two communicating applications. The TLS
protocol is layered on top of a reliable transport protocol
TCP/IP. All DVNE Protocol messages are encrypted by the TLS layer.
</t>
<t>
The following types of client authentication are supported:
</t>
<t>
<list style="symbols">
<t>
Client certificates (e.g., X.509) using PKI infrastructure (third
party trust relationship). Self signed certificates are also
supported, but the clients are authenticated via the username/password
mechanism.
</t>
<t>
Username/Password mechanism using Secure Remote Password (SRP-6) via
TLS protocol
</t>
</list>
</t>
<section title="TLS Certificate-based authentication">
<t>
The message flow for client certificate based authentication is shown
below. This is the same standard TLS message flow without any changes.
</t>
<t>
FIGURE TBD: Figure 2. TLS certificate authentication
</t>
</section>
<section title="TLS Username/Password-based Authentication">
<t>
The client can also initiate username/password based authentication
via TLS protocol using Secure Remote Password mechanism (SRP-6). The
client supplies the username parameter in the client hello
message. This indicates to the MEDIATOR that the client wishes to
perform username password authentication. The message flow for SRP
mechanism is shown below. Both sides exchange the SRP parameters
(random numbers, generator g etc.,) using the TLS:server key
exchange and TLS:client key exchange messages. The two sides then
derive the same secret key K and encrypt the TLS:finished messages
using this secret key. If the other side can decrypt the
TLS:finished successfully, it implies that both sides are in
possession of the same secret. For details of SRP mechanism, please
refer to RFC 5054.
</t>
<t>
FIGURE TBD: Figure 3. TLS username/password authentication
</t>
</section>
<section title="Fallback Authentication">
<t>
It is also possible that the MEDIATOR always initiate a client
certificate based authentication and use username/password as a
fallback mechanism. The MEDIATOR will reject the first TLS attempt
with an error code of unknown-psk-identity and in such cases, the
client can re-initiate a new TLS session using the username/password
mechanism. A typical message flow for this case is shown below.
</t>
<t>
FIGURE TBD: Figure 4. Certificate auth failure with fallback to
username/password authentication
</t>
</section>
</section>
<section title="DVNE Authentication">
<t>
DVNE client authentication is performed during LOGIN. This is in
addition to the TLS authentication. The DVNE authentication is a
mutual authentication between the Client and the Mediator. This is
based on Username/password mechanism. The client password is not sent
to the Mediator. Instead, each side performs a challenge-response
method of authentication. Each side computes a response for a given
nonce and challenges the other side to the do the same by sending
the same nonce value. When the computed response and the received
response match, the authentication is deemed successful.
</t>
<t>
The DVNE Authentication will use the MD5 hash algorithm as follows:
<list style="symbols">
<t>
Inputs:
<list style="symbols">
<t>
Username/Password
</t>
<t>
Nonce (16 Bytes)
</t>
</list>
</t>
<t>
Output:
<list style="symbols">
<t>
Response (16 Bytes)
</t>
</list>
</t>
<t>
Algorithms:
<list style="symbols">
<t>
HA1 = MD5(username:dvne authentication:password);
</t>
<t>
Response = MD5(nonce:HA1);
</t>
</list>
</t>
</list>
</t>
</section>
<section title="Addressing in Virtual Network">
<t>
Each virtual network has an independent range of IP addresses that it
can use. This address range does not collide with addresses assigned
to other virtual networks. In future, a DVNE client can only join more
than one virtual network and hence it is suggested not to use
overlapping addresses across virtual networks.
</t>
<t>
The client is assigned a Virtual Network IP address by the mediator during the LOGIN phase.
</t>
</section>
<section title="Connection Setup">
<t>
Once logged in, the DVNE clients can establish connections to other clients. To do this, the DVNE client has to send ‘Connection setup’ message to the Mediator. The Mediator will then perform the following functions:
<list style="symbols">
<t>
Validate the identifier of the destination client,
</t>
<t>
relay the transport addresses between the two clients
</t>
<t>
provide manual security association parameters (e.g., session key, SPI) to both clients. The SPI value has to be unique for a specific end node.
</t>
</list>
</t>
<t>
The clients can use all these information to setup the direct VPN
connection themselves.
</t>
</section>
<section title="VPN Connection">
<t>
The two end clients can select the type of VPN connection they wish to setup. These connections can be typically:
<list style="symbols">
<t>
IPSEC
<list style="symbols">
<t>
With IKE:In this case, the end hosts can use IKE protocol to
authenticate security credentials and then setup an IPSEC connection.
</t>
<t>
Manual IPSEC:Setup IPSEC using manual security association parameters
provided by the mediator
</t>
</list>
</t>
<t>
DTLS
</t>
</list>
</t>
</section>
</section>
<section title="Message authentication">
<t>
It is possible that a client can impersonate another client in the
messages that a client sends to a mediator. For example, a Client-A
can specify a different “FROM” field in the messages. In order to
prevent this, the client should include a “msg-auth-value” field in
the first message of every transaction initiated by the client to the
mediator. The “msg-auth-value” is computed using the username/password
of the client as specified in the “FROM” field of the request message.
</t>
<t>
The msg-auth-value is especially useful, if in future, we have to
implement “Mediator Proxy” which then forwards all the messages to a
“mediator”.
</t>
<t>
The “msg-auth-value” computation will use the MD5 hash algorithm as
follows:
<list style="symbols">
<t>
Inputs:
<list style="symbols">
<t>
Username/Password for the username specified in the “FROM” field;
</t>
</list>
</t>
<t>
Output:
<list style="symbols">
<t>
msg-auth-value (16 Bytes)
</t>
</list>
</t>
<t>
Algorithm:
<list style="symbols">
<t>
HA1 = MD5(username:”dvne message authentication”:password);
</t>
<t>
msg-auth-value = MD5(“0123456789abcdeffedcba9876543210”:HA1);
</t>
</list>
</t>
</list>
</t>
</section>
<section title="DVNE Protocol Details">
<t>
TBD.
</t>
</section>
<section title="Security Considerations">
<t>
TBD.
</t>
</section>
<section title="IANA Considerations">
<t>
TBD.
</t>
</section>
<section title="Acknowledgements">
<t>
This document was written using the xml2rfc tool described in RFC 2629
<xref target="RFC2629"/>.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
</references>
<references title="Informative References">
&rfc2629;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 04:23:26 |