Hi, Gabor, [email protected] wrote: > Hi Pete, > My responses inline: > > -----Original Message----- > From: ext Peter McCann [mailto:[email protected]] > Sent: Thursday, April 19, 2012 2:42 PM > To: Bajko Gabor (Nokia-CIC/SiliconValley); [email protected] > Cc: [email protected] > Subject: RE: identity verification (was: Database Discovery Question) > >> Hi, Gabor, >> >> [email protected] wrote: >>> Hi Pete, >>> >>> Some comments inline: >>> >>> >>> -----Original Message----- >>>> From: [email protected] [mailto:[email protected]] On >>>> Behalf Of ext Peter McCann >>>> Sent: Wednesday, April 18, 2012 9:02 AM >>>> To: Rosen, Brian >>>> Cc: [email protected] >>>> Subject: Re: [paws] Database Discovery Question >>>> >>>> Hi, Brian, >>>> >>>> The problem is, the master device cannot be authoritative on >>>> whether the slave device is approved for use by the regulator. It >>>> must rely on the WSDB it uses (has a relationship with) to tell it. >>>> >>>> At the least, we need a format for device identifiers that can be >>>> understood by multiple independently operated databases. >>>> >>> <GB> yes, this should be part of the data model. >> >> Agreed. >> >>>> Maybe the WSDB trusts the master device to collect this information >>>> securely from the slave devices using slave-to-master credentials. >>>> >>> <GB> yes, this is what at least the 802.11af draft amendment is >>> currently defining for the 802.11 air interface. The slave sends its >>> identifier to the master, then waits for the enablement signal. The >>> enablement signal comes after the master was able to successfully >>> validate the identifier of the slave with the DB. >> >> Is there any security or spoofing protection defined in 802.11af? >> > <GB> It inherits whatever is in the 802.11 base spec, ie .1x
Ok, so there are two sets of credentials. One is a Network Access Identifier used within EAP between the slave and the master. The second is a regulator-assigned identifier (such as an FCCID). Although the NAI can be authenticated using e.g., AAA back-end servers, it is NOT the same identifier that is used by the master to validate the slave for purposes of regulatory compliance. >>>> Normally, the allocation authority for the identifier space would >>>> be a trust anchor for the identifier-to-device binding. I agree >>>> that the master-to-slave interface is out of scope, but there >>>> should be some mechanism in the marketplace for the master device >>>> operator to securely bind the identifier presented by the slave to >>>> the communication channel with the slave device, in the sense that >>>> the master device is able to know in a secure way that the device >>>> it is talking to actually does own the regulator-assigned device >>>> identifier. It seems natural for the master device to rely on its >>>> relationship with a database to help with this binding. >>>> >>> <GB> I see two things here: binding between the communication >>> channel and identity; and binding between the identity and the >>> hardware to which it was assigned. The binding between the >>> communication channel and the identity as presented by slave is >>> there inherently in the radio. >> >> I don't understand this last statement. Do you mean a >> cryptographically secure binding? What if I spoof my MAC address? >> > <GB> Assuming an RSN network, after the .1x procedure, there is a key > derived to encrypt the STA to AP communication. > 802.11af does not assume that the credentials the slave has to get > authenticated with the master can in any way be used to prove the > ownership of the identity. There's a set of credentials for slave- > master authentication, and there might be (currently there is no > requirement for it) another mechanism for the slave to prove to the db > that it owns the identity it sent to the master. This is the critical decision we have to make. Note that the identity the slave sends for access authentication is different from the one it sends for validation with the database. Is there any cryptographic credential whatsoever associated with this second identifier? Why are we checking it against a whitelist at all, if it can be easily spoofed and replaced with another? >>> The task to verify that the identity indeed belongs to the slave >>> should not be the burden of the master device, rather the DB (if >>> seen necessary). In order for the DB to verify that the presented >>> identifier indeed belongs to that device, a client cert or sg >>> similar would be needed. >> >> That seems reasonable to me. The slave device has a client cert and >> somehow demonstrates knowledge of the private key that goes with the >> cert to the database. After this, the database can send "I approve" >> to the master device. Assuming that both communication channels >> (slave to master and master to database) have been authenticated and >> secured, the master can then tell the slave to go ahead. >> >> However, we now require the database be able to validate the >> credentials of any slave device that may be manufactured/owned by >> someone other than the manufacturer/owner of the master device. It >> would seem we need a nationally-scoped trust anchor to achieve this. >> > <GB> I think this is the part which is outside the scope of our > charter, which says: " 4. Ensure that the discovery mechanism, > database access method, and query/response formats have appropriate > security levels in place. ". There is no mention about the db making > sure the slave devices did not spoof their identity. Especially as > regulators do not require slave devices to have a mechanism to be able > to prove ownership of the identity. If I remember correctly, this was > considered in FCC, but then the requirement was dropped. Ok, so the check at the database is pretty meaningless, because the FCCID can be replaced with someone else's with no accountability. What's to prevent an attacker from spoofing someone else's FCCID, then behaving badly on the wireless channel in such a way that the FCCID needs to be put on a blacklist? It would be impossible to prevent this kind of DoS attack. >>> Afaik, regulators do not require for client certs binding the >>> identifier to the hardware. Therefore, the verification of whether the >>> identifier is the correct one or not seems to be outside the scope of >>> paws. The master should rely on the lower layers and the DB for this >>> verification. > >> This statement really confuses me. To me, a binding of an identifier >> to hardware means that there is some tamper and copy-proof storage for >> a private key epoxied into the wireless hardware. This private key >> would be used to authenticate & distribute keying material for a >> secure channel between the slave and the master. That part is indeed >> out of scope of PAWS, but the master-to-database messages to validate >> the slave's credentials are not. > > <GB> I think the confusion might come that you assume the private key > in the slave (if existed at all) would also be used to authenticate > the slave to the master. In my understanding that would not > necessarily be the case. Even if there was a private key in the slave, > the slave would acquire another set of (eg username/password) > credentials, independent of the private key, to connect to the master device. Ok, I now understand there will be two identifiers and one or two sets of cryptographic credentials. If there is only one cryptographic credential, it will be associated with the network access (slave-to-master) link, and you think the second cryptographic credential is just not needed. -Pete > - Gabor _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
