AW: AW: How to sign with DerivedKey based on UsernameToken ala. W SE

[Dittmann Werner <we...@siemens.com>]

Ruchith,
 
when I look ate the XML file that Brian distributed with his first
mail, then it is a "classic" Signature with a shared secret, using
HMAC-SHA1 as the signature algo. The shared secret is produced
using UsernameToken data. The UsernameToken itself is encrypted
before it is transmitted to the receiver. IMHO it is not a sort of
a secure conversation but an one-way signature.
 
The Reference stored in the SecurityTokenReference contains a ref
to the UsernameToken of the request, the reference type specifies
to use UsernameToken. Because of this structure it is somewhat
straightforward to implement it as just another way to sign/verify
in the existing signature/verificatio modules and handlers.
 
As already mentioned, we had this way of signing already (fall last
year) but removed it because it is not according to OASIS WSS.
 
Regards,
Werner

-----Ursprüngliche Nachricht-----
Von: Ruchith Fernando [mailto:ruchith_007@yahoo.com] 
Gesendet: Donnerstag, 21. Oktober 2004 11:10
An: Dittmann Werner; 'Brian Nielsen'; fx-dev@ws.apache.org
Betreff: Re: AW: How to sign with DerivedKey based on UsernameToken ala. WSE


Hi Guys,
 
The WS-Secure Conversation spec lets one derive keys based on a shared secret. This shared secret is established int he initial handshake. And usually it is a SecurityContextToken element. And the the secret is associated with this SecurityContextToken. 
 
When one creates a derived key the the 
<wsse:SecurityTokenReference>...</wsse:SecurityTokenReference>
element in the <DeriedKeyToken> element should refer to the <SecurityContextToken>. This is implemented in the Sec Conv imple that is there in WSS4J.
 
