Re: [reSIProcate] Security class and client-side authentication (longish)
On 11/17/04 4:22 PM, "Bob Bramwell" <bob@xxxxxxxxxx> wrote:
> 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.
>
I'm curious what a "UA" certificate looks like in the case you are imaging
but I'll ignore that for a second. You realize to make the scenario you
describe above work you will also probably need split horizon DNS so the DNS
names work. I really doubt this will work like you want for non TLS reason
... Keep in mind - a cert does not authorize you for any thing. It
authenticates that you are the DNS name claimed in the cert and then based
on this authentication, something else can do authorization. Anyways
ignoring if you want to to do this ...
I think you can do this with the stack today if the connection you make to
the UA is done on a different port from the connection you make to the
Proxy. In the stack today, when the stack is listening for TLS connection on
port x, anything that comes to that port get's one and only one certificate
presented to it. That is because basic TLS 1.0 does not allow the client to
tell the server who it is trying to connection to. If you want to listen to
connection from 3 different ports and have each port present a different
certificate, that works.
The extension "Server Name Indication" (RFC 3546) allows the TLS client to
tell the stack which server it is trying to connect to before the server
presents a certificate. We don't support this yet but should.