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
