Date: Wed, 1 Nov 2006 16:11:40 GMT From: David Wood<david@wood2.org.uk> To: freebsd-gnats-submit@FreeBSD.org Subject: ports/105025: [maintainer-update] Remove unnecessary patch files/patch-ab from net/freeradius Message-ID: <200611011611.kA1GBeAH086735@www.freebsd.org> Resent-Message-ID: <200611011620.kA1GKENK018081@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 105025
>Category: ports
>Synopsis: [maintainer-update] Remove unnecessary patch files/patch-ab from net/freeradius
>Confidential: no
>Severity: non-critical
>Priority: low
>Responsible: freebsd-ports-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: maintainer-update
>Submitter-Id: current-users
>Arrival-Date: Wed Nov 01 16:20:11 GMT 2006
>Closed-Date:
>Last-Modified:
>Originator: David Wood
>Release: FreeBSD 6.1-RELEASE-p10 i386
>Organization:
>Environment:
FreeBSD titanium.wood2.org.uk 6.1-RELEASE-p10 FreeBSD 6.1-RELEASE-p10 #0: Fri Oct 6 10:56:46 BST 2006 david@titanium.wood2.org.uk:/usr/obj/usr/src/sys/TITANIUM i386
>Description:
The functionality previously forced by files/patch-ab is now available using the FreeRADIUS with_ntdomain_hack = yes configuration option within mschap { }. files/patch-ab is therefore being removed. /usr/ports/UPDATED needs to carry a warning about the change in functionality, though it is expected to affect only a minority of users.
This change makes rlm-mschap behave the same on FreeBSD as on other platforms. This should help make FreeRADIUS configurations more portable between FreeBSD and other platforms. Without this change, it's possible for a FreeRADIUS configuration to work on FreeBSD but not on other platforms, where failures within MS-CHAP will be observed.
Background:
files/patch-ab was required to force RFC 2759 compliance in historic versions of FreeRADIUS. FreeRADIUS itself now provides the necessary functionality, which is enabled using with_ntdomain_hack = yes inside the mschap { } section of the FreeRADIUS configuration.
RFC 2759, the specification for MS-CHAPv2, requires the calculation of the NT-Response field relating to an MS-CHAPv2 Response to use only the user name, without any prepended domain name (see RFC 2759 paragraphs 4 and 8.2).
RFC 2759 paragraph 4 states "When computing the NT-Response field contents, only the user name is used, without any associated Windows NT domain name." Later, it states, "The Windows NT domain name may prefix the user's account name".
RFC 2759 paragraph 8.2 amplifies this by stating, in connection to the challenge_hash() function that files/patch-ab patches (which is the implementation of RFC 2759's ChallengeHash) "Only the user name (as presented by the peer and excluding any prepended domain name) is used as input to SHAUpdate()."
>How-To-Repeat:
>Fix:
See attached patch.
Note: files/patch-ab should be removed
Please add the following warning to /usr/ports/UPDATED:
AFFECTS: Users of net/freeradius
AUTHOR: David Wood <david@wood2.org.uk>
FreeBSD used to patch FreeRADIUS's rlm_mschap.c to strip all domain names when calculating the hash of an MS-CHAP challenge (a requirement specified in RFC 2759 paragraph 4 and amplified in paragraph 8.2).
FreeRADIUS now offers its own solution to discard a domain name before hashing in the MS-CHAP code, which can be enabled via a configuration option. As there is no longer any need for the FreeBSD patch, it has been removed, leaving the MS-CHAP code behaving as supplied by the FreeRADIUS team.
If the previous behaviour of the MS-CHAP code is required, add:
with_ntdomain_hack = yes
to the mschap { } section of your FreeRADIUS configuration. There should
be a commented out line that can be modified around line 696 of /usr/local/etc/raddb/radiusd.conf if your configuration is based on the sample FreeRADIUS configuration.
This option is not set by default in the sample FreeRADIUS configuration.
Only those who have clients sending a domain name as part of the user name when using MS-CHAP will be affected by this change; they will need to set this option to allow FreeRADIUS to authenticate their clients successfully. This may only affect those with older Windows clients, but I cannot be sure.
Some sources suggest setting this configuration option anyway to prevent FreeRADIUS from breaching RFC 2759 inadvertently, leading to authentication failure. It is left to the user whether to set this configuration option anyway, or only to set it in the event of authentication failures stemming from MS-CHAP.
Debug output from radiusd that reads "rlm_mschap: NT Domain delimeter found, should we have enabled with_ntdomain_hack?" suggests that this configuration option should be enabled.
Patch attached with submission follows:
diff -ruN /usr/ports/net/freeradius/Makefile /usr/ports_updated/net/freeradius/Makefile
--- /usr/ports/net/freeradius/Makefile Wed Nov 1 10:21:17 2006
+++ /usr/ports_updated/net/freeradius/Makefile Wed Nov 1 12:48:00 2006
@@ -7,6 +7,7 @@
PORTNAME= freeradius
PORTVERSION= 1.1.3
+PORTREVISION= 1
CATEGORIES= net
MASTER_SITES= ftp://ftp.freeradius.org/pub/radius/ \
ftp://ftp.ntua.gr/pub/net/radius/freeradius/ \
diff -ruN /usr/ports/net/freeradius/files/patch-ab /usr/ports_updated/net/freeradius/files/patch-ab
--- /usr/ports/net/freeradius/files/patch-ab Sun Aug 29 03:18:42 2004
+++ /usr/ports_updated/net/freeradius/files/patch-ab Thu Jan 1 01:00:00 1970
@@ -1,19 +0,0 @@
---- src/modules/rlm_mschap/rlm_mschap.c.orig Thu Aug 19 10:20:28 2004
-+++ src/modules/rlm_mschap/rlm_mschap.c Thu Aug 19 10:21:16 2004
-@@ -220,10 +220,15 @@
- SHA1_CTX Context;
- char hash[20];
-
-+ const char *name;
-+
-+ name = strchr(user_name, '\\');
-+ name = name == NULL ? user_name : name + 1;
-+
- SHA1Init(&Context);
- SHA1Update(&Context, peer_challenge, 16);
- SHA1Update(&Context, auth_challenge, 16);
-- SHA1Update(&Context, user_name, strlen(user_name));
-+ SHA1Update(&Context, name, strlen(name));
- SHA1Final(hash, &Context);
- memcpy(challenge, hash, 8);
- }
>Release-Note:
>Audit-Trail:
>Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200611011611.kA1GBeAH086735>