Resumen

  • En CoAP-EAP, exportar el MSK tras un método EAP satisfactorio no completa por sí solo la sesión protegida. El POST OSCORE del paso 7 y la respuesta OSCORE 2.04 Changed del paso 8 producen dos verificaciones distintas que deben conservarse.
  • Compartir un contexto criptográfico tampoco concede acceso general. La autorización de incorporación, la política de cada recurso, la vigencia, la sustitución de generaciones y la eliminación forzada tienen autoridades y tiempos propios.
  • Una prueba defendible enlaza generaciones de recursos CoAP, resultado EAP, linaje no secreto de derivación, negociación, Recipient IDs, verificaciones de los pasos 7 y 8, política efectiva, retiro y tráfico observado, sin registrar el MSK.

La respuesta que no llegó cambió el significado de «éxito»

El caso hipotético empieza después de la parte que suele recibir toda la atención. El servidor AAA aceptó las credenciales. El autenticador obtuvo el resultado de éxito y el material de clave. El par verificó el POST protegido que contenía EAP Success y emitió su 2.04 Changed. Una pérdida de red impidió que el controlador viera esa última respuesta.

No hubo un único estado global. El par sabía que podía verificar al autenticador. El autenticador todavía no sabía que el par había producido correctamente el mensaje de retorno bajo el contexto derivado. Un observador de red podía saber que hubo una transmisión, no necesariamente que el destinatario la aceptó. La aplicación que recibió tráfico más tarde tenía una decisión adicional: permitir o negar su propio recurso.

RFC 9820 define cómo transportar EAP sobre CoAP para dispositivos limitados. El dispositivo actúa como par EAP y servidor CoAP; el Controller actúa como autenticador EAP y cliente CoAP. En modo pass-through, un servidor AAA puede ejecutar el método o aportar la autorización. Esas funciones cruzadas vuelven insuficiente cualquier registro que diga sólo «cliente», «servidor» o «autenticado».

La ficha del RFC Editor y el registro del Datatracker clasifican RFC 9820 como especificación Standards Track del IETF, publicada en septiembre de 2025 a partir del trabajo de ACE. Esa condición da autoridad a la definición. No demuestra adopción, implementación, conformidad ni el resultado de una sesión real.

El orden vive en recursos que desaparecen

CoAP-EAP no mantiene toda la conversación detrás de un endpoint eterno. El par crea un recurso para el siguiente paso y elimina el anterior; Location-Path o Location-Query señala el destino nuevo. Por eso la generación del recurso es parte del significado del mensaje.

Una retransmisión dirigida a una generación borrada no se convierte en actual por llegar tarde. Un Step 0 duplicado durante una autenticación en curso debe descartarse silenciosamente. Un disparador antiguo recibido cuando ya no existe sesión puede iniciar, desde la perspectiva del autenticador, un intercambio nuevo que el par no reconoce de la misma manera.

RFC 7252 proporciona la semántica de petición, respuesta y fiabilidad de CoAP. RFC 4137 describe las máquinas de estado del par y el autenticador EAP. RFC 9820 compone ambas, pero no autoriza a un inventario de sesiones a reemplazarlas por una sola bandera.

El recibo útil conserva identidad y rol de cada extremo, generación anterior y nueva, identificadores CoAP y EAP, transición, respuesta, instante y observación de transporte. También explica si una repetición fue rechazada, descartada o tratada como nueva autenticación. Sin esa distinción, un operador puede confundir reordenamiento con ataque, o ataque con recuperación normal.

El paso 7 prueba algo que el resultado del método no prueba

Cuando el método EAP tiene éxito, el autenticador recibe el MSK exportado, el mensaje EAP Success y datos de autorización como Session-Lifetime. RFC 5247 define el marco de gestión de claves EAP. RFC 9820 requiere métodos que exporten MSK y EMSK de al menos 64 octetos.

Que el MSK exista en un lado no significa que los dos extremos hayan instalado contextos compatibles. RFC 9820 deriva Master Secret y Master Salt de OSCORE usando el MSK, la negociación de la suite y cadenas de contexto definidas. Los Recipient IDs intercambiados fijan las direcciones de envío y recepción. RFC 5869 especifica HKDF; RFC 8613 especifica OSCORE.

