Konfiguration und Fehlerbehebung des PPP Password Authentication Protocol (PAP)

Einleitung

Das Point-to-Point Protocol (PPP) unterstützt derzeit zwei Authentifizierungsprotokolle: Password Authentication Protocol (PAP) und Challenge Handshake Authentication Protocol (CHAP). Beide werden in RFC 1334 angegeben und auf synchronen und asynchronen Schnittstellen unterstützt.

• PAP stellt eine einfache Methode für einen Remote-Knoten bereit, seine Identität mithilfe eines bidirektionalen Handshakes herzustellen. Nach Abschluss der PPP-Verbindungsaufbauphase wird vom Remote-Knoten über den Link (im Klartext) wiederholt ein Benutzernamen-Passwort-Paar gesendet, bis die Authentifizierung bestätigt wird oder die Verbindung beendet wird.

• PAP ist kein sicheres Authentifizierungsprotokoll. Kennwörter werden in Klartext über den Link gesendet, und es besteht kein Schutz vor Wiedergabe- oder Test-and-Error-Angriffen. Der Remote-Knoten steuert die Häufigkeit und den Zeitpunkt der Anmeldeversuche.

Weitere Informationen zur Fehlerbehebung bei der PPP-Authentifizierung (mit PAP oder CHAP) finden Sie unter Problembehandlung bei der PPP-Authentifizierung (CHAP oder PAP) für ein vollständiges, schrittweises Flussdiagramm zur Fehlerbehebung in der PPP-Authentifizierungsphase. Weitere Informationen zur Fehlerbehebung in allen PPP-Phasen (LCP, Authentication, NCP) finden Sie im Dokument PPP Troubleshooting Flowchart für ein vollständiges Flussdiagramm zur schrittweisen Fehlerbehebung in allen zugehörigen PPP-Phasen und ausgehandelten Parametern.

Voraussetzungen

Anforderungen

Es gibt keine spezifischen Anforderungen für dieses Dokument.

Verwendete Komponenten

Dieses Dokument ist nicht auf bestimmte Software- und Hardware-Versionen beschränkt.

Konventionen

Weitere Informationen zu Dokumentkonventionen finden Sie unter Cisco Technical Tips Conventions (Technische Tipps von Cisco zu Konventionen).

Hintergrundinformationen

CHAP gilt als sicherer, da das Benutzerkennwort nie über die Verbindung gesendet wird. Weitere Informationen zu CHAP finden Sie unter Grundlegendes und Konfigurieren der PPP-CHAP-Authentifizierung.

Trotz seiner Mängel kann PAP in folgenden Umgebungen eingesetzt werden:

• Eine große Anzahl installierter Client-Anwendungen, die CHAP nicht unterstützen

• Inkompatibilitäten zwischen den verschiedenen Anbieterimplementierungen von CHAP

• Situationen, in denen ein unverschlüsseltes Passwort verfügbar sein muss, um eine Anmeldung am Remote-Host zu simulieren

Unidirektionale und bidirektionale Authentifizierung

Wie die meisten Authentifizierungstypen unterstützt PAP bidirektionale (bidirektional) und unidirektionale (unidirektional) Authentifizierung. Bei der unidirektionalen Authentifizierung authentifiziert nur die Seite, die den Anruf empfängt (NAS), die andere Seite (Client). Der Remote-Client authentifiziert den Server nicht.

Bei der bidirektionalen Authentifizierung sendet jede Seite unabhängig eine Authenticate-Request (AUTH-REQ) und empfängt entweder eine Authenticate-Acknowledge (AUTH-ACK) oder Authenticate-Not Acknowledged (AUTH-NAK). Diese werden mit dem Befehl angezeigt. Ein Beispiel für dieses Debugging auf dem Client ist unten dargestellt:

*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 der obigen Debug-Ausgabe war die Authentifizierung bidirektional. Wenn jedoch die unidirektionale Authentifizierung konfiguriert wäre, würden nur die ersten beiden Debugzeilen angezeigt.

Konfigurationsbefehle

Für die unten beschriebene normale PAP-Authentifizierung sind drei Befehle erforderlich:

ppp authentication pap [anrufen]

Der Router, für den der ppp authentication pap-Befehl konfiguriert wurde, verwendet PAP, um die Identität der anderen Seite (Peer) zu überprüfen. Das bedeutet, dass die andere Seite (Peer) den Benutzernamen/das Kennwort auf dem lokalen Gerät zur Verifizierung angeben muss.

