Storage of Client Certificates

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

RobertP - 12 Sep 2005 23:05 GMT

If I have 5,000 users of my web service, I need to have 5,000 public keys in
my server's Certificate Store?

Reply to this Message

Pablo Cibraro - 13 Sep 2005 14:23 GMT

No, only if you identitfy your clients through public keys.
In this case, maybe, using a UsernameToken is a better idea. You can use a
UsernameToken to identify clients and a X509 certificate to protect the
messages.
With this solution, your clients must have a public key and you only need a
private key in the server's certificate store.

Regards,
Pablo Cibraro
www.lagash.com

> If I have 5,000 users of my web service, I need to have 5,000 public keys
> in
> my server's Certificate Store?

Reply to this Message

RobertP - 13 Sep 2005 22:38 GMT

To send an encrypted response back to the client, I would need their public
key.

I guess I would not have to store their public key if they send the public
key to me with their request?

Thank You,

Robert

> No, only if you identitfy your clients through public keys.
> In this case, maybe, using a UsernameToken is a better idea. You can use a
[quoted text clipped - 10 lines]
> > in
> > my server's Certificate Store?

Reply to this Message

William Stacey [MVP] - 14 Sep 2005 00:24 GMT

You can use the server's cert to get a SecurityContextToken(SCT). This does
a secure key exchange. So you end up with a private Session key on both
sides. You can then use the SCT to encrypt messages in both directions and
both sides can decrypt as they both have the same session key (inside the
SCT). There are other ways too.

Signature

William Stacey [MVP]

> To send an encrypted response back to the client, I would need their
> public
[quoted text clipped - 24 lines]
>> > in
>> > my server's Certificate Store?

Reply to this Message

jason.chen@newsgroups.nospam - 14 Sep 2005 21:41 GMT

I think so, I've tried that also, successfully. basically client will send
their public key alone with the request, so you read it out from
SoapContext, and use it to encrypt the response. the downside of this is,
any user that has your public key will be able to consume your webservice.
if you think about it, your webservice is no longer 'secure', it's like
opening to public now. if you do not restrict what users can access your
webservice, then why go through the hassels protecting a public webservice
at the first place?

I think this brings up another question I have, what is the best practice in
order to restricted your webservice accessible to a set of known users? if
you have a list of public keys from your clients, how do you figure out
which public key to use when your webservice received a request? best
approach I can think of is maintaining a list of trusted public key
identifiers in your config file, and make sure the public key in the request
is among one of them. how do you guys think?

-jason

> To send an encrypted response back to the client, I would need their public
> key.
[quoted text clipped - 20 lines]
> > > in
> > > my server's Certificate Store?

Reply to this Message

William Stacey [MVP] - 15 Sep 2005 05:57 GMT

WSE has some nice ways to handle this, and you could hard code all this
yourself, but then your recreating the wheel in a lot of respects. First,
you only need one cert - the server's cert. This contains the RSA public
key and you already will have the matching RSA private key protected on the
server somewhere (i.e. container, file, etc). The cert is really only
needed to provide proof to the "client" who it is talking to and not some
man-in-the-middle. Otherwise, you could just do this with just a self
generated RSA key (I have some examples of doing this if you did not want to
use certs). The client starts with an authentication request. The cert is
used during Key exchange to generate a private session key on both sides.
The way WSE surfaces that key is with security tokens - a good one being the
Security Context Token (SCT). WSE has a built in way to get a SCT using
your cert (and the public key in that cert). Once you have a SCT, the cert
is out of the picture on both sides. Now all encryption and signing of
messages can be done with the SCT for the rest of the session (because the
SCT on both sides have the same SessionKey that is used for encryption).
When the client sends a signed message to WSE service, WSE can now verify
that message was signed by a user that "knows" the same session key as the
SCT cached on the server. Then you create a helper method on your Web
service such as AccessAllowed() or something (you can do in policy too I
think.) Each web method that requires security will call this method as a
first step, passing the SoapEnvelope to it. The helper method then verifies
the message was at least signed and that it was signed by an SCT that has
been Authenticated (i.e. the user authenticated in first step with a
password.)

Signature

William Stacey [MVP]

>I think so, I've tried that also, successfully. basically client will send
> their public key alone with the request, so you read it out from
[quoted text clipped - 47 lines]
>> > > in
>> > > my server's Certificate Store?

