Resumen

  • El checksum 0x8003 del autenticador reúne un hash de los enlaces de canal aportados, flags de contexto y, de forma opcional, un KRB_CRED con un TGT reenviable.
  • Ni los dieciséis ceros de ausencia de enlace, ni un KRB_AP_REQ sin retorno, ni una credencial transferida, ni un MIC o Wrap válido sustituyen la confirmación, autorización y aceptación de la aplicación.

La diferencia entre una carta certificada y un sobre bien rotulado es el acuse. RFC 1964 rotula sus sobres con gran precisión: OID de Kerberos V5, marco GSS-API y códigos de dos bytes para cada clase de token. Esa disciplina reduce ambigüedad de formato, pero el acuse solo aparece cuando el protocolo y la aplicación lo piden.

El mecanismo publicado en junio de 1996 usa el OID 1.2.840.113554.1.2.2. Un KRB_AP_REQ inicial lleva 01 00; KRB_AP_REP lleva 02 00; KRB_ERROR, 03 00. Para mensajes, IANA conserva 01 01 como MIC y 02 01 como Wrap. El código indica qué estructura debe analizarse. Si la estructura falla la verificación, pertenece a otra sesión o llega fuera de tiempo, su etiqueta no la rescata.

Lo que realmente resume Bnd

RFC 1964 reserva el checksum del autenticador para transportar contexto GSS-API. Los primeros cuatro bytes dicen que Bnd mide 16 bytes. Los siguientes dieciséis contienen MD5 de los componentes no nulos del enlace aportado por quien llama, con reglas específicas para longitudes y orden de bytes.

Hay un caso especialmente revelador: GSS_C_NO_BINDINGS produce dieciséis bytes cero. No son el hash de la conexión “normal”. No demuestran dirección, TLS, interfaz ni identidad del canal. Expresan que el mecanismo no recibió datos de enlace. Para convertir el campo en una defensa, las aplicaciones deben haber acordado antes qué canal vinculan y deben aportar valores comparables.

Después vienen seis bits con apariencia de lista de garantías. Delegación, autenticación mutua, detección de repeticiones y secuencia reflejan simultáneamente una petición del iniciador y la disponibilidad del servicio. Confidencialidad e integridad indican disponibilidad para tokens por mensaje. Por eso un bit activo no equivale a una acción consumada. Describe el contexto que puede ofrecerse, no el resultado de cada uso.

El retorno separa unilateral de mutuo

Sin mutual_req, la secuencia no incluye un token de vuelta de la meta. El KRB_AP_REQ puede permitir que la meta autentique al iniciador; el iniciador no recibe por ello confirmación de la meta. Decir “autenticación mutua” a partir de la petición sería añadir un paquete que nunca existió.

Con mutual_req, KRB_AP_REQ marca mutual-required y el checksum marca la petición mutua. La meta debe responder con KRB_AP_REP o KRB_ERROR. El análisis debe separar esos dos desenlaces: KRB_AP_REP válido completa con éxito el intercambio mutuo; KRB_ERROR informa del fracaso. “Hubo respuesta” no es una categoría suficiente.

Tampoco conviene estirar KRB_AP_REP. Confirma el intercambio de establecimiento, no la aceptación de una operación posterior. Un servidor puede autenticar un contexto y luego denegar una acción por política, datos o estado.

Delegar no borra al autorizador

Si la delegación está activa, el valor del checksum añade la opción 1, una longitud y un mensaje KRB_CRED. El TGT transferido tiene el flag FORWARDABLE. La meta recibe así material que puede servir para obtener tickets posteriores.

Entre recibir y actuar quedan varios escalones: validar y descifrar KRB_CRED, almacenar la credencial, comprobar vida y alcance, pedir un ticket para un servicio concreto y superar la autorización de ese servicio. Un registro de KRB_CRED prueba transferencia, no acceso final. El flag de delegación prueba aún menos si faltan el campo opcional y su validación.

Los mensajes tienen su propia contabilidad

MIC protege la integridad de datos que viajan aparte. Wrap lleva los datos con integridad y posible cifrado. Ambos usan números de secuencia con un indicador de dirección. Sin embargo, la detección de repetición y desorden es opcional y puede desactivarse a petición de la aplicación.

Una comprobación MIC correcta responde a una pregunta criptográfica. Un Unwrap correcto responde a otra. La aplicación todavía debe entender el contenido, vincularlo a una política, ejecutar una transición y emitir su propio resultado. La secuencia puede demostrar orden dentro del contexto sin demostrar aceptación fuera de él.

RFC 4121 actualizó el mecanismo y RFC 6649 retiró algoritmos débiles del horizonte recomendado. Este artículo no convierte DES o MD5 en consejo actual. Conserva, en cambio, una idea histórica fértil: las especificaciones mínimas funcionan cuando cada participante puede verificar localmente el estado que necesita y cuando ningún símbolo invade decisiones que pertenecen al siguiente sistema. Es una aplicación editorial de la primacía del código en ejecución, no una afirmación sobre la intención política de los autores.

Fuentes