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
