개념 사전 · 개념

PPP의 PAP·CHAP 인증

PAP · CHAP · Password Authentication Protocol · Challenge Handshake Authentication Protocol

와 는 링크에서 선택적으로 사용하는 피어 인증 방식이다. 는 이름과 비밀번호를 직접 전달하는 반면 는 에 대한 공유 비밀 기반 응답을 검증하며 둘 다 데이터 패킷 암호화를 제공하지 않는다.

밑줄 용어에 마우스를 올리거나, 키보드로 선택하거나, 터치하면 설명을 볼 수 있습니다.

01무엇이고, 어떤 일을 하나

링크 상대가 사전에 등록한 인증 식별과 비밀을 알고 있는지 확인한다.
LCP에서 합의한 인증 요구 방향과 실제 · 메시지를 연결한다.
인증 성공 이후에도 IPCP·IPv6CP 등 네트워크 설정이 별도로 필요함을 구분한다.

02어떤 순서로 동작하나

요구 방향 합의
LCP의 -Protocol 옵션으로 어느 측이 상대 인증을 요구하는지 정한다. 한쪽에서 인증 방식을 지정한 것과 양쪽이 서로를 인증하는 것은 같지 않다.
또는 시작
에서는 인증받는 측이 이름·비밀번호를 보낸다. 에서는 검증 측이 를 먼저 보내므로 요청의 주도 방향과 교환 순서가 다르다.
응답 검증
-MD5의 역사적 형식에서는 Identifier·비밀·를 이용한 해시 결과를 대조한다. 암호문으로 비밀번호를 복호화하는 절차가 아니며 표시된 Name과 로컬 등록 식별이 맞아야 한다.
결과와 NCP 진행
성공·실패 메시지에 따라 인증을 끝내고 성공했으면 필요한 NCP 협상을 진행한다. 인증 성공만으로 주소나 원격 경로가 준비됐다고 판정하지 않는다.

03먼저 알아둘 용어와 구성요소

: 클라이언트가 이름·비밀번호를 포함해 보내는 요청이다.
: 검증 측이 재사용되지 않도록 선택한 도전 값과 식별자를 보내는 메시지다.
: 상대가 도전 값·식별자·공유 비밀로 계산해 보내는 결과다.
: 상대의 응답을 자신이 보유한 비밀과 비교하여 승인 여부를 결정하는 측이다.

LEARN THROUGH PRACTICE

PPP 링크에서 CHAP 인증과 IP 사용 준비를 구분하기

Serial 링크의 LCP 상태와 로그를 대조하여 회선 설정·인증·네트워크 계층 준비를 순서대로 확인한다.

실습 구성과 전제

R3와 R4의 Serial1/0을 연결하고 양쪽에 캡슐화를 설정하는 실습이다.
양쪽에 상대 이름을 인식할 인증 정보가 준비되어 있어야 한다. 예시에는 인증 비밀값을 넣지 않는다.

