Re: [reSIProcate] Security class and client-side authentication (longish)
On 10/26/04 12:25 PM, "Bob Bramwell" <bob@xxxxxxxxxx> wrote:
>>
>> I'm really not sure what you are trying to do on this. Can you provide a
>> very specific use case? I thought it already worked for what I think you are
>> describing.
>>
> The new MS LCS 2005 *requires* mutual authentication. So, here I am with my
> B2B
> and someone using MS messenger (let's say) wants to connect through to the LCS
> 2005. In the server role the B2B presents certificate (A) to the MS messenger
> client which is happy, and we have TLS going on that leg of the communication.
> Now the B2B connects to the LCS 2005 which presents its certificate *and*
> requests a client certificate (B) from the B2B. At the moment I am not aware
> that there is any provision in reSIProcate for coping with this. *Please*
> correct me if I am wrong! It would save me a ton of work.
I don't understand why A and B would be different certificates. Explain that
to me but in the meantime I will assume they must be ...
If the B2BUA has two different transports for the two different sides (I
presume they are on different interfaces and thus different transports) it
creates both transports and servers and provides them a different cert. I
could be very wrong but I thought that works in the code today?
I guess what I am suggesting, is use a different transport to connect to LCS
than the one used for the messenger client to connect to the B2BUA.
If A and B are on the same transport, it can't work without TLS "Server Name
Indication" (RFC 3546) which we don't support yet (but should)