From nobody@FreeBSD.org  Thu Mar  1 08:58:04 2001
Return-Path: <nobody@FreeBSD.org>
Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21])
	by hub.freebsd.org (Postfix) with ESMTP id F262837B719
	for <freebsd-gnats-submit@FreeBSD.org>; Thu,  1 Mar 2001 08:58:01 -0800 (PST)
	(envelope-from nobody@FreeBSD.org)
Received: (from nobody@localhost)
	by freefall.freebsd.org (8.11.1/8.11.1) id f21Gw1h37499;
	Thu, 1 Mar 2001 08:58:01 -0800 (PST)
	(envelope-from nobody)
Message-Id: <200103011658.f21Gw1h37499@freefall.freebsd.org>
Date: Thu, 1 Mar 2001 08:58:01 -0800 (PST)
From: B.Candler@pobox.com
To: freebsd-gnats-submit@FreeBSD.org
Subject: pam_radius fix to allow null passwords for challenge/response
X-Send-Pr-Version: www-1.0

>Number:         25477
>Category:       bin
>Synopsis:       [pam] [patch] pam_radius(8) fix to allow null passwords for challenge/response
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          suspended
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Thu Mar 01 09:00:03 PST 2001
>Closed-Date:    
>Last-Modified:  Sat May 24 14:43:29 UTC 2008
>Originator:     Brian Candler
>Release:        4.2-STABLE
>Organization:
>Environment:
>Description:
When using pam_radius, if there is no password (AUTHTOK) set previously
then PAM always prompts the user for a password.
 
However, when using a RADIUS server with challenge/response, the password
in the first Access-Request packet is always ignored. It should be possible
to provide a null password in this packet, and for PAM only to prompt
at the point of receiving an Access-Challenge.

See RFC2865
>How-To-Repeat:
Try configuring sshd for SkeyAuthentication with PAM, and a cryptocard
easyRadius server.

You will find that the TIS challenge is
RADIUS password:
and the TIS response sent back is the dummy password for the initial
Access-Request. The subsequent Access-Challenge causes an unexpected extra
exchange from PAM, and sshd aborts with "Conversation Error"

Applying the patch below, and adding "nullok" after pam_radius.so in
pam.conf, makes it work. The initial Access-Request uses a null
password without prompting the user. The first user prompt is thus
the Radius challenge (given as an SSH_SMSG_AUTH_TIS_CHALLENGE), and
the response is, well, the response :-)

This works nicely and allows even a Windows client running ttssh to make
a successful ssh login with challenge/response and RADIUS backend.

>Fix:
Patch for /usr/src/lib/libpam/modules/ attached which adds a "nullok"
parameter to pam_radius.so

--- pam_radius.c.orig   Thu Mar  1 15:32:11 2001
+++ pam_radius.c        Thu Mar  1 16:03:15 2001
@@ -45,6 +45,7 @@
 /* Option names, including the "=" sign. */
 #define OPT_CONF               "conf="
 #define OPT_TMPL               "template_user="
+#define OPT_NULLOK             "nullok"
 
 static int      build_access_request(struct rad_handle *, const char *,
                    const char *, const void *, size_t);
@@ -202,6 +203,7 @@
        const char *pass;
        const char *conf_file = NULL;
        const char *template_user = NULL;
+       int nullok = 0;
        int options = 0;
        int retval;
        int i;
@@ -216,10 +218,17 @@
                else if (strncmp(argv[i], OPT_TMPL,
                    (len = strlen(OPT_TMPL))) == 0)
                        template_user = argv[i] + len;
+               else if (strcmp(argv[i], OPT_NULLOK) == 0)
+                       nullok = 1;
        }
        if ((retval = pam_get_user(pamh, &user, NULL)) != PAM_SUCCESS)
                return retval;
-       if ((retval = pam_get_pass(pamh, &pass, PASSWORD_PROMPT,
+       if (nullok) {
+               if (pam_get_item(pamh, PAM_AUTHTOK, &pass) != PAM_SUCCESS
+                   || pass == NULL)
+                       pass = "dummy";
+       }
+       else if ((retval = pam_get_pass(pamh, &pass, PASSWORD_PROMPT,
            options)) != PAM_SUCCESS)
                return retval;
 
--- pam_radius.8.orig   Thu Mar  1 15:32:24 2001
+++ pam_radius.8        Thu Mar  1 15:38:00 2001
@@ -48,6 +48,7 @@
 .Nm pam_radius.so
 .Op Cm use_first_pass
 .Op Cm try_first_pass
+.Op Cm nullok
 .Op Cm echo_pass
 .Op Cm conf Ns No = Ns Ar pathname
 .Op Cm template_user Ns No = Ns Ar username
@@ -74,6 +75,11 @@
 password has been entered,
 .Nm
 prompts for one as usual.
+.It Cm nullok
+causes
+.Nm
+never to prompt for a new password. If no password has been previously
+entered, a null one is sent.
 .It Cm echo_pass
 causes echoing to be left on if
 .Nm

>Release-Note:
>Audit-Trail:
Responsible-Changed-From-To: freebsd-bugs->billf 
Responsible-Changed-By: billf 
Responsible-Changed-When: Thu Mar 1 17:53:41 PST 2001 
Responsible-Changed-Why:  
I have the capability to test this and I know a little something 
about challenge/response and radius.. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=25477 

From: Brian Candler <B.Candler@pobox.com>
To: freebsd-gnats-submit@freebsd.org
Cc:  
Subject: Re: bin/25477: pam_radius fix to allow null passwords for challenge/response
Date: Wed, 11 Apr 2001 14:30:08 +0100

 Oops, just spotted I meant to put
   pass = "";  rather than  pass = "dummy";
 (not that it affects my particular application, but it would be cleaner to
 send a null password than an arbitrary one)
 
 An alternative approach would be to have some way to 'preset' the password
 in PAM, then 'try_first_pass' would do what I want. In the most generic
 form, this might be something like
 
      pam_set_item.so   pam_auth_tok="dummy"
 
 The reason I modified pam_radius was that it was the simplest way to achieve
 what I wanted, and it's not clear whether any other module is likely to
 benefit anyway.
State-Changed-From-To: open->feedback 
State-Changed-By: linimon 
State-Changed-When: Wed Mar 14 23:03:19 UTC 2007 
State-Changed-Why:  
To submitter: did this problem ever get fixed? 


Responsible-Changed-From-To: billf->linimon 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Wed Mar 14 23:03:19 UTC 2007 
Responsible-Changed-Why:  
Assignee did not respond to request for status of this PR, so reassign 
to the pool. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=25477 
State-Changed-From-To: feedback->suspended 
State-Changed-By: linimon 
State-Changed-When: Sun May 6 00:41:48 UTC 2007 
State-Changed-Why:  
No one responded to my request for status about this PR, so mark 
it suspended. 


Responsible-Changed-From-To: linimon->freebsd-bugs 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Sun May 6 00:41:48 UTC 2007 
Responsible-Changed-Why:  

http://www.freebsd.org/cgi/query-pr.cgi?pr=25477 
>Unformatted:
