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).
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
