Adding upstream version 3.2.5+dfsg.upstream/3.2.5+dfsgupstream

Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>

1 files changed, 81 insertions, 16 deletions

diff --git a/raddb/clients.conf b/raddb/clients.conf
index 60f9f4b..5f39ff1 100644
--- a/raddb/clients.conf
+++ b/raddb/clients.conf
@@ -9,6 +9,25 @@
 #  Define RADIUS clients (usually a NAS, Access Point, etc.).
 
 #
+#  There are a number of security practices which are critical in the
+#  modern era.
+#
+#  * don't use RADIUS/UDP or RADIUS/TCP over the Internet.  Use RADIUS/TLS.
+#
+#  * If you do send RADIUS over UDP or TCP, don't send MS-CHAPv2.
+#    Anyone who can see the MS-CHAPv2 data can crack it in milliseconds.
+#
+#  * use the "radsecret" program to generate secrets.  It uses Perl (sorry).
+#    Every time you run it, it will generate a new strong secret.
+#
+#  * don't create shared secrets yourself.  Anything you create is likely to
+#    be in a "cracking" dictionary, and will allow a hobbyist attacker
+#    to crack the shared secret in a few minutes.
+#
+#  * Don't trust anyone who tells you to ignore the above recommendations.
+#
+
+#
 #  Defines a RADIUS client.
 #
 #  '127.0.0.1' is another name for 'localhost'.  It is enabled by default,
@@ -82,17 +101,33 @@ client localhost {
 	#  Quotation marks can be entered by escaping them,
 	#	e.g. "foo\"bar"
 	#
-	#  A note on security:  The security of the RADIUS protocol
+	#  A note on security: The security of the RADIUS protocol
 	#  depends COMPLETELY on this secret!  We recommend using a
-	#  shared secret that is composed of:
+	#  shared secret that at LEAST 16 characters long.  It should
+	#  preferably be 32 characters in length.  The secret MUST be
+	#  random, and should not be words, phrase, or anything else
+	#  that is recognisable.
+	#
+	#  Computing power has increased enormously since RADIUS was
+	#  first defined.  A hobbyist with a high-end GPU can try ALL
+	#  of the 8-character shared secrets in about a day.  The
+	#  security of shared secrets increases MUCH more with the
+	#  length of the shared secret, than with number of different
+	#  characters used in it.  So don't bother trying to use
+	#  "special characters" or anything else in an attempt to get
+	#  un-guessable secrets.  Instead, just get data from a secure
+	#  random number generator, and use that.
+	#
+	#  You should create shared secrets using a method like this:
+	#
+	#	dd if=/dev/random bs=1 count=24 | base64
 	#
-	#	upper case letters
-	#	lower case letters
-	#	numbers
+	#  This process will give output which takes 24 random bytes,
+	#  and converts them to 32 characters of ASCII.  The output
+	#  should be accepted by all RADIUS clients.
 	#
-	#  And is at LEAST 8 characters long, preferably 16 characters in
-	#  length.  The secret MUST be random, and should not be words,
-	#  phrase, or anything else that is recognisable.
+	#  You should NOT create shared secrets by hand.  They will
+	#  not be random.  They will will be trivial to crack.
 	#
 	#  The default secret below is only for testing, and should
 	#  not be used in any real environment.
@@ -100,15 +135,45 @@ client localhost {
 	secret = testing123
 
 	#
-	#  Old-style clients do not send a Message-Authenticator
-	#  in an Access-Request.  RFC 5080 suggests that all clients
-	#  SHOULD include it in an Access-Request.  The configuration
-	#  item below allows the server to require it.  If a client
-	#  is required to include a Message-Authenticator and it does
-	#  not, then the packet will be silently discarded.
+	#  The global configuration "security.require_message_authenticator"
+	#  flag sets the default for all clients.  That default can be
+	#  over-ridden here, by setting it to a value.  If no value is set,
+	#  then the default from the "radiusd.conf" file is used.
+	#
+	#  See that file for full documentation on the flag, along
+	#  with allowed values and meanings.
+	#
+	#  This flag exists solely for legacy clients which do not send
+	#  Message-Authenticator in all Access-Request packets.  We do not
+	#  recommend setting it to "no".
+	#
+	#  The number one way to protect yourself from the BlastRADIUS
+	#  attack is to update all RADIUS servers, and then set this
+	#  flag to "yes".  If all RADIUS servers are updated, and if
+	#  all of them have this flag set to "yes" for all clients,
+	#  then your network is safe.  You can then upgrade the
+	#  clients when it is convenient, instead of rushing the
+	#  upgrades.
+	#
+	#  allowed values: yes, no, auto
+	#
+#	require_message_authenticator = no
+
+	#
+	#  The global configuration "security.limit_proxy_state"
+	#  flag sets the default for all clients.  That default can be
+	#  over-ridden here, by setting it to "no".
+	#
+	#  See that file for full documentation on the flag, along
+	#  with allowed values,and meanings.
+	#
+	#  This flag exists solely for legacy clients which do not send
+	#  Message-Authenticator in all Access-Request packets.  We do not
+	#  recommend setting it to "no".
+	#
+	#  allowed values: yes, no, auto
 	#
-	#  allowed values: yes, no
-	require_message_authenticator = no
+#	limit_proxy_state = yes
 
 	#
 	#  The short name is used as an alias for the fully qualified