Resumen

  • La imposibilidad de leer value no resuelve el permiso para ejecutar test. Con NACM activo, una sesión ordinaria necesita lectura de todas las instancias antecesoras que identifican la acción y autorización de ejecución. Las reglas coincidentes deciden primero; solo en su ausencia interviene exec-default, cuyo valor estándar es permit.
  • La acción compara el MAC candidato con otro calculado localmente y devuelve únicamente verdadero o falso. Puede ayudar a verificar un aprovisionamiento, pero no acredita autenticación de paquetes, recepción por un vecino ni preparación para retirar una clave anterior. Durante una rotación, el tráfico puede seguir dependiendo de ella.

El secreto permanece oculto mientras alguien solicita su uso

Imaginemos al operador ante una clave cuyo contenido no puede consultar. Dispone de una cadena binaria y de un MAC candidato que espera que corresponda a esa cadena. Si está efectivamente autorizado, puede enviarlos a test. La implementación calcula un MAC con la clave y el algoritmo configurados, compara ambos valores y devuelve indication, de tipo booleano. La respuesta no contiene los bytes secretos ni el MAC calculado localmente. RFC 9647, §2.3.

El supuesto permite separar dos facultades que una revisión superficial podría reunir bajo una sola etiqueta de acceso: conocer el secreto y solicitar una operación que lo utiliza. El operador carece de la primera. La segunda depende de una decisión independiente. Que el resultado sea pequeño limita lo que recibe, pero no elimina la necesidad de decidir quién puede provocar el cálculo.

La pregunta tampoco termina al comprobar que la solicitud está permitida. Una organización puede autorizar una comparación para resolver una duda concreta de aprovisionamiento. Otra decisión, mucho más amplia, sería aceptar ese mismo resultado como justificación suficiente para cerrar una rotación. Entre ambas aparece una segunda responsabilidad: determinar qué conclusión está facultado para sostener quien recibe el booleano.

El nombre identifica la clave; los indicadores describen sus usos

RFC 9647 reúne en cada entrada de clave los campos name, use-send, use-verify, value y algorithm, además de la acción anidada test. La hoja value lleva la anotación nacm:default-deny-all. La protección de esa hoja pertenece al control de acceso a sus datos; la acción tiene su propia evaluación de ejecución. RFC 9647, §2.3.

El modelo de información de RFC 9046 explica por qué hace falta un nombre: permite identificar la instancia cuando el valor de la clave no se puede leer. Su §3.8 exige que la implementación no permita leer ese valor y define la prueba como una forma de comprobar si la clave y el algoritmo producen el resultado esperado. RFC 9046, §3.8.

Ese nombre ofrece una referencia administrativa. No establece quién posee o custodia el material secreto, quién lo aprovisionó ni quién tiene permiso para usar la interfaz de prueba. Tampoco convierte a quien puede verlo en titular de la clave. La referencia ayuda a formular una solicitud precisa; la autorización determina si esa solicitud puede ejecutarse.

Los indicadores mantienen otra separación. use-send describe el uso de la clave para calcular un MAC que se incorpora a paquetes enviados; use-verify describe su utilización para verificar paquetes entrantes. Ninguno constituye una concesión de permisos de gestión. Tampoco son, por sí solos, constancias de paquetes realmente enviados o aceptados. RFC 9046, §3.8.

Por tanto, una evaluación necesita conservar varios significados sin intercambiarlos: identidad de la instancia, uso previsto en el protocolo, acceso de lectura y facultad de ejecutar una comparación. La comodidad de mostrar todos esos datos en una misma vista no los convierte en una misma autoridad.

La autorización exige lectura de los antecesores y ejecución de la acción

Para una sesión ordinaria con NACM activo, RFC 8341 §3.1.3 establece dos condiciones para invocar una acción YANG: acceso de lectura a todas las instancias de nodos de datos antecesores que la identifican y permiso exec sobre la propia acción. La hoja value es hermana de test, no uno de sus antecesores. Su protección no autoriza ni deniega, por sí misma, la prueba. RFC 8341, §3.1.3.

Esta distinción produce consecuencias en ambas direcciones. Poder leer los antecesores no basta si la ejecución está denegada. Disponer de una regla que permite ejecutar tampoco basta si falta la lectura necesaria para llegar a la instancia. Y no poder leer el valor secreto no impide automáticamente satisfacer las dos condiciones anteriores.

