Resumen

  • RFC 3983 declaraba listo un canal BEEP después de aceptar el perfil IRIS, pero esa condición solo habilitaba el intercambio para los tipos anunciados; no autenticaba por sí misma al servidor ni al usuario.
  • Cifrado, identidad del servidor, identidad del usuario y autorización de datos podían combinarse de varias formas. Las referencias añadían otro límite: una conexión cifrada no convertía al siguiente servidor en destinatario legítimo de las credenciales.

El cliente recibe una referencia, abre una conexión con el siguiente servidor y descubre que el perfil esperado ha sido aceptado. El canal ya está listo. ¿Debe reenviar las mismas credenciales? RFC 3983 respondía que no bastaba con la continuidad técnica. IRIS funcionaba mediante referencias como parte normal de su operación, y cada destino introducía una nueva pregunta de confianza.

La ficha oficial, el registro de erratas y el historial de Datatracker sitúan la especificación en enero de 2005 y en Standards Track. Su función era mapear Internet Registry Information Service sobre BEEP, Blocks Extensible Exchange Protocol. El expediente documental no mide implantación ni acredita un servicio actual.

BEEP aportaba funciones que un transporte específico habría tenido que recrear: delimitación de mensajes, autenticación, gestión de conexiones y negociación. También ofrecía herramientas y experiencia operativa. Los autores descartaban HTTP para esta finalidad por la posible confusión con aplicaciones Web y por las prácticas divergentes de TLS; el TCP directo no ofrecía la negociación que necesitaba un cliente conducido por referencias a servidores con parámetros diferentes. Era una preferencia razonada, no una medición universal de superioridad.

El URI del perfil combinaba la versión del esquema IRIS con el URN del tipo de registro. Durante la creación del canal podían ofrecerse varios elementos profile. La aceptación permitía acordar qué versión usar para cada tipo servido. En ese instante el canal se consideraba listo para mensajes IRIS, y el servidor debía atender consultas de todos los tipos que hubiera anunciado en cualquier canal abierto con el perfil correspondiente.

Atender no significaba conceder. El patrón por defecto era una pareja: el cliente enviaba MSG con XML IRIS válido; el servidor respondía RPY con XML IRIS válido, o empleaba ERR para fallos BEEP. Los tipos de registro podían definir otros patrones compatibles, aunque debían conservar el básico para lookupEntity. El núcleo IRIS y su estado mantenían por encima las decisiones sobre búsquedas, permisos y resultados. El canal hacía posible la pregunta, no garantizaba la respuesta.

La autenticación del servidor exigía una secuencia separada. Cuando se usaba el perfil de ajuste TLS de BEEP, cada tipo de registro debía definir preferentemente su método. Si no lo hacía, se aplicaba el básico. El cliente presentaba el nombre de la autoridad solicitada mediante serverName. El servidor devolvía un certificado X.509 con ese nombre. Primero se verificaba criptográficamente el certificado conforme a TLS; después se comparaba su sujeto con la autoridad, siguiendo el orden previsto entre dNSName y formas del subjectDN.

Una cadena válida para otro nombre no probaba el servidor buscado. Un nombre coincidente en un certificado no verificado tampoco. RFC 3983 conservó ambos controles porque respondían a preguntas distintas: si el certificado era criptográficamente aceptable y si representaba a la autoridad que el URI había pedido.

La lista de requisitos de un tipo de registro hacía imposible suponer una política común. Cada especificación debía declarar el patrón de mensajes y, por separado, definir autenticación TLS del servidor, elegir el método básico o declarar que no habría autenticación del servidor. Un perfil aceptado podía, por diseño explícito, abrir un canal sin esa prueba de identidad.

La identidad del usuario tampoco era consecuencia del TLS. RFC 3983 enumeraba SASL DIGEST-MD5 y OTP para autenticar usuarios sin cifrar la sesión. Enumeraba usos de TLS para cifrado, y variantes con certificado de cliente para sumar autenticación del usuario. El acceso anónimo podía existir sin haber usado ningún perfil de autenticación o mediante SASL ANONYMOUS. El conjunto de estados no era una escalera única: podía haber cifrado sin usuario identificado, servidor identificado sin usuario identificado, o usuario identificado sin permiso para una entrada.

La separación procedía de BEEP. RFC 3080, su estado, sus erratas y su expediente Datatracker definieron perfiles, canales, mensajes y ajustes. RFC 3081 y su ficha mapearon BEEP sobre TCP. Ajustar una sesión podía cambiar una propiedad de seguridad sin certificar las demás.

Las fuentes contemporáneas delimitan los mecanismos disponibles. RFC 2246 y su estado especificaron TLS 1.0. RFC 2222 y su ficha dieron el marco SASL citado. RFC 2817, con su estado, y RFC 2818, con el suyo, documentaron las formas de HTTP/TLS discutidas. Que el mecanismo existiera no probaba que una conexión lo hubiera aplicado bien.

La referencia devolvía la cuestión a la custodia de secretos. El texto desaconsejaba SASL PLAIN y prohibía usarlo antes de cifrar la sesión TCP. Pero incluso tras el cifrado, el cliente debía evitar entregar credenciales a servidores no confiables. La confidencialidad del trayecto no otorgaba legitimidad al receptor.

Después apareció otra asignación de transporte: RFC 4992 y su ficha actualizaron el núcleo con XPC sobre TCP. La secuencia demuestra que el transporte era modular; no explica por sí sola adopción, abandono ni causalidad.

El registro de esquemas URI de IANA conserva iris.beep, y el registro de parámetros BEEP de IANA conserva los espacios de perfiles y ajustes. Son registros de nombres de protocolo, no recibos de conexión, identidad o autorización.

RFC 3983 dejó una regla operativa más duradera que su tecnología concreta: “listo” debe llevar apellido. Listo para mensajes no es listo para confiar, entregar secretos o considerar verdadera una respuesta. Cuando un sistema reduce todos esos estados a una sola luz verde, pierde precisamente la evidencia que necesitará al investigar el siguiente salto.

Sources