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

[Tomas-Kraus]

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.)

Source: javaee/metro-wsit#1663
Author: glassfishrobot