ason is that by default we can assume that at
> least cipher suite 0. AES-CCM-16-64-128, SHA-256 is implemented in both
> entities. As such, if the controller includes option 0 in the list of
> cipher suites, the controller will not receive a bad request since at least
> the IoT device can select cipher suite 0 and therefore the authentication
> will follow until the end cipher suite negotiation can be verified. We
> think it is simpler and we can get rid of a bad request. Does it sound
> reasonable?
>
> [GS] Sounds OK to me.
>
>
>
>
>
>
>
> ___
> Ace mailing list
> a...@ietf.org
> https://www.ietf.org/mailman/listinfo/ace
>
--
Daniel Migault
Ericsson
___
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
-coap-eap-04.txt
>
> Dear ACE and EMU WG,
>
> We have submitted a new version of the draft (draft-ietf-ace-wg-coap-eap)
>
> This version provides information on the different comments, from the
> reviews and interim meetings.
>
> Best Regards.
>
>
> El 10/25/202
appen only if there is an
interest in the WG. Nevertheless, we would like to avoid that the charter is a
barrier later if there is interest in the WG to work in this transport of EAP
over CoAP:
Any opinion about this?
Best Regards.
El 18/11/2020 a las 8:08, Daniel Migault escribió:
Hi,
Please find the propos
Hi,
I have reviewed the eap-noob document and believe it is ready for adoption.
I have made a series of comments that are mostly editorial and some
clarifying questions. I am happy to review the document further.
Yours,
Daniel
[...]
Abstract
Extensible Authentication Protocol (EAP)
