DP - Using CHAP & PAP

The dp ppp engine in this distribution supports CHAP and PAP authentication. CHAP and PAP are defined in RFC 1334 "PPP Authentication Protocols". This note describes how to use these protocols.

Suggestions for improving this document will be welcomed by tkr@puffball.demon.co.uk.

There are four cases to consider, although only two are useful.

CHAP client

Suppose you connect to an Internet Service Provider that uses CHAP authentication. In addition to your hostname and IP address, you will be give a "name" (which may be the same as your hostname) and a "secret" (or "password").

For example, when I connect to BTnet I use

  hostname dial2.demo.bt.net
  name     dial2
  secret   imnotgoingtotellyou

and I go straight into PPP when I connect, with no UNIX-style login.

The CHAP "secret" must be stored in /etc/dp/config/chap thus

  # client server secret [IP address ...]
  dial2 * imnotgoingtotellyou

Note that you do not put in the name of the server because

you don't know it yet
if you do know it and put it in, ppp will give up saying "peer authentication required but appropriate secrets not found" (this is a Feature)

/etc/dp/config/chap should be root-owned and mode 600.

My /etc/dp/conf looks like this

  IF=dp0 SYS=dial2.demo.bt.net
    MODEMS=cuaa
    PHONE=0171332xxxx
    LOGIN_SCRIPT=direct
    TRACE=dial2-trace
    ACCESS=free
    LOG_LEVEL=3
    PPP_ARGS=name,dial2
    AUX=aux_script
  MODEM=cuaa DEV=cua/a BAUD=38400 DIAL_SCRIPT=us_robotics-dial

Note the use of the "direct" script to skip login.

Note also that you do _not_ specify the "+chap" argument to ppp - that would request your peer to authenticate itself using CHAP. The default behaviour is to authenticate yourself using CHAP if you are asked and you have the necessary secrets. (The "-chap" argument makes ppp refuse to do CHAP at all.)

You will want LOG_LEVEL=3 initially for debugging, with the following entry in your /etc/syslog.conf:

  local2.debug	/var/log/syslog

Now start a connection by PINGing some random address and look at /var/log/syslog.

If the configuration is correct, /var/log/syslog will look like this:

