PPP Password Authentication Protocol (PAP) configureren en problemen oplossen

Inleiding

Point-to-Point Protocol (PPP) ondersteunt momenteel twee verificatieprotocollen: PAP (Password Authentication Protocol) en CHAP (Challenge Handshake Authentication Protocol). Beide zijn gespecificeerd in RFC 1334 en worden ondersteund op synchrone en asynchrone interfaces.

• PAP biedt een eenvoudige methode voor een extern knooppunt om zijn identiteit vast te stellen met behulp van een tweerichtingshandshake. Nadat de PPP-koppelingsfase is voltooid, worden een paar gebruikersnaam en wachtwoord herhaaldelijk door de externe node over de koppeling verzonden (in duidelijke tekst) totdat de verificatie is bevestigd of totdat de verbinding is beëindigd.

• PAP is geen veilig authenticatieprotocol. Wachtwoorden worden in duidelijke tekst over de link verzonden en er is geen bescherming tegen afspeelacties of trial-and-error-aanvallen. De remote node heeft de controle over de frequentie en timing van de inlogpogingen.

Raadpleeg voor meer informatie over het oplossen van problemen met PPP-verificatie (met behulp van PAP of CHAP) Problemen oplossen met PPP-verificatie (CHAP of PAP) voor een volledig, stapsgewijs stroomschema voor het oplossen van problemen met de PPP-verificatiefase. Raadpleeg voor meer informatie over het oplossen van problemen in alle PPP-fasen (LCP, verificatie, NCP) het stroomschema voor het documenteren van PPP-probleemoplossing voor een volledig stroomschema voor stapsgewijze probleemoplossing van alle gerelateerde PPP-fasen en onderhandelde parameters.

Voorwaarden

Vereisten

Er zijn geen specifieke vereisten van toepassing op dit document.

Gebruikte componenten

Dit document is niet beperkt tot specifieke software- en hardware-versies.

Conventies

Raadpleeg Cisco Technical Tips Conventions (Conventies voor technische tips van Cisco) voor meer informatie over documentconventies.

Achtergrondinformatie

CHAP wordt als veiliger beschouwd omdat het gebruikerswachtwoord nooit over de verbinding wordt verzonden. Raadpleeg Controleren en configureren van PPP CHAP-verificatie voor meer informatie over CHAP.

Ondanks de tekortkomingen kan PAP worden gebruikt in de volgende omgevingen:

• Een groot aantal geïnstalleerde clienttoepassingen die CHAP niet ondersteunen

• Onverenigbaarheden tussen de verschillende implementaties van CHAP door leveranciers

• Situaties waarin een wachtwoord in platte tekst beschikbaar moet zijn om een login op de externe host te simuleren

Unidirectionele versus bidirectionele authenticatie

Zoals bij de meeste soorten authenticatie, ondersteunt PAP bi-directionele (twee-weg) en unidirectionele (één-weg) authenticatie. Bij unidirectionele verificatie wordt alleen de externe zijde (client) geverifieerd door de zijde die de oproep ontvangt (NAS). De externe client verifieert de server niet.

Bij bi-directionele authenticatie verzendt elke partij onafhankelijk een Authenticate-Request (AUTH-REQ) en ontvangt ze een Authenticate-Acknowledge (AUTH-ACK) of Authenticate-Not-Acknowledged (AUTH-NAK). Deze kunnen worden gezien met de debug ppp opdracht. Een voorbeeld van deze foutopsporing bij de client wordt hieronder weergegeven:

*Mar  6 19:18:53.322: BR0:1 PAP: O AUTH-REQ id 7 len 18 from "PAPUSER"

! --- Outgoing PAP AUTH-REQ. We are sending out our username (PAPUSER)and password ! --- to the NAS. The NAS will verify that the username/password is correct. 
*Mar  6 19:18:53.441: BR0:1 PAP: I AUTH-ACK id 7 Len 5

! --- Incoming AUTH-ACK. ! --- The NAS verified the username and password and responded with an AUTH-ACK. ! --- One-way authentication is complete at this point. 
*Mar  6 19:18:53.445: BR0:1 PAP: I AUTH-REQ id 1 Len 14 from "NAS"

! --- Incoming AUTH-REQ from the NAS. This means we now verify the identity of the NAS.

*Mar  6 19:18:53.453: BR0:1 PAP: Authenticating peer NAS

! --- Performing a lookup for the username (NAS) and password.

*Mar  6 19:18:53.457: BR0:1 PAP: O AUTH-ACK id 1 Len 5