양단 캡슐화와 LCP부터 맞춘다
- 한쪽이 HDLC이고 다른 쪽이 이면 물리적으로 연결되어도 정상적인 협상이 성립하지 않는다. 양단에서 encapsulation 를 맞추고 인터페이스 상태를 확인한다.
- 화면에는 up/up, Encapsulation , LCP Open이 보인다. 이 부분만으로 다른 네트워크까지 이 완성되었다고 판단할 수는 없다.
text
```
interface Serial1/0
 encapsulation ppp
 no shutdown
end
show interfaces Serial1/0
```
실습 흐름을 재구성한 명령 예시. 장치·인터페이스 이름은 구성에 맞춰 사용한다.
원본 크기로 보기 ↗
- Serial1/0 is up, line protocol is up으로 표시된다.
- Encapsulation PPP, LCP Open이 보이며 IPv4 주소와 MTU 1500도 함께 나온다.
확인 기준
먼저 양단의 ·LCP 상태가 맞는지 본다. LCP가 열리지 않았다면 IP 경로를 추가하기 전에 회선과 캡슐화를 확인한다.
Challenge·Response·Success를 방향별로 읽는다
- 양방향 인증에서는 각 장비가 독립적으로 를 보내므로 두 교환이 섞인다. 로그의 O는 송신, I는 수신이며 id로 같은 인증 교환을 연결한다.
- 화면은 송신 id 9와 수신 id 9, 수신 id 3과 송신 id 3을 보여 준다. 비밀값 자체가 전송되는 와 달리 은 에 대한 응답을 검증한다.
text
```
interface Serial1/0
 ppp authentication chap
end
show interfaces Serial1/0
show logging
```
상대 이름과 인증 정보가 먼저 구성되었다는 조건의 명령이다. 화면은 기존 실습 로그이며 추가 debug 실행을 요구하지 않는다.
원본 크기로 보기 ↗
- O CHALLENGE id 9와 I RESPONSE id 9가 보인다.
- I CHALLENGE id 3·O RESPONSE id 3·I SUCCESS id 3 및 O SUCCESS id 9가 함께 기록되어 있다.
확인 기준
한 방향의 Success만 보지 말고 요구한 양방향 인증이 모두 완료되는지 확인한다. 성공은 데이터 암호화 성공이라는 뜻이 아니다.
인증 뒤 NCP와 실제 IP 전달을 검증한다
- 의 링크 확립과 선택적 인증이 끝나면 는 IPCP 같은 NCP를 통해 준비된다. 로그의 IPCP AUTHOR 요청은 과정의 증거이지 IPCP Open 자체를 대신하는 표시는 아니다.
- 확장된 인터페이스 출력에서 IPCP 상태를 확인하고 같은 링크의 상대 주소로 ping한 뒤 원격 경로를 확인한다. 실패 시 인증 실패와 경로·반환 경로 문제를 분리한다.
text
```
show interfaces Serial1/0
show ip interface brief
show ip route
```
실습 흐름을 재구성한 명령 예시. 장치·인터페이스 이름은 구성에 맞춰 사용한다.
확인 기준
현재 캡처에는 IP ping의 최종 성공 횟수가 없다. LCP와 성공 범위를 넘어서 종단 통신 성공을 주장하지 않는다.

실습에서 확인한 동작 원리

상태는 LCP → 선택적 인증 → NCP → 실제 패킷 전달로 나누어 확인한다.
은 인증이며 사용자 데이터의 기밀성을 자동 제공하지 않는다.

관련 개념·전체 실습 화면 이어서 읽기 →

동작·명령 참고 문서

RFC 1661 — PPP 링크 단계 ↗RFC 1994 — CHAP 교환 ↗

04예제로 따라가기

가상 LCP옵션 03 05 c2 23 05는 Type3·Length5· Protocol 0xc223·Algorithm 5를 뜻한다. 옵션 Length는 값만이 아니라 Type·Length까지 포함한 5바이트다.
는 도착하는데 의 Name에 맞는 로컬 계정이 없으면 검증이 실패할 수 있다. 실제 비밀 값을 출력에 붙이기보다 Name·식별자·방향·결과 메시지를 연결한다.
가 LCP Opened이고 Success인데 IPCP가 Req-Sent라면 인증 비밀을 다시 바꾸기보다 주소 옵션·상대 NCP 응답을 조사한다. 실패한 단계가 달라진 것이다.

05혼동하기 쉬운 점과 확인 기준

·는 레거시 실습 맥락의 기술 설명이다. 특히 비밀 값의 노출과 -MD5의 한계를 현대적인 데이터 암호화 보호로 오해하지 않는다.
가 달라진다고 임의의 추가 보안 속성이 모두 생기는 것은 아니다. 상호 인증·키 교환·기밀성은 해당 프로토콜이 실제로 제공하는지 별도로 판단한다.

06상세 노트 · 실습 자료

헤더 구조, 설정 예시, 수치 계산과 수업 캡처는 아래 노트에서 이어집니다.

PPP·LCP·PAP/CHAP와 네트워크 계층 협상Serial 링크의 캡슐화부터 LCP 옵션, PAP·CHAP 인증, IPCP 개방까지 원본 설정과 패킷을 연결하고, 각 단계의 실패 원인을 구분합니다.상세 노트 읽기 →

공식 문서 · 표준

기초 개념과 동작 설명을 대조한 자료입니다. 제품 버전과 실제 설정에 따른 차이는 본문 및 원문에서 확인하세요.