WAN : Protocolo punto a punto (PPP)

Configuración y resolución de problemas del Protocolo de autenticación de contraseñas (PAP, por sus siglas en inglés) de PPP

18 Octubre 2015 - Traducción Automática
Otras Versiones: PDFpdf | Inglés (22 Agosto 2015) | Comentarios


Contenido


Introducción

El Point-to-Point Protocol (PPP) actualmente admite dos protocolos de autenticación: Protocolo de autenticación de contraseña (PAP) y Protocolo de confirmación de aceptación de la autenticación (CHAP). Ambos están especificados en RFC 1334 y están admitidos en interfaces sincrónicas y asincrónicas.

  • PAP proporciona un método simple para que un nodo remoto establezca su identidad mediante una entrada en contacto bidireccional. Una vez que se completa la fase de establecimiento del link PPP, el nodo remoto envía de manera repetida un par de nombre de usuario y contraseña a través del link (en texto claro) hasta que se recibe el acuse de recibo de la autenticación, o hasta que finaliza la conexión.

  • PAP no es un protocolo de autenticación seguro. Las contraseñas se envían a través del link en el texto claro y no hay protección contra el aparato de lectura o los ataques prueba y errores. El nodo remoto controla la frecuencia y la sincronización de los intentos de registro.

Para más información sobre la localización de averías ppp autentificación (utilizando o el PAP o la CHAP), refiera a la autentificación de localización de averías PPP (CHAP o PAP) para un organigrama completo, paso a paso para localizar averías de la fase de la autentificación PPP. Para más información sobre la localización de averías de todas las fases PPP (LCP, autenticación, NCP), refiera al organigrama del Troubleshooting de PPP del documento para un organigrama completo para el Troubleshooting paso a paso de todas las fases relacionadas PPP y parámetros negociados.

prerrequisitos

Requisitos

No hay requisitos específicos para este documento.

Componentes Utilizados

Este documento no tiene restricciones específicas en cuanto a versiones de software y de hardware.

Convenciones

Consulte Convenciones de Consejos TécnicosCisco para obtener más información sobre las convenciones del documento.

Antecedentes

La GRIETA se considera ser más segura porque la contraseña del usuario nunca se envía a través de la conexión. Para más información sobre la GRIETA, refiera a entender y a configurar la autenticación CHAP de PPP.

A pesar de sus defectos, PAP puede usarse en los siguientes entornos:

  • Una gran base de aplicaciones cliente instalada que no admite CHAP

  • Incompatibilidad entre las distintas instrumentaciones de vendedores de CHAP

  • Situaciones donde una contraseña de sólo texto deba estar disponible para simular un inicio de sesión en el host remoto.

Autenticación unidireccional versus bidireccional

Como con la mayoría de los tipos de autenticación, PAP admite autenticaciones unidireccionales (de una vía) y bidireccionales (de dos vías). Con la autenticación unidireccional, sólo el lado que recibe la llamada (NAS) autentica el lado remoto (cliente). El cliente remoto no autentica el servidor.

Con la autenticación bidireccional, cada lado envía independientemente Authenticate-Request (AUTH-REQ) y recibe Authenticate-Acknowledge (AUTH-ACK) o Authenticate-Not Acknowledged (AUTH-NAK). Éstos se pueden ver con el comando debug ppp authentication. A continuación, se muestra un ejemplo de esta depuración en el cliente:

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

En la salida de depuración antes mencionada, la autenticación era bidireccional. Sin embargo, si la autenticación unidireccional hubiese sido configurada, sólo se verían las dos primeras líneas de depuración.

Comandos de Configuración

Se requieren tres comandos para una autenticación PAP normal, descritos a continuación:

ppp autentificación pap [callin]

El router en que está configurado el comando ppp authentication pap utilizará PAP para verificar la identidad del otro lado (par). Esto significa que la otra parte (par) debe presentarle al dispositivo local su nombre de usuario/contraseña para verificarlos.

La opción CALLIN dice al router que configuran al comando ppp authentication pap callin encendido autenticará solamente el otro lado durante una llamada entrante. Para una llamada saliente, no autenticará el otro lado. Esto significa que el router que inicia la llamada no requiere de un pedido de autenticación (AUTH-REQ) de otro lado.

La siguiente tabla muestra cómo configurar la opción callin (Llamar):

Tipo de autenticación Cliente (llamadas) NAS (llamado)
Unidireccional ppp authentication pap callin ppp autentificación pap
Bidireccional ppp autentificación pap ppp autentificación pap

username <nombre de usuario> password <contraseña>

Este es el nombre de usuario y contraseña utilizados por el router local para autenticar el par PPP. Cuando el par manda su nombre de usuario y contraseña PAP, el router local revisará si el nombre de usuario y contraseña están configurados de forma local. Si hay una correspondencia con éxito, autentican al par.

Nota: La función del comando username para el PAP es diferente que su función para la GRIETA. Con CHAP, este nombre de usuario y contraseña se utilizan para generar la respuesta al desafío, pero PAP sólo lo usa para verificar si el nombre de usuario y la contraseña entrante son válidos.

Para una autenticación unidireccional, este comando sólo se requiere en el entrador llamado. Para la autentificación de dos sentidos este comando debe ser configurado en ambos lados.

