You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wss4j-dev@ws.apache.org by "O hEigeartaigh, Colm" <Co...@iona.com> on 2008/07/22 18:29:09 UTC
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/apache/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: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
RE: UsernameToken Derived Keys
Posted by "O hEigeartaigh, Colm" <Co...@iona.com>.
Hi Werner,
Ok I'll leave the existing UT-SIGN functionality as is, although I think it needs to be looked at for 2.0. I'm going to submit a patch to allow programmatic key derivation as per the UsernameToken 1.1 spec for the case of signing a soap message.
Colm.
-----Original Message-----
From: Dittmann, Werner (NSN - DE/Muenich) [mailto:werner.dittmann@nsn.com]
Sent: 23 July 2008 10:18
To: O hEigeartaigh, Colm; wss4j-dev
Subject: AW: UsernameToken Derived Keys
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:Colm.OhEigeartaigh@iona.com]
> 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: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>
----------------------------
IONA Technologies PLC (registered in Ireland)
Registered Number: 171387
Registered Address: The IONA Building, Shelbourne Road, Dublin 4, Ireland
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org
AW: UsernameToken Derived Keys
Posted by "Dittmann, Werner (NSN - DE/Muenich)" <we...@nsn.com>.
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:Colm.OhEigeartaigh@iona.com]
> 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: wss4j-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: wss4j-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: wss4j-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: wss4j-dev-help@ws.apache.org