Reply to this Message

jason.chen@newsgroups.nospam - 15 Sep 2005 15:38 GMT

Hi William,
I guess the idea of using SCT comes from how SSL works, using the cert
to transmit the shared private session key and both sides use the session
key to encrypt request and response going forward. but this method can only
ensure the identity of the server, because you only have the certificate of
the server. you can not identify the client, so anyone can access your data.
your mentioned in your last sentence, the user will be authenticated
with a password, that means both server and client will have to agree on a
password and share that information, isn't this a bad thing to do, and it
breaks the PKI?

-Jason

> WSE has some nice ways to handle this, and you could hard code all this
> yourself, but then your recreating the wheel in a lot of respects. First,
[quoted text clipped - 73 lines]
> >> > > in
> >> > > my server's Certificate Store?

Reply to this Message

William Stacey [MVP] - 15 Sep 2005 18:51 GMT

> I guess the idea of using SCT comes from how SSL works, using the cert
> to transmit the shared private session key and both sides use the session
[quoted text clipped - 8 lines]
> password and share that information, isn't this a bad thing to do, and it
> breaks the PKI?

You identify the client by virtue of the fact that it must know a username
and password on the server in order to get a SCT in the first place. So not
anyone can access your data. It is similar to how SSL works. Also, lets
not confuse keys here. We have a PKI public key on the client and symmetric
session key in the SCT ( same as SSL). The PKI is only used during key
exchange in order for both sides to agree on the symmetric session key.
This key is only known by both sides and sniffing can not discover the SKey.
Once that is done, everything else is done using the SKey and symmetric
encryption (AES, etc).

Signature

William Stacey [MVP]

Reply to this Message

jason.chen@newsgroups.nospam - 15 Sep 2005 19:29 GMT

Hi William,
I guess my problem is with client has to have a username and password to
authenticate itself, the best approach for SCT would be using 2 certificates
(one from server, one from client) to exchange the SKey. Althought I
haven't tried this myself, but I think regular SSL can be done this way, so
I would imagine SCT could support this as well.

thanks,
-Jason

> > I guess the idea of using SCT comes from how SSL works, using the cert
> > to transmit the shared private session key and both sides use the session
[quoted text clipped - 18 lines]
> Once that is done, everything else is done using the SKey and symmetric
> encryption (AES, etc).

Reply to this Message

William Stacey [MVP] - 15 Sep 2005 21:50 GMT

> I guess my problem is with client has to have a username and password
> to
> authenticate itself

Yes, but that is normally what you want to do anyway. He wants to provide
logon.

>, the best approach for SCT would be using 2 certificates
> (one from server, one from client) to exchange the SKey.

The "best" is relative. The best could be to require one-time-password
using a HW key in addition to a username and pw. However, we still need to
live in the real world. Requiring that every client has a cert and managing
that is not practical in most cases.

> haven't tried this myself, but I think regular SSL can be done this way,
> so
> I would imagine SCT could support this as well.

SSL does optionally allow for that, but it is normally not used on the Inet.
Most SSL sites you go to do not require a client cert, but the negotiation
is done solely with the server's cert and public key. Then logon can
proceed in various ways using the secure session.

Signature

William Stacey [MVP]

Reply to this Message

Sujeet - 27 Sep 2005 00:56 GMT

HI! Stacey,
Great post on WSE strategy on SCT.....
One question though....
Does the exchange of SCTs initially occur under the hood with WSE or we
need to explicitly make that happen.....or is it assumed that the same Server
Cert is present on both the client and the server....

sujeet

> > I guess my problem is with client has to have a username and password
> > to
[quoted text clipped - 19 lines]
> is done solely with the server's cert and public key. Then logon can
> proceed in various ways using the secure session.

Reply to this Message

Antonio Dias - 26 Oct 2005 11:20 GMT

> I think so, I've tried that also, successfully. basically client will send
> their public key alone with the request, so you read it out from
[quoted text clipped - 43 lines]
>>>> in
>>>> my server's Certificate Store?

what about keeping the client certificate keyIdentifier in SQl server
and when client send a request you include a UserId, get the certificate
keyidentifier from the DB and compare with the token you received int
the SoapContext. Is this a bad way to identify clients?

Reply to this Message

Storage of Client Certificates

Free Magazines