Hi Tero, You raise some good points. Comments inline.
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 Robert On 12/05/2015 05:00, Tero Kivinen wrote:
Xavier Vilajosana writes:after the last call we would like to close the security section in minimal. We wrapped up all comments from the previous days and from the meeting and here is our proposal:As you can guess, I disagree with the text. Does this text replace the whole "Security considerations" section or only some of it?
<RCC>Good question - I would assume the whole section</RCC>
<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>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>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>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>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>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>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>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>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>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 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>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.
Again in which case this SHOULD is not needed, i.e. why it is not MUST. What are the exceptions where you can send those frames without integrity protection? I agree that encryption might not be needed, if upper layer protocols provide end to end data confidentiality service, so that might be reason why we do not need encryption, but hop by hop L2 data integrity would still be useful to save resources in the network level, especially if there is routing protocol routing traffic between multiple nodes. The attacker could inject packets to the network and cause them to be forwarded through the network and consume resources on the network unless data frames are not protected. Also this assumes that K2 is in the devices already before they start running the joining process if all data, acknowledgement, and mac command frames need to use it. I do not think this is true, so most likely while using minimal for the bootstrap case the K2 might not be there yet, thus those frames needs to be sent without protection, and also those packets might need to forwarded in the network wasting resources from the network.
<RCC>I agree with that point and this perhaps should be elaborated.</RCC>
On the other hand during the fall-back case the K2 should already be there, and we should use it always.For early interoperability, K1 MAY be set to "6TiSCH minimal15".This again would need to explain what kind of attacks attacker can do when he knows the K1. It does not change anythign for the bootstrap case, but there is huge issues in the fall-back mode case. And if this is only meant for the interoperability testing case, then I do not think we should mention it here, but instead add it to the test specification that is used when running those interoperability tests. This is how it is done normally. And if you still claim that there would be uses for well-known K1 because of "network spearation issue", then this needs to be mentioned, and explainined why you think this is true. On the other hand that text does not belong to the security considerations section as it is not security issue, as well-known K1 does not provide any security services. So this K1 definition should be moved away from security considerations section to its own separate section, and in security considerations section there should only be the warnings saying that if well-known key is used for K1, then that does not provide ANY security benefits, and it MUST NOT be used in production network requiring any kind of security.
<RCC>I agree it might be worth elaborating on the purpose of using K1</RCC>
K2 SHOULD be a randomly generated high entropy cryptographic key. Key distribution is out of scope.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
