Major Description
In UsernameToken Profile key derivation, the flag that indicates the use for the salt is being placed on the wrong end. It should be at index 0 but is being placed at index 15. See org.apache.ws.security.message.token.UsernameToken.generateSalt(boolean).
The UsernameToken Profile 1.1 spec says
> "The high order 8 bits of the Salt will have the value of 01 if the key
> is to be used in a MAC and 02 if the key is to be used for encryption.
> The remaining 120 low order bits of the Salt should be a random value."
Java is big endian, which means the high order values come first (i.e. high byte is at index 0 of a byte array). From http://en.wikipedia.org/wiki/Endianness
> "The usual contrast is whether the most-significant or least-significant
> byte is ordered first - i.e. at the lowest byte address - within the
> larger data item. A big-endian machine stores the most-significant byte
> first (at the lowest address), and a little-endian machine stores the
> least-significant byte first. In these standard forms, the bytes remain
> ordered by significance."
Looking at other UsernameToken Profile implementations turned up this example: http://blogs.oracle.com/SureshMandalapu/entry/passwordderivedkeys_support_in_metro
which clearly shows the salt flag is at index 0 of the byte array:
> Absds/FHfgh/swderfa== decodes to 01bb1db3f1477e087fb3075eadf6
(when printing the byte array in hex starting at index 0).
And, in my discussion with Colm to confirm this issue, I asked what should be done about salt validation. Here is what he said:
> Hi Patrick,
>
> > Doesn't that mean index 0 of an array should hold the most significant
> > value?
>
> Yes, I think you're right. Could you submit a JIRA and patch?
>
> > * check both ends and if only one end is either 1 or 2,
> > then use that to validate the usage of the derived key
> > * if both ends contain either a 1 or 2 then skip validation on
> > the usage of the derived key
> > * if neither end has a 1 or a 2, then fail validation
>
> That sounds reasonable to me. I think it could be extended so that we
> validate that the correct flag has been set for signature
> verification, or for decryption, when using a derived key - I don't
> think the current code does this.
>
> Thanks,
>
> Colm.