Dear all : I did not get an answer to the complex question asked in the attached mail. Seems, though, that the strength derived from a 64 bits token will not be sufficient over time. This tells us that we need to make the EUI-64 field bigger when using a cryptographic token.
My proposal is to change slightly RFC6775-update to allow a Length of the ARO that is not limited to 2. The size of the ROVR field (the new name of the EUI-64 field after the current IESG review) is then deduced from the Length of the option. We also need to update the DAR similarly. A larger field can only be used when there is no backward compatibility issue. This is now discovered only with the 6CIO, in the RS / RA prior to the registration so we should be all good. Please let us know if there is an issue with all this. I intend to make the changes in -15 by cutoff Monday. Cheers, Pascal From: 6lo [mailto:[email protected]] On Behalf Of Pascal Thubert (pthubert) Sent: mardi 30 janvier 2018 09:51 To: [email protected] Subject: [6lo] Strength of the 64 bits token in AP-ND Dear all: As you now, AP ND is backward compatible with RFC 6775 and uses the same message formats. The EUI 64 field in the ARO and in the DAR/DAC message is used to transport the token that enables the proof of ownership validation. With the current draft, the token is mostly a compressed form of a public key. We use SHA-256 so we could make it 256 bits long. But for backward compatibility we use only 64 bits from the hash. This makes it easier for an attacker to form its own keypair that would derive into the same token. When the device moves, it is challenged by the new 6LR, which will validate the token as above and check with the 6LBR that the token is the same as earlier with the other 6LR, in a fashion consistent with RFC 6775. Only the 6LR will have visibility on the entire public key used during the challenge, there is no room in the DAR/DAC for it. An attacker may fake a moving device and be able to claim the address if it can build an identical token with a key of its own. One key question is the level of protection that we get with this. I see the following possibilities (hopefully there's more?): - by compressing the public key to 64 bits as the draft does today we have a limited security; may be acceptable in some networks, and provides backwards compatibility - using the whole 256 bits out of the SHA hash, the size of DAR and DAC messages and the ARO option would be impacted. We'd have to rework the backward compatibility with 6LoWPAN ND, ensure that the 6LR / 6LBR supports this spec before using a larger token, and use a larger field when the network is not backlevel - RFC 3972 has a trick whereby the cost of generating a new CGA depends exponentially on a security parameter Sec, both for the attacker and the defender. This allows more security with 64 bits only, but is exponentially compute intensive on the 6LN if it has to generate the token. Note that in some cases the token modifier could be provisioned to the device together with the key pair. In our description we are not going through the CGA steps. It might be that they are encumbered. We have a small modifier to be able to generate a limited number of tokens for one key, but it is small enough so an attacker cannot generate too many tokens for one key, so it has to generate many keys before it finds one that derives into a same token. What do people think? Pascal
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