! --- Outgoing AUTH-ACK. ! --- We have verified the username/password of the NAS and responded with an AUTH-ACK. ! --- Two-way authentication is complete.

In de bovenstaande debug-uitvoer was de authenticatie bidirectioneel. Als unidirectionele authenticatie was geconfigureerd, zouden we echter alleen de eerste twee debugregels zien.

Configuratiecommando's

Hieronder worden drie opdrachten beschreven die vereist zijn voor normale PAP-verificatie:

PPP-verificatie PAP [Calling]

De router waarop de PPP-opdracht voor verificatie is geconfigureerd, gebruikt PAP om de identiteit van de andere kant (peer) te verifiëren. Dit betekent dat de andere kant (peer) zijn gebruikersnaam / wachtwoord moet presenteren aan het lokale apparaat voor verificatie.

De optie Bellen zegt dat de router waarop de PPP-authenticatie-pap-aanroep is geconfigureerd, alleen de andere kant zal verifiëren tijdens een inkomende oproep. Voor een uitgaande oproep zal het de andere kant niet authenticeren. Dit betekent dat de router die de oproep initieert geen verzoek om verificatie (AUTH-REQ) van de andere kant vereist

In de volgende tabel wordt aangegeven wanneer de optie Bellen moet worden geconfigureerd:

Verificatietype	Klant (bellen)	NAS (aangeroepen)
eenrichtings	PPP-verificatie-PAP-aanroep	PPP-verificatie PAP
bidirectioneel	PPP-verificatie PAP	PPP-verificatie PAP

gebruikersnaam <gebruikersnaam> wachtwoord <wachtwoord>

Dit is de gebruikersnaam en het wachtwoord dat door de lokale router wordt gebruikt om de PPP-peer te verifiëren. Wanneer de peer zijn PAP-gebruikersnaam en -wachtwoord verzendt, controleert de lokale router of die gebruikersnaam en wachtwoord lokaal zijn geconfigureerd. Als er een succesvolle match is, wordt de peer geverifieerd.

Opmerking: de functie van de opdracht username voor PAP is anders dan de functie voor CHAP. Met CHAP worden deze gebruikersnaam en wachtwoord gebruikt om het antwoord op de uitdaging te genereren, maar PAP gebruikt deze alleen om te controleren of een inkomende gebruikersnaam en wachtwoord geldig zijn.

Voor eenrichtingsverificatie is deze opdracht alleen vereist op de router die wordt genoemd. Voor tweerichtingsverificatie is deze opdracht aan beide zijden noodzakelijk.

PPP verzonden-gebruikersnaam <gebruikersnaam> wachtwoord <wachtwoord>

Maakt uitgaande PAP-verificatie mogelijk. De lokale router gebruikt de gebruikersnaam en het wachtwoord die zijn opgegeven door de opdracht ppp-gebruikersnaam verzonden om zichzelf te verifiëren op een extern apparaat. De andere router moet dezelfde gebruikersnaam/hetzelfde wachtwoord hebben geconfigureerd met behulp van de hierboven beschreven opdracht gebruikersnaam.

Als u eenrichtingsverificatie gebruikt, is deze opdracht alleen nodig op de router die het gesprek start. Voor tweerichtingsverificatie moet deze opdracht aan beide zijden worden geconfigureerd.

Configuratievoorbeeld

In de volgende configuratiegedeelten worden de benodigde PAP-opdrachten weergegeven voor een eenrichtingsverificatiescenario.

Opmerking: Alleen de relevante secties van de configuratie worden weergegeven.

Configuratie aan belzijde (client)

interface BRI0

! --- BRI interface for the dialout.

 ip address negotiated
 encapsulation ppp

! --- Use PPP encapsulation. This command is a required for PAP.

 dialer string 3785555 class 56k

! --- Number to dial for the outgoing connection.

 dialer-group 1
 isdn switch-type basic-ni
 isdn spid1 51299611110101 9961111
 isdn spid2 51299622220101 9962222
 ppp authentication pap callin

! --- Use PAP authentication for incoming calls. ! --- The callin keyword has made this a one-way authentication scenario. ! --- This router (client) will not request that the peer (server) authenticate ! --- itself back to the client. 
 ppp pap sent-username PAPUSER password 7 

! --- Permit outbound authentication of this router (client) to the peer. ! --- Send a PAP AUTH-REQ packet to the peer with the username PAPUSER and password. ! --- The peer must have the username PAPUSER and password configured on it.

Configuratie van de ontvangende kant (server)

