Re: [STDS-802-Privacy] Proposal on a MAC mediator protocol
On 11/26/14, 2:26 PM, "Paul Lambert" <paul@xxxxxxxxxxx> wrote:
>On 11/26/14, 12:09 PM, "Rene Struik" <rstruik.ext@xxxxxxxxx> wrote:
>
>>Hi Paul:
>>
>>Thanks for your note below.
>>
>>Could you elaborate a little bit on the "rigidity" and difficulty to
>>cater to address changes?
>>
>> - above per 802.11ai (existing, but rigidly in it¹s own model of
>> connectivity and may not map well to MAC address change requirements)
>Rigidity meaning that the standard has multiple key management techniques
>some of which do not look like they would be readily modified to support
>my proposal. It’s possible, and the public key mechanism in 11ai might be
>able to be extended. The relationship to the 11ai address assignement and
>such also make it more difficult to modify.
>
>>
>>If the address is a function of a device's public key and nonce,
>>obviously "address ownership" requires the device to evidence ownership
>>of the corresponding private key. Do you have in mind that with each
>>different nonce the device signs a message to prove ownership, e.g., via
>>ECDSA?
>Not necessary. Private nonce may simply be exposed after the key exchange
>to show ownership. This is the same concept as the EMV Blinded ECDH
>exchange. The primary entity key is masked and may optionally be exposed
>by sharing the nonce used to mask the public key.
>
>>
>>Just curious: could you expand a little bit on the "per EMV spec" remark
>>below? (btw - does this refer to EMVCo?):
>>
>> I¹d disagree a little Š first the above key exchange is not quite
>>right,
>> I¹d suggest a blinded more static key usage (per EMV specification, plus
>>a
>> MAC blinding nonce).
>Simple version of suggested exchange below …. Minus some other features:
>
>csi = cipher suite identifier
>H = secure hash determined by cipher suite
>f = key derivation function determined by cipher suite
>s_i + secret for ‘i’
>G = group generator (using additive notation)
>P_i = s_i*G
>m_j = scalar random mask value (jth for i)
>Q_ij = m_j*P_i
>MAC_ij = H(csi, Q_ij, f(TSF))[0:6]
>
>MAC_kl = same as above but kth MAC of P_l
>
>Exchange
>
>MAC_ij —- csi, Q_ij —> MAC_kl
>MAC_ij <—- Q_kl —- MAC_kl
>
> Keys now calculated on both sides
>K_ij=K_kl= f(csi, m_j*s_i*Q_kl) = f(csi, m_k*s_l*Q_kij)
>
>Sharing m_j encrypted under derived key shows binding of Q_ij to P_i
>
>MAC_ij —- encr(k_ij, m_j, P_i, etc) —> MAC_kl
>
> MAC_kl can validate that
> Q_ij = m_j*P_i
And can validate that
MAC_ij = H(csi, Q_ij, f(TSF))[0:6]
Note - devices should maintain relationships based on “Id” not MAC
E.g.
Id_i = H(csi, P_i)[0:16]
If MAC_ij ever equal to some other MAC_kl the
Id_i should never equal Id_k unless they have the same private key
Paul
>
>Paul
>
>
>
>>
>>
>>Best regards, Rene
>>
>>On 11/21/2014 4:27 PM, Paul Lambert wrote:
>>> On 11/6/14, 11:57 AM, "Robert Moskowitz" <rgm@xxxxxxxxxxxxxxxxxxxx>
>>>wrote:
>>>
>>>> On 11/06/2014 01:03 PM, Christian Huitema wrote:
>>>>>> 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.
>>>>> Curious how that meshes with 802.1x/EAP, or with WPA2. Did you
>>>>>research
>>>>> that?
>>>> There is a high degree of commonality in these protocols. In part as
>>>> there are only a few ways to do them right. Plus a few of us have
>>>> worked on more than one. Lots of cross knowledge transfer.
>>> I¹d disagree a little Š first the above key exchange is not quite
>>>right,
>>> I¹d suggest a blinded more static key usage (per EMV specification,
>>>plus a
>>> MAC blinding nonce).
>>>
>>> 802.1x/EAP is problem in the 802.11 security architecture. Doing good
>>> peer-to-peer authentication is not well modeled hy the client/AP/AAA
>>> three-way model of 802.1x and EAP.
>>>
>>> It would be much better to use pre-association frames for a key
>>>exchange.
>>> For new P2P authentication, there are multiple options:
>>> - action frames (my preference)
>>> - probe req/rsp (easy, but include legacy cruft and not efficient)
>>> - authenticate and/or associate frames
>>> - above per 802.11ai (existing, but rigidly in it¹s own model of
>>> connectivity and may not map well to MAC address change requirements)
>>>
>>> WPA2 is in several parts Š the 802.1x setup is an issue (IMO) per
>>>above,
>>> but is not necessary and easily left out. The WPA2 4-way handshake
>>>steps
>>> are required to get nonces for the CCM/GCM Tk. However, the YK could be
>>> more directly estblished by a stream-lined authentication exchange
>>>(e.g.
>>> 802.11ai). Finally, the broadcast Group Key is shared during the 4-way
>>> exchange. This is a longer discussion Š since broadcast keys in a P2P
>>> environment need to be device unique.
>>>
>>> Paul
>>>
>>>
>>>
>>>>>> 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.
>>>>> What if there is no link-up time, as in for example Wi-Fi probes?
>>>>>When
>>>>> scanning for available networks, Wi-Fi devices send probe packets to
>>>>> elicit responses from any access point that would be present. These
>>>>> packets are sent infrequently, maybe every few minutes, while the
>>>>>device
>>>>> is not connected to any network and is in fact moving between
>>>>>networks.
>>>>> Uniqueness in one of these networks is not a guarantee of uniqueness
>>>>>in
>>>>> the next one.
>>>> First not only is there no reason to care what MACaddr is used for
>>>> PROBES, Apple already uses a random one to not leak tackable
>>>>information
>>>> about the devices. Use ANY MACaddr you want. Could be a problem if
>>>> there is a collision with an address that is already used and secured.
>>>>> This scanning traffic is a well known target of tracking systems.
>>>>> Protecting it is a high priority. That's the first application of
>>>>> randomized MAC addresses. And for that application, the simplest
>>>>> solution is statistical uniqueness through large enough random
>>>>>numbers.
>>>> If the address is only used for PROBES, just dream one up (local scope
>>>> of course) and use it. This need not be the one you plan on actually
>>>> using for the ASSOCIATION.
>>
>>
>>--
>>email: rstruik.ext@xxxxxxxxx | Skype: rstruik
>>cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
>>