>Number:         9459
>Category:       bin
>Synopsis:       pppd 'noauth' option, doesn't
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    bin-bug-people (Utility Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Feb 21 00:45:00 2000
>Last-Modified:
>Originator:     Miles Nordin
>Organization:
Ivy Ministries
>Release:        1.4.1 (uncertain)
>Environment:
	
System: NetBSD audrey 1.4_BETA NetBSD 1.4_BETA (AUDREY) #1: Sat Apr 24 16:40:46 MDT 1999 carton@rynn:/usr/src/sys/arch/sparc/compile/AUDREY sparc


>Description:
The noauth option does not completely disable authentication, while 
a pap-secrets file containing

"" * "" *

does completely disable authentication.  (i think)  The documentation 
seems to imply an equivalence between this entry in pap-secrets and 
noauth, which doesn't exist and probably should.

It's not clear to me what noauth does, if anything.

>How-To-Repeat:
Attempt to set up a PPP ``server'' (local/remote IP are specified
in the options file) that

1) has a default router
2) does not require any kind of authentication

and you will probably think of using the ``noauth'' option.  However, this 
is not sufficient--pppd sill reports ``not authorized to use that IP
address.''  

>Fix:
Either the influence of the 'noauth' option should be extended to do what 
a reasonable human being would expect it to do in this situation, or if 
its (lack of) behaviour is an intentional effort to keep sysadmins from 
implementing vague or foolish security, then the documentation should be 
adjusted to more explicitly describe 'noauth's impotency.

This is classified sw-bug, but maybe it should be doc-bug if security 
experts feel the current behaviour is correct.  FWIW (probably not much), 
I don't feel this way--there is no illusion of security about setting up a 
PPP server that doesn't do any authentication.  But perhaps we are appealing 
to some kind of tradition from Ciscoland or something.  I don't know.

The relevant section of documentation is quoted in the workaround below.

Below is a workaround for the problem, that c5666305 later reported 
``worked for him.''

-------8<------
Date: Thu, 17 Feb 2000 22:49:51 -0700 (MST)
From: Miles Nordin <carton@Ivy.NET>
To: Chan Yiu Wah <c5666305@hkstar.com>
Cc: current-users@netbsd.org, ein@hkstar.com
Subject: Re: dialup server (pppd)

On Fri, 18 Feb 2000, Chan Yiu Wah wrote:

> Feb 18 11:33:08 pc77 pppd[451]: Peer is not authorized to use remote address 192.168.200.159
> ------- /var/log/messages  -------
> 
> ------- /etc/ppp/options.tty00 ------
> 192.168.200.77:192.168.200.159
> nodefaultroute
> noauth
> ------- /etc/ppp/options.tty00 ------

According to the docs, noauth should take care of the problem I'm about to
solve in a more complicated way, but maybe the simple way is broken. I
know the default for this stuff changed recently. from pppd(8):

       The default behaviour of pppd is to allow  an  unauthenti-
       cated  peer  to  use a given IP address only if the system
       does not already have a route to  that  IP  address.   For
       example, a system with a permanent connection to the wider
       internet will normally have a default route, and thus  all
       peers will have to authenticate themselves in order to set
       up a connection.  On such a system, the auth option is the
       default.
[...]
       In some cases it is desirable to allow  some  hosts  which
       can't  authenticate themselves to connect and use one of a
       restricted set of IP addresses, even when the  local  host
       generally requires authentication.  If the peer refuses to
       authenticate itself when requested,  pppd  takes  that  as
       equivalent  to  authenticating  with  PAP  using the empty
       string for the username and password.  Thus, by  adding  a
       line  to  the  pap-secrets  file which specifies the empty
       string for the client and  password,  it  is  possible  to
       allow restricted access to hosts which refuse to authenti-
       cate themselves.

I therefore suggest creating (or editing) this file, on the server.  The
effect of this line should be approximately equivalent to noauth.

/etc/ppp/pap-secrets
#chap:
# client	server		secret		allowed IP's
#pap, applicant:
# user		remotename	secret
#pap, supplicant:
# user		our (host)name	secret		allowed IP's
#
""		*		""		*

-- 
Miles Nordin / v:+1 720 841-8308 fax:+1 530 579-8680
555 Bryant Street PMB 182 / Palo Alto, CA 94301-1700 / US
-------8<------
>Audit-Trail:
>Unformatted: