Merge remote branch SVN 2.1 into the git tree

Hopefully the last SVN merge we need to do, as these merges are getting
more and more difficult.  Most of the files had minor changes, but due to
the CRLF unification patch (commit 6b2883a637fe73492) we got an increased
number of conflicts.  In addition inclusion of IPv6 support makes the
creates a lot of merge issues in route.c and socket.c

This merge also reverts commit 7c18c6353904f8c6e7 which merged
add_bypass_address() into add_host_route_if_nonlocal().  However the SVN
tree began to use add_bypass_address() another place, where at first glance
it did not be appropriate to use add_host_route_if_nonlocal().

This merge has gone through a 'make check' without any errors, but have
not been tested more thoroughly yet.

Conflicts:
	ChangeLog
	INSTALL
	INSTALL-win32.txt
	Makefile.am
	acinclude.m4
	base64.c
	buffer.c
	buffer.h
	common.h
	configure.ac
	contrib/pull-resolv-conf/client.down
	contrib/pull-resolv-conf/client.up
	crypto.c
	cryptoapi.c
	easy-rsa/2.0/Makefile
	easy-rsa/2.0/README
	easy-rsa/2.0/build-ca
	easy-rsa/2.0/build-dh
	easy-rsa/2.0/build-inter
	easy-rsa/2.0/build-key
	easy-rsa/2.0/build-key-pass
	easy-rsa/2.0/build-key-pkcs12
	easy-rsa/2.0/build-key-server
	easy-rsa/2.0/build-req
	easy-rsa/2.0/build-req-pass
	easy-rsa/2.0/clean-all
	easy-rsa/2.0/inherit-inter
	easy-rsa/2.0/list-crl
	easy-rsa/2.0/pkitool
	easy-rsa/2.0/revoke-full
	easy-rsa/2.0/sign-req
	easy-rsa/2.0/vars
	easy-rsa/2.0/whichopensslcnf
	easy-rsa/Windows/build-ca-pass.bat
	easy-rsa/Windows/build-key-pass.bat
	easy-rsa/Windows/build-key-server-pass.bat
	easy-rsa/Windows/init-config.bat
	easy-rsa/Windows/vars.bat.sample
	error.c
	error.h
	forward.c
	helper.c
	httpdigest.c
	httpdigest.h
	ieproxy.c
	init.c
	init.h
	install-win32/Makefile.am
	install-win32/makeopenvpn
	install-win32/openssl/openssl097.patch
	install-win32/openssl/openssl098.patch
	install-win32/openvpn.nsi
	list.c
	list.h
	manage.c
	manage.h
	management/management-notes.txt
	mbuf.c
	mbuf.h
	misc.c
	misc.h
	mroute.c
	mroute.h
	msvc/autodefs.h.in
	msvc/config.py
	msvc/msvc.mak
	mtcp.c
	mudp.c
	multi.c
	multi.h
	occ.c
	openvpn-plugin.h
	openvpn.8
	openvpn.h
	options.c
	options.h
	otime.c
	otime.h
	perf.c
	pf.c
	ping.c
	pkcs11.c
	plugin.c
	plugin.h
	plugin/auth-pam/README
	plugin/auth-pam/auth-pam.c
	pool.c
	pool.h
	proto.h
	proxy.c
	ps.c
	push.c
	reliable.c
	route.c
	route.h
	sample-config-files/firewall.sh
	sample-scripts/bridge-start
	sample-scripts/bridge-stop
	sample-scripts/openvpn.init
	sample-scripts/verify-cn
	schedule.c
	schedule.h
	service-win32/openvpnserv.c
	sig.c
	socket.c
	socket.h
	socks.c
	socks.h
	ssl.c
	ssl.h
	status.c
	syshead.h
	tap-win32/SOURCES.in
	tap-win32/common.h
	tap-win32/proto.h
	tap-win32/tapdrvr.c
	tap-win32/types.h
	tun.c
	tun.h
	version.m4
	win/autodefs.h.in
	win/build.py
	win/build_all.py
	win/build_ddk.py
	win/build_exe.py
	win/config.py
	win/config_all.py
	win/config_tap.py
	win/config_ti.py
	win/js.py
	win/make_dist.py
	win/msvc.mak.in
	win/settings.in
	win/show.py
	win/sign.py
	win/tap_span.py
	win/wb.py
	win32.c
	win32.h

Signed-off-by: David Sommerseth <davids@redhat.com>
Reviewed-by: Gert Doering <gert@greenie.muc.de>
Reviewed-by: James Yonan <james@openvpn.net>
Reviewed-by: Adriaan de Jong <dejong@fox-it.com>

1 files changed, 142 insertions, 0 deletions

diff --git a/management/management-notes.txt b/management/management-notes.txt
index 1f4cbd0..785eb88 100644
--- a/management/management-notes.txt
+++ b/management/management-notes.txt
@@ -687,6 +687,38 @@ the 10.0.0.0/8 netblock is allowed: 10.10.0.1.  Also, the client
 may not interact with external IP addresses using an "unknown"
 protocol (i.e. one that is not IPv4 or ARP).
 
