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
