[Openvpn-users] New Username/Password Authentication Mode

[James Yonan]

This idea was proposed a few months ago, and I initially thought it would be a
post-2.0 thing, but it turned out to be easier than I thought to implement, so
you will find it in the just-released 2.0-beta12.

Some background: Since OpenVPN 1.0, TLS mode always involved the client and
server authenticating each other using a certificate/private key pair. While
this provides good security, it is not strictly necessary that the client
authenticate itself to the server using certificates. In many cases it might
be more convenient to use "Asymmetrical Authentication" where only the the
server authenticates itself to the client with a signed certificate while the
client authenticates itself to the server with a username/password
(incidentally, this authentication model is the basis for most of the
e-commerce and online finance sites on the web).

In some cases it might also be desirable to use double client-side
authentication, i.e. have the client present a certificate to the server AND a
username/password.

All of these options are now possible, and the server config can specify which
combination is required: username/password without a client certificate,
username/password plus client certificate, or client certificate alone.

To use:

* Add --auth-user-pass option to client config. Add a optional filename
argument (user/pass on two lines in the file) or omit for console prompt.

* Once you've added --auth-user-pass to the client config, you no longer need
to provide --cert and --key files, however you should still include them if
the server you are connecting to requires double authentication.

* In the server config, add --auth-user-pass-verify ./script. OpenVPN will
call this script on the server side with the username and password which were
provided by the client. The user/pass will be saved in the environment under
the "username" and "password" variable names. The script then returns success
(0) if it approves of the username/password or (1) if it disapproves. On
approval the tunnel will begin passing data immediately. On disapproval, the
server will send an "Auth Failure" message back to the client which will be
shown in the log file and cause the client to exit.

* The server config has two optional flags. --client-cert-not-required tells
the server that clients don't need to present a certificate, i.e. a
username/password by itself is sufficient. By default, if
--auth-user-pass-verify is used without --client-cert-not-required, then
double authentication will be required, i.e. the client must present a cert
AND username/password.

* The other optional server-side flag is --username-as-common-name. This
tells OpenVPN, on successful authentication using a username/password, to use
the username as the "common name", in order to identify the client in
log/status file listings or when --client-config-dir is used.

As you can see, this is a basic infrastructure which still requires a script
plug-in on the server side to perform the username/password verification.

If you download the tarball, you will find a perl script in
sample-scripts/auth-pam.pl which will do PAM authentication on a *nix system.
You can use this script along with the --auth-user-pass-verify directive on
the server.

It was pretty cool to run it for the first time, I was actually able to start
a VPN to my server without any client-side certificate, using only my standard
Linux login username/password.

This feature also creates the possibility of constructing "Anonymous VPNs".
Suppose you want to create a public access VPN which allows anyone to connect
using a standard config file. Just use the "true" shell command as your
--auth-user-pass-verify script.

For more info, see the man page.

James

[Leonard Isham]

Post by James Yonan
This idea was proposed a few months ago, and I initially thought it would be a
post-2.0 thing, but it turned out to be easier than I thought to implement, so
you will find it in the just-released 2.0-beta12.
Some background: Since OpenVPN 1.0, TLS mode always involved the client and
server authenticating each other using a certificate/private key pair. While
this provides good security, it is not strictly necessary that the client
authenticate itself to the server using certificates. In many cases it might
be more convenient to use "Asymmetrical Authentication" where only the the
server authenticates itself to the client with a signed certificate while the
client authenticates itself to the server with a username/password
(incidentally, this authentication model is the basis for most of the
e-commerce and online finance sites on the web).

I would caution everyone to carefully consider the security risks of
using server certificates only. Consider that a e-commerce server is
designed to provide protection to the client in their financial
transaction and this is implemented to certify that they are
correcting to the intended server.

With OpenVPN IMHO you would be letting an computer ans users(s) access
to your network based only on a password and ID. You loose the
computer or user "certification" that they are who they claim to be.
Additionally this might bypass and IDS or firewall configuration in
place.

