Re: [reSIProcate] Security class and client-side authentication (longish)
- From: Bob Bramwell <bob@xxxxxxxxxx>
- Date: Tue, 26 Oct 2004 13:25:36 -0600
Cullen Jennings wrote:
Sorry this thread is so long but there is some good stuff in here ....
>
Glad you think so :-) I've >>> snipped <<< a bunch of stuff for the sake of
brevity. Odd numbers of >>> are Cullen, even numbers of >> are Bob.
I think we should consider a design meeting to sort some of this out.
Sounds good. How should we go about this?
Seems like it would be an excellent topic for a coding session. Fix the TLS
and S/MIME credential handling in the stack and include support for fetching
certificates.
I think we need to figure out a time and place when people can make it. I
would not be able to do it until after Nov 13 (end of IETF)
>
I'm game, although they don't let me out much :-) Always seems ironic to me
that people working in the telecommunications field end up flying places so they
can communicate. I did a contract with Telus once (a Canadian telco) and they
didn't seem to believe in teleconferencing. They kept flying me to Vancouver
for 3-hour meetings.
This stuff is pretty hard to get right, I don't mind that we can override
and pass stuff in, but, I would like it so that for normal programs, all the
hard TLS security stuff happens for them in the stack.
OK. Me being me, I am never confident enough that I know how to do this in
general, so I usually end up leaving room for a user to "override" decisions I
am iffy about.
snip <<<
On 10/22/04 5:51 PM, "Bob Bramwell" <bob@xxxxxxxxxx> wrote:
I am trying to set things up to allow TLS connections to do client
authentication.
Just checking we mean the same thing my client authentication. This means
something acting as a TLS server can get the peerName of the client that
connected to it when the client does mutual TLS.
More or less. The TLS standard requires the client to obtain a certificate from
the server, and *allows* the server to request a certificate from the client,
all as a part of the handshake.
There are a number of things, notably in the Security class,
that will need to change to accomodate this.
At present a Security object has two public certificates associated with it:
its publicCert and its publicIdentityCert. The former is used as the
certificate presented to a TLS client when it connects to a TlsConnection
created in
server mode. The latter only appears to be used for signing stuff
(computeIdentity
and checkIdentity functions). No provision is made for a client side
certificate per se.
uhmm the PublicCert would be used for this
Well, maybe not. At present the PublicCert is used as the server certificate.
If we have a situation where the transport is being used as a TLS client and
the server requires mutual authentication, we *may* want a separate client side
certificate, mightn't we? I would have thought that situation might arise in
practice.
I don't think I understand the exmaple yet (just being slow). You mean you
have a sip server that has one port, that when you do a TLS connection to
it, it claims that it is "a.com" yet this same server also makes connection
to some other systems where it does mutual TLS and claims that it is "b.com"
Is this the example?
Not really. Both the incoming and the outgoing connections would involve
"a.com", but that could still mean that two different certificates (possibly
issued by different CAs) are in use, one as a server cert, and one as a client.
There is a more "interesting" scenario that appears to be possible in
reSIProcate: if I have only one TLS transport and an outgoing message has no
associated domain (presumably a "don't care" situation) the TLS transport is
used for this purpose (in TransportSelector::findTlsTransport). Now, supposing
the server to which the TlsConnection gets established requests a client
certificate.... This is where having a "pool" of client certificates to select
from (based on the acceptable CA list presented by the server) would be useful.
This would have to be on two separate ports (ie TLS transports) and each TLS
transport can have it's own name and cert. I thought this had been working
for a long tiem so that people could have a proxy that could act for
multiple virtual dcomains.
>
In the "a.com" incoming "b.com" outgoing scenario you describe I completely
agree that you would need two transports.
snip <<<
It therefore seems sensible to remove the
Security constructor tlsServer argument and the mTlsServer member variable
altogether.
You might be right that this is exactly the right thing to do but I have
certainly not got my head wrapped around what you are talking about yet
Did my earlier inline comments help? We can bop this around offline if you
think it might be useful.
we might need a quick phone call - my cell is 408 421 9990 if you can catch
me before 9:30 your time today
I don't think my clock is awake at that time. Ask Alan about my concept of
"core hours" sometime :-)
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.
--
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.