Sure, a new shared secret can be assigned by the new provider. However, some sort of confidential channel must be provided to communicate the shared secret from one side to the other.
In contrast, a certificate signing request does not need confidentiality, only integrity protection. -Pete [email protected] wrote: > - 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