Die Callin-Option besagt, dass der Router, auf dem der ppp authentication pap callin-Befehl konfiguriert ist, die andere Seite nur während eines eingehenden Anrufs authentifiziert. Bei einem ausgehenden Anruf wird die andere Seite nicht authentifiziert. Das bedeutet, dass der Router, der den Anruf initiiert, keine Authentifizierungsanforderung (AUTH-REQ) von der anderen Seite benötigt

Die folgende Tabelle zeigt, wann die Anruffunktion konfiguriert werden muss:

Authentifizierungstyp	Client (anrufend)	NAS (angerufen)
unidirektional	ppp authentication pap callin	ppp authentication pap
Bidirektional	ppp authentication pap	ppp authentication pap

username <Benutzername> password <Kennwort>

Dabei handelt es sich um den Benutzernamen und das Kennwort, die vom lokalen Router zur Authentifizierung des PPP-Peers verwendet werden. Wenn der Peer seinen PAP-Benutzernamen und sein Kennwort sendet, überprüft der lokale Router, ob dieser Benutzername und dieses Kennwort lokal konfiguriert sind. Bei erfolgreicher Übereinstimmung wird der Peer authentifiziert.

Hinweis: Die Funktion des Befehls username für PAP unterscheidet sich von der Funktion für CHAP. Bei CHAP werden dieser Benutzername und dieses Kennwort verwendet, um die Antwort auf die Anforderung zu generieren. PAP verwendet diesen jedoch nur, um die Gültigkeit eines eingehenden Benutzernamens und Kennworts zu überprüfen.

Für die unidirektionale Authentifizierung ist dieser Befehl nur auf dem angerufenen Router erforderlich. Für die bidirektionale Authentifizierung ist dieser Befehl auf beiden Seiten erforderlich.

PPP-Seite sent-username <Benutzername> Kennwort <Kennwort>

Aktiviert die ausgehende PAP-Authentifizierung. Der lokale Router verwendet den Benutzernamen und das Kennwort, die mit dem Befehl ppp pap sent-username angegeben wurden, um sich bei einem Remote-Gerät zu authentifizieren. Auf dem anderen Router muss derselbe Benutzername/dasselbe Kennwort konfiguriert sein, wie mit dem oben beschriebenen Befehl username.

Wenn Sie die unidirektionale Authentifizierung verwenden, ist dieser Befehl nur auf dem Router erforderlich, der den Anruf initiiert. Für die bidirektionale Authentifizierung muss dieser Befehl auf beiden Seiten konfiguriert werden.

Konfigurationsbeispiel

In den folgenden Konfigurationsabschnitten werden die erforderlichen PAP-Befehle für ein unidirektionales Authentifizierungsszenario beschrieben.

Hinweis: Nur die relevanten Abschnitte der Konfiguration werden angezeigt.

