SCTs basically work around two things: and asymmetric key and a symmetric
key.  The symmetric key is the shared secret.  I think it is 10 random bytes
(but could be more.)  It is generated by the client and sent to the server
in the request msg.  However it is encrypted with the asymmetric RSA public
key first.  This means that only the owner of the RSA private key can
decrypt it.  The RSA private key owner is the server your sending the
request to.  Now the server can decrypt the symmetric key, create a SCT with
the key and cache it.  The server sends back the SCT ID which the client
will use to create its' own SCT using the same ID and the symmetric key it
generated at first.  Now both sides have a SCT with the same ID and
symmetric key.  The asymmetric key is now not needed any longer and only the
shared symmetric key is used from now on for this SCT.  Client can encrypt
and/or sign tokens and soap bodies with the SCT which uses the shared
symmetric key to do the encryption (i.e. Rijndale, etc).  Only the SCT ID is
sent in the clear so the server can look it up in cache and decrypt the soap
message elements using the shared key.   The SCT ID is not helpful to anyone
else on the "wire" as they don't have the symmetric key and can not generate
it as it was only sent encrypted the first time using RSA during the SCT
request/reply.   So man-in-the-middle is not possible.  To break it, you
would need to break RSA or AES encryption.  Or somehow break X509 cert chain
verification from the client side to inject your own RSA public key and
inject your own box in the middle of the client and server.  None of which
is really that possible or practical today, so I think it is pretty secure.
I would not say impossible, as most anything is possible given the time and
resources.  SCT also has an option to allow the server to contribute entropy
to the symmetric shared key.  So both the server and client makeup the
shared key.  I am unclear how much this would actually add to the security
because to break single entropy from the client would still require one to
break RSA.  So if you could break RSA from the client, I would think you
could break RSA from the server.  However it does toss more walls into the
mix, so I guess it probably useful.  If your interested, I did a SCT
generator in c# which allows you to use TCP channel (or http) and use only
RSA public key on client side without needing certs.  I assume MS does
something very similar but instead uses public key from the negotiated (and
validated) cert.  This uses the public key from the SN assembly.

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

--
William Stacey [MVP]