Now if you implement both certificates and ID/password you have
increased security and lowered the risk of the wrong person entering
your network.

[Damir Dezeljin]

Hi.


Is it posible on Windows OpenVPN client to use the CA, cert and key files
from Windows Certificate Store by somehow specifying the common name of
the certificate or to even better to detect it automatically?
If no, is there any plan to implement it?


Is it posible to somehow specify the key password in config file or in any
other manner? I would like to avoid distributing non password protected
certificates. I know that if the password is stored in a file it is nearly
the same as distributing certificates without password. On other hand I
know that my users may in some circustances lose the certificate file
during transportation (yeh ... I have to live with it :) ), whiles their
passwords are usualy safe (username / password client authentication is
not enough for my specific need).

Best regards,
Dezo

[James Yonan]

Post by Damir Dezeljin
Hi.
Is it posible on Windows OpenVPN client to use the CA, cert and key files
from Windows Certificate Store by somehow specifying the common name of
the certificate or to even better to detect it automatically?
If no, is there any plan to implement it?

Interestingly enough, a patch has been submitted on openvpn-devel to do
exactly this, however it is currently held up from being merged because it
requires MSVC to build.

James

[Jon Bendtsen]

Den 18. okt 2004, kl. 8:48, skrev James Yonan:

[cut]

Post by James Yonan
* In the server config, add --auth-user-pass-verify ./script. OpenVPN will
call this script on the server side with the username and password which were
provided by the client. The user/pass will be saved in the
environment under
the "username" and "password" variable names. The script then returns success
(0) if it approves of the username/password or (1) if it disapproves.
On
approval the tunnel will begin passing data immediately. On
disapproval, the
server will send an "Auth Failure" message back to the client which will be
shown in the log file and cause the client to exit.

I've just run into ntlm_auth from samba, that can do authentication
against a
windows domain.
http://de.samba.org/samba/docs/man/ntlm_auth.1.html
This means that the above script can verify against windows.


[cut]

Post by James Yonan
If you download the tarball, you will find a perl script in
sample-scripts/auth-pam.pl which will do PAM authentication on a *nix system.

However, this is not the only option one has. Using winbind and
especially
pam_winbind.so from samba, one can do pam authentication against a
windows domain. This script asks the login service, which means the
login
file in /etc/pam.d/, or lines starting with login in /etc/pam.conf. It
might be
smart to create a file called openvpn in /etc/pam.d/ and change the
service
name in the above perl script. If you run multiple openvpn tunnels you
could
possibly use windows auth for one, and /etc/passwd+shadow auth for the
other. Or ...

If you use pam_winbind.so, you have to start the username with the
domain
name, followed by a single backslash, \, character, and then the
username.
ntlm_auth can be told which domain to ask, i dont think pam_winbind.so
can
do that.


A 3. possibility is to run openvpn as a service with a certificate but
not ask for
any passphrase. Then because the tunnel is up you can do a regularly
windows
domain logon. However, a sufficient skilled attacker can easily bypass
this and
use the certificate alone to gain access, so be careful if you use this
option.

It may be possible to store the certificate on a usb flash device, or
some other
device made particularly for storing certificates. Beta14 may allow
this, but still,
anyone getting their hands on such a usb device could possibly use this
device
to connect to the openvpn server as a trusted user.



Security people generally talks about 3 parts in an authentication that
is needed
to be secure. These parts are:
1) Something you know password/passphrase, ... very easy to change and
replace.
2) Something you have a certificate, a physical key, ... easy to change
and replace
3) Something you are biometrical, fingerprints, iris... once broken
VERY hard to change

Please, DO NOT TRUST 3, aka biometrical alone, and consider not to
trust it at all. Reasons are:
1) how do you change your fingerprint/iris?
2) you leave your fingerprints everywhere
3) fingerprints are already broken by several people using: vax, some
soft candy, ...
3b) contact lenses could be made to resemble your eyes
4) biometrical scanning will usually work even if body part has been
detached from body
4b) if Osama needs your eye to access the parking basement under a
building he wants to
blow up, and you dont want to help him, he will probably remove your
eye from your
skull, and possibly leave you blinded, or dead. Since he does not know
which eye, he
will take both eyes. Fingerprints? cut off all fingers.

