On Aug 21, 2008, at 8:37 AM, Hannes Tschofenig <[EMAIL PROTECTED]
> wrote:
TLS-SRP does not make a lot of sense in the context of end-to-end
security between two clients.
If you exchange a shared secret along the signaling path then you
can feed that right into TLS-PSK without the need to use TLS-SRP.
That is, however, not ideal either (from a security point of view).
There is a big difference btwn a 20 bit key which can be secure with
srp versus a 80 bit or so key with psk. If users are in the loop...
Ekr
Instead, you might just want to use the same stuff that was done
with DTLS-SRTP where the fingerprint of a cert is exchanged along
the signaling path to be later compared to the certs being exchanged
in the DTLS (or TLS run).
Dirk Meyer wrote:
Hi,
I have two questions if I understand RFC 5054 correctly. In our
scenario we have two clients with unverified certificates and a
shared
secret we use as password. One acts as TLS client, the other as TLS
server. Now I want to be sure that not only the TLS server can verify
the client knows the password but also the other way around. Looking
at the RFC I see that the premaster secret is calculated by both
parties using x with x = SHA1(s | SHA1(I | ":" | P)) and P is the
password. The server uses this indirectly by using v and v = g^x % N
So am I understanding this correct that BOTH will notice it when the
other does not know the password?
Second question is about the certificates. For the RFC:
| Client Hello (I) -------->
| Server Hello
| Certificate*
| Server Key Exchange
| <-------- Server Hello Done
| Client Key Exchange (A) -------->
| [Change cipher spec]
| Finished -------->
| [Change cipher spec]
| <-------- Finished
So the server MAY send its certificate but the client will never do
that. A simple rehandshake without exchanging at least the
fingerprints over the secure connection will not work.
Dirk
