> 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.
Yes!!! Distributing symmetric keys is a really bad idea for PAWS. They scale poorly, are more difficult to manage, and are more readily subject to misuse. Paul > > 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
