For generating UsernameToken Authentication with Password Derived Key, don't Base64 encode the Salt value

[glassfishrobot]

Hi, this is related to issue #1662 not hardcoding use of UTF-8"). The CXF team is having difficulty accomplishing interoperability with Metro for UsernameToken auth w/password derived keys (http://www.jroller.com/gmazza/entry/usernametoken_messagelayer_encryption). Specifically, we're noticing for key generation, the salt value is being base64 encoded in Metro PasswordDerivedKey's generate160BitKey(), while the spec doesn't given any indication that should be done:

public byte[] generate160BitKey(String password, int iteration, byte[] reqsalt)
throws UnsupportedEncodingException {

-> String saltencode = Base64.encode(reqsalt); <--

byte[] keyof160bits = new byte[20];
byte[] temp = password.getBytes();
byte[] temp1 = saltencode.getBytes();
byte[] input = new byte[temp1.length + temp.length];

System.arraycopy(temp, 0, input, 0, temp.length);
System.arraycopy(temp1, 0, input, temp.length, temp1.length);

According to line 386-387 of the spec (http://docs.oasis-open.org/wss/v1.1/wss-v1.1-spec-os-UsernameTokenProfile.pdf)::) "The key is derived as follows. The password (which is UTF-8 encoded) and Salt are concatenated in that order", i.e., the 128 salt bits should be used as-is without Base64 encoding them. (Even though lines 365-366 say it should be base64 encoded within the SOAP header, this is related to key generation, a separate matter.)

[glassfishrobot]

Reported by gmazza

[glassfishrobot]

Was assigned to symonchang

[glassfishrobot]

symonchang said:
UsernameToken auth w/password derived keys is not a prefer scenario in the real world. Use Encrypted UsernameToken is recommanded instead.

[glassfishrobot]

gmazza said:
While perhaps lower priority compared your other tasks right now, this functionality is supported by Metro--it's a clear choice given in NetBeans and documented here: http://metro.java.net/guide/ch12.html#ahicv1. We (CXF team) would eventually like to get this process working interoperably with your project (indeed, we may have to make changes on our own end for this as well.) At any rate, the source code given at my blog can be used to test Metro here as well as Metro - CXF interoperability, and feel free to contact me (gmazza at talend dot com) should you have any questions on it. Thanks!

[glassfishrobot]

snajper said:
Symon, this appears well digested and simple to fix - could we address this? The scenario is one of the metro-default-defined ones, also exposed within NetBeans.

[glassfishrobot]

This issue was imported from java.net JIRA WSIT-1663