So I wanted to roll my own SecurityContextToken (SCT) service.  Not because I want to reinvent the wheel, but because I did not want to have to use X509 certs and because I could not figure out how to issue SCTs using soap.tcp at the server.  All the documentation addresses using IIS web service and ASP.  First a word on SCTs as they can be a bit confusing.

The goal is to authenticate to the server and get a SCT at both sides.  The idea is you can only get a SCT if you authenticate at the server.  The SCTs at both sides have a random 16 byte “secret” key that both sides can use to encrypt the rest of the session (using AES/Rijndael or other.)  This is very similar to how SSL works.  SCTs are a bit more flexible as you don’t have to encrypt all parts of the conversation, only those parts that need encryption, so it is an opt-in model.  The interesting feature is that once the SCT is cached at the server side, you can send messages with only the SCT header in the message and the server can verify you already authenticated so you don’t need to keep sending a UsernameToken (UT).  However, you *should encrypt and/or sign each message with the SCT, so that the server can verify your SCT “knows” the secret key.  Otherwise anyone could construct a SCT using the same SCT.Identifier and can access  your Web method, as only the Identifier string is sent in the header.  At the server, the SCT also maps to an authenticated UsernameToken so that your methods can verify Role memberships and have access to the username, etc.  In WSE, you can use the SecurityContextTokenServiceClient class to request a SCT from a URL.  However this requires a server side X509 certificate.  I wanted a secure solution that did not require a cert, but still used secure PKI to negotiate the SCT.

This method resembles the built-in method, but requires only a standard RSA key pair as created with the RSACryptoServiceProvider class in the .Net framework.  If you sign your assemblies with a strong name (SN), then you already have everything you need.  The server private key needs to be secured as normal.  The client’s public key is already in the assembly for ready access to create an RSA object from it.  This does require that the client calling your web service actually is running your client assembly.  If this is not the case, the client could also get the public key via some prior out-of-band method such as email, diskette, etc.  You don’t want to allow the client to get the public key via a network call as a third party could do a Man-In-Middle attack by returning their own public key to your client.  This is the reason server Certs where created in the first place to prove to the client that you got the correct key and not some other key by an attacker.  As we "know" the server's public key already, we can avoid having to use Certs for this proof.  If you did want to get Public key using a network call, you would need to return a Cert or have some prior security context setup between the you and the server.  Anyway, here is the process:

1)      Client creates public RSA object from public key of service.
2)      Client generates random entropy (secret) bytes (k1) to be used as part of the shared session key (i.e. the SCT.KeyBytes value).
3)      Client creates a new RSA key pair (i.e. clientRSA) to be used for the key exchange.
4)      Client creates a message containing Key entropy bytes, user name, password, and the public key from clientRSA.  Client encrypts Key, user name, password, and public key fields using server’s public key from step 1.  Request is Signed.
5)      Server method gets message.  Server verifies signature and decrypts all fields to get the clear data.
6)      Server authenticates user using any method desired at the server.  I will use Win32’s LogonUser API to leverage Windows authentication so I don’t need another out-of-band user database.  You could, however, use your own database.  A UsernameToken is created (but not cached.)
7)      The server generates its’ random entropy bytes (k2) and combines them with the client’s “k1” bytes to generate a shared session key (sKey).
8)      The server creates a new SCT and sets the KeyBytes to the sKey.  The SCT is created with the UT passed to the constructor.
9)      The server generates a reply.  It adds “k2”, SCT.Identifier string, Expire date, and UT ID string to the message and encrypts the “k2” bytes using the public RSA key passed in the client request message.  Server also adds a Key Verifier hash so client can verify they both use same key.  The server also signs the reply so the client can verify it came only from the server.  The server also caches the SCT.
10)  The client gets the reply and verifies the signature.  It decrypts the “k2” key and generates “sKey” itself.  It then creates a new SCT using “sKey” and the Identifier passed from the server reply and verifies the KeyVerifier (Note the Identifiers have to match so the server can find the SCT in the cache).
11)  Client can now sign and encrypt future messages using just the new SCT (i.e. no UT required).  The SCT can be used until it expires, however it is probably good practice to get a new SCT for each unique session or set of related method calls.

Now that client has its new SecurityContextToken, it should keep it for the rest of the session and *only use the SCT or a DerivedKeyToken (DKT) derived from the SCT.  The UT is not needed or desired.  The client should also *always encrypt or, at a minimum, sign all outgoing messages with the SCT or DKT.  This is because the server can only verify you know the SCT shared key, if you sign or encrypt the message.  We don’t need to keep attaching the UT in the Soap header because that would be redundant and just overhead.   The SCT is already authenticated, so use that.  We can also add consistency and security to all our web method if we always *require a SCT in the header.  That way WSE automatically verifies the SCT, any hash, or decryption for us.  We do, however, still need to assert in our methods (or in Policy) that a SCT was attached, and the body was signed (or encrypted as needed).  As a rule, I would always require a body signature was attached.  As noted, after we get our SCT, we can forget about any UTs.  We don’t need to send them and should not (unless you have some specific need.)  If you do need to attach a UsernameToken to a Soap header – always encrypt it using the SCT.  The protocol summary is as follows:

C->S
    {K1, Username, password, C’s public key}S’s public key
    {digest[K1, Username, password, Mod1, Mod2, Exp]}C's private key

C<-S
    {K2}C’s public key
    UT.ID
    SCT.Identifier
    SCT.Expires
    KeyVerifier
    {digest[K2, UT.ID, SCT.Identifier, SCT.Expires, KeyVerifier]}S’s private key

Client (C) sends K1, Username, password, and C’s public key to Server (S).  All elements are encrypted with S’s public key.  Server creates SCT with generated sKey and returns K2, UT.ID, SCT.Identifier, SCT.Expires, KeyVerifier and Signature.  K2 is encrypted with C’s public key.  All elements are hashed and then signed using S’s private key.  Client can then verify all elements have not been changed and message sent by S.  Client generates sKey and SCT.

That is about it.  We now have a way to securely pass user credentials to the server and get a SCT in reply using soap.tcp and PKI.  UsernameTokens are then out of the picture so we don’t have to worry about SendPlainText or SendHash stuff anymore.  To keep this post ~short, I will show the implementation at Get SecurityContextToken C# Code .  Also note, this implementation is updated at Updated Get SecurityContextToken in C#. Cheers!

--
William