La evaluación depende además de qué reglas corresponden a la identidad y los grupos de la sesión. NACM procesa las listas y reglas aplicables en el orden configurado; la primera coincidencia decide permitir o denegar. La correspondencia considera, entre otros elementos, el módulo, la ruta y la operación solicitada. Una restricción escrita en algún lugar de la configuración no demuestra que sea la que resolverá la petición. RFC 8341, §3.4.5.

Si ninguna regla coincidente resuelve la ejecución, se aplica exec-default, cuyo valor estándar es permit. Esto no desplaza una regla que ya decidió la solicitud ni elimina la lectura de los antecesores. RFC 8341 §5.1 identifica los valores predeterminados y sitúa en el administrador la responsabilidad de comprobar si resultan apropiados. RFC 8341, §§3.4.5 y 5.1.

La respuesta a quién puede invocar test es, por ello, condicional: la identidad cuya sesión satisface los controles efectivos sobre esa instancia. Puede tratarse de una persona o de una cuenta utilizada por automatización. El nombre del puesto, la etiqueta «diagnóstico» o la ausencia de lectura del secreto no sustituyen esa evaluación.

Nada de esta combinación demuestra acceso universal, una elusión de NACM o un fallo de una instalación concreta. Los documentos permiten identificar qué habría que comprobar. No proporcionan la política efectiva de un sistema determinado ni una lista de sus cuentas autorizadas.

Quién decide el permiso efectivo

La implementación materializa la acción y sus controles. Quien administra la política de acceso determina las reglas y los valores aplicables. La gestión de identidades aporta usuarios y pertenencias a grupos. Finalmente, una persona o un proceso presenta la solicitud bajo una sesión concreta. Los grupos locales y, cuando están habilitados, los grupos proporcionados por el transporte participan en la evaluación de NACM. RFC 8341, §§3.4.5 y 5.1.

De esta distribución se desprende una cuestión organizativa: el responsable de la clave puede no controlar todos los mecanismos que permiten usarla. Aprobar su aprovisionamiento no equivale a decidir quién hereda permisos mediante un grupo general. Del mismo modo, quien modifica una política de diagnóstico puede ampliar la población capaz de solicitar comparaciones sin tocar el valor protegido.

Una evaluación útil debería identificar, para una cuenta y una instancia determinadas, qué permite leer los antecesores, qué resuelve la ejecución y qué contexto de grupos interviene. Si la solicitud llega al valor predeterminado, conviene reconocerlo expresamente. Una concesión deliberada y un permiso que resulta de la ausencia de reglas pueden producir la misma autorización técnica, pero dejan explicaciones administrativas diferentes.

La comprobación también necesita corresponder a la identidad que realizará el trabajo. Una prueba hecha con una cuenta administrativa no acredita los derechos de una cuenta de servicio. Un resultado histórico tampoco resuelve automáticamente una solicitud futura después de cambiar reglas o pertenencias. El objeto de la revisión es la facultad efectiva de ese actor, bajo esas condiciones, para usar esa clave mediante esa acción.

Estas son propuestas de evaluación y responsabilidad. No constituyen un procedimiento adicional impuesto por los RFC.

Una utilidad legítima: comprobar sin redistribuir el secreto

La acción tiene una utilidad clara cuando se necesita verificar un aprovisionamiento sin entregar la clave al operador de diagnóstico. Como diseño organizativo posible, un proceso autorizado puede preparar la cadena y el MAC esperado y proporcionar ese par a quien realizará la prueba. El operador obtiene una expectativa verificable sin recibir por ello los bytes de la clave.

RFC 9046 define precisamente la operación de comprobación mediante una cadena y un MAC calculado, mientras RFC 9647 presenta test como un medio para validar la configuración de la clave y del algoritmo. La distribución de funciones entre quien prepara el par y quien lo presenta es una opción de gobierno construida sobre esa capacidad. RFC 9046, §3.8; RFC 9647, §4.

El valor de la prueba depende de la procedencia de la expectativa. Una coincidencia es más útil para una decisión de aprovisionamiento cuando puede explicarse por qué ese par corresponde a la clave que se pretendía instalar y por qué se dirigió a la instancia correcta. Un booleano aislado no conserva esa explicación.

