Kris Pister writes: > Let's assume that the hand-off between the DTLS module and the CoAP > module tells CoAP if the packet was properly encrypted (vs. the > hand-off from UDP).
I think the DTLS to CoAP interface needs to also provide the authenticated identity of the other end, and also provide channel bindings i.e. make sure that the security properties of all packets remain same after the device has checked them. I.e. if device starts some operation that requires multiple UDP packets, then someone needs to make sure that all of those UDP packets have same security, and are from same authenticated identity. > My mote needs some sort of table that binds resources to security > requirements. That takes care of host A asking for temperature (OK) > vs. slotframe info (not allowed if not protected with DTLS). Yes. > But how does the mote differentiate between a READ and a DELETE from > mote B or C? Both will be encrypting their requests with DTLS. Does > the mote need a table of hosts, each with a list of resources, each > resource with a 4 bit flag of permissions? That is not enough. It needs to have table of resources, and ACLs who are allowed to do operations on them (using some kind of stable identity for the other end) and what operations are allowed for each peer. For each peer it also needs to know the authentication information that the peer uses to authenticate himself in DTLS. The stable identity cannot be short address, or IP-address as both of those can change. Some kind of stable IPv6 address would be possible (derived from the public key of the device), and perhaps even extended-address of the device (it is supposed to be unique). -- [email protected] _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
