요약

  • RFC 1994는 재사용 가능한 비밀번호 전송을 인증자가 주도하는 챌린지, 그리고 Identifier와 공유 비밀, 그리고 매번 바뀌는 Challenge Value로 계산되는 응답으로 대체했다.
  • Success는 해당 교환에 대한 로컬 일치 여부 검증을 기록했다. 상호 인증에는 반대 방향의 별도 협상이 필요했으며, 권한 부여, NCP 상태, 전달된 트래픽은 결과 범위 밖에 남았다.

1996년 8월,RFC 1994는 CHAP을 이전의 통합 PPP 인증 사양에서 분리해냈다. 이 교환은 PPP가 데이터 링크를 수립하고 인증 프로토콜을 협상한 뒤에만 시작되었다. 인증자가 Code 1, Challenge를 보내면 피어가 Code 2, Response를 돌려보냈다. 인증자가 기대값을 계산한 뒤 Code 3, Success 또는 Code 4, Failure를 전송했다.

응답은 링크를 통해 전송된 비밀번호가 아니었다. 그 값은 세 입력, 즉 Challenge Identifier, 양쪽 끝이 알고 있는 비밀, 그리고 Challenge Value를 연결한 것의 단방향 해시였다. Response는 Challenge Identifier를 그대로 복사했고, Success나 Failure는 Response Identifier를 복사했다. Challenge Value와 Identifier는 새 챌린지마다 바뀌어야 했다. 이 규칙들은 가로챈 응답이 하나의 특정 질문에 대한 답이 되도록 만들었지, 상시 자격 증명이 되게 하지 않았다.

이 보호는 그 질문이 진정으로 새로운 것이라는 데 의존했다. RFC 1994는 고유하고 예측 불가능한 챌린지 값을 권장했다. 같은 비밀로 챌린지를 재사용하면 가로챈 응답이 재사용 가능해질 수 있었다. 예측 가능성은 공격자가 미래의 질문에 대한 답을 미리 얻게 할 수 있었다. 그럼에도 이 RFC는 실시간 능동 도청에 대한 보호를 약속하지 않았다.

시계의 소유자는 인증자였다. 인증자는 링크 수립 후, 그리고 네트워크 계층 프로토콜 단계를 포함한 임의 간격으로 다시 챌린지를 보낼 수 있었다. 반복 챌린지는 한 번의 성공적 공격이 유용할 수 있는 기간을 줄였다. 하지만 첫 Success를 지속적인 증명으로 바꾸지는 않았다. 이후의 각 챌린지는 자신만의 Identifier와 값으로 새로운 비교를 만들어냈다.

방향 역시 엄격했다. RFC는 CHAP 인증이 단방향이라고 명시한다. 양방향으로 CHAP을 협상하면 상호 인증을 제공할 수 있지만, 그것은 두 개의 별도 행위였다. PPP는 전이중 인증이나 양방향 동일 프로토콜을 요구하지 않았고, RFC는 같은 비밀을 양방향으로 쓰지 말 것을 권고했다.

따라서 Success는 정밀한 증거적 의미를 가졌다. 인증자는 해당 챌린지에 대해 자신이 기대하는 값과 같은 Response Value를 받은 것이다. 이는 자연인을 독자적으로 식별하거나, 계정 자격을 증명하거나, 비밀이 어떻게 저장되는지 보여주거나, 지속적인 보관을 보장하거나, 링크를 암호화하거나, 사람이 읽을 수 있는 Message 필드를 검증하지 않았다. Message는 프로토콜 동작에 영향을 미치는 것이 명시적으로 금지되어 있었다.

유실 또한 경계를 드러냈다. Success가 사라지면 피어는 같은 Response를 반복할 수 있었다. 인증자는 해당 현재 Challenge Identifier에 대해 이전에 사용한 것과 동일한 응답 Code를 돌려주어야 했다. 전달 복구는 새로운 인증 결정이 아니었다.

RFC 1661은 다음 수령들을 별도로 유지했다. 인증 이후에도 모든 네트워크 계층 프로토콜은 여전히 자신의 NCP를 필요로 했고, Opened 상태의 NCP만이 그 패킷을 운반할 수 있었다. CHAP Success는 IP 주소, 경로, 패킷 도착 또는 애플리케이션 결과를 증명하지 않았다.

출처:RFC 1994;RFC Editor 기록;RFC 1661;RFC 1334;IANA PPP 번호 할당.