Resumen

  • RFC 1446 comprobaba por separado el resumen criptográfico y la vigencia temporal de un mensaje SNMPv2. Un MD5 correcto demostraba una relación con el secreto compartido bajo los supuestos del protocolo, pero no demostraba que el mensaje fuera reciente.
  • Mientras se conservara una clave privada de autenticación, partyAuthClock no podía disminuir. Reducirlo reabría un intervalo de marcas de tiempo; por eso el RFC exigía cambiar la clave en el mismo acto.
  • La recuperación necesitaba conservar una época de seguridad completa. RFC 3414 usaría más tarde la identidad del motor, un contador persistente de arranques y el tiempo del arranque actual, manteniendo separados el valor de autenticación y la prueba de oportunidad.

La restauración que volvió a admitir ayer

Un operador recupera la configuración no volátil de un agente después de un fallo. La copia contiene una identidad reconocida, el secreto correcto y un reloj de autenticación guardado horas antes. Nada parece corrupto. Sin embargo, la copia describe tres estados que no pertenecen necesariamente al mismo momento.

Antes del fallo, el agente ya había avanzado su noción del reloj de una parte hasta 120 000. Un intruso había capturado un mensaje marcado con 119 500. Con una vida útil de 300 segundos, aquella copia estaba fuera de plazo. Después de restaurar un registro que dice 119 400, la suma vuelve a favorecerla: 119 500 más 300 ya no queda por debajo de la hora local. El mensaje viejo cabe otra vez en la ventana.

No hizo falta calcular un MD5 nuevo. La repetición conserva exactamente los bytes cuyo resumen fue válido en el primer envío. Lo que cambió fue el juicio temporal del receptor. El equipo no recuperó el pasado; perdió la evidencia de haberlo dejado atrás.

Esta situación explica una de las reglas más precisas de RFC 1446: el reloj asociado a una parte debe crecer mientras se utilice la misma clave privada. Si el reloj disminuye, la clave debe cambiar simultáneamente. La nueva clave marca una discontinuidad que impide que los resúmenes de la época anterior aprovechen el intervalo numérico reabierto.

Autenticidad no era una sola casilla

RFC 1446 se publicó en abril de 1993 como documento Standards Track y hoy figura como Historic. Definía para SNMPv2 un protocolo de autenticación y otro de privacidad. En el perfil v2md5AuthProtocol, una parte empleaba 16 octetos de material privado y MD5 producía un resumen de 128 bits.

El emisor colocaba provisionalmente el secreto en el campo del resumen, serializaba esa forma del mensaje, la procesaba y sustituía el secreto por el resultado antes de transmitir. El receptor tomaba el resumen recibido, reconstruía la forma autenticada con su copia local del secreto, volvía a calcular y comparaba. Si los valores no coincidían, aumentaba snmpStatsWrongDigestValues y el mensaje era rechazado.

Pero el receptor ya había tenido que localizar más contexto que una clave. Necesitaba la parte fuente, su reloj localmente registrado y su vida útil. La prueba temporal descartaba el mensaje cuando se cumplía esta desigualdad:

authSrcTimestamp + vida útil < reloj de autenticación local

El descarte incrementaba snmpStatsNotInLifetimes. Así, dos mensajes podían contener resúmenes igualmente correctos y recibir resultados distintos porque uno pertenecía al intervalo admitido y otro no. También era posible que un mensaje reciente fallara por tener el resumen equivocado. Las dos dimensiones no se sustituían.

El término “auténtico” en la salida del procesamiento no debe convertirse en una afirmación universal. La coincidencia del resumen respalda integridad y origen bajo la clave conocida y los supuestos de MD5 del documento. La prueba de vida útil respalda una decisión local sobre frescura. Después aún quedaban la política de acceso y la operación solicitada. Mucho después podría observarse si algún estado externo cambió y si ese cambio persistió.

Una bitácora rigurosa conserva cada decisión: bytes recibidos, identidad atribuida, generación de secreto, resultado del resumen, reloj usado, ventana aplicada, decisión de acceso, respuesta del protocolo y comprobación independiente del resultado. Reducirlas a una marca verde de “autenticado” elimina justo las fronteras que permitían entender un incidente.

La ventana era política, no física

Los mensajes autenticados incluían marcas de tiempo de origen y destino con resolución de un segundo. La vida útil fijaba el retraso máximo que el administrador aceptaba. RFC 1446 pedía mantenerla tan pequeña como permitieran la precisión de los relojes, el tiempo de ida y vuelta y la frecuencia de las comprobaciones.

La recomendación dejaba visible un conflicto de incentivos. Una ventana corta distingue con mayor nitidez lo reciente, pero castiga retrasos y desajustes. Una ventana amplia reduce fallos operativos y al mismo tiempo prolonga el periodo durante el que una captura puede repetirse. Cambiar la vida útil no es simplemente “ajustar tolerancia”; modifica la política de riesgo del receptor.

Además, oportuno no quería decir irrepetible. Dos copias de un mismo mensaje podían entrar en la ventana. Para peticiones que modificaran estado, el RFC recomendaba esperar una confirmación positiva o la expiración antes de enviar la siguiente. La cautela protegía el orden práctico de las operaciones allí donde la combinación de digest y reloj no ofrecía semántica transaccional.

Una vez superadas la prueba temporal y la criptográfica, el agente consultaba el control de acceso. Solo cuando existía algún acceso permitido, las marcas autenticadas que excedían los registros locales podían adelantar de manera selectiva los relojes conocidos. El diseño no permitía que cualquier paquete enseñara la hora al receptor. Tampoco implicaba que adelantar el registro concediera permiso o produjera un efecto sobre el dispositivo.

El secreto nuevo cerraba el intervalo viejo

