Hi Göran,
Thank you again for your comments.
We have incorporated them into the a new 06 version of the draft that we
just submitted.
Best Regards,
Dan.
On 6/12/21 12:13, Göran Selander wrote:
Hi Dan,
Please find my replies to your two questions about the update inline
below.
Best regards
Göran
*From: *Dan Garcia Carrillo <[email protected]>
"The communication with the last resource (e.g. '/a/w') from this
point MUST be protected with OSCORE except during a new
(re)authentication (see Section 3.3)."
I don't understand why there is an exception. OSCORE seems to be
applied to communication with the last resource in all cases:
* In the case of new authentication the procedure explained in
Section 3.2 applies protection with OSCORE in communication with
the last resource.
* In the case of re-authentication, the procedure is explained in
Section 3.3 to be "exactly the same" as in Section 3.2.
[authors] Yes, we agree. We can remove that part from the sentence to
avoid any confusion. Nevertheless, after your comment, it would be
worth stating that if the access to any other resource requires OSCORE
protection can use the generated OSCORE context. Does it sound
reasonable?
[GS] Yes, the established security context can be used between other
resources if allowed by the application's security policy. Proposed
rephrasing of step 8:
OLD
"The IoT Device answers with '2.04 Changed' if the EAP
authentication is a success and the verification of the "POST"
protected with OSCORE in Step 7 is correctly verified. The
communication with the last resource (e.g. '/a/w') from this point
MUST be protected with OSCORE. Any other resource that requires
OSCORE protection MAY be protected with this OSCORE security
context."
NEW
"If the EAPauthentication and the verification of the OSCORE
protected "POST"in Step 7 is successful, thenthe IoT Device answers
with an OSCORE protected '2.04 Changed'. From this point on, the
communication with the last resource (e.g. '/a/w')
MUST be protected with OSCORE. If allowed by application policy,
sameOSCORE securitycontextMAY be use to protect communication toother
resources between the same endpoints."
----
Another editorial comment refering to the recent update:
OLD
"The reception of the POST
message protected with OSCORE with Sender ID equal to RID-I
(Recipient ID of the IoT device) sent in Step 2 is considered by
the IoT device as an alternate indication of success ([RFC3748
<https://datatracker.ietf.org/doc/html/rfc3748>])."
I would avoid the term Sender ID since it is all about verification of
a received message, e.g. like this.
NEW
"The verification of the received OSCORE protected"POST"
messageusing RID-I(Recipient ID of the IoT device) sent in Step 2 is
considered by
the IoT device as an alternate indication of success ([RFC3748
<https://datatracker.ietf.org/doc/html/rfc3748>])."
----
Section 5.1
"If the Controller sends a restricted list
of ciphersuites that is willing to accept, and the ones
supported by
the IoT device are not in that list, the IoT device will
respond with
a '4.00 Bad Request', expressing in the payload the ciphersuites
supported. "
Make clear (here or in a security consideration) that in case of
an error message containing a cipher suite, the exchange of cipher
suites between EAP authenticator and EAP peer cannot be verified.
For example, a man-in-the-middle could replace cipher suites in
either message which would not be noticed if the protocol is ended
after step 2.
[authors] That’s right. However, after your comments, we believe this
could be improved. The reason 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.
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
