Resumen

  • El elemento AUTH_SESSION de RFC 3520 lleva una autorización acotada desde la señalización de sesión hasta una solicitud de reserva. Validar su firma no sustituye la comparación exacta de dirección, puerto, recurso, tiempo e identidad.
  • Una cadena probatoria útil conserva por separado el token, su frescura, la autoridad aceptada, la política del dominio, la decisión y aplicación de RSVP, las precondiciones SIP, el tráfico observado y el resultado autenticado de la aplicación.

El incidente hipotético cabe en una sola comparación. El token decía destino A, puerto 5004. La reserva decía destino A, puerto 5006. Ambos números podían parecer razonables; solo uno estaba dentro de la decisión firmada. Aceptar el segundo porque «la firma pasó» habría convertido una prueba de integridad en permiso para algo que la firma no decía.

RFC 3520, publicada en abril de 2003 en el Standards Track y actualmente registrada como Proposed Standard, define un Session Authorization Policy Element para autorización y control de admisión por sesión. El host obtiene el elemento durante la señalización y lo copia sin cambios al objeto RSVP POLICY_DATA. Así se conserva una afirmación entre planos de control sin confiar en que el host la reescriba.

La norma permite decidir sobre recursos. No declara que esos recursos se hayan reservado de extremo a extremo, que los medios hayan circulado o que la sesión haya cumplido su finalidad. Cada verbo necesita su propio recibo.

El permiso está en los campos, no en el sobre

AUTH_SESSION puede identificar a la entidad autorizadora y a la sesión; puede fijar origen, destino, inicio, fin y recursos; y puede incluir datos de autenticación. Los recursos pueden describirse como ancho de banda máximo, flow spec RSVP, descripción SDP o DSCP.

En el modelo no asociado todos los campos deben coincidir con la solicitud. Las direcciones del datagrama tienen que corresponder y la QoS pedida no puede superar la concedida. Una discrepancia debe provocar denegación.

Los puertos revelan por qué importa registrar ausencias. Si el atributo de una dirección no incluye lista de puertos, las reglas consideran válidos todos los puertos de ese lado. Si existe una lista, solo esos puertos están autorizados. «Campo procesado» no basta: el recibo debe mostrar el valor recibido, la regla de normalización, el valor observado y el resultado de la comparación.

Una prueba automatizada que solo cambia un bit de la firma verifica criptografía. Una prueba mejor altera destino, puerto, ancho de banda, DSCP y tiempo uno por uno, y demuestra que cada ampliación sale rechazada.

Cuatro modelos, cuatro ubicaciones del contexto

El modelo acoplado puede usar solo SESSION_ID, porque el mismo servidor de política participa en la decisión de servicio y la de recursos. El identificador remite al estado que ese servidor conserva. Que su formato quede a la implementación no elimina la necesidad de mantenerlo durante réplica, reinicio y conmutación.

En el modelo asociado se añade la identidad de quien autorizó. El borde puede localizar al servidor que guarda la decisión del medio. Si no sabe por otra vía que esa identidad corresponde a un servidor legítimo de su dominio, necesita datos de autenticación para impedir una redirección a una autoridad falsa.

La variante con dos servidores cruza una frontera administrativa: uno conoce el servicio, el otro gobierna el recurso. Deben quedar registrados la consulta, la respuesta y el criterio local. En el modelo no asociado, el token lleva suficiente contexto para una decisión autónoma porque el verificador puede no compartir estado con el emisor.

No hay una casilla universal llamada «token válido». Cada arquitectura deposita la verdad en lugares distintos y exige una ruta probatoria propia.

Una identidad auténtica todavía puede carecer de competencia

AUTHENTICATION_DATA protege los datos anteriores del elemento. El texto de 2003 describe mecanismos de clave compartida, Kerberos y clave pública; en el último caso incluye ruta de certificación, revocación y firma.

Después de establecer la identidad y validar la petición de servicio, el router o Policy Decision Point consulta tablas de política local. Su contenido es asunto del dominio. Si necesita información suplementaria, debe obtenerla de forma segura.

Es una separación institucional, no solo técnica. La firma demuestra que una clave aceptada protegió una declaración. La política local decide si el titular de esa clave puede comprometer ese recurso bajo esas condiciones. Un certificado no redacta la matriz de autoridad.

Los algoritmos históricos del documento no deben leerse como consejo criptográfico contemporáneo. Aquí interesan las fronteras de evidencia que define el protocolo.

El tiempo y la memoria son controles diferentes

