"Eric Rescorla" wrote: > 1. A PAKE mode (SRP)[0] > 2. Session resumption.
After some searching I found only a draft about SRP and TLS, but openssl seems to support it which is a good sign. I want to avoid using something libraries do not support. > SRP allows the client and server to establish an authenticated connection > based purely on a short password. The only restriction is that they need > to share a known DH group, but that's easy to profile. What is a DH group? > If you're not willing to have long-term secret storage (though why you would > be willing to have long-term public storage but not secret storage would > need some explaining) you can do TLS-SRP and then rehandshake on the > same TLS channel, this time using self-signed certs, and then the peers can > simply remember each others certs. Let me try some scenarios here and you tell me if I missed something. Let us asume a client may have a client certificate that is different from the user certificate. But we have a pubsub entry with a list of all client certificates for a user signed by that user certificate about X.509 (setting up a CA is very complicated). Now Alice connects to a client of Bob. They look up if they know each other and they don't. So they choose SRP. I window will pop up asking for a password. Both user enter the password, TLS works and after that we do a rehandshake based on the certificates. Now both have the client certificate of the other. Using XMPP we can exchange the user certificate. Works! Now Alice and Bob connect again with different clients. They have the user certificate and use "normal" TLS handshakes. They receive a certificate they do not know. They look up the pubsub items and find the key they got and vertify the signature of that key using the others user certificate. Works! I start a client (e.g. set-top box). It generates a self-signed certificate and searches for a client of mine with the users secret key. This is doable in XMPP somehow. Let's call such a client master now. The new client connects to my master and chooses SRP. I either enter a password on both sides or the new one may have a static printed somewhere. After that we rehandshake, the client has the master public key and the master has the client certificate to sign and put on the XMPP server. Works! The XMPP server is used to store user certificates of friends signed by any client key or user key. It is also used to hold a list of client certificates and to revoke client certificates. The only thing that that not work if Alice wants to connect to a dump set-top box of Bob and never connected with Bob before. But IMHO this is a good sign. You should always start with connected to a client controlled by the user and not the bot. How does this sound? Dirk -- When nothing can possibly go wrong, it will.
