الخلاصة

  • تُحسب Response من Identifier والسر المشترك وChallenge Value متغيرة، من دون إرسال السر نفسه.
  • يعني Success أن المصادِق وجد تطابقاً محلياً لهذا التبادل؛ أما الاتجاه الآخر والتفويض وNCP وحركة البيانات فلها أدلة مستقلة.

يحدد RFC 1994 ثلاث حركات: يرسل المصادِق Challenge، ويرد الطرف بـ Response، ثم يقارن المصادِق حسابه ويرسل Success أو Failure. تنسخ Response معرّف التحدي، وتنتج قيمتها من تجزئة Identifier ثم secret ثم Challenge Value. ويجب تغيير المعرّف والقيمة مع كل تحد جديد.

التغيير يحد من إعادة التشغيل. فتكرار التحدي مع السر نفسه قد يعيد صلاحية جواب ملتقط، والتنبؤ به قد يسمح بالحصول على جواب المستقبل مسبقاً. لذلك يوصي النص بالتفرد وصعوبة التنبؤ، مع إقراره بأن CHAP لا يمنع التنصت النشط الآني.

المصادِق يملك توقيت السؤال، ويمكنه طرح تحد جديد أثناء مرحلة بروتوكولات الشبكة. هذا اختبار جديد لا تمديد للنجاح السابق. وإذا ضاعت رسالة Success وأعيدت Response الحالية، وجب إرجاع reply Code نفسه؛ إصلاح التسليم ليس حكماً جديداً.

المصادقة أحادية الاتجاه. ويتطلب التحقق المتبادل تفاوضاً مستقلاً في الاتجاه المعاكس، وقد يستخدم PPP بروتوكولاً مختلفاً لكل اتجاه. كما أن Name يفهرس سر نظام ولا يثبت شخصاً أو صلاحية. ووفق RFC 1661، لا تُحمل رزم طبقة الشبكة إلا بعد فتح NCP الخاص بها.

المصادر: RFC 1994، سجل RFC Editor، RFC 1661، RFC 1334، IANA PPP.