+COMMAND -- remote  (OpenVPN AS 2.1.5/OpenVPN 2.3 or higher)
+--------------------------------------------
+
+Provide remote host/port in response to a >REMOTE notification
+(client only).  Requires that the --management-query-remote
+directive is used.
+
+  remote ACTION [HOST PORT]
+
+The "remote" command should only be given in response to a >REMOTE
+notification.  For example, the following >REMOTE notification
+indicates that the client config file would ordinarily connect
+to vpn.example.com port 1194 (UDP):
+
+  >REMOTE:vpn.example.com,1194,udp
+
+Now, suppose we want to override the host and port, connecting
+instead to vpn.otherexample.com port 1234.  After receiving
+the above notification, use this command:
+
+  remote MOD vpn.otherexample.com 1234
+
+To accept the same host and port as the client would ordinarily
+have connected to, use this command:
+
+  remote ACCEPT
+
+To skip the current connection entry and advance to the next one,
+use this command:
+
+  remote SKIP
+
 OUTPUT FORMAT
 -------------
 
@@ -836,3 +868,113 @@ mappings, when not in single quotations:
          interpret it as enclosing a parameter.
 \[SPACE] Pass a literal space or tab character, don't
          interpret it as a parameter delimiter.
+
+Challenge/Response Protocol
+---------------------------
+
+The OpenVPN Challenge/Response Protocol allows an OpenVPN server to
+generate challenge questions that are shown to the user, and to see
+the user's responses to those challenges.  Based on the responses, the
+server can allow or deny access.
+
+In this way, the OpenVPN Challenge/Response Protocol can be used
+to implement multi-factor authentication.  Two different
+variations on the challenge/response protocol are supported: the
+"Dynamic" and "Static" protocols.
+
+The basic idea of Challenge/Response is that the user must enter an
+additional piece of information, in addition to the username and
+password, to successfully authenticate.  Normally, this information
+is used to prove that the user posesses a certain key-like device
+such as cryptographic token or a particular mobile phone.
+
+Dynamic protocol:
+
+The OpenVPN dynamic challenge/response protocol works by returning
+a specially formatted error message after initial successful
+authentication.  This error message contains the challenge question,
+and is formatted as such:
+
+  CRV1:<flags>:<state_id>:<username_base64>:<challenge_text>
+
+flags: a series of optional, comma-separated flags:
+ E : echo the response when the user types it
+ R : a response is required
+
+state_id: an opaque string that should be returned to the server
+ along with the response.
+
+username_base64 : the username formatted as base64
+
+challenge_text : the challenge text to be shown to the user
+
+Example challenge:
+
+  CRV1:R,E:Om01u7Fh4LrGBS7uh0SWmzwabUiGiW6l:Y3Ix:Please enter token PIN
+
+After showing the challenge_text and getting a response from the user
+(if R flag is specified), the client should submit the following
+auth creds back to the OpenVPN server:
+
+Username: [username decoded from username_base64]
+Password: CRV1::<state_id>::<response_text>
+
+Where state_id is taken from the challenge request and response_text
+is what the user entered in response to the challenge_text.
+If the R flag is not present, response_text may be the empty
+string.
+
+Example response (suppose the user enters "8675309" for the token PIN):
+
+  Username: cr1 ("Y3Ix" base64 decoded)
+  Password: CRV1::Om01u7Fh4LrGBS7uh0SWmzwabUiGiW6l::8675309
+
+Static protocol:
+
+The static protocol differs from the dynamic protocol in that the
+challenge question and response field is given to the user in the
+initial username/password dialog, and the username, password, and
+response are delivered back to the server in a single transaction.
+
+The "static-challenge" directive is used to give the challenge text
+to OpenVPN and indicate whether or not the response should be echoed.
+
+When the "static-challenge" directive is used, the management
+interface will respond as such when credentials are needed:
+
+  >PASSWORD:Need 'Auth' username/password SC:<ECHO>,<TEXT>
+
+  ECHO: "1" if response should be echoed, "0" to not echo
+  TEXT: challenge text that should be shown to the user to
+      facilitate their response
+
+For example:
+
+  >PASSWORD:Need 'Auth' username/password SC:1,Please enter token PIN
+
+The above notification indicates that OpenVPN needs a --auth-user-pass
+password plus a response to a static challenge ("Please enter token PIN").
+The "1" after the "SC:" indicates that the response should be echoed.
+
+The management interface client in this case should add the static
+challenge text to the auth dialog followed by a field for the user to
+enter a response.  Then the client should pack the password and response
+together into an encoded password:
+
+  username "Auth" foo
+  password "Auth" "SCRV1:<BASE64_PASSWORD>:<BASE64_RESPONSE>"
+
+For example, if the user entered "bar" as the password and 8675309
+as the PIN, the following management interface commands should be
+issued:
+
+  username "Auth" foo
+  password "Auth" "SCRV1:Zm9v:ODY3NTMwOQ=="
+
+Client-side support for challenge/response protocol:
+
+Currently, the Access Server client and standalone OpenVPN
+client support both static and dynamic challenge/response
+protocols.  However, any OpenVPN client UI that drives OpenVPN
+via the management interface needs to add explicit support
+for the challenge/response protocol.