Re: [STDS-802-Privacy] Proposal on a MAC mediator protocol
On 11/5/14, 11:30 PM, "Robert Moskowitz" <rgm@xxxxxxxxxxxxxxxxxxxx> wrote:
>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.
Yes - but it¹s not necessary to have the mediator you describe below
to cryptographically bind a Public Key to a MAC Address.
Per our discussion, I was referring to:
https://mentor.ieee.org/802.11/dcn/12/11-12-0378-00-0wng-key-centric-identi
ty.ppt
Slide 17 of the following is more what I intended from our discussion to
show changing addresses:
http://csrc.nist.gov/groups/ST/key_mgmt/documents/Sept2012_Presentations/LA
MBERT_CKMW2012.pdf
Basically a MAC address can be constructed as:
MAC_i_t = H(cipher_suite, public_key, time_t, nonce_i)[0:6]
With H being a cryptographic secure hash like SHA256
It is possible to have the MAC address change by instance of usage or
over time and be bound to a longer term public key
Two devices claiming the same MAC address would be distinguishable
post authentication. Having a security association between devices
disambiguates and detects collisions.
Paul
>
>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.