Re: [reSIProcate] Security class and client-side authentication (longish)

[Bob Bramwell <bob@xxxxxxxxxx>]

Sorry to be so long getting back to this thread.  The last couple of weeks have 
been rather hairy.  Anyway, to continue:

Cullen Jennings wrote:
> 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 we are talking about a single TLS domain which is being used for both 
incoming and outgoing messages we have to act as a server and as a client in the 
two situations.  The certificate used to convince a client that we are 
legitimate may not be the same one used to convice a server that we are 
legitimate.  For example, consider a situation where a bunch of UAs can talk 
directly to a proxy over mutually-authenticated TLS connections.  The proxy has 
a server certificate, and the UAs have client certificates (which may all be 
different).  Now we separate the UAs from the original proxy and put a new proxy 
in between, but we want this to be transparent to both ends.  The new proxy must 
present a UA client cert to the old proxy, and the old proxy's server cert to 
the UAs.

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

No guarantee that the two different sides will be on different interfaces.  In 
any case, the decision as to which outgoing transport is used is not based on 
port or interfaces AFAIK:  it is based on the getTlsDomain() value of the SIP 
messages in question.

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

I'm not saying that can't be done, but I can't see how to do that within the 
current reSIProcate TLS transport arrangements.

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

I'll look that up:  not familiar with it.  However, I don't see why "it can't 
work" without this.

Cheers,
        Bob.


--
Bob Bramwell            Jasomi Networks (Canada) | This space
Ph: 403 269 2938 x155   #310 602 11th Ave SW     | intentionally
FX: 403 269 2993        Calgary, AB, T2R 1J8     | left blank.