On 09/10/2012 09:55 PM, Rosen, Brian wrote: > I think the may is that not all domains need it. So the protocol has to > define how to do it, but implementations may not need it if they only are > intended for deployment in jurisdictions that don't require it AND the DB > doesn't need it (where service may not dependent on such authentication).
That was my understanding all right. S > Brian > > > > -----Original Message----- > From: Stephen Farrell [mailto:[email protected]] > Sent: Monday, September 10, 2012 04:47 PM Eastern Standard Time > To: Paul Lambert > Cc: '[email protected]' > Subject: Re: [paws] PAWS security > > > > 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 > _______________________________________________ paws mailing list [email protected] https://www.ietf.org/mailman/listinfo/paws