username PAPUSER password 0 cisco

! --- Username PAPUSER is the same as the one sent by the client. ! --- Upon receiving the AUTH-REQ packet from the client, we will verify that the ! --- username and password match the one configured here.

interface Serial0:23

! --- This is the D-channel for the PRI on the access server receiving the call.

 ip unnumbered Ethernet0
 no ip directed-broadcast
 encapsulation ppp

! --- Use PPP encapsulation. This command is a required for PAP.

 dialer-group 1
 isdn switch-type primary-ni
 isdn incoming-voice modem
 peer default ip address pool default
 fair-queue 64 256 0
 ppp authentication pap

! --- Use PAP authentication for incoming calls. ! --- This router (server) will request that the peer authenticate itself to us. ! --- Note: the callin option is not used as this router is not initiating the call.

Debug-uitgangen

Als u een PPP-probleem wilt opsporen, gebruikt u de opdrachten PPP-onderhandeling debuggen en PPP-verificatie debuggen. Er zijn twee belangrijke zaken waar je op moet letten:

1. Zijn beide partijen het erover eens dat PAP de authenticatiemethode is?

2. Zo ja, slaagt de PAP-verificatie?

Raadpleeg de onderstaande debugs voor informatie over hoe u deze vragen goed kunt beantwoorden. Zie ook Begrijpen debug ppp onderhandelingsoutput voor een uitleg van alle verschillende debugging lijnen met hun relatieve betekenis tijdens de verschillende PPP fasen, met inbegrip van PPP authenticatie. Dit document is nuttig om snel de oorzaak van mislukte PPP-onderhandelingen te bepalen. Raadpleeg voor meer informatie over het oplossen van problemen met PPP-verificatie (met behulp van PAP of CHAP) Problemen oplossen met PPP-verificatie (CHAP of PAP) voor een volledig, stapsgewijs stroomschema voor het oplossen van problemen met de PPP-verificatiefase.

Foutopsporing aan de belzijde (client) voor een geslaagde eenrichtingsverificatie van PAP

maui-soho-01#show debug
PPP:
  PPP authentication debugging is on
  PPP protocol negotiation debugging is on
maui-soho-01#ping 172.22.53.144

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 172.22.53.144, timeout is 2 seconds:

*Mar  6 21:33:26.412: %LINK-3-UPDOWN: Interface BRI0:1, changed state to up
*Mar  6 21:33:26.432: BR0:1 PPP: Treating connection as a callout
*Mar  6 21:33:26.436: BR0:1 PPP: Phase is ESTABLISHING, Active Open [0 sess, 0 load]
*Mar  6 21:33:26.440: BR0:1 PPP: No remote authentication for call-out

! --- The client will not authenticate the server for an outgoing call. ! --- Remember this is a one-way authentication example. 
*Mar  6 21:33:26.444: BR0:1 LCP: O CONFREQ [Closed] id 82 Len 10
*Mar  6 21:33:26.448: BR0:1 LCP:    MagicNumber 0x2F1A7C63 (0x05062F1A7C63)

! --- Outgoing CONFREQ (CONFigure-REQuest). ! --- Notice that we do not specify an authentication method, ! --- since only the peer will authenticate us. 
*Mar  6 21:33:26.475: BR0:1 LCP: I CONFREQ [REQsent] id 13 Len 14
*Mar  6 21:33:26.479: BR0:1 LCP:    AuthProto PAP (0x0304C023)

! --- Incoming LCP CONFREQ (Configure-Request) indicating that ! --- the peer(server) wishes to use PAP. 
*Mar  6 21:33:26.483: BR0:1 LCP:    MagicNumber 0x3DBEE95B (0x05063DBEE95B)
*Mar  6 21:33:26.491: BR0:1 LCP: O CONFACK [REQsent] id 13 Len 14
*Mar  6 21:33:26.495: BR0:1 LCP:    AuthProto PAP (0x0304C023)

! --- This shows the outgoing LCP CONFACK (CONFigure-ACKnowledge) indicating that ! --- the client can do PAP.

*Mar  6 21:33:26.499: BR0:1 LCP:    MagicNumber 0x3DBEE95B (0x05063DBEE95B)
*Mar  6 21:33:26.511: BR0:1 LCP: I CONFACK [ACKsent] id 82 Len 10
*Mar  6 21:33:26.515: BR0:1 LCP:    MagicNumber 0x2F1A7C63 (0x05062F1.A7C63)
*Mar  6 21:33:26.519: BR0:1 LCP: State is Open

