> 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
