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