! --- This shows LCP negotiation is complete.

*Mar  6 21:33:26.523: BR0:1 PPP: Phase is AUTHENTICATING, by the peer [0 sess, 0 load]

! --- The PAP authentication (by the peer) begins.

*Mar  6 21:33:26.531: BR0:1 PAP: O AUTH-REQ id 20 Len 18 from "PAPUSER"

! --- The client sends out a PAP AUTH-REQ with username PAPUSER. ! --- This username is configured with the ppp pap sent-username command. 
*Mar  6 21:33:26.555: BR0:1 PAP: I AUTH-ACK id 20 Len 5

! --- The Peer responds with a PPP AUTH-ACK, indicating that ! --- it has successfully authenticated the client.

Side (server) debug voor een succesvolle eenrichtingsverificatie van PAP

maui-nas-06#show debug
PPP:
  PPP authentication debugging is on
  PPP protocol negotiation debugging is on
maui-nas-06#
*Jan  3 14:07:57.872: %LINK-3-UPDOWN: Interface Serial0:4, changed state to up
*Jan  3 14:07:57.876: Se0:4 PPP: Treating connection as a callin

! --- Since the connection is incoming, we will authenticate the client.

*Jan  3 14:07:57.876: Se0:4 PPP: Phase is ESTABLISHING, Passive Open
*Jan  3 14:07:57.876: Se0:4 LCP: State is Listen
*Jan  3 14:07:58.120: Se0:4 LCP: I CONFREQ [Listen] id 83 Len 10
*Jan  3 14:07:58.120: Se0:4 LCP:    MagicNumber 0x2F319828 (0x05062F319828)
*Jan  3 14:07:58.124: Se0:4 LCP: O CONFREQ [Listen] id 13 Len 14
*Jan  3 14:07:58.124: Se0:4 LCP:    AuthProto PAP (0x0304C023)

! --- Outgoing CONFREQ (Configure-Request) ! --- use PAP for the peer authentication.

*Jan  3 14:07:58.124: Se0:4 LCP:    MagicNumber 0x3DD5D5B9 (0x05063DD5D5B9)
*Jan  3 14:07:58.124: Se0:4 LCP: O CONFACK [Listen] id 83 Len 10
*Jan  3 14:07:58.124: Se0:4 LCP:    MagicNumber 0x2F319828 (0x05062F319828)
*Jan  3 14:07:58.172: Se0:4 LCP: I CONFACK [ACKsent] id 13 Len 14
*Jan  3 14:07:58.172: Se0:4 LCP:    AuthProto PAP (0x0304C023)

! --- This shows the incoming LCP CONFACK (Configure-Acknowledge) indicating that ! --- the client can do PAP.

*Jan  3 14:07:58.172: Se0:4 LCP:    MagicNumber 0x3DD5D5B9 (0x05063DD5D5B9)
*Jan  3 14:07:58.172: Se0:4 LCP: State is Open
*Jan  3 14:07:58.172: Se0:4 PPP: Phase is AUTHENTICATING, by this end

! --- The PAP authentication (by this side) begins.

*Jan  3 14:07:58.204: Se0:4 PAP: I AUTH-REQ id 21 Len 18 from "PAPUSER"

! --- Incoming AUTH-REQ from the peer. This means we must now verify ! --- the identity of the peer.

*Jan  3 14:07:58.204: Se0:4 PPP: Phase is FORWARDING
*Jan  3 14:07:58.204: Se0:4 PPP: Phase is AUTHENTICATING
*Jan  3 14:07:58.204: Se0:4 PAP: Authenticating peer PAPUSER

! --- Performing a lookup for the username (PAPUSER) and password.

*Jan  3 14:07:58.208: Se0:4 PAP: O AUTH-ACK id 21 Len 5

! --- This shows the outgoing AUTH-ACK. ! --- We have verified the username and password and responded with an AUTH-ACK. ! --- One-way authentication is complete.

PAP voor probleemoplossing

Bij het oplossen van problemen met PAP beantwoordt u dezelfde vragen die worden weergegeven in het gedeelte Foutopsporingsuitvoer:

1. Zijn beide partijen het erover eens dat PAP de authenticatiemethode is?

2. Zo ja, slaagt de PAP-verificatie?

Raadpleeg voor meer informatie over het oplossen van problemen met PPP-verificatie (met behulp van PAP of CHAP) Problemen oplossen met PPP-verificatie (CHAP of PAP) voor een volledig, stapsgewijs stroomschema voor het oplossen van problemen met de PPP-verificatiefase.

