Dear John,
First of all, our apologies for the late response to your review, for
some unknown reason we did not see it at the time. It is much
appreciated and we will try to answer you as soon as possible.
Best Regards,
Dan.
On 25/10/21 17:02, John Mattsson wrote:
Thanks,
I think this is a very useful mechanism and a well written draft. Some
quick comments.
- "ciphersuite"
Note that both TLS and EDHOC spells this with space "cipher suite"
- Section 2. I don't understand what "SM" in Figure 1 is an
abbrevation for.
- Section 2. "UDP/TCP/Websockets" Why is the Websocket protocol in plural?
- Section 3. "EAP method that exports cryptographic material"
This can probably be reformulated in terms of MSK, EMSK or "Key
derivation" which
is the property that RFC 3748 uses.
- "EAP-MD5 cannot be used since it does not export key material"
MD5 should really not be used at all for security resons. Highlighting
it like this might
be the idea that it would be ok if EAP-MD5 had the "Key derivation"
property.
- "The required key, the Master Session Key (MSK), will be available
once the
EAP authentication is successful."
Does this belong in step 2?
- In Figure 2. I do not think you have to wait until EAP-SUCCES to
make MSK available.
The authentication can be successful before EAP-SUCCES.
- In section 3.3. it might be good to state that "Reauthentication"
might be needed to rekey MSK/EMSK and to increase protection against
key leakage.
(An important mitigation of pervasive monitoring is to force attackers
to do dynamic key exfiltration instead of static key exfiltration.
Dynamic key exfiltration increases the risk of discovery for the
attacker [RFC7624]. While OSCORE will soon be augmented with a
rekeying mechanism with forward secrecy, attackers can still get away
with doing static key exfiltration. This is similar to TLS 1.3 with
KeyUpdate, after leakage of application_traffic_secret_N, a passive
attacker can passively eavesdrop on all future application data sent
on the connection including application data encrypted with
application_traffic_secret_N+1, application_traffic_secret_N+2, etc.)
- "4. The values from 65000 to 65535 are reserved for experimentation"
what does "The values" refer to? Lifetime? In that case it would fit
better under 3.
- In addition to AES-CCM-16-64-128, only ciphersuites only cipher
suites with AES-GCM is included. My feeling was that most IoT people
are more interested in ChaCha20-Poly1305 than AES-GCM. I don't have a
strong personal opinion.
- "which is considered fresh key material"
“considered fresh”? Maybe "uniformally random"?
- With normal use of DTLS, Appendix A violates “The CoAP-EAP operation
is intended to be compatible with the use of intermediary entities
between the IoT device and the Controller”. This limitation should be
clearly stated.
- Probably good if the labels have “CoAP-EAP” in all the labels to
guarantee that they do not collide with anything else.
Cheers,
John
*From: *Emu <emu-boun...@ietf.org> on behalf of Dan Garcia Carrillo
<garcia...@uniovi.es>
*Date: *Monday, 25 October 2021 at 13:27
*To: *a...@ietf.org <a...@ietf.org>, EMU WG <emu@ietf.org>
*Subject: *Re: [Emu] New Version Notification for
draft-ietf-ace-wg-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/2021 a las 1:23 PM, internet-dra...@ietf.org escribió:
> A new version of I-D, draft-ietf-ace-wg-coap-eap-04.txt
> has been successfully submitted by Dan Garcia-Carrillo and posted to the
> IETF repository.
>
> Name: draft-ietf-ace-wg-coap-eap
> Revision: 04
> Title: EAP-based Authentication Service for CoAP
> Document date: 2021-10-25
> Group: ace
> Pages: 29
> URL: https://www.ietf.org/archive/id/draft-ietf-ace-wg-coap-eap-04.txt
> Status: https://datatracker.ietf.org/doc/draft-ietf-ace-wg-coap-eap/
> Htmlized:
https://datatracker.ietf.org/doc/html/draft-ietf-ace-wg-coap-eap
> Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-ace-wg-coap-eap-04
>
> Abstract:
> This document specifies an authentication service that uses the
> Extensible Authentication Protocol (EAP) transported employing
> Constrained Application Protocol (CoAP) messages. As such, it
> defines an EAP lower layer based on CoAP called CoAP-EAP. One
of the
> primer goals is to authenticate a CoAP-enabled IoT device (EAP peer)
> that intends to join a security domain managed by a Controller (EAP
> authenticator). Secondly, it allows deriving key material to
protect
> CoAP messages exchanged between them based on Object Security for
> Constrained RESTful Environments (OSCORE), enabling the
establishment
> of a security association between them.
>
>
>
>
> The IETF Secretariat
>
>
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
