Кратко

  • Response вычислялся из Identifier, общего секрета и нового Challenge Value; сам секрет по линии не передавался.
  • Success фиксировал совпадение локального расчёта в этом обмене. Обратное направление, полномочия, NCP и трафик требовали иных доказательств.

RFC 1994 задаёт три шага: authenticator посылает Challenge, peer возвращает Response, затем authenticator сравнивает свой расчёт и посылает Success или Failure. Response копирует Identifier вызова и хеширует Identifier + secret + Challenge Value. Для каждого нового Challenge должны меняться и Identifier, и значение.

Повтор вызова при том же секрете может вернуть силу перехваченному ответу; предсказуемость позволяет заранее получить будущий ответ. Поэтому документ требует уникальности и непредсказуемости, но не обещает защиты от активного перехвата в реальном времени.

Время выбирает authenticator. Он может снова послать Challenge даже в Network-Layer Protocol phase. Это новая проверка, а не продление прежней. Если Success потерян, повторный Response для текущего Identifier должен получить тот же reply Code: повтор доставки не меняет решения.

CHAP односторонний. Взаимная аутентификация требует отдельного согласования в обратном направлении, причём PPP допускает разные протоколы. Name помогает найти секрет системы, но не доказывает человека или право. По RFC 1661 каждый сетевой протокол ещё должен открыть собственный NCP.

Источники: RFC 1994, RFC Editor, RFC 1661, RFC 1334, IANA PPP.