Resumen

  • El núcleo principal de CBT iniciaba la política y las claves, pero un nodo autenticado podía heredar el material y distribuirlo a quienes se incorporaran después.
  • La carga central disminuía a cambio de ampliar el conjunto de routers privilegiados; el propio RFC proponía concentrar de nuevo la distribución en los núcleos si no era aceptable confiar en todos.
  • Una clave común acreditaba pertenencia al ámbito compartido, no la identidad del emisor, y borrar a un miembro de la lista no revocaba el secreto que ya poseía.

El coste que no aparecía en el contador de mensajes

Un centro de distribución puede contar cuántas operaciones se ahorra cuando deja de cifrar una copia de la clave para cada receptor. El contador es útil, pero incompleto. No registra cuántos routers pasan a custodiar el secreto, cuántas copias de la lista de acceso deben coincidir ni cuántos lugares pueden admitir por error a un receptor.

Ese intercambio está en el centro de RFC 1949. El documento partía de que una KDC tradicional debía autenticar a cada miembro y proteger para cada uno la clave de sesión del grupo. Multicastar juntas las copias cifradas no evitaba producirlas una a una. Para grupos amplios, el cuello de botella seguía intacto.

El registro del RFC Editor fecha la propuesta en mayo de 1996 y la clasifica como Experimental. Esa condición impide convertir su vocabulario de escalabilidad en una afirmación sobre uso real. Aquí se estudia el mecanismo que propuso y las fronteras que el propio texto reconoció.

CBT ofrecía una estructura ya ordenada. La solicitud de incorporación viajaba hacia un núcleo y el JOIN_ACK regresaba por el camino inverso para fijar la rama. La arquitectura de CBT describió relaciones de padre e hijo; la especificación CBTv2 hizo depender el estado on-tree de una confirmación explícita. Esa memoria de vecinos permitía saber por dónde devolver no sólo la autorización, sino también el material criptográfico.

Una autorización que bajaba por la rama

El iniciador del grupo preparaba una ACL firmada y la enviaba al núcleo principal. Este asumía el papel inicial de GKDC, generaba la clave del grupo y una KEK para renovarla. El host que quería entrar aportaba un token firmado; los routers autenticaban las solicitudes; el punto autorizado devolvía un paquete con la política, las claves y los parámetros de la asociación de seguridad, cifrados para cada salto pertinente.

Hasta ahí, el núcleo seguía siendo el origen. La escalabilidad aparecía cuando el nodo ya aceptado guardaba la ACL y las claves y podía servir al siguiente solicitante. La facultad de repartir no se limitaba a mover bits. Incluía interpretar la membresía disponible y decidir que un nuevo destinatario podía conocer el secreto.

Por eso la topología cumplía dos funciones diferentes. Como árbol de datos, indicaba por dónde reenviar paquetes. Como árbol de confianza, determinaba qué nodos podían ampliar el círculo criptográfico. La coincidencia de líneas no unificaba la evidencia: que un router estuviera bien situado para reenviar no demostraba que su política fuera actual ni que debiera conservar privilegios de admisión.

La especificación GKMP optaba por un controlador de grupo con deberes explícitos: crear y renovar claves, distribuirlas, verificar permisos y atender información de compromiso. Compararla con RFC 1949 ayuda a precisar el lenguaje. Quitar una KDC dedicada no quitaba la función de gobierno; la asignaba a un miembro, a un núcleo o a una red de custodios.

El límite de confiar en todos

RFC 1949 formuló su propia objeción. ¿Era razonable suponer que todos los routers del árbol no se comportarían mal y estarían protegidos? En la variante más distribuida, esos routers podían descifrar, comprobar, volver a cifrar y entregar claves. Un fallo dejaba de ser sólo un desvío de tráfico: podía revelar el contenido o alterar quién entraba.

