SecurityContextTokens and SecureConversation

SecurityContextTokens and SecureConversation

Post by UGV0ZXIgRm » Thu, 07 Jul 2005 23:12:04


Hi,

I need to implement my own issuing of SCTs through a negotiation between
client and server resulting in client and server agreeing on a common
symmetric key.

The original request will be unsigned - the trust is established through the
negotiation.

Is it possible to extend WSE 2.0 to allow for this ? Or is the whole
secureconversation part of WSE completely tied to certificates ?

Thanks,
 
 
 

SecurityContextTokens and SecureConversation

Post by William St » Fri, 08 Jul 2005 00:25:17

Here is one I did using public key (signed assem) on client and private rsa
key on server:
http://www.yqcomputer.com/ !1pnsZpX0fPvDxLKC6rAAhLsQ!303.entry

--
William Stacey [MVP]

"Peter Flintholm" < XXXX@XXXXX.COM > wrote in

 
 
 

SecurityContextTokens and SecureConversation

Post by UGV0ZXIgRm » Wed, 20 Jul 2005 20:05:02

Thanks for your reply.

The exchange in your example uses proprietary elements (the SCTMsg). I would
like to comply with the WS-Trust specs, i.e. use RequestSecurityToken /
RequestSecurityTokenResponses for the negotiation as specified in the
Negotiation and challenge extensions of the WS-Trust specification. The spec
allows for custom
tags to be inserted in the RequestSecurityToken element.

Of course, it is possible to do this by rewriting the SCTMsg class to
something that in XML representation is a RequestSecurityToken element, but I
was wondering if it is possible to extend the WSE SecurityContextTokenService
and SecurityContextTokenServiceClient classes instead ?

What I need to do is to insert my own custom tags in the
RequestSecurityToken that is sent from the extended
SecurityContextTokenServiceClient class. Likewise I will have to implement
support for recieving RequestSecurityTokenResponse in the extended
SecurityContextTokenService class (as the protocol i'm implementing is a
4-way exchange). Do you have any clues whether this is possible, or should I
simply implement it from scratch (SoapClient/SoapService) like your example ?
 
 
 

SecurityContextTokens and SecureConversation

Post by William St » Wed, 20 Jul 2005 21:09:31

I am now confused. It seemed you had asked to get a SCT without using
certs. Do do that, you need to do it yourself as WS SCTs can be had with
http and certs only (IIRC). If you want to go outside that (i.e. TCP and/or
no certs), then you need to do something like this. Note, once you have the
SCT, the rest of the conversation is standard WS-* stuff using the SCT.

--
William Stacey [MVP]

"Peter Flintholm" < XXXX@XXXXX.COM > wrote in
 
 
 

SecurityContextTokens and SecureConversation

Post by UGV0ZXIgRm » Wed, 20 Jul 2005 21:37:06

lease apologize the confusion - but I'm new to WSE ;-)

My concern is the actual soap messages exchange when aquiring the context
token. I want to use the WS-Trust Negotiation model to establish the secure
context something like this :

C -> S : RST
S -> C : RSTR
C -> S : RSTR
S -> C : RSTR

The last RSTS from the server will contain an identifier used by both client
and server. The common symmetric key will be derived by both the client and
server from my protocol specific elements embedded in the RST/RSTRs.

This kind of exchange is fully in line with the WS-SecureConversation and
WS-Trust specs. Establishing a secure context is in no way bound to http or
certs from the specs - this must be a WSE issue.

"William Stacey [MVP]" wrote:

 
 
 

SecurityContextTokens and SecureConversation

Post by William St » Thu, 21 Jul 2005 07:14:52

gt; The last RSTS from the server will contain an identifier used by both

This is basically what mine does in one request/reply pair. If you want
exactly what RSTS does, then why not use that?
If you want to change something, you can build on mine or rebuild your own.
What are you doing again and why can't you
use what is in WSE already?

--
William Stacey [MVP]



 
 
 

SecurityContextTokens and SecureConversation

Post by UGV0ZXIgRm » Thu, 21 Jul 2005 19:27:03

'm trying to establish trust - in the form of a context token - using a
password based authentication and key exchange protocol. The
WS-SecureConversation spec recommends that this is done by exchanging RST and
RSTR messages.
In my case the initial RST will by unsigned. There is no initial trust - the
trust is established through the negotiation.

Please note, that my goal is to exchange these WS-* compliant messages - not
specifically to use WSE, or for that matter .Net. I am doing this as a part
of a project on password based protocols to demonstrate partical use within
existing specifications.

The issue I have with your example is that it does not use the recommeded
RST/RSTR XML in the exchange, but instead exchanges some proprietary XML (the
serialized SCTMsg). I would have liked the information in the SCTMsg to have
been embedded in RST/RSTR messages.

I have tried to do this by extending the SecurityTokenService and
SecurityTokenServiceClient class, but as far as I can see the
SecurityTokenService class only supports signed requests ? Is that correct
understood ?

A bit strange, since the clientside SecurityTokenServiceClient supports
unsigned requests ?

-Peter





"William Stacey [MVP]" wrote:

 
 
 

SecurityContextTokens and SecureConversation

Post by William St » Fri, 22 Jul 2005 01:57:51

> The issue I have with your example is that it does not use the recommeded

Just change the SCTMsg to be same names and format of RST/RSTR then. I
don't have the need to rework the sample myself, but you should be able to
it with some work.



If the requestor doesn't have a X.509 then you need some form of TLS
connection or prior ephemeral key. IMO, at some point you will need some
form of PKI to bootstrap the process. Wish you luck.

--
William Stacey [MVP]