Resumen

  • RFC 9668 permite transportar EDHOC message_3 y la primera solicitud OSCORE en un solo mensaje CoAP para alcanzar dos viajes de ida y vuelta en el flujo directo.
  • La opción EDHOC número 21 sólo activa el parser combinado; no demuestra autenticación, creación del contexto, aceptación OSCORE, entrega a la aplicación ni efecto final.

El equipo de observabilidad había elegido una señal sencilla: si el paquete llevaba la opción EDHOC número 21, la conexión aparecía en verde. La opción llegó. Estaba vacía, exactamente como exige la especificación. Sin embargo, el servidor no encontró una sesión EDHOC compatible con el kid y detuvo el procesamiento.

El paquete cumplía la forma exterior del camino optimizado. No había completado ninguno de sus compromisos interiores.

RFC 9668 define una mejora valiosa para enlaces restringidos. En el flujo normal, cliente y servidor intercambian message_1 y message_2, completan EDHOC con message_3 y después realizan la primera transacción OSCORE. Como el Initiator puede derivar el Security Context tras procesar message_2, puede preparar message_3 y cifrar la solicitud CoAP sin esperar. Ambos objetos viajan juntos y el ciclo completo puede quedar en dos viajes de ida y vuelta.

La reducción es física: menos emisiones y menor latencia. La semántica sigue teniendo varias capas.

Un bit de presencia ordena, no autoriza

La opción EDHOC es crítica, Safe-to-Forward, forma parte de la clave de caché, no se repite y debe estar vacía. Si alguien añade un valor, el receptor lo ignora. Su presencia dice que el payload empieza con message_3 y continúa con el ciphertext OSCORE. Por eso obliga a procesar EDHOC antes de reconstruir la solicitud protegida.

El kid del OSCORE option transporta C_R. Ese mismo valor es el Sender ID del cliente en OSCORE y la clave con la que el servidor busca la sesión EDHOC. La doble función ahorra bytes, pero amplía el daño de una mala custodia del identificador. Hay que registrar la generación de sesión y contexto que resolvió el valor, no sólo el valor aislado.

Una vez elegida la sesión, el servidor comprueba el perfil de aplicación. Si éste obliga a enviar message_4, el camino combinado debe fallar. Después valida message_3 y sólo entonces crea el contexto OSCORE. Extrae el segundo componente, reconstruye la solicitud, elimina la opción EDHOC, aplica integridad y antirrepetición y entrega el resultado a la aplicación.

Estas etapas permiten una taxonomía precisa. Error de formato no es error de credencial. Error de message_3 no es rechazo de replay. Solicitud descifrada no es autorización concedida. Entrega a la aplicación no es compromiso durable. La opción 21 no hereda autoridad de ninguno de esos pasos posteriores.

El cifrado protege afirmaciones limitadas

message_3 y la solicitud OSCORE comparten datagrama, pero no una única protección. El ciphertext OSCORE no cubre message_3. EDHOC protege su objeto y OSCORE protege el suyo. Esta independencia es una ventaja: un fallo puede atribuirse a su capa. Se pierde cuando la telemetría crea un único estado “seguro”.

Si message_3 y OSCORE se validan, el servidor debe responder bajo OSCORE. La respuesta queda ligada a la solicitud y su verificación con la nueva clave puede aportar confirmación de clave del Responder al Initiator. Es una prueba criptográfica importante. Aun así, el contenido conserva el significado que le dio la aplicación.

Una respuesta “Changed” puede significar que se actualizó un valor en memoria, que se encoló una tarea o que un actuador confirmó movimiento; el protocolo no decide entre ellos. Para no inflar la respuesta, el dominio de negocio debe emitir estados explícitos: recibido, autorizado, aceptado, comprometido, observado o compensado. La seguridad garantiza procedencia e integridad; no convierte “aceptado” en “terminado”.

Repetir el sobre no repite todas las cosas del mismo modo

Las redes restringidas pierden paquetes. Un cliente puede no saber si el servidor recibió su mensaje combinado. RFC 9668 desaconseja varias interacciones simultáneas de la misma sesión y C_R, aunque contempla circunstancias muy limitadas. EDHOC evita procesar varias veces el mismo message_3 en una sesión y OSCORE mantiene protección de replay.

La aplicación puede tener otro límite. Si la primera solicitud es un comando no idempotente, el segundo intento necesita la misma identidad de operación y una respuesta consultable. De lo contrario, un mecanismo criptográficamente seguro puede rodear una duplicación de negocio perfectamente válida desde el punto de vista de cada capa.

La evidencia mínima enlaza referencia de transcript, generación EDHOC, generación OSCORE, kid, Partial IV, decisión de ventana, identidad de operación, estado de ejecución y respuesta. Es posible conservar esa cadena sin guardar secretos. Lo que no debe hacerse es sustituirla por la hora del datagrama.

El MTU también participa en la decisión

La optimización depende de que message_3 y el primer bloque protegido quepan. Una cadena de certificados o EAD puede aumentar message_3. Si COMB_PAYLOAD supera MAX_UNFRAGMENTED_SIZE, el cliente debe abandonar ese intento Block-wise y puede volver al flujo secuencial. Primero termina EDHOC; después envía OSCORE.

El repliegue no es un fallo de interoperabilidad. Es una decisión local autorizada por el estándar. Sin embargo, modifica latencia, energía y ventanas de timeout. Conviene registrar tamaños de componentes, MTU asumido, bloque, umbral, razón y modo final. Así la organización puede saber si el ahorro sólo existe para credenciales pequeñas o para una topología de radio determinada.

La especificación merece mantenerse estrecha. Define cómo dos pares interoperan y cómo señalan el sobre. No convierte una señal sintáctica en autoridad sobre la realidad de la aplicación.

Fuentes