Resumen

  • GSS_C_NO_CREDENTIAL no exigía necesariamente anonimato ni ausencia de identidad; pedía a la implementación de GSS-API que resolviera una credencial predeterminada según reglas locales.
  • RFC 1509 definió gss_cred_id_t como referencia opaca relativa al llamador. El mismo valor podía señalar credenciales diferentes en procesos distintos y no contenía por sí mismo información de seguridad.
  • El contexto autenticado no sustituía la autorización de la aplicación. Para atribuir una acción había que unir llamador, estado local, mecanismo, principal, flags, estado, peer y efecto.

Una constante con un verbo oculto

Una aplicación que no quería seleccionar explícitamente una credencial podía pasar GSS_C_NO_CREDENTIAL. Leído fuera del contrato, el nombre parece describir un vacío. Dentro de RFC 1509, activaba una resolución: usa la credencial predeterminada disponible para este llamador.

El establecimiento y alcance de ese valor por defecto quedaban en manos de la implementación. Por tanto, dos ejecuciones del mismo código podían afirmar principales distintos si cambiaban el usuario local, el servicio, la configuración, el mecanismo o el estado posterior a un reinicio.

RFC 2078, revisión Version 2 basada en experiencia de implementación, explicitó mejor la resolución del principal predeterminado, sus controles de autorización y sus fallos. Su ficha conserva esa evolución.

El argumento era pequeño; la decisión no. Una traza que conserva sólo la constante registra la petición, no la identidad que el sistema terminó usando.

El handle tampoco llevaba la credencial dentro

RFC 1509, Proposed Standard de John Wray publicado en septiembre de 1993 según su registro, definió gss_cred_id_t como dato atómico opaco para el llamador. Podía representarse con un puntero o un valor aritmético. Identificaba una credencial mantenida dentro de GSS-API o de su mecanismo.

El texto decía que el valor no contenía información relevante para la seguridad y no requería protección especial por parte de la aplicación. También admitía que el mismo valor identificara credenciales distintas cuando lo presentaban llamadores diferentes.

La igualdad numérica no establecía igualdad de objeto. Un proceso podía resolver el 7 hacia la credencial de Alice; otro, hacia la de Bob. Después de un reinicio, el 7 podía referirse a un registro recién creado. En otra máquina no tenía por qué existir.

La credencial, el principal que podía afirmar, el mecanismo que la entendía, su uso para iniciar o aceptar y su duración eran registros separados del handle.

El sistema operativo dibujaba el perímetro

RFC 1509 exigía definir el alcance. Una referencia podía limitarse al proceso adquirente, extenderse a sus hijos o compartirse entre procesos con una identidad local común, como un UID. El último handle podía determinar cuándo quedaba inaccesible la credencial.

La especificación abstracta, RFC 1508, asignaba a mecanismos del sistema y funciones del sistema operativo la restricción sobre quién podía obtener y utilizar las credenciales de un principal. Su registro muestra la relación con los bindings.

Usar una credencial equivalía a poder afirmar una identidad. Transferir esa capacidad entre procesos era una decisión local, no una propiedad automática de C.

RFC 1511 situó el trabajo en el grupo Common Authentication Technology: separar la implementación de la seguridad de la integración de datos de seguridad en los protocolos llamadores. Su registro enlaza la API genérica de RFC 1508, el binding C de RFC 1509 y mecanismos como Kerberos V5 y DASS.

La portabilidad estaba en la interfaz. La autoridad seguía mediada por el sistema que ejecutaba la llamada.

Contexto, conexión y token seguían relojes distintos

El ciclo descrito por RFC 1509 comenzaba con la adquisición de credenciales, continuaba con el establecimiento de un contexto compartido, permitía aplicar integridad o confidencialidad a mensajes y terminaba con la eliminación del contexto. Una sesión podía sobrevivir a varias conexiones y una asociación podía albergar varios contextos.

gss_ctx_id_t tenía la misma relatividad al llamador. Un valor igual podía identificar contextos diferentes. El estado criptográfico conjunto permanecía detrás del handle.

