Resumen

  • RFC 3012 dio al agente extranjero de Mobile IPv4 un desafío propio para distinguir una respuesta reciente de un valor ausente, reutilizado o ajeno a su ventana conocida antes de que terminara AAA.
  • Acertar el desafío sólo demostraba relación con estado local reciente; aún hacían falta autenticación, autorización, aceptación del registro, estado de reenvío y tráfico observado.

La movilidad interdominio obligaba a actuar con conocimiento incompleto. El dispositivo estaba físicamente conectado al entorno visitado, pero las credenciales capaces de identificarlo podían residir en su red de origen. El agente extranjero debía decidir cuánto procesamiento dedicar a una Registration Request sin compartir necesariamente un secreto con el remitente.

Enviar todo a un verificador remoto dejaba un hueco temporal. Una solicitud antigua podía reaparecer mientras la infraestructura de Authentication, Authorization and Accounting seguía trabajando. El borde visitado necesitaba una prueba que naciera en su propio reloj operativo.

RFC 3012, publicado en noviembre de 2000, introdujo esa prueba. El agente extranjero podía incluir una extensión Challenge en sus Agent Advertisements. El valor debía ser aleatorio y, preferiblemente, tener al menos 32 bits. El nodo móvil lo copiaba en una extensión MN-FA Challenge de su solicitud de registro.

El origen del valor era la pieza política y técnica. No venía del dominio de casa ni de una autoridad universal, sino del agente que administraba el acceso local. Por eso éste podía reconocer una respuesta a su propia acción reciente antes de conocer el resultado de identidad. Frescura y confianza dejaban de fingir que eran el mismo hecho.

El protocolo prohibió usar el desafío como credencial independiente. Después de MN-FA Challenge debía aparecer Mobile-Foreign Authentication o MN-AAA Authentication. Una solicitud con desafío pero sin ninguna de esas extensiones tenía que descartarse en silencio.

Si existía una asociación de seguridad directa, Mobile-Foreign Authentication podía ligar el mensaje. Cuando no existía, el móvil debía usar MN-AAA y se recomendaba añadir el Network Access Identifier de RFC 2794. Su realm ayudaba a localizar el dominio verificador; el texto del nombre no probaba que quien lo enviaba fuera su titular.

El orden del paquete era un orden de evidencia. El desafío identificaba el estado reciente invocado. El autenticador ligaba datos a un secreto y un algoritmo señalado por el SPI. La infraestructura externa verificaba. La política autorizaba o negaba. La coincidencia de un campo no absorbía las decisiones posteriores.

Tres códigos conservaron la causa local. MISSING_CHALLENGE indicaba ausencia. STALE_CHALLENGE señalaba que ese nodo ya había usado el valor. UNKNOWN_CHALLENGE decía que el agente no lo encontraba ni como último desafío devuelto con éxito ni dentro de sus anuncios recientes de CHALLENGE_WINDOW. El registro de IANA mantiene los números asignados.

Reducir los tres a “falló la autenticación” borra una distinción operativa. Una estructura incompleta, una repetición histórica y una supuesta emisión que el agente no reconoce son incidentes diferentes. La respuesta correcta, la métrica útil y la investigación posterior también difieren.

Las pérdidas de red exigían una excepción. Si el móvil repetía la misma Registration Request con idénticos Identification y Challenge, y el agente aún conservaba el registro pending correspondiente, podía reenviarla al Home Agent. Fuera de esa transacción viva, volver a usar el desafío normalmente era stale.

Así, la defensa no consistía en rechazar bytes repetidos sin contexto. Dependía de memoria: emisor, nodo, valor, Identification, estado pendiente y vencimiento. La misma secuencia podía ser una retransmisión necesaria o un intento de recuperar una autorización antigua según el estado que la acompañara.

También había que ligar la respuesta distante. Si el desafío viajaba hasta el Home Agent, el agente extranjero debía guardarlo con la solicitud pendiente y rechazar una Registration Reply que no devolviera el mismo valor. Esa igualdad asociaba resultado y transacción; no demostraba que se hubiese instalado una ruta ni que una aplicación recibiera datos.

