[STDS-802-Privacy] Proposal on a MAC mediator protocol
The following is a proposal on a MAC address mediator protocol.
Its purpose is to resolve MACaddr collisions, meeting the 802 policy
that if local scope addresses are used, there will be such a mediator
feature (or some such; someone help me with the exact wording that Pat
used monday evening).
To work, this protocol is crypographically based. Paul Lambert had
point out to me how my own ideas in HIP could be used for MAC addresses
as well. I have thought a lot about this and I will cut to the chase,
skipping over why I chose want is here. I am willing to put together a
few slides for thursday evening.
Here goes:
Every participating device has a MAC entity Identity consisting of the
public key of a ECDH keypair. A hash of this key into a 128 bit value
is the MAC entity Identifier, much like the HIT in HIP. A hash with a
nonce will be used to create the actual MACaddr used by the device. For
privacy purposes, the ECDH keypair are ephemeral, a device can
precompute a number of these and have them ready to use at will. For
collision avoidance a device must be ready to use a different Identity
or nonce to present a different MACaddr.
The media MAC mediator will regularly broadcast its ECDH public key.
This key MAY be contained within a digital certificate that a
participating device can validate from cached information; this is not
required. The timing of these broadcasts will help a device to
recognize the mediator of the media. In practice this could be a
function of a DHCP or RADVD server (or AP BEACON).
At linkup time, a device will listen for these broadcasts, use the
public key therein along with its Identity key and a nonce to construct
a shared secret. This secret will be used to MIC a packet to the
mediator that will contain the devices: MACaddr, Nonce, Identifier, and
Identity. If this is a new MACaddr for the mediator it would reply with
an ACCEPT MICed message. If there is a collision, it will REJECT,
causing the device to select a new MACaddr and try again.
The use of crypto should be apparent to most here, to protect against
attacks. ECDH is the lightest weight algorithm we have. I would even
recommend using a fold rather than a SHA hash as I do in HIP-DEX to
further lighten to load (for very small IoT devices, though 64 bit MACs
will should have a larger number space anyway). Plus the active nature
of an ECDH protocol protects against replay attacks. A 'key' feature
here is that it is actually the Identifier (and Identity) that are
registered with the mediator, and thus presenting a much larger number
space to lower the probablity of collisions.
A 'downside' to the existance of such a mediator protocol is that it can
be argued that given a collision resolution protocol, the privacy
feature CAN operate within a smaller number space.
This mediator protocol would be optional in environments where ZEROconf
is used. Afterall, who is the mediator on such a media?
This is basically a 3 packet protocol: BEACON, REQUEST, RESPONSE. It
can be fit into many existing such protocols already deployed on various
media.
Thank you and goodnight.