Lo que se transportaba al peer era un token de autenticación distinto: una cadena de bits opaca y protegida por el mecanismo, generada en un extremo para el mecanismo del otro. Las aplicaciones debían llevarla en su protocolo. Copiar el handle local no transportaba ese token, las claves, la aceptación del peer ni el contexto vivo.

Cuando el binding posterior quiso permitir movimiento entre procesos, RFC 2744 creó operaciones explícitas de exportación e importación. Exportar desactivaba el contexto de origen y producía un token interproceso; sólo debía existir una instancia activa. Como podía incluir claves, el token necesitaba protección y un receptor confiable. La ficha RFC 2744 registra que reemplazó a RFC 1509.

Mover estado exigía una transición controlada. Copiar un entero no era esa transición.

El nombre visible podía cambiar sin cambiar la identidad interna

RFC 1509 distinguió nombres imprimibles e internos. La forma legible podía depender de preferencias o configuración; un OID identificaba su espacio de nombres al importarla. gss_compare_names decidía igualdad interna, no la comparación ordinaria de cadenas.

La línea conceptual siguió en RFC 2743 y su registro. RFC 2744 señaló que volver a mostrar un nombre importado no tenía por qué recuperar la cadena original, ni siquiera el mismo identificador de espacio.

Así, el nombre de pantalla era una proyección. No era la credencial, y tampoco bastaba para saber qué cuenta autorizó después la aplicación.

Channel binding: una conjunción específica

RFC 1509 concatenaba el tipo y dirección del iniciador, el tipo y dirección del aceptador y datos de aplicación. El mecanismo ligaba ese material al establecimiento del contexto; una diferencia podía impedirlo. Algunos mecanismos podían incluir el material en el token, de modo que no debía contener secretos.

La coincidencia probaba una relación acotada entre ese intercambio GSS y los valores suministrados. No probaba propietario legal del canal, permiso de negocio, entrega o efecto. El llamador debía examinar flags solicitados y devueltos, estado mayor y estado específico del mecanismo. La aplicación aún decidía si el principal autenticado podía actuar.

Las consideraciones de seguridad de RFC 2744 mantienen ese límite: la API sola no ofrece garantía universal; importan el mecanismo y la conducta del llamador. El Datatracker de RFC 1509 acredita el documento, no una implementación, despliegue, vulnerabilidad o incidente.

Abstraer no era globalizar

Running-Code Primacy, de Heng Lu, exige verificar el contrato común en ejecución y resultado. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption defiende una capa común mínima que preserve decisiones locales. On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile separa referencias, identidades, decisiones y efectos.

RFC 1509 hizo portátil el modo de pedir servicios de seguridad. No convirtió la referencia local en identidad global. El llamador daba contexto al handle; el sistema mediaba la credencial; el mecanismo establecía el contexto; el peer procesaba tokens; la aplicación autorizaba; el sistema en marcha producía el resultado.

Las fuentes aquí reunidas prueban texto y linaje. No prueban cómo un producto nombrado representó handles, qué defaults eligió, qué se desplegó o si ocurrió un fallo.

El cero podía resolver una credencial. El mismo número podía resolver otra. Por eso la evidencia tenía que registrar el verbo oculto: quién pidió qué resolución, bajo qué política, y qué efecto siguió.

Fuentes

  1. Información de RFC 1509
  2. RFC 1509 — C bindings
  3. RFC 1509 en Datatracker
  4. Información de RFC 1508
  5. RFC 1508 — GSS-API
  6. Información de RFC 1511
  7. RFC 1511 — Common Authentication Technology Overview
  8. Información de RFC 2078
  9. RFC 2078 — GSS-API Version 2
  10. Información de RFC 2743
  11. RFC 2743 — GSS-API Version 2, Update 1
  12. Información de RFC 2744
  13. RFC 2744 — C bindings Version 2
  14. Heng Lu — Running-Code Primacy
  15. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  16. Heng Lu — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile