Resumen

  • RFC 3652 separó una Message Envelope fija de 20 octetos, destinada a entrega y reensamblaje, de una cabecera de 24 octetos y un cuerpo propio de cada operación. La firma digital de Message Credential no cubría la envoltura, pero sí la cabecera y el cuerpo.
  • Credential podía llevar una firma del originador o un código de autenticación de mensaje basado en una clave de sesión ya establecida. Ese límite describe el alcance de integridad del protocolo; no documenta un ataque, un fallo de implementación ni la imposibilidad de proteger capas inferiores.

Un mensaje, superficies de confianza distintas

En 2003, la especificación del protocolo Handle tenía que resolver algo más que una consulta. El cliente debía localizar el servidor responsable, pedirle que resolviera o administrara un Handle y entender la respuesta. Además, los mensajes podían atravesar redes que entregaban los datos de formas distintas. La versión 2.1 de RFC 3652 dividió esas funciones en cuatro piezas contiguas: Envelope, Header, Body y Credential. RFC 3652

La Envelope siempre estaba presente y medía exactamente 20 octetos. El RFC la describe como una envoltura de entrega, no como información de aplicación. Entre sus campos figuran la versión y las banderas del protocolo, un identificador de sesión, otro de solicitud, un número de secuencia y la longitud del mensaje. El Header obligatorio medía 24 octetos y reunía campos comunes como los códigos de operación y respuesta. El Body contenía datos específicos de la operación y podía estar vacío. RFC 3652

El límite de confianza no coincidía con el límite del paquete. RFC 3652 dice expresamente que la firma digital de Message Credential no protegía el contenido de Envelope, pero sí el Header y el Body. Una Credential no vacía podía contener una firma digital del originador o un código MAC unidireccional basado en una clave de sesión preestablecida. El documento presenta el Credential como mecanismo para autenticar un mensaje y comprobar su integridad durante el tránsito. Un MAC depende de un secreto compartido; una firma digital usa otro modelo de claves. RFC 3652 RFC 2104

La separación respondía a la función de la envoltura. Un cliente Handle podía usar datagramas UDP o un flujo TCP. RFC 3652 limitaba a 512 octetos los mensajes llevados por UDP, sin contar las cabeceras IP y UDP. Los mensajes más largos debían fragmentarse, y cada fragmento llevaba su número de secuencia en Envelope para permitir el reensamblaje. TCP no eliminaba el encuadre propio de Handle: su flujo de bytes también necesitaba límites de mensaje, y el protocolo podía fragmentar mensajes grandes antes de reunirlos. RFC 3652 RFC 768 RFC 793

Header y Body, en cambio, describían lo que el cliente y el servidor hacían. El código de operación pedía un tipo de tarea Handle; el de respuesta informaba el resultado: éxito, valor inexistente, referencia a otro servicio, denegación de autorización o autenticación requerida. El protocolo seguía un modelo de nombres y datos definido por separado, mientras RFC 3650 describía la arquitectura del servicio. El contenido semántico protegido empezaba después de la envoltura de entrega: reensamblar un fragmento no equivalía a autorizar la operación que transportaba. RFC 3652 RFC 3650 RFC 3651

Autenticación no era autorización

RFC 3652 también separaba la prueba del cliente de la decisión de permiso del servidor. Para acciones administrativas, el servidor podía enviar un desafío; el cliente respondía demostrando que poseía la clave privada o secreta correspondiente. Incluso después de validar esa prueba, el servidor tenía que comprobar si el administrador disponía de privilegios suficientes para la operación solicitada. Superar el desafío no autorizaba por sí solo un cambio en un Handle. Una sesión podía compartir estado y claves entre varias operaciones. RFC 3652

RFC 3552 trata la integridad, la autenticación del interlocutor, la confidencialidad y la seguridad del sistema como objetivos distintos; una firma o un MAC no proporcionan automáticamente todos. La sección de seguridad de RFC 3652 habla de firmas del servidor y autenticación del cliente, pero la definición del formato es más acotada: Credential cubre Header y Body, no la envoltura de entrega. Esa frase no demuestra que un mensaje se modificara en un sistema desplegado. Un canal de una capa inferior podría aportar otras protecciones; el RFC es una especificación, no un informe de incidente. RFC 3552 RFC 3652

Tampoco debe confundirse la Credential Handle con el perfil de firmas X.509. RFC 3279 define identificadores y codificaciones para certificados y listas de revocación de esa PKI; no amplía los octetos firmados por RFC 3652 ni convierte la Envelope en contenido autenticado. El vocabulario criptográfico no basta: hay que precisar qué objeto se autentica. RFC 3279 RFC 3652

RFC 3652 tiene categoría Informational, y su nota del IESG afirma que las discusiones no habían producido consenso del IETF sobre el sistema Handle ni sobre cómo encajaba en su arquitectura de identificadores. Describe un protocolo propuesto, no una adopción universal. Su enseñanza es más modesta: el encuadre, el reensamblaje y la autenticación pueden obedecer reglas distintas; cualquier afirmación de integridad debe indicar qué bytes cubre realmente Credential. RFC 3652

Fuentes