要約

  • Response は Identifier、共有秘密、毎回変わる Challenge Value から計算され、秘密そのものは回線を渡らない。
  • Success は認証側の期待値との一致だけを示す。相互認証、権限、NCP、通信成果は別の証拠である。

RFC 1994 では、authenticator が Challenge を送り、peer が Response を返し、authenticator が自分の計算と比較して Success または Failure を返す。Response は Challenge の Identifier を写し、その値は Identifier、secret、Challenge Value の連結に対する一方向ハッシュである。新しい Challenge ごとに Identifier と値の双方を変えなければならない。

この変化がリプレイの期限を作る。同じ秘密で Challenge を再使用すれば、傍受済み Response が再び通用し得る。予測可能なら、将来の答えを先に引き出され得る。規格は一意性と予測困難性を求める一方、リアルタイムの能動的盗聴までは防げないとした。

問いの時刻は authenticator が握る。Network-Layer Protocol phase 中にも再度 Challenge を送れるが、それは以前の Success を連続証明へ変えるのではなく、新しい照合を作る。Success が失われて同じ Response が再送された場合、現在の Identifier には以前と同じ reply Code を返す。配送の修復は再審査ではない。

CHAP は一方向である。相互認証には反対方向の別交渉が必要で、PPP は方向ごとに異なる方式さえ許す。Name も秘密表の索引であり、自然人や権限の独立証明ではない。RFC 1661 では、その後さらに各 NCP が Opened になって初めてネットワーク層パケットを運べる。

出典：RFC 1994、RFC Editor、RFC 1661、RFC 1334、IANA PPP。