Resumen

  • Cuando el intercambio incluye una respuesta, RFC 2025 concatena el randSrc del iniciador con el randTarg del destino para formar el Context ID. La presencia de ambos deja constancia de una aportación de frescura por cada parte.
  • SPKM-2 unilateral solo envía SPKM-REQ. El destino no aporta un aleatorio: debe confiar en que el del iniciador es nuevo o rechazar el contexto. key-src-bind enlaza mejor la solicitud y la clave propuesta, pero no crea participación del destino.
  • La repetición durante el establecimiento y los servicios opcionales replay/sequence de los mensajes posteriores son planos separados. El Context ID tampoco demuestra autorización, entrega ni resultado de negocio.

Un recibo con dos procedencias visibles

RFC 2025 definió el Simple Public-Key GSS-API Mechanism, SPKM. Sus tokens de establecimiento transportan muchos campos, pero la construcción del Context ID ofrece una lectura probatoria especialmente limpia. El iniciador proporciona randSrc; si el intercambio continúa con una respuesta, el destino añade randTarg. La concatenación de los dos valores se usa en los tokens sucesivos de ese contexto de seguridad.

Cada mitad tiene autor. El iniciador puede reconocer que el destino produjo algo para el intercambio actual; el destino sabe que su valor recién generado quedó incorporado junto al del iniciador. Por eso randSrc || randTarg funciona como un recibo bilateral de una afirmación muy concreta: con alta probabilidad, este contexto no reutiliza la identidad de uno anterior.

La precisión importa. RFC 2025 no exige que los aleatorios sean impredecibles. Exige que sea altamente probable que nunca se hayan usado. Su misión es evitar reutilización entre contextos, no ocultar un secreto. La supuesta fortaleza criptográfica del número no amplía lo que el recibo acredita.

La excepción de un solo token

SPKM-1 siempre obtiene respuesta del destino. En autenticación unilateral usa SPKM-REQ y SPKM-REP-TI; en la mutua añade SPKM-REP-IT. SPKM-2 mutuo también tiene respuesta. Esos recorridos dejan un lugar para que el destino inserte randTarg.

SPKM-2 unilateral no. El intercambio consta únicamente de SPKM-REQ, de modo que no existe token de retorno en el que el destino pueda contribuir. El Context ID queda reducido al aleatorio del iniciador. La especificación ofrece al destino dos opciones: confiar en la frescura de ese valor o rechazar el contexto.

No es solo una diferencia de latencia. En los intercambios con respuesta, quien acepta puede añadir su propia prueba de no reutilización al identificador común. En el caso unilateral, el destino renuncia a ese control y evalúa la afirmación del iniciador. El Context ID conserva utilidad como identificador, pero ya no atestigua una frescura construida entre dos partes.

El alcance exacto de key-src-bind

La especificación añade una defensa para SPKM-2 unilateral. Si el algoritmo de establecimiento de clave no enlaza por sí mismo el nombre de origen con la clave de contexto, SPKM-REQ debe incluir key-src-bind, el resumen MD5 del nombre de origen codificado y la clave propuesta.

Así, el destino dispone de una señal que une el origen declarado, el token recibido y la clave. RFC 2025 señala que también ayuda a confiar en la frescura del token y de la clave propuesta. Pero el campo sigue naciendo en la solicitud del iniciador. No añade una respuesta, no produce randTarg y no prueba que el destino generara material nuevo.

Vinculación, contribución de frescura y autenticación mutua son afirmaciones diferentes. Una pantalla que las comprime en un único “contexto establecido” pierde justamente la distinción que el protocolo conserva.

Dos preguntas distintas sobre replay

SPKM también puede ofrecer detección de repetición y control de orden para mensajes protegidos después del establecimiento. Son servicios basados en números de secuencia cuando la aplicación los solicita. No aparecen automáticamente porque el Context ID incorpore valores aleatorios.

La especificación general GSS-API, RFC 2743, trata replay y sequence por mensaje como opciones seleccionables. El llamante las pide, el aceptador informa de lo disponible y una implementación puede marcar duplicación o desorden mediante un estado suplementario sin impedir necesariamente que el mensaje llegue al llamante. La aplicación sigue siendo responsable del transporte de tokens.

Una auditoría debe separar, por tanto, el intento de distinguir este establecimiento de otro antiguo y la verificación de duplicados u orden dentro del contexto ya aceptado. El Context ID aporta evidencia para lo primero. Los indicadores negociados, el estado de secuencia y cada resultado de verificación aportan evidencia para lo segundo.

La escala correcta del registro histórico

El RFC Editor mantiene RFC 2025 como Proposed Standard de octubre de 1996 y, en esta revisión, la búsqueda de erratas no mostraba ninguna publicada. El registro SMI de IANA conserva identificadores de objeto para SPKM-1, SPKM-2, SPKM-3 y los tokens GSS de SPKM. Esto demuestra la historia de la especificación y de las asignaciones, no un despliegue actual.

RFC 2847 definió después SPKM-3 como equivalente a SPKM-1 salvo por cambios indicados. Sirve para seguir la genealogía del mecanismo, pero no altera el límite de RFC 2025: el Context ID solo se interpreta junto al patrón de intercambio que lo produjo.

La lectura segura es breve. randSrc || randTarg documenta una aportación bilateral de frescura al contexto. El Context ID de SPKM-2 unilateral documenta únicamente la aportación del iniciador, incluso con key-src-bind. Ninguno demuestra por sí solo autorización mediante certificados, selección de algoritmos, entrega de mensajes o conclusión de una operación.

Fuentes