Konfiguration der anrufenden Seite (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.

Konfiguration der Empfangsseite (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-Ausgaben

Verwenden Sie zum Debuggen eines PPP-PAP-Problems die Befehle debug ppp negotiation und debug ppp authentication. Es gibt zwei Hauptprobleme, auf die Sie achten müssen:

1. Stimmen beide Seiten zu, dass PAP die Authentifizierungsmethode ist?

2. Wenn ja, ist die PAP-Authentifizierung erfolgreich?

Informationen zur richtigen Beantwortung dieser Fragen finden Sie in den unten stehenden Debugs. Unter debug ppp negotiation Output finden Sie eine Erläuterung aller Debug-Zeilen mit ihrer jeweiligen Bedeutung während der verschiedenen PPP-Phasen, einschließlich der PPP-Authentifizierung. Dieses Dokument ist hilfreich, um schnell die Ursache von PPP-Aushandlungsfehlern zu ermitteln. Weitere Informationen zur Fehlerbehebung bei der PPP-Authentifizierung (mit PAP oder CHAP) finden Sie unter Problembehandlung bei der PPP-Authentifizierung (CHAP oder PAP) für ein vollständiges, schrittweises Flussdiagramm zur Fehlerbehebung in der PPP-Authentifizierungsphase.

Calling Side (Client)-Debugging für eine erfolgreiche unidirektionale PAP-Authentifizierung

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.

Called Side (Server)-Debugging für eine erfolgreiche unidirektionale PAP-Authentifizierung

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-Fehlerbehebung

Beantworten Sie bei der PAP-Fehlerbehebung die gleichen Fragen, die im Abschnitt Debug Output (Debug-Ausgabe) aufgeführt sind:

1. Stimmen beide Seiten zu, dass PAP die Authentifizierungsmethode ist?

2. Wenn ja, ist die PAP-Authentifizierung erfolgreich?

Weitere Informationen zur Fehlerbehebung bei der PPP-Authentifizierung (mit PAP oder CHAP) finden Sie unter Problembehandlung bei der PPP-Authentifizierung (CHAP oder PAP) für ein vollständiges, schrittweises Flussdiagramm zur Fehlerbehebung in der PPP-Authentifizierungsphase.

Die beiden Seiten sind sich nicht über PAP als Authentifizierungsprotokoll einig

In bestimmten Konfigurationen können Sie beobachten, dass die beiden Seiten sich nicht auf PAP als Authentifizierungsprotokoll oder stattdessen auf CHAP einigen (wenn Sie PAP wollten). Gehen Sie folgendermaßen vor, um solche Probleme zu beheben:

1. Überprüfen Sie, ob der Router, der den Anruf empfängt, über einen der folgenden Authentifizierungsbefehle verfügt:

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

2. Vergewissern Sie sich, dass auf dem Router, der den Anruf tätigt, ppp authentication pap Calling konfiguriert ist.

3. Vergewissern Sie sich, dass der Anrufer den Befehl ppp pap sent-username username password password richtig konfiguriert hat, wobei Benutzername und Passwort mit dem auf dem empfangenden Router konfigurierten Passwort übereinstimmen.

4. Konfigurieren Sie den Befehl ppp chap reject im Schnittstellenkonfigurationsmodus auf dem anrufenden Router.

   Cisco Router akzeptieren standardmäßig CHAP als Authentifizierungsprotokoll. Wenn der Client PAP ausführen möchte, der Zugriffsserver jedoch PAP oder CHAP ausführen kann (ppp authentication chap pap konfiguriert), kann der Befehl ppp chap reject verwendet werden, um den Client zu zwingen, PAP als Authentifizierungsprotokoll zu akzeptieren.

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

PAP-Authentifizierung fehlgeschlagen

Wenn sich beide Seiten auf PAP als Authentifizierungsprotokoll einigen, die PAP-Verbindung jedoch fehlschlägt, handelt es sich höchstwahrscheinlich um ein Problem mit Benutzername/Kennwort.

1. Vergewissern Sie sich, dass der Anrufer den Befehl ppp pap sent-username username password password richtig konfiguriert hat, wobei Benutzername und Passwort mit dem auf dem empfangenden Router konfigurierten Passwort übereinstimmen.

2. Bei der bidirektionalen Authentifizierung müssen Sie sicherstellen, dass der Befehl ppp pap sent-username username password password richtig konfiguriert ist, wobei Benutzername und Passwort mit dem auf dem anrufenden Router konfigurierten Passwort übereinstimmen.

   Wenn bei der bidirektionalen Authentifizierung der Befehl ppp pap sent-username username password password kennwort auf dem empfangenden Router nicht vorhanden ist und der PPP-Client versucht, den Server zu zwingen, sich remote zu authentifizieren, so würde die Ausgabe von debug ppp negotiation (oder debug ppp authentication)

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

   Diese Fehlermeldung ist ein Hinweis auf ein Konfigurationsproblem und nicht unbedingt auf eine Sicherheitslücke.

3. 3. Vergewissern Sie sich, dass Benutzername und Passwort mit dem Passwort übereinstimmen, das im Befehl ppp pap sent-username username password Passwort auf dem Peer konfiguriert wurde.

   Wenn sie nicht übereinstimmen, wird die folgende Meldung angezeigt:

   *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.
   
   

Zugehörige Informationen

• PPP-Fehlerbehebung - Flussdiagramm
• Fehlerbehebung PPP-Authentifizierung (CHAP oder PAP)
• Grundlagen der debug ppp negotiation-Ausgabe
• PPP-Authentifizierung mit ppp chap Hostname und ppp authentication chap callin-Befehlen
• DFÜ-Technologie: Übersichten und Erläuterungen
• Technischer Support und Dokumentation für Cisco Systeme