Feb  7 23:48:27 dial2.demo.bt.net ppp[299]: Starting ppp daemon version dp-3.1.3tkr patchlevel 0
Feb  7 23:48:27 dial2.demo.bt.net ppp[299]: popped stream module : ttcompat
Feb  7 23:48:27 dial2.demo.bt.net ppp[299]: popped stream module : ldterm
Feb  7 23:48:28 dial2.demo.bt.net ppp[299]: Using unit dp0
Feb  7 23:48:28 dial2.demo.bt.net ppp[299]: hostname = dial2.demo.bt.net
Feb  7 23:48:28 dial2.demo.bt.net ppp[299]: connect: dp0 /dev/cua/a
[...]
Feb  7 23:48:28 dial2.demo.bt.net ppp[299]: rcvd [LCP ConfReq id=0x1 < 00 04 00 00>     
	the "" is the peer requesting CHAP
[...]
Feb  7 23:48:29 dial2.demo.bt.net ppp[299]: sent [LCP ConfAck id=0x2     ]
	which we eventually accept
[...]
Feb  7 23:48:29 dial2.demo.bt.net ppp[299]: rcvd [CHAP Challenge id=0xb2 , name = "baynard-ascend1"]
	they send a challenge
Feb  7 23:48:29 dial2.demo.bt.net ppp[299]: ChapReceiveChallenge: Rcvd id 178.
Feb  7 23:48:29 dial2.demo.bt.net ppp[299]: ChapReceiveChallenge: received name field: baynard-ascend1
Feb  7 23:48:29 dial2.demo.bt.net ppp[299]: sent [CHAP Response id=0xb2 <23881d707568a6e125a43a32fe0c4b28>, name = "dial2"]
	we respond
[...]
Feb  7 23:48:30 dial2.demo.bt.net ppp[299]: rcvd [CHAP Success id=0xb2 "\000"]
Feb  7 23:48:30 dial2.demo.bt.net ppp[299]: ChapReceiveSuccess: Rcvd id 178.
	they like our response
[...]
Feb  7 23:48:30 dial2.demo.bt.net ppp[299]: sent [IPCP ConfReq id=0x1 ]
	and go on to IPCP
[...]

If not, you will instead see:

Feb  7 16:05:12 dial2.demo.bt.net ppp[359]: rcvd [CHAP Failure id=0xe7 "\000"]
Feb  7 16:05:12 dial2.demo.bt.net ppp[359]: ChapReceiveFailure: Rcvd id 231.
Feb  7 16:05:12 dial2.demo.bt.net ppp[359]: Untimeout 25e38:3f6bc.
Feb  7 16:05:12 dial2.demo.bt.net ppp[359]: Setting itimer for 0 seconds.
Feb  7 16:05:12 dial2.demo.bt.net ppp[359]: Remote message: 
Feb  7 16:05:12 dial2.demo.bt.net ppp[359]: CHAP authentication failed
Feb  7 16:05:49 dial2.demo.bt.net ppp[359]: POLL signal received
Feb  7 16:05:49 dial2.demo.bt.net ppp[359]: io(): POLLHUP
Feb  7 16:05:49 dial2.demo.bt.net ppp[359]: Hangup

PAP client

Suppose you want to talk to a directly-connected Linux machine, using PAP authentication. Your username is "puffball" and your password is "elephants".

In /etc/dp/config/upap put

  # client server secret [IP address ...]
  puffball * elephants

and make the file root-owned and mode 600.

In /etc/dp/conf put

  IF=dp0 SYS=linux
    MODEMS=cuaa
    LOGIN_SCRIPT=direct
    TRACE=linux-trace
    ACCESS=free
    LOG_LEVEL=3
    PPP_ARGS=user,puffball
    AUX=aux_script
  MODEM=cuaa DEV=cua/a BAUD=9600 DIAL_SCRIPT=direct

As with CHAP, you do not explicitly request authentication.

Make sure you have local2.debug entry in your /etc/syslog.conf as for CHAP above, PING some random address, and in /var/log/syslog you should see

Feb 12 16:40:21 puffball ppp[310]: Starting ppp daemon version dp-3.1.3tkr patchlevel 0
Feb 12 16:40:21 puffball ppp[310]: popped stream module : ttcompat
Feb 12 16:40:21 puffball ppp[310]: popped stream module : ldterm
Feb 12 16:40:21 puffball ppp[310]: Using unit dp0
Feb 12 16:40:21 puffball ppp[310]: hostname = puffball
Feb 12 16:40:21 puffball ppp[310]: connect: dp0 /dev/cua1
[...]
Feb 12 16:40:21 puffball ppp[310]: rcvd [LCP ConfReq id=0x1     ]
	the peer requests PAP authentication
[...]
Feb 12 16:40:21 puffball ppp[310]: sent [LCP ConfAck id=0x1     ]
	and we agree
[...]
Feb 12 16:40:21 puffball ppp[310]: sent [PAP AuthReq id=0x1 user="puffball" password="elephants"]
	we send our username and password
[...]
Feb 12 16:40:21 puffball ppp[310]: rcvd [PAP AuthAck id=0x1msg="Login ok"]
	and the peer accepts it
Feb 12 16:40:21 puffball ppp[310]: upap_rauthack: Rcvd id 1.
Feb 12 16:40:21 puffball ppp[310]: Remote message: Login ok
Feb 12 16:40:21 puffball ppp[310]: sent [IPCP ConfReq id=0x1  ]
[...]

CHAP server

To set up a "hub" machine with CHAP authentication, create /etc/dp/config/chap containing

  client1 * secret1
  client2 * secret2
  ...

and /etc/dp/conf containing

  IF=dp0 SYS=hub
    LOGIN=Pclient1
    TRACE=client1
    ACCESS=free
    LOG_LEVEL=3
    PPP_ARGS=+chap,name,hub
  IF=dp1 SYS=hub
    LOGIN=Pclient2
    TRACE=client2
    ACCESS=free
    LOG_LEVEL=3
    PPP_ARGS=+chap,name,hub
  ...

However this is not particularly useful within the architecture of dp. To avoid UNIX login altogether you would need a continuously-running ppp process on each serial port (hours of fun with pmadm, but doable) but dp expects a fixed binding between client and network interface, whereas using CHAP (or PAP) the identity of the client is not known until the authentication phase.

I tested using dummy passwordless logins Pclient1, Pclient2 with dplogin as shell. dplogin then maps the client to the correct dpN interface.

PAP server

To set up a "hub" machine with PAP authentication, create /etc/dp/config/upap containing

  client1 * password1
  client2 * password2
  ...

and /etc/dp/conf containing

  IF=dp0 SYS=hub
    LOGIN=Pclient1
    TRACE=client1
    ACCESS=free
    LOG_LEVEL=3
    PPP_ARGS=+pap,name,hub
  IF=dp1 SYS=hub
    LOGIN=Pclient2
    TRACE=client2
    ACCESS=free
    LOG_LEVEL=3
    PPP_ARGS=+pap,name,hub
  ...

This setup has the same problems as the CHAP server described above.

Tim Rylance / tkr@puffball.demon.co.uk Last updated: 28 July 1995