La obligación de cambiar la clave no era una ceremonia de higiene. Cerraba una relación matemática concreta. El mensaje capturado reunía dos propiedades: su resumen correspondía a la clave antigua y su marca había pertenecido a una ventana aceptada. Al retroceder únicamente el reloj, las dos propiedades volvían a coincidir. Al sustituir simultáneamente la clave, la marca podía parecer reciente, pero el resumen dejaba de ser reconocible.

RFC 1447 llevó la regla al modelo de información de las partes. La descripción de partyAuthClock prohibía reducir el valor a menos que cambiara al mismo tiempo la clave privada de autenticación. partyAuthLifetime expresaba en segundos el margen admitido. Estos objetos no eran piezas independientes de inventario: juntos delimitaban una época.

La actualización de un secreto también tenía una duración operativa. Una estación responsable decidía el cambio, enviaba una solicitud, esperaba entrega, confirmaba que el agente la había adoptado, sincronizaba a otras estaciones y solo entonces podía retirar el valor viejo. Durante ese tránsito podía necesitar ambas claves, y debía conservarlas incluso si ella misma se reiniciaba.

Por eso “se envió una rotación” es una afirmación mucho más débil que “todos los participantes operan en la nueva época”. Un recibo de transporte no demuestra aplicación. La aceptación local de una petición no demuestra que otro gestor aprendió el valor. La eliminación prematura del secreto anterior puede causar una interrupción; conservarlo sin límite amplía una ambigüedad de confianza.

Aprender la hora sin creerla todavía

El protocolo suponía relojes aproximadamente sincronizados y al menos una estación de gestión responsable de coordinar el tiempo y distribuir secretos. Si las claves no cambiaban, la sincronización debía llevar la noción más lenta hacia la más rápida. No debía hacer bajar la más adelantada y reabrir un tramo bajo la misma clave.

Había una excepción útil para arrancar el conocimiento. Un gestor que ignoraba si su reloj coincidía con el del agente podía hacer primero una consulta no autenticada. El valor recibido servía como candidato. Después de adoptarlo, debía repetir la consulta con autenticación para confirmar la nueva base.

La primera observación no adquiría autoridad por ser necesaria. Seguía siendo una afirmación no autenticada que ayudaba a localizar al interlocutor. La segunda observación añadía evidencia ligada al secreto. Esta separación entre descubrimiento y confirmación anticipa una disciplina que todavía falta en muchos sistemas de inventario: un dato puede ser útil para orientar el siguiente paso sin ser prueba suficiente para cerrar el caso.

Con varias estaciones responsables, el problema dejaba de ser solo técnico. ¿Cuál podía iniciar una nueva época? ¿Cómo aprendían las demás el reloj y la clave? ¿Qué confirmación autorizaba destruir el secreto anterior? RFC 1446 exigía coordinación local porque ningún campo del mensaje podía resolver por sí solo la gobernanza entre custodios.

Sobrevivir al apagado sin fingir continuidad

La identidad de cada parte, su reloj de autenticación, su clave privada de autenticación y su clave privada de privacidad debían contar con representaciones no volátiles e incorruptibles. La vida útil merecía el mismo tratamiento cuando fuera posible. No bastaba con que una base tuviera columnas para esos valores; la implementación debía preservar su relación a través del fallo.

El reloj podía mantenerse con alimentación de respaldo. También podía guardarse periódicamente y, al reiniciar, avanzar de manera conservadora más allá del máximo que habría podido alcanzar desde el último punto. El objetivo no era reconstruir el segundo exacto perdido, sino no volver a una zona donde el secreto antiguo ya había validado tráfico.

Si un agente permanecía apagado hasta que el reloj alcanzaba su máximo, el valor quedaba detenido allí. La única petición de gestión autenticada que debía enviarse era una que cambiara, como mínimo, el reloj y la clave. Si los parámetros protegidos se perdían, el documento indicaba reemplazarlos por valores aleatorios y exigir redistribución manual. La recuperación fallaba de forma visible antes que inventar una continuidad.

La estación responsable que detectaba un reinicio podía tener que restaurar otros atributos de la parte, incluida la vida útil si no había persistido. El procedimiento incluso podía adelantar artificialmente una marca para que el mensaje de reparación autenticado entrara en la ventana. Recuperar era, por tanto, crear una transición coherente y verificable, no copiar ciegamente el último archivo disponible.

Un contador hizo posible que el tiempo empezara de cero

El modelo USM de RFC 3414 adoptó después otro modo de representar la época. Un snmpEngineID identifica al motor SNMP autoritativo. snmpEngineBoots cuenta sus reinicios o reinicializaciones y debe sobrevivir en almacenamiento no volátil. snmpEngineTime cuenta segundos dentro del arranque actual.

El temporizador puede volver a cero porque el contador de arranques avanza. Un mensaje de una ejecución anterior lleva el número de época equivocado aunque su tiempo interno se parezca al del presente. El receptor autoritativo rechaza un contador distinto o una hora fuera de la ventana fija de 150 segundos.

Cambió la estructura, no la necesidad de dos pruebas. El valor de autenticación seguía sin bastar para demostrar oportunidad. Y si el motor no podía determinar de manera fiable su último contador, debía fijarlo en el máximo, con lo que los mensajes autenticados fallaban la prueba temporal hasta que una intervención manual estableciera otra identidad de motor o nuevos secretos de usuario.

RFC 3414 no sustituyó directamente a RFC 1446; hubo pasos intermedios en la evolución de SNMP. La comparación importante es conceptual. RFC 1446 protegía la monotonía de una hora continua mediante una transición de clave. RFC 3414 permitía reiniciar el tiempo local gracias a una identidad y un contador persistente. Ambos exigían saber en qué época se había producido el mensaje.

Sources