The global directory is queried once per TLS server and client pair. This is done over a TLS strong authentication connection between the global directory server and the TLS server. The query by the TLS server and its response is encrypted. After that, the server holds onto the user's public key for future connections from the client. There is no new centralized traffic point other than all the routers that make up the internet for passive listeners to exploit.
Under current TLS strong authentication negotiations, the server must have the client's public key uploaded to it over a secondary channel before the connection can be authenticated. This proposal eliminates this requirement. In essence I'm proposing doing away with reliance on the Certificates entirely. Only public/private keys are required. Karl From: Jon Callas [mailto:[email protected]] Sent: Thursday, September 12, 2013 06:21 To: Karl Malbrain Cc: Jon Callas; Phillip Hallam-Baker; Theodore Ts'o; [email protected] Subject: Re: [perpass] proposed enhancement to TLS strong authentication protocol On Sep 11, 2013, at 11:56 AM, Karl Malbrain <[email protected]<mailto:[email protected]>> wrote: The goal of the proposal is to enable the use of strong authentication for all TLS connections over the internet. The certificates as things-in-themselves don't really matter, they are actually just a vehicle to post the public key of the user/server in a reliable public place. The security occurs when the challenges to prove private key ownership are cross-issued by each party. MITM would not have the private keys to answer either challenge. Note that this still doesn't solve the problem of MITM obtaining the server's private key. I'm still working on that one. I might be misunderstanding, but it seems to me that your global directory would allow a passive listener to fingerprint the client by sniffing in a variety of places -- near the client, near the server, or near the directory. If you assume an attacker interested in collecting metadata about the clients, this would be suboptimal. I may be missing something, but this sounds like it is just a global, central certificate authority, albeit one that is not actually issuing the certificates, but still assigning them GUIDs, which are by definition globally unique. Am I indeed missing something? Jon
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
