Re: [Ace] [Emu] New Version Notification for draft-ietf-ace-wg-coap-eap-04.txt

[Dan Garcia Carrillo <[e-mail]>]

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 <[e-mail]>
>
>     "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.
>