[Security] TLS-SRP Questions

[Hannes Tschofenig]

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