PAP(PPP Password Authentication Protocol) 구성 및 문제 해결

소개

PPP(Point-to-Point Protocol)는 현재 두 가지 인증 프로토콜을 지원합니다. PAP(Password Authentication Protocol) 및 CHAP(Challenge Handshake Authentication Protocol) 둘 다 RFC 1334에 지정되어 있으며 동기식 및 비동기식 인터페이스에서 지원됩니다.

• PAP는 원격 노드가 양방향 핸드셰이크를 사용하여 ID를 설정하는 간단한 방법을 제공합니다. PPP 링크 설정 단계가 완료되면 인증이 승인되거나 연결이 종료될 때까지 사용자 이름 및 비밀번호 쌍이 링크를 통해(일반 텍스트로) 원격 노드에 의해 반복적으로 전송됩니다.

• PAP는 보안 인증 프로토콜이 아닙니다. 비밀번호는 링크를 통해 일반 텍스트로 전송되며 재생 또는 시행착오 공격으로부터 보호되지 않습니다. 원격 노드는 로그인 시도의 빈도 및 타이밍을 제어합니다.

PPP 인증 문제 해결(PAP 또는 CHAP 사용)에 대한 자세한 내용은 PPP 인증 단계 문제 해결을 위한 전체 단계별 순서도에 대한 PPP(CHAP 또는 PAP) 인증 문제 해결을 참조하십시오. 모든 PPP 단계(LCP, 인증, NCP) 트러블슈팅에 대한 자세한 내용은 모든 관련 PPP 단계 및 협상된 매개변수의 단계별 트러블슈팅에 대한 전체 순서도에 대한 문서 PPP 트러블슈팅 순서도를 참조하십시오.

사전 요구 사항

요구 사항

이 문서에 대한 특정 요건이 없습니다.

사용되는 구성 요소

이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.

표기 규칙

문서 규칙에 대한 자세한 내용은 Cisco 기술 팁 표기 규칙을 참고하십시오.

배경 정보

CHAP는 사용자 비밀번호가 연결을 통해 전송되지 않으므로 보다 안전한 것으로 간주됩니다. CHAP에 대한 자세한 내용은 PPP CHAP 인증 이해 및 구성을 참조하십시오.

단점에도 불구하고 PAP는 다음과 같은 환경에서 사용될 수 있습니다.

• CHAP를 지원하지 않는 대규모 클라이언트 애플리케이션 설치 기반

• 서로 다른 공급업체의 CHAP 구현 간 비호환성

• 원격 호스트에서 로그인을 시뮬레이션하는 데 일반 텍스트 비밀번호를 사용할 수 있어야 하는 경우

단방향 및 양방향 인증

대부분의 인증 유형과 마찬가지로 PAP는 양방향(양방향) 및 단방향(단방향) 인증을 지원합니다. 단방향 인증을 사용하면 통화를 받는 측(NAS)만 원격 측(클라이언트)을 인증합니다. 원격 클라이언트는 서버를 인증하지 않습니다.

양방향 인증을 사용하면 각 측에서 AUTH-REQ(Authenticate-Request)를 독립적으로 전송하고 AUTH-ACK(Authenticate-Acknowledge) 또는 AUTH-NAK(Authenticate-Not Acknowledged)를 수신합니다. 이러한 항목은 명령에서 확인할 수 있습니다. 클라이언트에서의 이 디버그의 예는 다음과 같습니다.

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

위의 디버그 출력에서 인증은 양방향이었습니다. 그러나 단방향 인증이 구성된 경우 처음 두 개의 디버그 행만 표시됩니다.

컨피그레이션 명령

아래에 설명된 세 가지 명령은 일반적인 PAP 인증에 필요합니다.

ppp 인증 pap [callin]

ppp authentication pap 명령이 구성된 라우터는 PAP를 사용하여 다른 쪽(피어)의 ID를 확인합니다. 즉, 다른 쪽(피어)이 확인을 위해 로컬 디바이스에 사용자 이름/비밀번호를 제공해야 합니다.

callin 옵션은 ppp authentication pap callin 명령이 구성된 라우터가 수신 통화 중에만 상대방을 인증한다고 말합니다. 발신 통화의 경우 상대방을 인증하지 않습니다. 즉, 통화를 시작하는 라우터가 다른 쪽에서 인증 요청(AUTH-REQ)을 요구하지 않습니다

다음 표는 callin 옵션을 구성하는 시기를 보여줍니다.

인증 유형	클라이언트(통화)	NAS(호출됨)
단방향	ppp 인증 pap callin	ppp 인증 pap
양방향	ppp 인증 pap	ppp 인증 pap

사용자 이름 <사용자 이름> 암호 <암호>

로컬 라우터가 PPP 피어를 인증하는 데 사용하는 사용자 이름 및 비밀번호입니다. 피어가 PAP 사용자 이름 및 비밀번호를 전송하면 로컬 라우터는 해당 사용자 이름 및 비밀번호가 로컬로 구성되었는지 확인합니다. 성공적인 일치가 있는 경우 피어가 인증됩니다.

참고: PAP에 대한 username 명령의 기능은 CHAP에 대한 기능과 다릅니다. CHAP를 사용하면 이 사용자 이름과 암호는 챌린지에 대한 응답을 생성하는 데 사용되지만, PAP는 수신 사용자 이름과 암호가 올바른지 확인하는 데만 사용합니다.

단방향 인증의 경우 이 명령은 호출된 라우터에서만 필요합니다. 양방향 인증의 경우 이 명령은 양측에 필요합니다.

PPP pap sent-username <username> password <password>

