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
