Resumen

  • CHAP calculaba la respuesta sobre Identifier, secreto compartido y Challenge Value cambiante, sin transmitir el secreto.
  • Success sólo confirmaba la comparación del autenticador para ese intercambio; el sentido opuesto, la autorización y la entrega de tráfico quedaban fuera.

La RFC 1994 fijó tres mensajes: Challenge desde el autenticador, Response desde el par y Success o Failure tras la comparación local. Response copiaba el Identifier del reto y su valor era el hash de Identifier + secret + Challenge Value. Un nuevo reto debía cambiar tanto el Identifier como el valor.

La variación hacía caducar una respuesta capturada. Repetir un reto con el mismo secreto abría la puerta al replay; predecirlo permitía pedir anticipadamente la respuesta futura. Por eso la RFC recomendó retos únicos e impredecibles, aunque reconoció que CHAP no detiene la escucha activa en tiempo real.

El autenticador controlaba el momento y podía volver a preguntar durante la fase de protocolos de red. Esa posibilidad medía otra vez; no prolongaba la prueba anterior. Si se perdía Success, el par podía repetir Response y el autenticador debía devolver el mismo código para el Identifier vigente: retransmisión no era una nueva decisión.

La dirección importaba. CHAP era unilateral. La autenticación mutua exigía negociar otro intercambio en sentido contrario, incluso con un protocolo distinto. El Name ayudaba a buscar el secreto de un sistema; no acreditaba por sí solo a una persona, una cuenta o una autorización.

RFC 1661 mantenía separado el resultado operativo. Cada protocolo de red necesitaba abrir su NCP antes de transportar paquetes. Success no probaba cifrado, dirección IP, ruta, recepción ni entrega de aplicación.

Fuentes: RFC 1994, registro RFC Editor, RFC 1661, RFC 1334, IANA PPP.