Resumen

  • RFC 1446 permitía que una parte SNMPv2 actualizara su secreto antes de preparar la respuesta, de modo que el acuse podía usar una clave que el gestor todavía no había incorporado.
  • El silencio dejaba dos estados opuestos: petición perdida y clave antigua en ambos lados, o respuesta perdida y clave nueva solo en el agente.
  • Como el secreto no era legible, un valor público novedoso servía de testigo; hasta resolverlo, el gestor debía guardar las claves antigua y nueva incluso tras reiniciar.

Dos explicaciones para el mismo silencio

La RFC 1446 describió el cambio de un secreto existente como un intercambio protegido. El gestor generaba el valor, enviaba una setRequest y esperaba la respuesta antes de modificar su propia base. El receptor procesaba la orden antes de responder.

Si la respuesta faltaba, el protocolo no podía deducir el camino. Tal vez la petición nunca llegó y el secreto anterior seguía activo. Tal vez la operación se ejecutó y fue la respuesta la que desapareció. En ese caso, repetir con la clave vieja podía producir un fallo precisamente porque la primera escritura había funcionado.

El estado privado no podía consultarse. Leer la clave para reconciliarla habría destruido la confidencialidad que el sistema intentaba proteger. La seguridad cerraba una vía de observación y obligaba a diseñar otra.

El propio acuse podía parecer falso

La carrera era más aguda cuando una parte cambiaba su propio secreto. El destino actualizaba su base antes de generar la respuesta. Esa respuesta se construía con la clave nueva. El gestor, por diseño, no actualizaba su copia hasta recibirla.

Así, una respuesta legítima podía llegar a un verificador que solo conocía la clave anterior. Si no contemplaba la transición, la clasificaría como inauténtica. Orden enviada, entrega, escritura local, respuesta generada, respuesta recibida y respuesta aceptada formaban una cadena, no una casilla de “éxito”.

El registro de RFC 1446 la clasifica como histórica. MD5 y DES documentan una decisión de 1993 y no deben convertirse en consejo actual. La enseñanza procede de la secuencia distribuida, no de recomendar aquellos algoritmos.

Una señal visible sin publicar el secreto

La salida propuesta fue adjuntar un valor público reconocible y nuevo. Al modificar el secreto de autenticación, el gestor escribía también el campo público de autenticación; al cambiar el de privacidad, hacía lo mismo con el público de privacidad. Si faltaba el acuse, podía leer ese marcador.

La Party MIB separaba los componentes públicos de los privados, además del reloj y la vida útil. El marcador no era la clave ni permitía derivarla. Probaba una transición identificable en una superficie que sí admitía lectura.

Su alcance era concreto. Encontrar el marcador indicaba que el cambio había alcanzado el estado del receptor. No demostraba que la base del gestor ya coincidiera, que el secreto sobreviviera a una caída, que la siguiente operación fuese autorizada o que hubiera efecto en el servicio.

Conservar ambas era conservar la posibilidad de volver

Desde el envío hasta la confirmación, el gestor tenía que retener la clave anterior y la propuesta. La red podía retrasar la respuesta durante mucho tiempo. RFC 1446 exigía prepararse para conservar ambas incluso a través de reinicios.

El controlador no debía escribir solo el futuro deseado. Tenía que persistir los dos resultados posibles de la transacción. Si eliminaba la clave vieja y la petición nunca había llegado, perdía el acceso. Si eliminaba la nueva y solo se había perdido la respuesta, también podía quedar fuera.

La recuperación incluía identidad de parte, claves privadas y reloj de autenticación en representaciones no volátiles. El reloj debía avanzar de forma monótona pese a fallos de energía. Recuperar el proceso sin recuperar ese conjunto podía dejar mensajes genuinos fuera de ventana y exigir resincronización administrativa.

Integridad no era orden ni autorización

El digest compartido pretendía probar origen e integridad. El reloj y la vida útil acotaban retraso y repetición. No impedían borrar o suprimir mensajes. La propia RFC advertía que una respuesta autenticada ausente no probaba una caída del agente o de la red; el aviso de fallo podía perderse por desfase temporal o desacuerdo de secretos.

Tampoco había un orden general de mutaciones. El gestor debía esperar el acuse positivo o la caducidad antes de enviar el siguiente cambio. snmpSetSerialNo, definido en la MIB de SNMPv2, aportaba una ayuda específica para ordenar operaciones Set. No certificaba persistencia ni efecto.

El modelo administrativo añadía partes, contextos y políticas de acceso. Autenticar el origen de un mensaje no resolvía por sí solo qué objetos podía cambiar ese actor ni si la modificación alcanzó la realidad operativa.

El marcador reapareció en USM

La arquitectura evolucionó. La RFC 1910 experimentó con usuarios, identidad de agente, reinicios, tiempo y control de acceso. La RFC 2574 y la RFC 3414 llevaron el modelo de seguridad basado en usuarios a SNMPv3.

El método posterior conservó el problema a la vista. Objetos KeyChange aplicaban una transformación unidireccional, un bloqueo coordinaba escritores y usmUserPublic guardaba un valor aleatorio. Si la respuesta no llegaba, el gestor leía ese campo para saber si la nueva clave estaba activa.

La persistencia del marcador no convierte el modelo de partes en práctica vigente. Revela una constante: cuando se cambia un secreto ilegible por un canal no fiable, hace falta evidencia independiente del acuse.

Fuentes