También importa quién eligió cada elemento. Si un mismo proceso selecciona el destino, prepara el patrón y declara completada la verificación, la organización puede obtener una comprobación de consistencia interna. Para afirmar que se verificó la intención de otra parte, necesitará además establecer la relación entre esa intención y los elementos utilizados. La coincidencia no crea independencia entre quienes producen y aceptan la evidencia.

Un resultado positivo tampoco demuestra que el solicitante conozca la clave. Puede haber recibido legítimamente el par de prueba. Atribuirle posesión del secreto a partir de su capacidad para presentar un MAC correcto confundiría el origen del dato de entrada con el permiso para consultar la acción.

El booleano sostiene una decisión limitada

Una comparación completada permite responder una pregunta precisa: si el MAC candidato coincide con el calculado localmente para la cadena presentada, con la clave y el algoritmo utilizados. El alcance definido de la respuesta termina ahí. RFC 9647, §2.3.

La diferencia entre los posibles registros de una solicitud resulta decisiva:

Registro disponible Decisión que puede respaldar Límite que debe conservarse
indication=true en una comparación completada Dar por satisfecha esa comprobación local, si la instancia y la expectativa están identificadas No acredita recepción ni autenticación de tráfico real
indication=false en una comparación completada Revisar la discrepancia entre el resultado local y el candidato No identifica por sí solo si el problema está en la cadena, el candidato, la instancia, la clave o el algoritmo
Denegación de acceso Revisar la autorización de esa solicitud No constituye una comparación con resultado falso
Solicitud sin respuesta concluyente Mantener la ejecución o su resultado sin confirmar No permite afirmar que la prueba falló ni que se completó

Como criterio de decisión, una coincidencia puede justificar avanzar desde «pendiente de comprobación local» a «comprobación local satisfecha». Para que esa formulación resulte útil, debería conservar la referencia a lo que se probó. La expresión general «clave validada» pierde precisión si oculta la entrada, la expectativa o el momento.

Una discrepancia también merece una interpretación limitada. Es evidencia de que la comparación no produjo la coincidencia esperada, no un diagnóstico completo sobre su causa. Transformarla inmediatamente en una orden de sustitución podría actuar sobre una suposición equivocada. Antes de ampliar la decisión, conviene saber qué supuesto del ensayo dejó de sostenerse.

La rotación exige evidencia que distinga la clave nueva de la antigua

RFC 8967 contempla una rotación con solapamiento: se incorpora la nueva clave, ambas participan durante la transición y después se retira la anterior. Los paquetes llevan MAC calculados con las claves; no transportan sus bytes secretos. En la comprobación MAC de recepción basta una coincidencia entre los valores calculados y los recibidos para superar esa etapa. RFC 8967, §§4 y 5.

La consecuencia analítica es estrecha, pero importante: el tráfico que continúa funcionando durante el solapamiento puede seguir dependiendo de la clave antigua. Una prueba local satisfactoria de la nueva no identifica cuál sostuvo la aceptación en el otro extremo. Reunir ambos datos —coincidencia local y continuidad— tampoco elimina esa ambigüedad.

La autenticación de paquetes tiene además condiciones propias. RFC 8967 describe el cálculo sobre el paquete y su pseudocabecera, la transmisión de los MAC y el procesamiento de recepción, incluidos contador, índice y desafíos. La comparación de una cadena suministrada a una interfaz de gestión no acredita que ese recorrido haya ocurrido. RFC 8967, §§4–6.

Por ello, ni test, ni el nombre administrativo de la clave, ni los indicadores use-send y use-verify bastan para declarar recepción por un vecino, estado de rutas, preparación para el cambio definitivo o salud de la red. Cada afirmación necesita evidencia correspondiente al hecho que describe.

Para decidir la retirada de la clave anterior, la evidencia relevante tendría que distinguir la aceptación atribuible a la nueva de la continuidad que todavía podría sostener la antigua. El mecanismo concreto dependerá de lo que pueda observarse y acreditarse en la implementación. No puede presumirse una capacidad de atribución que estos documentos no proporcionan para un sistema concreto.