Cuando una relación directa MN-FA permitía validar y retirar el desafío antes de reenviar, el agente debía conservar localmente el Identification. El dato visible podía desaparecer del siguiente tramo, pero la obligación de explicar el límite de repetición permanecía.

RFC 3012 dejó la verificación completa fuera de Mobile IPv4. Su apéndice habló de una “verification infrastructure”. El agente extranjero podía enviarle el material de autenticación y esperar un resultado seguro. No fijó el protocolo interno ni exigió que el verificador fuera una entidad de Mobile IP.

Esa omisión era deliberada. El estándar definió una costura interoperable, no un monopolio administrativo. Los operadores podían usar sistemas AAA y políticas locales distintas, siempre que preservaran el significado de los campos y resultados que atravesaban la costura.

Para encajar con la infraestructura existente, CHAP_SPI 2 describió un cálculo MD5 de estilo CHAP compatible con prácticas de RADIUS. La propia consideración de seguridad advirtió que era más débil que HMAC-MD5 y debía evitarse cuando fuera posible. La vía de despliegue no fue presentada como destino criptográfico.

El mecanismo tampoco eliminó la denegación de servicio. Un atacante podía reproducir solicitudes y provocar una respuesta que pareciera rechazo mientras una aceptación legítima seguía en vuelo. El móvil podía actuar sobre el mensaje que llegara primero. Una prueba de frescura local no ordenaba mágicamente todos los eventos de extremo a extremo.

La longitud hacía visible otro límite. Con desafíos menores de cuatro bytes, el agente debía conservar también Identification para reforzar la unicidad. Llamar aleatorio a un valor corto no sustituía la entropía; la historia de transacción tenía que completar la evidencia.

RFC 4721 reemplazó RFC 3012 en 2007. Exigió registrar los desafíos aplicables por nodo móvil y prohibió volver a valores anunciados antes del último ya utilizado. Aclaró el procesamiento de anuncios y respuestas, añadió protección frente a mensajes falsos e incorporó una opción HMAC-MD5.

No hay base para convertir esas mejoras en relato de un ataque concreto. Sí permiten una conclusión sólida: la frescura sólo existe dentro de una historia ordenada. Importan quién emitió el valor, para qué nodo, cuál fue el último aceptado, qué solicitud sigue pending y qué autenticador cubre el intercambio.

La tesis tampoco repite RFC 2002. Aquella especificación construyó el binding temporal entre una home address y una care-of address. RFC 3012 trató el paso previo en el borde visitado: obtener una garantía local contra la repetición antes de que la autoridad remota aceptara o negara el binding.

Ni equivale a PPP CHAP. Allí el desafío pertenecía a una autenticación de enlace entre autenticador y peer. Aquí un agente extranjero incorporaba su señal de frescura a un registro Mobile IPv4 y podía recurrir a una infraestructura AAA independiente. Compartir MD5 no compartía gobierno.

La idea de especificación inicial mínima de Lu Heng ayuda a leer la arquitectura. Lo común era pequeño: formato, orden, ventana, errores y correlación. La elección de verificador, política de admisión y evolución futura quedaba localizada. Running-Code Primacy añade que una norma publicada no demuestra qué opción, algoritmo o ventana ejecutó una red real.

Un paquete puede probar que el desafío volvió. Un log criptográfico puede probar una verificación. Un registro de política puede probar autorización. El Home Agent puede probar que aceptó estado. El plano de datos puede probar paquetes. Mantener esas pruebas separadas es más exigente que pronunciar “challenge-response”, pero también es la única manera de saber qué ocurrió.

La puerta lanzó un desafío porque ésa era la pregunta que podía responder sola. La confianza aún debía llegar por una cadena más larga. RFC 3012 conserva valor histórico precisamente porque no ocultó esa dependencia.

Sources