PPP pap sent-username <nombre de usuario> password <contraseña>

Activa la autenticación PAP saliente. El router local utiliza el nombre de usuario y contraseña especificado por el comando ppp pap sent-username de autenticarse a un dispositivo remoto. El otro router debe poseer este mismo nombre de usuario/contraseña configurados mediante el comando username descrito anteriormente.

Si utiliza la autenticación unidireccional, este comando sólo es necesario en el router que inicia la llamada. Para la autentificación de dos sentidos este comando debe ser configurado en ambos lados.

Ejemplo de configuración

Las siguientes secciones de configuración muestran los comandos PAP necesarios para un escenario de autenticación unidireccional.

Nota: Únicamente, se incluyen las secciones relevantes de la configuración.

Configuración de la parte que llama (cliente)

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

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

Configuración del lado receptor (servidor)

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.

‘Resultados de la depuración’

Para depurar un problema PPP PAP, utilice los comandos debug ppp negotiation y debug ppp authentication. Hay dos temas que tiene que observar:

  1. ¿Están de acuerdo ambos lados en que el método de autenticación es PAP?

  2. De ser así, ¿la autenticación PAP se realiza correctamente?

Refiera a los debugs abajo para la información sobre cómo contestar correctamente a las estas preguntas. También, refiera por favor comprensión de los resultados de la negociación ppp del debug para una explicación de todas las líneas de debugging diferentes con su significado relativo durante las diversas fases PPP, incluyendo la autenticación PPP. Este documento es útil en rápidamente determinar la causa de los incidentes de la negociación PPP. Para más información sobre la localización de averías ppp autentificación (utilizando o el PAP o la CHAP), refiera a la autentificación de localización de averías PPP (CHAP o PAP) para un organigrama completo, paso a paso para localizar averías de la fase de la autentificación PPP.

Depuración de la parte que llama (cliente) para realizar una autenticación PAP unidireccional correcta

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.

Depuración de la parte llamada (servidor) para realizar una autentificación PAP unidireccional correcta

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.

Solución de problemas de PAP

Mientras resuelve problemas de PAP, conteste las mismas preguntas que se muestran en la Sección de resultados de depuración:

  1. ¿Están de acuerdo ambos lados en que el método de autenticación es PAP?

  2. De ser así, ¿la autenticación PAP se realiza correctamente?

Para más información sobre la localización de averías ppp autentificación (utilizando o el PAP o la CHAP), refiera a la autentificación de localización de averías PPP (CHAP o PAP) para un organigrama completo, paso a paso para localizar averías de la fase de la autentificación PPP.

Ambas partes no coinciden sobre PAP como el protocolo de autenticación

En ciertas configuraciones, puede observarse que los dos lados no concuerdan en PAP como protocolo de autenticación o bien concuerdan en CHAP (mientras que se deseaba que fuera PAP). Utilice los siguientes pasos para solucionar los problemas:

  1. Verifique que el router que recibe la llamada tenga uno de los siguientes comandos de autenticación

    ppp authentication pap
           or 
    ppp authentication pap chap 
           or 
    ppp authentication chap pap
    
  2. Compruebe que el router que realiza la llamada posee configurado el comando ppp authentication pap callin.

  3. Verifique que el lado de llamada posea el comando ppp pap sent-username username password password correctamente configurado, donde el nombre de usuario y la contraseña coincidan con los configurados en el router de recepción.

  4. Configure el comando ppp chap refuse en el modo de configuración de la interfaz en el router de llamada.

    Los routeres Cisco, por abandono, validarán la GRIETA como el protocolo de autenticación. En una situación donde el cliente desea hacer el PAP pero el Access Server puede hacer PAP o la GRIETA (grieta pap de la autenticación PPP configurada), el comando ppp chap refuse puede ser utilizado para forzar al cliente a validar el PAP como el protocolo de autenticación.

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

La autenticación PAP no tiene éxito

Si los dos lados están de acuerdo con el PAP mientras que el protocolo de autenticación, pero la conexión PAP falla, es más probable un problema del nombre de usuario/de la contraseña.

  1. Verifique que el lado de llamada posea el comando ppp pap sent-username username password password correctamente configurado, donde el nombre de usuario y la contraseña coincidan con los configurados en el router de recepción.

  2. Para la autentificación en dos sentidos, verifique que el lado receptor tenga correctamente configurado el comando ppp pap sent-username username password password, donde el nombre del usuario y la contraseña coinciden con los configurados en el router de llamada.

    Al realizar la autenticación de doble sentido, si el comando ppp pap sent-username nombre de usuario password contraseña no estuviera presente en el router de recepción y el cliente PPP intenta forzar el servidor para autenticar en forma remota, el resultado de debug ppp negotiation (debug ppp autentication) indicaría

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

    Este mensaje de error indica un problema de configuración y no necesariamente una falla de seguridad.

  3. 3. Verifique que el nombre de usuario y contraseña, haga juego el que está configurado en el comando ppp pap sent-username username password password en el par.

    Si no hacen juego usted ve este mensaje:

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

Discusiones relacionadas de la comunidad de soporte de Cisco

La Comunidad de Soporte de Cisco es un foro donde usted puede preguntar y responder, ofrecer sugerencias y colaborar con colegas.


Información Relacionada


Document ID: 10313