[Back from Vancouver, so now I have time to answer some of these emails] Robert Cragie writes: > In summary: > > * There may need to be a decision on whether to mandate use of integrity > protection on MAC enhanced beacons. > * There may need to be a decision on whether to mandate use of integrity > protection and encryption on MAC data, command and ack frames. > * There may need to be a distinction of MAC data frames used for carrying > authentication exchanges which do not usually have any protection > * The properties of K1 and its purpose may need to be elaborated further
Yes. This is good summary. > This draft assumes the existence of two cryptographic keys, K1 and > K2. EBs SHOULD be authenticated with key K1. > > First of all, the correct therm is data integrity, not authenticate. > Authenticate would mean that we would actually provide verification > that the identity of a peer entity in a current association is as > claimed. Here we just provide protection that data is not modified. > > <RCC>AES-CCM as it is used provides data origin authenticity. The term AE > (authenticated encryption) is commonly used with AES-CCM mode of operation. So > personally I feel "authenticated" is OK but "integrity protected" would also > work and I agree is probably more accurate wrt. AES-CCM</RCC> The data origin authenticity would be correct term if we would actually authenticate the sender. I.e. if you do KMP with the other end and authenticate that the sender is who you think it is, then this would be ok term. In our case where we mostly use group shared keys or even well know keys, there is really no authentication for the server. At best you can know the data origin (sender) is someone who knows the key, i.e. the ones who has the group shared key. When using well-known keys there is no idea who the sender is, thus saying we do data origin authenticity would be quite misleading. > See RFC 4949 for "data integrity", "data integrity service", > "authenticate", and "authentication". > > In which cases it is ok not to integrity protect the EBs with K1? > > <RCC>We seem to have gone around the houses on "MAY", "SHOULD" or "SHALL" for > this. "MAY" is pretty pointless as it really says nothing. "SHOULD" recommends > the use of integrity protection and "SHALL" would mandate the use of integrity > protection. As far as I can tell, this document is a recommended set of > parameters for minimal operation., so "SHOULD" would appear to be the right > choice, although I personally see no problem mandating integrity protection. > As a recommendation, I don't see the need to elaborate on the cases where the > choice is to go against the recommendation.</RCC> > > What happens if EBs are not protected by K1. I.e. what kind of attacks > are possible in such case, and why do you think we do not need to care > about them here. > > This is security consideraions section so you should explain those > things here. > > <RCC>Again, I don't see the need to elaborate on the cases where the choice is > to go against the recommendation but again it might be better to have this > mandatory.</RCC> Note, that well-known key == no security for EBs at all. So if well-known key is given in the draft, then you need to explain what kind of attacks it opens the users. > Note, that answers to those depends a lot where the minimal is used. > In the bootstrap case we can say that the bootstrap process provides > its own authentication and data integrity services for its messages, > thus L2 protection for the EBs are not really needed. > > <RCC>You are confusing the purpose of adding the MIC to the beacon. It is not > particularly for security reasons, it is to provide the potential for better > discrimination. This is independent from any security applied during the > bootstrap process.</RCC> So why are we talking about that in the "Security Considerations" section? I myself think protecting EBs with proper key will provide useful features, and for example will allow nodes to reconnect the network without doing the full bootstrap and reauthentication process. > For the fall-back mode of operation when no dynamic scheduling > solution is availabe or functional, this is not true and in such cases > I think K1 protection is mandatory. > > <RCC>I don't see a particular distinction between this and initial > synchronisation. Both provide coarse synchronisation mechanisms > sufficient to allow the node to get itself (back) onto the network. > Maybe you can explain the differences or point me to some text which > explains it.</RCC> If the device looses syncronization or gets dropped out of the network for some reason, and wants to come back, if the EBs are protected with secure K1 then it can trust information in the EBs and do faster reconnect. I.e it will get the ASN etc from the EB, and as the K1 is unique for this network it can trust this information to be correct. It cannot verify that it is not replay, as attacker could have stored the EBs and replay them back to node so it would think the ASN is what it used to be when EBs were sent. After that the node can send any frame protected with K1 to coordinator, and if it will send secured frame back then node will know the ASN is no replay and after that it has resynced the network. Now it just needs to join the network again and for that it can use either K1 or K2 to protect the joining process too. If EBs are not authenticated (or well-known key is used), node cannot really trust anything in there, and security analysis gets harder. I.e. it is not trivial to say that there is no attacks, if node starts using K2 based on the ASN it cannot trust. Sending any encrypted frames using K2 would cause issues, so K2 would be needed to send MICed frames only, and even then I am not sure there cannot be different types of attack (all depends on what kind of protocol the rejoining process is). And of course the K2 might be rekeyed much more frequently than K1, as K2 might be rekeyed everytime there is change in the network members (i.e anybody leaves the network). > For the third use case i.e. "during early interoperability testing and > development" this is mostly non-issue, as none of those networks are > used in real production use. > > DATA, ACKNOWLEDGEMENT, and MAC COMMAND frame types SHOULD be > authenticated and encrypted with key K2. > > If I have understood correctly there are actually lot of cases where > the other frame types are not encrypted, but are only integrity > protected. At least that was my understanding from the comments people > made earlier. Here we still say that they SHOULD be both integrity > protected and encrypted. > > <RCC>I assumed differently, i.e. if any of the above frame do have a > payload, it SHOULD be encrypted. It is not clear to me why you would > deliberately choose to not encrypt a payload of one of the above > frame types.</RCC> Good, that my understanding was wrong. There were people saying something like "they do not see any reason to encrypt anything as there is higher layer end to end encryption there anyways". I myself think that encrypting everything going on with K2 is right way to do it. Of course it again opens some issues if you want to use K2 in rejoining based on untrusted ASN... -- [email protected] _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
