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

[Göran Selander <[e-mail]>]

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 EAP authentication and the verification of the OSCORE protected "POST" in Step 7 is successful, then the 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, same OSCORE security context MAY be use to protect communication to other 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"

    message using 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.