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
