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.
-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