La construcción del elemento exige START_TIME o SESSION_ID para prevenir replay. Con tiempo, la seguridad depende de la fuente de reloj, el desfase y la ventana aceptada. En el modelo no asociado los servidores deben soportar sincronización NTP, y la RFC advierte que relojes desincronizados pueden abrir la puerta a la repetición.

Con identificador, la seguridad depende del estado recordado. Un servidor de relevo que no recibe el registro de uso anterior puede aceptar de nuevo los mismos bytes. Una firma reproducida sigue siendo una firma válida.

Por eso el registro debe incluir origen temporal, offset, tolerancia, decisión del caché anti-replay o, alternativamente, nacimiento, uso previo y replicación durable del identificador. RFC 5905 ofrece contexto posterior de NTP; no demuestra la disciplina de reloj de una instalación concreta.

No todos los nodos tienen que entender el objeto

Un router RSVP consciente de política envía el mensaje al PDP y espera la respuesta. Uno que no es consciente ignora los objetos de política y continúa el procesamiento. Ver el elemento al principio y al final del camino no prueba que cada salto lo hiciera cumplir.

El mapa de control debe identificar PEP, PDP, nodos que ignoraron el objeto y estado realmente instalado. También debe retener cualquier modificación de recursos hecha por la política. La cobertura de enforcement es un hecho de topología observado, no una propiedad heredada del token.

Cuando el PDP no logra verificar el elemento, RFC 3520 prescribe Policy Control Failure, Error Code 02, y recomienda devolver detalle mediante AUTH_DATA. Ese código demuestra un tipo concreto de fallo. Que no aparezca no demuestra que la política local aceptó, que hubiese capacidad, que RSVP terminara ni que la aplicación funcionara.

RSVP y SIP mantienen la historia abierta

El marco RFC 3521 describe un avance escalonado: la gestión de sesión entrega el token; el host emite PATH; el borde consulta política; el servidor puede modificar recursos; RESV informa que la reserva está completa o todavía progresa. La repetición de «o progresa» impide tratar un evento intermedio como cierre.

RFC 3312 ofrece otro corte. Las precondiciones SIP mantienen estado deseado y actual. Si una precondición obligatoria no se satisface, el establecimiento queda suspendido y los medios no deberían fluir. Una actualización de QoS puede mover el estado actual, pero aún no acredita el flujo ni la experiencia de la aplicación.

Reservar una cola no prueba que llegara audio. Admitir una solicitud no prueba consentimiento. Recibir un mensaje SIP no prueba continuidad. El nombre del resultado debe coincidir con lo que se observó, no con el evento que resultó más fácil facturar.

Una cadena de recibos, no un único semáforo

Primero se conserva la solicitud de sesión, el actor autenticado y el principal operativo o jurídico. Después, identidad y alcance del autorizador, versión de su decisión, bytes exactos del token, referencia de credencial, resultados de cadena y revocación y control anti-replay.

Luego se comparan token y solicitud: origen, destino, puertos, recurso y vigencia. Se registra qué PDP decidió, qué política aplicó, qué modificó y qué PEP ejecutó. PATH, RESV y errores quedan correlacionados. Los saltos que ignoraron política se declaran.

Finalmente se añaden estados SIP deseado y actual, telemetría del transporte y resultado autenticado de la aplicación. La definición comercial de «completo» debe apuntar al último recibo requerido, no cambiar silenciosamente según qué sistema produjo primero un verde.

La cadena también debe resistir fallos. Un reinicio no puede borrar el replay; una deriva de reloj no puede ensanchar el mandato; una ruta nueva no puede mantener la etiqueta de admisión fuera de la zona de control conocida.

Límite de la evidencia

Este Artículo no identifica producto, fabricante, operador, router, servidor, cliente, usuario, sesión, flujo, incidente ni despliegue. No afirma uso actual, conformidad, seguridad, rendimiento, QoS ni resultado empresarial de ningún sistema.

RFC 3520 se trata como trabajo Standards Track de abril de 2003 actualmente Proposed Standard. RFC 3521, RFC 3313 y RFC 5866 conservan estatus y ámbitos propios. El dominio administrativo especializado de RFC 3313 no se extiende a Internet en general. Los documentos posteriores sobre NTP y Diameter solo aportan comparación.

Las notas de Heng Lu sobre autoridad y running code son lentes editoriales declaradas, no fuentes de intención del IETF. Ayudan a preguntar quién puede mandar y qué ocurrió realmente.

La conclusión es delimitada: una autorización puede coincidir casi por completo y aun así no cubrir la petición; incluso cuando sí la cubre, todavía no prueba la sesión entregada.

Fuentes