De twee partijen zijn het niet eens over PAP als authenticatieprotocol

In bepaalde configuraties kunt u zien dat de twee partijen het niet eens zijn over PAP als het verificatieprotocol of in plaats daarvan over CHAP (wanneer u PAP wilde). Gebruik de volgende stappen om dergelijke problemen op te lossen:

1. Controleer of de router die de oproep ontvangt een van de volgende verificatieopdrachten heeft

   ppp authentication pap
          or 
   ppp authentication pap chap 
          or 
   ppp authentication chap pap
   

2. Controleer of de router die de oproep doet, PPP-verificatie heeft geconfigureerd.

3. Controleer of de aanroepende kant het commando ppp-verzonden gebruikersnaam-gebruikersnaam wachtwoord heeft correct geconfigureerd, waarbij de gebruikersnaam en het wachtwoord overeenkomen met die welke zijn geconfigureerd op de ontvangende router.

4. Configureer de opdracht ppp chap refuse in de interfaceconfiguratiemodus op de aanroepende router.

   Cisco-routers accepteren standaard CHAP als het verificatieprotocol. In een situatie waarin de client PAP wil uitvoeren, maar de toegangserver PAP of CHAP kan uitvoeren (ppp-verificatie chap pap geconfigureerd), kan de opdracht ppp chap weigeren worden gebruikt om de client te dwingen PAP als het verificatieprotocol te accepteren.

   maui-soho-01(config)#interface BRI 0
   maui-soho-01(config-if)#ppp chap refuse
   

PAP-verificatie mislukt

Als de twee partijen het eens zijn over PAP als het verificatieprotocol, maar de PAP-verbinding mislukt, is dit waarschijnlijk een probleem met de gebruikersnaam / het wachtwoord.

1. Controleer of de aanroepende kant de opdracht ppp-verzonden gebruikersnaam gebruikersnaam wachtwoord correct heeft geconfigureerd, waarbij de gebruikersnaam en het wachtwoord overeenkomen met de gebruikersnaam die op de ontvangende router is geconfigureerd.

2. Controleer voor tweerichtingsverificatie of aan de ontvangende kant het wachtwoord van de verzonden PPP-gebruikersnaam is geconfigureerd en het wachtwoord van de gebruikersnaam correct is geconfigureerd, waarbij de gebruikersnaam en het wachtwoord overeenkomen met het wachtwoord dat is geconfigureerd op de aanroepende router.

   Als bij het uitvoeren van tweerichtingsverificatie de opdracht ppp-verzonden gebruikersnaam en wachtwoord niet aanwezig waren op de ontvangende router en de PPP-client probeert de server te dwingen zich op afstand te verifiëren, dan zou de uitvoer van debug ppp-onderhandeling (of debug ppp-verificatie) aangeven

   *Jan  3 16:47:20.259: Se0:1 PAP: Failed request for PAP credentials.  Username maui-nas-06

   Deze foutmelding duidt op een configuratieprobleem en niet noodzakelijkerwijs op een inbreuk op de beveiliging.

3. 3. Controleer of de gebruikersnaam en het wachtwoord overeenkomen met het wachtwoord dat is geconfigureerd in de opdracht ppp sent-username username password op de peer.

   Als ze niet overeenkomen, ziet u dit bericht:

   *Jan  3 17:18:57.559: Se0:3 PAP: I AUTH-REQ id 25 Len 18 from "PAPUSER"
   *Jan  3 17:18:57.559: Se0:3 PPP: Phase is FORWARDING
   *Jan  3 17:18:57.559: Se0:3 PPP: Phase is AUTHENTICATING
   *Jan  3 17:18:57.559: Se0:3 PAP: Authenticating peer PAPUSER
   *Jan  3 17:18:57.559: Se0:3 PAP: O AUTH-NAK id 25 Len 32 msg is
    "Password validation failure"
   
   ! --- This is an outgoing AUTH-NAK. This means that the mismatch occurred ! --- on this router. Verify that the username and password configured locally is ! --- identical to that on the peer.
   
   

Gerelateerde informatie

• Flowchart voor probleemoplossing voor PPP
• Problemen met PPP-verificatie (CHAP of PAP) oplossen
• Foutopsporings-PPP-onderhandelingsuitvoer begrijpen
• PPP-verificatie De oproepopdrachten ppp chap-hostnaam en ppp-verificatie chap gebruiken
• Dialup-technologie: overzichten en uitleg
• Technische ondersteuning en documentatie – Cisco Systems