So, are you sure you want to use biometrical scanning at all for
security?



JonB

[Peter 'Luna' Runestig]

Post by Jon Bendtsen
4) biometrical scanning will usually work even if body part has been
detached from body

No, dead body parts don't work (only in "Minority Report").

[Jon Bendtsen]

Post by Peter 'Luna' Runestig

Post by Jon Bendtsen
4) biometrical scanning will usually work even if body part has been
detached from body

No, dead body parts don't work (only in "Minority Report").

Are you saying that when a finger is cut off that the fingerprint
changes
(within a reasonable time limit)
I dont believe it does within a few hours, and if you keep it in the
right conditions, then it could last days. Enough to fool the system



JonB

[Charles Duffy]

Post by Jon Bendtsen
Are you saying that when a finger is cut off that the fingerprint
changes (within a reasonable time limit)

Retinal scanners, at least, look for signs of bloodflow and movement
(which is constantly taking place in a living eye). I'd expect that modern
fingerprint scanners would be entirely capable of doing something similar.

Personally, my concerns wrt biometric authentication have more to
do with equipment tampering to enable replay attacks (by spoofing sensor
output).

[Jason Haar]

Post by Jon Bendtsen

Post by Peter 'Luna' Runestig
No, dead body parts don't work (only in "Minority Report").

Are you saying that when a finger is cut off that the fingerprint
changes

Ga! Sorry this is so off-topic - but you've hit a sore point with me WRT
biometrics.

There's all this talk about how wonderful the "new, improved" systems are
nowadays - how they can distinguish dead body bits from live.

..and yet they all forget the bleeding obvious - if you are willing to kill
- why didn't you just put the gun to their head AND MAKE THEM DO ALL THE
HARD WORK FOR YOU.

Why bother killing and maiming when the threat of violence does a better job?

[Jon Bendtsen]

Post by Jason Haar

Post by Jon Bendtsen

Post by Peter 'Luna' Runestig
No, dead body parts don't work (only in "Minority Report").

Are you saying that when a finger is cut off that the fingerprint
changes

Ga! Sorry this is so off-topic - but you've hit a sore point with me WRT
biometrics.
There's all this talk about how wonderful the "new, improved" systems are
nowadays - how they can distinguish dead body bits from live.
..and yet they all forget the bleeding obvious - if you are willing to kill
- why didn't you just put the gun to their head AND MAKE THEM DO ALL THE
HARD WORK FOR YOU.

Because it is MUCH easier to control a cut off finger than a finger
that is
still attached to it's body.

Post by Jason Haar
Why bother killing and maiming when the threat of violence does a better job?

Someone might see you, your gun, and the victim. If they only see you,
and you
appear to use the normal authentication, they will not wonder when you
access
a restricted area.

But now we are getting way too off topic. I'm sorry i brought this up.



JonB

[Jon Bendtsen]

Den 18. okt 2004, kl. 8:48, skrev James Yonan:

[cut]

Post by James Yonan
* In the server config, add --auth-user-pass-verify ./script. OpenVPN will
call this script on the server side with the username and password which were
provided by the client. The user/pass will be saved in the
environment under
the "username" and "password" variable names. The script then returns success
(0) if it approves of the username/password or (1) if it disapproves.
On
approval the tunnel will begin passing data immediately. On
disapproval, the
server will send an "Auth Failure" message back to the client which will be
shown in the log file and cause the client to exit.

Here follows 1 bash and 1 expect scripts that can be used with the above
OpenVPN option. You'll probably have to modify the host parameter.

The scripts uses expect to control a ssh session to the remote host.
This
authenticates the user to the remote host in a secure way. Usually this
means
that the remote host is authenticated against users in /etc/passwd, but
the
remote host can use other ways to authenticate ssh logins, which could
be
windows, ldap, ... If you use windows you might as well use
pam_winbind.so
but you might not want to run more services at your firewall?

