I'll hover here and chip in, we went through all of this with
CipherIM our proprietary Im client in the late 90's 'til 2001.
We did end up generating a key pair at client install time (including
testing password strength with a little feedback 'progress bar' ) and
then storing the public part of our keys on the client domains
server. It all worked fine. We setup SSL client -> server, then
generated a one time symmetric key for each session.
I did write all this up earlier, happy to re-post if I can find it.
David.
On 18/08/2008, at 9:39 PM, Dirk Meyer wrote:
Peter Saint-Andre wrote:
Hi Dirk, thanks for starting a discussion about this.
Let's hope more people will join it :)
certificate. One solution could be to sign the certificate by a CA
everyone knows.
For users whose servers are federated across the open XMPP network,
it's possible that the XMPP ICA could issue client certificates.
Yes, that is solution 1 for this problem. Each user can get a
certificate signed by the XMPP CA. But is that practical. I have not
tried to get a signature for my XMPP server yet, but how hard is it?
Every person who can use an IM client and register for an account
should be able to get a signed certificate. IMHO usability is the main
problem we have to keep in mind when trying to solve this.
But maybe this is not needed, some sort of web of trust based on
the certificates is also a valid solution.
It would be interesting to experiment with using OpenPGP keys for
TLS, as described in RFC 5018:
http://tools.ietf.org/html/rfc5081
Then we could leverage existing webs of trust.
Yes, OpenGPG support in TLS is one solution. I did not know it became
a standard, only experimental, but still, the last version I saw was
only a draft. The big question here: is this supported? From what I
found out openssl does not support it, gnutls does. We should not use
something that is not supported on some platforms.
Maybe we can add a signing mechanism outside X.509 for XMPP. The
certificates would be self-signed and the user needs to verify the
certificate based on the fingerprint, the JID and an XMPP web of
trust.
So your client would generate even just an RSA/DSA key?
Yes, a key-pair and self-sign to make any TLS library happy. After
that we can create a web of trust outside the ssl library. I don't
know if this will work, but it could.
BTW, I think we already have webs of trust in a way over XMPP: we
call it the roster. But currently we don't connect the roster items
to keys or other cryptographic information.
I know, but the roster is only the answer to "Who are my friends?" and
SHOULD NOT the answer to "Is this my friend?". When we both use the
same XMPP server and have TLS between clients and server everything is
secure except that the server itself could read my messages. The
reason for us to open a client-to-client stream is that we do not
trust something in the middle. That "something" is the server, there
is nothing else. So we should not ask the server for keys.
But the roster or the server can be used to help our web of trust. I
could sign your key and upload it to _your_ server somehow. When
a friend of mine receives your key from your self he also gets my
signature knowing that I trust your key.
Has anyone on this list looked into the Secure Remote Password
protocol?
Here are some links:
http://srp.stanford.edu/
http://srp.stanford.edu/whatisit.html
http://srp.stanford.edu/analysis.html
http://srp.stanford.edu/design.html
http://tools.ietf.org/html/rfc2945
http://tools.ietf.org/html/rfc5054
Not yet, but I will take a deeper look.
You might be interested in this, too:
http://www.ietf.org/internet-drafts/draft-groth-openpgp-attribute-
extension-00.txt
Again, I will take a look.
Thanks
Dirk
--
Smash forehead on keyboard to continue.....
------------------------------------------------------------------------------------------------
Email Security by Cleartext a CO2 Free company - www.cleartext.net
------------------------------------------------------------------------------------------------
