Dear John,
Thank you for taking the time to review the document. I think with this
the next version would be much more accurate.
Please find responses to your comments inline.
Best Regards,
CoAP-EAP authors.
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"
[authors] We will change the wording, thank you
- Section 2. I don't understand what "SM" in Figure 1 is an
abbrevation for.
[authors] SM stands for State Machine, we will explain that in the
text, thank you for pointing that out.
- Section 2. "UDP/TCP/Websockets" Why is the Websocket protocol in plural?
[authors] Probably a typo, thanks
- 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.
[authors] We will rephrase using key derivation.
- "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.
[authors] That’s correct. Most probably is better to just mentioned that
any EAP method that does not export key material MUST NOT be used. It is
worth mentioning that the goal of this statement was, as the document
defines an EAP lower layer, not so much as trying to make
recommendations on which EAP methods are secure or should be considered
deprecated. We just intend to provide information on which EAP methods
are suitable for its use with this particular EAP lower layer.
- "The required key, the Master Session Key (MSK), will be available
once the
EAP authentication is successful."
Does this belong in step 2?
[authors] It is a clarification to highlight that the MSK is used to
derive key material for the OSCORE context. We can remove it if it
clarifies the paragraph or even to point to step 7.
- 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.
[authors] This is an interesting comment that we already commented on
EMU WG, though we do not receive any comment. In fact, we tend to agree
with you. All the details are in this e-mail we sent:
https://mailarchive.ietf.org/arch/msg/emu/bnMFV4_1uTW7sSwVOp7WzVZZCAI/
In summary, the EAP peer state machine does not inform the EAP lower
layer that the key is available in eapKeyData until it is in SUCCESS
state. In this final state, the eapKeyAvailable is set to TRUE.
In any case, everything is now solved because the arrival of
OSCORE-protected CoAP message is considered as an alternate success
indication.
- 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.)
[authors] Yes, sure. We will add this comment to the text. In fact that
is the intention to the reauthentication: to refresh the MSK/EMSK. In
fact, the EAP Key Management Framework establishes a default value of 8
hours to refresh the MSK/EMSK. Therefore that would be the default value
each time the OSCORE key material is refreshed.
- "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.
[authors] Thank you for pointing that out. The CBOR structure is
intended to be extensible. We have the values for what is currently
expected in the protocol, but we want to keep the structure open for
future additions if they are needed.
The values from 65000 to 65535are referring to the index of the values
that are not yet assigned, for extensibility. Those indexes are reserved
for experimentation.
- 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"?
[authors] Basically, the EAP Key Management Framework uses that specific
terminology (RFC 5274- 5.7
<https://datatracker.ietf.org/doc/html/rfc5247#section-5.7>. Key
Freshness”). That is why we used this term. “While preserving algorithm
independence, session keys MUST be strong and fresh. Each session
deserves an independent session key.”
- 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.
[authors] We agree. that this consideration applies. We will add that to
the DTLS annex.
- Probably good if the labels have “CoAP-EAP” in all the labels to
guarantee that they do not collide with anything else.
[authors] Thank you for this point. We will apply this change when using
labels for key derivation to avoid confusion.
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