El autenticador envía entonces EAP Success dentro de un POST protegido por OSCORE. El par debe obtener su propio MSK, derivar el contexto y verificar ese mensaje. El paso 7 es, por tanto, una transición probatoria: convierte una conclusión local del autenticador en una afirmación que el par sólo puede aceptar si posee material compatible.

No se debe «mejorar» la auditabilidad copiando el MSK al registro. Deben guardarse la huella de la transcripción, identificadores de suite y método, Recipient IDs, generación de derivación, versiones ejecutadas y resultado de verificación. Los secretos quedan fuera.

El paso 8 devuelve la prueba a quien inició el intercambio

Después de aceptar el paso 7, el par responde con 2.04 Changed, también protegido por OSCORE. Cuando el autenticador verifica esa respuesta, obtiene evidencia de que el par derivó el mismo Master Secret y pudo usar el contexto correspondiente.

La cadena tiene al menos cinco afirmaciones separables: el método concluyó; se exportó material; cada lado derivó localmente; el par verificó el POST; el autenticador verificó la respuesta. Una caída entre las dos últimas no invalida retroactivamente el método, pero impide afirmar confirmación bilateral completa.

La negociación criptográfica forma parte de la derivación. Si una alteración produce transcripciones distintas, los contextos divergen y los mensajes protegidos no verifican. El registro CoRE Parameters de IANA y el registro EAP de IANA asignan códigos estables. No atestiguan cuál fue elegido ni qué binario lo ejecutó.

El segundo testigo tampoco es una ceremonia destinada al informe. Permite distinguir «el autenticador cree haber terminado» de «ambos extremos demostraron posesión compatible». Esa diferencia decide si se puede activar estado compartido, iniciar la vigencia y avanzar hacia una política de aplicación.

La protección compartida no es autorización universal

Tras el paso 8, la última recurso CoAP-EAP debe usar OSCORE. El mismo contexto puede proteger otros recursos sólo cuando la política de la aplicación lo permite. La condición es tan importante como la criptografía.

Autenticación responde a una pregunta sobre identidad o credencial bajo un método. Confirmación de clave responde a una pregunta bilateral sobre el contexto. Autorización decide si ese par puede invocar ese recurso en ese momento. Resultado describe lo que la aplicación hizo realmente. Ninguna capa hereda automáticamente el mandato de la siguiente.

Durante el arranque, la organización responsable del par puede aportar atributos a través de RADIUS o Diameter; en modo autónomo, la política puede residir en el autenticador. Después puede exigirse autorización más granular. RFC 9200 define un perfil ACE de OAuth para entornos restringidos, pero citarlo no demuestra que una implementación haya evaluado un token ni que un recurso concreto estuviera permitido.

Durante la autenticación, el tráfico IP no protegido debe limitarse al intercambio CoAP-EAP. Una regla de firewall que abra una subred completa en cuanto aparezca EAP Success amplía el poder de una señal local. Incluso un paquete OSCORE válido debe unirse a la versión de política, la decisión del propietario del recurso y el efecto observado.

La renovación no sustituye el estado al empezar

Si no se proporciona Session-Lifetime, RFC 9820 adopta ocho horas como valor por defecto siguiendo la recomendación de RFC 5247. No es una garantía comercial ni una duración universalmente prudente.

Durante la reautenticación, la generación activa y una candidata coexisten. La anterior se elimina y sustituye cuando la nueva autenticación concluye plenamente. Si el intento falla, el estado anterior puede seguir válido hasta expirar o hasta un nuevo intento.

El comienzo de la renovación no equivale a activación. El registro debe mostrar inicio, resultado del método, pasos protegidos, política, activación, última aceptación de la generación vieja, retirada y expiración. Una caché puede seguir aceptando el contexto anterior cuando el Controller ya presenta el nuevo como vigente.

Esta superposición tiene consecuencias para actos irreversibles. Una orden admitida por una generación que estaba a punto de retirarse puede ser criptográficamente válida y, sin embargo, violar la intención operacional. La política debe decidir si tales actos se bloquean durante ambigüedad; el protocolo no toma esa decisión empresarial por ella.