aragorn:~# cat auth.sh
#!/bin/bash

host="frodo"

./auth.exp $host $username $password >> /dev/null
if [ $? -ne 0 ]; then
echo "exit 1"
else
echo "exit 0"
fi

aragorn:~# cat auth.exp
#!/usr/bin/expect -f
#
# This Expect script was generated by autoexpect on Thu Oct 21 20:25:31
2004
# Expect and autoexpect were both written by Don Libes, NIST.
#
# Note that autoexpect does not guarantee a working script. It
# necessarily has to guess about certain things. Two reasons a script
# might fail are:
#
# 1) timing - A surprising number of programs (rn, ksh, zsh, telnet,
# etc.) and devices discard or ignore keystrokes that arrive "too
# quickly" after prompts. If you find your new script hanging up at
# one spot, try adding a short sleep just before the previous send.
# Setting "force_conservative" to 1 (see below) makes Expect do this
# automatically - pausing briefly before sending each character. This
# pacifies every program I know of. The -c flag makes the script do
# this in the first place. The -C flag allows you to define a
# character to toggle this mode off and on.

set force_conservative 0 ;# set to 1 to force conservative mode even if
;# script wasn't run conservatively originally
if {$force_conservative} {
set send_slow {1 .1}
proc send {ignore arg} {
sleep .1
exp_send -s -- $arg
}
}

#
# 2) differing output - Some programs produce different output each time
# they run. The "date" command is an obvious example. Another is
# ftp, if it produces throughput statistics at the end of a file
# transfer. If this causes a problem, delete these patterns or replace
# them with wildcards. An alternative is to use the -p flag (for
# "prompt") which makes Expect only look for the last line of output
# (i.e., the prompt). The -P flag allows you to define a character to
# toggle this mode off and on.
#
# Read the man page for more info.
#
# -Don


set timeout 2
set host [lindex $argv 0]
set username [lindex $argv 1]
set password [lindex $argv 2]

spawn ssh $username@$host
match_max 100000
expect "password:"
send -- "$password\r"
expect {
"Linux $host" "exit 0"
"Permission denied" "exit 1"
}
exit 1
aragorn:~#



timeout is because if the host doesnt answer, we dont want to wait too
long time before giving up.
$argv 0 is $1 in a regular shell script, $arvg 1 is $2...
"Linux $host" is part of the output i get with a normal login
"Permission denied" is what i get with a wrong password
the last exit 1 is it it times out.

The ssh tunnel is closed nicely, so you dont keep it open.




JonB

[James Yonan]

Post by Jon Bendtsen
[cut]

Post by James Yonan
* In the server config, add --auth-user-pass-verify ./script. OpenVPN will
call this script on the server side with the username and password which were
provided by the client. The user/pass will be saved in the
environment under
the "username" and "password" variable names. The script then returns success
(0) if it approves of the username/password or (1) if it disapproves.
On
approval the tunnel will begin passing data immediately. On
disapproval, the
server will send an "Auth Failure" message back to the client which will be
shown in the log file and cause the client to exit.

Here follows 1 bash and 1 expect scripts that can be used with the above
OpenVPN option. You'll probably have to modify the host parameter.
The scripts uses expect to control a ssh session to the remote host.
This
authenticates the user to the remote host in a secure way. Usually this
means
that the remote host is authenticated against users in /etc/passwd, but
the
remote host can use other ways to authenticate ssh logins, which could
be
windows, ldap, ... If you use windows you might as well use
pam_winbind.so
but you might not want to run more services at your firewall?
aragorn:~# cat auth.sh
#!/bin/bash
host="frodo"
./auth.exp $host $username $password >> /dev/null

Watch out here. You want to keep $password at arms length from the
shell's tendency to want to parse (or even god forbid eval) passed command
line vars.

For example, if someone entered their password with a space, it would
expand to 2 parms passed to ./auth.exp.

You can fix this by putting double quotes around $username and $password.

