TCP/IP and Data Communications Administration Guide

Editing `asppp.cf` for PAP/CHAP Security

You can edit the asppp.cf file to establish security and to specify whether parts of the link will respond to Password Authentication Protocol (PAP), or Challenge-Handshake Authentication Protocol (CHAP),as described in "PPP Security". The asppp.cf file is edited by adding a series of keywords. In this section, authenticator is the system starting the link or challenge, and is frequently the server. Peer is the other end of the link, and is often the client.

The keywords to be added are require_authentication and will_do_authentication. The authenticator or server generally require authentication and the peer or client generally do authentication.

Table 11-1 Authenticator Keywords and Associated Strings


`require_authentication pap`	`require_authentication chap`
`pap_peer_id`	`chap_peer_secret`
`pap_peer_password`	`chap_peer_name`

Table 11-2 Peer Keywords and Associated Strings


`will_do__authentication pap`	`will_do_authentication chap`
`pap_id`	`chap_secret`
`pap_password`	`chap_name`

How to Install PAP/CHAP

On the server, become superuser and prepare to edit the /etc/asppp.cf file.

Add the require_authentication keyword for each machine on the link to use either CHAP or PAP security.
1. For each pap keyword add an associated pap_peer_id and pap_peer_password string.
2. For each chap keyword add an associated chap_peer_secret and chap_peer_name string.
  
  You can state the keywords explicitly, or if you prefer, you can use the default for the path. Refer to Table 11-3 to see what each keyword specifies. Examples can be found in Example 11-4.

On each remote host on the link to use either PAP or CHAP security, add an entry in the remote host's /etc/asppp.cf file with the will_do_authentication keyword.
1. For each pap keyword entry add an associated pap_id and pap_password string.
2. For each chap keyword entry add an associated chap_secret and chap_name string.

You can state the keywords explicitly, or if you prefer, you can use the default for the path. Refer to Table 11-3 to see what each keyword specifies. Examples can be found starting with Example 11-4.

Rules for PAP/CHAP Keywords

Either server or client can require authentication or offer to do authentication.
If PAP and CHAP are both present, the authenticator first tries CHAP. If that fails, the link is terminated. The authenticator will not try PAP.

The default value for PAP and CHAP authentication keywords is off. The syntax for keywords is:

require_authentication     off | pap[chap] | chap[pap]

will_do_authentication     off | pap[chap] | chap[pap]

If you fail to specify pap_id and pap_password or pap_peer_id and pap_peer_password keywords and values for the associated path, the corresponding values are set to the NULL string.
You must specify chap_name,chap_secret, chap_peer_secret and chap_peer_name keywords and values for that path.

Table 11-3 PAP/CHAP Keyword Definitions


Keywords	Value Definition
`require_authentication` `keywords` [Keyword alternatives are: `off\|pap[chap] \| chap[pap]`]	Specifies whether the peer must authenticate itself. If either `pap` or `chap` is present, the peer must participate in authentication or end the connection. The default value is off.
`pap_peer_id` `peername` [peername is the name of the system at the other end of the point-to-point link from the authenticator. It takes the form of a string with the syntax specified in Footnote 4.]	Specifies the name of the peer to be authenticated for the current path. `peername` string is one or more octets [Octet is the more accurate definition of byte.] . To indicate a zero-length string, do not include the keyword.
`pap_peer_password` `string` [string is a single token without embedded white space. The standard ANSI C \ escape sequence may be used to embed special characters. Use \s for the space character. Any pound sign at the beginning of the string must be escaped (\#) to avoid interpretation as a comment. A NULL (\0) truncates the string.]	Specifies password for peer in one or more octets. To indicate a zero-length string, do not include the keyword.
`chap_peer_secret` `string`	Specifies the secret used with the challenge value to generate the response sent by the peer. The format is one or more octets, preferably at least 16.
`chap_peer_name` `peername`	Specifies the identity of the peer transmitting the packet. The name should not be NULL or terminated with CR/LF. The name is received from the peer in a response packet and consists of one or more octets.
`will_do_authentication` `keywords`	Specifies whether the system is willing to participate as the authenticated peer in the specified authentication process. If both `pap` and `chap` are present, then the system is willing to participate in either authentication protocol. The default value is off.
`pap_id` `peername`	Specifies the name of the system to be sent to the authenticator in the response packet. To indicate a zero-length string, do not include the keyword.
`pap_password` `string`	Specifies the password for the system to be sent to the authenticator in the response packet. To indicate a zero-length string, do not include the keyword.
`chap_secret` `string`	Contains the secret that is used with the received challenge value to generate the response sent to the authenticator. The format is one or more octets, preferably at least 16.
`chap_name` `peername`	Specifies the identity of the system. The name should not end with a NULL or CR/LF. The name is sent to the authenticator in a response packet.

PAP/CHAP Examples

Example 11-4 shows the asppp.cf file for the server mojave with PAP and CHAP authentication required. The peers are nomada (PAP) and nomadb (CHAP).

Example 11-4 Code Example for Server `mojave`

ifconfig ipdptp0 plumb mojave nomada up
ifconfig ipdptp1 plumb mojave nomanb up
path
      peer_system_name tamerlane
      require_authentication pap  #tells nomada that mojave
                                  #requires pap authentication
      pap_peer_id desert
      pap_peer_password oasis
path
      peer_system_name lawrence
      require_authentication chap  #tells nomadb that mojave
                                   #requires chap authentication
      chap_peer_name another\sdesert
      chap_peer_secret secret\soasis\swith\007bell

Example 11-5 sample shows mojave's remote host nomada offering to do both PAP and CHAP authentication.

Example 11-5 Code Example for Remote Host `nomada`

ifconfig ipdptp0 plumb tamerlane mojave up
path
      interface ipdptp0
      peer_system_name mojave
      will_do_authentication chap pap #nomada tells mojave
                                      #that it will do chap and
                                      #pap authentication
      pap_id desert
      pap_password oasis
      chap_name desert\srain
      chap_secret %$#@7&*(+|`P'12

Example 11-6 shows mojave's remote host nomadb offering to do CHAP authentication.

Example 11-6 Code Example for Remote Host `nomadb`

ifconfig ipdptp0 plumb nomadb mojave private up
path
     interface ipdptp0
     peer_system_name mojave
     will_do_authentication chap   #nomadb tells mojave that it
                                   #will do chap authentication
     chap_name another\sdesert
     chap_secret secret\soasis\swith\007bell

Ideally, both CHAP and PAP are included in the configuration file, with the server requiring authentication and the remote host willing to do authentication. However this is reversible so that either side can require authentication. CHAP secrets need to be delivered by secure means. This generally involves handing them over in person.

Editing asppp.cf for PAP/CHAP Security