Re: [STDS-802-Privacy] Proposal on a MAC mediator protocol
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
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
>