Resumen

  • RFC 3961 separó la clave base de las claves específicas y convirtió el número de uso, público y distinto de cero, en una entrada obligatoria para cifrar o comprobar integridad.
  • El perfil simplificado derivaba materiales distintos para checksum, cifrado e integridad; una comprobación correcta acreditaba esa combinación, no la autoridad del usuario ni el resultado del servicio.

Un oráculo no necesita responder preguntas en lenguaje natural. Basta con que acepte texto y devuelva un cifrado útil. La sección de seguridad de RFC 3961 recordó que ciertas implementaciones compartían claves entre Kerberos v4 y v5: la operación disponible en una versión podía ayudar a atacar la otra. Una misma clave había unido dos contextos que el protocolo trataba como distintos.

La respuesta del RFC fue más amplia que prohibir aquella combinación. Publicado en 2005, definió una interfaz entre Kerberos y sus sistemas de cifrado y checksum. Cada mecanismo debía especificar formato de clave, conversión desde contraseña o aleatoriedad, derivación, estado, cifrado, integridad y función seudoaleatoria. El número de tipo identificaba ese paquete de reglas, pero no sustituía su definición.

Del contexto semántico a la clave concreta

Kerberos podía comenzar con una clave de larga duración o de sesión. RFC 3961 la llamó clave de protocolo o clave base y recomendó que no tocara datos de usuario: debía alimentar una derivación unidireccional. La clave concreta de una operación surgía de esa base y de un número de uso asignado por la especificación que consumía el mecanismo.

Los números de uso son enteros de 32 bits, públicos y no nulos. Su fuerza no consiste en ocultarse, sino en separar funciones. En el perfil simplificado, cuatro octetos del número se concatenan con 0x99, 0xAA o 0x55. Así aparecen Kc para checksum, Ke para cifrado y Ki para integridad. Incluso dentro de un mismo uso, cifrar y autenticar no dependen del mismo material derivado.

El confusor aleatorio impedía que textos iguales produjeran señales triviales y reducía el valor de un oráculo de cifrado. La derivación por uso hacía otra cosa: un mensaje de un tipo no debía adquirir validez sólo porque otro tipo compartiera la clave base. Era una defensa contra la confusión de protocolos, no una declaración de que cualquier algoritmo incluido fuese fuerte.

Un etype no era un hecho operativo

RFC 1510 contenía la especificación anterior de Kerberos V5. RFC 4120 la reemplazó en el plano del protocolo y utilizó la abstracción separada de RFC 3961. La división permitió que nuevas familias criptográficas llegaran sin incrustar sus detalles en cada mensaje.

RFC 3962 incorporó AES al marco. Después, RFC 4537 permitió que cliente y servidor negociaran tipos: una lista ofrecida, una preferencia, una decisión local y una subclave elegida. El registro de parámetros Kerberos de IANA prueba que un identificador fue asignado y remite a su documento. No prueba que un dominio lo habilitó ni que una sesión lo seleccionó.

El recibo criptográfico tenía límites

Al descifrar, el mecanismo debía comprobar el HMAC y descartar los datos si fallaba. Si pasaba, el sistema podía afirmar que ciphertext, clave derivada, uso y etiqueta eran compatibles. Para afirmar más necesitaba otros registros: qué principal estaba asociado a la clave, qué mensaje exigía ese uso, la vigencia del ticket, el control de repetición, la decisión de la aplicación y el efecto final.

RFC 6113 aplicó el marco a la preautenticación generalizada. Aun allí, completar una operación criptográfica no absorbió la emisión del ticket ni la autorización de una aplicación. Un registro serio enlaza cada etapa y conserva hashes y referencias de versión, nunca los bytes secretos de la clave.

La abstracción sobrevivió a sus primeros algoritmos

RFC 6649 desaconsejó DES simple. RFC 8429 actualizó RFC 3961 y retiró más algoritmos heredados. Esos actos cambiaron la recomendación normativa; no demuestran que todos los despliegues migraran.

RFC 8009 ofrece la prueba más interesante de continuidad. Sus tipos AES con HMAC-SHA2 cumplen el marco general, pero no el perfil simplificado: autentican el ciphertext antes de descifrar. La construcción que RFC 3961 había recomendado pudo quedar atrás sin perder la interfaz que separaba protocolo y criptosistema.

La ficha de RFC Editor y el historial de Datatracker documentan la publicación. La lista de erratas distingue una corrección Unicode verificada, una cuestión técnica de DES retenida para futura actualización y una propuesta rechazada. Son estados editoriales distintos y ninguno, por sí solo, prueba un fallo de producción.

RFC 3961 convirtió una intuición de seguridad en disciplina de protocolo: la misma clave no debía hablar con una sola voz en todas partes. El número de uso hizo comprobable la diferencia. La autorización siguió perteneciendo a quien debía decidirla.

Fuentes