Commercial Certificate -- dotnet web services enhancements

Cormac
7/26/2005 8:57:30 AM

Hi Alex/Sam

I was in a similar situation since I didn't want to even use X509
certificates tried to find a resolution to using X509 certificates since you
have to install them on all client machines, if you get them from a
certificate authority they cost a packet. If you create your own then you
have to create your own certificate authority and issue them through one of
the Microsoft servers (forgot the name). Until I found William Staceys (Cool
Guy) blog.

http://spaces.msn.com/members/staceyw/Blog/cns!1pnsZpX0fPvDxLKC6rAAhLsQ!268.entry

He was mad enough to come up with a solution that uses Security Context
Tokens or Secure Conversation as many people call it that allows the
developer to develop a Security Context Token Service that issues Security
Context Tokens to clients and encrypt and sign each SOAP message without
using X509 certificates.

He uses strong naming on each assembley to create a Public and Private key
just like in X509 certificates to create a Symmetric key to be used by both
endpoints.

I have implemented it with WSE 2.0 SP 3 and am upgrading it to Beta 2, I
would strongly recommend it instead of using X509 certificates why through
money and alot of frustation away on X509 certificates when this is free and
better in my humble opionon.

Cormac

[quoted text, click to view]

Alex Trebek
7/26/2005 3:38:26 PM

Excellent!! -- Thanks!!!

Alex

[quoted text, click to view]

Julie Lerman
8/1/2005 5:41:58 PM

Guys-
Do you NEED certificates on all of the clients?
The most common scenario is to get a web server certificate. This confused
me at first because there is "no such thing" at verisign/thawte etc. They
are SSL Certificates!!

oops there's lightning!!!
gotta shut down
more later
julie lerman
[quoted text, click to view]

Julie Lerman
8/1/2005 9:38:40 PM

wow - some storm. The power just came back on! <G>

Anyway...

depending on your scenario, you don't always need the clients to have their
own certificates, though you definitely want one on the server. Typical
scenario is if the clients' are being authenticated either on the intranet
using their windows logins or over the web iwth a login/password against a
database. You can use something like a secure conversation and get all of
the encryption and signing. there are situations where this might mean
encrypting and signing with a usernametoken which is possible but not
recommended - and if you are talking about WSE2.0 (assuming this to be the
case) and considering using the username tokens - definitely check Keith
Brown's article about using them safely. (you should find that right on the
msdn web services (Securing the Username Token with Web Services
Enhancements 2.0 ) at msdn.microsoft.com/webservices/buildling/wse.

You really have to figure out what it is you want and need to accomplish in
your application (on both ends) and then you can decide how you want to put
the pieces together. It is a little complicated which is why in WSE3.0, they
have gone to a model of selecting the entire scenario from one end to the
other and back again, rather then determining what you want the client to do
and then separately determining what you want the server to do. That's the
new turnkey security scenarios.

Anyway - I hope this helps a little, and if you want to explain what your
scenario is, I can try to help you figure out where you need what types of
certificates. Also, if you are able to move right to WSE3.0 (which means
using VS2005 and also not deploying until late fall) then a lot of these
things will be much easier.

Julie Lerman

[quoted text, click to view]

Cormac
8/2/2005 3:46:03 AM

Hi just me again

Excellent point Julie, have seen some of your posts, blog and I think some
articles you may have written. I still think William's implementation is the
best solution I have seen anywhere because certificates are messey to set up
on client machines
where in Williams scenario strong named assemblies are used I have found
they are far more simple to enable. Plus the whole point of Secure
Conversation is that it is far easier to implement and not resticted like SSL
in its capacity for just endpoint to endpoint encryption. I.E. what if more
hops are required in the solution.

I have been playing with the new WSE 3.0, the implementation of MTOM and the
turnkey scenario's are excellent but very dissapointed that still no choice
for someone who DOES NOT WANT TO USE X509 certificates, Kerberos, or SSL and
just plain jane (sorry only jane I knew wasn't very plain) solution like what
William has came up with that is super powerful as well as being simple.

Cheers

Cormac

[quoted text, click to view]

Alex Trebek
8/2/2005 9:52:50 AM

Julie,

In my case, the 'clients' are actually internal SOAP services communicating
with one another behind the firewall in a SOA architecture. Due to the
sensitive nature of the information being passed (credit info, ssns, etc..)
the machines have to prove they have the rights to contact the service
(other server) and the entire comm must be encrypted. Govt restrictions
require that we don't pass unencrypted info. Outside clients will contact a
http web service (running under ssl) which will then pass their request to
appropriate service for processing (some sync and some async depending on
the nature of the request. Although there are existing Windows secure comm
protocols that can handle machine-to-machine, not all servers are/will
remain Win. In my case, I'll never have outside clients contacting the SOAP
services directly. They will always pass thru the http web service as a
proxy to a tcp service.

Thanks for you help,

Alex
[quoted text, click to view]

kevin
9/8/2005 5:06:03 AM

Interesting information.
But what if you do, in fact, need an x509 cert?
One of our clients is mandating that we use them. This means not only x509,
but we have to get them from a CA (ie, not make our own).
How do we do this? We called Verisign and they had no clue what we were
talking about. I've found a tool with instructions on how to generate a file
to send to verisign but it's a tarball for Unix.
We've requested SSL certs before with no probs, but isn't this different?
Don't we have to send Verisign the public/private key?
Help?
Thanks.
-- kevin

[quoted text, click to view]

William Stacey [MVP]
9/8/2005 5:54:48 PM

Thanks Cormac. FWIW, I created a new one based on Secure Remote Password
(SRP) protocol from Tom Wu of Standford:
http://channel9.msdn.com/ShowPost.aspx?PostID=107763

This basically does the same thing as the other one, as the end result is
still a SCT; but it does the key exchange very different.
I feel this one is even more secure then the other one for various reasons:
1) No RSA public key to protect or worry about on the client side. Keys are
dynamically generated for each run of the protocol.
2) No keys on *either side need to be stored or generated.
3) Discovering the password does not allow previous (or future) messages to
be decrypted by an attacker.
4) Discovery of the SKey, does not get anyone closer to discovering the
password.
5) No password is ever sent on the wire, not even encrypted. Only Proof of
Knowledge of the password. Password is never in the server pipe-line.
6) No replay on the SCT negotiation is possible. So it is kinda like a
built in Nonce, without having to use or track Nonce history.
7) Works perfect with custom username/pw database.

Possible down sides:
1) Sends Username in the clear.
2) As Password is never sent in the clear (nor can it be generated) so the
server side can not use LogonUser() API to do Windows logon in your logon
provider.

However, both of those could be overcome by using another step. Get a SCT
using an Anonymous Username and some well-known password. Then use that SCT
to encrypt another token such as UsernameToken.SendPlainText or some other
method. As you have a SCT, you can encrypt a message and reply to do pretty
much what ever you wanted. Hope that makes some sense. Cheers.
--
William Stacey [MVP]

--
William Stacey [MVP]

[quoted text, click to view]

Got something to say? Click here to post a reply to this thread.

Don't see what you're looking for? Try a search.

View other messages about dotnet web services enhancements

dotnet web services enhancements : Commercial Certificate