La respuesta más estricta consistía en enviar toda incorporación segura hasta un router núcleo y reservar allí la capacidad de distribución. Se perdía una parte de la ventaja operativa, pero se reducía el número de entidades privilegiadas. La decisión real era gradual: cuánto trabajo central evitar y cuánta superficie de confianza aceptar.

Un JOIN_ACK demostraba que una rama había sido confirmada bajo cierto estado. Una firma vinculaba un mensaje con su firmante. Ninguno demostraba que todas las ACL distribuidas coincidieran, que una clave vieja hubiera sido borrada o que el custodio no fuera comprometido después. La auditoría debía conservar la versión y el momento de cada decisión.

Saber la clave del grupo no decía quién habló

Si todos comparten una misma clave, un mensaje válido puede proceder de cualquiera que la conozca. RFC 1949 distinguió por ello las claves específicas de emisor. Un miembro remitente podía publicar sus parámetros firmados dentro de la protección del grupo. Un remitente externo primero negociaba con el núcleo principal, que después difundía su material específico.

La separación marca tres permisos: recibir, enviar y atribuir un paquete a un origen concreto. El secreto común no los fusiona. Mucho menos prueba la identidad natural de una persona, la representación de una organización o la autorización de la operación que siga al paquete.

La baja administrativa y la salida criptográfica

El documento incluía una KEK y el cambio periódico de clave, pero no resolvía la exclusión selectiva dentro del mismo árbol. Un miembro borrado todavía conocía la generación vigente. Para que su salida fuera efectiva, el resto necesitaba un secreto nuevo distribuido mediante un grupo/árbol de nueva formación.

La jerarquía lógica de RFC 2627 explicó después el principio de exclusión con otro tipo de árbol: al retirar una hoja, había que sustituir todas las claves que conocía en el camino hasta la raíz y entregarlas sólo a los restantes. No es una prueba de descendencia respecto de RFC 1949. Es una formulación posterior de la diferencia entre editar membresía y cambiar capacidad.

La arquitectura MSEC de RFC 4046 separó el registro, la retirada, la fuente autorizada, el rekey escalable, la resistencia a colusión y la recuperación tras compromiso. Así mostró que la seguridad de grupo vive en una secuencia de estados y no en una única ceremonia de entrega.

Una propuesta no es una instalación

La idea de Heng Lu sobre la primacía del código en funcionamiento obliga a buscar pruebas fuera del número del RFC. Harían falta trazas de incorporación, versiones de ACL, inventarios de custodios, evidencia de borrado, resultados de cambio de clave y ensayos que confirmen que un excluido deja de leer.

La especificación inicial mínima y la adopción voluntaria permiten apreciar la economía del planteamiento: reutilizar la incorporación explícita de CBT y hacer opcional la distribución. Pero un núcleo pequeño debe exponer su decisión decisiva. Heredar la facultad de repartir claves no puede quedar escondido dentro de un simple cambio de estado de routing.

Separar las capas de realidad evita que “distribuido” actúe como sinónimo de legítimo o seguro. Bajo esa palabra hay un núcleo, una ACL firmada, custodios autorizados, una clave de grupo, una KEK, credenciales de emisor y generaciones de rekey. El centro dejó de ejecutar todo el trabajo; su autoridad se convirtió en estado transportable.

RFC 1949 dejó así una medida doble para la escalabilidad. La primera cuenta cifrados y mensajes. La segunda cuenta custodios, copias antiguas, rutas de compromiso y el trabajo necesario para que una persona que salió ayer no pueda descifrar mañana.

Fuentes

  1. RFC Editor — registro actual de RFC 1949
  2. RFC 1949 — Scalable Multicast Key Distribution
  3. RFC 2093 — Group Key Management Protocol Specification
  4. RFC 2189 — Core Based Trees version 2 Protocol Specification
  5. RFC 2201 — Core Based Trees Multicast Routing Architecture
  6. RFC 2627 — Key Management for Multicast
  7. RFC 4046 — MSEC Group Key Management Architecture
  8. Heng Lu — Running-Code Primacy
  9. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  10. Heng Lu — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile