De configuratie en probleemoplossing van PPP Password Verification Protocol (PAP)

Inleiding

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

• PAP biedt een eenvoudige methode voor een externe knooppunt om zijn identiteit vast te stellen met behulp van een tweerichtingshanddruk. Nadat de fase van de PPP-koppelingsinstelling is voltooid, wordt een gebruikersnaam en wachtwoordpaar herhaaldelijk door de externe knooppunt over de link (in duidelijke tekst) verzonden totdat de verificatie wordt bevestigd of totdat de verbinding wordt beëindigd.

• PAP is geen beveiligd verificatieprotocol. Wachtwoorden worden via de link in duidelijke tekst verzonden en er is geen bescherming tegen playback of trial-and-error aanvallen. De externe knooppunt heeft de controle over de frequentie en de timing van de inlogpogingen.

Raadpleeg Probleemoplossing PPP-verificatie (met behulp van PAP of CHAP) voor meer informatie over probleemoplossing bij PPP-verificatie (CHAP of PAP) voor een compleet, stapsgewijs stroomschema voor probleemoplossing in de PPP-verificatiefase. Raadpleeg het stroomschema voor PPP-probleemoplossing voor een compleet stroomschema voor stapsgewijze probleemoplossing van alle verwante PPP-fasen en overeengekomen parameters voor meer informatie over het oplossen van problemen in alle PPP-fasen (LCP, verificatie, NCP).

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 begrip en configuratie van PPP CHAP-verificatie voor meer informatie over CHAP.

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

• Een grote geïnstalleerde basis van clienttoepassingen die geen CHAP ondersteunen

• Onverenigbaarheden tussen verschillende leveranciers implementaties van CHAP

• Situaties waar een plaintext wachtwoord beschikbaar moet zijn om een login bij de verre gastheer te simuleren

Unidirectionele VS bidirectionele verificatie

Zoals met de meeste soorten authentificatie, steunt PAP bidirectionele (bidirectionele) en unidirectionele (unidirectionele) authentificatie. Met unidirectionele authenticatie, alleen de kant die de oproep ontvangt (NAS) authenticeert de externe kant (client). De externe client verifieert de server niet.

Met bi-directionele authenticatie, stuurt elke kant onafhankelijk een Authenticate-request (AUTH-REQ) en ontvangt of een Authenticate-Acwlewlewlewlewlewlewlewlewlewlewlewlewlewlewledgeof (AUTH-NAK). Deze zijn te zien met de opdracht. Een voorbeeld van dit debug bij de client wordt hieronder getoond:

*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, de authenticatie was tweerichtings. Als unidirectionele authenticatie was geconfigureerd, zouden we alleen de eerste twee debug-regels zien.

Configuratieopdrachten

Er zijn drie opdrachten vereist voor de normale PAP-verificatie die hieronder wordt beschreven:

ppp-verificatiepap [aanroepen]

De router waarop de ppp-verificatiepap is geconfigureerd zal PAP gebruiken om de identiteit van de andere kant (peer) te verifiëren. Dit betekent dat de andere kant (peer) de gebruikersnaam/het wachtwoord voor het lokale apparaat ter verificatie moet presenteren.

De callin optie zegt dat de router dat de ppp authenticatie pap callin opdracht is geconfigureerd alleen de andere kant tijdens een inkomende oproep zal verifiëren. Voor een uitgaande oproep wordt de andere kant niet geverifieerd. Dit betekent dat de router die de vraag in werking stelt geen verzoek om authentificatie (AUTH-REQ) van de overkant vereist

De volgende tabel toont wanneer de beloptie moet worden geconfigureerd:

Verificatietype	Klant (bellen)	NAS (genaamd)
unidirectioneel	ppp-verificatie pap bellen	ppp-verificatiepap
tweerichtings	ppp-verificatiepap	ppp-verificatiepap

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 verstuurt, zal de lokale router controleren of die gebruikersnaam en wachtwoord lokaal zijn geconfigureerd. Als er een succesvolle match is, wordt de peer geverifieerd.

Opmerking: de functie van de gebruikersnaamopdracht 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 verifiëren dat een inkomende gebruikersnaam en wachtwoord geldig zijn.

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

PPP-pakketnaam met gebruikersnaam <gebruikersnaam> wachtwoord <wachtwoord>

Maakt uitgaande PAP-verificatie mogelijk. De lokale router gebruikt de gebruikersnaam en het wachtwoord dat door de ppp-pap-opdracht voor het verzenden van een gebruikersnaam is opgegeven om zichzelf te verifiëren op een extern apparaat. De andere router moet dezelfde gebruikersnaam/wachtwoord hebben ingesteld met behulp van de bovenbeschreven gebruikersnaam opdracht.

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