But the spec also allows DerivedKeys to use some other token that has a secret associated with it as the base of deriving keys. I guess Brian is trying to get that sort of a scenarion to work. But this is NOT implemented YET :-( in the impl available in WSS4J. 
 
Also the Sec Conv handlers support signing parts of the message. HMAC-SHA1 is used as the sig. algo(http://www.w3.org/2000/09/xmldsig#hmac-sha1 <http://www.w3.org/2000/09/xmldsig#hmac-sha1> )
And the signature and vertification functionalities are implemented in the code we have in WSS4J.
 
Regards,
Ruchith
 
Dittmann Werner <we...@siemens.com> wrote:

Brian,

thanks for the pointers. Some things are clearer now.

To solve this specific .NET interoperability problem just
let me sum up what is already available:

The handler(s) already provide ways to create a UsernameToken
and let them set the password type ("text" or "digest"), the
created, the nonce, username, and password. If
the password type is "text" then UsernameToken uses the
passwordstring and puts it in the request without any
modifications. This is a code snippet from a Handler:

WSSAddUsernameToken builder = new WSSAddUsernameToken(actor, mu);
builder.setPasswordType(pwType);
// add the UsernameToken to the SOAP Enevelope
builder.build(doc, username, password);

if (utElements != null && utElements.length > 0) {
for (int j = 0; j < utElements.length; j++) {
utElements[j].trim();
if (utElements[j].equals("Nonce")) {
builder.addNonce(doc);
}
if (utElements[j].equals("Created")) {
builder.addCreated(doc);
}
}
}

In the code snippet "builder.setPasswordType(pwType);" sets the
password type. All these setting can be controlled via the
Axis deployment file. Pls have a look into the interop directory,
client deploy wsdd, scenario #2 (Ping 2). There you find how
to setup the UsernameToken that way.

After the UsernameToken was prepared we need to generate the
specific "secret" from the UsernameToken values as described 
in herveyw's blog. There is already a method in UsernameToken
class that generates this secret, eaxctly as decribed in the blog.
This is the method "public byte[] getSecretKey()". Thus we have
all necessary data available.

But this is not the whole story :-).

The missing link is: how to control, produce, and verify a
Signature with the generated secret. Here we need to enhance
the handlers, the Signature methods, and the verification methods.

To control this specific signing is probably easier then the 
verification. For signing with this UsernameToken secret I would 
propose to introduce a additional value for the "signatureKeyIdentifier" 
deployment parameter (something like: "useUsernameTokenKey"). This 
would then drive all necessary checks and setup of the signature class. 
This class has to be enhanced to provide this specific signing 
(the xmlsec library support this, AFAIK).

I have to dig into the WSSecurityEngine to see how to deal with 
this at verfication time.

Just a short question: was the XML request you sent in a previous
mail generated by a .NET client? If so, this could serve as a 
guide how the stuff shall look like.

Regards,
Werner

> -----Ursprüngliche Nachricht-----
> Von: Brian Nielsen [mailto:brian@sweetxml.org] 
> Gesendet: Donnerstag, 21. Oktober 2004 00:01
> An: fx-dev@ws.apache.org
> Betreff: RE: How to sign with DerivedKey based on 
> UsernameToken ala. WSE
> 
> 
> Werner,
> 
> Once more thank you for a quick reply.
> 
> According to herveyw's blog, it is from the WS-Trust spec.
> (http://www.dynamic-cast.com/mt-archives/000019.html)
> 
> I the article "Securing Web Services with WSE 2.0" by Aaron Skonnard
> (http://msdn.microsoft.com/msdnmag/issues/04/10/ServiceStation
> /default.aspx)
> The section "Using DerivedKeyTokens" describes the basic idea 
> behind and
> that seems to be in line with this posting in a blog
> (http://benjaminm.net/PermaLink.aspx?guid=e11eaf6b-9d81-4fee-b
> fdf-9e2936545f
> 4e) where he states:
> 
> 
> WSE 2.0 uses the algorithm defined in the WS-SecureConversation
> specification, which creates the derived key by performing a 
> SHA1 hash over
> the original key (in the case below, a reference to the key),
> along with the
> combination of a label and a nonce value (a unique value 
> that's seen only
> once). (I cannot make wss4j generate a Nonce with a 
> PasswordText
> password, and at the moment I have no idea what the label is, 
> but that'll
> probably become clear when I know how to do it). In another posting he
> compares the different tokens
> (http://benjaminm.net/PermaLink.aspx?guid=87fd974c-1f77-437f-8
> 191-6e6fd92f83
> 1f)
> 
> Another ressource is the article "How to: Sign a SOAP Message 
> by Using a
> User Name and Password" from msdn
> (http://msdn.microsoft.com/library/default.asp?url=/library/en
> -us/wse/html/g
> xconsigningsoapmessageusingusernamepassword.asp)
> 
> That describes how it's expressed in a policy file.
> 
> Hope that's what you asked for? 
> 
> Regards 
> Brian.
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: Werner Dittmann [mailto:Werner.Dittmann@t-online.de] 
> Sent: Wednesday, October 20, 2004 8:49 PM
> To: Brian Nielsen
> Cc: fx-dev@ws.apache.org
> Subject: Re: How to sign with DerivedKey based on 
> UsernameToken ala. WSE
> 
> 
> Brian,
> 
> there is some code in the UsernameToken class that generates 
> a specific
> value using hashing etc to generate a secret key according to 
> WS-Trust 
> specification. Maybe this is what .NET uses as as key to sign 
> parts of the
> request. Once upon the time we had code in that used this 
> generated value to
> sign 
> the parts of the SOAP request. This code was remove because 
> it was not 
> required by the OASIS WSS Specification. Unfort unatly, because early 
> this year we moved the code from sourceforge to Apache this 
> code maybe not
> in CVS.
> 
> Do you have any pointers to the way .NET works with this?
> 
> Regards,
> Werner
> 
> Brian Nielsen wrote:
> > I have to interop with a service using .NET WSE, where several parts
> > are signed based on a feature implemented in WSE 2.0, using 
> a hashed 
> > value on the UsernameToken, which i recall comming from the secure 
> > conversation spec. I can see some code regarding secure 
> conversation 
> > and som handlers, but no documentation or examples, can 
> someone please 
> > guide me how to add a handler to my client-config.wsdd that 
> uses this 
> > feature?
> > 
> > Regards
> > Brian Nielsen
> 
> 




  _____  

Do you Yahoo!?
Yahoo!  <http://us.rd.yahoo.com/mail_us/taglines/aac/*http://promotions.yahoo.com/new_mail/static/ease.html> Mail Address AutoComplete - You start. We finish.