Borrar localmente no expulsa globalmente

Para la eliminación forzada, el autenticador envía un DELETE protegido a la última recurso de estado. El par devuelve 2.02 Deleted, también protegido. Si la respuesta no llega antes de EXCHANGE_LIFETIME, el autenticador elimina su estado local.

El timeout permite recuperar recursos, pero no prueba recepción remota. Tras una partición, el autenticador puede declarar cerrado su estado mientras el par conserva un contexto, una caché mantiene permisos o la red sigue reenviando intentos. «Eliminado» debe decir quién eliminó qué y con qué prueba.

La secuencia auditable incluye principal que ordenó, razón y política, generación, DELETE transmitido, recepción del par si se conoce, eliminación local, acuse protegido, verificación del autenticador, vencimiento, invalidación de cachés, rechazos posteriores y cese observado de tráfico. Una ausencia de paquetes sólo puede acotar la observación; no demuestra por sí sola que el dispositivo haya borrado secretos.

La confianza empieza antes del primer paquete útil

El descubrimiento del autenticador o intermediario queda fuera del alcance de RFC 9820. Encontrar un servicio no prueba que pertenezca a la autoridad prevista. RFC 6677 ofrece enlace de canal EAP y un identificador de capa inferior que puede revelar discrepancias dentro del método y la ruta AAA, pero una configuración real debe conservar su resultado.

El par puede confiar en un autenticador que posee el MSK porque su servidor AAA confió en él. Es una delegación limitada, no una etiqueta abstracta de «controlador confiable». El recibo debe nombrar organización, servidor AAA, configuración, canal y sesión.

Los Step 0 falsificados también pueden agotar estado del autenticador. El RFC recomienda limitar tasa y minimizar estado hasta recibir EAP-Response/Identity. El contador de rate limiting prueba que un límite operó, no que cada origen fuera legítimo.

Un ensayo serio provoca realidades incompatibles

El montaje mínimo contiene un par, un autenticador, una ruta AAA, dos recursos con políticas distintas y un observador independiente. Después del camino feliz, debe alterar la transcripción de suite, perder el paso 7, perder el paso 8, repetir una generación retirada, duplicar Step 0, fallar una reautenticación, medir la superposición, negar un segundo recurso y ejecutar dos eliminaciones: una reconocida y otra sin acuse.

Para cada prueba se comparan estado EAP, generación CoAP, verificación OSCORE, decisión de aplicación y tráfico. Debe quedar claro qué lado sabe cada hecho. El ensayo fracasa si su única salida es success o failure.

La prueba más reveladora es asimétrica: el método termina, el par acepta el paso 7, el paso 8 se pierde y una caché permite una operación. Obliga a la dirección a decidir si la operación era admisible cuando las autoridades poseían pruebas diferentes.

Lo que no establecen las fuentes

RFC 9820 no identifica productos, operadores ni despliegues. No aporta mediciones de batería, latencia, pérdidas, interoperabilidad, volumen de admisiones o ataques observados. Sus escenarios explican el diseño.

El historial del Datatracker, sus referencias salientes y los documentos que lo citan prueban relaciones documentales. La búsqueda de erratas informa del estado editorial, no de la seguridad de un sistema.

RFC 3748 define el marco EAP general. Ni él ni RFC 9820 permiten inferir que un equipo particular se autenticó, fue autorizado o dejó de actuar.

Fuentes

  1. IETF Datatracker: RFC 9820
  2. Historial de RFC 9820
  3. Documentos que citan RFC 9820
  4. Referencias de RFC 9820
  5. Heng Lu: especificación inicial mínima
  6. Heng Lu: capas de realidad
  7. Heng Lu: primacía del código ejecutado
  8. IANA CoRE Parameters
  9. IANA EAP Parameters
  10. Erratas de RFC 9820
  11. Ficha del RFC Editor
  12. RFC 3748
  13. RFC 4137
  14. RFC 5247
  15. RFC 5869
  16. RFC 6677
  17. RFC 7252
  18. RFC 8613
  19. RFC 9200
  20. RFC 9820