Configuratievoorbeeld

De volgende configuratiesecties tonen de benodigde PAP-opdrachten 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 ontvangstzijde (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

Om een PPP PAP kwestie te zuiveren gebruik de debug ppp onderhandeling en debug ppp authentificatiebevelen. Er zijn twee belangrijke kwesties waar u op moet letten:

1. Zijn beide partijen het erover eens dat PAP de methode van authenticatie is?

2. Zo ja, slaagt de PAP-verificatie?

Verwijs naar de debugs hieronder voor informatie over hoe te om deze vragen behoorlijk te beantwoorden. Raadpleeg ook Begrip debug ppp-onderhandelingsoutput voor een uitleg van alle verschillende debugging-regels met hun relatieve betekenis tijdens de verschillende PPP-fasen, inclusief PPP-verificatie. Dit document is nuttig om de oorzaak van PPP-onderhandelingsfouten snel te bepalen. Raadpleeg Probleemoplossing PPP-verificatie (met behulp van PAP of CHAP) voor meer informatie over probleemoplossing bij PPP-verificatie (CHAP of PAP) voor een compleet, stapsgewijs stroomschema voor probleemoplossing in de PPP-verificatiefase.

Calling Side (client) debug voor een succesvolle eenmalige PAP-verificatie

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.

Call Side (server) debug voor een succesvolle unidirectionele PAP-verificatie

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

Wanneer het oplossen van problemen PAP, beantwoord de zelfde vragen die in de Debug sectie van de Output worden getoond:

1. Zijn beide partijen het erover eens dat PAP de methode van authenticatie is?

2. Zo ja, slaagt de PAP-verificatie?

Raadpleeg Probleemoplossing PPP-verificatie (met behulp van PAP of CHAP) voor meer informatie over probleemoplossing bij PPP-verificatie (CHAP of PAP) voor een compleet, stapsgewijs stroomschema voor probleemoplossing in de PPP-verificatiefase.

De twee partijen zijn het niet eens over PAP als verificatieprotocol

In bepaalde configuraties kunt u waarnemen dat de twee partijen niet akkoord gaan met PAP als het verificatieprotocol of in plaats daarvan akkoord gaan met 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-verificatiepap heeft geconfigureerd.

3. Controleer dat de aanroepende kant het correct gevormde bevel ppp pap verzend-gebruikersnaam gebruikersbenaming wachtwoord wachtwoord heeft, waar de gebruikersbenaming en het wachtwoord aanpassen die op de ontvangende router worden gevormd.

4. Configureer de opdracht ppp chap weigeren in interface configuratie modus op de aanroepende router.

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

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

De PAP-verificatie is niet geslaagd

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

1. Controleer dat de oproepende kant het commando ppp pap sent-username gebruikersnaam wachtwoord wachtwoord wachtwoord correct geconfigureerd heeft, waar de gebruikersnaam en het wachtwoord overeenkomen met degene die op de ontvangende router is geconfigureerd.

2. Voor bidirectionele authentificatie, verifieer dat de ontvangende kant het bevel ppp pap verzonden-gebruikersbenaming wachtwoord van het gebruikerswachtwoord correct gevormd heeft, waar de gebruikersbenaming en het wachtwoord aanpassen die op de roepende router worden gevormd.

   Wanneer het doen van bidirectionele authentificatie, als het bevel ppp de gebruikersbenamingswachtwoord van de pap ver-gebruikersbenaming het wachtwoord niet aanwezig op de ontvangende router was en de PPP cliëntpogingen om de server te dwingen om ver voor authentiek te verklaren, de output van debug ppp onderhandeling (of debug ppp authentificatie) zou wijzen

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

   Deze foutmelding is een indicatie van een configuratieprobleem en hoeft niet per se een beveiligingslek te zijn.

3. 3. Controleer dat de gebruikersnaam en het wachtwoord overeenkomen met het wachtwoord dat is ingesteld in het wachtwoord voor het wachtwoord voor het wachtwoord voor de gebruikersnaam en het wachtwoord voor het wachtwoord van de opdrachtppp 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 PPP-probleemoplossing
• Probleemoplossing voor PPP (CHAP of PAP)-verificatie
• Het begrip van debug ppp onderhandelingsoutput
• PPP-verificatie met behulp van de opdrachten ppp-chap hostname en ppp-verificatie chap
• Opbeltechnologie: Overzichten en toelichtingen
• Technische ondersteuning en documentatie – Cisco Systems