Re: [STDS-802-Privacy] Proposal on a MAC mediator protocol
On 11/26/14, 3:58 PM, "Christian Huitema" <huitema@xxxxxxxxxxxxx> wrote:
>> 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
>
>The problem of course is that when you do that, you reveal the public key
>P_i to the other party. This has an obvious privacy effect, which depends
>on the lifetime of that public key. If the lifetime is "forever," then we
>have a long term identifier and a privacy issue. Of course, the privacy
>effect could be mitigated by picking a different public key for each
>"session," but that supposes cipher suites in which picking such random
>keys is easy.
>
>Before we go further, we should be clear about what problem we are trying
>to solve. Clearly, this type of exchanges can be used to prove that the
>device "owns" a particular random number. But what does that ownership
>mean? If two devices claim the same key, who wins? Who decides?
Two Œdevices¹ that prove they have the same key must be treated as the
same device.
But to the main point, what are we problems are we trying to solve? I may
have taken us away from just MAC address randomization to a
specific approach to both randomize an address and support an ability to
find and authenticate devices.
Privacy is not the same as anonymity. Authentication and authorization
must still be supported for some scenarios. It¹s just that at a minimum
there should be privacy from third party observation of wireless frames
disclosing private information. Not sending a long term public key
in the clear also helps, but does not fully solve how to determine
which key/identity to show under the key exchange to another device.
Paul
>
>-- Christian Huitema
>
>