On 09/10/2012 09:30 PM, Paul Lambert wrote: > >> -----Original Message----- >> From: Rosen, Brian [mailto:[email protected]] >> Sent: Monday, September 10, 2012 1:14 PM > ... >> It would be easy to discover the certs of the DBAs, because there are >> few of them, and controlled by regulators. Discovery of the server can >> include discovery of the certs. The other way is harder for >> manufacturers because of the issues you cite, but overall, it's much >> easier than shared secrets. > So, we may be in agreement :-) > > The DBs can be discovered, but they need some common trust point > in the devices per regulatory authority. > >> >> It is a requirement to authenticate both sides, so we need solutions >> for both. > Looking at the security stuff documented by this group, we have > as a threat: > 3.2.1. Impersonation of a master device
Where's that? I only see a "MAY" in [1] for client auth (which I think is correct). S. [1] http://tools.ietf.org/html/draft-ietf-paws-problem-stmt-usecases-rqmts-08#section-8 > A little late for me to argue this requirement, so yes we > have created a requirement for master device authentication. > I don't see why a Rogue device even cares about the DB. The > devices are "certified" as compliant to the regulatory rules. > Extra cryptography will not prevent Rogue devices from simply > transmitting in whatever channel they want. > > Given this client authentication requirement - I totally agree > that client public keys are a little more work, but always > better than distributing secret keys. > > Paul > >> >> Brian >> >> >> >> -----Original Message----- >> From: Paul Lambert [mailto:[email protected]] >> Sent: Monday, September 10, 2012 04:04 PM Eastern Standard Time >> To: Rosen, Brian; 'Peter McCann'; 'Peter Stanforth'; 'Stephen >> Farrell'; '[email protected]' >> Cc: '[email protected]' >> Subject: RE: [paws] PAWS security >> >>> -----Original Message----- >>> From: Rosen, Brian [mailto:[email protected]] >> ... >>> The easiest way to do this is to have the manufacturer put a cert in >>> the device that it signs. Then the only thing the database needs is >>> the public key of the manufacturer, >> You cannot prevent spoofing of a DB without having a root of some sort >> that "certifies" real db providers. This is a small number of >> certificates installed in the servers. >> >> Having a per-device cert signed by a manufacturer and installed in the >> factory is harder. It's more certificates and complicates the >> manufacturing process. The authentication to a manufacturer is not >> necessarily useful. The authentication of the manufacturers FCC ID and >> device Id might be of interest, but the regulations do not mandate >> (AFAIK) this complexity of assignment of a few bits of per device >> regulatory information. >> >>> Why do we want to make this harder? >> There are two requirements: >> - authentication of multiple DB providers within a regulatory domain >> - "secure" transmission of Regulatory ID and Device identification >> to DB >> Proposal below was primarily focused on the first requirement above. >> Your proposal for device certs is for the second. >> Both might be required ... device certs have other options also than >> manufacturer oriented certs and is a longer discussion. >> >> Paul >> >>> Because some manufacturers think its too much work to do that? >>> >>> Brian >>> >>> >>> >>> -----Original Message----- >>> From: Paul Lambert [mailto:[email protected]] >>> Sent: Monday, September 10, 2012 03:15 PM Eastern Standard Time >>> To: Peter McCann; Peter Stanforth; Stephen Farrell; >>> [email protected] >>> Cc: [email protected] >>> Subject: Re: [paws] PAWS security >>> >>> >>>> This restriction may hold today for the FCC, but I have a hard time >>>> believing that a pre-existing manufacturer-database relationship >>>> will be mandatory in every regulatory domain for the forseeable >>>> future. I think we should design to minimize the friction in >>>> changing database providers. >>> >>> The least friction would be to hardwire devices with a PK "root" for >>> each regulatory domain that the device supports. >>> >>> Valid DBs would have credentials signed by the key holder of roots >> for >>> each regulatory domain >>> >>> Paul >>> >>> >>>> -Pete >>>> >>>> Peter Stanforth wrote: >>>>> I completely agree with your statement below. If we are good any >>>> radio >>>>> will have the "Technical" capability to work with any database. >>>>> BUT, and this is a big BUT, the regulation may not allow it - The >>>>> FCC does not today. And as a DBA I only want to work with devices >>>>> where I have a predefined relationship. Not least of which, >>>>> because as I am authorized by a Regulator I want to make sure I >> am >>>>> doing everything I can to avoid their wrath. >>>>> This has come up before. PAWS is defining an API/Protocol, not >> the >>>>> regulation nor the business cases at this time. So I still say >>>>> that >>>> we >>>>> can comply with your statement without considering a "User". >>>>> >>>>> On MonSep/10/12 Mon Sep 10, 2:18 PM, "Peter McCann" >>>>> <[email protected]> wrote: >>>>> >>>>>> This is a key question we need to answer. >>>>>> >>>>>> I thought we were defining a protocol that would allow a radio >>> from >>>>>> any manufacturer to interoperate with a database of any database >>>> vendor. >>>>>> >>>>>> -Pete >>>>>> >>>>>> Peter Stanforth wrote: >>>>>>> Pete, I am not sure I believe in a use case where "users" move >>>>>>> from one DB to another. The relationship is between the radio >>>>>>> vendor and the DBA. The radio vendor may have multiple >>>>>>> relationships and allow an end user to choose one, but it will >>> be >>>>>>> from the predefined >>>> list. >>>>>>> As a DBA I don't think I would want, and in the USA we are not >>>>>>> permitted, to establish a relationship with a user without a >>>>>>> preexisting relationship with the radio vendor. So security >>> should >>>>>>> be primarily a radio vendor-DBA issue. Wearing my DBA hat I >>>>>>> don't think I would want to service a radio that I do not have >> a >>>>>>> preexisting relationship with it's manufacturer. I am not sure >>>> that >>>>>>> user relationships are even within the scope of what PAWS >> should >>>>>>> be >>>> defining. Peter S. >>>>>>> >>>>>>> On MonSep/10/12 Mon Sep 10, 1:58 PM, "Peter McCann" >>>>>>> <[email protected]> wrote: >>>>>>> >>>>>>>> Personally, I think that manually provisioned symmetric keys >>> will >>>>>>>> severely limit the ability for users to flexibly move from one >>>>>>>> database provider to another. It will require some secure >>>>>>>> out-of-band channel on which to transmit the secret key from >>>>>>>> one party to the other, and a mechanism for the user to push >>>>>>>> the >>>> secret >>>>>>>> key down into the master device. >>>>>>>> >>>>>>>> Provisioning of certificates does not require the secret >>> channel, >>>>>>>> only one that is integrity protected. I think this is much >>>>>>>> easier to achieve in practice. >>>>>>>> >>>>>>>> -Pete >>>>>>>> >>>>>>>> Stephen Farrell wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> On 09/07/2012 10:01 PM, [email protected] wrote:> At the >>>>>>>>> Vancouver F2F we had extensive discussions on the security >>> model >>>>>>>>> for PAWS. Draft-das proposes to use shared secrets pre- >>>> provisioned >>>>>>>>> in the master devices for authentication, while draft-lei >>>> proposes >>>>>>>>> to mandate client certificates into master devices. >>>>>>>>>> >>>>>>>>>> There seemed to be an understanding that the credential >> types >>>>>>>>>> in >>>>>>> use >>>>>>>>> for authentication are a matter of a business model chosen by >>>>>>>>> the provider which deploys white space devices, rather than a >>>> protocol >>>>>>>>> decision. >>>>>>>>>> >>>>>>>>>> Brian mentioned that the iesg may not allow a document to be >>>>>>>>> published which specifies how shared secrets are used, but >>>>>>>>> does not have a provisioning mechanism for the shared secrets >>> defined. >>>>>>>>> In my opinion, a mechanism for distributing shared secrets >>>>>>>>> does not necessarily have to be defined, as a shared secret >>>>>>>>> can be established using current practices to set up shared >>>>>>>>> secrets with financial institutions (using the browser). >>>>>>>>>> Thus, my suggestion would be to describe in the document how >>>>>>>>>> a shared >>>>>>>>> secret and how a client certificate is used to authenticate a >>>>>>>>> master device. Then, if we run into issues with iesg, in >> worst >>>>>>>>> case we could remove the shared secret part and keep the >> other >>>> one. >>>>>>>>>> >>>>>>>>>> I'd like to get additional views on this topic. >>>>>>>>> >>>>>>>>> I can help a little here (depending on your definition of >>>>>>>>> help:-) >>>>>>>>> >>>>>>>>> BCP 107 [1] is the one to look at when considering how to >>>> approach >>>>>>>>> automated key management requirements. That has an IMO very >>> good >>>>>>>>> abstract: >>>>>>>>> >>>>>>>>> The question often arises of whether a given security >> system >>>>>>>>> requires some form of automated key management, or whether >>>> manual >>>>>>>>> keying is sufficient. This memo provides guidelines for >>>> making >>>>>>>>> such decisions. When symmetric cryptographic mechanisms >> are >>>> used >>>>>>>>> in a protocol, the presumption is that automated key >>>> management >>>>>>>>> is generally but not always needed. If manual keying is >>>>>>>>> proposed, >>>>> the >>>>>>>>> burden of proving that automated key management is not >>>> required >>>>>>>>> falls to the >>>>>>> proposer. >>>>>>>>> For those that might be less familiar with IETF processes, >> the >>>>>>>>> fact that that's a BCP means that its entirely valid for an >> AD >>>>>>>>> to strenuously push back against a WG that wants to ignore >>>>>>>>> what it >>>> says. >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> S. >>>>>>>>> >>>>>>>>> PS: I've not read the drafts, and couldn't make the session >> in >>>>>>>>> Vancouver, so this might be entirely off topic, but in the >>>>>>>>> case >>>> of >>>>>>>>> PAWS I'd also argue that the regulators' apparent desire to >>>>>>>>> force devices to authenticate is not necessarily the right >> one >>>>>>>>> for the IETF to force upon all users of the PAWS protocol. So >>>>>>>>> there could for example be a mode of operation where the DB >>>>>>>>> signs stuff but doesn't care who's asking and that'd be a far >>>>>>>>> far easier scenario in terms of automated key management. >>>>>>>>> >>>>>>>>> [1] http://tools.ietf.org/html/bcp107 >>>>>>>>> _______________________________________________ paws mailing >>>>>>>>> list [email protected] https://www.ietf.org/mailman/listinfo/paws >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> paws mailing list >>>>>>>> [email protected] >>>>>>>> https://www.ietf.org/mailman/listinfo/paws >>>>>> >>>>>> >>>>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> paws mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/paws >>> _______________________________________________ >>> paws mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/paws _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
