Colm, the currently implemented UT-SIGN was _not_ implemented to meet the UT 1.1 profile but was based on a .NET WSE implmentation that was long before UT 1.1 . Together with some WSE users we re-engineered the .NET WSE mechanisms and implemented it in WSS4J to have .NET WSE interoperability.
This .NET WSE mechanism used WS-Trust spec to derive the secret key. Also the .NET WES implmentation always use encryption to encrypt the UsernameToken header - thus the password was encrypted - at least these behaviours were discovered analysing the use cases for .NET WSE. If we are going to implement the UT 1.1 functionality then I would propose to introduce a new action name to avoid compatibility problems with existing applications that may use the old .NET WSE way. Regards, Werner > -----Ursprüngliche Nachricht----- > Von: ext O hEigeartaigh, Colm [mailto:[EMAIL PROTECTED] > Gesendet: Dienstag, 22. Juli 2008 18:29 > An: wss4j-dev > Betreff: UsernameToken Derived Keys > > Devs, > > I've been looking at using a UsernameToken to derive a key to > to "sign" > via HMAC some message content. > > Both the UsernameTokenSignedAction (via the UT_SIGN action) and the > TestWSSecurityNew13 test deal with this functionality. There are two > problems. First of all, the Username Token that's created in > both cases > with something like: > > WSSecUsernameToken builder = new WSSecUsernameToken(); > builder.setWsConfig(reqData.getWssConfig()); > builder.setPasswordType(reqData.getPwType); > > builder.setUserInfo(reqData.getUsername(), password); > builder.addCreated(); > builder.addNonce(); > > still includes the password, which is a major security hole. > This issue > was raised by Sergio here: > > https://issues.apache.org/jira/browse/WSS-127 > > Secondly, the secret key to use with the HMAC is apparently derived > according to the WS-Trust spec, e.g. see the getSecretKey methods of: > > http://svn.apache.org/viewvc/webservices/wss4j/trunk/src/org/a > pache/ws/s > ecurity/message/token/UsernameToken.java?view=markup > > IMO the default behaviour should instead be to use the > generateDerivedKey() method of UsernameToken, which is what is in the > UsernameToken Profile 1.1 specification. In other words, the > UsernameToken that's sent across the wire includes username, salt and > iteration values, which the receiving party can use with > their password > to create a suitable secret key. > > I would like to change the UsernameTokenSignedAction functionality to > comply with the U/T 1.1 spec, and also change the SignatureProcessor > functionality so that it calls to generateDerivedKey rather than > getSecretKey. Are there objections to this? Is anyone using this code? > > Colm. > > ---------------------------- > IONA Technologies PLC (registered in Ireland) > Registered Number: 171387 > Registered Address: The IONA Building, Shelbourne Road, > Dublin 4, Ireland > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
