On Nov 16, 2013, at 8:30 AM, Learmonth, Iain Ross <[email protected]> wrote: > Phillip Hallam-Baker mentions that this is essentially the CardSpace model > [20] > but taking roaming into account. His view is that you should use one public > keypair per device or if the authentication keys are going to be per site then > you should use a strong (non user chosen) symmetric key and a proof of > possession scheme. There is really no value to a public key scheme for > authentication if there are only two parties to the conversation and no need > for > non repudiation. This is only possible if TLS supports the use of symmetric > schemes for client authentication.
I think you've slightly misrepresented PHB's modification—what he said was that you would keep the public/private keypair per site on the key server, but the keys you use to authenticate to the site would be private keys. This saves having to generate multiple public/private key pairs per site, and works fine as long as you have repudiation. Two additional things that have occurred to me since we had this conversation: - Repudiation can be done by having any device contact the key server and repudiate any key, after having gotten the repudiation message signed by the key server using the private key associated with that site; this avoids the privacy issue of revealing the key server's IP address, but requires that the site actually implement the repudiation protocol; if they don't, you're SOL. One could also have a distributed repudiation model, but I don't think it adds anything. And even with online repudiation, it's up to the site to check that the key hasn't been repudiated, so no matter what, you are relying on the site to do repudiation correctly. The good news is that it's easy to test whether they are doing it, and indeed that could be written into the protocol. - One use case for this is, e.g., if you have a financial manager who needs access to some of your accounts in order to make trades on your behalf, and you want to give them a key, but you'd like to be able to revoke the key. No change to the proposed protocol is required—it's simply another case where this security model would win massively. Thanks for writing up the summary. _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
