One document matched: draft-mrw-dvne-prot-00.txt
Network Working Group M. Wasserman
Internet-Draft Painless Security
Intended status: Standards Track P. Nallur
Expires: April 22, 2011 Futurewei Technologies
October 19, 2010
Dynamic Virtual Network Engine (DVNE) Protocol
draft-mrw-dvne-prot-00.txt
Abstract
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.
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.
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 April 22, 2011.
Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
Wasserman & Nallur Expires April 22, 2011 [Page 1]
Internet-Draft DVNE Protocol October 2010
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.
Table of Contents
1. Requirements Terminology . . . . . . . . . . . . . . . . . . . 3
2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. DVNE Protocol Functional Overview . . . . . . . . . . . . . . 4
5. Description of DVNE Protocol Operation . . . . . . . . . . . . 5
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.2. Client Startup or Installation . . . . . . . . . . . . . . 6
5.3. Login . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.4. Identification . . . . . . . . . . . . . . . . . . . . . . 6
5.5. Authentication . . . . . . . . . . . . . . . . . . . . . . 6
5.5.1. TLS Certificate-based authentication . . . . . . . . . 7
5.5.2. TLS Username/Password-based Authentication . . . . . . 7
5.5.3. Fallback Authentication . . . . . . . . . . . . . . . 7
5.6. DVNE Authentication . . . . . . . . . . . . . . . . . . . 8
5.7. Addressing in Virtual Network . . . . . . . . . . . . . . 8
5.8. Connection Setup . . . . . . . . . . . . . . . . . . . . . 9
5.9. VPN Connection . . . . . . . . . . . . . . . . . . . . . . 9
6. Message authentication . . . . . . . . . . . . . . . . . . . . 9
7. DVNE Protocol Details . . . . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
Wasserman & Nallur Expires April 22, 2011 [Page 2]
Internet-Draft DVNE Protocol October 2010
1. Requirements Terminology
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 [RFC2119].
2. Introduction
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.
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.
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.
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).
3. Definitions
o DVNE Client: Client software running on a host or a network node
(e.g., router) that communicates with the DVNE Mediator.
o DVNE Mediator: A server that implemnets DVNE and provides
configuration information and parameters to DVNE clients.
o DVNE Session: A secure session between a DVNE Client and DVNE
Mediator.
Wasserman & Nallur Expires April 22, 2011 [Page 3]
Internet-Draft DVNE Protocol October 2010
4. DVNE Protocol Functional Overview
DVNE Protocol (DVNEP) is a signaling protocol between a DVNE Client
and DVNE Mediator to essentially perform the following functions:
o Authentication of clients
o Peer discovery (locate the peer)
o Address assignment to the DVNE client
o Provide all parameters necessary for the two endpoints to setup a
secure VPN connection.
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.
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:
o Client startup or installation. Upon client startup, the client
should be able to reach one or more DVNE Mediator.
o Client cache to store data provided by the Mediator
The following is a list functions described in this document:
o Client identification:To uniquely identify a client in a specific
domain. A domain represents a specific virtual network or overlay
network.
o Client authentication:In the first phase, the clients are
authenticated using username/password mechanism.
o Client Location:The clients can be located behind any type of
multiple NAT traversals
* Use standards compliant protocols like STUN, TURN and ICE to
identify and locate a client behind one or more NATs.
o 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
Wasserman & Nallur Expires April 22, 2011 [Page 4]
Internet-Draft DVNE Protocol October 2010
is connected to the DVNE network. The following are supported as
a part of addressing functions:
* Private address space in the virtual network
* Static address or dynamic address via the DHCP server (NOT
supported in phase 1)
o 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.
o Peer discovery:The DVNE Mediator assists a client in locating and
discovering a desired client in the same virtual network.
* Dynamic translation of client id to end points:used for
determining the destination end point location or a next-hop
determination
* Provide a list of Virtual Network members to every client
o Connection setup and release requests
* The relay of the client transport addresses and other
information between the clients.
* If the clients request to establish a manual IPSEC connection,
for example, then provide the security parameters (e.g., keys,
SPI) to the clients.
5. Description of DVNE Protocol Operation
This section describes the operation of the DVNE protocol at a
conceptual level.
5.1. Overview
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.
FIGURE TBD: Figure 1. DVNE and its components
Wasserman & Nallur Expires April 22, 2011 [Page 5]
Internet-Draft DVNE Protocol October 2010
5.2. Client Startup or Installation
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.
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.
5.3. Login
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:
o Identify and authenticate the clients.The client and the mediator
perform mutual authentication
o Determine the virtual network that the client belongs to
o Provide the client with the latest list of VN Members that are
'online' in the virtual network
o Provide the client with Virtual Network global data (e.g., TURN,
STUN server addresses)
5.4. Identification
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.
5.5. Authentication
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
Wasserman & Nallur Expires April 22, 2011 [Page 6]
Internet-Draft DVNE Protocol October 2010
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.
The following types of client authentication are supported:
o 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.
o Username/Password mechanism using Secure Remote Password (SRP-6)
via TLS protocol
5.5.1. TLS Certificate-based authentication
The message flow for client certificate based authentication is shown
below. This is the same standard TLS message flow without any
changes.
FIGURE TBD: Figure 2. TLS certificate authentication
5.5.2. TLS Username/Password-based Authentication
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.
FIGURE TBD: Figure 3. TLS username/password authentication
5.5.3. Fallback Authentication
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
Wasserman & Nallur Expires April 22, 2011 [Page 7]
Internet-Draft DVNE Protocol October 2010
mechanism. A typical message flow for this case is shown below.
FIGURE TBD: Figure 4. Certificate auth failure with fallback to
username/password authentication
5.6. DVNE Authentication
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.
The DVNE Authentication will use the MD5 hash algorithm as follows:
o Inputs:
* Username/Password
* Nonce (16 Bytes)
o Output:
* Response (16 Bytes)
o Algorithms:
* HA1 = MD5(username:dvne authentication:password);
* Response = MD5(nonce:HA1);
5.7. Addressing in Virtual Network
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.
The client is assigned a Virtual Network IP address by the mediator
during the LOGIN phase.
Wasserman & Nallur Expires April 22, 2011 [Page 8]
Internet-Draft DVNE Protocol October 2010
5.8. Connection Setup
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:
o Validate the identifier of the destination client,
o relay the transport addresses between the two clients
o 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.
The clients can use all these information to setup the direct VPN
connection themselves.
5.9. VPN Connection
The two end clients can select the type of VPN connection they wish
to setup. These connections can be typically:
o IPSEC
* With IKE:In this case, the end hosts can use IKE protocol to
authenticate security credentials and then setup an IPSEC
connection.
* Manual IPSEC:Setup IPSEC using manual security association
parameters provided by the mediator
o DTLS
6. Message authentication
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.
The msg-auth-value is especially useful, if in future, we have to
implement "Mediator Proxy" which then forwards all the messages to a
Wasserman & Nallur Expires April 22, 2011 [Page 9]
Internet-Draft DVNE Protocol October 2010
"mediator".
The "msg-auth-value" computation will use the MD5 hash algorithm as
follows:
o Inputs:
* Username/Password for the username specified in the "FROM"
field;
o Output:
* msg-auth-value (16 Bytes)
o Algorithm:
* HA1 = MD5(username:"dvne message authentication":password);
* msg-auth-value = MD5("0123456789abcdeffedcba9876543210":HA1);
7. DVNE Protocol Details
TBD.
8. Security Considerations
TBD.
9. IANA Considerations
TBD.
10. Acknowledgements
This document was written using the xml2rfc tool described in RFC
2629 [RFC2629].
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Wasserman & Nallur Expires April 22, 2011 [Page 10]
Internet-Draft DVNE Protocol October 2010
11.2. Informative References
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
Authors' Addresses
Margaret Wasserman
Painless Security
356 Abbott Street
North Andover, MA 01845
USA
Phone: +1 781 405 7464
Email: mrw@painless-security.com
URI: http://www.painless-security.com
Padmanabha Nallur
Futurewei Technologies
3255-4, Scott Blvd
Santa Clara, California
USA
Email: pnallur@huawei.com
Wasserman & Nallur Expires April 22, 2011 [Page 11]
| PAFTECH AB 2003-2026 | 2026-04-24 03:03:38 |