아웃바운드 PAP 인증을 활성화합니다. 로컬 라우터는 ppp pap sent-username 명령으로 지정한 사용자 이름 및 비밀번호를 사용하여 원격 디바이스에 자신을 인증합니다. 다른 라우터에는 위에서 설명한 username 명령을 사용하여 구성된 동일한 사용자 이름/비밀번호가 있어야 합니다.

단방향 인증을 사용하는 경우 이 명령은 통화를 시작하는 라우터에서만 필요합니다. 양방향 인증의 경우 이 명령을 양쪽에서 구성해야 합니다.

컨피그레이션 예시

다음 컨피그레이션 섹션에서는 단방향 인증 시나리오에 필요한 PAP 명령을 보여줍니다.

참고: 컨피그레이션의 관련 섹션만 표시됩니다.

발신측(클라이언트) 컨피그레이션

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.

Receiving Side(서버) 컨피그레이션

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.

출력 디버그

PPP PAP 문제를 디버깅하려면 debug ppp negotiation 및 debug ppp authentication 명령을 사용합니다. 주의해야 할 두 가지 주요 문제가 있습니다.

1. 양측이 PAP가 인증 방법이라는 데 동의합니까?

2. 그렇다면 PAP 인증은 성공합니까?

이러한 질문에 올바르게 대답하는 방법에 대한 자세한 내용은 아래 디버그를 참조하십시오. 또한 PPP 인증을 포함하여 서로 다른 PPP 단계 동안 서로 다른 모든 디버깅 라인에 대한 상대적 의미에 대한 설명은 디버그 PPP 협상 출력 이해를 참조하십시오. 이 문서는 PPP 협상 실패의 원인을 신속하게 확인하는 데 유용합니다. PPP 인증 문제 해결(PAP 또는 CHAP 사용)에 대한 자세한 내용은 PPP 인증 단계 문제 해결을 위한 전체 단계별 순서도에 대한 PPP(CHAP 또는 PAP) 인증 문제 해결을 참조하십시오.

성공적인 단방향 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.

성공적인 단방향 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

PAP를 트러블슈팅할 때 디버그 출력 섹션에 나와 있는 동일한 질문에 답합니다.

1. 양측이 PAP가 인증 방법이라는 데 동의합니까?

2. 그렇다면 PAP 인증은 성공합니까?

PPP 인증 문제 해결(PAP 또는 CHAP 사용)에 대한 자세한 내용은 PPP 인증 단계 문제 해결을 위한 전체 단계별 순서도에 대한 PPP(CHAP 또는 PAP) 인증 문제 해결을 참조하십시오.

양측은 PAP를 인증 프로토콜로 인정하지 않는다

특정 컨피그레이션에서는 양측이 PAP에 인증 프로토콜로 동의하지 않거나 CHAP(PAP를 원할 때)에 동의하는 것을 확인할 수 있습니다. 이러한 문제를 해결하려면 다음 단계를 수행하십시오.

1. 통화를 수신하는 라우터에 다음 인증 명령 중 하나가 있는지 확인합니다

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

2. 통화를 수행하는 라우터에 ppp 인증 pap 통화가 구성되어 있는지 확인합니다.

3. 발신측에 명령 ppp pap sent-username username password가 올바르게 구성되었는지 확인합니다. 여기서 사용자 이름 및 비밀번호는 수신 라우터에 구성된 것과 일치합니다.

4. 발신 라우터의 인터페이스 컨피그레이션 모드에서 ppp chap refuse 명령을 구성합니다.

   Cisco 라우터는 기본적으로 CHAP를 인증 프로토콜로 수락합니다. 클라이언트가 PAP를 수행하려고 하지만 액세스 서버가 PAP 또는 CHAP(ppp 인증 chap pap가 구성됨)를 수행할 수 있는 경우 ppp chap refuse 명령을 사용하여 클라이언트가 PAP를 인증 프로토콜로 수락하도록 강제할 수 있습니다.

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

PAP 인증에 실패했습니다.

양측이 PAP를 인증 프로토콜로 합의했지만 PAP 연결이 실패하는 경우 사용자 이름/비밀번호 문제일 가능성이 높습니다.

1. 발신측에 명령 ppp pap sent-username username password가 올바르게 구성되었는지 확인합니다. 여기서 사용자 이름 및 비밀번호는 수신 라우터에 구성된 것과 일치합니다.

2. 양방향 인증의 경우 수신 측에 명령 ppp send-username username password가 올바르게 구성되었는지 확인합니다. 여기서 사용자 이름 및 비밀번호는 발신 라우터에 구성된 것과 일치합니다.

   양방향 인증을 수행할 때 명령 ppp pap sent-username username password가 수신 라우터에 없고 PPP 클라이언트가 서버를 원격으로 인증하도록 강제하려고 시도하면 debug ppp 협상(또는 debug ppp authentication)의 출력은 다음과 같습니다

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

   이 오류 메시지는 컨피그레이션 문제를 나타내며 반드시 보안 침해일 필요는 없습니다.

3. 3. 사용자 이름 및 비밀번호가 피어의 ppp pap sent-username username password 명령에 구성된 것과 일치하는지 확인합니다.

   일치하지 않는 경우 다음 메시지가 표시됩니다.

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

관련 정보

• PPP 문제 해결 순서도
• PPP(CHAP 또는 PAP) 인증 문제 해결
• 디버그 ppp 협상 결과 이해
• PPP 인증 ppp chap hostname 및 ppp authentication chap callin 명령을 사용합니다.
• 전화 접속 기술: 개요 및 설명
• 기술 지원 및 문서 − Cisco Systems