La prueba conserva así una función útil dentro de la rotación: reducir una incertidumbre local sobre la clave y el algoritmo. Quien autoriza su uso debe saber qué incertidumbre resuelve; quien autoriza la retirada debe hacerse cargo de las que permanecen abiertas.

El costo de conceder demasiado y de restringir demasiado

Un acceso excesivamente amplio extiende el conjunto de personas y procesos capaces de solicitar cálculos con una clave, aunque nadie reciba sus bytes. La amplitud debe evaluarse respecto del propósito: qué identidades necesitan la comparación, sobre qué instancias y para respaldar qué decisiones. Recibir únicamente un booleano no vuelve irrelevante esa distribución.

Un acceso demasiado estrecho puede impedir una comprobación legítima, retrasar un aprovisionamiento o crear dependencia de un pequeño grupo de administradores. Como efecto organizativo posible, también puede incentivar solicitudes de credenciales más amplias o de acceso directo al secreto para resolver una tarea que la acción permitiría atender con menos información. Son incentivos a considerar, no conductas observadas en un despliegue.

RFC 9647 aporta una razón técnica para tratar la acción con cuidado: señala la necesidad de controlar el acceso y advierte sobre posibles canales laterales, incluido el tiempo de respuesta. Indica con fuerza normativa SHOULD que las implementaciones comparen el MAC suministrado y el generado localmente en tiempo constante. No es una afirmación de filtración observada. RFC 9647, §4.

La calidad de esa comparación y la selección de usuarios autorizados atienden problemas diferentes. Una implementación cuidadosa no decide qué equipo necesita usarla. Una política restrictiva tampoco demuestra que la implementación siga la recomendación de comparación.

El equilibrio de gobierno consiste en conceder una facultad suficientemente útil para su finalidad, con un alcance que pueda explicarse. La frecuencia permitida, las ventanas de uso o las condiciones de aprobación serían decisiones locales; no deben presentarse como propiedades que la definición de test impone automáticamente.

Un registro debe explicar quién pidió la prueba y qué se decidió

Para auditar la autorización conviene poder relacionar la identidad de la sesión, la instancia de clave, el contexto de acceso y el momento de la solicitud. Para auditar el resultado hace falta, además, vincular la prueba con su expectativa y con el estado relevante de la configuración. Para auditar la decisión posterior se necesita saber qué se aprobó a partir de ese resultado.

Esta propuesta no exige registrar los bytes secretos. Puede apoyarse en referencias verificables al par de prueba y a su procedencia, con acceso al detalle sujeto a la política correspondiente. Tampoco supone que el modelo entregue por sí solo un expediente completo: la salida definida de test es el booleano. RFC 9647, §2.3.

Las cuentas de servicio requieren especial cuidado interpretativo. Una entrada que identifica una cuenta de automatización puede atribuir la invocación a esa identidad técnica. Por sí sola no identifica a la persona que solicitó el trabajo, a quien lo aprobó o al evento que lo desencadenó. Si varios flujos utilizan la misma cuenta, su nombre no permite separarlos retrospectivamente.

La atribución puede terminar legítimamente en una ejecución automática, sin una intervención humana inmediata. En ese caso, interesa conservar qué flujo actuó, qué condición lo activó y quién administraba su facultad de hacerlo. Confundir al propietario de la cuenta con el autor de cada solicitud borraría esa diferencia.

Las fuentes permiten establecer la frontera normativa y la semántica de la prueba. No documentan una política efectiva, una fuga, un ataque ni un resultado de red. La conclusión pública es concreta: mantener ilegible una clave deja abierta una decisión separada sobre quién puede solicitar su uso. Una autorización bien explicada vincula esa facultad con un propósito; una conclusión bien fundada conserva el tamaño real de la evidencia obtenida.

Fuentes

  • RFC 9647, §§2.3 y 4: modelo YANG, entradas y salida de test, protección de value y consideraciones de seguridad.
  • RFC 8341, §§3.1.3, 3.4.5 y 5.1: lectura de antecesores, ejecución de acciones, evaluación de reglas y valores predeterminados de NACM.
  • RFC 9046, §3.8: modelo de información de la clave MAC y finalidad de su prueba.
  • RFC 8967, §§4–6: procesamiento de paquetes autenticados, rotación con solapamiento y formatos.