Thanks Dan. It seems we are reaching the point where we can move the document forward.
Until now in this group, chairs have usually been writing the document shepherd, but I am wondering if anyone in the WG would be interested in writing such a document. The reason we are proposing this is to increase the number of people familiar with WG chairs tasks, and provide more opportunities for people to show some interest in positions such as chairs, secretaries, ads... If anyone is interested in writing the document shepherd please let us know by the end of the week. Similarly, anyone interested in a chair position, please let us know so we can make our ADs aware of it. Yours, Logan and Daniel On Tue, Dec 7, 2021 at 5:11 PM Dan Garcia Carrillo <garcia...@uniovi.es> wrote: > 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 <garcia...@uniovi.es> <garcia...@uniovi.es> > > > "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. > > > > > > > > _______________________________________________ > Ace mailing list > a...@ietf.org > https://www.ietf.org/mailman/listinfo/ace > -- Daniel Migault Ericsson
_______________________________________________ Emu mailing list Emu@ietf.org https://www.ietf.org/mailman/listinfo/emu