Even better would be to have the expect script (if possible), reference
$username and $password directly from the environment rather than passing
as command line vars.

James

Post by Jon Bendtsen
if [ $? -ne 0 ]; then
echo "exit 1"
else
echo "exit 0"
fi
aragorn:~# cat auth.exp
#!/usr/bin/expect -f
#
# This Expect script was generated by autoexpect on Thu Oct 21 20:25:31
2004
# Expect and autoexpect were both written by Don Libes, NIST.
#
# Note that autoexpect does not guarantee a working script. It
# necessarily has to guess about certain things. Two reasons a script
#
# 1) timing - A surprising number of programs (rn, ksh, zsh, telnet,
# etc.) and devices discard or ignore keystrokes that arrive "too
# quickly" after prompts. If you find your new script hanging up at
# one spot, try adding a short sleep just before the previous send.
# Setting "force_conservative" to 1 (see below) makes Expect do this
# automatically - pausing briefly before sending each character. This
# pacifies every program I know of. The -c flag makes the script do
# this in the first place. The -C flag allows you to define a
# character to toggle this mode off and on.
set force_conservative 0 ;# set to 1 to force conservative mode even if
;# script wasn't run conservatively originally
if {$force_conservative} {
set send_slow {1 .1}
proc send {ignore arg} {
sleep .1
exp_send -s -- $arg
}
}
#
# 2) differing output - Some programs produce different output each time
# they run. The "date" command is an obvious example. Another is
# ftp, if it produces throughput statistics at the end of a file
# transfer. If this causes a problem, delete these patterns or replace
# them with wildcards. An alternative is to use the -p flag (for
# "prompt") which makes Expect only look for the last line of output
# (i.e., the prompt). The -P flag allows you to define a character to
# toggle this mode off and on.
#
# Read the man page for more info.
#
# -Don
set timeout 2
set host [lindex $argv 0]
set username [lindex $argv 1]
set password [lindex $argv 2]
match_max 100000
expect "password:"
send -- "$password\r"
expect {
"Linux $host" "exit 0"
"Permission denied" "exit 1"
}
exit 1
aragorn:~#
timeout is because if the host doesnt answer, we dont want to wait too
long time before giving up.
$argv 0 is $1 in a regular shell script, $arvg 1 is $2...
"Linux $host" is part of the output i get with a normal login
"Permission denied" is what i get with a wrong password
the last exit 1 is it it times out.
The ssh tunnel is closed nicely, so you dont keep it open.
JonB
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Openvpn-users mailing list
https://lists.sourceforge.net/lists/listinfo/openvpn-users

[Jon Bendtsen]

[cut]

Post by James Yonan

Post by Jon Bendtsen
./auth.exp $host $username $password >> /dev/null

Watch out here. You want to keep $password at arms length from the
shell's tendency to want to parse (or even god forbid eval) passed command
line vars.

you're right, and i even know this. OOOOPS :/

Post by James Yonan
For example, if someone entered their password with a space, it would
expand to 2 parms passed to ./auth.exp.
You can fix this by putting double quotes around $username and
$password.
Even better would be to have the expect script (if possible), reference
$username and $password directly from the environment rather than passing
as command line vars.

yes, it would. However i dont know if one can do that, because i only
started
using expect yesterday ,-p



JonB

[George Ross]

Post by James Yonan
All of these options are now possible, and the server config can specify which
combination is required: username/password without a client certificate,
username/password plus client certificate, or client certificate alone.

Am I right in thinking that only exactly one of those is (currently?)
possible? Is there any way to accept EITHER username/password without a
client certificate OR client certificate alone?

[James Yonan]

Post by George Ross

Post by James Yonan
All of these options are now possible, and the server config can specify which
combination is required: username/password without a client certificate,
username/password plus client certificate, or client certificate alone.

Am I right in thinking that only exactly one of those is (currently?)
possible?

Yes, currently only one method is possible at a time.

Post by George Ross
Is there any way to accept EITHER username/password without a
client certificate OR client certificate alone?

No, not currently.

James