- as individual- In a deployment using shared secrets, changing the provider should not require the shared secret to be transferred between providers. The master device could set up a new shared secret with the new provider. Using client certificates is not problem free either: if the master device's certificate is not signed by a CA whose root cert is trusted by the new provider, then trust has to be established or the master needs to enroll to get a new cert from that provider. - Gabor
-----Original Message----- From: ext Peter McCann [mailto:[email protected]] Sent: Monday, September 10, 2012 10:58 AM To: Stephen Farrell; Bajko Gabor (Nokia-CIC/SiliconValley) Cc: [email protected] Subject: RE: [paws] PAWS security 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
